Re: Oh my God! They killed completion! YOU BASTARDS!

Re: Oh my God! They killed completion! YOU BASTARDS!

[Sven Wischnowsky]

Andrew Main wrote:

> 
> pacman@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                         wischnow@informatik.hu-berlin.de

Re: Oh my God! They killed completion! YOU BASTARDS!

[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 <pws@ifh.de>       Tel: +39 50 844536
WWW:  http://www.ifh.de/~pws/
Gruppo Teorico, Dipartimento di Fisica
Piazza Torricelli 2, 56100 Pisa, Italy

Re: Oh my God! They killed completion! YOU BASTARDS!

[Zoltan Hidvegi]

TGAPE! <tgape@cyberramp.net> wrote:
> > That's what Etc/NEWS is for.  It needs to be updated for 3.1.
> 
> Documentation's great.  So, who in this group is a documentation
> fanatic?  No one, I see.  That would explain why the documentation is so
> friggin out of date.  Of course, the fact that the documentation is

You can help if you have time.  People develop zsh in their free time for
fun, and it looks like most of them find more fun in coding than in
documentation.  The main documentation, the manual is kept up to date,
and you can get a very nice printed documentation from the texinfo
version.  It's more than a hundred page long with nice indexes and table
of contents.  It's worth reading, even experienced developers can learn
from it.  Unfortunately it is too long and written in the usual Unix
manpage style language which is sometimes hard to read for inexperienced
users.

> Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be

ChangeLog is not for the users, it is a log for the developers.  Etc/NEWS
is updated for major releases, but it may lag behind the changes during
the development.  Note that 3.1 is beta, it is under development, and
noone guarantees that it'll work as you expect.  If you chose to use beta
software, you should be prepared for surprises.  The announcement on
zsh-announce did describe the changed options.

> person affected.  When one of my friends upgrades zsh on his machine,
> there are dozens affected, many who aren't necessarily observant enough
> to realize 'Hey, a shell upgrade occurred, and zefram's done an annoying
> default option change on me on some option I'm completely unfamiliar
> with because I immediately dismissed it as a bad idea.'  I've heard
> there's someone at work who can do this to hundreds, and I've seen ISPs
> where they could potentially do it to thousands.

First it was not Zefram but me who changed this with the approval from
most of the people reading zsh-workers at that time.  And if a system
administrator installs a beta software for dezens or maybe thousans of
users, he should have a good reason and then he probably knows how to
handle these issues.  He can set up /etc/zshenv to set the option
preferred by the users.  The default options were changed to make the
shell more usable without playing with options.  Many users did not even
know about these options since they never read the manual.  Of course the
choice of options is a matter of taste, but there seemd to be a consensus
here on the new set.

> people to mention I have little sense.  Still, I agree with him that it
> shouldn't be default.  Just because it's useful doesn't mean that it
> should be set as a trap to the unwary; most people who start using zsh
> are used to other shells which don't do that.

But most people start using zsh exactly because it does things that other
shells don't.  Actually ALWAYS_LAST_PROMPT was one of the main reasons I
started using zsh.  When I saw this behavior, I saw the light :-).

Zoltan

Re: Oh my God! They killed completion! YOU BASTARDS!

[Bart Schaefer]

On May 17,  1:58am, TGAPE! wrote:
} Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
}
} Andrew Main wrote:
} > 
} > 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.
} 
} Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be
} longer than many people wish to read before starting to use the new
} shell, as well as frequently being too terse [...] to be of much use
} anyway - they generally assume that the new program'll work the same as
} their old version, except for bug fixes, until they play with the new
} options.

This is exactly why I generally object so much when changes are made that
are not "backwards compatible."  A shell isn't like other applications --
if it doesn't start up properly because it can't parse your init files,
you may not even be able to log in; and if it does start, but behaves in
an unexpected way, it can waste many hours (and in extreme cases cause
loss of data) before sanity is restored.  This is not to say that any of
the 3.1.x changes have those effects, just to emphasize that care should
be taken when changing behaviors.

} When one of my friends upgrades zsh on his machine,
} there are dozens affected, many who aren't necessarily observant enough
} to realize 'Hey, a shell upgrade occurred, and zefram's done an annoying
} default option change on me on some option I'm completely unfamiliar
} with because I immediately dismissed it as a bad idea.'  I've heard
} there's someone at work who can do this to hundreds, and I've seen ISPs
} where they could potentially do it to thousands.

And it is often the case that when such an upgrade is done, the Etc/NEWS
and other auxiliary doc files aren't installed in any public place, so
those poor users can't read them even if they are so inclined.

I'm no longer the "zsh admin" for any significant group of people, but
I was for a while, and starting with about version 2.4 I always had to
dump a bunch of stuff in /etc/zshenv to be sure zsh continued to behave
the way everyone expected.  I'd bet admins assume that isn't necessary.

} I'd suggest rather than an emulate version, just a detect version, like
} vim has - when vim changes significantly, anyone who is used to the old
} version gets a comment about how their .vimrc file is for an older
} version, and would they please read about the changes.

