PATCH: Add CORRECT_NOCOMPSYS option

PATCH: Add CORRECT_NOCOMPSYS option

[Frank Terbeck]

---

The documentation snippet pretty much tells the story. Without the new
option set, you get:

% nautilus
zsh: correct 'nautilus' to '_nautilus'? (YNEA)

With the option set, it goes directly to:
% nautilus
zsh: command not found: nautilus

I think it's a reasonable solution, that a) removes this (to me)
annoying warning and b) makes a lot of sense, if you want to use the
command_not_found_handler() feature.

This certainly is not perfect. A better solution would be to disallow
_commandname type function names from being the result of a correction
without completely disabling correction.

Still, I think this would work fairly well in most cases.
Per default, the option is disabled, which means zsh will behave
exactly like it does now. No change at all.

Regards, Frank

 Doc/Zsh/options.yo |   14 ++++++++++++++
 Src/options.c      |    1 +
 Src/utils.c        |   15 ++++++++++++++-
 Src/zsh.h          |    1 +
 4 files changed, 30 insertions(+), 1 deletions(-)

diff --git a/Doc/Zsh/options.yo b/Doc/Zsh/options.yo
index 6b3ba34..c6b99dd 100644
--- a/Doc/Zsh/options.yo
+++ b/Doc/Zsh/options.yo
@@ -1015,6 +1015,20 @@ pindex(NOCORRECTALL)
 item(tt(CORRECT_ALL) (tt(-O)))(
 Try to correct the spelling of all arguments in a line.
 )
+pindex(CORRECT_NOCOMPSYS)
+pindex(NO_CORRECT_NOCOMPSYS)
+pindex(CORRECTNOCOMPSYS)
+pindex(NOCORRECTNOCOMPSYS)
+item(tt(CORRECT_NOCOMPSYS))(
+When using the function based completion system compsys, the function that
+handles completions for a command is usually named tt(_<command>). When using
+correction, those functions will look like the most probable target for the
+correction code. For the user, it usually does not make sense to call these
+functions by hand.
+
+This option causes zsh to tt(not attempt correction) if a function of the
+previously described name exists.
+)
 pindex(DVORAK)
 pindex(NO_DVORAK)
 pindex(NODVORAK)
diff --git a/Src/options.c b/Src/options.c
index d310f34..14b4da8 100644
--- a/Src/options.c
+++ b/Src/options.c
@@ -115,6 +115,7 @@ static struct optname optns[] = {
 {{NULL, "completeinword",     0},			 COMPLETEINWORD},
 {{NULL, "correct",	      0},			 CORRECT},
 {{NULL, "correctall",	      0},			 CORRECTALL},
+{{NULL, "correctnocompsys",   0},			 CORRECTNOCOMPSYS},
 {{NULL, "cshjunkiehistory",   OPT_EMULATE|OPT_CSH},	 CSHJUNKIEHISTORY},
 {{NULL, "cshjunkieloops",     OPT_EMULATE|OPT_CSH},	 CSHJUNKIELOOPS},
 {{NULL, "cshjunkiequotes",    OPT_EMULATE|OPT_CSH},	 CSHJUNKIEQUOTES},
diff --git a/Src/utils.c b/Src/utils.c
index cf37582..79e1105 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2257,7 +2257,7 @@ spscan(HashNode hn, UNUSED(int scanflags))
 mod_export void
 spckword(char **s, int hist, int cmd, int ask)
 {
-    char *t;
+    char *t, *funame;
     int x;
     char ic = '\0';
     int ne;
@@ -2282,6 +2282,19 @@ spckword(char **s, int hist, int cmd, int ask)
 	    return;
     }
     t = *s;
+
+    if (cmd && isset(CORRECTNOCOMPSYS)) {
+	x = (int)strlen(t);
+	funame = (char *)zalloc(x + 2);
+	*funame = '_';
+	strncpy(funame + 1, t, x);
+	funame[x + 1] = '\0';
+	if (shfunctab->getnode(shfunctab, funame)) {
+	    free(funame);
+	    return;
+	}
+	free(funame);
+    }
     if (*t == Tilde || *t == Equals || *t == String)
 	t++;
     for (; *t; t++)
diff --git a/Src/zsh.h b/Src/zsh.h
index 3c1623c..0558739 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -1856,6 +1856,7 @@ enum {
     COMPLETEINWORD,
     CORRECT,
     CORRECTALL,
+    CORRECTNOCOMPSYS,
     CPRECEDENCES,
     CSHJUNKIEHISTORY,
     CSHJUNKIELOOPS,
-- 
1.6.2.1.136.g8e24

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Bart Schaefer]

On Apr 5,  2:07am, Frank Terbeck wrote:
}
} This certainly is not perfect. A better solution would be to disallow
} _commandname type function names from being the result of a correction
} without completely disabling correction.

My reservation about this is that the leading-underscore naming
convention is (1) just that, a convention, and (2) specific to this
implementation of the completion system -- the whole idea of putting
the completion system into shell code was to remove this kind of
dependency from the base shell and make it possible for anyone to
implement their own system (admittedly increasingly unlikely at
this point, but still).

A more general solution would be an fignore-type variable, which
compinit could set to the value "_*" or some such thing.

-- 

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Frank Terbeck]

Bart Schaefer <schaefer@brasslantern.com>:
> On Apr 5,  2:07am, Frank Terbeck wrote:
> }
> } This certainly is not perfect. A better solution would be to disallow
> } _commandname type function names from being the result of a correction
> } without completely disabling correction.
[...]
> A more general solution would be an fignore-type variable, which
> compinit could set to the value "_*" or some such thing.

