Re: [gentoo-dev] bash-completion-2.1-r1

[Samuli Suominen]

On 09/09/13 12:24, Michał Górny wrote:
> Hello, all.
>
> I'd like to ask finally: who feels himself responsible for deploying
> bashcomp-2.1-r1? Does he have any kind of plan? Does anyone care at
> all?

2.1-r1 works great here and I don't see any other work left than maybe a 
wiki page for instructing people howto use `complete` like `complete -r` 
to remove unwanted completions that cause grief in the way people want 
to use the command
and you don't need to disable completions to get the filename instead, 
bash-completion supports... (from README, first entry in FAQ)

Q. The bash completion code inhibits some commands from completing on
    files with extensions that are legitimate in my environment. Do I
    have to disable completion for that command in order to complete on
    the files that I need to?

A. No. Use M-/ to (in the words of the man page) attempt file name
    completion on the text to the left of the cursor. This will
    circumvent any file type restrictions put in place by the bash
    completion code.

> Do I have to say it's pretty far from professional to commit it
> half-working, with no clear information how to proceed, neither for
> users nor for developers? As far as I can see, there were mostly either
> random patches or random bugs, with no clear generic guidelines.
>
> I have enough projects on my back but I guess I'll end up carrying this
> mess if nobody bothers to do so.
>
>
> For future reference, I so far know the following:
>
> 1. bash supports two directories for completions: completionsdir
> (/usr/.../completions) and compatdir (/etc). gentoo added a third
> directory that i will call gentoodir (/usr/.../bash-completion).
>
> 2. bash sources all files in compatdir (at start?).
>
> 3. eselect used to symlink stuff from $gentoodir to $compatdir to
> enable completions. therefore, all enabled stuff polluted
> the environment all the time.
>
> 4. files in completionsdir are sourced when command matching filename
> is typed in. that is 'foo <tab>' -> "$completionsdir/foo" is sourced.
>
> 5. in order for completionsdir to work,
> /usr/share/bash-completion/bash_completion must be sourced first.
> (is this just me? is this something to be done in global bashrc?)

yes, that's the way to enable bash completion support per user just like 
documented in top of README

> Aside to the above, what needs to be answered:
>
> 1. how to properly disable completions the 'new way'?

something like
http://blog.onetechnical.com/2012/06/19/disable-bash-autocompletion-on-ubunt/
should be replicated at wiki.gentoo.org

>
> 2. do we want to support adding stuff to $compatdir?

why not, does something need this?

> what do we do with completions that don't fit $completionsdir?

like? some old format of bash completion files that don't work if not 
sourced directly?
should be treated like other bugs, ie. treat it as a bug, report 
upstream of the file, patch the file
if not possible, put them in the compatdir?

didn't tackle the compatdir issue yet because nothing obvious needed it, 
surely adding extra eclass code is on need-basis... :/

> 3. how do we handle completion 'dependencies'? the 'old way' just
> relied on them being sourced from $compatdir early. do we source them
> explicitly now? do we put them in $compatdir unconditionally?

> 4. do we want to maintain eselect for bash completions? do we want it
> to handle disabling and 'enabling' completions the 'new way'?

eselect module seems unnecessary, when you can disable them using 
`complete` and the list of completions you get by `ls` :P
but like I said before, it's still doable if someone wants to add 
another layer, I just don't see any value in that...

so seems like people who claim 2.1-r1 is somehow broken or half-working 
didn't read README, and insist on ready wiki page also for ~arch users?