[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: Wed, 13 Aug 2014 06:42:57 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 08/11/2014 07:01 PM, Eli Zaretskii wrote:

Compare this with x-popup-menu: the similarity is striking.  Which is
why I suggested to use menus on TTYs.

Yes, it would be nice if we can use them. However, the fact that menus handle evens themselves (or try to) makes me think it's not the cleanest approach.

Given these requirements, I think the only 2 alternatives to implement
them for GUI frames are:

   . tooltip frames, suitably beefed up <...>

   . some low-level graphics feature <...>

Nothing else seems possible, because if we rely on the current display
engine, we will be unable to fully control at least the vertical
position of the lines in your popup, and in some cases (e.g.,
line-prefix) also the horizontal position.

Not even menus? My understanding was they might be able to satisfy most of the requirements, aside from working with proportional fonts.

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.

Find the longest prefix and align everything so that the left edge
keeps clear of that?

Yes, sounds like a reasonable simplification. This would be a step back in terms of functionality, though, but possibly a justified one.

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.

You'd put it on the overlay string.

Let me rephrase the previous message: "...there's no specific span of text to put the overlay on". Or that's my understanding.

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

We have different commands that move up and down, with specific logic
behind them.


A simple example:

    (define-key keymap (kbd "M-n") 'company-select-next)
    (define-key keymap (kbd "M-p") 'company-select-previous)
    (define-key keymap (kbd "<down>") 'company-select-next-or-abort)
    (define-key keymap (kbd "<up>") 'company-select-previous-or-abort)

The last two abort completion, do some magic and push the event back into `unread-command-events'. This happens if <up> is pressed when the first candidate is selected, or <down> is pressed when the last one is.

Among other things, `company-select-next' and its counterpart save the number of the currently selected completion candidate, and the other commands and front-ends use that to display information related to it, and for correct visualization.

Allowing the menu to handle those keys doesn't sound like a good

We could generalize the current menu code to allow something like

Sounds promising.

You can always exit the menu, pop up the documentation buffer, then
redraw the menu, all this programmatically.

Will the menu allow me to customize the keymap it's using? To be able to invoke the `company-show-doc-buffer' command in the first place?

Same as above: exit the menu, do what you need, then redraw it.

Would that work via post-command-hook?

No.  The current menu code simply ignores any commands it wasn't
programmed to understand and act upon.

Ignores, or allows them to go through?

That is a problem you won't be able to escape.  Emacs modes aren't
supposed to fight each other; if they do, the user is in trouble.

Some packages's fringe indicators might be incompatible by their essence, there's not much we could do there.

Others could co-exist. If the fringe allowed "layered" display of bitmaps, for example, flymake could assign its overlays a higher priority and happily coexist with diff-hl indicators.

Could I display some vertical graphic in the margins that smoothly spans
several lines?

Emacs can display image slices (see the documentation of the 'display'
property), so this should be possible.  I didn't try it, though.

Thanks, I'll look it up sometime.

And? Suppose there are multiple minor modes in that buffer that might
like to handle that click?

Again, fights like that should be resolved "by other means".

In the buffer contents, they are resolved with buttons. Why not on the fringe?

reply via email to

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