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

On 08/13/2014 07:28 PM, Eli Zaretskii wrote:

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.

Cool. Like Stefan suggested, I'll try playing with a toolkit-less popup first, and then you could see if you can provide a similar API with tty menus.

I've been under impression that "tty menus" could work in graphical mode, too, but now I understand that they're non-portable, like the name suggests. That's too bad.

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.

Yep, I meant "tty menus" there. Not an option.

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.

Why use the special new property, then? Just put a new overlay over it. If it also has `display' and higher priority, it would take over.

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.

So, you would suggest I dynamically rebind `tty-menu-navigation-map'?

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

If one piece of code creates one button, and another piece of code creates another button, they can put different handlers into the button properties, so the results of clicking of these buttons will be different, even if they are in the same buffer, on the same line.

Same could be done the fringe, at least in theory.

reply via email to

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