bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] support 'COMP_WORDBREAKS' value on a per-completion basis


From: Raphaël
Subject: Re: [RFC] support 'COMP_WORDBREAKS' value on a per-completion basis
Date: Fri, 24 Jun 2011 15:13:18 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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.bug@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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]