Call for opinions on a couple of prospective zsh patches

Call for opinions on a couple of prospective zsh patches

[Bart Schaefer]

Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
features that could appear in zsh 3.0.6.  I'm undecided whether to add
any or all of them.  They are:

* Completion using "dynamic abbreviations" after the manner of the emacs
  dabbrev package.  This includes adding a special `dabbrev-complete' ZLE
  action, along the lines of expand-or-complete, complete-word, etc.

  I find the effects of `dabbrev-complete' to be -very- similar to
	setopt menu_complete
	compctl -D -s '${=$(history -nr 1)}'
  except that it can be bound to a different key than regular completion,
  it always uses menu-completion behavior regardless of the option, and
  the menu is sorted in reverse time order rather than alphabetically.

  The next 3.1 release will include commands to bind special user-defined
  completions to separate keystrokes (in the way that expand-or-complete
  can be bound to a different key than complete-word, in 3.0) and also to
  associate menu behavior with individual completions and to custom-sort
  the menus; so a new builtin complete action is not likely to be added in
  3.1.6.  I'm thus reluctant to have 3.0 branch off in a direction that
  the development version won't follow.  And I think that most of the
  benefits of `dabbrev-complete' can be had in plain 3.0.5 by adding the
  above -s ... to a few compctls, so a builtin is not strictly necessary.

* Partial word motions in the face of mixed case, i.e. move the cursor to
  the next/previous capital letter InMixedCaseWordsLikeThisOne, including
  deletions that treat words this way.  This is also handled by adding a
  few new ZLE builtins, and relies on isupper() to detect upper case, so
  it may behave differently in different language locales.

  My first inclination was to think that this should be handled with the
  WORDCHARS variable, but of course WORDCHARS adds other characters that
  are treated as alphanumeric; there's no way to say that upper case
  letters should -not- be treated as alphanumeric.  I guess I'd prefer a
  patch that handled wordchar-exlusions more generically (without adding
  builtins) and I may even look at adding such a thing.

  For this patch to go into 3.0.6, I'd want PWS to agree that the new ZLE
  builtins would appear in 3.1.6, too.

* Support for the LS_COLORS environment string, to colorize file names in
  the same contexts where the LIST_TYPES option presently appends various
  markers ('/' for directories, '@' for symlinks, etc.).  Depends on the
  terminal having color capability, obviously.

  The only issue about this one is that it's borrowed from GNU copylefted
  source.  I don't want to include it without an exemption from the GPL,
  and Greg doesn't want to pester the FSF about an exemption unless I'm
  certain to include it; so we're temporarily at an impasse.  If several
  zsh users say they'd like to see this included, I'll tell Greg to go
  ahead and request the exemption.

Please agree/disagree/comment to help me make a decision on these.  Thanks.

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

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

[Adam Spiers]

Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
> Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
> features that could appear in zsh 3.0.6.  I'm undecided whether to add
> any or all of them.  They are:
> 
> * Completion using "dynamic abbreviations" after the manner of the emacs
>   dabbrev package.  This includes adding a special `dabbrev-complete' ZLE
>   action, along the lines of expand-or-complete, complete-word, etc.

I submitted a patch to zsh-workers in Feb 1998 (see threads 'tcsh-like
history-based dabbrev-expand patch' and 'PATCH: complete-history')
which added history-dabbrev-expand and history-reverse-dabbrev-expand
actions, but it didn't get included because Peter had already written
a patch for zle -C, which allowed you to do something like

  zle -C complete-history -H '' 0
  bindkey "\M-/" complete-history

There were a few differences in functionality between the two (mine
had a reverse action, and with Peter's, the sequence M-/ TAB was
equivalent to M-/ M-/), but they were essentially the same thing.

Personally I find this feature so useful that I can't stand being
without it, and still use that version with my patch hacked in to this
day, which is unfortunate, because it's prevented me from regularly
trying out the newer development versions.

Which versions is zle -C (or similar) available in these days?

>   I find the effects of `dabbrev-complete' to be -very- similar to
> 	setopt menu_complete
> 	compctl -D -s '${=$(history -nr 1)}'
>   except that it can be bound to a different key than regular completion,
>   it always uses menu-completion behavior regardless of the option, and
>   the menu is sorted in reverse time order rather than alphabetically.

I really do relish it being bound to a different key.  I think I'd
prefer not to have it if it was the choice between being bound to TAB
as a fallback completion and not having it.

Also, I don't like the idea of menu-completion behaviour, because I
tend to keep a huge history (precisely for the reason that it makes a
dabbrev-expand action so useful), so I'd end up with huge menus (or a
"do you want a huge menu" prompt) most times I hit the key.  Ugh.

>   The next 3.1 release will include commands to bind special user-defined
>   completions to separate keystrokes (in the way that expand-or-complete
>   can be bound to a different key than complete-word, in 3.0) and also to
>   associate menu behavior with individual completions and to custom-sort
>   the menus; so a new builtin complete action is not likely to be added in
>   3.1.6.  I'm thus reluctant to have 3.0 branch off in a direction that
>   the development version won't follow.

Fair point.

>   And I think that most of the
>   benefits of `dabbrev-complete' can be had in plain 3.0.5 by adding the
>   above -s ... to a few compctls, so a builtin is not strictly necessary.

I'd say that if this next 3.1 release is coming soon then maybe don't
bother.  However, I would really love to see support for this
functionality ASAP.  Apart from anything else, tcsh already has it,
and we can't let tcsh have features zsh doesn't have, can we? :-)

