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?
