[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
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?
- Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate), Dmitry Gutov, 2014/08/06
- Re: Layered display API, Dmitry Gutov, 2014/08/06
- Re: Layered display API, Eli Zaretskii, 2014/08/07
- Re: Layered display API,
Dmitry Gutov <=
- Re: Layered display API, Eli Zaretskii, 2014/08/11
- Re: Layered display API, Dmitry Gutov, 2014/08/12
- Re: Layered display API, Stefan Monnier, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Dmitry Gutov, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Stefan Monnier, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Dmitry Gutov, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13