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

[Daniel Mendler]

On 4/8/21 1:49 AM, Drew Adams wrote:
> > Proposal 1: Disabling the history
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> What's the problem?  How does it hurt for users to
> have the default history, `minibuffer-history',
> available?  They don't have to use it, right?
>
> I'm not saying I'm opposed to your proposed solution.
> I'm saying I haven't seen the problem specified that
> you're trying to solve.
As an author of completion commands I like the ability to disable the 
history if I think it is useful. One such case is when you browse the 
history itself using `completing-read`, but this is certainly a very 
narrow case. But `read-from-minibuffer` already accepts the `t` 
argument, so it will be less confusing if `completing-read` is aligned 
with it.
> > Proposal 4: Add support for `group-function'
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> So the overall problem you say you want to solve is
> that `completing-read' is too complex, hard to use,
> and hard to implement.  Yet you want to add something
> like this, to make it even more complex and hard to
> implement? ;-)
Haha, yes :) But adding metadata functions is a small cost and small 
addition in complexity.
> My main concern about further complicating the code
> implementing `completing-read' is that things will
> end up hard-coded - and hence difficult to use by
> users and by implementers of 3rd-party code.
In this case it is actually an optional extension. The UI does not have 
to use it, but can use it to offer an enhanced display. If the 
completion command does not use it nothing is lost. The proposal is 
fully forward/backward compatible. It is a pure enhancement, like 
annotation/affixation functions.
> > Proposal 5: Forbid the null completions for `REQUIRE-MATCH=t'
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Empty completion returning a special value (namely "")
> lets code know that the user provided empty completion.
> That's a _feature_.
I'd say it is a bug. Stefan Monnier seems to agree to some extent if I 
understood correctly. Unfortunately the bug is widespread so one has to 
look a bit around if there will bad effects due to fixing the bug.
> > Proposal 6: Return text properties from `completing-read'
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 100% agreement.  I proposed this a zillion years ago
> (and added it to Icicles).  Rejected for Emacs.  But
> this feature should only be _possible_, not imposed.
I hope that patches which allow text properties will be accepted. The 
initial responses I received sounded positive. There seems to be some 
agreement that it is useful to improve the support of the selection use 
case of `completing-read`.
> > Proposal 7: Allow duplicates and retain object identity
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >     There are not many completion tables which generate
> >     duplicate candidates
> Do you mean not many _kinds_ of completion tables,
> or not many completion tables (in practice)?  If
> you mean the latter, I'd like to know why you think
> that, as I doubt it's the case.  (No, I don't have
> numbers either.)
I am just saying that I have not observed many duplicates while using 
Emacs with completion systems, which do not deduplicate. I think 
`find-library` or `load-library` shows duplicate candidates?
> >     and there exist multiple completion systems
> >     which do not perform deduplication at all.
> Icicles among them.
And Selectrum and Vertico :)

> >     Note that this proposal is useful mainly for completion tables which
> >     disable sorting by setting `display/cycle-sort-function' to the
> >     identity function.
> Why?  (I'm pretty sure I disagree.)
I assume a Swiper-like command. If you don't sort then you can simply 
scroll through the duplicate candidates, which retain their original 
order. I am sure one can jump through many hoops to make this nice in 
any case. Stefan Monnier requested that default completion should also 
disambiguate the duplicates on the UI level, such that one can still 
chose between them ("reifying the object identity").
> > Proposal 8: Completion style optimization of filtering and highlighting
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Again, please explain just what's been found,
> instead of reporting what you've decided.  Details
> matter.  What kind of highlighting?  When and how
> was highlighting done, and to what?  What was tried?
> In what contexts?  Just what problems were found?
No, I am making concrete proposals here. I am not reporting issues.

> General critique: Please present _one_ proposal per
> thread, for consideration.  This thing about a Yalta
> meeting having taken place and someone descending
> from the summit with stone tables presenting the
> IX Proposals isn't so helpful, IMO.
I considered this but decided against it due to the relations and to 
keep the discussion at one place. As you see from the current responses 
the discussion seems to be productive. This includes your mail. Thank 
you for your responses!
Daniel Mendler