[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: |
Thu, 07 Aug 2014 00:49:01 +0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 |
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?
- 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 <=
- Re: Layered display API, Eli Zaretskii, 2014/08/07
- Re: Layered display API, Dmitry Gutov, 2014/08/10
- 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