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:
I haven't looked closely at the proposed patches, but there are certain
things about the reasoning I find puzzling.
> === 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...
That's not quite how it works. Readline does use $COMP_WORDBREAKS
(indirectly) to decide the word to complete, but does so before it
invokes any application-specific completion function. That's the
word against which the values in COMPREPLY will be matched.
The programmable completion code also splits the line into words the
same way, when it creates the COMP_WORDS array. It's important that
use the same word delimiters, so the programmable completion code is
working on the same text as readline.
Those two cases, and deciding whether or not to quote a character in
a possible completion, are the places where the word break characters
are used. Only the last one happens after the completion function is
executed.
> If the current argument is 'http://', then:
> - if $COMP_WORDBREAKS contains ':' , only '//' will be used by the
> completion process.
> - otherwise (and if ' ' (space) is part of $COMP_WORDBREAKS), the
> whole 'http://' string will be used.
Correct, but this happens before the completion function is invoked.
> The problem is that this evaluation happens after the completion function
> has returned (and won't work before $COMP_WORDBREAKS has really been
> modified to match our needs):
No. The problem is exactly the opposite: COMP_WORDBREAKS has to be
modified before completion is attempted.
>
> The FAQ says:
> E13) Why does filename completion misbehave if a colon appears in the
> filename?
> and the workaround proposed, ie:
>
> _comp() {
> export COMP_WORDBREAKS="${COMP_WORDBREAKS//:/}"
> COMPREPLY=( $(compgen -W "http://foo http://bar"; -- "$cur") )
> }
> ... has mainly two drawbacks:
E13 doesn't say that. It does recommend changing COMP_WORDBREAKS, but
does not say to put it into a completion function. It's a general
guideline, not one geared towards programmable completion specifically.
That misunderstanding affects your two `drawbacks'.
>
> 1) the completion has to alter the user environment
> $ comp http://<TAB>
> $ echo $COMP_WORDBREAKS
> "'><=;|&( ### ':' has disappeared, other completion functions
> ### may suffer from this
>
> 2) the first time we try a completion, _comp() has not yet been executed
> so our modified $COMP_WORDBREAKS isn't yet part of the context.
> $ comp http://<TAB>
> completes (the first time) to
> $ comp http:http://
> but after that, $COMP_WORDBREAKS is modified so the next calls will succeed.
I will look at the patches to see what they do, but, as I said above,
the reasoning is confusing.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
