On 2020-06-16 at 08:57, to...@tuxteam.de wrote: > On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f...@tuta.io wrote: > > [...] > >> Maybe sometimes completion is not working as it should, nothing is >> perfect, but globally I think that it saves time more than its >> wastes. > > Then just use it and be happy. And just accept that some (me, among > others) are happier without :-) > > Yes, I've tried it. Yes, I think it's technically nifty. But no, it > doesn't mesh well with the way I work. Even if it were bug-free, it > wouldn't be "my" thing. > > I live by the command line, and there are roughly two classes of > things I do: those I do very often, where history search is just > unbeatable, and those I do rarely. For those I have a man page open, > sometimes a notebook (in Emacs, but I disgress) to take notes and I > proceed slowly. > > The top of the first class are candidates for automation and > scripting. > > In the first class, I don't need autocompletion, since I know what > I'm doing (heck, my muscle memory nearly knows. In the second class, > autocompletion is a train wreck waiting to happen: I really *want* to > know why each piece is there. > > The only really useful autocompletion is actually file path > autocompletion, and I have that without any extra packages.
I tend to concur with all of the above, but I have some additional details to note. There *are* contexts where I would find the ability to tab-complete things other than paths to be useful; lengthy package names for apt-get would be one example. For me, however, the cost in memory/CPU/etc. footprint that has already been noted is enough to outweigh the benefit that that would bring. The biggest reason why I intentionally disable programmable completion, however, is actually centered on the way it *changes* file-and-directory path completion. Without programmable completion, if I type the first few characters of a directory name and press Tab, it will complete up to the name of that directory (or to the point of uniqueness, if there are multiple files / directories in the current context starting with that prefix) and then stop. With programmable completion, IIRC from the last time I checked (which I'll admit was quite some years ago), in at least some contexts it will instead complete all the way up to the end of the path. I specifically recall a case when I had a directory /tmp/foo/bar/baz, and I wanted to create /tmp/foo/bar/quux; I typed 'mkdir /tmp/f[tab]', with the intention of typing 'b[tab]quux', and found that it had completed to the end of 'baz' (and possibly to an actual filename within that directory) and I had to backspace by some considerable amount to get to where I'd wanted to be. Cases where there is a multi-layer directory tree with only one item at each level of the tree are comparatively rare, but ISTR that even when there were multiple items at deeper levels it would still complete up to the point of uniqueness, ignoring directory boundaries. The additional keystrokes to tab-complete to the end of such a "only one item in the parent directory" tree are, for me, more than worth it for the additional level of control involved. If I could selectively enable programmable completion for only specific contexts where I've tried it out and decided that I want it, I'd probably be happy to use it in at least some contexts. I haven't found a good way of doing that, however, and haven't found it worth the bother to dig all that deeply looking for one. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
