zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@u.genie.co.uk>
To: Zsh workers <zsh-workers@sunsite.dk>
Subject: Re: prefix-needed style in _popd
Date: Tue, 27 Mar 2001 22:16:29 +0100	[thread overview]
Message-ID: <3AC1032D.263705A8@u.genie.co.uk> (raw)
In-Reply-To: <1010327175637.ZM14146@candle.brasslantern.com>

Bart Schaefer wrote:

> This is actually what _mailboxes does ... it adds all possible matches,
> with + or @ or % or full paths or whatever ... I was wondering whether
> it ought to be testing prefix-needed, too.

It should really. As should _mh. Also, it seems that _mh acts as if
prefix-needed is true while _mailboxes acts like it is false. 

> Sven's patch to _popd makes it behave as if prefix-needed were true
> without actually testing the style any more, whereas _mailboxes behaves
> as if prefix-needed were false.  The inconsistency concerns me (but not
> very much).

We should probably agree on a consistent default for prefix-needed (and
quite possibly other styles). It is already `true' by default for
options which is the most significant thing which prefix-needed affects
so true is going to suprise the least people. On the other hand, there
is the argument that the default should be completeness and the styles
should be used to refine this down to what the user wants.

> I don't set prefix-needed at all, myself, but I don't understand the
> objection to the `false' behavior.  If you're used to typing a prefix,
> then you'll have typed one, and any listing will be restricted to the
> matches that have that prefix.  Is the issue that you don't want to
> see the possible completions that have a prefix when you complete with
> no prefix in the word on the line?

It is exactly what you describe at the end. I consider the completion
system to be as valuable for providing information as for "completing".
I now rarely use ls other than with -l, so I regularly press tab without
first typing a few letters. Without options in the list of completions,
it is often much easier to see what I want. I'm not even convinced that
I like having long options completed unless I first type two minuses.

Completion can be more useful if it is generating fewer matches but is
being intelligent enough to include those things which the user wants
(the fewer things in the list of matches, the less buried the one the
user wants is). I find that with prefix-needed it is more often
successful with this and I find it predictable because I'm used to it
working that way.

Oliver



  reply	other threads:[~2001-03-27 21:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-27  9:42 Sven Wischnowsky
2001-03-27 11:39 ` Oliver Kiddle
2001-03-27 17:56   ` Bart Schaefer
2001-03-27 21:16     ` Oliver Kiddle [this message]
2001-03-28  6:22       ` Bart Schaefer
2001-03-28 10:03         ` Peter Stephenson
  -- strict thread matches above, loose matches on Subject: below --
2001-03-27  9:22 Oliver Kiddle

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=3AC1032D.263705A8@u.genie.co.uk \
    --to=opk@u.genie.co.uk \
    --cc=zsh-workers@sunsite.dk \
    /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).