> * Partial word motions in the face of mixed case, i.e. move the cursor to
>   the next/previous capital letter InMixedCaseWordsLikeThisOne, including
>   deletions that treat words this way.  This is also handled by adding a
>   few new ZLE builtins, and relies on isupper() to detect upper case, so
>   it may behave differently in different language locales.
> 
>   My first inclination was to think that this should be handled with the
>   WORDCHARS variable, but of course WORDCHARS adds other characters that
>   are treated as alphanumeric; there's no way to say that upper case
>   letters should -not- be treated as alphanumeric.  I guess I'd prefer a
>   patch that handled wordchar-exlusions more generically (without adding
>   builtins) and I may even look at adding such a thing.
> 
>   For this patch to go into 3.0.6, I'd want PWS to agree that the new ZLE
>   builtins would appear in 3.1.6, too.

I would like to see a lot more flexibility with the WORDCHARS stuff.
I'm constantly finding that M-f and M-b don't do what I want them to,
and I can't get them to behave how I want either.  How about the
option of an emacs-like {forward,backward}-word, which jumps to a
different place depending on which direction you're heading, for
example?

> * Support for the LS_COLORS environment string, to colorize file names in
>   the same contexts where the LIST_TYPES option presently appends various
>   markers ('/' for directories, '@' for symlinks, etc.).  Depends on the
>   terminal having color capability, obviously.
> 
>   The only issue about this one is that it's borrowed from GNU copylefted
>   source.  I don't want to include it without an exemption from the GPL,
>   and Greg doesn't want to pester the FSF about an exemption unless I'm
>   certain to include it; so we're temporarily at an impasse.  If several
>   zsh users say they'd like to see this included, I'll tell Greg to go
>   ahead and request the exemption.

I would /love/ to see this feature.  I've been missing having that in
all the shells I've used.

Adam

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

[Bart Schaefer]

On Jun 6,  2:36pm, Adam Spiers wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} Bart Schaefer (schaefer@candle.brasslantern.com) wrote:
} > Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
} > features that could appear in zsh 3.0.6.  I'm undecided whether to add
} > any or all of them.  They are:
} > 
} > * Completion using "dynamic abbreviations" after the manner of the emacs
} >   dabbrev package.  This includes adding a special `dabbrev-complete' ZLE
} >   action, along the lines of expand-or-complete, complete-word, etc.
} 
} Personally I find this feature so useful that I can't stand being
} without it, and still use that version with my patch hacked in to this
} day, which is unfortunate, because it's prevented me from regularly
} trying out the newer development versions.
} 
} Which versions is zle -C (or similar) available in these days?

Peter has been doing interim unofficial patch releases about once a week
for some while now, because Zefram's net access has been intermittent.
The "zle -C" stuff merged with some other completion changes that Sven
Wischnowsky implemented, and all will appear in 3.1.6.

(You know you've been reading zsh-workers a long time when you can spell
Wischnowsky without looking it up.)

} >   I find the effects of `dabbrev-complete' to be -very- similar to
} > 	setopt menu_complete
} > 	compctl -D -s '${=$(history -nr 1)}'
} 
} Also, I don't like the idea of menu-completion behaviour, because I
} tend to keep a huge history (precisely for the reason that it makes a
} dabbrev-expand action so useful), so I'd end up with huge menus (or a
} "do you want a huge menu" prompt) most times I hit the key.  Ugh.

