bash-completion
bash-completion copied to clipboard
_filedir: remove . and .. from suggestions
The title says it all. This is a breaking change, but I would be surprised if anyone entered e.g. the text .. by typing Ctrl+j twice. This change allows to fully complete a hidden file name when there is only one hidden file besides . and .. (or at least, to benefit from prefix completion, such as with .git and .gitignore).
Any chance that this gets merged some day? This is easy to review.
Easy to review, hard to decide. The goal makes sense to me, but then again I'm not convinced we want to do that. It feels just so weird not be able to start to complete a longer path that way.
I don't follow what you mean by Ctrl+J though, I thought the offending completions would be there just by entering them, i.e. the periods, as is, then tab as usual etc.
There's a bunch of stylistic issues in the patch, some of which would likely be fixed by shfmt. But I'll point them out if/once we know that + the fixing work wouldn't be a waste of your and my time.
I’m not sure I get your concern about longer paths. Which kind of paths this patch would prevent you from completing? Unless I’ve overlooked something, it only removes paths which are equal to . or .., it does not remove longer paths that involve such dots.
(About Ctrl+J: I was simply saying that, currently, someone who would want to enter .. using bash-completion, would use Ctrl+J for that purpose (typing .<tab> wouldn’t work because the dot is a common prefix to at least . and ..). But this looks pointless anyway.)
It will break for example ls ..<Tab>, no completions offered after that. One has to manually type at least up to the trailing slash as in ./or ../ to get completion towards the current or parent dir going further. Personally, the current dir case is a rarity, but with completions starting with the parent dir I tab a lot, and having to enter the slash interferes badly with my muscle memory there. Likely because at least with my keyboard layout (Finnish FWIW) it is much easier to reach the tab than the slash (which requires both hands).
I see now. Then, what about removing . and .. only when the word being completed is . ?
By the way, I realize that the behavior I originally proposed and implemented lacks generality, we should do this instead: when the word being completed is . or ends with /., we discard . and .. and anything that ends with /. or /.. from completions.
For the . case, I think I would be annoyed if hitting tab after it gave me e.g. .gitignore without any options when I meant to be going to the parent dir. Surely I could learn not to hit tab there but just do the two periods, but I don't know.
For the ends with /. case, I see some problems too, for example when variables are involved ($somedir/.. etc) or tildes (~/.. etc). And actually just going more than one level upwards (../.. etc).