[Top][All Lists]

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

Re: Layered display API

From: Dmitry Gutov
Subject: Re: Layered display API
Date: Sat, 16 Aug 2014 03:03:33 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 08/15/2014 10:39 AM, Eli Zaretskii wrote:

Well, since we don't only need to replace the displayed characters, but
also modify them, this doesn't do a lot of work for us.

Not sure why you would need to modify them.  My understanding is that
you include in the overlay some of the displayed text, and also
include your own text.

Yes, we take the displayed text, *modify* its copy to overwrite some pieces of it with our text, and put it on our overlay. So one of the hard parts, if done perfectly, would be to obtain the displayed text correctly.

What I'm suggesting will allow you not to duplicate the displayed
text, but just add an overlay with your own.

Sorry, I'm getting strongly mixed signals here: just recently, when I enumerated a list of requirements for displaying our popup, you replied:

Given these requirements, I think the only 2 alternatives to implement
them for GUI frames are:

  . tooltip frames, suitably beefed up to provide some features they
    currently don't, like more control of colors and faces

  . some low-level graphics feature that would allow to overlay an
    arbitrary pixmap on the window display (this is far from my area
    of expertise, so I cannot say anything more about this

Nothing else seems possible, because if we rely on the current display
engine, we will be unable to fully control at least the vertical
position of the lines in your popup, and in some cases (e.g.,
line-prefix) also the horizontal position.

So, which part of the job would the new text property perform, and which part of it will be left to us to implement?

See above: because what exists doesn't do the job for you well enough.
Copying into your overlay existing text from buffer, other overlays,
and display strings is fragile design with known deficiencies (which
were revealed in this thread).  Having a special property that would
avoid all that is a win, IMO.  For example, you will be able to stop
worrying about line-prefix and images.

Let's imagine this sample case:

  (insert "e\naaaaaa\n")
  (insert (propertize " " 'display "bbbbbb\ncccccc")

(By the way, try this out in *scratch* and do some C-n, C-p. Do you see the movement error? Here, the cursor always jumps over the "aaa..." line when moving toward the beginning of the buffer.)

Let's say the point is at the end of the first line (after "e"), and we'd like to display a popup under it, 4 columns wide and 2 lines tall. If the popup is all filled with "x" characters, it should look like this:


If the new property was already implemented, what would the code to do this look like?

reply via email to

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