[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
something.
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.
- Re: Layered display API, (continued)
- Re: Layered display API, Eli Zaretskii, 2014/08/07
- Re: Layered display API, Dmitry Gutov, 2014/08/10
- Re: Layered display API, Eli Zaretskii, 2014/08/11
- Re: Layered display API, Dmitry Gutov, 2014/08/12
- Re: Layered display API, Stefan Monnier, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Dmitry Gutov, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Stefan Monnier, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API,
Dmitry Gutov <=
- Re: Layered display API, Eli Zaretskii, 2014/08/13
- Re: Layered display API, Dmitry Gutov, 2014/08/14
- Re: Layered display API, Eli Zaretskii, 2014/08/14
- Re: Layered display API, Dmitry Gutov, 2014/08/14
- Re: Layered display API, Eli Zaretskii, 2014/08/15
- Re: Layered display API, Dmitry Gutov, 2014/08/15
- Re: Layered display API, Eli Zaretskii, 2014/08/16
- Re: Layered display API, Dmitry Gutov, 2014/08/16
- Re: Layered display API, Bo Lin, 2014/08/13
- Re: Layered display API, Eli Zaretskii, 2014/08/13