rakitzis
tab-completion for commands
At one time I'd considered offering tab-completion only for commands that you've already typed (either in this session or one loaded via $history). But I think I should at least experiment with real-time find every command in the path completion.
I think it is acceptable if tab-completion for commands only works when the command is the first word on the line. Consider
X = foo Y = abc<tab> def<tab> ghi<tab>
Ideally, we should complete abc as a filename, def as a command, and ghi as a filename again. But that is unlikely to happen.
This is for GNU readline. (It's possible that libedit could be taught to complete commands; I don't know.)
I have implemented completion of builtin and external commands, functions and variables in my fork with commits 41a196fd and 2884a347. I've tried to explain everything in the commit messages, so that I spare you the details here.
The second commit is pretty useful for the completion example in your post. Instead of the second <tab> you could use <M-!> to get command name completion for def, for the other two cases of <tab> filename completion would still be the default.
Wow, thanks!
Apologies that I haven't had a chance to review this yet. At first glance the code looks reasonable, but hope to look more closely at some point over the winter holiday.
@muennich Bert, I am so sorry, I cannot believe I have neglected this for so long :cry:
I can see your commits in github, but I cannot for the life of me work out how to get them into the tree. Can you turn them into a PR? Or even just email me a patch?
Those commits don't seem to be part of a branch (maybe it was deleted?), but you should be able to do git cherry-pick 41a196f 2884a34 to pull them in.
Those commits no longer seem to be in the repository, even though github can see them somewhere!
Anyway, I was able to get them from @muennich 's own repo, they merged cleanly, and the result is in a branch called completion while I test things.
Sorry I rebase my commits regularly onto your master; I should have opened a pull request for this. Anyway, I would suggest, that you also cherry-pick my commit 4aed5d2 which I would include in my PR.
Ah! I see, I think... I still find git infinitely baffling :smile:
Have added that commit.
I've tidied the code up slightly cb99a1b
And I've added a check so we only complete executable commands 6fe8c0e
The latter obviously makes an awful lot of stat() calls. I was worried it would be too slow. But on the slowest box I could find, with NFS root, TAB TAB on an empty command line spits back
Display all 884 possibilities? (y or n)
apparently instantaneously. So I think we can live with it. (Computers are so darn quick these days!)
The one remaining flaw I can see is that we don't handle subdirectories along $path. I know this is not the way Unix has gone: we have wrappers git log rather than subdirs git/log. But Unix is wrong :smile: As things stand, @muennich 's version completes the directory as if it were a command; mine ignores directories. In an ideal world, I'd like to complete the directory as, say, sub/ then further TABbing would offer up the names inside that directory (or directories, if it occurs multiple times along the path). It's a bit more work though.
I think this works 154fb22
I'll take another look with fresh eyes tomorrow, see if it can be cleaned up at all.