emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Layered display API


From: Stefan Monnier
Subject: Re: Layered display API
Date: Wed, 06 Aug 2014 16:56:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> Basically, we'd like to be able to display a rectangle with propertized 
>> text inside, at an arbitrary position (I would say pixel coordinates, 
>> but that might not work well in terminal), so that it would be displayed 
>> above the buffer contents.
> That you already have, don't you?

I don't think we do.

> Why can't you include the newline in the overlay string instead?

I wonder as well.

> This is indeed a missing feature.  It should be easy enough to provide
> some special kind of display property that would overlay any other
> displayed content,

A similar request was made to overlay non-text content.

> but won't that introduce the kind of arms race we already have with
> overlay priorities?

We have tons of such arms races in the current display system
(e.g. faces, invisibility, ...).  It'd be nice to solve them, but
I don't think this is an argument against providing another display
feature that also suffers from such arms races.

> Btw, why doesn't company use normal tooltips on GUI frames and
> text-mode menus on a TTY?  Wouldn't that be better?

Normal tooltips can be used but have their own problems (I'm pretty sure
one of auto-complete, completion-ui, or other uses that in some cases).
E.g. depending on compile-time choices, they may be provided by the GUI
toolkit, in which case we have very little control about what features
they provide (key-bindings, fonts, colors, ...).

But yes, one possible direction is to spice up our support for "tooltip
frames" such that it can be used for such purposes without losing the
ability to control faces and key-bindings and with control over the
precise layout and the borders that might be drawn around it.


        Stefan



reply via email to

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