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

[T.V Raman]

Philip Kaludercic <philipk@posteo.net> writes:


In the spirit of exerimentation I'd second what Stefan suggested,

Step 1: Create a selection oriented equivalent of completing-read

2. See how that works out --

3. Then, compare it with completing-read -- and see if we can derive a
   master composite function that handles both use-cases well.

   completing-read has been around for a long time which means: The
   good -- it has withstood the test of time -- and possibly bad: it's
   constraining  with respect to backward compatibility and trying new
   things.

   We've now experimented in Emacs with entire packages trying to offer
   alternatives;  let's now use that learning to move toward building
   the correct lower-level support functions, and the suggestion above
   is trying to be the next step in that process
   
>
>> 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.
>
>>>  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.

-- 

Thanks,

--Raman
?7?4 Id: kg:/m/0285kf1  ?0?8