From: "Bart Schaefer" <schaefer@brasslantern.com>
To: Andrew Main <zefram@tao.co.uk>,
pacman@cqc.com, zsh-workers@math.gatech.edu
Subject: Re: Oh my God! They killed completion! YOU BASTARDS!
Date: Thu, 7 May 1998 09:39:39 -0700 [thread overview]
Message-ID: <980507093939.ZM18315@candle.brasslantern.com> (raw)
In-Reply-To: <199805070858.JAA01558@taos.demon.co.uk>
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
next prev parent reply other threads:[~1998-05-07 16:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-05-07 5:14 pacman
1998-05-07 8:58 ` Andrew Main
1998-05-07 16:39 ` Bart Schaefer [this message]
1998-05-07 16:47 ` Andrew Main
1998-05-17 1:58 ` TGAPE!
1998-05-17 9:19 ` Bart Schaefer
1998-05-18 5:12 ` Zoltan Hidvegi
1998-05-07 18:45 ` pacman
1998-05-08 8:59 ` Andrew Main
1998-05-07 18:08 ` Andrew R. Large
1998-05-07 9:30 Sven Wischnowsky
1998-05-07 9:59 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=980507093939.ZM18315@candle.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=pacman@cqc.com \
--cc=zefram@tao.co.uk \
--cc=zsh-workers@math.gatech.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).