Zsh Mailing List Archive
Messages sorted by:
Re: Oh my God! They killed completion! YOU BASTARDS!
- X-seq: zsh-workers 3942
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Andrew Main <zefram@xxxxxxxxx>, pacman@xxxxxxx, zsh-workers@xxxxxxxxxxxxxxx
- Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
- Date: Thu, 7 May 1998 09:39:39 -0700
- In-reply-to: <199805070858.JAA01558@xxxxxxxxxxxxxxxx>
- References: <199805070858.JAA01558@xxxxxxxxxxxxxxxx>
On May 7, 9:58am, Andrew Main wrote:
} Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
} pacman@xxxxxxx 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
Bart Schaefer Brass Lantern Enterprises
Messages sorted by: