Release candidate patch for 3.0.6

Release candidate patch for 3.0.6

[Bart Schaefer]

I've made up a a third pre-patch for 3.0.6, which carries the version number
3.0.6-pre-2.  The set is now:
        ftp://ftp.brasslantern.com/pub/zsh/zsh-3.0.5-3.0.6-pre-0.diff
        ftp://ftp.brasslantern.com/pub/zsh/zsh-3.0.6-pre-0-pre-1.diff
        ftp://ftp.brasslantern.com/pub/zsh/zsh-3.0.6-pre-1-pre-2.diff

Remember that after applying patches to 3.0.5, you must "touch stamp-h.in"
before running configure to prevent make from attempting to rerun autoconf
and autoheader.

Checksums on the latest diff:

(BSD)  47228   107
(SYSV) 55939 214 zsh-3.0.6-pre-1-pre-2.diff

This patch is slightly larger than the others, although it includes fewer
real changes.  The accumulated FAQ changes form a large diff, and deleting
all the RCS $Id...$ lines made for a whole lot of small ones.

A word on zsh.h macros:  I didn't change STOPHIST and ALLOWHIST, which
include trailing semicolons in their definitions and hence must be used
without one.  Strictly speaking, those macros should be used the way that
PERMALLOC and LASTALLOC are, but to actually make them include matching
braces would force a considerable reorganization of the lexer code; not
worth doing in 3.0.  So ...

Except for the minor items noted below, I believe the code to be ready for
release as 3.0.6.  However, I'm going to wait a bit to see if any other
comments or bugs crop up (Ville Herva's timing was good today).  I'm a bit
concerned that 3.0.6 is not getting tested much because most zsh-workers
are running -pws-16.

Things that still might happen:

* The config.log and an empty config.cache were erroneously (?) included
  in the 3.0.5 tar file. Unless somebody can tell me why not to, I'll
  delete them from the final 3.0.6.

* I'll also likely delete the Src/tags and Src/TAGS files.  Looks like
  they were actually in RCS at some point (see the Makefile), but my
  ctags program produces a file almost twice as large as the old one,
  so I'm not confident I can regenerate them reliably.  Suggestions?

* I might still be talked out of the macro changes in zsh.h.

* I haven't done anything with Greg Badros's color completion patches;
  nobody on zsh-workers has commented on this, but it just occurred to
  me that Greg himself might not be on zsh-workers, so I've explicitly
  Cc'd him.  I personally am completely indifferent to colorizing.

Here are the new ChangeLog entries since -pre-1:

+ 1999-04-28 05:29  Bart Schaefer <schaefer@zsh.org>
+ 
+ 	* Src/zle_main.c: Move setting of timeval tv_sec = 0 to immediately
+ 	before select() to work around obscure Linux problem where select()
+ 	may write garbage into tv_sec after the kernel has been running for
+ 	248 days.  Linux problem and its workaround reported by Ville Herva
+ 	<vherva@babbage.tky.hut.fi> in zsh-workers 6126.
+ 
+ 1999-04-28 05:20  Bart Schaefer <schaefer@zsh.org>
+ 
+ 	* INSTALL, Makefile.in, configure.in, Doc/Makefile.in,
+ 	Etc/Makefile.in, Functions/Makefile.in, Misc/Makefile.in,
+ 	Misc/compctl-examples, Src/Makefile.in, Src/builtin.c,
+ 	Src/compat.c, Src/cond.c, Src/exec.c, Src/glob.c, Src/globals.h,
+ 	Src/hashtable.c, Src/hashtable.h, Src/hist.c, Src/init.c,
+ 	Src/input.c, Src/jobs.c, Src/lex.c, Src/linklist.c, Src/loop.c,
+ 	Src/math.c, Src/mem.c, Src/params.c, Src/parse.c, Src/prototypes.h,
+ 	Src/rlimits.awk, Src/signals.c, Src/signals.h, Src/signames.awk,
+ 	Src/subst.c, Src/system.h, Src/text.c, Src/utils.c, Src/watch.c,
+ 	Src/zle.h, Src/zle_bindings.c, Src/zle_hist.c, Src/zle_main.c,
+ 	Src/zle_misc.c, Src/zle_move.c, Src/zle_refresh.c,
+ 	Src/zle_tricky.c, Src/zle_utils.c, Src/zle_vi.c, Src/zle_word.c,
+ 	Src/ztype.h, StartupFiles/Makefile.in, StartupFiles/zlogin,
+ 	StartupFiles/zshenv, StartupFiles/zshrc, Util/Makefile.in,
+ 	Util/reporter, Util/zsh-development-guide: Remove $Id...$ line.
+ 
+ 	* Src/zsh.h: Remove $Id...$ line.  Change all macros that use "if
+ 	(...) {;} else ..." to be unambiguous statements, mostly by
+ 	wrapping in "do { ... } while (0)".
+ 
+ 1999-04-28 05:16  Bart Schaefer <schaefer@zsh.org>
+ 
+ 	* Etc/FAQ: Update to latest FAQ.  Remove $ from around $Id ... $
+ 	line to freeze RCS id.
+ 
+ 1999-04-25 17:17  schaefer
+ 
+ 	* Src/globals.h, Src/zle_refresh.c, Src/zsh.h: Tatsuo Furukawa
+ 	<frkwtto@osk3.3web.ne.jp> change to use absolute cursor move when
+ 	available, from zsh-workers 6073, as modified by Geoff Wing in
+ 	6096.

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

alwayslastprompt bugs in 3.0.6-pre-2 (?)

[Bart Schaefer]

On Apr 28,  1:30am, Greg Badros wrote:
} Subject: colorized completion patch [was Re: Release candidate patch for 3
}
} Also note that there are bugs in 3.0.6-pre-2 (yes, even before my code!
} :-) ) in the erasing of completions in M-x command mode when "setopt
} alwayslastprompt".

