Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Minor bug(s) with NO_MULTI_FUNC_DEF
- X-seq: zsh-workers 50321
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- Cc: Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: Minor bug(s) with NO_MULTI_FUNC_DEF
- Date: Thu, 2 Jun 2022 08:23:52 -0700
- Archived-at: <https://zsh.org/workers/50321>
- In-reply-to: <20220602102309.GF28173@tarpaulin.shahaf.local2>
- List-id: <zsh-workers.zsh.org>
- References: <CAH+w=7Y7Q8H9YVEjNd8gsE=5LzpRo74DvVAeK9ORguuuhr00kg@mail.gmail.com> <1980097513.514587.1653987797049@mail2.virginmedia.com> <20220602102309.GF28173@tarpaulin.shahaf.local2>
On Thu, Jun 2, 2022 at 3:47 AM Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
>
> Devil's advocate: letting this syntax bypass the NO_MULTI_FUNC_DEF check
> would break the invariant that «foo bar baz qux» and «foo {bar,baz} qux»
> are always equivalent.
We're not considering «foo {bar,baz} qux» here, rather
«foo{bar,baz}qux» (the spacing is important). The latter results in
«foobarqux foobazqux».
> So, if we document it, I'd rather it were documented as "This may change
> in the future" than as a feature.
I don't have an opinion about that, but as long as the check is done
by counting parser words it's not going to change.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author