Re: feature/icomplete-vertical

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right.  But is there a very large cost in implementing a mechanism of
>> notification that applications can optionally subscribe to take action
>> when this common thing happens to them?
>
> I don't think the cost is large, but someone needs to do the writing.
> Emacs was never designed to display completions this way, so it's not
> surprising these mechanisms weren't implemented until now.

Right.  Though it's not only for completion.

>>    This function exists to allow Lisp programs to adjust the buffer text
>>    so that it fits visually in WINDOW.
>> 
>> I don't know how to use the function to do this.  In other words, I have
>> some buffer text and I would like to know:
>> 
>> 1) If it fits in WINDOW;
>> 2) If it doesn't, where is the cutoff, as a text position.
>
> Basically, remove lines one by one until it fits.

This was the approach I took in eldoc.el, but I found it's complex.  And
it assumes we want to cut off at logical line positions.  In a recent
proposal of bug#43543 I proposed taking it out of eldoc.el (presumably
to be replaced later with some more generic means).

> We could write a similar function to do what you want, but please note
> that such a function will not understand the semantics of the text, so
> it could suggest truncating it at some place which makes no sense.
> If the caller would like a smarter 'service", we will have to come up
> with some method of telling the function where it makes sense to
> truncate the text.

Right. My idea is that a "dumb" service gives us a text position and the
application, which does know the semantics of the things being
displayed, decides based on that.

For example, icomplete would remove the candidate where the truncation
happened and replace it with an elipsis, whereas eldoc would remove the
piece of documentation entirely and maybe replace it with a hint to
visit the *eldoc* buffer.

João