ignored-patterns giving correction a go

ignored-patterns giving correction a go

[Oliver Kiddle]

I added the following to by .zshrc after seeing it in Peter's Zsh Guide
as an example:

zstyle ':completion:*:functions' ignored-patterns '_*'

This is often very useful because I don't get functions beginning with
underscores until I've actually typed the underscore. The trouble is
that the correction completer gets to have a go before completion is
tried without the ignored-patterns so for e.g which _co<tab> offers me
corrections such as co. Is there any way around this?

Oliver

Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 21,  5:10pm, Sven Wischnowsky wrote:
> } Subject: Re: ignored-patterns giving correction a go
> }
> } > }   zstyle ... tag-order --foo=files --bar=files
> } > }   zstyle '*-foo' ignored-patterns '*.ps'
> } > 
> } > Tags right now are pretty much predetermined by the completion functions
> } > that use them, e.g. the way _files uses globbed-files.  Hmm ... is that
> } > changed by what you're working on now?
> } 
> } Yes, and that's what the original example above was about -- the
> } `user' `invented' the tag names `foo' and `bar', linking them to the
> } `method' `files'. And before that I made the suggestion to allow the
> } file-patterns style to contain invented tag names.
> 
> So where do the method names come from?  I don't think we want this to
> be so configurable that, for example, the file-patterns style could be
> caused to generate parameter names.  Do we?

Should be answered by the message I just sent...

> } > 		    shift "i > $# ? $# : i"  # Stupid shift error on i > $#
> } 
> } Yes! It's annoying, isn't it? I was tempted more than one to change it.
> 
> Bash gives the same error.  Sigh.

So does ksh (`shift: bad number'). Damn. Does that make `argv=( $argv[2,-1] )'
more efficient in some cases? (Assignments are one of those things
that get optimised by the execution code, avoiding the call to
execpline*() and execcmd().)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: ignored-patterns giving correction a go

[Bart Schaefer]

On Mar 21,  5:10pm, Sven Wischnowsky wrote:
} Subject: Re: ignored-patterns giving correction a go
}
} > }   zstyle ... tag-order --foo=files --bar=files
} > }   zstyle '*-foo' ignored-patterns '*.ps'
} > 
} > Tags right now are pretty much predetermined by the completion functions
} > that use them, e.g. the way _files uses globbed-files.  Hmm ... is that
} > changed by what you're working on now?
} 
} Yes, and that's what the original example above was about -- the
} `user' `invented' the tag names `foo' and `bar', linking them to the
} `method' `files'. And before that I made the suggestion to allow the
} file-patterns style to contain invented tag names.

So where do the method names come from?  I don't think we want this to
be so configurable that, for example, the file-patterns style could be
caused to generate parameter names.  Do we?
 
} > 		    shift "i > $# ? $# : i"  # Stupid shift error on i > $#
} 
} Yes! It's annoying, isn't it? I was tempted more than one to change it.

Bash gives the same error.  Sigh.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Bart Schaefer wrote:

> On Mar 21, 11:00am, Sven Wischnowsky wrote:
> } Subject: Re: ignored-patterns giving correction a go
> }
> } Bart Schaefer wrote:
> } 
> } > }   zstyle ... tag-order foo=files bar=files
> } > }   zstyle '...:foo' file-patterns '*.ps'
> } > 
> } > Presumably the '...' part in both of those lines is, in many cases,
> } > going to be the same.  And then you need to repeat it _again_ to give
> } > the patterns for `bar'.
> } 
> } Just occured to me: people don't need to repeat the patterns, of
> } course, as long as they use their own little naming convention for the 
> } tags they invent:
> } 
> }   zstyle ... tag-order --foo=files --bar=files
> }   zstyle '*-foo' ignored-patterns '*.ps'
> 
> But people arent' going to invent their own tags all that often, are they?
> Tags right now are pretty much predetermined by the completion functions
> that use them, e.g. the way _files uses globbed-files.  Hmm ... is that
> changed by what you're working on now?

Yes, and that's what the original example above was about -- the
`user' `invented' the tag names `foo' and `bar', linking them to the
`method' `files'. And before that I made the suggestion to allow the
file-patterns style to contain invented tag names.

