From: Dmitry Gutov <dgutov@yandex.ru>
To: Daniel Mendler <mail@daniel-mendler.de>, emacs-devel@gnu.org
Subject: Re: Improvement proposals for `completing-read'
Date: Thu, 8 Apr 2021 23:44:57 +0300 [thread overview]
Message-ID: <292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru> (raw)
In-Reply-To: <a9dfa0ad-149e-a8e3-11a1-c2dd1021dd03@daniel-mendler.de>
On 08.04.2021 11:37, Daniel Mendler wrote:
>> 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.
Perhaps. We might disable deduplication only optionally, though, OTOH
retaining text properties seems to be always useful (even if caller
wouldn't be able to always rely on it).
>> 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.
AFAIK, being able to do this is essential to reach best performance in a
number of important use cases.
> 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 :)
I was thinking more about interactions over network, with HTTP requests
sent and received asynchronously. Mainly the cases where one uses the
LSP protocol or similar.
>> 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.
You can check out Company's asynchronous convention for backends:
https://github.com/company-mode/company-mode/blob/f3aacd77d0135c09227400fef45c54b717d33f2e/company.el#L456-L467
It's a very simple lambda-based future-like value. It can be updated to
use a named type, and with other features too. I think it's a clean and
simple base to build on, though.
> 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.
I'm not sure where to look, sorry.
> 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.
I'm not 100% clear, but it sounds like chunked iteration. Which is a
good feature to have. Though perhaps not always applicable to every UI
(blinking with new results in a completion popup might be not
user-friendly).
> 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.
See my link, perhaps.
Or in general, a Future/Promise API has a way to subscribe to the
value's update(s) (and the completion frontend can do that).
Having to use a global variable seems pretty inelegant in comparison.
> But since this proposal is much more complicated than the ones I didn't
> add something like this here. Small steps first.
No hurry at all. Sometimes, though, a big feature like that can inform
the whole design from the outset.
next prev parent reply other threads:[~2021-04-08 20:44 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 [this message]
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
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=292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=mail@daniel-mendler.de \
/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).