Agreed. But well beyond my knowledge of the zsh sources. :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

On Sat, 04 Apr 2009 19:37:17 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 5,  2:07am, Frank Terbeck wrote:
> }
> } This certainly is not perfect. A better solution would be to disallow
> } _commandname type function names from being the result of a correction
> } without completely disabling correction.
> 
> My reservation about this is that the leading-underscore naming
> convention is (1) just that, a convention, and (2) specific to this
> implementation of the completion system -- the whole idea of putting
> the completion system into shell code was to remove this kind of
> dependency from the base shell and make it possible for anyone to
> implement their own system (admittedly increasingly unlikely at
> this point, but still).
> 
> A more general solution would be an fignore-type variable, which
> compinit could set to the value "_*" or some such thing.

Right, here's a more general solution.  Shout if I've missed something.

Index: Doc/Zsh/options.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/options.yo,v
retrieving revision 1.80
diff -u -r1.80 options.yo
--- Doc/Zsh/options.yo	26 Mar 2009 15:21:39 -0000	1.80
+++ Doc/Zsh/options.yo	5 Apr 2009 18:11:45 -0000
@@ -1007,6 +1007,9 @@
 Note that, when the tt(HASH_LIST_ALL) option is not set or when some
 directories in the path are not readable, this may falsely report spelling
 errors the first time some commands are used.
+
+The shell variable tt(CORRECT_IGNORE) may be set to a pattern to
+match words that will never be offered as corrections.
 )
 pindex(CORRECT_ALL)
 pindex(NO_CORRECT_ALL)
Index: Doc/Zsh/params.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/params.yo,v
retrieving revision 1.52
diff -u -r1.52 params.yo
--- Doc/Zsh/params.yo	3 Mar 2009 21:04:53 -0000	1.52
+++ Doc/Zsh/params.yo	5 Apr 2009 18:11:46 -0000
@@ -797,6 +797,14 @@
 The number of columns for this terminal session.
 Used for printing select lists and for the line editor.
 )
+vindex(CORRECT_IGNORE)
+item(tt(CORRECT_IGNORE))(
+If set, is treated as a pattern during spelling correction.  Any
+potential correction that matches the pattern is ignored.  For example,
+if the value is `tt(_*)' then completion functions (which, by
+convention, have names beginning with `tt(_)') will never be offered
+as spelling corrections.
+)
 vindex(DIRSTACKSIZE)
 item(tt(DIRSTACKSIZE))(
 The maximum size of the directory stack.  If the
Index: Src/utils.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/utils.c,v
retrieving revision 1.220
diff -u -r1.220 utils.c
--- Src/utils.c	24 Mar 2009 16:14:33 -0000	1.220
+++ Src/utils.c	5 Apr 2009 18:11:47 -0000
@@ -2236,6 +2236,7 @@
 
 static int d;
 static char *guess, *best;
+static Patprog spckpat;
 
 /**/
 static void
@@ -2243,6 +2244,9 @@
 {
     int nd;
 
+    if (spckpat && pattry(spckpat, hn->nam))
+	return;
+
     nd = spdist(hn->nam, guess, (int) strlen(guess) / 4 + 1);
     if (nd <= d) {
 	best = hn->nam;
@@ -2257,7 +2261,7 @@
 mod_export void
 spckword(char **s, int hist, int cmd, int ask)
 {
-    char *t;
+    char *t, *correct_ignore;
     int x;
     char ic = '\0';
     int ne;
@@ -2293,6 +2297,14 @@
 	    break;
     if (**s == Tilde && !*t)
 	return;
+
+    if ((correct_ignore = getsparam("CORRECT_IGNORE")) != NULL) {
+	tokenize(correct_ignore = dupstring(correct_ignore));
+	remnulargs(correct_ignore);
+	spckpat = patcompile(correct_ignore, 0, NULL);
+    } else
+	spckpat = NULL;
+
     if (**s == String && !*t) {
 	guess = *s + 1;
 	if (itype_end(guess, IIDENT, 1) == guess)



-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Bart Schaefer]

On Apr 5,  7:13pm, Peter Stephenson wrote:
}
} Right, here's a more general solution.  Shout if I've missed something.

Looks reasonable to me.  Should it be made clearer that this does not
apply to the CORRECT_ALL option?

I was just looking at adding something to _setup to copy the value of
CORRECT_IGNORE into the ignored-patterns style, but that suffers from
the same bootstrapping issues as MENUSELECT and ZLS_COLORS.  So maybe
it would just be better to document it somewhere.

Or perhaps it would be good enough simply to set it if it is not set:

if ! zstyle -m ':completion:*:-command-:*' ignored-patterns '*'
then
  zstyle ':completion:*:-command-:*' ignored-patterns '_*'
fi

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

On Sun, 05 Apr 2009 15:11:15 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Apr 5,  7:13pm, Peter Stephenson wrote:
> }
> } Right, here's a more general solution.  Shout if I've missed something.
> 
> Looks reasonable to me.  Should it be made clearer that this does not
> apply to the CORRECT_ALL option?

I added the sentence

  The pattern does not apply the correction
  of file names, as applied by the tt(CORRECT_ALL) option (so with the
  example just given files beginning with `tt(_)' in the current
  directory would still be completed).

> I was just looking at adding something to _setup to copy the value of
> CORRECT_IGNORE into the ignored-patterns style, but that suffers from
> the same bootstrapping issues as MENUSELECT and ZLS_COLORS.  So maybe
> it would just be better to document it somewhere.
> 
> Or perhaps it would be good enough simply to set it if it is not set:
> 
> if ! zstyle -m ':completion:*:-command-:*' ignored-patterns '*'
> then
>   zstyle ':completion:*:-command-:*' ignored-patterns '_*'
> fi

Or maybe use $CORRECT_IGNORE here if set and maybe allow ignored-patterns
to be set in such a way that it won't do that.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Richard Hartmann]

On Mon, Apr 6, 2009 at 11:09, Peter Stephenson <pws@csr.com> wrote:

> I added the sentence
>
>  The pattern does not apply the correction
>  of file names, as applied by the tt(CORRECT_ALL) option (so with the
>  example just given files beginning with `tt(_)' in the current
>  directory would still be completed).

