unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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



  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

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