> } > I find myself wishing for some way to merge
> } > them, maybe something like
> } > 
> } >     zstyle ... tag-order foo=files bar=files \
> } > 	    + foo file-patterns '*.ps' \
> } > 	    + bar file-patterns '*.pdf'
> } > 
> } > That specific example would make the word `+' magic, which might not be
> } > a good idea ... but we're running out of metacharacters that don't need
> } > to be annoyingly quoted.
> 
> Speaking of "just occured to me":
> 
>     function zstyle() {

I had played with the idea to first try it with a function, too ;-)

> ...
> 		    shift "i > $# ? $# : i"  # Stupid shift error on i > $#

Yes! It's annoying, isn't it? I was tempted more than one to change
it. Or maybe add an option to make it be quiet... unfortunately `shift -q' 
has always been interpreted as `shift -$q'. Sigh.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: ignored-patterns giving correction a go

[Bart Schaefer]

On Mar 21, 11:00am, Sven Wischnowsky wrote:
} Subject: Re: ignored-patterns giving correction a go
}
} Bart Schaefer wrote:
} 
} > }   zstyle ... tag-order foo=files bar=files
} > }   zstyle '...:foo' file-patterns '*.ps'
} > 
} > Presumably the '...' part in both of those lines is, in many cases,
} > going to be the same.  And then you need to repeat it _again_ to give
} > the patterns for `bar'.
} 
} Just occured to me: people don't need to repeat the patterns, of
} course, as long as they use their own little naming convention for the 
} tags they invent:
} 
}   zstyle ... tag-order --foo=files --bar=files
}   zstyle '*-foo' ignored-patterns '*.ps'

But people arent' going to invent their own tags all that often, are they?
Tags right now are pretty much predetermined by the completion functions
that use them, e.g. the way _files uses globbed-files.  Hmm ... is that
changed by what you're working on now?

} > I find myself wishing for some way to merge
} > them, maybe something like
} > 
} >     zstyle ... tag-order foo=files bar=files \
} > 	    + foo file-patterns '*.ps' \
} > 	    + bar file-patterns '*.pdf'
} > 
} > That specific example would make the word `+' magic, which might not be
} > a good idea ... but we're running out of metacharacters that don't need
} > to be annoyingly quoted.

Speaking of "just occured to me":

    function zstyle() {
	case "$1" in
	-*) builtin zstyle "$@";;
	*)  setopt localoptions noksharrays
	    integer i
	    local style="$1"
	    1=''
	    for ((i=2; $#; ++i))
	    do
		if [[ $i -gt $# || "$argv[i]" == '+' ]]
		then
		    builtin zstyle "$style${(@)argv[1,i-1]}"
		    shift "i > $# ? $# : i"  # Stupid shift error on i > $#
		    i=1
		fi
	    done;;
	esac
    }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> The only issue I have with this is that it increases the number of
> similar zstyle commands one must give to configure a behavior.  Here's
> your example from 10134:
> 
> }   zstyle ... tag-order foo=files bar=files
> }   zstyle '...:foo' file-patterns '*.ps'
> 
> Presumably the '...' part in both of those lines is, in many cases,
> going to be the same.  And then you need to repeat it _again_ to give
> the patterns for `bar'.  I find myself wishing for some way to merge
> them, maybe something like
> 
>     zstyle ... tag-order foo=files bar=files \
> 	    + foo file-patterns '*.ps' \
> 	    + bar file-patterns '*.pdf'
> 
> That specific example would make the word `+' magic, which might not be
> a good idea ... but we're running out of metacharacters that don't need
> to be annoyingly quoted.

Just occured to me: people don't need to repeat the patterns, of
course, as long as they use their own little naming convention for the 
tags they invent:

  zstyle ... tag-order --foo=files --bar=files
  zstyle '*-foo' ignored-patterns '*.ps'

Or maybe ':completion:*:-foo' or something like that. Onewould only
have to make sure that either

- these tag names are not used more than once,
- or (better) they are used consistently wherever one wants the
  behaviour configured for the tag (avoiding multiple tags with the
  same styles set for them)

Anyway, I'll first get the other stuff done and then we can discuss
(and play with) ways to make the style setup easier.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: ignored-patterns giving correction a go

[Bart Schaefer]

On Mar 17, 10:05am, Sven Wischnowsky wrote:
} Subject: Re: ignored-patterns giving correction a go
}
} I use something like:
} 
}   zstyle :completion::::: completer _next_tags _expand _complete \
}                                     _complete _match _correct \
}                                     _approximate _prefix

BTW, there's no doc for _next_tags ... what happens if you invoke it as
a widget but it's NOT in your completer list?

}   zstyle ':completion:*:complete-2:*' prefer-ignored yes
}   zstyle ':completion:*:(correct|approximate|prefix)-1:*' prefer-ignored yes

Obviously the documentation for using a completer twice doesn't belong
just under the matcher-list spec any more.

} All this alternate-set stuff looks like a hack. [...] The problem is
} that if we remove the alternate set stuff for new completion, we'll
} have trouble re-implementing the behaviour of $fignore, at least when
} we want it to have the exact same effect.

The tricky bit is really the fail-over behavior, isn't it?  That is,
the way the alternate set is automatically used if the "real" set is
empty?

So what if we just made the alternate set a group of its own, on the
same level as the -default- group, e.g. -alternate-.  Change the -a
option of compadd to require an argument, `-a alternate-group-name',
that, when used with `-[JV] group-name' and `-F array' names the group
into which the completions matching the -F patterns are placed; the
sorting of that group is the same as for the -[JV], -[12] apply, etc.
When no -a is given the -alternate- group is used by -F, and when -a
is given with no -[JV], the completions that don't match the -F pattern
go into -default-.

