Re: in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches
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
Re: in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches
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 vinc...@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)
