zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCH] Re: Should we be avoiding "zstyle -m" ?
Date: Tue, 9 Jan 2024 10:30:11 -0800	[thread overview]
Message-ID: <CAH+w=7agGbAjbQCk_LNq4SRn8jUNE5N6oB5zq-i19iJZ_2NOxA@mail.gmail.com> (raw)
In-Reply-To: <CAHYJk3RKRE5QW-E9_r2gJtncxqG9fkq5Oh1rr6f9rc6CEY7ziQ@mail.gmail.com>

On Tue, Jan 9, 2024 at 1:17 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> I don't understand what the \ does in your context argument for zstyle -m

That is in reference to url-quote-magic.

The more typical usage would be in completion, e.g., in _sysrc
  zstyle -m ":completion:${curcontext%:*}:values" cache-policy '*'
where the context argument is built up by the chain of calls below
_main_complete and actually means something well-defined

The \* in the url-quote-magic context is just there so that the part
after the last colon is neither empty nor a legal value for a URL
scheme.

> This makes me suspicious that maybe the code doesn't at all do what
> the author expected it to do?

It's expected to return false for e.g.
  zstyle 'zstyle ':url-quote-magic:http*' url-metas '+*?[]^(|)#{}='
because that context is more specific than
  zstyle ':url-quote-magic:*' url-metas '*?[]^(|)~#{}='
for which it should return true (and does as you found).

The idea is to install the least-specific context whenever the user
has not already defined that, so that the user doesn't need to define
contexts other than the most specific.  So it needs a context that
will never match something more specific.  The actual lookup, later,
always will be in a full context, so is expected to skip the
least-specific default when the user has defined something more
specific that matches.

> I am slightly more confident in my view after the following experiment
> (again a new shell):
> % zstyle ':url-quote-magic:\\*' url-metas '*?[]^(|)~#{}='
> % zstyle -m ':url-quote-magic:\*' url-metas '*' && echo true
> true
>
> So if I've set the url-metas style for the \\* context, the code will
> now override whatever my url-metas style was set for in the * context

No, it won't ... it would only override when zstyle -m returns false
-- the tests in url-quote-magic are all || rather than &&

This is a different bug in that asserting a style for the '...::\\*'
context ends up being equivalent to setting the default url-metas to
unset, but given there are no sensible contexts that contain a leading
backslash, this would never occur unless someone were deliberately
trying to break it.

> On a more general note, I think the whole approach is wrong and we
> should never set a style if we think it's empty; just use the fallback
> value when you look up the style and it was empty later on in the
> code, that will never have weird subtleties like this.

True, but it considerably muddies the code that actually needs the
style values.  In url-quote-magic, that also means pushing the
defaults for some styles down into helper functions so they
potentially end up being mentioned more than once, and it prevents
setting up the defaults at autoload time so they don't have to be
re-asserted every time the function runs.

This could be a bit less messy now by using namespace parameters to
hold the defaults, but at the time zstyle was the only
explictly-scoped global cache.


      reply	other threads:[~2024-01-09 18:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-07 20:06 Bart Schaefer
2024-01-08 16:52 ` Peter Stephenson
2024-01-09  4:22   ` [PATCH] " Bart Schaefer
2024-01-09  9:17     ` Mikael Magnusson
2024-01-09 18:30       ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7agGbAjbQCk_LNq4SRn8jUNE5N6oB5zq-i19iJZ_2NOxA@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).