[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: complexity in minibuffer

From: Dmitry Gutov
Subject: Re: complexity in minibuffer
Date: Wed, 2 Jun 2021 23:15:29 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 02.06.2021 22:03, João Távora wrote:
On Wed, Jun 2, 2021 at 7:31 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

On 02.06.2021 18:06, Stefan Monnier wrote:
I suspect they should get an `md` argument instead (which will include
the `group-function`, of course).

Good idea: this way the argument is not tied to an optional feature, but
would OTOH provide renderers' access to any such feature that we might
add in the future.

Agree  we have to give _some_ state of the completion operation
to the renderer, not just the completions themselves.   But lets
concentrate that state as much as possible.  Ideally, as I think
you once suggested, we'd have a "completion operation instance"
object/ADT that contains the collection of completions and all the
paraphernalia used to manipulate it.  We'd pass _that_ around,
instead of md's, minibuffer-* special vars, completion-extra-properties
and whatnot.  Not sure if easy to realize but at least that's what
I would aim for.

Ideally, perhaps, but I don't think we're at the stage where we can confidently implement that yet. This completion context with the session cache, etc.

We still might pass MD even in that case, because it's not just a function of the current completion, but of the current field as well. Depend on what the info a particular function will want/need.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]