Just to be certain: A binary called _foo would never be considered for
spelling correction in this case?

richih@titanium ~ % echo $CORRECT_IGNORE
_*
richih@titanium ~ % pwd
/home/richih
richih@titanium ~ % which _foo
/bin/_foo
richih@titanium ~ % _fo<enter>
zsh: command not found: _fo
richih@titanium ~ % foo<enter>
zsh: command not found: foo
richih@titanium ~ %



Richard

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

On Wed, 27 May 2009 18:30:13 +0200
Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 11:09, Peter Stephenson <pws@csr.com> wrote:
> 
> > I added the sentence
> >
> >  The pattern does not apply the correction
> >  of file names, as applied by the tt(CORRECT_ALL) option (so with the
> >  example just given files beginning with `tt(_)' in the current
> >  directory would still be completed).
> 
> Just to be certain: A binary called _foo would never be considered for
> spelling correction in this case?

Correct.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Greg Klanderman]

>>>>> Peter Stephenson <pws@csr.com> writes:

> On Wed, 27 May 2009 18:30:13 +0200
> Richard Hartmann <richih.mailinglist@gmail.com> wrote:
>> 
>> Just to be certain: A binary called _foo would never be considered for
>> spelling correction in this case?

> Correct.

I don't use the correction stuff, only a matcher-list that does exact
match, then case-insensitive, then case-insensitive substring.

But in the same vein, what I really want is a way to configure the
behavior for functions, variables, etc. beginning with "_" to be like
filenames beginning with ".": completion should work if I have
explicitly typed the leading "_", but even substring matching should
not *generate* a leading "_".

Can anyone point me to the file completion logic that does this?

greg

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Richard Hartmann]

On Wed, May 27, 2009 at 21:12, Greg Klanderman <gak@klanderman.net> wrote:

> But in the same vein, what I really want is a way to configure the
> behavior for functions, variables, etc. beginning with "_" to be like
> filenames beginning with ".": completion should work if I have
> explicitly typed the leading "_", but even substring matching should
> not *generate* a leading "_".

I think this is a good explanation of what, imo, the final goal should
be.


RIchard

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Frank Terbeck]

Richard Hartmann <richih.mailinglist@gmail.com>:
> On Wed, May 27, 2009 at 21:12, Greg Klanderman <gak@klanderman.net> wrote:
> 
> > But in the same vein, what I really want is a way to configure the
> > behavior for functions, variables, etc. beginning with "_" to be like
> > filenames beginning with ".": completion should work if I have
> > explicitly typed the leading "_", but even substring matching should
> > not *generate* a leading "_".
> 
> I think this is a good explanation of what, imo, the final goal should
> be.

The final goal for what?
For completion (without looking at it in detail), I think what Greg
wants could be done with the _ignore completer. At least I got
something similar for a set of commands:

zstyle ':completion:*:complete:-command-::commands' \
    ignored-patterns 'aptitude-*'

Because I never want to complete the commands named
aptitude-create-state-bundle or aptitude-run-state-bundle.

With the above style 'apti<tab>' always completes to 'aptitude'.
But 'aptitude-<tab>' offers the two commands mentioned earlier, too,
in case I really really want one of them.

My completer style looks like this:
zstyle ':completion:*' completer _expand _complete _ignored _approximate

Where _ignore is the important bit.


That's completion. Correction is a whole other deal. And
CORRECT_IGNORE is just for that. So you don't get completion functions
as _suggestions_ for _correction_. (E.g. you don't have vim installed
but you try to execute it, chances are that correction will ask you
'zsh: correct 'vim' to '_vim'? (YNEA)' - which is utterly useless and
annoying).

So, when you're talking about a final goal, IMHO, CORRECT_IGNORE is
quite a reasonable solution. And it *only* works on words in command
position (aka. the stuff 'setopt correct' does - words corrected by
'setopt correct_all' are not touched at all).

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Greg Klanderman]

>>>>> Frank Terbeck <ft@bewatermyfriend.org> writes:

> The final goal for what?

Not completing all the stupid completion widget functions starting
with "_" at a shell prompt where they are totally irrelevant.

It'd still not be perfect; ideally they'd be in some other namespace
or something and therefore never be completed, but various helper
functions of my own would still be completable if I explicitly type
the "_".

> For completion (without looking at it in detail), I think what Greg
> wants could be done with the _ignore completer.

> :

> So, when you're talking about a final goal, IMHO, CORRECT_IGNORE is
> quite a reasonable solution.

Neither of these mechanisms do what I described.  If you allow
substring completion, i.e.

| zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}' '+ l:|=* r:|=*'

then even with the 'ignored-patterns' zstyle set to '_*', if you try
to complete something which has no non-ignored matches, it will then
fall back to not ignoring those patterns, and will complete to
something that starts with "_" even when there was no "_" before you
hit <tab>.  If you remove the _ignore completer, then you can never
complete a function starting with "_".

For CORRECT_IGNORE, just look back to Richard's original question in
this thread - with that setting you can *never* complete something
that matched the pattern, which is not what you want.

Even with the 'matcher-list' setting for substring completion, file
completion of files starting with '.' does work as I want.  Can
someone point me to where that is handled?

cheers,
Greg

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Frank Terbeck]

Greg Klanderman <gak@klanderman.net>:
> >>>>> Frank Terbeck <ft@bewatermyfriend.org> writes:
> 
> > The final goal for what?
> 
> Not completing all the stupid completion widget functions starting
> with "_" at a shell prompt where they are totally irrelevant.
[...]

Yes, that was my guess. Completion.

> > For completion (without looking at it in detail), I think what Greg
> > wants could be done with the _ignore completer.
> 
> > :
> 
> > So, when you're talking about a final goal, IMHO, CORRECT_IGNORE is
> > quite a reasonable solution.
> 
> Neither of these mechanisms do what I described.  If you allow
> substring completion, i.e.
> 
> | zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}' '+ l:|=* r:|=*'
> 
> then even with the 'ignored-patterns' zstyle set to '_*', if you try
> to complete something which has no non-ignored matches, it will then
> fall back to not ignoring those patterns, and will complete to
> something that starts with "_" even when there was no "_" before you
> hit <tab>.  If you remove the _ignore completer, then you can never
> complete a function starting with "_".

Since I don't use matcher-lists, I cannot comment any further. Compsys
experts will have to take on that one. :)

> For CORRECT_IGNORE, just look back to Richard's original question in
> this thread - with that setting you can *never* complete something
> that matched the pattern, which is not what you want.

That's my point. CORRECT_IGNORE has *nothing* to do with completion.
It's about correction. That is precisely why I was asking about what
Richard meant by 'final goal', because the thread initially had
nothing to do with completion.

Final goal in completion - based on what you described - will have to
be solved within compsys.

Final goal in correction (for the problem I described), can be
achieved by what CORRECT_IGNORE provides. If someone wants more
control in _correction_ than that, that someone would probably have to
reimplement the correction code into a more flexible system (maybe
even function based - like compsys). But I doubt it would be worth it.

> Even with the 'matcher-list' setting for substring completion, file
> completion of files starting with '.' does work as I want.  Can
> someone point me to where that is handled?

Could a compsys guru shed some light on this? :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

On Thu, 28 May 2009 14:44:33 -0400
Greg Klanderman <gak@klanderman.net> wrote:
> Even with the 'matcher-list' setting for substring completion, file
> completion of files starting with '.' does work as I want.  Can
> someone point me to where that is handled?

It's probably where the references to GLOBDOTS are in
Src/Zle/computil.c.  See if .'s stop being ignored when GLOBDOTS is
turned on; if so, ^x? will produce trace output that should show you if
the effect of the glob is being produced within the shell function
suite, or is hidden somewhere, which would probably be compfiles.

_path_files makes undocumented and somewhat cryptic calls to compfiles,
which is implemented within the zsh/computil module.  This is cryptic in
a more cosmic sense.  Anyone who still remembers looking at the BASIC
code for Philosopher's Quest on the BBC Micro will find it familiar.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Greg Klanderman]

>>>>> Peter Stephenson <p.w.stephenson@ntlworld.com> writes:

> It's probably where the references to GLOBDOTS are in
> Src/Zle/computil.c.  See if .'s stop being ignored when GLOBDOTS is
> turned on;

Yep, 'setopt globdots' stops the '.'-files from being ignored, so that
gives me somewhere to start.

> if so, ^x? will produce trace output that should show you if
> the effect of the glob is being produced within the shell function
> suite, or is hidden somewhere, which would probably be compfiles.

> _path_files makes undocumented and somewhat cryptic calls to compfiles,

Yeah, I've traced into there once or twice, gotten really lost, and
eventually given up.  So I'll probably put this aside for now until I
am feeling more adventurous.. the dearth of useful comments makes it
rather impenetrable without large blocks of time to spend on this.

Like I just spent a while trying to understand the two uses of
GLOBDOTS in computil.c, attempting to reconcile why those two uses
appear in similar looking but logically very different expressions,
and wondering if one of those expressions is wrong.

>From your past comments Peter, I've inferred that this code is all due
to a group of contributors who are no longer active, is that right?

thanks,
Greg

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

Greg Klanderman wrote:
> From your past comments Peter, I've inferred that this code is all due
> to a group of contributors who are no longer active, is that right?

Sven Wischnowsky wrote almost all of the programmable completion code
himself, but then got a proper job.  It's amazingly effective but very
hard to fathom; even after I've spent hours puzzling through a bit and
worked out enough to see how to fix a bug, it always surprises me just
how little I've learnt about the overall code.  Needless to say, if we
can reclaim this for the human race, comment it, and make it fit
together in a way that makes it possible to maintain, it would be a huge
help.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Greg Klanderman]

>>>>> Peter Stephenson <pws@csr.com> writes:

> Needless to say, if we
> can reclaim this for the human race, comment it, and make it fit
> together in a way that makes it possible to maintain, it would be a huge
> help.

I suppose there's no hope of getting Sven to help us add some comments?
Anyway, sounds like as any of us spend any time in this code we need
to make a point of adding comments with anything we learn and get
those committed to the codebase.

Do those two uses of GLOBDOTS in computil.c happen to make any sense to you?

greg

Re: PATCH: Add CORRECT_NOCOMPSYS option

[Peter Stephenson]

Greg Klanderman wrote:
> Do those two uses of GLOBDOTS in computil.c happen to make any sense to you?

In the first case, cfp_bld_pats(), it's compiling a list of matched
files (presumably in a given directory, but that's a guess) to return
from the array pats.  It's skipping those files to which the
NO_GLOB_DOTS test applies.  At what stage this function is called is
another matter.

The second case, cfp_add_sdirs(), is more obscure, but evidentally sdirs
has come down from the special-dirs style so the code is related to that.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

Following up to
   http://www.zsh.org/mla/workers/2009/msg00793.html
from almost two years ago:

>>>>> On May 28, 2009 Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> On Wed, May 27, 2009 at 21:12, Greg Klanderman <gak@klanderman.net> wrote:
>> But in the same vein, what I really want is a way to configure the
>> behavior for functions, variables, etc. beginning with "_" to be like
>> filenames beginning with ".": completion should work if I have
>> explicitly typed the leading "_", but even substring matching should
>> not *generate* a leading "_".

> I think this is a good explanation of what, imo, the final goal should be.

What do you guys think of the patch below?  I'm open to better names
for the zstyle.. I've tested it a fair amount locally.

thanks,
Greg



Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.9
diff -u -r1.9 _command_names
--- Completion/Zsh/Type/_command_names	19 Aug 2007 23:31:31 -0000	1.9
+++ Completion/Zsh/Type/_command_names	1 Mar 2011 20:28:22 -0000
@@ -4,10 +4,20 @@
 # complete only external commands and executable files. This and a
 # `-' as the first argument is then removed from the arguments.
 
-local args defs
+local args defs hide ffilt
 
 zstyle -t ":completion:${curcontext}:commands" rehash && rehash
 
+zstyle -s ":completion:${curcontext}:functions" hide-internal hide
+case "${hide:-never}" in
+  no|false|never)
+    ffilt='';;
+  yes|true|always)
+    ffilt='[(I)[^_.]*]';;
+  auto|dtrt)
+    [[ $PREFIX = [_.]* ]] && ffilt='' || ffilt='[(I)[^_.]*]';;
+esac
+
 defs=(
   'commands:external command:_path_commands'
 )
