From: Arthur Miller <arthur.miller@live.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Sticky tooltips
Date: Wed, 30 Sep 2020 17:17:33 +0200 [thread overview]
Message-ID: <VI1PR06MB4526AADBAEC73BF19D0979FE96330@VI1PR06MB4526.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <83pn63iajn.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 30 Sep 2020 17:50:04 +0300")
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.
next prev parent reply other threads:[~2020-09-30 15:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 20:04 Sticky tooltips Arthur Miller
2020-09-28 22:11 ` Jean Louis
2020-09-29 3:39 ` Arthur Miller
2020-09-29 4:20 ` Jean Louis
2020-09-29 2:41 ` Eli Zaretskii
2020-09-29 3:36 ` Arthur Miller
2020-09-29 14:17 ` Eli Zaretskii
2020-09-29 21:30 ` Arthur Miller
2020-09-30 14:50 ` Eli Zaretskii
2020-09-30 15:17 ` Arthur Miller [this message]
2020-10-01 2:28 ` Sv: " arthur miller
2020-10-01 12:58 ` Eli Zaretskii
2020-10-02 10:47 ` Sv: " arthur miller
2020-10-05 9:27 ` Arthur Miller
2020-10-05 9:48 ` Eli Zaretskii
2020-10-05 10:18 ` Arthur Miller
2020-10-05 10:52 ` Eli Zaretskii
2020-10-05 11:04 ` Arthur Miller
-- strict thread matches above, loose matches on Subject: below --
2020-10-05 0:55 Arthur Miller
2020-10-22 16:17 Arthur Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR06MB4526AADBAEC73BF19D0979FE96330@VI1PR06MB4526.eurprd06.prod.outlook.com \
--to=arthur.miller@live.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).