Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author


On Oct 5,  5:56pm, Zefram wrote:
} >                               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.

I wasn't thinking of typing them.  I was thinking of e.g. the completion
function system, where it wants to (in shell code) build complex patterns
from user input plus things it adds on its own.  It might be useful for
it to be able to turn on qualfiers for some sections of the pattern, and
then turn them off in a section where it wanted to append other stuff.
This might reduce the need to parse the user input and try to figure out 
how to merge it with other qualifiers.

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

That would be OK, but it'd have to work to use (#qG)(#q.) etc. at the
end -- and, again thinking of the completion system, in an expression
such as `*(.)(#qG)' there's the issue of whether (.) is a qualifier.

Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Messages sorted by: Reverse Date, Date, Thread, Author