Sticky tooltips

Sticky tooltips

[Arthur Miller]

[-- Attachment #1: test --]
[-- Type: text/plain, Size: 4296 bytes --]

;;; poor-man-tooltip.el ---                                 -*- lexical-binding: t; -*-

(require 'widget)

(defvar pm-tooltip-duration)
(setq pm-tooltip-duration 4)

(defun pm-test ()
  (interactive)
  (pm-tooltip "Here is some tootip text."))

(define-minor-mode pm-minor-mode
  ""
  :keymap (let ((map (make-sparse-keymap)))
            (define-key map (kbd "C-g")   'pm-quit-tooltip)
            map))

(defun pm-tooltip (tooltip-text)
  
  (let ((cur-line 0)
        (lng-line 0)
        (tooltip-timer nil)
        (tooltip-frame nil))
    
    (with-current-buffer (get-buffer-create "tooltip-buffer")
      (kill-all-local-variables)
      (let ((inhibit-read-only t))
        (erase-buffer))
      (remove-overlays)
      
      (insert " ")
      (insert tooltip-text)
      (goto-char (point-min))

      (while (not (eobp))
        (setq cur-line (- (line-end-position) (line-beginning-position)))
        (when (> cur-line lng-line)
          (setq lng-line cur-line))
        (forward-line))
      
      (newline)
      (insert-char ?- (- lng-line 6))
      (widget-insert " Sticky ")
      (widget-create 'checkbox 
                 :notify (lambda (s &rest ignore)
                           (if (widget-value s)
                                 (progn
                                   (when tooltip-timer
                                     (cancel-timer tooltip-timer)
                                     (setq tooltip-timer nil))
                                   (message "Sticky tooltip enabled!"))
                             ;; else
                             (progn
                               (when tooltip-frame
                                 (setq tooltip-timer (pm-start-timer
                                                      tooltip-frame)))
                               (message "Sticky tooltip disabled!")))))
      (use-local-map widget-keymap)
      (widget-setup))
      
    (setq tooltip-frame (pm-show-at-cursor "tooltip-buffer"))
    (setq tooltip-timer (pm-start-timer tooltip-frame))))

(defun pm-quit-tooltip (tooltip-frame)
  (with-current-buffer (get-buffer "tooltip-buffer")
    (kill-buffer))
  (delete-frame tooltip-frame))

(defun pm-start-timer (tooltip-frame)
  (let ((tooltip-timer
        (run-with-timer pm-tooltip-duration nil
                        (apply-partially #'pm-quit-tooltip tooltip-frame))))
    tooltip-timer))

(defun pm-show-at-point (menuname)
  (let ((position (pos-visible-in-window-p nil nil t)))
      (pm-create-tooltip menuname (nth 0 position) (nth 1 position))))

(defun pm-show-at-cursor (menuname)
  (let ((cursor-pos (mouse-pixel-position)))
        (pm-create-tooltip menuname (cadr cursor-pos) (cddr cursor-pos))))
    
(defun pm-create-tooltip (menuname x y)
  
  (with-current-buffer (get-buffer menuname)
    (pm-minor-mode)

    (setq tab-line-format nil)
    (setq mode-line-format nil)
    (setq cursor-type nil)
    (setq buffer-read-only t)
    
    (let ((parent (selected-frame))
          (child-frame (make-frame   '((visible . 0)
                                       (border-width . 2)
                                       (internal-border-width . 2)
                                       (undecorated . 0)
                                       (keep-ratio . t)
                                       (menu-bar-lines . 0)
                                       (tool-bar-lines . 0)
                                       (left-fringe . 0)
                                       (right-fringe . 0)
                                       (line-spacing . 0)
                                       (unsplittable . t)
                                       (minibuffer . nil)
                                       (no-other-frame . t)
                                       (drag-internal-border . t)
                                       (inhibit-double-buffering . t)
                                       (desktop-dont-save . t)))))
      
      (set-frame-parameter child-frame 'parent-frame parent)
      (fit-frame-to-buffer child-frame)
      ;; seems that afte fit-frame-to-buff there is few pixels missing
      (set-frame-width child-frame (+ 1 (frame-width child-frame)))
      (set-frame-position child-frame x y)
      child-frame)))

(provide 'poor-man-tooltip)

[-- Attachment #2: Type: text/plain, Size: 1107 bytes --]


Somebody suggested for sticky tooltips the other day; Mr. Eli Z.
explained about tooltips, when compiled in Gtk are controlled by Gtk.

So I wonder - do they need to be?

A tooltip is just a small pop-up window showing some text (usually).
Emacs is already very good at showing text in all kind of windows so
question is, is Gtk really needed to render tooltips? Even if Emacs
is compiled with Gtk? Is there any special advantage over an "Emacs
frame"?

I tested idea with a sticky tooltip based on just ordinary buffer
displayed in a child frame. I haven't done any text
styling/propertizing, faces, colors etc. The frame is displayed at mouse
cursor (just for test) and it starts a timer which deletes frame after
an (customizable) interval. There is a small checkbox to make it
"sticky" (it just removed the expiration timer); toggling it on will
start timer again.

It is just a sketch of the idea; i just wonder if such similar tooltip
implementatation (all Emacs) would be interesting. It seems to be quite
trivial and if it is done all in Elisp then I guess it would be same on
all gui platforms? 

Re: Sticky tooltips

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-09-28 23:06]:
> ;;; poor-man-tooltip.el ---                                 -*- lexical-binding: t; -*-
> 
> (require 'widget)
> 
> (defvar pm-tooltip-duration)
> (setq pm-tooltip-duration 4)
> 
> (defun pm-test ()
>   (interactive)
>   (pm-tooltip "Here is some tootip text."))

Under EXWM is not working so well.

Re: Sticky tooltips

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> * Arthur Miller <arthur.miller@live.com> [2020-09-28 23:06]:
>> ;;; poor-man-tooltip.el ---                                 -*- lexical-binding: t; -*-
>> 
>> (require 'widget)
>> 
>> (defvar pm-tooltip-duration)
>> (setq pm-tooltip-duration 4)
>> 
>> (defun pm-test ()
>>   (interactive)
>>   (pm-tooltip "Here is some tootip text."))
>
> Under EXWM is not working so well.

Probably, and probably with many other x11 managers. A WM can do
whatever (reparent, resize etc) and all those requests about
decorations, visibility etc are usually just hints that WM can but does
not need to implement. I don't know what exwm does or how Emacs passes
all this data to WM.

It was anyway just a quick test to show how "sticky" tooltip might
look-like, interface wise.

Re: Sticky tooltips

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-09-29 06:39]:
> > Under EXWM is not working so well.
> 
> Probably, and probably with many other x11 managers. A WM can do
> whatever (reparent, resize etc) and all those requests about
> decorations, visibility etc are usually just hints that WM can but does
> not need to implement. I don't know what exwm does or how Emacs passes
> all this data to WM.
> 
> It was anyway just a quick test to show how "sticky" tooltip might
> look-like, interface wise.

Yes, the concept I got. There was small check box, it was not possible
to check it that it sticks. When clicked, some blue cursor appeared on
the sticky tooltip. My theme was dark, the box was not really visible,
maybe it was dark too. It looks like sticky notes on Gnome desktop.

It is great that such features are easily implementable.

Thank you for demo.

Re: Sticky tooltips

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Mon, 28 Sep 2020 22:04:50 +0200
> 
> Somebody suggested for sticky tooltips the other day; Mr. Eli Z.
> explained about tooltips, when compiled in Gtk are controlled by Gtk.
> 
> So I wonder - do they need to be?

They don't have to be, we just use that as the default.  We have a
variable to turn that off and use our own tooltips.

I presume GTK users would prefer the GTK tooltips, though, because
they preserve the look-and-feel of the other GTK applications, and can
be customized in the same ways.

> I tested idea with a sticky tooltip based on just ordinary buffer
> displayed in a child frame.

You propose to switch to "tooltips" that pop up in a special buffer?

Re: Sticky tooltips

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Mon, 28 Sep 2020 22:04:50 +0200
>> 
>> Somebody suggested for sticky tooltips the other day; Mr. Eli Z.
>> explained about tooltips, when compiled in Gtk are controlled by Gtk.
>> 
>> So I wonder - do they need to be?
>
> They don't have to be, we just use that as the default.  We have a
> variable to turn that off and use our own tooltips.
>
> I presume GTK users would prefer the GTK tooltips, though, because
> they preserve the look-and-feel of the other GTK applications, and can
> be customized in the same ways.
Yes; I understand that. But then rest of Emacs does not look much like
the Gtk anyway, it's a win-loose. 

>> I tested idea with a sticky tooltip based on just ordinary buffer
>> displayed in a child frame.
>
> You propose to switch to "tooltips" that pop up in a special buffer?
I was mostly proposing for "pure Emacs" frame, special buffer or not, I
don't know. Why not?

That makes implementing "sticky" tooltip as someone suggested quite
trivial.

There is only one tooltip active at a time (I think), so there is just
one buffer/frame needed; and tooltip text could be erased/set when a
tooltip is shown. Would that be too inneificient?

Re: Sticky tooltips

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 29 Sep 2020 05:36:29 +0200
> 
> > You propose to switch to "tooltips" that pop up in a special buffer?
> I was mostly proposing for "pure Emacs" frame, special buffer or not, I
> don't know. Why not?
> 
> That makes implementing "sticky" tooltip as someone suggested quite
> trivial.
> 
> There is only one tooltip active at a time (I think), so there is just
> one buffer/frame needed; and tooltip text could be erased/set when a
> tooltip is shown. Would that be too inneificient?

You are, in effect, describing the way our native tooltips are
implemented: they are special small frames.  See tooltip.el.

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 05:36:29 +0200
>> 
>> > You propose to switch to "tooltips" that pop up in a special buffer?
>> I was mostly proposing for "pure Emacs" frame, special buffer or not, I
>> don't know. Why not?
>> 
>> That makes implementing "sticky" tooltip as someone suggested quite
>> trivial.
>> 
>> There is only one tooltip active at a time (I think), so there is just
>> one buffer/frame needed; and tooltip text could be erased/set when a
>> tooltip is shown. Would that be too inneificient?
>
> You are, in effect, describing the way our native tooltips are
> implemented: they are special small frames.  See tooltip.el.

Haha; typical me :-) 

I took looked in tooltip.el thanks. It works really nice, and it
switches flawlesly between gtk/native tooltips; I am impressed.

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.

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). Maybe it can be done
somehow, I don't know; however I am not so sure if "sticky tooltip" is
that good idea; echoing to message buffer is maybe good enough for most
people? 

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? 

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? 

Maybe special-buffers is not a bad idea? Just thinking out of the box :-).

Re: Sticky tooltips

[Eli Zaretskii]

> 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.

> 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 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.

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.

Sv: Sticky tooltips

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]

I can't sleep, so I thought it help to read some C code. I got just more awake.

Anyway, I have looked at x-show-tip, and yes it is pretty  much same as I described 🙂.

I am not sure how to get buffer out of x-show-tip, so I was thinking about different
strategv: modify x-show-tip to take as argument a buffer (or string-or-buffer) and modify it accordingly;
throw away most of "lispy" code that deals with setting up buffer and styling the string. The
buffer itself should be setup and styled on lisp side in tooltip.el. Just as illutstration:

(defcustom tooltip-enable-sticky nil
  "When enabled the tooltip frame will show a small checkbox widget
witch when enabled will make a tooltip not dissapear after timeout. To
  close a sticky tooltip untick the checkbox."
  :type 'boolean
  :group 'tooltip)

(defun tooltip-show (text &optional use-echo-area)
....
  (if use-echo-area
      (tooltip-show-help-non-mode text)
    (condition-case error
.....

 (with-current-buffer (get-buffer-create "some name")

     ;; do some other setup needed ...

     (insert (propertize text 'face 'tooltip))

     (when enable-sticky-tooltips
        ;; setup "widget" part to show
        ;; checkbox
     )

     ;; send in "ready-made" buffer

     (x-show-tip (current-buffer)
           (  ... )
.....


Amd x-show-tip would have signature like this

  (Lisp_Object buffer, Lisp_Object frame, Lisp_Object parms,
  Lisp_Object timeout, Lisp_Object dx, Lisp_Object dy)

I don't know how the function would deal with Gtk tooltips; if they can also take a buffer
and display it, that is why I mean the function to take string-or-buffer.

Another thing is timer; if user is going to make an action to cancel timer (enable sticky)
then lisp code needs access to the timer, so it probably should be handled in lisp too.

________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 30 september 2020 16:50
Till: Arthur Miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Sticky tooltips

> 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.

> 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 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.

[-- Attachment #2: Type: text/html, Size: 8875 bytes --]

Re: Sv: Sticky tooltips

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 1 Oct 2020 02:28:25 +0000
> 
> I am not sure how to get buffer out of x-show-tip,

??? The name of the buffer is fixed: " *tip*" (with the leading
space).  You can even switch to it interactively, and see the text
there (it would be the text of the last tootlip displayed), provided
that your build is not GTK, or if it is GTK, you've turned off GTK
tooltips and switched to the native ones.

> I don't know how the function would deal with Gtk tooltips; if they can also take a buffer
> and display it, that is why I mean the function to take string-or-buffer.

We'd need to modify the code to stash the tooltip text in some buffer
or variable.

Sv: Sv: Sticky tooltips

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

> ??? The name of the buffer is fixed: " *tip*" (with the leading
> space).
🙂 I was just not remembering what I saw in C file when I was
typing. But thanks for the tips. I do need to learn more about
how lispy C interacts with lisp; I think I have got some understanding,
but I definitely need to play more. The best hobby 🙂.

> We'd need to modify the code to stash the tooltip text in some buffer
> or variable.

Yes, the x-show-tip will need to be modified; my thought was to just
send in the string when Gtk tooltips are enabled, that is why I mean
string-or-buffer as argument. I am back at home on Sunday, so I'll play
with it.
________________________________
Från: Eli Zaretskii <eliz@gnu.org>
Skickat: den 1 oktober 2020 14:58
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Sv: Sticky tooltips

> From: arthur miller <arthur.miller@live.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 1 Oct 2020 02:28:25 +0000
>
> I am not sure how to get buffer out of x-show-tip,

??? The name of the buffer is fixed: " *tip*" (with the leading
space).  You can even switch to it interactively, and see the text
there (it would be the text of the last tootlip displayed), provided
that your build is not GTK, or if it is GTK, you've turned off GTK
tooltips and switched to the native ones.

> I don't know how the function would deal with Gtk tooltips; if they can also take a buffer
> and display it, that is why I mean the function to take string-or-buffer.

We'd need to modify the code to stash the tooltip text in some buffer
or variable.

[-- Attachment #2: Type: text/html, Size: 4534 bytes --]

Re: Sv: Sticky tooltips

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: arthur miller <arthur.miller@live.com>
>> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Thu, 1 Oct 2020 02:28:25 +0000
>> 
>> I am not sure how to get buffer out of x-show-tip,
>
> ??? The name of the buffer is fixed: " *tip*" (with the leading
> space).  You can even switch to it interactively, and see the text
> there (it would be the text of the last tootlip displayed), provided
> that your build is not GTK, or if it is GTK, you've turned off GTK
> tooltips and switched to the native ones.
>
>> I don't know how the function would deal with Gtk tooltips; if they can also take a buffer
>> and display it, that is why I mean the function to take string-or-buffer.
>
> We'd need to modify the code to stash the tooltip text in some buffer
> or variable.

It was actually even easier; C code can just get ready-made-buffer on
it's own, does not even need it passed in as argument; and for Gtk,
nothing changes, a string can be send and it does not need to be
propertized.

I've sent yesterday patch in another thread; I can resend in this one if
it is preferable.

Where do I find the mouse motion callback for tooltips? 

The idea is to not dismiss the tooltip frame during the timer period so
that user have time to tick the checkbox. When timer times out then the
tooltip frame can be dismissed. And if checkbox was ticked, the frame
will be dismissed when user uncheck the box.

This also leaves question how it will behave if a tooltip frame is live
on the screen and another tooltip frame is "requested". I haven't looked
into C code to see if multiple tooltip frames can be live or not; can
take a look after the mouse motion callback is fixed.

Today I have also removed some unnecessary 'propertize' call, but it is
not essential so I can send it in later.

Re: Sv: Sticky tooltips

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 05 Oct 2020 11:27:15 +0200
> 
> Where do I find the mouse motion callback for tooltips? 

I don't understand the question, sorry.  What is this callback you are
looking for? what is it supposed to do?

> This also leaves question how it will behave if a tooltip frame is live
> on the screen and another tooltip frame is "requested".

In that case we pop down the previous tooltip, AFAIR.  There can be
only one tooltip active at any given time.

Re: Sv: Sticky tooltips

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 05 Oct 2020 11:27:15 +0200
>> 
>> Where do I find the mouse motion callback for tooltips? 
>
> I don't understand the question, sorry.  What is this callback you are
> looking for? what is it supposed to do?

Tooltip frame is hidden as soon as mouse moves. I wish to suspend that
behaviour while a timer is active; must be some mouse motion event; I am
not sure where to look for it; where is it defined.

>> This also leaves question how it will behave if a tooltip frame is live
>> on the screen and another tooltip frame is "requested".
>
> In that case we pop down the previous tooltip, AFAIR.  There can be
> only one tooltip active at any given time.

Yes. I think it can be hacked in x-show-tip: will have to check if a
sticky tooltip is enabled. I can save it as buffer local variable in the
buffer, so it could be read in x-show-tip which then can either
delete/re-use frame or create a new frame.

Re: Sv: Sticky tooltips

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 05 Oct 2020 12:18:50 +0200
> 
> >> Where do I find the mouse motion callback for tooltips? 
> >
> > I don't understand the question, sorry.  What is this callback you are
> > looking for? what is it supposed to do?
> 
> Tooltip frame is hidden as soon as mouse moves.

Not as soon as mouse moves, as soon as mouse moves off the display
element that is described by the tooltip.  At least that's what
happens with native tooltips (maybe GTK tips behave differently).

This is not done by a callback, this is done by tooltip-show-help when
it is called with a null string or a string different from the one
displayed last.

Re: Sv: Sticky tooltips

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 05 Oct 2020 12:18:50 +0200
>> 
>> >> Where do I find the mouse motion callback for tooltips? 
>> >
>> > I don't understand the question, sorry.  What is this callback you are
>> > looking for? what is it supposed to do?
>> 
>> Tooltip frame is hidden as soon as mouse moves.
>
> Not as soon as mouse moves, as soon as mouse moves off the display
> element that is described by the tooltip.  At least that's what
> happens with native tooltips (maybe GTK tips behave differently).
You are correct; I wasn't paying attention to details.

> This is not done by a callback, this is done by tooltip-show-help when
> it is called with a null string or a string different from the one
> displayed last.

Allright; acknowledged; thnks. I'll take more look at it.