[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: 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.)


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

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?

reply via email to

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