From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: BARE_GLOB_QUAL
Date: Fri, 5 Oct 2001 17:20:20 +0000 [thread overview]
Message-ID: <1011005172020.ZM32750@candle.brasslantern.com> (raw)
In-Reply-To: <20011005175629.J19300@fysh.org>
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
next prev parent reply other threads:[~2001-10-05 17:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20011002225307.A13954@astaroth.sweth.net>
[not found] ` <87adz976ru.fsf@ceramic.fifi.org>
[not found] ` <20011002231841.B14325@astaroth.sweth.net>
[not found] ` <1011003040449.ZM25370@candle.brasslantern.com>
[not found] ` <20011003001256.B14675@astaroth.sweth.net>
[not found] ` <1011003060441.ZM25764@candle.brasslantern.com>
[not found] ` <20011003021524.A15356@astaroth.sweth.net>
[not found] ` <1011003162422.ZM29481@candle.brasslantern.com>
[not found] ` <20011003142330.A16765@astaroth.sweth.net>
[not found] ` <1011004042305.ZM30162@candle.brasslantern.com>
[not found] ` <20011004004307.C18930@astaroth.sweth.net>
[not found] ` <1011005161336.ZM32521@candle.brasslantern.com>
[not found] ` <20011005172343.A2872@fysh.org>
2001-10-05 16:45 ` BARE_GLOB_QUAL Bart Schaefer
2001-10-05 16:56 ` BARE_GLOB_QUAL Zefram
2001-10-05 17:20 ` Bart Schaefer [this message]
2001-10-08 12:31 ` compctl -g not working Sven Wischnowsky
2001-10-14 1:45 ` 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=1011005172020.ZM32750@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/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).