@@ -24,7 +34,7 @@
 
   defs=( "$defs[@]"
     'builtins:builtin command:compadd -k builtins'
-    'functions:shell function:compadd -k functions'
+    "functions:shell function:compadd -k functions$ffilt"
     'aliases:alias:compadd -k aliases'
     'suffix-aliases:suffix alias:_suffix_alias_files'
     'reserved-words:reserved word:compadd -k reswords'
Index: Completion/Zsh/Type/_parameters
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_parameters,v
retrieving revision 1.1
diff -u -r1.1 _parameters
--- Completion/Zsh/Type/_parameters	2 Apr 2001 11:20:15 -0000	1.1
+++ Completion/Zsh/Type/_parameters	1 Mar 2011 20:28:22 -0000
@@ -6,7 +6,7 @@
 # If you specify a -g option with a pattern, the pattern will be used to
 # restrict the type of parameters matched.
 
-local expl pattern fakes faked tmp
+local expl pattern fakes faked tmp hide pfilt
 
 pattern=(-g \*)
 zparseopts -D -K -E g:=pattern
@@ -23,8 +23,18 @@
   done
 fi
 
+zstyle -s ":completion:${curcontext}:parameters" hide-internal hide
+case "${hide:-never}" in
+  no|false|never)
+    pfilt='';;
+  yes|true|always)
+    pfilt='[^_.]';;
+  auto|dtrt)
+    [[ $PREFIX = [_.]* ]] && pfilt='' || pfilt='[^_.]';;
+esac
+
 _wanted parameters expl parameter \
     compadd "$@" -Q - \