This is why I suggested a script that would report differences; sysadmins
could set it up to run when the new version is first started up.  None of
zsh's startup files are suitable for version tagging because zsh has no
business rewriting them (except the .zhistory, which may be turned off),
so I can't advocate version detection as a built-in, but it could be done
in a sample /etc/zshenv or something.

} I personally wasn't affected by this one, as I happen to be paranoid -
} my .zlogin file sets all options the way I want them; if the default is
} what I want, I still set it that way.  Not everyone is as looney as
} myself, however.

I have conditionals for every version of zsh back to about 2.0 to figure
out which options are available and set them appropriately to keep things
working as consistently as possible.  Some of those branches haven't been
executed since 1994, but I figure if I take them out then I'll forget to
fix something the next time some option or other gets revised.

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

Re: Oh my God! They killed completion! YOU BASTARDS!

[TGAPE!]

Andrew Main wrote:
> 
> 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.

Documentation's great.  So, who in this group is a documentation
fanatic?  No one, I see.  That would explain why the documentation is so
friggin out of date.  Of course, the fact that the documentation is
actually spread out between so many files probably contributes to it; I
usually find that at least the manpages are current, which is a good
thing.  The others - I've learned to mostly ignore them, they too rarely
have the right information for the problems I look at them for.  This is
at least better than at work, where I find talking to the author is
frequently the only way to go, as the documentation was last updated in
'96, and the code last updated last month.  (Ok, exaggeration - month and
a half ago, and it was December '96.)

Etc/NEWS (or ChangeLog, or whatever) has the problem that it tends to be
longer than many people wish to read before starting to use the new
shell, as well as frequently being too terse (this isn't a
contradiction, rather a statement of human nature) to be of much use
anyway - they generally assume that the new program'll work the same as
their old version, except for bug fixes, until they play with the new
options.  This is a good thing, especially on machines which have
multiple users - when I upgrade zsh on my machine, *I* am the primary
person affected.  When one of my friends upgrades zsh on his machine,
there are dozens affected, many who aren't necessarily observant enough
to realize 'Hey, a shell upgrade occurred, and zefram's done an annoying
default option change on me on some option I'm completely unfamiliar
with because I immediately dismissed it as a bad idea.'  I've heard
there's someone at work who can do this to hundreds, and I've seen ISPs
where they could potentially do it to thousands.

I'd suggest rather than an emulate version, just a detect version, like
vim has - when vim changes significantly, anyone who is used to the old
version gets a comment about how their .vimrc file is for an older
version, and would they please read about the changes.  Anyone who
doesn't have a version tag in their configuration file is obviously
using an older version.  At work, I control the upgrades for vim, and
there are about half a dozen people who use it.  So far, I've never had
a complaint about unexpected changes due to an upgrade.

I personally wasn't affected by this one, as I happen to be paranoid -
my .zlogin file sets all options the way I want them; if the default is
what I want, I still set it that way.  Not everyone is as looney as
myself, however.  I personally use the feature Alan castigated as the
worst idea ever thought of, but then he'd probably be one of the first
people to mention I have little sense.  Still, I agree with him that it
shouldn't be default.  Just because it's useful doesn't mean that it
should be set as a trap to the unwary; most people who start using zsh
are used to other shells which don't do that.

(Btw, yes, I would find it more convenient if my compctl lines didn't
have to include every friggin completion.  Course, not trusting you
guys, I probably still wouldn't be lazy and remove the redundant ones.)

And, Alan, the emacs call was highly out of line - if they made this
change in emacs style, to use it, you'd have had to type
Esc-xcomplete-word-and-move-the-cursor-to-the-line-the-previous-prompt,
which of course can only be feasibly typed by pressing tab an
inordinante number of times, to distinguish it from complete-line,
complete-word-and-enter, complete-word-and-move-the-mouse-randomly,
complete-word-and-move-the-cursor-to-the-top-of-the-screen, and other
such blatherskite.  If they ever do try something like this to zsh I
will agree that they should be drawn, quartered, shot, flayed, salted,
filleted, burned at the stake, and beheaded (but otherwise treated with
respect, unlike Our Friend Bill).  I do feel that, considering what the
list of things to bind keys to, Kenny is in danger.  Hopefully, this is
a Christmas show...

--\Grimm, tgape@bigfoot.com
Ed|-----BEGIN GEEK CODE BLOCK-----
 A|Version: 3.1
lv|GS/CS/O/>AT PS+-->? PE++()>? Y+-->? PGP->- G++(-) t+--- s+:- c++++$ K
in|N(++) b++(++++) d+$(-) 5 O- !tv-- !E---$>? ULIBS(VUCX)+$(++++$)>++++$
 G|R(-)* V--$ a->970(?) w---($)>----!? W--()(-)>? P++-- C++$(---)(>?) >o
ri|X-->? y+-*>++++** M-$>? D++--- DI++++>$ e++* h+* r--%*>+++ L+++>++++$
mm|------END GEEK CODE BLOCK------

Re: Oh my God! They killed completion! YOU BASTARDS!

[Andrew Main]

pacman@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

Re: Oh my God! They killed completion! YOU BASTARDS!

[pacman]

Andrew Main wrote:
>
>pacman@cqc.com wrote:
>
>There was a policy decision made in 3.1.1 that, generally speaking, the
>clever interactive options should be enabled by default.

For new features, that might make sense. For things which are variations on
an existing feature, I'm not so sure.

>                                                          It does change
>the default behaviour, but it doesn't affect scripts (where compatibility
>really matters), and the new behaviour is usually preferred.

