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

[Drew Adams <drew.adams@oracle.com>]

> >> 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.

That justification just repeats "I want it."  Why?
What problem does the proposed solution try to solve?

I'm not saying you don't need it or you shouldn't
have it.  I'm asking why.

> One such case is when you browse the history itself
> using `completing-read`, but this is certainly a very
> narrow case.

Why is it even a use case?  Why disable history when
`completing-read' against the history?  Maybe you
have a good reason - what is it?

> But `read-from-minibuffer` already accepts the `t`
> argument, so it will be less confusing if
> `completing-read` is aligned with it.

That hardly seems like a good argument.  The
behavior of those functions is quite different,
including their use of arguments that might seem
similar because of their names.

Consistency slapped on with a broad brush is
generally not a good guideline.  Local consistency
can be a good guideline - one among many.

And is this perhaps another case of favoring users
of such Elisp functions over users of the code
that makes use of those functions?

Why/when is it useful for _users_ to not be able
to access the history of their inputs?  What if
they just want to explore that history (without
using some command explicitly designed for that)?

Again:

 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.

> >> 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.

Why?  Reasons, please.  I gave reasons why it's
a feature.  Why do you think it's a bug?

> Stefan Monnier seems to agree to some extent if
> I understood correctly.

Appeal to authority or popularity isn't a reason.

Explain how else code can know whether the user
just hit RET (empty input).  Or explain why we
would want to remove the possibility to know that.

> Unfortunately the bug is widespread so one has to
> look a bit around if there will bad effects due
> to fixing the bug.

We're not there yet.  I'm asking why this feature
should be removed.

> There seems to be some agreement that it is useful to
> improve the support of the selection use case of `completing-read`.

I don't know what that means.  What's "the selec..."?

> >> 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?

You haven't seen many is different from "there
are not many."

I'd agree that there are likely more uses of
completion where duplicates are removed than
uses where they are not.

I'd even say there are likely more uses where
dups _should_ be removed.  But more doesn't
imply that the less case is few.

I expect there are many use cases for retaining
duplicates.  And even that if there were only a
few there might be a lot of use of those few.

> >>     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.

It sounds like you're assuming that the order is,
say, the order of things (text bits, markers,...)
in a buffer.

As long as the "duplicates" retain, internally,
their complete identities (unique objects), the
UI can, if it likes, make use of that, and even
make it known in various ways to users.

There's no reason that arbitrary sort orders
can't be useful, just because the displayed
candidates might look like duplicates.

> 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").

Why the "default completion"?  We already have
that possibility (e.g. using text properties).

It should be up to a specific use of completion
(e.g. of `completing-read') whether to (1) allow
seeming duplicates and (2) distinguish them during
completion.

> >> 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.

Proposals require some presentation of the utility
or need.  Raison d'être is perhaps the most important
part of a proposal - any proposal.

(And no, those proposals are not very concrete.)

> > 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!

Such a discussion can be productive, but it can only
go so far, as things get more real.  The devil is in
the details.