I think you're confusing menu-completion with completion listings.  In a
menu completion, repeatedly striking the completion key (e.g. TAB) cycles
through the list of possible matches; you still see only one at a time,
and you aren't prompted about it.  Listing behavior (setopt auto_list and
list_ambiguous) means that if the word can't be completed, all possible
matches are displayed (or you get prompted if there are too many).

Greg's patches do not cause listing behavior, ever; it's a new builtin,
so it doesn't recognize the regular completion options.  Hm, I'd probably
have to try to do something about that if I were going to include it.

} I'd say that if this next 3.1 release is coming soon then maybe don't
} bother.

The 3.1.6 release should not be very far apart from the 3.0.6 release,
barring unforseen circumstances.

Slightly off-topic:

} I'm constantly finding that M-f and M-b don't do what I want them to,
} and I can't get them to behave how I want either.  How about the
} option of an emacs-like {forward,backward}-word, which jumps to a
} different place depending on which direction you're heading, for
} example?

I imagine this was either an oversight, or works the way it does because
Paul Falstad didn't like having two spaces left behind following a
forward-word backward-delete-word sequence.  I've long been using
	bindkey -s '^[f' '^[E^F'

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

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

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

"Bart Schaefer" wrote:
> * Partial word motions in the face of mixed case, i.e. move the cursor to
>   the next/previous capital letter InMixedCaseWordsLikeThisOne, including
>   deletions that treat words this way.  This is also handled by adding a
>   few new ZLE builtins, and relies on isupper() to detect upper case, so
>   it may behave differently in different language locales.
> 
>   My first inclination was to think that this should be handled with the
>   WORDCHARS variable, but of course WORDCHARS adds other characters that
>   are treated as alphanumeric; there's no way to say that upper case
>   letters should -not- be treated as alphanumeric.  I guess I'd prefer a
>   patch that handled wordchar-exlusions more generically (without adding
>   builtins) and I may even look at adding such a thing.
> 
>   For this patch to go into 3.0.6, I'd want PWS to agree that the new ZLE
>   builtins would appear in 3.1.6, too.

Well, in 3.1 you can do more sophisticated things by altering $CURSOR with
widgets already, so new builtins are not really necessary.  Furthermore,
getting a complete set of functions with this alternative word behaviour
looks a slightly wasteful way of doing it (and if it's an incomplete set of
functions, I guarantee it won't have the one you want).

But it would be nice to have some advance on $WORDCHARS, which has always
frustrated me (I always wanted to be able to specify characters which
*shouldn't* be parts of words, since $WORDCHARS is too long for me to see
easily what's not in it --- and how else can I tell the code that only
spaces should delimit words; and why does the default include =, - and /
but not +; parentheses but not |?  Etc.).

Perhaps the solution to the problem in question is to add a variable
$WORDSTART giving a list of characters with this behaviour, and the
corresponding macro iwords().  It could allow ranges, so you can add "A-Z";
the change to inittyptab() to allow that isn't too drastic --- the change
to zle_word.c is the hairy one.  That's less sophisticated w.r.t. locales,
unfortunately; you'd have to add ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ by hand,
which is a little unpleasant.  An alternative is to allow A to stand for
all upper case, 1 for all digits, etc; or to allow escape sequences, so \\
-> backslash, \U -> uppercase, etc (that's perhaps the neatest).  I don't
see an easy way of avoiding a new variable by enhancing $WORDCHARS, since in
principle anything can appear in that.  You could, say, have a list of
possible initial characters after two spaces, but it's a bit of a mess.

Perhaps, if my frustrations above are widespread, there's room for a
variable $NONWORDCHARS, too.  That's easy to add: by default it's not set,
and if it is it takes precedence over $WORDCHARS in inittyptab() so that
anything not in it is made a word character; no editing code needs to
change.  Can this be made to the job of $WORDSTART?  It seems to me not,
since forward-word puts the cursor *after* the non-word character, which
isn't what you want with special initial characters (they're behaving more
like special final characters, in fact).

-- 
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: Call for opinions on a couple of prospective zsh patches

[Bart Schaefer]

On Jun 6,  4:13pm, Peter Stephenson wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} "Bart Schaefer" wrote:
} > * Partial word motions in the face of mixed case, i.e. move the cursor to
} >   the next/previous capital letter InMixedCaseWordsLikeThisOne, including
} >   deletions that treat words this way.
} 
} Well, in 3.1 you can do more sophisticated things by altering $CURSOR with
} widgets already, so new builtins are not really necessary.  Furthermore,
} getting a complete set of functions with this alternative word behaviour
} looks a slightly wasteful way of doing it (and if it's an incomplete set of
} functions, I guarantee it won't have the one you want).

