Re: Layered display API

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 13 Aug 2014 06:42:57 +0400
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: rudalics@gmx.at, emacs-devel@gnu.org
> 
> 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.

The menu code can be extended.  More accurately, we could refactor the
menu code to provide the capabilities of overlaying text on window
display for other Lisp features.

> > 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.

At least with some toolkits, GUI menus have decorations, which will
look strange if we use them in this capacity.

> >>> 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".

The buffer text that is covered by the "large display property" is
still there, right?  It just isn't displayed.

> Will the menu allow me to customize the keymap it's using?

Of course!  This is Emacs.  See the end of menu-bar.el: the menu
navigation keys are defined as a keymap.

> > 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?

Ignores.  They are processed and produce no effect.

> >> 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?

I don't see how buttons can resolve conflicts.  Maybe I'm missing
something.