Re: Sticky tooltips

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 29 Sep 2020 23:30:14 +0200
>> 
>> Yeah, you are correct, what tooltip already does, as you say is
>> logically what I described, but the implementation is different:
>> tooltip.el seems to outsource all it's work to xfns.c, and the code for
>> tooltip frame creation; I used just "a naked frame" and some Lisp to
>> create an effect of a tooltip.
>
> The C-level implementation notwithstanding, we still insert the
> tooltip text into a buffer, so we could snatch it from there, right?
> We could have a command that took that text and displayed it in *Help*
> buffer, for example.
>
>> By the way; "tooltip-show" (in tooltip.el) seems to take a string
>> argument; rather than a buffer, and that widget library "widget.el",
>> needs a buffer (for the minor mode, etc).
>
> See above.
Yes boss; I am sure you are correct :-). I am not sure if I can do much
there since I am not sure I understand the underlaying C implementation
really that well; but I'll look try to look at it and play with it for
the weekend. Otherwise it would be easy to just wrap the function and in
tooltip.el. 

>> Just as a side curious question: did tooltips really needed own c
>> implementation? Isn't code in x-create-tip-frame and x-show-tip seems
>> redundant to other frame creation routines/display? Couldn't tooltips be
>> implemented using normal frames, with "tooltip-special" code written in
>> lisp? 
>
> If you compare x-create-frame and x-create-tip-frame, you will see
> that the tip frame is special, and some of the differences are in
> fields of the frame object that are not exposed to Lisp.  To move this
> to Lisp would mean we'd have to expose them to Lisp first, and I'm not
> sure we want to do that.

I haven't compared, but I suppose it is not same; tooltip frame is
undecorated and different window class then ordinary frame. I understand
if those low level details are not interesting to expos to lisp, since they
are platfrom specific. I think that is what might be spooking in that
other example with I posted about focus not being set correctly in a
child frame.

>> I dont' mean to ditch it away, just a reflection on complexity. Maybe I
>> don't see all the complexity with tooltips; but it is still ~900+ lines
>> of c code that need to be maintained for X11, and there are well w32 and
>> ns implementations, so around 3k locs? 
>
> The code replication is a separate issue: we did make an effort lately
> to extract some common code and have it only once.  Patches are
> welcome to do that in x-create-frame and x-create-tip-frame as well.
> It isn't entirely trivial, because the common code is interspersed
> with window-system specific API calls.

Indeed, I noticed when I was looking the tooltip code; the code seems
much better and more readable without all platfrom if-defs; when I
looked at some code like a year or half-year ago, it was more difficult
to read it; I am not sure I looked at tooltip code back then though. But
I think this X/Win32/Mac file separation makes it much nicer. Big +1 for
that one.