Re: zsh-3.0-pre4 released

[Zefram <A.Main@xxxxxxxxxxxxxxxxx>]

>Actually, I'd say the biggest change is "setopt nofoo" == "unsetopt foo".
>Which I still think should have been left out until some post-3.0 version.

Why?  It breaks nothing except for scripts that try to detect options
being set by doing `setopt | grep foo`, which is broken anyway.  The
old names still work in [[ -o nofoo ]].

>I must say, having an option called BAD_PATTERN feels rather odd to me.
>Since we have IGNORE_BRACES, either we should have IGNORE_BAD_PATTERN,
>or else we should have just BRACES.  Or it should have been left alone.
[more like this]

Yes, I thought so too.  However, a "no" prefix is the prevalent way of
negating option sense, so I added support for that only.  To change
IGNORE_BRACES to NO_BRACES (i.e. a negated BRACES) would break backward
compatibility, unless there is some way to support the old name.

I do plan to write a patch to add exactly such a mechanism.  As it will
no doubt be somewhat controversial, I'll describe it now for people to
tear apart:

The general idea is that we have a list of fixed option `aliases',
which provide alternative names for certain options.  The list itself
would look something like

    {"ignorebraces", -BRACES},
    {"trackall", HASHCMDS},

The "trackall" entry provides a ksh name for the equivalent zsh
option.  The "ignorebraces" entry provides backward compatibility, in
the hypothetical situation that we decide that "braces" is a better
name.  I wouldn't make that type of change when adding the mechanism,
but would only do some ksh compatibility names.

The aliased names would be handled by optlookup(), with essentially no
changes required anywhere else.  In fact, I'd probably make the list
itself local to optlookup().  This flexibility, to add new types of
option name, is one of the reasons I added the optlookup()
abstraction.

I'd like to know what people think of this idea.  In particular,
Zoltan, would you allow such a patch into the baseline?

-zefram