Bart Schaefer wrote on Tue, Jun 03, 2014 at 23:42:29 -0700:
> 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.

By "directory traversal", I meant to refer not just to the order of
visiting directories (e.g., depth-first), but also to the order of
visiting files within those directories (the readdir() order).  Is there
a way to make the docs clearer?

"filesystem tree traversal order" might be more accurate, but I don't
really know whether it would be clearer than the current text to the
average reader.

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

What would (odoN) do?  It produces the same output as (oN) alone, since
presence of (oN) causes any other sort qualifiers to be ignored.

+1 on defaulting to (oN).  Patch attached.  It implements "default to
(oN) if (Yn) has been specified and no sort has been specified in any
qualifiers group".

I'm also attaching a second patch that prevents GS_NONE from being
left-shifted in the code.  I couldn't produce a user-visible problem,
but I confirmed that (1<<19) gets bitwise-or'd into gf_sorts (and 1<<19
has no defined meaning in that bitfield).

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

I don't see any other default right now either, but I wanted to leave
the door open to assign a bare (Y) some other, currently-unanticipated
meaning in the future.

>

Thanks,

Daniel