[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [External] : Re: Improvement proposals for `completing-read'

From: Drew Adams
Subject: RE: [External] : Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 17:22:20 +0000

> maybe we could arrange for the minibuffer text to be
> matched against the *annotated* candidates in some cases.
> I think this requires more thought, together with concrete
> examples.

In Icicles there's a distinction:

1. Annotations are _not_ matchable (intentionally).

2. Completion candidates can be multi-part.  Each
   part can be matched separately.  Use of any part
   by a user is optional.

So if a command wants to make what might normally
be considered an annotation matchable it just uses
multi-completion, that is, it gives candidates two
parts, the second being what would have been the

It's also possible for particular parts not to be
displayed in *Completions*.  You can nevertheless
complete against them.

An example is choosing a file or buffer name.  The
commands for this use multi-completion.  The first
part of a candidate is the file or buffer name.
The second part is the file or buffer content.
The content part is _not_ shown in *Completions*.

So you can choose a file or buffer by matching its
name or its content or both.

Users can completely ignore the content part.  They
can even not know it's available to match against.
(It's created only on demand, so no performance
penalty when you don't match content.)

Doing this is fairly straightforward.  It would be
even more so if vanilla `completing-read-default'
took care of it.  As it is, I need to fudge the
parts together for `completing-read-default', and
tease them apart when needed.

As a candidate for `(icicle-)completing-read', a
multi-completion just has a list of strings as its
car instead of a single string.  That possibility
is currently unexploited (aka available) by vanilla.

(Multi-completions are thus possible only for alist
collections.  That restriction could be removed if
underlying code such as `completing-read-default'
took care of them.)

>From the doc of `icicle-completing-read':

  The car of an alist entry can also be a list of
  strings.  In this case, the completion candidate
  is a multi-completion.

  The strings are joined pairwise with
  `icicle-list-join-string' to form the completion
  candidate seen by the user.

  You can use variable `icicle-candidate-properties-alist'
  to control the appearance of multi-completions in
  buffer `*Completions*'.

  You can use variables `icicle-list-use-nth-parts'
  and `icicle-list-nth-parts-join-string' to control
  the minibuffer behavior of multi-completions.

See https://www.emacswiki.org/emacs/Icicles_-_Programming_Multi-Completions.

> you can't do the highlighting correctly for
> `partial-completion` without having access to
> the "pattern" against which it was matches.

Exactly.  The pattern and the kind of matching.  E.g.,
for regexp patterns `string-match' is relevant for
finding the matched part of a candidate.

Highlighting candidate match parts (and their common
expansion, if there is one) should be done only in
the function that displays the candidates (e.g. in

reply via email to

[Prev in Thread] Current Thread [Next in Thread]