rc icon indicating copy to clipboard operation
rc copied to clipboard

tab-completion for commands

Open TobyGoodwin opened this issue 9 years ago • 9 comments

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.)

TobyGoodwin avatar May 17 '15 19:05 TobyGoodwin

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.

xyb3rt avatar Dec 05 '15 18:12 xyb3rt

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.

TobyGoodwin avatar Dec 23 '15 11:12 TobyGoodwin

@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?

TobyGoodwin avatar Apr 25 '18 21:04 TobyGoodwin

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.

refi64 avatar Apr 26 '18 05:04 refi64

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.

TobyGoodwin avatar Apr 26 '18 06:04 TobyGoodwin

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.

xyb3rt avatar Apr 26 '18 06:04 xyb3rt

Ah! I see, I think... I still find git infinitely baffling :smile:

Have added that commit.

TobyGoodwin avatar Apr 26 '18 06:04 TobyGoodwin

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.

TobyGoodwin avatar Apr 28 '18 07:04 TobyGoodwin

I think this works 154fb22

I'll take another look with fresh eyes tomorrow, see if it can be cleaned up at all.

TobyGoodwin avatar Apr 28 '18 22:04 TobyGoodwin