From: Daniel Mendler <mail@daniel-mendler.de>
To: Drew Adams <drew.adams@oracle.com>,
"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Re: [External] : Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 11:29:40 +0200 [thread overview]
Message-ID: <3470841e-d0ef-69d2-aa58-67fd0fd57645@daniel-mendler.de> (raw)
In-Reply-To: <SA2PR10MB44747409BFE86B789660C127F3759@SA2PR10MB4474.namprd10.prod.outlook.com>
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
next prev parent reply other threads:[~2021-04-08 9:29 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-07 11:16 Improvement proposals for `completing-read' Daniel Mendler
2021-04-07 17:11 ` Stefan Monnier
2021-04-07 17:20 ` Stefan Monnier
2021-04-07 19:46 ` Daniel Mendler
2021-04-07 21:26 ` Stefan Monnier
2021-04-08 9:01 ` Daniel Mendler
2021-04-08 14:44 ` Stefan Monnier
2021-04-08 15:26 ` Stefan Kangas
2021-04-08 15:47 ` Daniel Mendler
2021-04-08 17:31 ` Stefan Monnier
2021-04-08 15:37 ` Daniel Mendler
2021-04-08 17:22 ` [External] : " Drew Adams
2021-04-08 18:22 ` Dmitry Gutov
2021-04-08 18:48 ` Drew Adams
2021-04-08 19:03 ` Dmitry Gutov
2021-04-08 19:32 ` Drew Adams
2021-04-08 17:30 ` Stefan Monnier
2021-04-08 17:57 ` Daniel Mendler
2021-04-08 18:13 ` Stefan Monnier
2021-04-08 19:15 ` Daniel Mendler
2021-04-08 19:20 ` Dmitry Gutov
2021-04-08 19:46 ` [External] : " Drew Adams
2021-04-08 20:12 ` Dmitry Gutov
2021-04-08 21:12 ` Drew Adams
2021-04-08 22:37 ` Stefan Kangas
2021-04-09 0:03 ` Dmitry Gutov
2021-04-09 2:09 ` Using more and/or better icons in Emacs Stefan Kangas
2021-04-09 3:09 ` Lars Ingebrigtsen
2021-04-09 3:35 ` chad
2021-04-09 12:06 ` Stefan Kangas
2021-04-09 7:41 ` Yuri Khan
2021-04-09 9:59 ` tomas
2021-04-09 11:15 ` Dmitry Gutov
2021-04-09 11:19 ` Dmitry Gutov
2021-04-09 12:22 ` Stefan Kangas
2021-04-09 12:29 ` Dmitry Gutov
2021-04-09 17:46 ` Stefan Kangas
2021-04-09 18:45 ` Eli Zaretskii
2021-04-09 19:30 ` Alan Third
2021-04-09 19:40 ` Alan Third
2021-04-09 22:38 ` Dmitry Gutov
2021-04-10 0:56 ` Stefan Kangas
2021-04-10 1:43 ` Stefan Kangas
2021-04-10 9:12 ` Alan Third
2021-04-10 10:56 ` Stefan Kangas
2021-04-10 13:48 ` Alan Third
2021-04-12 19:39 ` Alan Third
2021-04-13 1:25 ` Stefan Kangas
2021-04-13 7:35 ` Alan Third
2021-04-13 10:39 ` Stefan Kangas
2021-04-13 19:50 ` Alan Third
2021-04-13 22:44 ` Stefan Kangas
2021-04-14 6:46 ` Eli Zaretskii
2021-04-15 15:37 ` Alan Third
2021-04-15 15:50 ` Eli Zaretskii
2021-04-15 17:10 ` Alan Third
2021-04-11 21:57 ` Dmitry Gutov
2021-04-09 23:16 ` Alan Third
2021-04-10 0:55 ` Stefan Kangas
2021-04-10 7:23 ` Eli Zaretskii
2021-04-10 9:17 ` Alan Third
2021-04-10 9:25 ` Eli Zaretskii
2021-04-08 17:22 ` [External] : Re: Improvement proposals for `completing-read' Drew Adams
2021-04-08 18:33 ` Drew Adams
2021-04-07 23:11 ` Drew Adams
2021-04-08 7:56 ` Eli Zaretskii
2021-04-07 18:39 ` Jean Louis
2021-04-07 19:49 ` Daniel Mendler
2021-04-07 22:16 ` Dmitry Gutov
2021-04-08 8:37 ` Daniel Mendler
2021-04-08 20:44 ` Dmitry Gutov
2021-04-08 21:30 ` Daniel Mendler
2021-04-10 2:21 ` Dmitry Gutov
2021-04-10 9:18 ` Daniel Mendler
2021-04-11 0:51 ` Dmitry Gutov
2021-04-11 13:08 ` Daniel Mendler
2021-04-12 0:32 ` Dmitry Gutov
2021-04-12 0:40 ` Daniel Mendler
2021-04-12 10:47 ` Dmitry Gutov
2021-04-12 11:04 ` Daniel Mendler
2021-04-14 0:00 ` Dmitry Gutov
2021-04-14 10:44 ` Daniel Mendler
2021-04-07 23:49 ` [External] : " Drew Adams
2021-04-08 9:29 ` Daniel Mendler [this message]
2021-04-08 17:19 ` Drew Adams
2021-04-09 11:19 ` Jean Louis
2021-04-09 11:47 ` Daniel Mendler
2021-04-09 17:22 ` Drew Adams
2021-04-09 17:41 ` Daniel Mendler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3470841e-d0ef-69d2-aa58-67fd0fd57645@daniel-mendler.de \
--to=mail@daniel-mendler.de \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).