Re: BARE_GLOB_QUAL

[Zefram <zefram@xxxxxxxx>]

Bart Schaefer wrote:
>Hm.  We're using (#x) for various values of x to introduce things like
>approximate completion, case-insensitive matching, and backrefs.  How
>about (#q...) for qualifiers?

Ah, that only works when EXTENDED_GLOB is on -- AIR, we wanted a syntax
that would work without EXTENDED_GLOB.  However, on thinking about
it now, I don't see any pressing need for that.  It seems reasonable
to have a system where the BARE_GLOB_QUAL option provides access
to an EXTENDED_GLOB feature in non-EXTENDED_GLOB globbing syntaxes.
(#q...) looks like a good choice.

>                               Also (#Q-) could turn off BARE_GLOB_QUAL,
>and (#Q+) could turn it on.  (I can't decide which of those just (#Q)
>should do.)

That's silly.  "(#Q+)" is a lot more characters than just adding "#q"
at the beginning of the qualifiers group.  Similarly, "(#Q-)" is more
typing than adding an extra pair of parens around the non-qualifier group.

We should just have "(#q...)" for qualifiers, and encourage people to
turn off BARE_GLOB_QUAL.

>That would introduce the possibility of having different qualifiers for
>different parts of the glob pattern, e.g. `*(#qG)/*(#q.^G)' would list
>all plain files not owned by the current effective group that are in
>directories that are owned by the current effective group.

That's a neat idea, but, as you say, hairy.

>For now, all (#q...) should simply be gathered up and applied at the end
>as if they appeared in a single list.

No.  To retain upward compatibility with the hairy idea, qualifiers
embedded within a pattern should be an error.  We should require
qualifiers to appear at the end, where they'll still mean the same thing
when we do implement embedded qualifiers.

-zefram