On Thu, Jun 23, 2011 at 10:49:20AM -0400, Chet Ramey wrote:
> On 5/30/11 2:05 PM, Raphaël Droz wrote:
> > It seems like if gnu.bash....@googlegroups.com eat the first occurrence
> > of this email (not in the mailman archives)... second attempt:
> >
> > === Rationale:
> > Let's say you want to complete http URL (which contain ':').
> >
> > The completion probably contains this kind of statement:
> >
> > _comp() {
> > COMPREPLY=( $(compgen -W "http://foo http://bar"; -- "$cur") )
> > }
> >
> > After the completion function is evaluated, readline will consider
> > the value of $COMP_WORDBREAKS to split the word to complete...
>
> I sent an earlier message explaining how this explanation was slightly
> wrong, but I looked at the patches and they do the right thing. The
> patch attempts to determine the command name before readline performs
> its wordbreak processing, and installs a new value for the set of word
> break characters before that happens.
I'm was misleading in my earlier message. I talked about COMP_WORDBREAKS
value during the time of a bash instance (function parsing, first
invocation for first completion, COMP_WORDBREAKS changes, second
invocation which use the expected value).
If we change the scope and look at the "second invocation" (of the
completion function), you're explanation was very clear. COMP_WORDBREAKS
is first used by readline. And the readline code was nice in this
aspect: providing the exact hook name I had to search for:
rl_completion_word_break_hook. bash implements its part of
completion and use it (eg, calling programmable completion) with the
common rl_completer_word_break_characters OR, if implemented, the
word_break_completion_hook(). Priority given to the later
(_rl_find_completion_word()).
>
> The question that comes to mind is whether or not this complication is
> worth it. This seems like a pretty heavyweight solution to an
> occasional problem with `:'.
It is partly heavyweight... but it uses a well defined hook
char *rl_completion_word_break_hook()
which was sleeping in the core of readline for decades.
Sadly, in the current form of the patch, the hook is _systematically_
implemented in bashline.c, so word_break_completion_hook() is
_systematically_ fired.
I would have preferred something like:
[ in the context we know the current cmd_name ] {
if(progcomp_search ( cmd_name )) {
// register the hook
rl_completion_word_break_hook = word_break_completion_hook;
}
But I don't know the code enough to attempt such a thing.
Worse, find_cmd_start ( 0 ) is chronologically redundant.
Ideally, I guess having
char *word_break_completion_hook(char *cmd_name);
would be more useful than the simple:
char *word_break_completion_hook(void);
It would avoid the need to call find_cmd_start() twice at each <tab>
press, but it would mean storing *cmd_name (in a quite long call stack).
> The best approach might be to remove the
> colon from the default set of word break characters. I have to think
> that the number of users completing colon-separated path values is
> smaller than the number attempting to complete URLs.
Please don't !
We need ':' in the default set of word break characters, completing
colon-separated paths is still useful in 2011.
The point of the patch is just is to *allow* to change the default set
when needed. It is useful for the completion of commands using
protocol://path as argument (think about gvfs-mount and all the
"strings://" which can come in the game):
file, ssh, {http,ftp}{,s}, smb, dav, obex, ...
I didn't think a lot about this but it _may_ be useful for the other
applications using readline I know about: the mysql client.
It's just a matter of choosing COMP_WORDBREAKS for a given completion
but I agree that it should be the least intrusive possible.
I hope this email was less confusing.
Raph
