Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Call for opinions on a couple of prospective zsh patches



On Jun 6,  2:41pm, Stefan Monnier wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} I simply have the impression that there hasn't been (m)any complaints
} about 3.0.x stability, so why keep hacking on it instead of getting 3.2
} ready for wider distribution ?

If it were a matter of "instead" I'd agree with you.  I'll let Peter speak
to 3.2 timeframes, if he has an opinion.

} The 3.0.x line should be restricted to bug-fixes.  Just like 3.2.x will be.

So far, there are 42 new ChangeLog entries in 3.0.6.  Of those, five (or
maybe six, see below) represent minor new features, all of which were first
introduced in 3.1.x.  (Greg's changes are the most significant I've looked
at, which I why I'm asking about them.)  The others are all bugfixes, many
of which also originated in 3.1.x.

Since somebody will ask, the five new features are:
    * The `preexec' function, like `precmd' but executed just before
      each command line is executed;
    * `emulate -L ...' short for `emulate ...; setopt localoptions';
    * Quoted strings may appear inside ${...}; e.g. ${(f)"$(typeset)"}
      is equivalent to "${(@f)$(typeset)}";
    * The a, c, and m glob qualifiers (access, inode change, and modify
      time comparisons) now accept times in seconds;
    * The HIST_REDUCE_BLANKS option was added, to cause history entries
      not to store strings of consecutive IFS characters between words
      (history searches also ignore most whitespace).

The PRINT_EIGHT_BIT option was also added, but I consider that a bugfix.

} > One concern is to get out a Y2K-fixed 3.0 to be included in various linux
} > releases etc.  before 3.2 reaches fruition.
} 
} I don't see in what way dabbrev, LS_COLORS and `mixed case partial word
} motions' will help fix the Y2K bug.

This is true; note I said "one concern."  Another (which I should have
mentioned, but I was in a hurry earlier) is to reduce "culture shock" when
people upgrade to 3.1.6 or 3.2.  For example, 3.1.6 will introduce a new
format for storing extended (timestamped) history entries in .zhistory.
Both 3.0.6 and 3.1.6 will be able to read both the old and new formats
(this is the maybe-sixth new feature) so that you can continue to switch
back and forth between development and stable releases if you want to;
but 3.0.6 still writes the old format.

The five changes above are all to increase compatibility between 3.1 and
3.0 configurations/scripts, though there will still be things you can do
in 3.1.6 that you simply can't do in 3.0.anything.

In any case, the point is that there is going to be a 3.0.6 release, and
the next 3.1 release won't be 3.2, so I don't want to arbitrarily exclude
anything that a significant number of zsh-users would find useful.  (If
it impacted stability, that would be another matter, but none of Greg's
changes are that radical from a code standpoint).  If general sentiment
is to hold such new features entirely for 3.2, then I have no objection;
it saves me some effort.

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



Messages sorted by: Reverse Date, Date, Thread, Author