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: Mon, 11 Aug 2014 05:14:24 +0400 [thread overview]
Message-ID: <53E818F0.2080104@yandex.ru> (raw)
In-Reply-To: <837g2knwb2.fsf@gnu.org>
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?
next prev parent reply other threads:[~2014-08-11 1:14 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
2014-08-07 15:39 ` Eli Zaretskii
2014-08-11 1:14 ` Dmitry Gutov [this message]
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=53E818F0.2080104@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).