zsh-users
 help / color / mirror / code / Atom feed
* problem with context specification
@ 2020-01-13 16:46 ` Pier Paolo Grassi
  2020-01-13 16:56   ` Peter Stephenson
  2020-01-13 17:06   ` Daniel Shahaf
  0 siblings, 2 replies; 13+ messages in thread
From: Pier Paolo Grassi @ 2020-01-13 16:46 UTC (permalink / raw)
  To: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Hello, I am trying to define a style for a completion command different
from the more general style, but I am failing to override the style for
this specific command.

I have this declaration:

zstyle ':completion:*' matcher-list 'm:{a-z}={A-Za-z}' 'm:{a-z}={A-Za-z}
r:|[._-]=* r:|=*' 'm:{a-z}={A-Za-z} l:|=* r:|=*'

that is how I would like general completion to work in regard to he
matcher-list style

For the episodes command I would like to override this style, and set it to:

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

but this doesn't seem to match when i try completion pressing tab after the
episodes command.

if I substitute this as the general case, eg:

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

then everything get this style, so the syntax is correct. it seem that what
is wrong is the pattern.
I tried some variations of it, with no success:

  zstyle ':completion:*:*:episodes:*' ...
  zstyle ':completion:*:episodes:*' ...

my main problem is that I don't really understand the pattern syntax, and
haven't been able to find a man page detailing it (the documentation on the
zstyle builtin doesn't explain it), so I basically try random variations.
Using ctrl-x h after episodes on the command line it gives:

tags in context :completion::complete:episodes::
    argument-rest  (_arguments _episodes)

so I've tried:
  zstyle ' :completion::complete:episodes::'

but still to no effect, and also the lack of * seems a little suspicious

any help on this is appreciated, thanks

Pier Paolo Grassi
linkedin: https://www.linkedin.com/in/pier-paolo-grassi-19300217
founder: https://www.meetup.com/it-IT/Machine-Learning-TO

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 16:46 ` problem with context specification Pier Paolo Grassi
@ 2020-01-13 16:56   ` Peter Stephenson
  2020-01-13 17:46     ` Mikael Magnusson
  2020-01-13 17:53     ` Bart Schaefer
  2020-01-13 17:06   ` Daniel Shahaf
  1 sibling, 2 replies; 13+ messages in thread
From: Peter Stephenson @ 2020-01-13 16:56 UTC (permalink / raw)
  To: zsh-users

On Mon, 2020-01-13 at 17:46 +0100, Pier Paolo Grassi wrote:
> For the episodes command I would like to override this style, and set it to:
> 
> zstyle ':completion:*:*:episodes:*:*' matcher-list 'm:{a-z}={A-Za-z} l:|=*
> r:|=*'
> 
> but this doesn't seem to match when i try completion pressing tab after the
> episodes command.

I've a feeling matcher-list is only run in a very general context, so
updating per command doesn't work, and you need to use the matcher style
for more specific cases.  However, I may not be remembering the two
styles where this applies correctly, and the documentation doesn't
explicitly say where the two work and don't work.

pws




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 16:46 ` problem with context specification Pier Paolo Grassi
  2020-01-13 16:56   ` Peter Stephenson
@ 2020-01-13 17:06   ` Daniel Shahaf
  2020-01-13 17:41     ` [PATCH] docs: Add an example of setting and querying zstyles (was: Re: problem with context specification) Daniel Shahaf
  2020-01-14 15:59     ` problem with context specification Pier Paolo Grassi
  1 sibling, 2 replies; 13+ messages in thread
From: Daniel Shahaf @ 2020-01-13 17:06 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

Pier Paolo Grassi wrote on Mon, Jan 13, 2020 at 17:46:09 +0100:
> if I substitute this as the general case, eg:
> 
>   zstyle ':completion:*' matcher-list 'm:{a-z}={A-Za-z} l:|=* r:|=*'
> 
> then everything get this style, so the syntax is correct. it seem that what
> is wrong is the pattern.
> I tried some variations of it, with no success:
> 
>   zstyle ':completion:*:*:episodes:*' ...
>   zstyle ':completion:*:episodes:*' ...
> 
> my main problem is that I don't really understand the pattern syntax, and
> haven't been able to find a man page detailing it (the documentation on the
> zstyle builtin doesn't explain it), so I basically try random variations.

The documentation does explain it; quote:

              For ordering of comparisons, patterns are searched from most
              specific to least specific, and patterns that are equally
              specific keep the order in which they were defined.  A pattern
              is considered to be more specific than another if it contains
              more components (substrings separated by colons) or if the
              patterns for the components are more specific, where simple
              strings are considered to be more specific than patterns and
              complex patterns are considered to be more specific than the
              pattern `*'.

