From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12399 invoked from network); 7 May 1998 16:48:47 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 May 1998 16:48:47 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id MAA18753; Thu, 7 May 1998 12:43:02 -0400 (EDT) Resent-Date: Thu, 7 May 1998 12:43:02 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980507093939.ZM18315@candle.brasslantern.com> Date: Thu, 7 May 1998 09:39:39 -0700 In-Reply-To: <199805070858.JAA01558@taos.demon.co.uk> Comments: In reply to Andrew Main "Re: Oh my God! They killed completion! YOU BASTARDS!" (May 7, 9:58am) References: <199805070858.JAA01558@taos.demon.co.uk> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Andrew Main , pacman@cqc.com, zsh-workers@math.gatech.edu Subject: Re: Oh my God! They killed completion! YOU BASTARDS! MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"Y3KoM1.0.va4.LIUKr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/3942 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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