Re: Add function to make frame topmost?

[David De La Harpe Golden]

Lennart Borgman wrote:

> The problem is that it is not powerful enough for things like menus of
> the type used by for company-mode or completion-ui (see EmacsWiki).

I'm not too familiar with either. I think the tooltip type window hint 
is indeed also used or abused for completion panel display by some 
non-emacs X11 apps (so says xprop). I don't now want to give too much 
weight to it - what emacs puts in and does with an X11 window that it 
tells the window manager is a tooltip is still pretty much up to emacs 
(of course currently emacs might currently only be allowing display of a 
string...)

> What about having a
> function make-tooltip-type-frame?

Hmm. It _might_ make sense to allow it as an elisp-exposed emacs frame 
parameter.  e.g. for argument's sake

(make-frame '((disposition . tooltip))
(make-frame '((disposition . utility)))
etc.

Not sure "disposition" is the right word...

It would probably then also prove necessary to be able to specify 
override-redirect and wm-transient-for at the lisp level as frame 
parameters (though maybe the former could be implied - you're hardly not 
going turn on override-redirect if you're making a tooltip) - the 
lisp-level wm-transient-for (or "master-frame") frame parameter could 
probably be limited to other emacs frames.

OTOH, that all might be getting a bit lowlevel to expose so directly at 
the elisp level:  The precedent from tooltips and popup menus is that 
there are special-purpose apis for them at the elisp level, maybe
there's an argument for some sort of  single-purpose
(inline-completion-panel-show <mumble>)
and (notification-show <mumble>)
functions by analogy with
(tooltip-show "blah") and (popup-menu 'blah).

such an approach has the advantage it might be coaxed into doing 
something vaguely useful on text terminals.

OTOTOH, maybe the extra frame parameters might become a lower level 
implementation detail of such an api.