[Top][All Lists]

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

Re: Inline completion preview

From: Eli Zaretskii
Subject: Re: Inline completion preview
Date: Fri, 27 Oct 2023 08:52:03 +0300

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 26 Oct 2023 21:39:16 +0200
> Eli Zaretskii <eliz@gnu.org> writes:
> > I wish people would work on adding to Emacs some a GUI infrastructure
> > for showing such completion candidates like other IDEs do, instead of
> > once again using overlays with after-string properties.
> I'm not sure I know enough about the benefits of other approaches, what
> do you envision?

Did you see how other IDEs implement this display?  That's what I

> > The result of using overlay strings is simply not visually appealing,
> It doesn't seem to me very different from what I see in other editors,
> but I guess that's a matter of taste.

Then maybe you should describe the use case in more details, because
this could be a misunderstanding of sorts.  What are the use case(s)
where the feature you propose would be useful?

> Sorry, that might have not been clear enough, I wrote:
>     ISTM that the best approach is a simple library that uses only
>     `completion-at-point` as a backend, because `completion-at-point` is
>     already extensible enough to support a variety of completion
>     backends.

This is an argument from the implementation POV, it basically says
"let's do it because we can".  The question I asked is different: why
do we need to invent something new when we seem to already have
similar functionalities that are widely used?  A response I expected
would explain why those existing packages cannot support the desired
feature, or are too heavy for such a simple feature, or have some
other issues when used for this functionality.

reply via email to

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