[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: Mon, 11 Aug 2014 05:14:24 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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

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?

reply via email to

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