Oh my God! They killed completion! YOU BASTARDS!
Andrew Main
pac...@cqc.com wrote:
>I must object to the changes to completion behavior in zsh 3.1 as opposed to
>the previous versions. First, on the matter of LIST_AMBIGUOUS, I would
>suggest that if you're going to add a new option that dramatically alters
>some existing rules that people have been been using for a long time, at the
>very least you shouldn't turn it on by default!
There was a policy decision made in 3.1.1 that, generally speaking, the
clever interactive options should be enabled by default. It does change
the default behaviour, but it doesn't affect scripts (where compatibility
really matters), and the new behaviour is usually preferred.
> If I _wanted_ to use a new option, I'd like the chance to read
>about it first, and then turn it on if it sounds like a good idea.
The Etc/NEWS file does list new options. These options being on by
default isn't listed, but this is a beta version, and it is listed in
the ChangeLog.
>particular option, I think, is not a good idea, and I don't appreciate having
>it forced upon me by a new default setting. Please, let's have a little
>backward compatibility.
Possibility for zsh-workers: should `emulate' have the capability to
emulate earlier zsh versions? So `emulate zsh-2.3' would turn off
LIST_AMBIGUOUS and so on.
>17:01 6 londo /home/pacman/src %echo $ZSH_ <--\
>ZSH_NAME ZSH_VERSION |
> /---------------/
>My cursor is sitting HERE! --/ WHAT THE HELL IS THAT?
ALWAYS_LAST_PROMPT. One of my favourite features. It means that you
don't waste screen space with old completion lists -- new lists visibly
replace the old one -- and the command line doesn't jump around, so
it's easier to keep your eyes on what you're editing. This has been
available since 2.5.
>This behavior is wrong. It's SO wrong.. The vastness of your wrongness here
>astounds me. All the languages in the world do not have enough words to
>adequately describe the degree of wrongness exhibited by zsh 3.1 completion.
I'm glad to see I'm not the only person that gets this emotional about
computer programs.
But ALWAYS_LAST_PROMPT is right. It's SO right. So vastly right that
having to use bash purees my brain when it puts the completion list in
the wrong place.
>This is like compiling a new version of vi, only to find out that it is an
>emacs clone.
Bad analogy. vi's popularity rests on having a simple and *complete*
interface. zsh has a history of adding cool and unusual features.
Surely you can't expect us to make no progress in this direction in
two years?
>And this, unlike the first issue, can't even be fixed by toggling an option.
"unsetopt alwayslastprompt".
>The description of ALWAYS_LAST_PROMPT is brief and confusing (how can a
>completion key be given an argument? What does that mean? Is that a numeric
>prefix?
Yes. In vi mode you'd have to fiddle with the key bindings to do it.
I doubt that anyone actually does this, though: just set the option the
way you want it.
>Secondly, there is stuff on the screen below the prompt. Being down there, it
>looks like it should be part of the command line I'm editing, but it isn't.
You'll get used to it, if you use it. I can understand how it might be
confusing when unexpected.
-zefram
Andrew Main
Bart Schaefer wrote:
>Maybe a better approach would be to distribute an autoloadable script
>that, when run, would report the differences between the current zsh and
>a specified previous version (default the last major release).
That's what Etc/NEWS is for. It needs to be updated for 3.1.
-zefram
Sven Wischnowsky
Andrew Main wrote:
>
> pac...@cqc.com wrote:
> >
> > ... [ about LIST_AMBIGUOUS being set by default...]
> >
> ...
>
This one confused me a bit, too, on my first TAB after the change
since I don't use it and missed the corresponding messages...
>
> Possibility for zsh-workers: should `emulate' have the capability to
> emulate earlier zsh versions? So `emulate zsh-2.3' would turn off
> LIST_AMBIGUOUS and so on.
>
Hm. That may result in pretty complicated code sometimes, if this is
not restricted to option settings. (Not that the current code is simple...;-)
> >17:01 6 londo /home/pacman/src %echo $ZSH_ <--\
> >ZSH_NAME ZSH_VERSION |
> > /---------------/
> >My cursor is sitting HERE! --/ WHAT THE HELL IS THAT?
>
> ALWAYS_LAST_PROMPT. One of my favourite features. It means that you
> don't waste screen space with old completion lists -- new lists visibly
> replace the old one -- and the command line doesn't jump around, so
> it's easier to keep your eyes on what you're editing. This has been
> available since 2.5.
>
> >This behavior is wrong. It's SO wrong.. The vastness of your wrongness here
> >astounds me. All the languages in the world do not have enough words to
> >adequately describe the degree of wrongness exhibited by zsh 3.1 completion.
>
> I'm glad to see I'm not the only person that gets this emotional about
> computer programs.
>
> But ALWAYS_LAST_PROMPT is right. It's SO right. So vastly right that
> having to use bash purees my brain when it puts the completion list in
> the wrong place.
>
Interesting... for some of the things I implemented, I always wondered
if people use it or even like it. ALWAYS_LAST_PROMPT was/is one of them.
Bye
Sven
--
Sven Wischnowsky wisc...@informatik.hu-berlin.de
Andrew R. Large
pac...@cqc.com (07 May 1998 at 00:14 GMT as "pac...@cqc.com") said:
>
> [Passionate diatribe deleted]
>
Sorry to waste a little bandwith for this, but I wanted to give the first
few respondents to this message some major kudos.
To me, the original message sounded a bit like an attempt to start a flame
war. Rather than responding in kind or castigating the fellow for poor
manners, you all responded very professionally. Rare to see these days in
Internet forums, and highly appreciated.
[And yes, for the record, I like the feature Mr. pacman was complaining
about]
--
-=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Andrew Large | Sun Microsystems, Inc.
andrew...@eng.sun.com | 901 San Antonio Road
(650) 786-6503 [office] | MS MPK18-209
(650) 786-4101 [fax] | Palo Alto, CA 94303-4900
-=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=-
Peter Stephenson
Sven Wischnowsky wrote:
> Andrew Main wrote:
>
> > Possibility for zsh-workers: should `emulate' have the capability to
> > emulate earlier zsh versions? So `emulate zsh-2.3' would turn off
> > LIST_AMBIGUOUS and so on.
> >
>
> Hm. That may result in pretty complicated code sometimes, if this is
> not restricted to option settings. (Not that the current code is simple...;-)
I'm afraid that's proably a fatal flaw with this, nice as it would be.
If you have an emulate zsh-X, people are going to assume it does what
its name suggest, rather than just change the options. Probably a
clear list of changes in default options, maybe in the documentation
as well as the news file so that it's available to users on most
right-thinking systems, would be enough --- people just want to set
them once in their .zshrc. Then we can avoid *too* many messages
demonstrating passionate attachment to options...
--
Peter Stephenson <p...@ifh.de> Tel: +39 50 844536
WWW: http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy
Bart Schaefer
On May 7, 9:58am, Andrew Main wrote:
} Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
}
} pac...@cqc.com wrote:
} >I must object to the changes to completion behavior in zsh 3.1 as opposed to
} >the previous versions. First, on the matter of LIST_AMBIGUOUS, I would
} >suggest that if you're going to add a new option that dramatically alters
} >some existing rules that people have been been using for a long time, at the
} >very least you shouldn't turn it on by default!
I'm surprised nobody has pointed out that LIST_AMBIGUOUS has been an option
for several versions now. What changed was its default setting.
} There was a policy decision made in 3.1.1 that, generally speaking, the
} clever interactive options should be enabled by default. It does change
} the default behaviour, but it doesn't affect scripts (where compatibility
} really matters), and the new behaviour is usually preferred.
I'm not sure if this is a problem for LIST_AMBIGUOUS (I haven't installed
3.1.4 yet) but we should be careful that a new default setting is not going
to adversely affect other options that may be set in the user's .z* files.
For example, if we were to make AUTO_MENU a default, people who normally
set MENU_COMPLETE would be in for a nasty surprise.
} > If I _wanted_ to use a new option, I'd like the chance to read
} >about it first, and then turn it on if it sounds like a good idea.
}
} The Etc/NEWS file does list new options.
Which doesn't help for either of LIST_AMBIGUOUS or ALWAYS_LAST_PROMPT,
because they aren't new.
} >particular option, I think, is not a good idea, and I don't appreciate
} >having it forced upon me by a new default setting. Please, let's have
} >a little backward compatibility.
}
} Possibility for zsh-workers: should `emulate' have the capability to
} emulate earlier zsh versions?
Maybe a better approach would be to distribute an autoloadable script
that, when run, would report the differences between the current zsh and
a specified previous version (default the last major release).
Alternately/additionally, have a script that would search the PATH for
older versions of zsh (`make install` usually leaves old versions behind
as zsh-x.y.z), allow the user to pick one, and generate on stdout a list
of setopt commands the user might want to add to his .zshrc, e.g., by
comparing the output of "setopt" from the old version to the current
one.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Andrew Main
pac...@cqc.com wrote:
> Even ^R and ^L treat the completion list as if it was
>part of the command line! Ugh!
I was rather proud of that addition, actually.
>With automenu on, echo $ZSH_<TAB><TAB> shows ZSH_NAME with a slash after it.
>Why's that?
That's AUTO_PARAM_SLASH. It adds a slash after a parameter name if the
parameter's value happens to be the name of a directory. Not really
appropriate with ZSH_NAME, but the slash will go away quite readily if
you have AUTO_REMOVE_SLASH set.
-zefram