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 23:30:26 +0200 [thread overview]
Message-ID: <7d03e917-6a61-23b3-e735-a8e43c3fb65f@daniel-mendler.de> (raw)
In-Reply-To: <292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru>
On 4/8/21 10:44 PM, Dmitry Gutov wrote:
>> 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.
Yes, this is all possible with async completion tables in Consult. There
is a consult-spotify package which queries some web api and there is
also consult-lsp in the works which accesses the lsp api
(https://github.com/minad/consult/issues/263).
>> 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.
Yes, this looks very simple. I actually prefer the functional style in
contrast to some named types as you have it in Company. So how is this
used? When completing the fetcher is called and as soon as it returns
via the callback the results are displayed? But chunking is not possible
and probably also not desired? See below for my response regarding
chunking in Consult.
>> 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.
Take a look at `consult--async-sink` at
https://github.com/minad/consult/blob/3121b34e207222b2db6ac96a655d68c0edf1a449/consult.el#L1264-L1297.
These `consult--async-*` functions can be chained together to produce an
async pipeline. The goal here was to have reusable functions which I can
glue together to create different async backends. See for example the
pipeline for asynchronous commands:
https://github.com/minad/consult/blob/3121b34e207222b2db6ac96a655d68c0edf1a449/consult.el#L1505-L1513.
> 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).
Indeed, the UI receives the candidates as soon as they come in. One has
to ensure that this does not freeze the UI with some timer. Then there
is also throttling when the user changes the input. It works very well
for the `consult-grep` style commands. You may want to try those. They
are similar to `counsel-grep` but additionally allow to filter using the
Emacs completion style. Take a look here, in case you are interested
https://github.com/minad/consult#asynchronous-search. Note that you
don't have to use chunking necessarily. You can use a single chunk if
the whole async result arrives in bulk.
>> 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.
It is not a global variable but a function. But for sure, one could also
design the async future such that it receives a callback argument which
should be called when new candidates arrive. The way I wrote it in
Consult is that the `consult-async-sink` handles a 'refresh action,
which then informs the completion UI.
> No hurry at all. Sometimes, though, a big feature like that can inform
> the whole design from the outset.
Yes, sure. When planning to do a big overhaul you are certainly right.
But currently I am more focused on fixing a few smaller pain points with
the API, like retaining text properties and so on.
Daniel Mendler
next prev parent reply other threads:[~2021-04-08 21:30 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 [this message]
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=7d03e917-6a61-23b3-e735-a8e43c3fb65f@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 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).