Re: Layered display API

[Dmitry Gutov]

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
> > > expect.
> >
> > We have different commands that move up and down, with specific logic
> > behind them.
>
> Examples?

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
> > idea.
>
> We could generalize the current menu code to allow something like
> that.

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?