Re: [PATCH] Re: (Y) modifier: up to N matches?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 4,  2:08am, Daniel Shahaf wrote:
} Subject: [PATCH] Re: (Y) modifier: up to N matches?
} 
} Bart Schaefer wrote on Mon, Jun 02, 2014 at 20:46:03 -0700:
} > 
} > 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.

Yes, but if there's only one it's pretty obvious why.  Consider that in
your doc update you wrote:
  +filenames.  If more than var(n) matches exist, only the first var(n)
  +matches in directory traversal order will be considered.

Yet those n filenames are returned in alphabetical order, which has no
relation to directory traversal order.  In fact, people might expect
(Od) to cause subdirectories to be "traversed" before files in the
current directory, which never happens with (Y).  It might even be
preferable if (Yn) implied (odoN).

I'll repeat that this isn't a major objection.

} 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.

I'm doubtful that any default semantic other than (Y1) will be useful.

As an aside, I'm now pondering whether this can be made usable with **/
to find n matches in every directory rather than the first n matches
in the whole tree.  **/*(e{'reply=($REPLY/*(NY3))'}) almost works but
doesn't include the current diretory.