-        "${(@k)parameters[(R)${pattern[2]}~*local*]}" \
+        "${(@M)${(@k)parameters[(R)${pattern[2]}~*local*]}:#${~pfilt}*}" \
         "$fakes[@]" \
         "${(@)${(@M)faked:#${~pattern[2]}}%%:*}"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.232
diff -u -r1.232 compsys.yo
--- Doc/Zsh/compsys.yo	17 Dec 2010 17:10:48 -0000	1.232
+++ Doc/Zsh/compsys.yo	1 Mar 2011 20:28:22 -0000
@@ -1658,6 +1658,14 @@
 completions at all, the tt(tag-order) style can be modified as described
 below.
 )
+kindex(hide-internal, completion style)
+item(tt(hide-internal))(
+This style is applicable to the tt(functions) and tt(parameters) completion
+tags.  If tt(true), never complete internal names (i.e. those whose names
+begin with '_' or '.').  If tt(false) (the default) then always complete
+internal names.  If tt(auto), then only complete internal names when the
+leading character is explicitly matched.
+)
 kindex(hosts, completion style)
 item(tt(hosts))(
 A list of names of hosts that should be completed.  If this is not set,

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Peter Stephenson]

On Tue, 01 Mar 2011 15:39:55 -0500
Greg Klanderman <gak@klanderman.net> wrote:
> >>>>> On May 28, 2009 Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> > On Wed, May 27, 2009 at 21:12, Greg Klanderman <gak@klanderman.net> wrote:
> >> But in the same vein, what I really want is a way to configure the
> >> behavior for functions, variables, etc. beginning with "_" to be like
> >> filenames beginning with ".": completion should work if I have
> >> explicitly typed the leading "_", but even substring matching should
> >> not *generate* a leading "_".
> 
> > I think this is a good explanation of what, imo, the final goal should be.
> 
> What do you guys think of the patch below?  I'm open to better names
> for the zstyle.. I've tested it a fair amount locally.

Looks good to me.

I think you missed the following case...

Index: Completion/Zsh/Type/_functions
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_functions,v
retrieving revision 1.3
diff -p -u -r1.3 _functions
--- Completion/Zsh/Type/_functions	8 Jun 2005 12:45:36 -0000	1.3
+++ Completion/Zsh/Type/_functions	1 Mar 2011 21:10:13 -0000
@@ -1,5 +1,15 @@
 #compdef unfunction
 
