Re: Layered display API

[Dmitry Gutov <dgutov@yandex.ru>]

On 08/07/2014 07:39 PM, Eli Zaretskii wrote:

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

Display some strings in the buffer starting with the given line and 
column, correctly lining all following lines up vertically, to form a 
rectangle

Something like the following would work:

(make-popup :x-coord 340 :y-coord 200 :width ... :height ... :contents 
"foo\nbar\nbaz" :default-face ...)

  The keyword arguments are just for show, and the above assumes that 
popups aren't tied to specific buffers (or window, I guess). Making it 
buffer-local would be fine, too, I guess, then :x-coord and :y-coord 
might be replaced with :x-offset and :y-offset, specified relative to 
the popup's reference position in the buffer's contents.

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

- `line-prefix', as discussed.

- Different values of `line-height', `line-spacing', images in the buffer.

- Changes in some lines' appearance done some other way, like the 
separator line in `log-edit' buffers.

- The `intangible' property would probably also cause some problems for 
our current implementation.

- Proportional fonts, obviously.

- Not being able to display the popup over the mode-line and window 
separators. This would be useful for completion when typing in the 
minibuffer.

- The "one big overlay" approach conflicts with other packages that use 
overlays to put information on the margins or fringes, such as linum and 
diff-hl. The lines displaying our popup lose the linum and diff-hl 
indicators.

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

An overlay where BEG = END. It wasn't a very meaningful question, I guess.

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

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

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

We have different commands that move up and down, with specific logic 
behind them. Allowing the menu to handle those keys doesn't sound like a 
good idea.

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

It _might_ help with displaying the one-line help we already show in the 
echo area (although the programmatic interface seems to be incompatible: 
we only ask the backend for that information when the candidate is 
selected), but it definitely won't help with popping up the 
documentation buffer.

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

Could you elaborate on that? Would that work via post-command-hook?

>> And, at least in the tooltip's case, they can't be styled.
>
> What do you mean by "styled"?

Displayed with different background color, for example.

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

Of course.

>> Still, this way you can only use 2 colors
>
> Why only 2?

The fringe foreground color and the fringe background color. The fringe 
face may vary between lines, but a bitmap instance ends up using only 
two colors at a time.

>> each line can only contain one bitmap
>
> Fringe real estate is limited, so yes, there are limits to this.

Fringe size is not fixed, the user (or packages) can change it. Even 
with the current default size, I could use being able to display several 
bitmaps at a time: for example, the simple-looking indicator from 
diff-hl and, above it, `?' or `!` from flymake.

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

line-prefix is again something only one package can use at a time.

Could I display some vertical graphic in the margins that smoothly spans 
several lines?

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

And? Suppose there are multiple minor modes in that buffer that might 
like to handle that click?