From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27672 invoked from network); 7 May 1998 09:07:16 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 May 1998 09:07:16 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id EAA09725; Thu, 7 May 1998 04:58:19 -0400 (EDT) Resent-Date: Thu, 7 May 1998 04:58:19 -0400 (EDT) From: Andrew Main Message-Id: <199805070858.JAA01558@taos.demon.co.uk> Subject: Re: Oh my God! They killed completion! YOU BASTARDS! To: pacman@cqc.com Date: Thu, 7 May 1998 09:58:16 +0100 (BST) Cc: zsh-workers@math.gatech.edu In-Reply-To: <19980507051403.11506.qmail@defiant.cqc.com> from "pacman@cqc.com" at May 7, 98 00:14:02 am X-Loop: zefram@tao.co.uk X-Phase: The Moon is Waxing Gibbous (85% of Full) X-Stardate: [-30]1116.86 X-US-Congress: moronic fuckers X-Headers: OTT X-Mouse: +++ ????? +++ Out Of Cheese Error. Redo From Start. X-Parrot: no, it's only resting. X-Personality: INTJ X-email-is-not-HTML: X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VgmQP2.0.uN2.gUNKr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3939 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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