From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: rudalics@gmx.at, emacs-devel@gnu.org
Subject: Re: Layered display API
Date: Thu, 07 Aug 2014 00:49:01 +0400 [thread overview]
Message-ID: <53E294BD.1000500@yandex.ru> (raw)
In-Reply-To: <8361i5pmch.fsf@gnu.org>
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?
next prev parent reply other threads:[~2014-08-06 20:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <86tx5r7l1j.fsf@yandex.ru>
[not found] ` <53E097F7.5050407@gmx.at>
[not found] ` <53E0ABF9.7070506@yandex.ru>
[not found] ` <8338dbqcai.fsf@gnu.org>
[not found] ` <53E14AF4.6050804@yandex.ru>
[not found] ` <83k36mpbxg.fsf@gnu.org>
2014-08-06 12:40 ` Layered display API (was: bug#18195: 24.3.92; window-screen-lines is not accurate) Dmitry Gutov
2014-08-06 17:19 ` Eli Zaretskii
2014-08-06 18:20 ` Alp Aker
2014-08-06 18:39 ` Eli Zaretskii
2014-08-06 20:48 ` Layered display API Stefan Monnier
2014-08-07 2:45 ` Eli Zaretskii
2014-08-06 20:49 ` Dmitry Gutov [this message]
2014-08-07 15:39 ` Eli Zaretskii
2014-08-11 1:14 ` Dmitry Gutov
2014-08-11 15:01 ` Eli Zaretskii
2014-08-13 2:42 ` Dmitry Gutov
2014-08-13 12:46 ` Stefan Monnier
2014-08-13 15:29 ` Eli Zaretskii
2014-08-13 16:27 ` Dmitry Gutov
2014-08-13 17:07 ` Eli Zaretskii
2014-08-13 17:45 ` Stefan Monnier
2014-08-13 15:28 ` Eli Zaretskii
2014-08-14 2:35 ` Dmitry Gutov
2014-08-14 2:53 ` Eli Zaretskii
2014-08-14 13:12 ` Dmitry Gutov
2014-08-14 15:20 ` Eli Zaretskii
2014-08-15 1:20 ` Dmitry Gutov
2014-08-15 6:39 ` Eli Zaretskii
2014-08-15 23:03 ` Dmitry Gutov
2014-08-16 7:41 ` Eli Zaretskii
2014-08-16 9:17 ` Dmitry Gutov
2014-08-14 2:06 ` Bo Lin
2014-08-14 2:49 ` Eli Zaretskii
2014-08-14 16:08 ` Bo Lin
2014-08-14 16:19 ` Eli Zaretskii
2014-08-14 16:42 ` Bo Lin
2014-08-06 20:56 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53E294BD.1000500@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).