Are these problems that didn't exist in 3.0.5?  Can you describe them in
more detail?  I've just spent a few minutes fooling with alwayslastprompt,
listambiguous and autolist, and I don't see any problems.

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

Re: alwayslastprompt bugs in 3.0.6-pre-2 (?)

[Bart Schaefer]

On Apr 28,  2:47pm, Greg Badros wrote:
> Subject: Re: alwayslastprompt bugs in 3.0.6-pre-2 (?)
> "Bart Schaefer" <schaefer@brasslantern.com> writes:
> 
> ESC-x backward[CTRL-D]-char[ENTER]
>               ^^^^^^^^ this shows the menu under the "execute:" prompt
> 
> After pressing ENTER, only the first line of the menu is erased.  The
> rest disappears after the next prompt, but not while editing the current 
> line.

Oh.  Believe it or not, that's intentional.  It was only changed recently
in 3.1.5-pws-something when a whole slew of other commands were also added
to the set of actions that completely clear the completion listing.

> Also, when at the end of the xterm window (nxterm from RedHat 5.2, or
> the latest xterm96 built from sources) once I hit the "b" in "backward"
> above, a newline and a space get printed causing the text to scroll up
> unnecessarily.

Geoff can say for sure, but I think that's a side-effect of writing code
that works OK on terminals whose termcap/info entries lie about the way
automargin behaves on the last line of the display.

In short, I don't think either of these counts as a bug.

Re: alwayslastprompt bugs in 3.0.6-pre-2 (?)

[Bart Schaefer]

On Apr 28,  6:09pm, Greg Badros wrote:
> Subject: Re: alwayslastprompt bugs in 3.0.6-pre-2 (?)
> "Bart Schaefer" <schaefer@brasslantern.com> writes:
> 
> Can someone justify to me why it's better to not clear the completion
> listing for Esc-X?

Probably not, because it's not better.  That's why it changed in 3.1.5+.
The issue is that there are a number of other commands that don't clear
the completion list for which that's also sub-optimal, so it's hard to
justify fixing any one of them, and harder to justify fixing all of them.

However, if Sven (or anyone else) sends a patch, I'll include it.

Re: alwayslastprompt bugs in 3.0.6-pre-2 (?)

[Bart Schaefer]

On Apr 28,  6:38pm, Bart Schaefer wrote:
> However, if Sven (or anyone else) sends a patch, I'll include it.

I should qualify that:  I won't include a patch that seems to have the
potential to introduce new bugs just for the sake of fixing these display
anomalies.

Re: colorized completion patch [was Re: Release candidate patch for 3.0.6]

[Greg Badros]

"Bart Schaefer" <schaefer@brasslantern.com> writes:

> On Apr 28,  1:30am, Greg Badros wrote:
> > Subject: colorized completion patch [was Re: Release candidate patch for 3
> > Ah, what the hell... I went ahead and updated my patch for zsh-3.0.6-pre2.
> 
> Maybe this got asked before, but:  What's the GPL encumbrance status of the
> code you lifted from fileutils?  Is it your code and you are separately
> licensing it to the Zsh Development Group?  Or is it someone else's code,
> in which case it is GPL'd and I can't include it?
> 
> (The zsh group has a long history of dissastisfaction with GNU licensing,
> all the way back to PF himself.  I can't accept any code that "infects"
> zsh with the GPL.)

Understood.  When I first introduced my patch a while back, this came
up.  I asked RMS about it, and he seemed willing to grant an exception
for the small amount of GNU code I was using, but then the discussion
closed to between RMS and some zsh maintainer (I don't remember who, but 
my guess is it was someone still on the list).

I'll ask Richard again if the issue wasn't resolved 2 years ago --
coincidentally, I was just demoing my Scwm (scheme constraints window
manager) to him on Wednesday while he was down here visiting Melbourne, Australia.

Greg