Zsh Mailing List Archive
Messages sorted by:
Re: A couple of queries
- X-seq: zsh-workers 189
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: coleman@xxxxxxxxxxxxxxx (Richard Coleman)
- Subject: Re: A couple of queries
- Date: Sun, 9 Jul 1995 06:47:31 +0100 (BST)
- In-reply-to: <9507090453.AA10898@xxxxxxxxxxxxxxxxxxxxxxxxx> from "Richard Coleman" at Jul 9, 95 00:53:47 am
- Sender: zefram@xxxxxxxxxxxxxxxxx
-----BEGIN PGP SIGNED MESSAGE-----
>I haven't seen that code. I was going to remove that comment, but forgot.
>The code has been posix-ified considerably since the start of the 2.6
The code in that function seems to indicate that S_IF* isn't POSIX.
Not having a copy of POSIX.1 (and the library here won't open for a
while :-(), can someone confirm that this is the case? Should the code
be rewritten to use the (ugly, less efficient) S_IS* macros?
>I'm not against adding them if they don't add too much code. I think these
>would be useful. But I would prefer to use the same option for all of them.
>So we need an option letter that is free on all of these builtins, and would
>have to change compctl -L to match this. Since compctl -L is new, this
>shouldn't cause too much problem.
I'd like them all to use the same letter, and was rather disappointed
to see that typeset -L is taken. -L is a very obvious, quite intuitive
choice, so personally I'd be prepared to have an exception. I would
probably have chosen -Q.
If we want them *all* to be the same letter, the possibilities are -J,
- -M, -U, -V, -W, -Y, -w and -y, assuming -Q is taken by compctl. (Hmm,
I hope we don't start needing to use digits for compctl, it's terribly
ugly (why did we do that with zsh's command line options?)) None of
these is anywhere near as good as -L; can someone come up with a
rational reason to pick one of them? Perhaps -M for coMMands?
>But I would prefer that we wait until the next beta release before this is
>implemented. My box is overflowing with patches. I'm in the process
>of making more changes to the code dealing with internal hash tables. So
>any patch adding these features would be broken by the time I receive it.
I don't think so. Most of the listing code is there already -- I'll
just need to add a little code to output in a different format. It's a
fundamentally simple addition. Anyway, I'll wait for the next beta
before writing this stuff.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Messages sorted by: