[Top][All Lists]

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

Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package

From: Eric Abrahamsen
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Thu, 08 Apr 2021 21:21:08 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 08.04.2021 17:44, Philip Kaludercic wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>> On 08.04.2021 01:59, Philip Kaludercic wrote:
>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
>>>>> What I was disagreeing in the previous message, is whether it's worth
>>>>> to create a semantic distinction between completing-read and
>>>>> selecting-read. How would a Lisp author choose between the two? The
>>>>> former should actually be more powerful (it will retain support for
>>>>> TAB completion, and yet it could still be supported by selection-style
>>>>> frameworks such as Company or Ivy);
>>>> completing-read can be more powerful, as it includes expanding text
>>>> and
>>>> selecting items, but I if you are not interested in text-expansion you
>>>> should probably limit yourself to selection,
>>> Am "I" in this example the user, or the author of the caller code?
>> The I was probably a typo.
> I was asking what you meant by "you", actually. Probably not important
> at this point.
>>>>   so that everyone is ensured
>>>> to have the same presentation.
>>> If that's the goal, why don't we make sure to include a "selection"
>>> interface that supports text-expansion as well, like both Company and
>>> Ivy do?
>>> What's the purpose of having that distinction?
>> My hypothisis is that selection is held back by completing-read, and
>> that a framework that is explicitly made for selection and not
>> retrofitted into the existing framework could stand to improve the user
>> experience.
> Ah... all right. So the idea could be to annotate the cases where
> text-expansion is not needed. I'm not sure there is a good way to make
> that determination, though. OTOH, I can imagine cases which pretty
> much *need* selection-like interface.
> xref-show-definitions-completing-read would be one example (it's
> relatively awkward to make the choice using completion, though
> certainly not impossible).

This is exactly the sort of use-case I think selection would be perfect
for. As another data point, Gnus has `gnus-multiple-choice', yet another
approach to the problem.

reply via email to

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