emacs-devel
[Top][All Lists]
Advanced

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

Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [


From: Philip Kaludercic
Subject: Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Thu, 08 Apr 2021 20:03:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> > What's the purpose of having that distinction?
>> 
>> My hypothisis is that selection is held back
>> by completing-read,

> Why do you think so?  Held back in what way(s)?
> Details, please.

Can completing-read offer a hierarchical overview, allow inspection into
selected items, ensure that calls return values eq to the input, lazily
compute textual representations when they are needed?  Starting from a
clean slate and intentionally designing an alternative function around
selection would seem to have the advantage that we already know that
people want, instead of having to fight what we already have.

>> and that a framework that is explicitly made for
>> selection and not retrofitted into the existing
>> framework could stand to improve the user experience.
>
> Again, why do you think so?
>
> This is as vague as a suggestion to rewrite Emacs
> so it uses Rust (or Python or Scheme or whatever)
> instead of Lisp, with no attempt to say what the
> need for that is or the advantages would be.
>
> I'm not arguing that `completing-read' has no
> room for improvement.  In fact, I'm the first to
> say (and to have said, and shown) that there's
> plenty of room.
>
> (I've actually improved it in many ways, in my
> own code and practice.  Lots of details and
> experience with my own "proposed" changes to it.)
>
> But a vague argument at the level of "selecting"
> versus "completing" doesn't cut it, in my book.
>
> Push the existing envelope first, to see where
> the real limits of `completing-read' are, before
> asking for an overhaul.

I am not proposing an overhaul, but to make the job easier for
completing-read. Instead of continuing to extend it by adding additional
special arguments and finding loopholes in the current implementations
of selection frameworks, I argue that a cleaner and more consistent
solution can be found in trying to understand when selection is wanted,
and how a solution that can be provided that directly solves the
problem.

I don't want to sound like a "Rewrite X in Y" kind of guy, because I
don't want to replace completing-read. I like it, and I like it
simple. Maybe it doesn't make sense to have both, but some
experimentation is necessary before that can be concluded.

-- 
        Philip K.



reply via email to

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