It broke a script in my head, which says "Left little finger pushes tab. Eyes
move to bottom of screen to find cursor". My brain-script has been working
that way since zsh 2.5 or so, and before that, it worked that way with tcsh.

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

OK, now I have a roadmap for upgrade: read that new option list and then
check their description, and turn them off if you're married to the old
behavior.

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

You make it sound so nice, but I'm really used to knowing that everything
after my prompt is part of the command I'm typing. Considering multi-line,
ZLE, there really is no clear separator between what is part of the command
line, and what is just some other stuff after it, except that you can't move
the cursor down there. Even ^R and ^L treat the completion list as if it was
part of the command line! Ugh!

>
>I'm glad to see I'm not the only person that gets this emotional about
>computer programs.

You should have seen me. I was pounding my desk and straining to keep from
screaming.

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

That's funny, the first thing I thought when I saw it happen was "Oh no, this
must be some crazy bash feature. They're cloning bash now."

>
>"unsetopt alwayslastprompt".

What I tried was "setopt noalwayslastprompt" and it didn't seem to have an
effect. Of course now, after I complain about it, it does. I should have
saved the history from that test, because now I'll never know what was
happening. OK, I'll revise my complaint: FAQ 4.3, which lists all the
completion-related options, doesn't have alwayslastprompt.

>You'll get used to it, if you use it.  I can understand how it might be
>confusing when unexpected.
>

Quite.

More minor things I noticed while playing around:

With 3.0, there is a default compctl for setopt itself. In 3.1, it seems to
be gone. What do I have to do, pick apart the compctl example file and add
lots of stuff to /etc/zshrc, just to make 3.1 catch up with 3.0's default
completion awareness?

With automenu on, echo $ZSH_<TAB><TAB> shows ZSH_NAME with a slash after it.
Why's that?

-- 
Alan Curry

Re: Oh my God! They killed completion! YOU BASTARDS!

[Andrew R. Large]

pacman@cqc.com (07 May 1998 at 00:14 GMT as "pacman@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.large@eng.sun.com  |   901 San Antonio Road
  (650) 786-6503 [office]   |      MS MPK18-209
    (650) 786-4101 [fax]    | Palo Alto, CA 94303-4900
-=*=-=*=-=*=-=*=-=*=-=*=-=*=+=*=-=*=-=*=-=*=-=*=-=*=-=*=-

Re: Oh my God! They killed completion! YOU BASTARDS!

[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

Re: Oh my God! They killed completion! YOU BASTARDS!

[Bart Schaefer]

On May 7,  9:58am, Andrew Main wrote:
} Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
}
} pacman@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

Re: Oh my God! They killed completion! YOU BASTARDS!

[Andrew Main]

pacman@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

Oh my God! They killed completion! YOU BASTARDS!

[pacman]

Oh my God! They killed completion! YOU BASTARDS!

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! The principle of least
astonishment has been grossly violated here. I have spent considerable time
in the past fixing up my shell stratup files to get the thing to behave like
I want it to. 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. This
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.

And it gets worse than that. In listing completions, zsh is now doing
something really stupid. I type "echo $ZSH_<TAB>" (with autolist turned on)
and what happens?

17:01 6 londo /home/pacman/src %echo $ZSH_ <--\
ZSH_NAME     ZSH_VERSION                      |
                              /---------------/
My cursor is sitting HERE! --/ WHAT THE HELL IS THAT? Who did this? Some
anti-zsh person must have infiltrated the development group and sabotaged it.
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.
If shells were rated on a scale of 1=right (zsh 3.0) to 10=wrong
(COMMAND.COM), zsh's giant step backwards from 3.0 to 3.1 would earn it a
rating equal to the number of atoms in the universe.

This is like compiling a new version of vi, only to find out that it is an
emacs clone.

And this, unlike the first issue, can't even be fixed by toggling an option.
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? Hello! Is anybody home? Completion bindings generally don't exist in
vi command mode, and numeric prefixes generally don't exist in insert mode),
but I tried turning it on and off, and it had no effect that I could see.

Why do I consider this behavior wrong? Well, first, it's a shocking and
virtually undocumented change in default behavior, which can't be good.
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.

Please, undo this horrible thing. Put the prompt back at the bottom of the
screen where it belongs.

-- 
Alan Curry
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d? s++:-- a-- C++ UB+++L++++ P+ L+++>++++ E--- W-- N++ o K? w--- O? M--
V? PS+ PE+ Y+ PGP-(--) t* 5++ X+++ R- tv++ b-- DI- D++ G+++ !e h! r-->+++ y?
------END GEEK CODE BLOCK------