zsh-workers
 help / color / mirror / code / Atom feed
From: Wayne Davison <wayne@clari.net>
To: "Bart Schaefer" <schaefer@brasslantern.com>
Cc: zsh-workers@sunsite.auc.dk
Subject: Re: Patch available for 3.0.6-pre-0
Date: Wed, 21 Apr 1999 16:52:09 -0700	[thread overview]
Message-ID: <199904212352.QAA27713@bebop.clari.net> (raw)
In-Reply-To: schaefer's message of Wed, 21 Apr 1999 01:15:54 -0700. <990421011554.ZM9242@candle.brasslantern.com>

"Bart Schaefer" writes:
> I'd appreciate feedback from anyone who grabs it and applies it.

I've compiled it and am checking it out now.  So far so good.

One thing I think would be nice to achieve for the 3.0.6 release is
to remove all the warnings when building zsh with gcc 2.8.1.  To
this end, I have tweaked the source and generated a diff from your
pre-0 release.  The patch is about 22k, so I won't include it here.
Anyone who wants it can grab it via the web:

    http://www.clari.net/~wayne/zsh-3.0.6-pre-0.patch

The changes were simply adding a bunch of braces to various if
blocks, and changing a few character-subscript values into unsigned-
character subscripts.

Some of the added braces were to enclose some one-line macros that
consist of an "if ... else ..."  block.  This makes it look like some
of the ifs have braces that are enclosing only one line.  I suppose
I'd prefer to see these macros get changed from this:

    if (...) {
        cmdpop();
    }

into this:

    if (...)
        CMDPOP

(so that CMDPOP could be written using curly braces), but that was
beyond the scope of my simple patch.

You may also notice that I added a few extra brace sets to some
indented-code blocks that were right near where I was already adding
braces.  I did this because I think that the code reads better when
multi-line blocks of indented code are enclosed in braces (even when
they aren't absolutely required), and because it seemed to me that
this is consistent with the latest coding style (e.g. the while loop
in the new read1char() function).

> * I haven't decided what to do with RCS $Id$ keywords.

I for one would not miss them if they were removed, but I don't
feel strongly about this.

..wayne..


  parent reply	other threads:[~1999-04-21 23:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-04-21  8:15 Bart Schaefer
1999-04-21  8:47 ` Peter Stephenson
1999-04-21 14:14 ` Tatsuo Furukawa
1999-04-21 16:05   ` Bart Schaefer
1999-04-22 15:07     ` Tatsuo Furukawa
1999-04-24  5:53       ` Bart Schaefer
1999-04-25  6:57         ` Geoff Wing
1999-04-26 15:22           ` Tatsuo Furukawa
1999-04-27 16:24             ` Bart Schaefer
1999-04-21 23:52 ` Wayne Davison [this message]
1999-04-24  4:32   ` Bart Schaefer
1999-04-24  7:12     ` Wayne Davison
1999-04-23 12:48 Sven Wischnowsky
1999-04-23 14:13 Sven Wischnowsky

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=199904212352.QAA27713@bebop.clari.net \
    --to=wayne@clari.net \
    --cc=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.auc.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).