zsh-workers
 help / color / mirror / code / Atom feed
From: Zefram <A.Main@dcs.warwick.ac.uk>
To: coleman@math.gatech.edu (Richard Coleman)
Subject: Re: A couple of queries
Date: Sun, 9 Jul 1995 06:47:31 +0100 (BST)	[thread overview]
Message-ID: <27410.199507090547@stone.dcs.warwick.ac.uk> (raw)
In-Reply-To: <9507090453.AA10898@redwood.skiles.gatech.edu> from "Richard Coleman" at Jul 9, 95 00:53:47 am

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

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.

 -zefram

-----BEGIN PGP SIGNATURE-----
Version: 2.6.i

iQBVAgUBL/9tWWWJ8JfKi+e9AQGG9gH8D6R7CNNYlLOtDorySrrmFR8lS3YrFjUb
UNhpCrtbXeqMBOUAhoVJs6VGX6vim12nV0BkWuctCeemzL5DCKkFWw==
=s7Jb
-----END PGP SIGNATURE-----


      reply	other threads:[~1995-07-09  5:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1995-07-09  4:28 Zefram
1995-07-09  4:53 ` Richard Coleman
1995-07-09  5:47   ` Zefram [this message]

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=27410.199507090547@stone.dcs.warwick.ac.uk \
    --to=a.main@dcs.warwick.ac.uk \
    --cc=coleman@math.gatech.edu \
    /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).