(I'd almost rather pick a different option that -a and eliminate -a
entirely, to break noisily any completion functions that now use -a
without an argument; but -A is already taken, as are most of the other
sensible letters.)

Then make the default completion behavior be as if the tag-order were
the array (-default- -alternate-).  If in any context the tag-order
style is overridden, the user must explicitly name -alternate- (or any
group passed with -a by other completion functions) to have it used.
Document this, of course.

For the special case of fignore, _files and _path_files can use -a
to name multiple alternate group names, and play with the default
tag-order the way _files already does for globbed-files directories
all-files.  Does that sound like it'll (1) work and (2) be less of a
hack than the present behavior?

An advantage is that you can cause alternates from several groups to
accumulate all in the same place, so for _files you might have the
groups globbed-files directories all-ignored-files all-files, where
all-ignored-files includes both files and paths that matched $fignore.
Not that this is how I'm suggesting it work, I'm just using it by way
of example.

One problem is that I don't see how you can eliminate the current
alternate-set support from the C code and still have fignore work for
old compctl, but maybe you have an idea for going about that.  Or
maybe that code would just go unused in the new system.

(What happens right now if you call
	compadd -V group ...
and later
	compadd -J group ...
that is, specify some sorted and some unsorted matches for the same
group?)

(What's the point of setting groups[2] inside the _tags loop in _files?
it doesn't appear to get used anywhere after line 19 where it's copied
into the opts array.)

} Some more about 10134: after having thought about it some more, I
} begin to like the suggestion with `tag-order tag=method ...' with the
} shortcut `tag-order foo'.

The only issue I have with this is that it increases the number of
similar zstyle commands one must give to configure a behavior.  Here's
your example from 10134:

}   zstyle ... tag-order foo=files bar=files
}   zstyle '...:foo' file-patterns '*.ps'

Presumably the '...' part in both of those lines is, in many cases,
going to be the same.  And then you need to repeat it _again_ to give
the patterns for `bar'.  I find myself wishing for some way to merge
them, maybe something like

    zstyle ... tag-order foo=files bar=files \
	    + foo file-patterns '*.ps' \
	    + bar file-patterns '*.pdf'

That specific example would make the word `+' magic, which might not be
a good idea ... but we're running out of metacharacters that don't need
to be annoyingly quoted.

I was going to try to reply in some detail to 10134, but I'm out of time
and (other than preferring the tag=method form to having yet _another_
set of styles to name method-tags) it's probably better if Sven just
tries things out and reports how well he thinks they work.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: ignored-patterns giving correction a go

[Sven Wischnowsky]

Oliver Kiddle wrote:

> I added the following to by .zshrc after seeing it in Peter's Zsh Guide
> as an example:
> 
> zstyle ':completion:*:functions' ignored-patterns '_*'
> 
> This is often very useful because I don't get functions beginning with
> underscores until I've actually typed the underscore. The trouble is
> that the correction completer gets to have a go before completion is
> tried without the ignored-patterns so for e.g which _co<tab> offers me
> corrections such as co. Is there any way around this?

See 9865.

I use something like:

  zstyle :completion::::: completer _next_tags _expand _complete \
                                    _complete _match _correct \
                                    _approximate _prefix
  zstyle ':completion:*:complete-2:*' prefer-ignored yes
  zstyle ':completion:*:(correct|approximate|prefix)-1:*' prefer-ignored yes

(Simpler setups can obviously be thought of ;-)

All this alternate-set stuff looks like a hack. Initially it was
invented for $fignore with compctl, but I really, really think we
could do it better now with the completion system. And we should do it 
better, I think, it probably the most important part of 10134, for me
at least. The problem is that if we remove the alternate set stuff for 
new completion, we'll have trouble re-implementing the behaviour of
$fignore, at least when we want it to have the exact same effect.

Some more about 10134: after having thought about it some more, I
begin to like the suggestion with `tag-order tag=method ...' with the
shortcut `tag-order foo'. If I'm not completely mistaken, it would
allow us to change the internals, allow much better control and still
don't invalidate anyone's setup. I think I'll play a bit with this at
the weekend.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de