-local expl
+local expl hide ffilt
 
-_wanted functions expl 'shell function' compadd -k "$@" - functions
+zstyle -s ":completion:${curcontext}:functions" hide-internal hide
+case "${hide:-never}" in
+  no|false|never)
+    ffilt='';;
+  yes|true|always)
+    ffilt='[(I)[^_.]*]';;
+  auto|dtrt)
+    [[ $PREFIX = [_.]* ]] && ffilt='' || ffilt='[(I)[^_.]*]';;
+esac
+
+_wanted functions expl 'shell function' compadd -k "$@" - "functions$ffilt"

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 1, 2011 Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:

> Looks good to me.

> I think you missed the following case...

Yes, thank you Peter!  That's actually where I started, before
figuring out that a function used in command position doesn't actually
use that completer, then forgot to go take care of that one after
getting the case I really wanted working..

Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Oliver Kiddle]

Greg Klanderman wrote:
> 
> >>>>> On May 28, 2009 Richard Hartmann <richih.mailinglist@gmail.com> wrote:
> > On Wed, May 27, 2009 at 21:12, Greg Klanderman <gak@klanderman.net> wrote:
> >> But in the same vein, what I really want is a way to configure the
> >> behavior for functions, variables, etc. beginning with "_" to be like
> >> filenames beginning with ".": completion should work if I have
> >> explicitly typed the leading "_", but even substring matching should
> >> not *generate* a leading "_".

Does the ignored completer not do this for you?

I have:
zstyle ':completion::(^approximate*):*:functions' ignored-patterns '_*'

Your hide-internal style is very similar to prefix-needed. The intention
with zstyle in the past was to overload styles where reasonably possible
and rely on the contexts for disambiguation.

Oliver

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Richard Hartmann]

On Tue, Mar 1, 2011 at 21:39, Greg Klanderman <gak@klanderman.net> wrote:
>
> Following up to
>   http://www.zsh.org/mla/workers/2009/msg00793.html
> from almost two years ago:

Nice. Thanks :)


> What do you guys think of the patch below?  I'm open to better names
> for the zstyle.. I've tested it a fair amount locally.

Looks good to me (Peter's patch applied).


Richard

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 1, 2011 Oliver Kiddle <okiddle@yahoo.co.uk> wrote:

> Does the ignored completer not do this for you?

> I have:
> zstyle ':completion::(^approximate*):*:functions' ignored-patterns '_*'

Hi Oliver,

I already answered that question 2 years ago:  :-)

http://www.zsh.org/mla/workers/2009/msg00797.html

> Your hide-internal style is very similar to prefix-needed.

Sorry, I hadn't seen that.. if people agree, I can use the
prefix-needed style instead; the issues I see with that are:

1. Prefix-needed is defined as defaulting to true, but to preserve
   current behavior for functions/parameters, the default would have
   to be false.  How bad would it be to have different defaults for
   different uses of prefix-needed?  Alternatively, how bad would it
   be to change the current default behavior for function/parameter
   completion?

2. At present prefix-needed is boolean valued, whereas my
   hide-internal is ternary valued.  I suppose my true value is not
   really necessary, so I'd just map hide-internal=auto to
   prefix-needed=true.

Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Bart Schaefer]

On Mar 2,  1:49pm, Greg Klanderman wrote:
} Subject: Re: PATCH: zstyle to control completion of functions/parameters b
}
} >>>>> On March 1, 2011 Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
} > Your hide-internal style is very similar to prefix-needed.
} 
} Sorry, I hadn't seen that.. if people agree, I can use the
} prefix-needed style instead; the issues I see with that are:
} 
} 1. Prefix-needed is defined as defaulting to true, but to preserve
}    current behavior for functions/parameters, the default would have
}    to be false.

How about if prefix-needed becomes a ternary, with default "auto" where
the behavior of "auto" is defined to mean "false" in the new contexts
where you are applying it and "true" in all the contexts where it now
applies?

(This may be a silly suggestion, I haven't carefully worked out all
the interactions or how much code would need to be touched.)

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

> How about if prefix-needed becomes a ternary, with default "auto" where
> the behavior of "auto" is defined to mean "false" in the new contexts
> where you are applying it and "true" in all the contexts where it now
> applies?

I'm not sure that's any different from documenting that the default
depends on the context (which you have to do either way), you're just
naming that behavior.

Easiest is to just use 'zstyle -t' in the new use cases and leave the
'zstyle -T' as-is in the existing twelve uses.

If you like 'auto', then it's not much more effort to add all the true
strings plus 'auto' to the existing 'zstyle -T' calls.  The new uses
would remain 'zstyle -t' as 'auto' and unset mean false in this
context.

Somebody make a choice and I'll do it..

Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

Here's a new patch for the easier option (without 'auto').
Let me know what you think..

cheers,
Greg



Index: Completion/Zsh/Type/_functions
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_functions,v
retrieving revision 1.3
diff -u -r1.3 _functions
--- Completion/Zsh/Type/_functions	8 Jun 2005 12:45:36 -0000	1.3
+++ Completion/Zsh/Type/_functions	3 Mar 2011 16:08:17 -0000
@@ -1,5 +1,9 @@
 #compdef unfunction
 
-local expl
+local expl ffilt
 
