pws-24

pws-24

[Peter Stephenson]

http://www.ifh.de/~pws/computing/
950658 bytes zsh-3.1.5-pws-24.tar.gz
762279 bytes zsh-3.1.5-pws-24.tar.bz2
    24 bytes zsh-3.1.5-pws-24.tar.bz2.bin -> zsh-3.1.5-pws-24.tar.bz2
434603 bytes zsh-3.1.5-pws-24.doc.tar.gz
304675 bytes zsh-3.1.5-pws-24.doc.tar.bz2
    28 bytes zsh-3.1.5-pws-24.doc.tar.bz2.bin -> zsh-3.1.5-pws-24.doc.tar.bz2

This time, the major visible changes are the complist coloured listing and
menu selection library (see the complist section of zshmodules.1), and that
the completion startup scripts compinit, compdump, compinstall are now
functions, so should be autoloaded with `autoload -U' (compinit autoloads
the other two) and then run directly.  This means compinit can't work out
where the completion files are if there not already in $fpath.  They will
already be in fpath if you do a full installation including the functions,
and compinstall will provide appropriate code in .zshrc.

intro.ms has moved from the main to the doc distribution.

There is nothing major I still think needs doing before releasing 3.1.6,
although various things like the builtin jobs signals saga still probably
need tweaking.  I hope to produce a test release in a couple of weeks (for
which I'll have to find out how to upload it to ftp.zsh.org).

I tried this version on SunOS 4.1.3 for the first time and something very
strange is happening, apparently in glob.c.  If anybody can provide more
details, I'd be glad.

1999-06-25  Peter Stephenson  <pws@ibmth.difi.unipi.it>

	* pws: 6857: Completion/Core/compinit,
	  Completion/Core/compinstall, Doc/Zsh/compsys.yo: compinit and
	  compinstall are now functions which unfunction and autoload
	  themselves.  _compdir is used by compinstall to record where
	  it found the completion directories.  compinit is now otherwise
	  stuck with fpath.

	* pws: 6851, 6853: typeset -g doesn't locallize parameters; bug
	  that unset parameters were recreated global instead of at
	  some higher local level; handle PM_AUTOLOAD consistent with other
	  flags.

	* Sven: 6850: Src/init.c: always generate a new pgrp for the
	  shell, since the parent (e.g. xterm) may not have done that
	  and zsh now runs programs in its own pgrp.

	* Sven: 6848: Src/exec.c: don't suspend if the shell is the
	  only thing to suspend (or something like that).

	* Sven: 6841: Src/loop.c: %_ in else branches for PS4

1999-06-24  Peter Stephenson  <pws@ibmth.difi.unipi.it>

	* pws: 6834: Src/glob.c, Src/hashtable.c: dyncat() changed always
	  to use heap memory (as it erroneously claimed); hashtable element
	  tablename (used for debugging) freed.

	* Bart: 6830: Src/params.c: don't create the hashtable for an
	  assoc array on assignment unless there is something to put in it.

	* Sven: 6825: Src/Zle_tricky.c: make sure path prefix and suffix
	  are quoted in filename completion; recalculate length of match
	  string.

	* Sven: 6824: Src/exec.c, Src/signals.c: functions got deleted
	  from the process table too early for job control.

	* pws: 6823: Src/exec.c, Src/utils.c:  names and line numbers
	  of functions printed for errors during execution.

	* Sven: 6822: Src/Zle/complist.c, Src/Zle/zle_tricky.c: assorted
	  completion fixes: crash with old completion; too many spaces
	  with menu inserting; too many beeps with LISTBEEP.

	* Sven: 6819: Src/exec.c, Src/jobs.c, Src/signals.c:  Run
	  jobs inside shell constructs in the same process group as the
	  shell itself.

	* Sven: 6817: Src/Zle/comp.h, Src/Zle/complist.c,
	  Src/Zle/zle_tricky.c: Change ZLS_SELECT to SELECTMIN;
	  don't automatically switch on select widget until there are
	  $SELECTMIN choices.

1999-06-23  Peter Stephenson  <pws@ibmth.difi.unipi.it>

	* pws: 6816: Doc/Zsh/params.yo, Src/utils.c:  ZBEEP parameter
	  gives string to output instead of beeping.

	* Sven: 6815: Src/Zle/complist.c: switch off menu-select for
	  hidden matches.

	* pws: 6814: Doc/Zsh/mod_zle.yo, Doc/Zsh/options.yo,
	  Doc/Zsh/zle.

Re: Feature freeze for 3.1.6? RE: pws-24

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> I actually suggest feature freeze for this release. Or it is pretty likely th
> at
> it will never come out :-0

In my experience, this has turned out to be something of a red herring in
the past.  The major problems with previous releases haven't been with new
features, which tend to evolve anyway as real users get their hands on
them, but on necessary improvements to the shell code; simple new features
which turn out to be a real benefit (parameters, options, etc.)  don't
cause any trouble.  However, anything major is now certainly going to have
to wait.

> I really think, that 3.1.6 is at least misleading and something like 4.0.0-pr
> e1
> would be much more appropriate. The initial aim of 3.1.x was to implement
> modules, and current 3.1.5-pwsNN set has developed far beyond this.

You're right that 3.1.5 and 3.1.6 don't look much alike.  However, I want 4
to be a non-beta release from the word go (ideally with not many major
changes from `3.1.6', but that will depend how things go), and I'd like to
stick to the convention that all `proper' releases are just X.Y, with extra
tags only for intermediate (non-released) versions.  How about something
like 3.1.99? or even 3.99? or something?

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Feature freeze for 3.1.6? RE: pws-24

[Andrej Borsenkow]

>
> There is nothing major I still think needs doing before releasing 3.1.6,
> although various things like the builtin jobs signals saga still probably
> need tweaking.

I actually suggest feature freeze for this release. Or it is pretty likely that
it will never come out :-0

I really think, that 3.1.6 is at least misleading and something like 4.0.0-pre1
would be much more appropriate. The initial aim of 3.1.x was to implement
modules, and current 3.1.5-pwsNN set has developed far beyond this.

The last think I'd like to be settled is job control ... at least, I expect the
clear statement on what does work and what does not work (and what will never
work).

Apart from that I believe it is pretty ready for public release.

/andrej

RE: Feature freeze for 3.1.6? RE: pws-24

[Andrej Borsenkow]

>
> You're right that 3.1.5 and 3.1.6 don't look much alike.  However, I want 4
> to be a non-beta release from the word go (ideally with not many major
> changes from `3.1.6', but that will depend how things go), and I'd like to
> stick to the convention that all `proper' releases are just X.Y, with extra
> tags only for intermediate (non-released) versions.  How about something
> like 3.1.99? or even 3.99? or something?
>

If I remember correctly, when 3.0.0 came to life it was settled on a "Linux
versioning": x.y.z is a development release for odd y, and stable for even y,
with z being bug fix release. And major number (x) is incremented at your
discretion :-)

The vital point is, that 3.1.6 is just a bug fix in this scheme ... and more
than a year for a bug fix is certainly too much :-)

Related theme: what about public CVS for Zsh? In this case it won't suffer as
much from maintainer change and there will be no need for pws-NN releases any
more (as much as I like them :-) Is it possible to host Zsh source tree on
sunsite.auc.dk?

/andrej

Re: Feature freeze for 3.1.6? RE: pws-24

[Bart Schaefer]

On Jun 28, 12:02pm, Peter Stephenson wrote:
} Subject: Re: Feature freeze for 3.1.6? RE: pws-24
}
} You're right that 3.1.5 and 3.1.6 don't look much alike. [...] How
} about something like 3.1.99? or even 3.99? or something?

On Jun 28,  2:44pm, Andrej Borsenkow wrote:
} Subject: RE: Feature freeze for 3.1.6? RE: pws-24
}
} The vital point is, that 3.1.6 is just a bug fix in this scheme ...
} and more than a year for a bug fix is certainly too much :-)

Personally, I think calling it 3.1.6 will be just fine; there's never
been any statement that the `z' numbers were "bug fixes," only that
the even `y' indicated a stable release and the odd `y' a development
release.

