zsh-workers
 help / color / mirror / code / Atom feed
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


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