The upshot of this is that each of the patterns ':completion:*:*:episodes:*'
and ':completion:*:episodes:*' is considered to be more specific than
':completion:*'.  A style set under either of the former would have precedence
over a style set under the latter, _as far as zstyle is concerned_.  (See
pws's answer for the caveat.)

> Using ctrl-x h after episodes on the command line it gives:
> 
> tags in context :completion::complete:episodes::
>     argument-rest  (_arguments _episodes)
> 
> so I've tried:
>   zstyle ' :completion::complete:episodes::'
> 
> but still to no effect, and also the lack of * seems a little suspicious

No, the lack of stars is expected.  What you put in zshrc is patterns; the
completion system then looks up specific strings that the patterns are matched
against.  The settings attached to the most specific pattern that matches are
used.

Minimal example:

zshrc contains:

% zstyle ':foo:bar' lorem yes
% zstyle ':foo:*'   lorem no

Then the foo subsystem might run, for example:

% zstyle -t :foo:bar lorem && pwd
/home/daniel
% zstyle -t :foo:baz lorem && pwd
% 

I take it the documentation of zstyle didn't make this clear, so could you
suggest how to improve it?

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] docs: Add an example of setting and querying zstyles (was: Re: problem with context specification)
  2020-01-13 17:06   ` Daniel Shahaf
@ 2020-01-13 17:41     ` Daniel Shahaf
  2020-01-14 15:59     ` problem with context specification Pier Paolo Grassi
  1 sibling, 0 replies; 13+ messages in thread
From: Daniel Shahaf @ 2020-01-13 17:41 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

diff --git a/Doc/Zsh/mod_zutil.yo b/Doc/Zsh/mod_zutil.yo
index 1e35d2245..e556e2b37 100644
--- a/Doc/Zsh/mod_zutil.yo
+++ b/Doc/Zsh/mod_zutil.yo
@@ -17,18 +17,37 @@ item(tt(zstyle -m) var(context) var(style) var(pattern))(
 This builtin command is used to define and lookup styles.  Styles are
 pairs of names and values, where the values consist of any number of
 strings.  They are stored together with patterns and lookup is done by
-giving a string, called the `context', which is compared to the
-patterns.  The definition stored for the first matching pattern will be 
-returned.
+giving a string, called the `em(context)', which is matched against the
+patterns.  The definition stored for the most specific pattern that matches
+will be returned.
 
-For ordering of comparisons, patterns are searched from most specific to
-least specific, and patterns that are equally specific keep the order in 
-which they were defined.  A pattern is considered to be more specific
+A pattern is considered to be more specific
 than another if it contains more components (substrings separated by
 colons) or if the patterns for the components are more specific, where 
 simple strings are considered to be more specific than patterns and
 complex patterns are considered to be more specific than the pattern
-`tt(*)'.
+`tt(*)'.  A `tt(*)' in the pattern will match zero or more characters
+in the context; colons are not treated specially in this regard.
+If two patterns are equally specific, the tie is broken in favour of
+the pattern that was defined first.
+
+em(Example)
+
+For example, to define your preferred form of precipitation depending on which
+city you're in, you might set the following in your tt(zshrc):
+
+example(zstyle ':weather:europe:*' preferred-precipitation rain
+zstyle ':weather:europe:germany:* preferred-precipitation none
+zstyle ':weather:europe:germany:*:munich' preferred-precipitation snow)
+
+Then, the fictional `tt(weather)' plugin might run under the hood a command
+such as
+
+example(zstyle -s ":weather:${continent}:${country}:${county}:${city}" preferred-precipitation REPLY)
+
+in order to retrieve your preference into the scalar variable tt($REPLY).
+
+em(Usage)
 
 The first form (without arguments) lists the definitions.  Styles
 are shown in alphabetic order and patterns are shown in the order
@@ -39,7 +58,7 @@ tt(zstyle).  The optional first argument is a pattern which will be matched
 against the string supplied as the pattern for the context; note that
 this means, for example, `tt(zstyle -L ":completion:*")' will
 match any supplied pattern beginning `tt(:completion:)', not
-just tt(":completion:*"):  use tt(":completion:\*") to match that.
+just tt(":completion:*"):  use tt(':completion:\*') to match that.
 The optional second argument limits the output to a specific var(style) (not a
 pattern).  tt(-L) is not compatible with any other options.
 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 16:56   ` Peter Stephenson