-_wanted functions expl 'shell function' compadd -k "$@" - functions
+zstyle -t ":completion:${curcontext}:functions" prefix-needed && \
+ [[ $PREFIX != [_.]* ]] && \
+ ffilt='[(I)[^_.]*]'
+
+_wanted functions expl 'shell function' compadd -k "$@" - "functions$ffilt"
Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.9
diff -u -r1.9 _command_names
--- Completion/Zsh/Type/_command_names	19 Aug 2007 23:31:31 -0000	1.9
+++ Completion/Zsh/Type/_command_names	3 Mar 2011 16:08:17 -0000
@@ -4,10 +4,14 @@
 # complete only external commands and executable files. This and a
 # `-' as the first argument is then removed from the arguments.
 
-local args defs
+local args defs ffilt
 
 zstyle -t ":completion:${curcontext}:commands" rehash && rehash
 
+zstyle -t ":completion:${curcontext}:functions" prefix-needed && \
+ [[ $PREFIX != [_.]* ]] && \
+ ffilt='[(I)[^_.]*]'
+
 defs=(
   'commands:external command:_path_commands'
 )
@@ -24,7 +28,7 @@
 
   defs=( "$defs[@]"
     'builtins:builtin command:compadd -k builtins'
-    'functions:shell function:compadd -k functions'
+    "functions:shell function:compadd -k functions$ffilt"
     'aliases:alias:compadd -k aliases'
     'suffix-aliases:suffix alias:_suffix_alias_files'
     'reserved-words:reserved word:compadd -k reswords'
Index: Completion/Zsh/Type/_parameters
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_parameters,v
retrieving revision 1.1
diff -u -r1.1 _parameters
--- Completion/Zsh/Type/_parameters	2 Apr 2001 11:20:15 -0000	1.1
+++ Completion/Zsh/Type/_parameters	3 Mar 2011 16:08:17 -0000
@@ -6,7 +6,7 @@
 # If you specify a -g option with a pattern, the pattern will be used to
 # restrict the type of parameters matched.
 
-local expl pattern fakes faked tmp
+local expl pattern fakes faked tmp pfilt
 
 pattern=(-g \*)
 zparseopts -D -K -E g:=pattern
@@ -23,8 +23,12 @@
   done
 fi
 
+zstyle -t ":completion:${curcontext}:parameters" prefix-needed && \
+ [[ $PREFIX != [_.]* ]] && \
+ pfilt='[^_.]'
+
 _wanted parameters expl parameter \
     compadd "$@" -Q - \
-        "${(@k)parameters[(R)${pattern[2]}~*local*]}" \
+        "${(@M)${(@k)parameters[(R)${pattern[2]}~*local*]}:#${~pfilt}*}" \
         "$fakes[@]" \
         "${(@)${(@M)faked:#${~pattern[2]}}%%:*}"
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.232
diff -u -r1.232 compsys.yo
--- Doc/Zsh/compsys.yo	17 Dec 2010 17:10:48 -0000	1.232
+++ Doc/Zsh/compsys.yo	3 Mar 2011 16:08:17 -0000
@@ -2298,13 +2298,29 @@
 )
 kindex(prefix-needed, completion style)
 item(tt(prefix-needed))(
-This, too, is used for matches with a common prefix.  If it is set to
-`true' this common prefix must be typed by the user to generate the
-matches.  In the case of command options, this means that the initial
-`tt(-)', `tt(+)', or `tt(-)tt(-)' must be typed explicitly before option
-names will be completed.
+This style is also relevant for matches with a common prefix.  If it is
+set to `true' this common prefix must be typed by the user to generate
+the matches.
 
-The default value for this style is `true'.
+The style is applicable to the tt(options), tt(signals), tt(jobs),
+tt(functions), and tt(parameters) completion tags.
+
+For command options, this means that the initial `tt(-)', `tt(+)', or
+`tt(-)tt(-)' must be typed explicitly before option names will be
+completed.
+
+For signals, an initial `tt(-)' is required before signal names will
+be completed.
+
+For jobs, an initial `tt(%)' is required before job names will be
+completed.
+
+For function and parameter names, an initial `tt(_)' or `tt(.)' is
+required before function or parameter names starting with those
+characters will be completed.
+
+The default value for this style is `false' for tt(function) and
+tt(parameter) completions, and  `true' otherwise.
 )
 kindex(preserve-prefix, completion style)
 item(tt(preserve-prefix))(

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Bart Schaefer]

On Mar 3, 10:33am, Greg Klanderman wrote:
} Subject: Re: PATCH: zstyle to control completion of functions/parameters b
} 
} Easiest is to just use 'zstyle -t' in the new use cases and leave the
} 'zstyle -T' as-is in the existing twelve uses.

That's probably fine.  I was just trying to avoid the situation where
the doc has to keep track of which cases default to true and which ones
default to false.  That is, there seem to be three choices from the
doc point of view:

(1) Explicitly list where it defaults to true and where false.
(2) Stop claiming there's any default at all, and say that when it
is not set, every context chooses the most-commonly-wanted behavior
for that context.  (Or the behavior that produces the smallest set
of matches, or whatever it is.)
(3) Give a name to "context chooses" and say that's the default.

The other advantage of (3) is that you can say things like

zstyle ':completion:*:foo:*' prefix-needed true
zstyle ':completion:*:foo:bar' prefix-needed auto

whereas if the only way to get "auto" is to leave the style unset,
you can't have the specific case differ from the wildcard case.  But
I don't know if there would ever be a need for that ... so I guess go
with (2) as easier, because (3) can always be done later.

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Oliver Kiddle]

Greg Klanderman wrote:
> 
> Easiest is to just use 'zstyle -t' in the new use cases and leave the
> 'zstyle -T' as-is in the existing twelve uses.

That seems sensible to me. I suspect there are other styles that have
different defaults in different contexts.

