Re: Layered display API

[Bo Lin]

Eli Zaretskii <address@hidden> writes:

>> >> > What I meant is this: if you need to display below the last line of
>> >> > the buffer text, put the overlay at EOB, and include newlines in the
>> >> > overlay string when you need to move to the next screen line.  To
>> >> > align text horizontally you could use spaces or align-to display
>> >> > properties in the string.
>> >> 
>> >> Yes, I might try this, as soon as there's some suggestion how to handle 
>> >> the problem of `line-prefix' in this multi-overlay approach.
>> >
>> > Find the longest prefix and align everything so that the left edge
>> > keeps clear of that?
>> 
>> Zero length overlays don't get displayed so this won't work when the
>> buffer is empty.
>
> When a buffer is empty, there are no line prefixes, right?  Or did I
> misunderstand what you eman?

I thought this was about avoid padding the buffer text with
newlines?

>> >> >>      This is indeed a missing feature.  It should be easy enough to 
>> >> >> provide
>> >> >>      some special kind of display property that would overlay any other
>> >> >>      displayed content
>> >> >>
>> >> >>
>> >> >> That would leave a question where will it have to be set on.
>> >> >> Would that new kind of overlay be able to be displayed far
>> >> >> from the position it's set on?
>> >> >
>> >> > No, I meant conceal the text produced by other display properties, and
>> >> > display your overlay string instead.
>> >> 
>> >> It doesn't seem to be solving much: if I want to display something in 
>> >> the middle of, say, large `display' text, there's no specific span of 
>> >> text to set that new property on.
>> >
>> > You'd put it on the overlay string.
>> 
>> Ideally, for a popup tooltip, it should cover only the small
>> rectangular area that is the tooltip, while leaving everything else
>> intact to minimize visual disturbances. This is, AFAICT, currently
>> impossible to achieve if you have to conceal anything with a
>> 'display property, because: 1) in the simplest case the 'display is
>> a string, but you don't know the proper display width of each
>> character; and 2) the 'display can be not-strings.
>
> I wasn't talking about the currently existing display properties, I
> was talking about a new property with the capabilities I described.

Oh, I see. Yeah, that would be very nice.

-Bo