Re: Layered display API

[Eli Zaretskii]

> Date: Thu, 07 Aug 2014 00:49:01 +0400
> From: Dmitry Gutov <address@hidden>
> CC: address@hidden, address@hidden
> 
>     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.

So what would be the requirements for "correct positioning"?

>     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.

So text with display properties is one problem.  Any others?

>         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...

Sorry, I don't understand the question: what would be zero-length?

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.

>         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?

No, I meant conceal the text produced by other display properties, and
display your overlay string instead.

>     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

A normal menu, created by x-popup-menu, which now works on TTYs.  You
can pop up the menu at any place in the window text area.

> (by tooltip, do you mean `tooltip-show'?)

Yes, a real tooltip.

> 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)

Text-mode menus support navigation with cursor movement keys, like
C-p, C-n, up-arrow, and down-arrow.  More accurately, any key bound to
next/previous-line will navigate through the menu items as you'd
expect.

> press another combination of keys and see a doc buffer pop up

Help-echo in menus is supported, and shown in the echo area
automatically, so you could have all that documentation in the
help-echo string.

> or just continue typing in the buffer and see the popup with completion 
> candidates get updated unobtrusively.

This can be achieved programmatically, by refreshing the menu when the
user types.

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

What do you mean by "styled"?

In any case, if something is missing in tooltip frames to support this
kind of applications, we had better added that.  IMO, showing
completion candidates in a tooltip will look much more professionally
than the current text emulation.  AFAIK, other IDEs do use tooltips in
these cases.

> Still, this way you can only use 2 colors

Why only 2?

> each line can only contain one bitmap

Fringe real estate is limited, so yes, there are limits to this.

An alternative is to use line-prefix or display margins, and display
images there.

>     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.

Again, you can display images in the margin or the line-prefix, and so
a button could be displayed there, I think.

> Suppose there are multiple modes using the fringe, and they all want to 
> handle clicks. How would they handle that without conflicts?

The click on the fringe is interpreted in the context of the selected
window's buffer, AFAIR.