From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Completion heuristics (was Re: bug in _rpm?)
Date: Fri, 17 Sep 1999 12:35:46 +0200 (MET DST) [thread overview]
Message-ID: <199909171035.MAA02368@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Fri, 17 Sep 1999 09:48:27 +0000
Bart Schaefer wrote:
> 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.
I know, that one wasn't meant that serious.
> 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.
[unambiguous]
Yes, in fact, I've already been thinking in the same direction after
the latest discussion.
> Better cursor placement would only help a little, and I think in this
> example not at all.
Well, if done right... see below.
> 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.
I'm not so sure about (1) either. But I need play with different
implementations to be better able to think about this. Maybe at the
weekend.
> 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.
That's what I tried to implement before 7630. The problem is that we
can't reliably calculate that information, as you thought.
> 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.
And that's what I've tried to achieve from the beginning. Remember the
older discussions about cursor positioning? The completion code even
puts the cursor preferably in a position where the user can continue
by simply inserting something instead of having to type backspace-<char>.
The problem we have now is a problem at a lower level. How to find the
best position between those that look equally interesting for the
completion code and if to insert string-parts for which there is
nothing on the line at all.
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-09-17 10:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-17 10:35 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-09-20 14:22 Sven Wischnowsky
1999-09-20 9:37 Sven Wischnowsky
1999-09-17 8:45 bug in _rpm? Sven Wischnowsky
1999-09-17 9:48 ` Completion heuristics (was Re: bug in _rpm?) Bart Schaefer
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=199909171035.MAA02368@beta.informatik.hu-berlin.de \
--to=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).