* Release candidate patch for 3.0.6 @ 1999-04-28 7:15 Bart Schaefer [not found] ` <qrrbtg9171h.fsf@elwha.cs.washington.edu> 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 1999-04-28 7:15 UTC (permalink / raw) To: zsh-workers; +Cc: Greg Badros 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <qrrbtg9171h.fsf@elwha.cs.washington.edu>]
* alwayslastprompt bugs in 3.0.6-pre-2 (?) [not found] ` <qrrbtg9171h.fsf@elwha.cs.washington.edu> @ 1999-04-28 15:43 ` Bart Schaefer [not found] ` <qrryajczabg.fsf@elwha.cs.washington.edu> [not found] ` <990429112806.ZM9027@candle.brasslantern.com> 1 sibling, 1 reply; 6+ messages in thread From: Bart Schaefer @ 1999-04-28 15:43 UTC (permalink / raw) To: Greg Badros; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <qrryajczabg.fsf@elwha.cs.washington.edu>]
* Re: alwayslastprompt bugs in 3.0.6-pre-2 (?) [not found] ` <qrryajczabg.fsf@elwha.cs.washington.edu> @ 1999-04-29 0:44 ` Bart Schaefer [not found] ` <qrr676gxme7.fsf@elwha.cs.washington.edu> 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 1999-04-29 0:44 UTC (permalink / raw) To: Greg Badros; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <qrr676gxme7.fsf@elwha.cs.washington.edu>]
* Re: alwayslastprompt bugs in 3.0.6-pre-2 (?) [not found] ` <qrr676gxme7.fsf@elwha.cs.washington.edu> @ 1999-04-29 1:38 ` Bart Schaefer 1999-04-29 2:14 ` Bart Schaefer 0 siblings, 1 reply; 6+ messages in thread From: Bart Schaefer @ 1999-04-29 1:38 UTC (permalink / raw) To: Greg Badros; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: alwayslastprompt bugs in 3.0.6-pre-2 (?) 1999-04-29 1:38 ` Bart Schaefer @ 1999-04-29 2:14 ` Bart Schaefer 0 siblings, 0 replies; 6+ messages in thread From: Bart Schaefer @ 1999-04-29 2:14 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <990429112806.ZM9027@candle.brasslantern.com>]
* Re: colorized completion patch [was Re: Release candidate patch for 3.0.6] [not found] ` <990429112806.ZM9027@candle.brasslantern.com> @ 1999-04-29 21:51 ` Greg Badros 0 siblings, 0 replies; 6+ messages in thread From: Greg Badros @ 1999-04-29 21:51 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1999-04-29 21:51 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-04-28 7:15 Release candidate patch for 3.0.6 Bart Schaefer [not found] ` <qrrbtg9171h.fsf@elwha.cs.washington.edu> 1999-04-28 15:43 ` alwayslastprompt bugs in 3.0.6-pre-2 (?) Bart Schaefer [not found] ` <qrryajczabg.fsf@elwha.cs.washington.edu> 1999-04-29 0:44 ` Bart Schaefer [not found] ` <qrr676gxme7.fsf@elwha.cs.washington.edu> 1999-04-29 1:38 ` Bart Schaefer 1999-04-29 2:14 ` Bart Schaefer [not found] ` <990429112806.ZM9027@candle.brasslantern.com> 1999-04-29 21:51 ` colorized completion patch [was Re: Release candidate patch for 3.0.6] Greg Badros
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).