Re: Completion: display of candidates

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Yes, I could.  I just thought that there's probably some kind of
>> metadata I could attach for customizing the display.
>
> It can't be "display only" since the user expects to type what is
> displayed, so it also affects what the user types.

Right, and here comes the next problem: concretely I get my completions
from `locate --basename <pattern>`.  So the user (me) might enter a
wildcard pattern like "foo*bar.*".  But the completions/matches
obviously have no * in it, so no completion matches the candidates.

How to handle that?  Use the PREDICATE argument in completing-read so
that the input ".em*s" matches the found candidate ".emacs (/home/horn)"
by transforming the wildcard to an emacs regexp and using
string-match-p?

> BTW, you might be interested in the GNU ELPA package `uniquify-files`
> which tries to do almost exactly what you suggest (it requires a few
> ugly hacks currently, but we hope to be able to improve the
> minibuffer.el infrastructure so those can be dispensed with).

I'll have a look at it.  Thanks for the pointer.

>> So I guess the best thing to do is to format the entries as you
>> suggest and put a text property on the text holding the absolute path
>> so that I don't have to reconstruct it myself which could be
>> error-prone if the directory or basename contain parens themselves.
>
> You can't really rely on those text-properties, because the user may
> have typed that text by hand.

I use the REQUIRE-MATCH argument of completing read, and even if I
didn't, if there's no property the user (me) must have entered a file
name then.

Bye,
Tassilo