And there was almost a year between 3.1.2 and 3.1.3, with several
zefram-N releases in between, so it's not like we haven't done this
before.

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

public CVS archive

[Peter Stephenson]

[Disk full again.  Viewers in certain areas may have received a blank
first message.]

"Andrej Borsenkow" wrote:
> Related theme: what about public CVS for Zsh? In this case it won't suffer as
> much from maintainer change and there will be no need for pws-NN releases any
> more (as much as I like them :-) Is it possible to host Zsh source tree on
> sunsite.auc.dk?

Oh yes, I was going to ask about this, too.  There was an offer to host a
CVS source archive there before, which I'd like to take up if it's still
possible.  It will also save major disk space hassles here.

After consideration, it seems too much work to try to fit previous versions
into it (there is no existing `official' CVS archive, just partial personal
ones), particularly with all the shifting of files in the latest version.
so I was thinking of starting this with the first test release of 3.1.6.
I'd be quite happy for it to live somewhere with the existing zsh web
pages, to minimize administrative overhead.  (Hey, look, I'm talking like a
manager.  Just off for the pointy hair cut.)

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: public CVS archive

[Andrej Borsenkow]

>
> After consideration, it seems too much work to try to fit previous versions
> into it (there is no existing `official' CVS archive, just partial personal
> ones), particularly with all the shifting of files in the latest version.
> so I was thinking of starting this with the first test release of 3.1.6.

I believe, 3.0.6 should be there as well. I don't know CVS good enough to
decide, if it is worth making it a branch or just separate package. Making this
a branch is probably too much overhead.

/andrej

Re: public CVS archive

[Ollivier Robert]

According to Andrej Borsenkow:
> I believe, 3.0.6 should be there as well. I don't know CVS good enough to
> decide, if it is worth making it a branch or just separate
> package. Making this a branch is probably too much overhead.

As long as you don't have a myriad of branches, CVS is fine. Having to
branches, one for 3.0.x and the other for 3.1.x is bearable. It makes
merging easier.

Having a anoncvs server for zsh would be very nice.
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.

Re: public CVS archive

[Bart Schaefer]

On Jun 29,  2:28pm, Ollivier Robert wrote:
} Subject: Re: public CVS archive
}
} As long as you don't have a myriad of branches, CVS is fine. Having to
} branches, one for 3.0.x and the other for 3.1.x is bearable. It makes
} merging easier.

Actually, in this particular case it makes merging more difficult.  The
directory structure has changed in 3.1.x (for example, all the zle_* files
have moved to the Src/Zle subdir; in 3.0.x they're in Src) and bits and
pieces of things have moved as well (for example, bin_fg() has moved from
builtin.c to jobs.c, though both files are still in Src; other things have
moved from builtin.c to files in new directory Src/Builtins).

CVS is particularly poor at tracking entire file renames -- you have to
remove the file from one directory and add it in another -- and doesn't
help any more than any other source-code-control system when it comes to
whole functions moved from one file to another.

For many files, therefore, its extremely misleading to try to merge from
3.1.x<-->3.0.x using CVS's merge capability.  Either you can't do it at
all, or you end up with tracts of missing (in the 3.1-->3.0 direction) or
duplicated (3.0-->3.1) code in some files.  It just isn't worth it; it's
easier to generate patches and then figure out which files to apply them
to.

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