@ 2020-01-13 17:46     ` Mikael Magnusson
  2020-01-14 11:52       ` Peter Stephenson
  2020-01-13 17:53     ` Bart Schaefer
  1 sibling, 1 reply; 13+ messages in thread
From: Mikael Magnusson @ 2020-01-13 17:46 UTC (permalink / raw)
  To: zsh-users

On 1/13/20, Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Mon, 2020-01-13 at 17:46 +0100, Pier Paolo Grassi wrote:
>> For the episodes command I would like to override this style, and set it
>> to:
>>
>> zstyle ':completion:*:*:episodes:*:*' matcher-list 'm:{a-z}={A-Za-z}
>> l:|=*
>> r:|=*'
>>
>> but this doesn't seem to match when i try completion pressing tab after
>> the
>> episodes command.
>
> I've a feeling matcher-list is only run in a very general context, so
> updating per command doesn't work, and you need to use the matcher style
> for more specific cases.  However, I may not be remembering the two
> styles where this applies correctly, and the documentation doesn't
> explicitly say where the two work and don't work.

You're correct, the documentation for tag-order says:
"The matcher-list style offers something similar, but it is tested
very early in the completion system and hence can’t be set for single
commands nor for more specific contexts."

But arguably it could say this in the documentation for matcher-list instead.

-- 
Mikael Magnusson

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 16:56   ` Peter Stephenson
  2020-01-13 17:46     ` Mikael Magnusson
@ 2020-01-13 17:53     ` Bart Schaefer
  1 sibling, 0 replies; 13+ messages in thread
From: Bart Schaefer @ 2020-01-13 17:53 UTC (permalink / raw)
  To: Zsh Users

On Mon, Jan 13, 2020 at 8:57 AM Peter Stephenson
<p.stephenson@samsung.com> wrote:
>
> I've a feeling matcher-list is only run in a very general context, so
> updating per command doesn't work, and you need to use the matcher style
> for more specific cases.

Yes, that's exactly it.  matcher-list is an oddball that gets queried
before the individual completers are called, so it never has the
fully-formed context string.  It populates the default _matchers array
at the top level of _main_complete, which is then overridden by the
matcher style when _descriptions is called after the context is filled
out.

The documentation comes at this sort of sideways; under matcher-list we find:

              It is possible to create match specifications valid for particu-
              lar  completers  by  using the third field of the context.  This
              applies  only   to   completers   that   override   the   global
              matcher-list, which as of this writing includes only _prefix and
              _ignored.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 17:46     ` Mikael Magnusson
@ 2020-01-14 11:52       ` Peter Stephenson
  0 siblings, 0 replies; 13+ messages in thread
From: Peter Stephenson @ 2020-01-14 11:52 UTC (permalink / raw)
  To: zsh-users

On Mon, 2020-01-13 at 18:46 +0100, Mikael Magnusson wrote:
> You're correct, the documentation for tag-order says:
> "The matcher-list style offers something similar, but it is tested
> very early in the completion system and hence can’t be set for single
> commands nor for more specific contexts."
> 
> But arguably it could say this in the documentation for matcher-list instead.

Thanks --- rather than duplicate it's probably better to add
cross-references.  But it's all rather a headful to take in however
documented.

pws

