zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>,
	zsh-workers@sunsite.auc.dk
Subject: Completion heuristics (was Re: bug in _rpm?)
Date: Fri, 17 Sep 1999 09:48:27 +0000	[thread overview]
Message-ID: <990917094827.ZM30892@candle.brasslantern.com> (raw)
In-Reply-To: <199909170845.KAA02144@beta.informatik.hu-berlin.de>

On Sep 17, 10:45am, Sven Wischnowsky wrote:
} Subject: Re: bug in _rpm?
}
} >   % rpm -ihv /usr/src/redhat/RPMS/i386/<TAB>
} >   % rpm -ihv /usr/src/redhat/RPMS/i386/--
} >   zsh: do you wish to see all 28 possibilities? 
} > 
} > Where did that `--' come from?
} 
} Do you have many files in that directory, all of the form `*-*-*'

He must.  That's what RPM file names look like.

} If so, it's the unambiguous string that was inserted (with a somewhat
} weird cursor placement -- but we are currently thinking about ways to
} improve that, see 7831 and follow-ups; any help appreciated).

In this situation the amount of information and typing assistance that
is provided by inserting any ambiguous string at all is so small as to
be merely confusing.  The whole point of ambigous string insertion is
that the human is supposed to be better than zsh at resolving the
ambiguity, which ceases to be true below a certain information-content
threshold.

Better cursor placement would only help a little, and I think in this
example not at all.

One approach would be to figure out some heuristic for determining that
the ambiguous string "looks enough like" an element of the set of possible
matches, and not insert it at all if it looks "too different."

A wild guess at such a heuristic:

1.  There's exactly one choice for cursor placement to resolve the
    ambiguity; OR

2.  The ambiguous string shares a common (non-empty) prefix with ALL
    of the possible matches; OR

3.  The ambiguous string is at least half as long as the difference
    between the lengths of the shortest match and the longest and at
    least one-fourth as long as the length of the shortest.

Number (3) is obviously the wildest of the guesses.  I'd probably go with
just the first two, but I don't rely on intra-word match-specs all that
often, so I don't know exactly how to predict what's useful there.

As for cursor placement:  Put it wherever the addition of a character
would make the greatest difference in the number of matches; another
way to say this is, place the cursor at the implicit * that matches the
greatest number of alternatives.  This may be beyond our ability to
determine ... but the whole point of completion is to help the user
reduce the set of alternatives from N to 1 as quickly as possible, so
wherever will help throw out the most alternatives is the right place
to ask for more input.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


  reply	other threads:[~1999-09-17  9:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-17  8:45 bug in _rpm? Sven Wischnowsky
1999-09-17  9:48 ` Bart Schaefer [this message]
1999-09-17 10:35 Completion heuristics (was Re: bug in _rpm?) Sven Wischnowsky
1999-09-20  9:37 Sven Wischnowsky
1999-09-20 14:22 Sven Wischnowsky

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=990917094827.ZM30892@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=wischnow@informatik.hu-berlin.de \
    --cc=zsh-workers@sunsite.auc.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).