Oliver

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 3, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> (1) Explicitly list where it defaults to true and where false.
> (2) Stop claiming there's any default at all, and say that when it
> is not set, every context chooses the most-commonly-wanted behavior
> for that context.  (Or the behavior that produces the smallest set
> of matches, or whatever it is.)
> (3) Give a name to "context chooses" and say that's the default.

[...]

> so I guess go with (2) as easier, because (3) can always be done later.

Hi Bart, was my revised patch from Thursday morning OK, or would you
like it to be vaguer w.r.t. the default behavior?

thanks,
Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Bart Schaefer]

On Mar 6,  3:07pm, Greg Klanderman wrote:
}
} Hi Bart, was my revised patch from Thursday morning OK, or would you
} like it to be vaguer w.r.t. the default behavior?

It's fine.

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 6, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> It's fine.

Thanks Bart.. can somebody commit it, pretty please!  :-)

thanks,
Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 6, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> It's fine.

Well, maybe not :-(

I've noticed some bugginess with this:

| zsh -f
| phl% autoload -U compinit
| phl% compinit -u
| phl% function foobar () { echo foobar }

OK, now hit <tab> to complete after 'foobar':
| phl% foobar<tab>
and it adds a space.

now,
| phl% zstyle ':completion:*' prefix-needed true
and try completing 'foobar' again:
| phl% foobar<tab>
and it just beeps.

If I change _command_names to instead declare a local 'funcnames' and
change the prefix-needed logic to:

| if zstyle -t ":completion:${curcontext}:functions" prefix-needed && \
|    [[ $PREFIX != [_.]* ]] ; then
|   funcnames=(${(k)functions[(I)[^_.]*]})
| else
|   funcnames=(${(k)functions})
| fi

and change the compadd in defs for functions to 'compadd -a funcnames',
then it works fine.

Completion of 'foobar' after 'unfunction' (i.e. using the equivalent
change made to _functions) however works fine.

So it seems like compadd's handling of the -k with subscript is not
always working properly.

My parameter completion change seems to be unaffected; which makes
sense since it's directly adding the completions to the compadd
invocation.

thanks,
Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Bart Schaefer]

On Mar 9,  1:41pm, Greg Klanderman wrote:
} Subject: Re: PATCH: zstyle to control completion of functions/parameters b
}
} | zsh -f
} | phl% autoload -U compinit
} | phl% compinit -u
} | phl% function foobar () { echo foobar }
} 
} | phl% zstyle ':completion:*' prefix-needed true
} and try completing 'foobar' again:
} | phl% foobar<tab>
} and it just beeps.
} 
} So it seems like compadd's handling of the -k with subscript is not
} always working properly.

Try this ... if it works, produce a patch for the others and I'll get
it committed:

--- _command_names.~1.10.~	2011-03-08 08:03:02.000000000 -0800
+++ _command_names	2011-03-10 07:53:32.000000000 -0800
@@ -28,7 +28,7 @@
 
   defs=( "$defs[@]"
     'builtins:builtin command:compadd -k builtins'
-    "functions:shell function:compadd -k functions$ffilt"
+    "functions:shell function:compadd -k functions${(q)ffilt}"
     'aliases:alias:compadd -k aliases'
     'suffix-aliases:suffix alias:_suffix_alias_files'
     'reserved-words:reserved word:compadd -k reswords'


-- 

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Try this ... if it works,

It does, as does

+    "functions:shell function:compadd -k 'functions$ffilt'}"

which I like a little better.

> produce a patch for the others

_parameters doesn't need it, as it is directly producing the matches
as arguments to compadd.

_functions seems to be working, it is using _wanted which is passing
the arguments to compadd separately.

I really wonder if this shouldn't be considered a quoting bug
somewhere between _alternative and the actual call to compadd?

Hmm, maybe the line:

        eval "action=( $action )"

in _alternative?  Maybe it should be

        eval "action=( "${=action}" )"

(haven't actually tested that)?

Or is it intentional that _alternatives, because it is taking a list
of compadd arguments as a single string, must necessarily have proper
quoting applied?  I.e. we actually want the full eval semantics?

Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Bart Schaefer]

On Mar 10, 11:44am, Greg Klanderman wrote:
}
} Or is it intentional that _alternatives, because it is taking a list
} of compadd arguments as a single string, must necessarily have proper
} quoting applied?  I.e. we actually want the full eval semantics?

Unfortunately, I don't know the answer to that.  You'd have to scan
through the completion suite looking for uses of _alternatives ...

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Unfortunately, I don't know the answer to that.

yeah, it was a somewhat rhetorical question..

> You'd have to scan
> through the completion suite looking for uses of _alternatives ...

no thanks :-)  I'll send you a patch for just _commend_names;
do you prefer single quotes or ${(q)ffilt}?

Greg

Re: PATCH: zstyle to control completion of functions/parameters beginning with underscore

[Greg Klanderman]

>>>>> On March 10, 2011 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Try this ... if it works, produce a patch for the others and I'll get
> it committed:

As discussed, the others are OK as-is; here's an alternate patch for
the one problematic case.

thanks,
Greg


Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.10
diff -u -r1.10 _command_names
--- Completion/Zsh/Type/_command_names	8 Mar 2011 16:08:37 -0000	1.10
+++ Completion/Zsh/Type/_command_names	11 Mar 2011 16:58:12 -0000
@@ -28,7 +28,7 @@
 
   defs=( "$defs[@]"
     'builtins:builtin command:compadd -k builtins'
-    "functions:shell function:compadd -k functions$ffilt"
+    "functions:shell function:compadd -k 'functions$ffilt'"
     'aliases:alias:compadd -k aliases'
     'suffix-aliases:suffix alias:_suffix_alias_files'
     'reserved-words:reserved word:compadd -k reswords'