diff --git a/Doc/Zsh/compsys.yo b/Doc/Zsh/compsys.yo
index ce3e6ea1e..c2d20ca40 100644
--- a/Doc/Zsh/compsys.yo
+++ b/Doc/Zsh/compsys.yo
@@ -2060,6 +2060,9 @@ specification.  The value should be in the form described in
 ifzman(the section `Completion Matching Control' in zmanref(zshcompwid))\
 ifnzman(noderef(Completion Matching Control))\
 .  For examples of this, see the description of the tt(tag-order) style.
+
+For notes comparing the use of this and the tt(matcher-list) style, see
+under the description of the tt(tag-order) style.
 )
 kindex(matcher-list, completion style)
 item(tt(matcher-list))(
@@ -2124,6 +2127,9 @@ If there is no current matcher or it is empty, and the option
 tt(NO_CASE_GLOB) is in effect, the matching for files is performed
 case-insensitively in any case.  However, any matcher must
 explicitly specify case-insensitive matching if that is required.
+
+For notes comparing the use of this and the tt(matcher) style, see
+under the description of the tt(tag-order) style.
 )
 kindex(max-errors, completion style)
 item(tt(max-errors))(



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-13 17:06   ` Daniel Shahaf
  2020-01-13 17:41     ` [PATCH] docs: Add an example of setting and querying zstyles (was: Re: problem with context specification) Daniel Shahaf
@ 2020-01-14 15:59     ` Pier Paolo Grassi
  2020-01-14 16:45       ` Daniel Shahaf
  1 sibling, 1 reply; 13+ messages in thread
From: Pier Paolo Grassi @ 2020-01-14 15:59 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 3914 bytes --]

thanks all for the clarifications. I will try to use the method described
in the tag-order style documentation

to answer Daniel:

> I take it the documentation of zstyle didn't make this clear, so could you
> suggest how to improve it?

It's not clear to me what is the meaning of the various "sections"of the
pattern (the segments delimited by the colons)
what should I put in the first section? is there a list of possible values
and relative meaning?
and so on for each section
why the number of sections is not the same for every pattern? How can I
know how many pattern I should put in?
I assume the stars are for matching every possible value for that segment,
are there other globbing operators available? can I use them for
prefix/suffix matching? (eg someth* for something etc)
Not that I think it would be particularly useful, but the question came to
mind
I assume also that the stars don't match multiple segments, but this
doesn't seem to be stated in the docs.

regards

Pier Paolo Grassi
linkedin: https://www.linkedin.com/in/pier-paolo-grassi-19300217
founder: https://www.meetup.com/it-IT/Machine-Learning-TO


Il giorno lun 13 gen 2020 alle ore 18:06 Daniel Shahaf <
d.s@daniel.shahaf.name> ha scritto:

> Pier Paolo Grassi wrote on Mon, Jan 13, 2020 at 17:46:09 +0100:
> > if I substitute this as the general case, eg:
> >
> >   zstyle ':completion:*' matcher-list 'm:{a-z}={A-Za-z} l:|=* r:|=*'
> >
> > then everything get this style, so the syntax is correct. it seem that
> what
> > is wrong is the pattern.
> > I tried some variations of it, with no success:
> >
> >   zstyle ':completion:*:*:episodes:*' ...
> >   zstyle ':completion:*:episodes:*' ...
> >
> > my main problem is that I don't really understand the pattern syntax, and
> > haven't been able to find a man page detailing it (the documentation on
> the
> > zstyle builtin doesn't explain it), so I basically try random variations.
>
> The documentation does explain it; quote:
>
>               For ordering of comparisons, patterns are searched from most
>               specific to least specific, and patterns that are equally
>               specific keep the order in which they were defined.  A
> pattern
>               is considered to be more specific than another if it contains
>               more components (substrings separated by colons) or if the
>               patterns for the components are more specific, where simple
>               strings are considered to be more specific than patterns and
>               complex patterns are considered to be more specific than the
>               pattern `*'.
>
> The upshot of this is that each of the patterns
> ':completion:*:*:episodes:*'
> and ':completion:*:episodes:*' is considered to be more specific than
> ':completion:*'.  A style set under either of the former would have
> precedence
> over a style set under the latter, _as far as zstyle is concerned_.  (See
> pws's answer for the caveat.)
>
> > Using ctrl-x h after episodes on the command line it gives:
> >
> > tags in context :completion::complete:episodes::
> >     argument-rest  (_arguments _episodes)
> >
> > so I've tried:
> >   zstyle ' :completion::complete:episodes::'
> >
> > but still to no effect, and also the lack of * seems a little suspicious
>
> No, the lack of stars is expected.  What you put in zshrc is patterns; the
> completion system then looks up specific strings that the patterns are
> matched
> against.  The settings attached to the most specific pattern that matches
> are
> used.
>
> Minimal example:
>
> zshrc contains:
>
> % zstyle ':foo:bar' lorem yes
> % zstyle ':foo:*'   lorem no
>
> Then the foo subsystem might run, for example:
>
> % zstyle -t :foo:bar lorem && pwd
> /home/daniel
> % zstyle -t :foo:baz lorem && pwd
> %
>
> I take it the documentation of zstyle didn't make this clear, so could you
> suggest how to improve it?
>
> Cheers,
>
> Daniel
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-14 15:59     ` problem with context specification Pier Paolo Grassi
@ 2020-01-14 16:45       ` Daniel Shahaf
  2020-01-14 17:55         ` Pier Paolo Grassi
  2020-01-14 18:05         ` Peter Stephenson
  0 siblings, 2 replies; 13+ messages in thread
From: Daniel Shahaf @ 2020-01-14 16:45 UTC (permalink / raw)
  To: Pier Paolo Grassi; +Cc: Zsh-Users List

Pier Paolo Grassi wrote on Tue, 14 Jan 2020 15:59 +00:00:
> to answer Daniel:
> 
> > I take it the documentation of zstyle didn't make this clear, so could you
> > suggest how to improve it?
> 
> It's not clear to me what is the meaning of the various "sections"of the
> pattern (the segments delimited by the colons)

This, too, is explained in the manual (see zshcompsys(1), or online):

       The context string always consists of a fixed set of fields, separated
       by colons and with a leading colon before the first.  Fields which are
       not yet known are left empty, but the surrounding colons appear anyway.
       The fields are always in the order
       :completion:function:completer:command:argument:tag.  These have the
       following meaning:

> what should I put in the first section?

":completion:", literally.  That's hard-coded.  See the patch I posted
for another example, and Misc/vcs_info-examples in the source
distribution.

> is there a list of possible values and relative meaning?

The manual does list the available completers and many tags and styles (the style
is, e.g., "matcher-list" in your example), but it's possible some commands use custom
ones.  Ctrl+X h is the standard recommendation for discovering these.

> and so on for each section
> why the number of sections is not the same for every pattern?

Because asterisks can match colons.  The number of sections in the
context _that is looked up_ (with zstyle -s/-t/-T/-b/-a) is always the
same.  There's an example in the patch I posted.

> How can I know how many pattern I should put in?

One pattern per zstyle command in your zshrc.

If you mean how many colon-separated parts, that's up to you.  It's
basically a matter of coding style unless you set the same style in
multiple contexts, in which case the colons directly affect precedence,
as explained in the portion of the docs I quoted in my first answer
(though in retrospect I'm not sure now if that was what you were asking
about then).

> I assume the stars are for matching every possible value for that segment,

No.  An asterisk matches zero or more characters, _including colons_.
(My patch said that explicitly.)

> are there other globbing operators available?

Yes, anything that works in «case $haystack in ‹needle›) …;; esac», or
equivalently in «[[ ‹haystack› == ‹needle› ]]», can be used in zstyle settings.

> can I use them for prefix/suffix matching? (eg someth* for
> something etc)

Yes, you could:

% zstyle 'foob*' key value
%                           
% zstyle -s foobar key REPLY 
% typeset -p REPLY
typeset REPLY=value
% 

For example, I set:

zstyle ':completion:*:*:git-*:*:hosts' ignored-patterns localhost ip6-localhost ip6-loopback

and the style applies to git-push(1), git-pull(1), git-ls-remote(1), etc..

> Not that I think it would be particularly useful, but the question
> came to mind I assume also that the stars don't match multiple
> segments, but this doesn't seem to be stated in the docs.

See above.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-14 16:45       ` Daniel Shahaf
@ 2020-01-14 17:55         ` Pier Paolo Grassi
  2020-01-14 18:05         ` Peter Stephenson
  1 sibling, 0 replies; 13+ messages in thread
From: Pier Paolo Grassi @ 2020-01-14 17:55 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh-Users List

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

thanks, this is very helpful in putting together many bits of information.
zsh has a very extensive documentation and sometimes it feels a bit
overwhelming

Pier Paolo Grassi
linkedin: https://www.linkedin.com/in/pier-paolo-grassi-19300217
founder: https://www.meetup.com/it-IT/Machine-Learning-TO


Il giorno mar 14 gen 2020 alle ore 17:45 Daniel Shahaf <
d.s@daniel.shahaf.name> ha scritto:

> Pier Paolo Grassi wrote on Tue, 14 Jan 2020 15:59 +00:00:
> > to answer Daniel:
> >
> > > I take it the documentation of zstyle didn't make this clear, so could
> you
> > > suggest how to improve it?
> >
> > It's not clear to me what is the meaning of the various "sections"of the
> > pattern (the segments delimited by the colons)
>
> This, too, is explained in the manual (see zshcompsys(1), or online):
>
>        The context string always consists of a fixed set of fields,
> separated
>        by colons and with a leading colon before the first.  Fields which
> are
>        not yet known are left empty, but the surrounding colons appear
> anyway.
>        The fields are always in the order
>        :completion:function:completer:command:argument:tag.  These have the
>        following meaning:
>
> > what should I put in the first section?
>
> ":completion:", literally.  That's hard-coded.  See the patch I posted
> for another example, and Misc/vcs_info-examples in the source
> distribution.
>
> > is there a list of possible values and relative meaning?
>
> The manual does list the available completers and many tags and styles
> (the style
> is, e.g., "matcher-list" in your example), but it's possible some commands
> use custom
> ones.  Ctrl+X h is the standard recommendation for discovering these.
>
> > and so on for each section
> > why the number of sections is not the same for every pattern?
>
> Because asterisks can match colons.  The number of sections in the
> context _that is looked up_ (with zstyle -s/-t/-T/-b/-a) is always the
> same.  There's an example in the patch I posted.
>
> > How can I know how many pattern I should put in?
>
> One pattern per zstyle command in your zshrc.
>
> If you mean how many colon-separated parts, that's up to you.  It's
> basically a matter of coding style unless you set the same style in
> multiple contexts, in which case the colons directly affect precedence,
> as explained in the portion of the docs I quoted in my first answer
> (though in retrospect I'm not sure now if that was what you were asking
> about then).
>
> > I assume the stars are for matching every possible value for that
> segment,
>
> No.  An asterisk matches zero or more characters, _including colons_.
> (My patch said that explicitly.)
>
> > are there other globbing operators available?
>
> Yes, anything that works in «case $haystack in ‹needle›) …;; esac», or
> equivalently in «[[ ‹haystack› == ‹needle› ]]», can be used in zstyle
> settings.
>
> > can I use them for prefix/suffix matching? (eg someth* for
> > something etc)
>
> Yes, you could:
>
> % zstyle 'foob*' key value
> %
> % zstyle -s foobar key REPLY
> % typeset -p REPLY
> typeset REPLY=value
> %
>
> For example, I set:
>
> zstyle ':completion:*:*:git-*:*:hosts' ignored-patterns localhost
> ip6-localhost ip6-loopback
>
> and the style applies to git-push(1), git-pull(1), git-ls-remote(1), etc..
>
> > Not that I think it would be particularly useful, but the question
> > came to mind I assume also that the stars don't match multiple
> > segments, but this doesn't seem to be stated in the docs.
>
> See above.
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-14 16:45       ` Daniel Shahaf
  2020-01-14 17:55         ` Pier Paolo Grassi
@ 2020-01-14 18:05         ` Peter Stephenson
  2020-01-14 18:34           ` Bart Schaefer
  1 sibling, 1 reply; 13+ messages in thread
From: Peter Stephenson @ 2020-01-14 18:05 UTC (permalink / raw)
  To: zsh-users

On Tue, 2020-01-14 at 16:45 +0000, Daniel Shahaf wrote:
> > I assume the stars are for matching every possible value for that segment,
> No.  An asterisk matches zero or more characters, _including colons_.
> (My patch said that explicitly.)

This can certainly be a right pain.  If we'd thought about it at the
time, we might have made the convention that separators are /s and we
can turn on per-path matching for this case (actually not as trivial as it
might sound because currently that's heavily specific to managing file
paths, so we'd need an extra zstyle-specific loop in any case).

I guess there might still be room for an option that does this in some
clever way, though it'll only be useful if it can do it with colons.

Still not foolproof, though, as if extra segments ever appear you
can end up with a failed match for no good reason.  So I'm not
sure how advisable it would be to unleash this on users.

This can be filed under "probably won't ever actually happen".

pws


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-14 18:05         ` Peter Stephenson
@ 2020-01-14 18:34           ` Bart Schaefer
  2020-01-14 18:50             ` Daniel Shahaf
  0 siblings, 1 reply; 13+ messages in thread
From: Bart Schaefer @ 2020-01-14 18:34 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh Users

On Tue, Jan 14, 2020 at 10:06 AM Peter Stephenson
<p.stephenson@samsung.com> wrote:
>
> On Tue, 2020-01-14 at 16:45 +0000, Daniel Shahaf wrote:
> > > I assume the stars are for matching every possible value for that segment,
> > No.  An asterisk matches zero or more characters, _including colons_.
>
> This can certainly be a right pain.

It's important to remember that the colons are strictly a completion
system convention -- they have nothing to do with the semantics of
zstyle itself, which can use any sort of context patterns and style
names.  That's why completion styles explicitly begin with the fixed
string ":completion:".  I even spent a while experimenting with using
it to construct an object hierarchy for a message-passing programming
style (too slow to be more than a curiosity).

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: problem with context specification
  2020-01-14 18:34           ` Bart Schaefer
@ 2020-01-14 18:50             ` Daniel Shahaf
  0 siblings, 0 replies; 13+ messages in thread
From: Daniel Shahaf @ 2020-01-14 18:50 UTC (permalink / raw)
  To: zsh-users

Bart Schaefer wrote on Tue, 14 Jan 2020 18:34 +00:00:
> On Tue, Jan 14, 2020 at 10:06 AM Peter Stephenson
> <p.stephenson@samsung.com> wrote:
> >
> > On Tue, 2020-01-14 at 16:45 +0000, Daniel Shahaf wrote:
> > > > I assume the stars are for matching every possible value for that segment,
> > > No.  An asterisk matches zero or more characters, _including colons_.
> >
> > This can certainly be a right pain.
> 
> It's important to remember that the colons are strictly a completion
> system convention -- they have nothing to do with the semantics of
> zstyle itself,

That's not so.  A colon is hardcoded into the determination of which
pattern is more specific than another.  For example, consider this:

zstyle ':foo:*' key value
zstyle ':foo:bar:*' key value

This is two patterns.  The second one is more specific than the first
because it has more segments.  The order of definition of these two
patterns will not affect lookup results:

% zstyle ':foo:*' key value1 
% zstyle ':foo:bar:*' key value2 
% zstyle -s :foo:bar:baz key a 
% zstyle -d ':foo:*'
% zstyle -d ':foo:bar:*'
% zstyle ':foo:bar:*' key value2 
% zstyle ':foo:*' key value1 
% zstyle -s :foo:bar:baz key b 
% echo $a $b 
value2 value2
% 

Now, change the example to not use colons:

zstyle '/lorem/*' key value
zstyle '/lorem/ipsum/*' key value

This is two patterns that are *equally* specific — each of them consists
of one colon-separated segment that's neither a literal string nor the
pattern «*» — so the order of definition does matter: if you change the
order of definitions of these two patterns, lookup results will be
different:

% zstyle '/lorem/*' key value1 
% zstyle '/lorem/ipsum/*' key value2 
% zstyle -s /lorem/ipsum/dolor key a 
% zstyle -d '/lorem/*'
% zstyle -d '/lorem/ipsum/*'
% zstyle '/lorem/ipsum/*' key value2 
% zstyle '/lorem/*' key value1 
% zstyle -s /lorem/ipsum/dolor key b 
% echo $a $b 
value1 value2
% 

This is documented and tested.

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-01-14 18:51 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20200113164758eucas1p17ea364450eec705f49edaa8fb69fa65b@eucas1p1.samsung.com>
2020-01-13 16:46 ` problem with context specification Pier Paolo Grassi
2020-01-13 16:56   ` Peter Stephenson
2020-01-13 17:46     ` Mikael Magnusson
2020-01-14 11:52       ` Peter Stephenson
2020-01-13 17:53     ` Bart Schaefer
2020-01-13 17:06   ` Daniel Shahaf
2020-01-13 17:41     ` [PATCH] docs: Add an example of setting and querying zstyles (was: Re: problem with context specification) Daniel Shahaf
2020-01-14 15:59     ` problem with context specification Pier Paolo Grassi
2020-01-14 16:45       ` Daniel Shahaf
2020-01-14 17:55         ` Pier Paolo Grassi
2020-01-14 18:05         ` Peter Stephenson
2020-01-14 18:34           ` Bart Schaefer
2020-01-14 18:50             ` Daniel Shahaf

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).