[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: T.V Raman
Subject: Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Thu, 08 Apr 2021 09:40:12 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

   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.



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

reply via email to

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