From: Daniel Mendler <mail@daniel-mendler.de>
To: Dmitry Gutov <dgutov@yandex.ru>, emacs-devel@gnu.org
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 10:37:59 +0200 [thread overview]
Message-ID: <a9dfa0ad-149e-a8e3-11a1-c2dd1021dd03@daniel-mendler.de> (raw)
In-Reply-To: <09b67fc5-f8fd-c48a-8b0b-ad47c88761f1@yandex.ru>
On 4/8/21 12:16 AM, Dmitry Gutov wrote:
> On 07.04.2021 14:16, Daniel Mendler wrote:
>> .. Proposal 1: Disabling the history
>> .. Proposal 2: More efficient sorting
>> .. Proposal 3: Sort file names by history
>> .. Proposal 4: Add support for `group-function'
>> .. Proposal 5: Forbid the null completions for `REQUIRE-MATCH=t'
>> .. Proposal 6: Return text properties from `completing-read'
>> .. Proposal 7: Allow duplicates and retain object identity
>> .. Proposal 8: Completion style optimization of filtering and
>> highlighting
> 6. would indeed make sense, and I'm not sure why we wouldn't want to
> have it in the non-selection case. Whatever come makes use of the
> completed value, could do the stripping of properties.
>
> Often, completing-read's caller can ensure the properties are there, by
> using something like (assoc-default completed-string collection) at the
> end. But that only works if the caller is also the provider of the
> completion table (otherwise it's an "opaque" data structure).
Yes, you can use an alist and this is also what I use in my Consult
package when I want to obtain the associated data. But allowing
text-properties could simplify some scenarios and it would be more
natural when you are doing selection. If you consider proposal 7
(identity/deduplication), retaining the text properties is an automatic
outcome.
> 9. completion tables need to be able to delegate all matching logic to
> an external process, both filtering and sorting. That's an important
> case for code completion, where we can take advantage of existing code
> and its "fuzzy matching" implementations.
This would be neat, but it requires a lot of restructuring of the
completion logic. For this reason I am not fond of this idea. But you
can achieve something like this with your proposal 10. See what I
describe there, regarding Consult async.
I tried to integrate `fzf` once with Consult async, like generating a
list outside Emacs, pushing it through `fzf` for fuzzy-filtering and
presenting it to the user via completion. But it turned out that most of
the external implementations are not good enough for this use case. They
don't have an option to open a pipe to update the filtering input for
example. I could write my own fuzzy matcher external backend which would
work perfectly with async completion. However then I can also just wait
for gccemacs :)
> 10. support for delayed/asynchronous fetching of completions which
> doesn't interrupt user's typing (it would generally abort the request if
> user input is detected, but there might be other approaches to that).
> Again, that's helpful when completions are produces by an external process.
You may want to take a look at my Consult package, specifically the
async functionality. I believe that this functionality can easily be
provided on top of the current infrastructure, and actually in a nice way.
In Consult I am using closures which hold the asynchronously acquired
data. The closure function must accept a single argument, it can either
be a string (the new input) or it can be a list of newly obtained
candidates.
(There are also a few more arguments which are accepted 'flush and one
can potentially extend this and compose the closure functions. But this
is a detail.)
If it is a list the closure function must append the new candidates to
the already existing ones and return the full list of candidates. The
completion table then calls the async closure with either the input or
nil when doing all-completions.
Now a single problem remains - if new data is incoming the async data
source must somehow inform completion that new candidates are available.
In order to do this the async source must trigger the UI for example via
icomplete-exhibit/selectrum-exhibit and so on. It would be good to have
a common "completion-refresh" entry point for that. In Consult I have to
write a tiny bit of integration code for each supported completion system.
But since this proposal is much more complicated than the ones I didn't
add something like this here. Small steps first.
Daniel Mendler
next prev parent reply other threads:[~2021-04-08 8:37 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9dfa0ad-149e-a8e3-11a1-c2dd1021dd03@daniel-mendler.de \
--to=mail@daniel-mendler.de \
--cc=dgutov@yandex.ru \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.