Looking at it more closely, I see that Greg didn't supply backward motion,
only forward motion and both forward and backward deletion.  It wouldn't
be difficult for me to add backward motion.

However, as you point out:

} ... forward-word puts the cursor *after* the non-word character ...

and so does backward-word; both assume that there is at least one non-word
character between words, which isNotTheCaseHere.  So a simple change for
something like WORDCHARS would leave the cursor in the wrong place on
every motion.

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

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

[Bart Schaefer]

On Jun 6,  4:13pm, Peter Stephenson wrote:
}
} But it would be nice to have some advance on $WORDCHARS, which has always
} frustrated me (I always wanted to be able to specify characters which
} *shouldn't* be parts of words [...]).
} 
} Perhaps, if my frustrations above are widespread, there's room for [...]

I've had this message sitting in my editor for three days now trying to
decide what to say about it.  I share some of your frustrations; I always
forget that WORDCHARS doesn't mean the opposite of what it does until I
actually want to try something with it, and then I get annoyed.

My biggest complaint is that I always want {,backward-}kill-word to treat
path components as separate words, but I usually want transpose-words to
treat entire paths as a single word.  (I tried vi-backward-kill-word, but
it stops both before and after killing each individual / character, which
drives me nuts.)  Yes, in 3.1.5-pws-* I can rewrite the widgets to do it,
but it's always seemed that it ought to be easier.  (Now that I've said
that, I note that it's probably off-topic.)

Anyway, the reason I've been staring at this for so long without answering
is that, though your WORDSTART and NONWORDCHARS suggestions are reasonable,
there's something about that approach that doesn't feel quite right.  The
trouble is, I can't think of anything better without resorting to full-
blown regular expressions (or at least glob patterns) after the manner of
emacs.

The gist is that I'm with you, but not in a very helpful way just yet.

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

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

[Stefan Monnier]

>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> My biggest complaint is that I always want {,backward-}kill-word to treat
> path components as separate words, but I usually want transpose-words to
> treat entire paths as a single word.  (I tried vi-backward-kill-word, but

Somewhat agreed (except I don't agree with the particular split).
In Emacs, this is solved by having

	backward-word
and
	backward-sexp

The <foo>-sexp manipulation commands would be great.


	Stefan

Re: WORDCHARS, etc.

[Peter Stephenson]

"Bart Schaefer" wrote:
> Anyway, the reason I've been staring at this for so long without answering
> is that, though your WORDSTART and NONWORDCHARS suggestions are reasonable,
> there's something about that approach that doesn't feel quite right.  The
> trouble is, I can't think of anything better without resorting to full-
> blown regular expressions (or at least glob patterns) after the manner of
> emacs.

I've had this sort of worry, too.  Maybe there's room for defining new
flags for commands, telling it (say) whether to use space-separated words
instead of WORDCHARS-defined words, which might be handled by some sleight
of hand in the macro used in zle_word, i.e. instead of testing iword() we
test !inblank() (we're approaching the limits of type flags possible with a
short if we need more).  The syntax might be that you defined a new widget
using `zle', but in a way that made it use an existing builtin function
just with those extra flags.  That would reduce the hassle to one zle and
one bindkey command.  I think this could even be done quite easily with zle
-A, where you allowed the thingy to store ZLE_* flags and used the
appropriate part of the set to override the ones in the widget (non-zle
hackers are not expected to understand that sentence). So, for example

zle -Ab transpose-words transpose-space-words

(b for blank, since it allows tab and newline too) would define a command
transpose-space-words which acts exactly the same way as transpose-words
but words are delimited by blanks.

Aliases for using uppercase-delimited words could use the same mechanism
(combined with $WORDSTART, if necessary), say `zle -As ...' (confusion
becuase b = blank or beginning, s = space or start, but I didn't invent
this crazy language).  However, that would still require rather more
surgery in zle_word.c (and in this case presumably implies the new
word-delimiters are supplementary to the usual set, so -s could be combined
with -b).

Maybe we could even use get_comp_string() to decide where the beginning of
the current syntactic word is, and hence allow a flag for that too
(particularly now it knows where the start of a string is), but I don't
think I want to contemplate full sexp handling this side of the millenium
(3001, I mean).

-- 
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: Call for opinions on a couple of prospective zsh patches

[Stefan Monnier]

>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> * Completion using "dynamic abbreviations" after the manner of the emacs
[...]
> * Partial word motions in the face of mixed case, i.e. move the cursor to
[...]
> * Support for the LS_COLORS environment string, to colorize file names in

I think adding anything to 3.0 is a mistake.  We should instead hurry to
get 3.2 out the door.  3.1.x has too many neat features that most people don't
get to use since RedHat and friends only come with 3.0.5.

Adding any of the three to 3.1 makes sense, but to 3.0 ?
I really wish the next 3.1.x were called 3.2.0.


	Stefan

PS: GNU ls's LS_COLORS code is brain dead:  if you want to include it at least
    try to fix it so that its auto-detection of color capability is a bit less
    pathetically optimistic (trying to colorize the output when TERM=dumb
    is ...well... dumb!)

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

[Adam Spiers]

Stefan Monnier (monnier+lists/zsh/users/news/@tequila.cs.yale.edu) wrote:
> I think adding anything to 3.0 is a mistake.  We should instead hurry to
> get 3.2 out the door.  3.1.x has too many neat features that most people don't
> get to use since RedHat and friends only come with 3.0.5.
> 
> Adding any of the three to 3.1 makes sense, but to 3.0 ?
> I really wish the next 3.1.x were called 3.2.0.

I'm no zsh developer really so my opinion shouldn't count for much,
but I'm with Stefan here.  3.0.x is really quite old now and I know
that there is some really nice stuff in 3.1.x which I would rather see
released in stable form at the expense of maintaining 3.0.x.  Then
again, it may be that there's still a while to go before 3.1.x
approaches stability?  In which case, forget everything I said :-)

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

