Re: bash-completion pros/cons
[much snipping]
On Tue 16 Jun 2020 at 09:19:16 (-0400), The Wanderer wrote:
> On 2020-06-16 at 08:57, tomas@tuxteam.de wrote:
> > On Tue, Jun 16, 2020 at 01:53:59PM +0200, l0f4r0@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.
> > 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.
It knows the names of a lot of subcommands, and can spell them.
> The biggest reason why I intentionally disable programmable completion,
> however, is actually centered on the way it *changes* file-and-directory
> path completion.
That can be annoying.
> 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.
It seems that I have to press [TAB] more than once for it to complete
the actual filename, but do use [ESC] [BACKSPACE] to rubout by word
rather than character.
But in any case, AIUI most of the above can be controlled by bash
itself, through things like shopt, readline, and even history.
Where bash-completion does get in the way for me is, for example,
where you download a file that's, say, a PDF but it arrives via wget
called, say, index_0001.3872359.html, for whatever reason.
So you type xpdf inde [TAB] and bash-completion refuses to
complete the name any further. If you're lucky, typing * [RETURN]
will work, if there aren't any disruptive filenames which match
inde*, but in other cases the fastest workaround I know is to type
[HOME]less[SPACE][END] whereupon bash-completion is happy to match
any old filename for the less command, which you then rub out.
That's just one example, but it represents a whole class where it
seems that a bunch of files have disappeared because bash won't match them.
> 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.
Yes, good luck with that! It's probably deeply embedded in bash, and
even if you could hide/unhide some files, everything's likely to be
cached on efficiency grounds. It might be possible to set up some
xterms with tailored bashrc variables, to at least make completion
only work in certain instances. But then you're probably in the wrong
directory with the wrong history whenever you try to use one.
Cheers,
David.
Reply to: