in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches

[Vincent Lefevre]

It seems that $COMP_WORDBREAKS annoys users when filenames contain
one of its characters:
http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00034.html
http://lists.gnu.org/archive/html/bug-bash/2006-09/msg00019.html
http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00163.html
and my bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674084

Unsetting $COMP_WORDBREAKS is not a solution, as completion would no
longer work in contexts where such characters are word separators.

How about the following behavior when the user types [TAB]?

1. Try to complete the whole word, ignoring $COMP_WORDBREAKS.
2. If there are no matches, take $COMP_WORDBREAKS into account
like now.

I suppose that false positives for (1) are rare enough, so that this
heuristic would work well in practice.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Chet Ramey]

On 5/23/12 7:11 AM, Vincent Lefevre wrote:
> It seems that $COMP_WORDBREAKS annoys users when filenames contain
> one of its characters:
> http://lists.gnu.org/archive/html/bug-bash/2005-07/msg00034.html
> http://lists.gnu.org/archive/html/bug-bash/2006-09/msg00019.html
> http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00163.html
> and my bug report:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674084
>
> Unsetting $COMP_WORDBREAKS is not a solution, as completion would no
> longer work in contexts where such characters are word separators.
>
> How about the following behavior when the user types [TAB]?
>
> 1. Try to complete the whole word, ignoring $COMP_WORDBREAKS.

"The whole word" implies some default hidden value for COMP_WORDBREAKS
that the user can't touch or modify. The whole raison d'etre for having
it in the first place is to allow the user to specify these things. It's
easy enough to have COMP_WORDBREAKS only contain whitespace and shell
metacharacters. Maybe there should be a shell option to set that.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU ch...@case.edu http://cnswww.cns.cwru.edu/~chet/

[Raphaël Droz]

On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote:
> It seems that $COMP_WORDBREAKS annoys users when filenames contain
> one of its characters:

[...]

> Unsetting $COMP_WORDBREAKS is not a solution, as completion would no
> longer work in contexts where such characters are word separators.

indeed, it's not

On Thu, May 24, 2012 at 03:16:40PM -0400, Chet Ramey wrote:
> The whole raison d'etre for having
> it in the first place is to allow the user to specify these things. It's
> easy enough to have COMP_WORDBREAKS only contain whitespace and shell
> metacharacters.

of course but COMP_WORDBREAKS is used in the context of different
completion which are kind enough to not alter main user environment.
That's why COMP_WORDBREAKS would need to apply in a given "context"
( like the scope of a function being used as a completion :) )

On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote:
> How about the following behavior when the user types [TAB]?
>
> 1. Try to complete the whole word, ignoring $COMP_WORDBREAKS.

> 2. If there are no matches, take $COMP_WORDBREAKS into account
> like now.

See:
https://lists.gnu.org/archive/html/bug-bash/2011-05/msg00148.html
[thread follow-up]:
https://lists.gnu.org/archive/html/bug-bash/2011-06/msg00032.html

The patch in the above thread allowed COMP_WORDBREAKS to be set on a
completion basis using a newly created `complete` -B switch.

It uses the proper hook for this task but as been considered (probably
rightfully) "heavyweight". It would needs a strong knowledge of the
codebase (and hook definition) in order to add such a feature in an
elegant manner.



regards