Alex Kost <alez...@gmail.com> skribis: > Ludovic Courtès (2015-06-07 18:36 +0300) wrote:
[...] >> However it’s important to fall back to file name completions for things >> that are not handled, so that at least it is not worse than without the >> pcomplete code. > > Yes, it is the current behaviour (I mean the file names completion). Perfect. >>> Completing may lag a bit from time to time. It happens because shell >>> commands (like ‘guix ... --help’) are called when necessary to find >>> options, packages, etc. But the found entries are "memoized" so next >>> time the same entries will be completed much faster. >> >> I wonder if ‘guix-pcomplete-run-guix’ couldn’t run the command in a REPL >> instead of spawning a process. That is, when completing ‘guix build’, >> it would evaluate something like: >> >> (with-output-to-string >> (lambda () >> (catch 'quit >> (lambda () >> ((@ (guix scripts build) guix-build) "--help")) >> (const #t)))) >> >> How does that sound? > > It was the initial deliberate decision to separate completions code from > interacting with "guix repl", to make completing independent. I imagine > that a user wouldn't like to see that some "Guix REPL has been started" > just because he presses TAB after ‘guix pa’ in his shell buffer. Well, > at least I wouldn't use such strange completions. > > I think lags made by spawning the guix processes are bearable and not > repeatable (I mean the next time ‘guix pa’<TAB> is completed > immediately), so I would not like to change the code to use a REPL if > you don't mind :-) > > (Perhaps in the future there will be added some option (e.g., a boolean > `guix-pcomplete-use-repl' variable) to choose what a user prefers) Right, it makes sense to have that module independent of the rest. I just tried and it feels faster than the Bash completion anyway. :-) Thank you! Ludo’. PS: I wonder if something could also be done for “./pre-inst-env guix”...
