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

[Drew Adams]

> > I mentioned variable `icicle-transform-function', whose
> > most common values are `icicle-remove-duplicates' and
> > nil (which means don't remove dups).
> >
> > (Like such a variable, completion metadata is an
> > aggregate operation: it applies to a set of completions,
> > not to just this or that completion.)
> >
> > `icicle-transform-function' is applied to all candidates,
> > and it can do anything.
> 
> A general completion table does specify any,
> `icicle-transform-function` and it wouldn't know how.

(Maybe you meant "does not"?)

I described `icicle-transform-function' - see that.
The point is about the behavior provided: transforming
the current completion set.

The current completion table is not the only thing that
can be general.  Everything need not be encoded in it.

Binding a variable allows for use of the same "table"
to behave somewhat differently.  And the same transform
function can be used with multiple, and very different,
"tables".

Both of those are important - as opposed to having to
encode the transformation in each completion table (e.g.
function) itself.

(Of course a completion table can itself remove dups
(or just not create any).  That's already available.)

An alist is a completion table.  Nothing says that the
general completion machinery can't, tomorrow, apply a
function to that alist (a map, a reduce, a whatever)
to produce a different alist.

And there are other ways, besides binding a function
variable or encapsulating in a completion table, to
affect the behavior of completion over a candidate set.

> Some standard, cross-frontend approach would be required.

Sure.  And one such way is to allow for a function that
acts on the set of current candidates (e.g. those matching
input pattern and satisfying filter predicates), possibly
transforming it.

One such possible (and common) transformation is to remove
duplicates.

My points here were two, the first being the more important:

1. Allow for more general behavior possibilities than just
   removing dupicates - however that's done.  (And yes, of
   course we're talking in this thread about what would be
   a common approach.)

2. Binding a function variable is one way that can be done.

Do I think the way chosen should necessarily be part of the
completion table?  A priori, no.  No need to limit thought
to only that possibility now.  And see above, about some
advantages of not doing that.

Am I wedded to binding a function variable as the only way
to do it?  No.  It's certainly a simple way to do it, not
involving any surgery or redefinition of "completion tables".

But the main point was #1: transformation in general, not
just dup removal.  Why not?

> >> I do think it's questionable, though, to include
> >> completions that are hard to distinguish.
> >
> > Don't confuse looking different in *Completions*, at the
> > outset and always, with easy to distinguish.  There are
> > other ways to make them appear different - from mode-line
> > to ephemeral appearance changes in *Completions*.  There
> > is more than one way to skin this cat.
> 
> Ephemeral appearance changes could be good enough. Or icons,
> like on the attached video.

I noticed only one use of `completing-read' in that video -
for `M-x electric-pair-mode'), and no icons in that case (no
*Completions* buffer display at all).

And I didn't notice any cases of duplicate candidates,
whether or not distinguished by their icons.

But I guess you just meant to show icons next to completion
candidates.  Sure, why not?  Any kind of apparent distinction
(face, label, sound,...) is an apparent distinction.