Re: Layered display API

[Dmitry Gutov <dgutov@yandex.ru>]

On 08/06/2014 09:19 PM, Eli Zaretskii wrote:

> That you already have, don't you?  The problem is not display, AFAIU,
> the problem is the decision where exactly to display it, and the
> answer depends on the dimensions of the text and the window.

"Below or above" are just the main choices. Correctly positioning it at 
the right line and column, without disturbing the text around, can still 
be a problem in advanced cases, like you mentioned here and in another 
thread.

> If some features are missing to achieve the above (and they are not
> the 2 mentioned below), then please spell them out, because I thought
> the display part was already solved, once the layout is decided.

Only if we use 1 overlay (the "crazy" approach) and only if we can 
easily get the text contained on the target rows, and there are physical 
buffer positions corresponding to the first and last lines where we want 
to display the popup (or thereabouts). If the whole text in the window 
is already rendered with `display' property, and we want to display the 
popup above only some part of it... good luck with that.

> (And pixel units work quite well on text terminals, except that each
> character position is 1 pixel.)

Ok.

>> 1. If the buffer ends (shortly) after the current line, we're forced to
>> pad it with a newline, and then carefully undo that and restore the
>> buffer modification status.
>
> Why can't you include the newline in the overlay string instead?

Haven't tried yet. And in the overlay-a-line case, each of them would be 
zero-length, then? Guess that could work...

>> 2. If the buffer is already heavily using the `display' text property,
>> or other similar ones, our tooltip positioning also breaks or works
>> unexpectedly. Example: the `report-emacs-bug' buffer
>> (https://github.com/company-mode/company-mode/issues/136).
>
> 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?

 > , but won't that introduce the kind of arms race we
> already have with overlay priorities?  IOW, what if more than one
> feature wants to have its string displayed on top of everything?

I've only read about this "arms race" here on emacs-devel, instead of 
seeing it in practice. When we want to have layered display, using some 
kind of priorities system is probably a fact of life. I don't think 
there's a way around it.

> Btw, why doesn't company use normal tooltips on GUI frames and
> text-mode menus on a TTY?  Wouldn't that be better?

I'm not 100% sure what's text-mode menu is (by tooltip, do you mean 
`tooltip-show'?), but maybe because when active, they take over event 
handling, so you can't move up and down the list with M-n/M-p (or any 
other bindings the user prefers), press another combination of keys and 
see a doc buffer pop up, or just continue typing in the buffer and see 
the popup with completion candidates get updated unobtrusively.

And, at least in the tooltip's case, they can't be styled.

>> Somewhat relatedely, I'd love to be able to sanely display smooth
>> graphics spanning multiple lines in the fringe (or in the area that
>> would replace it)
>
> How is this different from displaying bitmaps that fill the whole
> height of a screen line, so that adjacent bitmaps don't leave any
> pixels between them?

That's what I've been trying to do in diff-hl (see ELPA), and failing to 
do the arithmetics just right when line-spacing and zoom factor and 
present. It should be easier with the recently added functions, though.

Still, this way you can only use 2 colors, each line can only contain 
one bitmap, and the way you have to define the bitmaps globally is 
pretty simplistic.

* Supporting vector graphics would be nicer, instead of having to 
redefine the bitmaps when zoom level changes.

* If two visible buffers have different zoom levels, I don't know how 
display the required bitmaps in both of their fringes right. Include the 
line height in the bitmap names, maybe? Speaking of crazy approaches.

> Clicking on the fringes already works.

We do support buttons in buffers, even though we probably could add 
click handlers and then look up coordinates. Suppose there are multiple 
modes using the fringe, and they all want to handle clicks. How would 
they handle that without conflicts?