Re: zsh-3.0-pre4 released

[Zefram <A.Main@xxxxxxxxxxxxxxxxx>]

>What I do consider important is the confusion from the introduction of a
>large number of new options -- which is what it looks like to anyone who
>simply glances at the output of "setopt"; and which it is, syntactically
>at least, although less so semantically.

I've been using the `new options' (slightly) longer than anyone else
(how's that for brag value :-)), and while I agree that it is initially
a little disconcerting, I find that I prefer the cleaner setopt
output.  I also find that the testing of options is a little clearer in
general, in the code.  (The option patch actually normalised all option
tests to either isset(FOO) or unset(FOO).)

>Further, although I'm extremely happy about the attention that was paid
>to backwards compatibility, I can only repeat how uncomfortable I am
>about options that end up named BAD_PATTERN, EQUALS, EXEC, HUP, RCS, and
>UNSET.  What does "setopt unset" look like to you?

Confusing.  However, I do prefer unset(UNSET) to isset(NOUNSET).

>                                                    Why shouldn't "nohup"
>parallel the command prefix of the same name?

It does.

>At least with the NO_ prefix, you could tell that there is some expected
>behavior that is being modified.

True, that's how the options used to work, but what is the "expected
behaviour"?  It varies depending on whether we're emulating sh, ksh,
csh, zsh, (when we get round to it) POSIX, or whatever.  Not to mention
that not even all the non-special options defaulted to off anyway,
IIRC.

>BTW, while I'm on the subject, I'd like to throw in my vote for changing
>SH_FILE_EXPN to KSH_FILE_EXPANSION.  Besides being, as Zefram pointed out,
>more a ksh than sh thing, spelling out the "expansion" is no longer than
>ALWAYS_LAST_PROMPT, and I think we should avoid unnecessary abbreviations.

Partially agreed.  When I produced that patch I used SH_FILE_SUBST, in
order to avoid excessive length but also avoid a cryptic abbreviation;
I guess a full "expansion" is fine.  But whether it's sh or ksh makes
little difference, as both behave the same way in this regard.

>("What does the Revision Control System have to do with my init files?")

That one had me stumped for a while.

>braceccl            (what's a CCL, anyway?)

Character CLass?  I think this one needs changing; how about
BRACE_CHARS?  Does anyone have a better idea?

>histnostore

Should be HIST_STORE.

>nobadpattern

BAD_PATTERN currently means "complain about malformed patterns".  I
can't immediately come up with a better name.

>nobanghist

Again, I don't see a better name.  There's history regardless of this
option -- it only enables the bangchar form.  (Admittedly not always a
!, but how else can one describe this?)

>norcs               (IGNORE_RC_FILES, perhaps?)

RC_FILES, meaning what RCS currently does.

>nounset             (NULL_UNSET, ala NULL_GLOB?)

Yes, NULL_UNSET is much clearer.  Currently we have UNSET meaning
"complain about unset parameters", and its negation isn't exactly
obvious.

Other possibilities: EXTENDED_GLOB should be ZSH_GLOB; RM_STAR_SILENT
should be negated to RM_STAR_WARNING (note that changing the default
behaviour is a separate issue); SHIN_STDIN should be STDIN or something
less cryptic; HIST_ALLOW_CLOBBER should be HIST_ADD_CLOBBER (that's
what it does); IGNORE_BRACES has already been discussed; NOMATCH should
be clearer; RC_EXPAND_PARAM arguably should be RC_ARRAYS; REC_EXACT
should be RECOGNISE_EXACT or ACCEPT_EXACT_MATCH or similar.

-zefram