From: Mikael Magnusson <mikachu@gmail.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Bart Schaefer <schaefer@brasslantern.com>,
zsh workers <zsh-workers@zsh.org>
Subject: Re: [PATCH] Re: (Y) modifier: up to N matches?
Date: Wed, 4 Jun 2014 08:01:21 +0200 [thread overview]
Message-ID: <CAHYJk3QA-N-uoTu2XtmFWK1xCv9C79fSp30SW7hqGdZkPD9cMg@mail.gmail.com> (raw)
In-Reply-To: <20140604020804.GA2032@tarsus.local2>
On 4 June 2014 04:08, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> Bart Schaefer wrote on Mon, Jun 02, 2014 at 20:46:03 -0700:
>> On Jun 2, 6:23pm, Daniel Shahaf wrote:
>> }
>> } Would it make sense to have (Y) take a numeric argument specifying the
>> } maximal number of files to match? e.g., *(NY5) would expand to between
>> } 0 and 5 filenames (but never more than 5).
>>
>> My concern is that people are going to expect the (o)/(O) qualifiers to
>> take effect before (Y) does, and will be confused about the "skipped"
>> files when it takes effect after. If (Y) can't return more than one
>> result, there's nothing to sort.
>
> The expectations about sorting are just as much of a problem with (Y) as
> they would be with (Y42): in both cases there might be "skipped" files.
> For example, in the source dir, *(Y/on) [or *(Y1/on)] might result in "Etc"
> even though "Doc" exists.
>
> Let's clarify that in the documentation of (Y).
>
>> However, I can't come up with any other objection.
>
> Two patches attached. The first patch implements (Y42) and adds completion
> and the above-mentioned docs clarification. (The two latter parts should be
> useful even if we don't add an argument to (Y).) The second patch isn't
> strictly required, but it cleans up the return type changes that are no
> longer needed after the first patch.
>
> FWIW, I'm intentionally making (Y) without argument an error; we can settle
> on its semantics later after (Y42) has seen some "in the field" use. The
> spelling (Y1) can be used instead.
>
> Cheers,
>
> Daniel
We already have [1,42] for the first 42 matches after sorting, just
make a reference to that I guess? And as for taking arguments, all
other glob qualifiers that take variable length arguments do it in the
form of u:args: where the : can be any character, so this should be
consistent with that, I think.
--
Mikael Magnusson
next prev parent reply other threads:[~2014-06-04 6:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 18:23 Daniel Shahaf
2014-06-03 3:46 ` Bart Schaefer
2014-06-04 2:08 ` [PATCH] " Daniel Shahaf
2014-06-04 6:01 ` Mikael Magnusson [this message]
2014-06-04 6:54 ` Bart Schaefer
2014-06-04 6:42 ` Bart Schaefer
2014-06-04 9:25 ` Peter Stephenson
2014-06-04 23:08 ` Daniel Shahaf
2014-06-04 23:16 ` Bart Schaefer
2014-06-05 4:45 ` Bart Schaefer
2014-06-05 23:24 ` Oliver Kiddle
2014-06-06 2:20 ` Bart Schaefer
2014-06-06 2:40 ` Daniel Shahaf
2014-06-06 2:45 ` Daniel Shahaf
2014-06-06 4:24 ` Bart Schaefer
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=CAHYJk3QA-N-uoTu2XtmFWK1xCv9C79fSp30SW7hqGdZkPD9cMg@mail.gmail.com \
--to=mikachu@gmail.com \
--cc=d.s@daniel.shahaf.name \
--cc=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).