[Bart Schaefer]

On Jun 6,  6:13pm, Adam Spiers wrote:
} Subject: Re: Call for opinions on a couple of prospective zsh patches
}
} 3.0.x is really quite old now and I know that there is some really nice
} stuff in 3.1.x which I would rather see released in stable form at the
} expense of maintaining 3.0.x.

We've got separate people maintaining the two releases now, so there's
little conflict in keeping both updated.

} Then again, it may be that there's still a while to go before 3.1.x
} approaches stability?

There's a lot of very new stuff in 3.1 now which hasn't had exposure except
to the developers list, so there probably is a while to go.  One concern is
to get out a Y2K-fixed 3.0 to be included in various linux releases etc.
before 3.2 reaches fruition.

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

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

[Stefan Monnier]

>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:
> We've got separate people maintaining the two releases now, so there's
> little conflict in keeping both updated.

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 ?
The 3.0.x line should be restricted to bug-fixes.  Just like 3.2.x will be.

> 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.


	Stefan

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

[Bart Schaefer]

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

Re: WORDCHARS, etc.

[Sven Wischnowsky]

Peter Stephenson wrote:

> I've had this sort of worry, too.  Maybe there's room for defining new
> flags for commands, telling it (say) whether to use space-separated words
> instead of WORDCHARS-defined words, which might be handled by some sleight
> of hand in the macro used in zle_word, i.e. instead of testing iword() we
> test !inblank() (we're approaching the limits of type flags possible with a
> short if we need more).  The syntax might be that you defined a new widget
> using `zle', but in a way that made it use an existing builtin function
> just with those extra flags.  That would reduce the hassle to one zle and
> one bindkey command.  I think this could even be done quite easily with zle
> -A, where you allowed the thingy to store ZLE_* flags and used the
> appropriate part of the set to override the ones in the widget (non-zle
> hackers are not expected to understand that sentence).

The more I read about this the more I think that we should just go
ahead and allow all zle widget functions to get (an arbitrary number
of) arguments (strings). If no arguments are given, the function uses
its defaults. We could than probably have a couple of generic
functions (e.g. for word movement) and define aliases to them with
fixed arguments (as Peter suggested with flags), probably even for
some of the functions that are currently real builtin widgets.

I mean, we were talking about allowing arguments for the search-
functions anyway, so why not use it it many more places.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de