Fix some tooltip related problems

Fix some tooltip related problems

[martin rudalics]

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

I intend to apply the attached patch to master.  Its ChangeLog goes
as below.  Comments and suggestions welcome.

Thanks, martin

-------------------------------------------------------------------

Fix some tooltip related problems

Replace 'tooltip' frame parameter with a 'tooltip' member in
the frame structure.  For GTK+ builds use 'tip_last_frame' to
find the frame for which the currently visible tooltip was
made.  For modeline help-echoing have tooltips show applicable
actions only.

* lisp/bindings.el (mode-line-default-help-echo): New function
as default value of homonymous option.
* src/dispextern.h (tip_frame, tip_window): Remove
declarations.
* src/frame.c (make_frame): Initialize new frame structure
member 'tooltip'.
(Fframe_list, other_frames): Rewrite with new macro
FRAME_TOOLTIP_P.
(syms_of_frame): Remove Qtooltip.
* src/frame.h (struct frame): New member 'tooltip'.
(FRAME_TOOLTIP_P): New macro.
* src/gtkutil.c (xg_prepare_tooltip, xg_hide_tooltip): Rewrite
using boolean return values.
* src/nsfns.m (tip_frame): Remove declaration.
* src/w32fns.c (w32_display_monitor_attributes_list)
(w32_display_monitor_attributes_list_fallback): Rewrite with
new macro FRAME_TOOLTIP_P.
(tip_last_string, tip_last_frame, tip_last_parms): New Lisp
scalars replacing Lisp vector last_show_tip_args.
(x_create_tip_frame): Set new frame's 'tooltip' structure
member to true, remove setting of Qtooltip frame parameter.
(x_hide_tip): Additionally test tip_frame for liveness.
(Fx_show_tip): Handle last_show_tip_args to tip_last_frame,
tip_last_string and tip_last_parms conversion.
(syms_of_w32fns): staticpro tip_last_frame, tip_last_string
and tip_last_parms instead of last_show_tip_args.
* src/w32term.c (w32_read_socket, x_new_font): Rewrite with
new macro FRAME_TOOLTIP_P.
* src/w32term.h (tip_window): Add external declaration.
* src/xdisp.c (x_consider_frame_title, prepare_menu_bars)
(should_produce_line_number): Rewrite with new macro
FRAME_TOOLTIP_P.
(note_mode_line_or_margin_highlight): If
`mode-line-default-help-echo' specifies a function, call it to
produce help echo string.
* src/xfns.c (x_make_monitor_attribute_list)
(Fx_display_monitor_attributes_list): Rewrite with
new macro FRAME_TOOLTIP_P.
(tip_last_string, tip_last_frame, tip_last_parms): New Lisp
scalars replacing Lisp vector last_show_tip_args.
(x_create_tip_frame): Set new frame's 'tooltip' structure
member to true, remove setting of Qtooltip frame parameter.
(x_hide_tip): Rewrite with additional tests of frames for
liveness and taking into account that for GTK+ tips the
reference frame is now stored in tip_last_frame instead of
tip_frame.
(Fx_show_tip): Handle last_show_tip_args to tip_last_frame,
tip_last_string and tip_last_parms conversion.  For GTK+ store
FRAME argument in tip_last-frame.
(syms_of_xfns): staticpro tip_last_frame, tip_last_string
and tip_last_parms instead of last_show_tip_args.
* src/xterm.c (x_update_begin, handle_one_xevent, x_new_font)
(x_set_window_size): Rewrite with new macro FRAME_TOOLTIP_P.
* src/xterm.h (tip_window): Add external declaration.

[-- Attachment #2: tooltip.diff --]
[-- Type: text/plain, Size: 40586 bytes --]

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 8375bb9..c806cae 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -124,17 +124,56 @@ mode-line-eol-desc
 \f
 ;;; Mode line contents

-(defcustom mode-line-default-help-echo
-  "mouse-1: Select (drag to resize)\n\
-mouse-2: Make current window occupy the whole frame\n\
-mouse-3: Remove current window from display"
+(defun mode-line-default-help-echo (window)
+  "Return default help echo text for WINDOW's mode-line."
+  (let* ((frame (window-frame window))
+         (line-1a
+          ;; Show text to select window only if the window is not
+          ;; selected.
+          (not (eq window (frame-selected-window frame))))
+         (line-1b
+          ;; Show text to drag modeline if and only if it can be done.
+          (or (window-in-direction 'below window)
+              (let ((mini-window (minibuffer-window frame)))
+                (and (eq frame (window-frame mini-window))
+                     (or (minibuffer-window-active-p mini-window)
+                         (not resize-mini-windows))))))
+         (line-2
+          ;; Show text make window occupy the whole frame
+          ;; only if it doesn't already do that.
+          (not (eq window (frame-root-window frame))))
+         (line-3
+          ;; Show text to delete window only if that's possible.
+          (not (eq window (frame-root-window frame)))))
+    (when (or line-1a line-1b line-2 line-3)
+      (concat
+       (when (or line-1a line-1b)
+         (concat
+          "mouse-1: "
+          (when line-1a "Select")
+          (when line-1b
+            (if line-1a " (drag to resize)" "Drag to resize"))
+          (when (or line-2 line-3) "\n")))
+       (when line-2
+         (concat
+          "mouse-2: Make window occupy whole frame"
+          (when line-3 "\n")))
+       (when line-3
+         "mouse-3: Remove window from frame")))))
+
+(defcustom mode-line-default-help-echo #'mode-line-default-help-echo
   "Default help text for the mode line.
 If the value is a string, it specifies the tooltip or echo area
 message to display when the mouse is moved over the mode line.
-If the text at the mouse position has a `help-echo' text
-property, that overrides this variable."
-  :type '(choice (const :tag "No help" :value nil) string)
-  :version "24.3"
+If the value is a function, call that function with one argument
+- the window whose mode-line to display.  If the text at the
+mouse position has a `help-echo' text property, that overrides
+this variable."
+  :type '(choice
+          (const :tag "No help" :value nil)
+          function
+          string)
+  :version "27.1"
   :group 'mode-line)

 (defvar mode-line-front-space '(:eval (if (display-graphic-p) " " "-"))
diff --git a/src/dispextern.h b/src/dispextern.h
index 25bd6b2..441361b 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3452,15 +3452,6 @@ int face_at_string_position (struct window *, Lisp_Object, ptrdiff_t, ptrdiff_t,
 void x_implicitly_set_name (struct frame *, Lisp_Object, Lisp_Object);
 void x_change_tool_bar_height (struct frame *f, int);

-/* The frame used to display a tooltip.
-
-   Note: In a GTK build with non-zero x_gtk_use_system_tooltips, this
-   variable holds the frame that shows the tooltip, not the frame of
-   the tooltip itself, so checking whether a frame is a tooltip frame
-   cannot just compare the frame to what this variable holds.  */
-extern Lisp_Object tip_frame;
-
-extern Window tip_window;
 extern frame_parm_handler x_frame_parm_handlers[];

 extern void start_hourglass (void);
diff --git a/src/frame.c b/src/frame.c
index 1c6289a..73b4b4e 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -832,6 +832,7 @@ struct frame *
   f->no_focus_on_map = false;
   f->no_accept_focus = false;
   f->z_group = z_group_none;
+  f->tooltip = false;
 #if ! defined (USE_GTK) && ! defined (HAVE_NS)
   f->last_tool_bar_item = -1;
 #endif
@@ -1467,20 +1468,21 @@ of them (the selected terminal frame) is actually displayed.
 \f
 DEFUN ("frame-list", Fframe_list, Sframe_list,
        0, 0, 0,
-       doc: /* Return a list of all live frames.  */)
+       doc: /* Return a list of all live frames.
+The return value does not include any tooltip frame.  */)
   (void)
 {
-  Lisp_Object frames;
-  frames = Fcopy_sequence (Vframe_list);
 #ifdef HAVE_WINDOW_SYSTEM
-  if (FRAMEP (tip_frame)
-#ifdef USE_GTK
-      && !NILP (Fframe_parameter (tip_frame, Qtooltip))
-#endif
-      )
-    frames = Fdelq (tip_frame, frames);
-#endif
-  return frames;
+  Lisp_Object list = Qnil, tail, frame;
+
+  FOR_EACH_FRAME (tail, frame)
+    if (!FRAME_TOOLTIP_P (XFRAME (frame)))
+      list = Fcons (frame, list);
+  /* Reverse list for consistency with the !HAVE_WINDOW_SYSTEM case.  */
+  return Fnreverse (list);
+#else /* !HAVE_WINDOW_SYSTEM */
+  return Fcopy_sequence (Vframe_list);
+#endif /* HAVE_WINDOW_SYSTEM */
 }

 DEFUN ("frame-parent", Fframe_parent, Sframe_parent,
@@ -1711,7 +1713,8 @@ of them (the selected terminal frame) is actually displayed.
  * other_frames:
  *
  * Return true if there exists at least one visible or iconified frame
- * but F.  Return false otherwise.
+ * but F.  Tooltip frames do not qualify as candidates.  Return false
+ * if no such frame exists.
  *
  * INVISIBLE true means we are called from make_frame_invisible where
  * such a frame must be visible or iconified.  INVISIBLE nil means we
@@ -1725,7 +1728,6 @@ of them (the selected terminal frame) is actually displayed.
 other_frames (struct frame *f, bool invisible, bool force)
 {
   Lisp_Object frames, frame, frame1;
-  struct frame *f1;
   Lisp_Object minibuffer_window = FRAME_MINIBUF_WINDOW (f);

   XSETFRAME (frame, f);
@@ -1735,7 +1737,8 @@ of them (the selected terminal frame) is actually displayed.

   FOR_EACH_FRAME (frames, frame1)
     {
-      f1 = XFRAME (frame1);
+      struct frame *f1 = XFRAME (frame1);
+
       if (f != f1)
 	{
 	  /* Verify that we can still talk to the frame's X window, and
@@ -1744,7 +1747,7 @@ of them (the selected terminal frame) is actually displayed.
 	  if (FRAME_WINDOW_P (f1))
 	    x_sync (f1);
 #endif
-	  if (NILP (Fframe_parameter (frame1, Qtooltip))
+	  if (!FRAME_TOOLTIP_P (f1)
 	      /* Tooltips and child frames count neither for
 		 invisibility nor for deletions.  */
 	      && !FRAME_PARENT_FRAME (f1)
@@ -1877,7 +1880,7 @@ of them (the selected terminal frame) is actually displayed.
 	}
     }

-  is_tooltip_frame = !NILP (Fframe_parameter (frame, Qtooltip));
+  is_tooltip_frame = FRAME_TOOLTIP_P (f);

   /* Run `delete-frame-functions' unless FORCE is `noelisp' or
      frame is a tooltip.  FORCE is set to `noelisp' when handling
@@ -1925,27 +1928,31 @@ of them (the selected terminal frame) is actually displayed.
 	 Do not call next_frame here because it may loop forever.
 	 See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15025.  */
       FOR_EACH_FRAME (tail, frame1)
-	if (!EQ (frame, frame1)
-	    && NILP (Fframe_parameter (frame1, Qtooltip))
-	    && (FRAME_TERMINAL (XFRAME (frame))
-		== FRAME_TERMINAL (XFRAME (frame1)))
-	    && FRAME_VISIBLE_P (XFRAME (frame1)))
-         break;
+	{
+	  struct frame *f1 = XFRAME (frame1);
+
+	  if (!EQ (frame, frame1)
+	      && !FRAME_TOOLTIP_P (f1)
+	      && FRAME_TERMINAL (f) == FRAME_TERMINAL (f1)
+	      && FRAME_VISIBLE_P (f1))
+	    break;
+	}

       /* If there is none, find *some* other frame.  */
       if (NILP (frame1) || EQ (frame1, frame))
 	{
 	  FOR_EACH_FRAME (tail, frame1)
 	    {
+	      struct frame *f1 = XFRAME (frame1);
+
 	      if (!EQ (frame, frame1)
-		  && FRAME_LIVE_P (XFRAME (frame1))
-		  && NILP (Fframe_parameter (frame1, Qtooltip)))
+		  && FRAME_LIVE_P (f1)
+		  && !FRAME_TOOLTIP_P (f1))
 		{
-		  /* Do not change a text terminal's top-frame.  */
-		  struct frame *f1 = XFRAME (frame1);
 		  if (FRAME_TERMCAP_P (f1) || FRAME_MSDOS_P (f1))
 		    {
 		      Lisp_Object top_frame = FRAME_TTY (f1)->top_frame;
+
 		      if (!EQ (top_frame, frame))
 			frame1 = top_frame;
 		    }
@@ -5617,7 +5624,6 @@ or a list (- N) meaning -N pixels relative to bottom/right corner.
   DEFSYM (Qgeometry, "geometry");
   DEFSYM (Qicon_left, "icon-left");
   DEFSYM (Qicon_top, "icon-top");
-  DEFSYM (Qtooltip, "tooltip");
   DEFSYM (Quser_position, "user-position");
   DEFSYM (Quser_size, "user-size");
   DEFSYM (Qwindow_id, "window-id");
diff --git a/src/frame.h b/src/frame.h
index 402d6c0..2c9c414 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -342,6 +342,9 @@ struct frame
   ENUM_BF (output_method) output_method : 3;

 #ifdef HAVE_WINDOW_SYSTEM
+  /* True if this frame is a tooltip frame.  */
+  bool_bf tooltip : 1;
+
   /* See FULLSCREEN_ enum on top.  */
   ENUM_BF (fullscreen_type) want_fullscreen : 4;

@@ -351,9 +354,7 @@ struct frame

   /* Nonzero if we should actually display horizontal scroll bars on this frame.  */
   bool_bf horizontal_scroll_bars : 1;
-#endif /* HAVE_WINDOW_SYSTEM */

-#if defined (HAVE_WINDOW_SYSTEM)
   /* True if this is an undecorated frame.  */
   bool_bf undecorated : 1;

@@ -967,6 +968,7 @@ struct frame
 #define FRAME_Z_GROUP_ABOVE_SUSPENDED(f)	\
   ((f)->z_group == z_group_above_suspended)
 #define FRAME_Z_GROUP_BELOW(f) ((f)->z_group == z_group_below)
+#define FRAME_TOOLTIP_P(f) ((f)->tooltip)
 #ifdef NS_IMPL_COCOA
 #define FRAME_NS_APPEARANCE(f) ((f)->ns_appearance)
 #define FRAME_NS_TRANSPARENT_TITLEBAR(f) ((f)->ns_transparent_titlebar)
@@ -983,6 +985,7 @@ struct frame
 #define FRAME_Z_GROUP_NONE(f) ((void) (f), true)
 #define FRAME_Z_GROUP_ABOVE(f) ((void) (f), false)
 #define FRAME_Z_GROUP_BELOW(f) ((void) (f), false)
+#define FRAME_TOOLTIP_P(f) ((void) f, false)
 #endif /* HAVE_WINDOW_SYSTEM */

 /* Whether horizontal scroll bars are currently enabled for frame F.  */
diff --git a/src/gtkutil.c b/src/gtkutil.c
index 047417f..34c0fcc 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -687,6 +687,7 @@ struct xg_frame_tb_info
       g_signal_connect (x->ttip_lbl, "hierarchy-changed",
                         G_CALLBACK (hierarchy_ch_cb), f);
     }
+
   return FALSE;
 }

@@ -713,7 +714,8 @@ struct xg_frame_tb_info
   GtkRequisition req;
   Lisp_Object encoded_string;

-  if (!x->ttip_lbl) return 0;
+  if (!x->ttip_lbl)
+    return FALSE;

   block_input ();
   encoded_string = ENCODE_UTF_8 (string);
@@ -745,7 +747,7 @@ struct xg_frame_tb_info

   unblock_input ();

-  return 1;
+  return TRUE;
 #endif /* USE_GTK_TOOLTIP */
 }

@@ -768,18 +770,18 @@ struct xg_frame_tb_info
 #endif
 }

+
 /* Hide tooltip if shown.  Do nothing if not shown.
    Return true if tip was hidden, false if not (i.e. not using
    system tooltips).  */
-
 bool
 xg_hide_tooltip (struct frame *f)
 {
-  bool ret = 0;
 #ifdef USE_GTK_TOOLTIP
   if (f->output_data.x->ttip_window)
     {
       GtkWindow *win = f->output_data.x->ttip_window;
+
       block_input ();
       gtk_widget_hide (GTK_WIDGET (win));

@@ -792,10 +794,10 @@ struct xg_frame_tb_info
         }
       unblock_input ();

-      ret = 1;
+      return TRUE;
     }
 #endif
-  return ret;
+  return FALSE;
 }

 \f
diff --git a/src/nsfns.m b/src/nsfns.m
index d5049a7..4c8376e 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -2753,10 +2753,6 @@ and GNUstep implementations ("distributor-specific release
   return make_number (1 << min (dpyinfo->n_planes, 24));
 }

-
-/* Unused dummy def needed for compatibility. */
-Lisp_Object tip_frame;
-
 /* TODO: move to xdisp or similar */
 static void
 compute_tip_xy (struct frame *f,
diff --git a/src/w32fns.c b/src/w32fns.c
index ed375cd..55db4d5 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -6423,7 +6423,7 @@ DISPLAY should be either a frame or a display name (a string).
     {
       struct frame *f = XFRAME (frame);

-      if (FRAME_W32_P (f) && !EQ (frame, tip_frame))
+      if (FRAME_W32_P (f) && !FRAME_TOOLTIP_P (f))
 	{
 	  HMONITOR monitor =
 	    monitor_from_window_fn (FRAME_W32_WINDOW (f),
@@ -6510,7 +6510,7 @@ DISPLAY should be either a frame or a display name (a string).
     {
       struct frame *f = XFRAME (frame);

-      if (FRAME_W32_P (f) && !EQ (frame, tip_frame))
+      if (FRAME_W32_P (f) && !FRAME_TOOLTIP_P (f))
 	frames = Fcons (frame, frames);
     }
   attributes = Fcons (Fcons (Qframes, frames), attributes);
@@ -6916,20 +6916,25 @@ no value of TYPE (always string in the MS Windows case).  */)
 static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
 			    Lisp_Object, int, int, int *, int *);

-/* The frame of a currently visible tooltip.  */
-
+/* The frame of the currently visible tooltip.  */
 Lisp_Object tip_frame;

-/* If non-nil, a timer started that hides the last tooltip when it
-   fires.  */
+/* The window-system window corresponding to the frame of the
+   currently visible tooltip.  */
+Window tip_window;

+/* A timer that hides or deletes the currently visible tooltip when it
+   fires.  */
 Lisp_Object tip_timer;
-Window tip_window;

-/* If non-nil, a vector of 3 elements containing the last args
-   with which x-show-tip was called.  See there.  */
+/* STRING argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_string;

-Lisp_Object last_show_tip_args;
+/* FRAME argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_frame;
+
+/* PARMS argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_parms;


 static void
@@ -7002,6 +7007,7 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,

   FRAME_FONTSET (f)  = -1;
   fset_icon_name (f, Qnil);
+  f->tooltip = true;

 #ifdef GLYPH_DEBUG
   image_cache_refcount =
@@ -7113,9 +7119,6 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
   SET_FRAME_LINES (f, 0);
   adjust_frame_size (f, width * FRAME_COLUMN_WIDTH (f),
 		     height * FRAME_LINE_HEIGHT (f), 0, true, Qtip_frame);
-  /* Add `tooltip' frame parameter's default value. */
-  if (NILP (Fframe_parameter (frame, Qtooltip)))
-    Fmodify_frame_parameters (frame, Fcons (Fcons (Qtooltip, Qt), Qnil));

   /* Set up faces after all frame parameters are known.  This call
      also merges in face attributes specified for new frames.
@@ -7261,7 +7264,17 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
     *root_x = min_x;
 }

-/* Hide tooltip.  Delete its frame if DELETE is true.  */
+/**
+ * x_hide_tip:
+ *
+ * Hide currently visible tooltip and cancel its timer.
+ *
+ * This will try to make tooltip_frame invisible (if DELETE is false)
+ * or delete tooltip_frame (if DELETE is true).
+ *
+ * Return Qt if the tooltip was either deleted or made invisible, Qnil
+ * otherwise.
+ */
 static Lisp_Object
 x_hide_tip (bool delete)
 {
@@ -7286,15 +7299,20 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,

       if (FRAMEP (tip_frame))
 	{
-	  if (delete)
+	  if (FRAME_LIVE_P (XFRAME (tip_frame)))
 	    {
-	      delete_frame (tip_frame, Qnil);
-	      tip_frame = Qnil;
+	      if (delete)
+		{
+		  delete_frame (tip_frame, Qnil);
+		  tip_frame = Qnil;
+		}
+	      else
+		x_make_frame_invisible (XFRAME (tip_frame));
+
+	      was_open = Qt;
 	    }
 	  else
-	    x_make_frame_invisible (XFRAME (tip_frame));
-
-	  was_open = Qt;
+	    tip_frame = Qnil;
 	}
       else
 	tip_frame = Qnil;
@@ -7334,7 +7352,8 @@ with offset DY added (default is -10).

 A tooltip's maximum size is specified by `x-max-tooltip-size'.
 Text larger than the specified size is clipped.  */)
-  (Lisp_Object string, Lisp_Object frame, Lisp_Object parms, Lisp_Object timeout, Lisp_Object dx, Lisp_Object dy)
+  (Lisp_Object string, Lisp_Object frame, Lisp_Object parms,
+   Lisp_Object timeout, Lisp_Object dx, Lisp_Object dy)
 {
   struct frame *tip_f;
   struct window *w;
@@ -7345,8 +7364,7 @@ with offset DY added (default is -10).
   int old_windows_or_buffers_changed = windows_or_buffers_changed;
   ptrdiff_t count = SPECPDL_INDEX ();
   ptrdiff_t count_1;
-  Lisp_Object window, size;
-  Lisp_Object tip_buf;
+  Lisp_Object window, size, tip_buf;
   AUTO_STRING (tip, " *tip*");

   specbind (Qinhibit_redisplay, Qt);
@@ -7368,19 +7386,12 @@ with offset DY added (default is -10).
   else
     CHECK_NUMBER (dy);

-  if (NILP (last_show_tip_args))
-    last_show_tip_args = Fmake_vector (make_number (3), Qnil);
-
   if (FRAMEP (tip_frame) && FRAME_LIVE_P (XFRAME (tip_frame)))
     {
-      Lisp_Object last_string = AREF (last_show_tip_args, 0);
-      Lisp_Object last_frame = AREF (last_show_tip_args, 1);
-      Lisp_Object last_parms = AREF (last_show_tip_args, 2);
-
       if (FRAME_VISIBLE_P (XFRAME (tip_frame))
-	  && EQ (frame, last_frame)
-	  && !NILP (Fequal_including_properties (last_string, string))
-	  && !NILP (Fequal (last_parms, parms)))
+	  && EQ (frame, tip_last_frame)
+	  && !NILP (Fequal_including_properties (string, tip_last_string))
+	  && !NILP (Fequal (parms, tip_last_parms)))
 	{
 	  /* Only DX and DY have changed.  */
 	  tip_f = XFRAME (tip_frame);
@@ -7414,14 +7425,14 @@ with offset DY added (default is -10).

 	  goto start_timer;
 	}
-      else if (tooltip_reuse_hidden_frame && EQ (frame, last_frame))
+      else if (tooltip_reuse_hidden_frame && EQ (frame, tip_last_frame))
 	{
 	  bool delete = false;
 	  Lisp_Object tail, elt, parm, last;

 	  /* Check if every parameter in PARMS has the same value in
-	     last_parms.  This may destruct last_parms which, however,
-	     will be recreated below.  */
+	     tip_last_parms.  This may destruct tip_last_parms
+	     which, however, will be recreated below.  */
 	  for (tail = parms; CONSP (tail); tail = XCDR (tail))
 	    {
 	      elt = XCAR (tail);
@@ -7431,7 +7442,7 @@ with offset DY added (default is -10).
 	      if (!EQ (parm, Qleft) && !EQ (parm, Qtop)
 		  && !EQ (parm, Qright) && !EQ (parm, Qbottom))
 		{
-		  last = Fassq (parm, last_parms);
+		  last = Fassq (parm, tip_last_parms);
 		  if (NILP (Fequal (Fcdr (elt), Fcdr (last))))
 		    {
 		      /* We lost, delete the old tooltip.  */
@@ -7439,15 +7450,17 @@ with offset DY added (default is -10).
 		      break;
 		    }
 		  else
-		    last_parms = call2 (Qassq_delete_all, parm, last_parms);
+		    tip_last_parms =
+		      call2 (Qassq_delete_all, parm, tip_last_parms);
 		}
 	      else
-		last_parms = call2 (Qassq_delete_all, parm, last_parms);
+		tip_last_parms =
+		  call2 (Qassq_delete_all, parm, tip_last_parms);
 	    }

-	  /* Now check if there's a parameter left in last_parms with a
+	  /* Now check if there's a parameter left in tip_last_parms with a
 	     non-nil value.  */
-	  for (tail = last_parms; CONSP (tail); tail = XCDR (tail))
+	  for (tail = tip_last_parms; CONSP (tail); tail = XCDR (tail))
 	    {
 	      elt = XCAR (tail);
 	      parm = Fcar (elt);
@@ -7468,9 +7481,9 @@ with offset DY added (default is -10).
   else
     x_hide_tip (true);

-  ASET (last_show_tip_args, 0, string);
-  ASET (last_show_tip_args, 1, frame);
-  ASET (last_show_tip_args, 2, parms);
+  tip_last_frame = frame;
+  tip_last_string = string;
+  tip_last_parms = parms;

   /* Block input until the tip has been fully drawn, to avoid crashes
      when drawing tips in menus.  */
@@ -7486,7 +7499,8 @@ with offset DY added (default is -10).
       if (NILP (Fassq (Qborder_width, parms)))
 	parms = Fcons (Fcons (Qborder_width, make_number (1)), parms);
       if (NILP (Fassq (Qborder_color, parms)))
-	parms = Fcons (Fcons (Qborder_color, build_string ("lightyellow")), parms);
+	parms = Fcons (Fcons (Qborder_color, build_string ("lightyellow")),
+		       parms);
       if (NILP (Fassq (Qbackground_color, parms)))
 	parms = Fcons (Fcons (Qbackground_color, build_string ("lightyellow")),
 		       parms);
@@ -10805,9 +10819,12 @@ successive mouse move (or scroll bar drag) events before they are
   staticpro (&tip_timer);
   tip_frame = Qnil;
   staticpro (&tip_frame);
-
-  last_show_tip_args = Qnil;
-  staticpro (&last_show_tip_args);
+  tip_last_frame = Qnil;
+  staticpro (&tip_last_frame);
+  tip_last_string = Qnil;
+  staticpro (&tip_last_string);
+  tip_last_parms = Qnil;
+  staticpro (&tip_last_parms);

   defsubr (&Sx_file_dialog);
 #ifdef WINDOWSNT
diff --git a/src/w32term.c b/src/w32term.c
index db4ccf5..137c798 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5569,7 +5569,7 @@ static void x_horizontal_scroll_bar_report_motion (struct frame **, Lisp_Object
 	struct frame *f = XFRAME (frame);
 	/* The tooltip has been drawn already.  Avoid the
 	   SET_FRAME_GARBAGED below.  */
-	if (EQ (frame, tip_frame))
+	if (FRAME_TOOLTIP_P (f))
 	  continue;

 	/* Check "visible" frames and mark each as obscured or not.
@@ -6046,7 +6046,7 @@ static void x_horizontal_scroll_bar_report_motion (struct frame **, Lisp_Object
       /* Don't change the size of a tip frame; there's no point in
 	 doing it because it's done in Fx_show_tip, and it leads to
 	 problems because the tip frame has no widget.  */
-      if (NILP (tip_frame) || XFRAME (tip_frame) != f)
+      if (!FRAME_TOOLTIP_P (f))
 	adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
 			   FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
 			   false, Qfont);
diff --git a/src/w32term.h b/src/w32term.h
index e500b73..c69bebe 100644
--- a/src/w32term.h
+++ b/src/w32term.h
@@ -817,6 +817,8 @@ typedef BOOL (WINAPI * AppendMenuW_Proc) (
 extern int w32_system_caret_hdr_height;
 extern int w32_system_caret_mode_height;

+extern Window tip_window;
+
 #ifdef _MSC_VER
 #ifndef EnumSystemLocales
 /* MSVC headers define these only for _WIN32_WINNT >= 0x0500.  */
diff --git a/src/xdisp.c b/src/xdisp.c
index 59fa00e..d2bb47f 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -11866,7 +11866,7 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
   if ((FRAME_WINDOW_P (f)
        || FRAME_MINIBUF_ONLY_P (f)
        || f->explicit_name)
-      && NILP (Fframe_parameter (frame, Qtooltip)))
+      && !FRAME_TOOLTIP_P (f))
     {
       /* Do we have more than one visible frame on this X display?  */
       Lisp_Object tail, other_frame, fmt;
@@ -11883,8 +11883,8 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
 	  if (tf != f
 	      && FRAME_KBOARD (tf) == FRAME_KBOARD (f)
 	      && !FRAME_MINIBUF_ONLY_P (tf)
-	      && !EQ (other_frame, tip_frame)
 	      && !FRAME_PARENT_FRAME (tf)
+	      && !FRAME_TOOLTIP_P (tf)
 	      && (FRAME_VISIBLE_P (tf) || FRAME_ICONIFIED_P (tf)))
 	    break;
 	}
@@ -11953,13 +11953,6 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
 {
   bool all_windows = windows_or_buffers_changed || update_mode_lines;
   bool some_windows = REDISPLAY_SOME_P ();
-  Lisp_Object tooltip_frame;
-
-#ifdef HAVE_WINDOW_SYSTEM
-  tooltip_frame = tip_frame;
-#else
-  tooltip_frame = Qnil;
-#endif

   if (FUNCTIONP (Vpre_redisplay_function))
     {
@@ -12000,7 +11993,7 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
 	      && !XBUFFER (w->contents)->text->redisplay)
 	    continue;

-	  if (!EQ (frame, tooltip_frame)
+	  if (!FRAME_TOOLTIP_P (f)
 	      && !FRAME_PARENT_FRAME (f)
 	      && (FRAME_ICONIFIED_P (f)
 		  || FRAME_VISIBLE_P (f) == 1
@@ -12038,7 +12031,7 @@ static void ATTRIBUTE_FORMAT_PRINTF (1, 0)
 	  struct window *w = XWINDOW (FRAME_SELECTED_WINDOW (f));

 	  /* Ignore tooltip frame.  */
-	  if (EQ (frame, tooltip_frame))
+	  if (FRAME_TOOLTIP_P (f))
 	    continue;

 	  if (some_windows
@@ -21160,13 +21153,7 @@ struct glyph_row *

 #ifdef HAVE_WINDOW_SYSTEM
   /* Don't display line number in tooltip frames.  */
-  if (FRAMEP (tip_frame) && EQ (WINDOW_FRAME (it->w), tip_frame)
-#ifdef USE_GTK
-      /* GTK builds store in tip_frame the frame that shows the tip,
-	 so we need an additional test.  */
-      && !NILP (Fframe_parameter (tip_frame, Qtooltip))
-#endif
-      )
+  if (FRAME_TOOLTIP_P (XFRAME (WINDOW_FRAME (it->w))))
     return false;
 #endif

@@ -30841,9 +30828,11 @@ A polygon is a cons (poly . [x0 y0 x1 y1 ...]) where each pair in the
 		= buffer_local_value (Qmode_line_default_help_echo,
 				      w->contents);

-	      if (STRINGP (default_help))
+	      if (FUNCTIONP (default_help) || STRINGP (default_help))
 		{
-		  help_echo_string = default_help;
+		  help_echo_string = (FUNCTIONP (default_help)
+				      ? safe_call1 (default_help, window)
+				      : default_help);
 		  XSETWINDOW (help_echo_window, w);
 		  help_echo_object = Qnil;
 		  help_echo_pos = -1;
diff --git a/src/xfns.c b/src/xfns.c
index 12b7d83..0176e2b 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -4612,8 +4612,9 @@ struct mouse_cursor_data {
     {
       struct frame *f = XFRAME (frame);

-      if (FRAME_X_P (f) && FRAME_DISPLAY_INFO (f) == dpyinfo
-	  && !EQ (frame, tip_frame))
+      if (FRAME_X_P (f)
+	  && FRAME_DISPLAY_INFO (f) == dpyinfo
+	  && !FRAME_TOOLTIP_P (f))
 	{
 	  int i = x_get_monitor_for_frame (f, monitors, n_monitors);
 	  ASET (monitor_frames, i, Fcons (frame, AREF (monitor_frames, i)));
@@ -4914,12 +4915,9 @@ struct mouse_cursor_data {
     {
       struct frame *f = XFRAME (frame);

-      if (FRAME_X_P (f) && FRAME_DISPLAY_INFO (f) == dpyinfo
-	  && !(EQ (frame, tip_frame)
-#ifdef USE_GTK
-	       && !NILP (Fframe_parameter (tip_frame, Qtooltip))
-#endif
-	       ))
+      if (FRAME_X_P (f)
+	  && FRAME_DISPLAY_INFO (f) == dpyinfo
+	  && !FRAME_TOOLTIP_P (f))
 	{
 	  GdkWindow *gwin = gtk_widget_get_window (FRAME_GTK_WIDGET (f));

@@ -6052,22 +6050,27 @@ no value of TYPE (always string in the MS Windows case).  */)
  ***********************************************************************/

 static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
-                            Lisp_Object, int, int, int *, int *);
-
-/* The frame of a currently visible tooltip.  */
+			    Lisp_Object, int, int, int *, int *);

+/* The frame of the currently visible tooltip.  */
 Lisp_Object tip_frame;

-/* If non-nil, a timer started that hides the last tooltip when it
+/* The window-system window corresponding to the frame of the
+   currently visible tooltip.  */
+Window tip_window;
+
+/* A timer that hides or deletes the currently visible tooltip when it
    fires.  */
+Lisp_Object tip_timer;

-static Lisp_Object tip_timer;
-Window tip_window;
+/* STRING argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_string;

-/* If non-nil, a vector of 3 elements containing the last args
-   with which x-show-tip was called.  See there.  */
+/* FRAME argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_frame;

-static Lisp_Object last_show_tip_args;
+/* PARMS argument of last `x-show-tip' call.  */
+Lisp_Object tip_last_parms;


 static void
@@ -6141,6 +6144,7 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
   f->output_data.x->white_relief.pixel = -1;
   f->output_data.x->black_relief.pixel = -1;

+  f->tooltip = true;
   fset_icon_name (f, Qnil);
   FRAME_DISPLAY_INFO (f) = dpyinfo;
   f->output_data.x->parent_desc = FRAME_DISPLAY_INFO (f)->root_window;
@@ -6324,13 +6328,6 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
   SET_FRAME_LINES (f, 0);
   change_frame_size (f, width, height, true, false, false, false);

-  /* Add `tooltip' frame parameter's default value. */
-  if (NILP (Fframe_parameter (frame, Qtooltip)))
-    {
-      AUTO_FRAME_ARG (arg, Qtooltip, Qt);
-      Fmodify_frame_parameters (frame, arg);
-    }
-
   /* FIXME - can this be done in a similar way to normal frames?
      https://lists.gnu.org/r/emacs-devel/2007-10/msg00641.html */

@@ -6405,7 +6402,9 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
    the display in *ROOT_X, and *ROOT_Y.  */

 static void
-compute_tip_xy (struct frame *f, Lisp_Object parms, Lisp_Object dx, Lisp_Object dy, int width, int height, int *root_x, int *root_y)
+compute_tip_xy (struct frame *f,
+		Lisp_Object parms, Lisp_Object dx, Lisp_Object dy,
+		int width, int height, int *root_x, int *root_y)
 {
   Lisp_Object left, top, right, bottom;
   int win_x, win_y;
@@ -6502,7 +6501,19 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
 }


-/* Hide tooltip.  Delete its frame if DELETE is true.  */
+/**
+ * x_hide_tip:
+ *
+ * Hide currently visible tooltip and cancel its timer.
+ *
+ * If GTK+ system tooltips are used, this will try to hide the tooltip
+ * referenced by the x_output structure of tooltip_last_frame.  For
+ * Emacs tooltips this will try to make tooltip_frame invisible (if
+ * DELETE is false) or delete tooltip_frame (if DELETE is true).
+ *
+ * Return Qt if the tooltip was either deleted or made invisible, Qnil
+ * otherwise.
+ */
 static Lisp_Object
 x_hide_tip (bool delete)
 {
@@ -6512,10 +6523,17 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
       tip_timer = Qnil;
     }

-
-  if (NILP (tip_frame)
-      || (!delete && FRAMEP (tip_frame)
-	  && !FRAME_VISIBLE_P (XFRAME (tip_frame))))
+#ifdef USE_GTK
+  /* The GTK+ system tooltip window can be found via the x_output
+     structure of tip_last_frame, if it still exists.  */
+  if (x_gtk_use_system_tooltips && NILP (tip_last_frame))
+    return Qnil;
+  else if (!x_gtk_use_system_tooltips
+	   && (NILP (tip_frame)
+	       || (!delete
+		   && FRAMEP (tip_frame)
+		   && FRAME_LIVE_P (XFRAME (tip_frame))
+		   && !FRAME_VISIBLE_P (XFRAME (tip_frame)))))
     return Qnil;
   else
     {
@@ -6526,61 +6544,114 @@ static void compute_tip_xy (struct frame *, Lisp_Object, Lisp_Object,
       specbind (Qinhibit_redisplay, Qt);
       specbind (Qinhibit_quit, Qt);

-#ifdef USE_GTK
-      {
-	/* When using system tooltip, tip_frame is the Emacs frame on
-	   which the tip is shown.  */
-	struct frame *f = XFRAME (tip_frame);
-
-	if (FRAME_LIVE_P (f) && xg_hide_tooltip (f))
-	  {
-	    tip_frame = Qnil;
-	    was_open = Qt;
-	  }
-      }
-#endif
+      if (x_gtk_use_system_tooltips)
+	{
+	  /* The GTK+ system tooltip window is stored in the x_output
+	     structure of tip_last_frame.  */
+	  struct frame *f = XFRAME (tip_last_frame);

-      if (FRAMEP (tip_frame))
+	  if (FRAME_LIVE_P (f))
+	    {
+	      if (xg_hide_tooltip (f))
+		was_open = Qt;
+	    }
+	  else
+	    tip_last_frame = Qnil;
+	}
+      else
 	{
-	  if (delete)
+	  if (FRAMEP (tip_frame))
 	    {
-	      delete_frame (tip_frame, Qnil);
-	      tip_frame = Qnil;
+	      struct frame *f = XFRAME (tip_frame);
+
+	      if (FRAME_LIVE_P (f))
+		{
+		  if (delete)
+		    {
+		      delete_frame (tip_frame, Qnil);
+		      tip_frame = Qnil;
+		    }
+		  else
+		    x_make_frame_invisible (f);
+
+		  was_open = Qt;
+		}
+	      else
+		tip_frame = Qnil;
 	    }
 	  else
-	    x_make_frame_invisible (XFRAME (tip_frame));
+	    tip_frame = Qnil;
+	}
+
+      return unbind_to (count, was_open);
+    }
+#else /* not USE_GTK */
+  if (NILP (tip_frame)
+      || (!delete
+	  && FRAMEP (tip_frame)
+	  && FRAME_LIVE_P (XFRAME (tip_frame))
+	  && !FRAME_VISIBLE_P (XFRAME (tip_frame))))
+    return Qnil;
+  else
+    {
+      ptrdiff_t count;
+      Lisp_Object was_open = Qnil;
+
+      count = SPECPDL_INDEX ();
+      specbind (Qinhibit_redisplay, Qt);
+      specbind (Qinhibit_quit, Qt);
+
+      if (FRAMEP (tip_frame))
+	{
+	  struct frame *f = XFRAME (tip_frame);

-	  was_open = Qt;
+	  if (FRAME_LIVE_P (f))
+	    {
+	      if (delete)
+		{
+		  delete_frame (tip_frame, Qnil);
+		  tip_frame = Qnil;
+		}
+	      else
+		x_make_frame_invisible (XFRAME (tip_frame));

 #ifdef USE_LUCID
-	  /* Bloodcurdling hack alert: The Lucid menu bar widget's
-	     redisplay procedure is not called when a tip frame over
-	     menu items is unmapped.  Redisplay the menu manually...  */
-	  {
-	    Widget w;
-	    struct frame *f = SELECTED_FRAME ();
-	    if (FRAME_X_P (f) && FRAME_LIVE_P (f))
+	      /* Bloodcurdling hack alert: The Lucid menu bar widget's
+		 redisplay procedure is not called when a tip frame over
+		 menu items is unmapped.  Redisplay the menu manually...  */
 	      {
-		w = f->output_data.x->menubar_widget;
+		Widget w;
+		struct frame *f = SELECTED_FRAME ();

-		if (!DoesSaveUnders (FRAME_DISPLAY_INFO (f)->screen)
-		    && w != NULL)
+		if (FRAME_X_P (f) && FRAME_LIVE_P (f))
 		  {
-		    block_input ();
-		    xlwmenu_redisplay (w);
-		    unblock_input ();
+		    w = f->output_data.x->menubar_widget;
+
+		    if (!DoesSaveUnders (FRAME_DISPLAY_INFO (f)->screen)
+			&& w != NULL)
+		      {
+			block_input ();
+			xlwmenu_redisplay (w);
+			unblock_input ();
+		      }
 		  }
 	      }
-	  }
 #endif /* USE_LUCID */
+
+	      was_open = Qt;
+	    }
+	  else
+	    tip_frame = Qnil;
 	}
       else
 	tip_frame = Qnil;

       return unbind_to (count, was_open);
     }
+#endif /* USE_GTK */
 }

+
 DEFUN ("x-show-tip", Fx_show_tip, Sx_show_tip, 1, 6, 0,
        doc: /* Show STRING in a "tooltip" window on frame FRAME.
 A tooltip window is a small X window displaying a string.
@@ -6611,7 +6682,8 @@ with offset DY added (default is -10).

 A tooltip's maximum size is specified by `x-max-tooltip-size'.
 Text larger than the specified size is clipped.  */)
-  (Lisp_Object string, Lisp_Object frame, Lisp_Object parms, Lisp_Object timeout, Lisp_Object dx, Lisp_Object dy)
+  (Lisp_Object string, Lisp_Object frame, Lisp_Object parms,
+   Lisp_Object timeout, Lisp_Object dx, Lisp_Object dy)
 {
   struct frame *f, *tip_f;
   struct window *w;
@@ -6622,8 +6694,7 @@ with offset DY added (default is -10).
   int old_windows_or_buffers_changed = windows_or_buffers_changed;
   ptrdiff_t count = SPECPDL_INDEX ();
   ptrdiff_t count_1;
-  Lisp_Object window, size;
-  Lisp_Object tip_buf;
+  Lisp_Object window, size, tip_buf;
   AUTO_STRING (tip, " *tip*");

   specbind (Qinhibit_redisplay, Qt);
@@ -6662,36 +6733,27 @@ with offset DY added (default is -10).
         {
 	  compute_tip_xy (f, parms, dx, dy, width, height, &root_x, &root_y);
           xg_show_tooltip (f, root_x, root_y);
-          /* This is used in Fx_hide_tip.  */
-          XSETFRAME (tip_frame, f);
+	  tip_last_frame = frame;
         }
+
       unblock_input ();
       if (ok) goto start_timer;
     }
 #endif /* USE_GTK */

-  if (NILP (last_show_tip_args))
-    last_show_tip_args = Fmake_vector (make_number (3), Qnil);
-
   if (FRAMEP (tip_frame) && FRAME_LIVE_P (XFRAME (tip_frame)))
     {
-      Lisp_Object last_string = AREF (last_show_tip_args, 0);
-      Lisp_Object last_frame = AREF (last_show_tip_args, 1);
-      Lisp_Object last_parms = AREF (last_show_tip_args, 2);
-
       if (FRAME_VISIBLE_P (XFRAME (tip_frame))
-	  && EQ (frame, last_frame)
-	  && !NILP (Fequal_including_properties (last_string, string))
-	  && !NILP (Fequal (last_parms, parms)))
+	  && EQ (frame, tip_last_frame)
+	  && !NILP (Fequal_including_properties (tip_last_string, string))
+	  && !NILP (Fequal (tip_last_parms, parms)))
 	{
 	  /* Only DX and DY have changed.  */
 	  tip_f = XFRAME (tip_frame);
 	  if (!NILP (tip_timer))
 	    {
-	      Lisp_Object timer = tip_timer;
-
+	      call1 (Qcancel_timer, tip_timer);
 	      tip_timer = Qnil;
-	      call1 (Qcancel_timer, timer);
 	    }

 	  block_input ();
@@ -6703,15 +6765,14 @@ with offset DY added (default is -10).

 	  goto start_timer;
 	}
-      else if (tooltip_reuse_hidden_frame && EQ (frame, last_frame))
+      else if (tooltip_reuse_hidden_frame && EQ (frame, tip_last_frame))
 	{
 	  bool delete = false;
 	  Lisp_Object tail, elt, parm, last;

 	  /* Check if every parameter in PARMS has the same value in
-	     last_parms unless it should be ignored by means of
-	     Vtooltip_reuse_hidden_frame_parameters.  This may destruct
-	     last_parms which, however, will be recreated below.  */
+	     tip_last_parms.  This may destruct tip_last_parms which,
+	     however, will be recreated below.  */
 	  for (tail = parms; CONSP (tail); tail = XCDR (tail))
 	    {
 	      elt = XCAR (tail);
@@ -6721,7 +6782,7 @@ with offset DY added (default is -10).
 	      if (!EQ (parm, Qleft) && !EQ (parm, Qtop)
 		  && !EQ (parm, Qright) && !EQ (parm, Qbottom))
 		{
-		  last = Fassq (parm, last_parms);
+		  last = Fassq (parm, tip_last_parms);
 		  if (NILP (Fequal (Fcdr (elt), Fcdr (last))))
 		    {
 		      /* We lost, delete the old tooltip.  */
@@ -6729,17 +6790,18 @@ with offset DY added (default is -10).
 		      break;
 		    }
 		  else
-		    last_parms = call2 (Qassq_delete_all, parm, last_parms);
+		    tip_last_parms =
+		      call2 (Qassq_delete_all, parm, tip_last_parms);
 		}
 	      else
-		last_parms = call2 (Qassq_delete_all, parm, last_parms);
+		tip_last_parms =
+		  call2 (Qassq_delete_all, parm, tip_last_parms);
 	    }

-	  /* Now check if every parameter in what is left of last_parms
-	     with a non-nil value has an association in PARMS unless it
-	     should be ignored by means of
-	     Vtooltip_reuse_hidden_frame_parameters.  */
-	  for (tail = last_parms; CONSP (tail); tail = XCDR (tail))
+	  /* Now check if every parameter in what is left of
+	     tip_last_parms with a non-nil value has an association in
+	     PARMS.  */
+	  for (tail = tip_last_parms; CONSP (tail); tail = XCDR (tail))
 	    {
 	      elt = XCAR (tail);
 	      parm = Fcar (elt);
@@ -6760,9 +6822,9 @@ with offset DY added (default is -10).
   else
     x_hide_tip (true);

-  ASET (last_show_tip_args, 0, string);
-  ASET (last_show_tip_args, 1, frame);
-  ASET (last_show_tip_args, 2, parms);
+  tip_last_frame = frame;
+  tip_last_string = string;
+  tip_last_parms = parms;

   if (!FRAMEP (tip_frame) || !FRAME_LIVE_P (XFRAME (tip_frame)))
     {
@@ -7823,7 +7885,6 @@ FRAMES should be nil (the selected frame), a frame, or a list of
   defsubr (&Sx_display_list);
   defsubr (&Sx_synchronize);
   defsubr (&Sx_backspace_delete_keys_p);
-
   defsubr (&Sx_show_tip);
   defsubr (&Sx_hide_tip);
   defsubr (&Sx_double_buffered_p);
@@ -7831,9 +7892,12 @@ FRAMES should be nil (the selected frame), a frame, or a list of
   staticpro (&tip_timer);
   tip_frame = Qnil;
   staticpro (&tip_frame);
-
-  last_show_tip_args = Qnil;
-  staticpro (&last_show_tip_args);
+  tip_last_frame = Qnil;
+  staticpro (&tip_last_frame);
+  tip_last_string = Qnil;
+  staticpro (&tip_last_string);
+  tip_last_parms = Qnil;
+  staticpro (&tip_last_parms);

   defsubr (&Sx_uses_old_gtk_dialog);
 #if defined (USE_MOTIF) || defined (USE_GTK)
diff --git a/src/xterm.c b/src/xterm.c
index f771631..0a2068d 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -996,12 +996,7 @@ struct x_display_info *
 x_update_begin (struct frame *f)
 {
 #ifdef USE_CAIRO
-  if (! NILP (tip_frame) && XFRAME (tip_frame) == f
-      && ! FRAME_VISIBLE_P (f)
-#ifdef USE_GTK
-      && !NILP (Fframe_parameter (tip_frame, Qtooltip))
-#endif
-      )
+  if (FRAME_TOOLTIP_P (f) && !FRAME_VISIBLE_P (f))
     return;

   if (! FRAME_CR_SURFACE (f))
@@ -8091,7 +8086,7 @@ static void xembed_send_message (struct frame *f, Time,
       /* Redo the mouse-highlight after the tooltip has gone.  */
       if (event->xunmap.window == tip_window)
         {
-          tip_window = 0;
+          tip_window = None;
           x_redo_mouse_highlight (dpyinfo);
         }

@@ -8733,7 +8728,7 @@ static void xembed_send_message (struct frame *f, Time,

 #ifdef USE_X_TOOLKIT
           /* Tip frames are pure X window, set size for them.  */
-          if (! NILP (tip_frame) && XFRAME (tip_frame) == f)
+          if (FRAME_TOOLTIP_P (f))
             {
               if (FRAME_PIXEL_HEIGHT (f) != configureEvent.xconfigure.height
                   || FRAME_PIXEL_WIDTH (f) != configureEvent.xconfigure.width)
@@ -9971,11 +9966,7 @@ struct x_error_message_stack {
       /* Don't change the size of a tip frame; there's no point in
 	 doing it because it's done in Fx_show_tip, and it leads to
 	 problems because the tip frame has no widget.  */
-      if (NILP (tip_frame) || XFRAME (tip_frame) != f
-#ifdef USE_GTK
-	  || NILP (Fframe_parameter (tip_frame, Qtooltip))
-#endif
-	  )
+      if (!FRAME_TOOLTIP_P (f))
 	{
 	  adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
 			     FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
@@ -11204,7 +11195,7 @@ struct x_error_message_stack {
   /* The following breaks our calculations.  If it's really needed,
      think of something else.  */
 #if false
-  if (NILP (tip_frame) || XFRAME (tip_frame) != f)
+  if (!FRAME_TOOLTIP_P (f))
     {
       int text_width, text_height;

diff --git a/src/xterm.h b/src/xterm.h
index f73dd0e..1849a5c 100644
--- a/src/xterm.h
+++ b/src/xterm.h
@@ -503,6 +503,8 @@ struct x_display_info

 extern void select_visual (struct x_display_info *);

+extern Window tip_window;
+
 /* Each X frame object points to its own struct x_output object
    in the output_data.x field.  The x_output structure contains
    the information that is specific to X windows.  */

RE: Fix some tooltip related problems

[Drew Adams]

(If this has no effect on users or Lisp then you can
ignore this message.)

Could you perhaps describe the changes in terms of what
changes for (1) users and (2) existing Lisp code?  And
could you describe the problem(s) it is meant to solve?

> Replace 'tooltip' frame parameter with a 'tooltip'
> member in the frame structure.

I don't find a `tooltip' parameter mentioned in the
docs (e.g. Emacs 26 pretests).  Is this related to
variable `tooltip-frame-parameters'?

If so, this might break code (of which I have some)
that uses that variable to configure tooltip frames.

Does this affect use of `x-show-tip' or `tooltip-show'?

> For modeline help-echoing have tooltips show applicable
> actions only.

What does that mean?  What "inapplicable" stuff will
users no longer be able to see in tooltips?

Re: Fix some tooltip related problems

[martin rudalics]

 > (If this has no effect on users or Lisp then you can
 > ignore this message.)
 >
 > Could you perhaps describe the changes in terms of what
 > changes for (1) users and (2) existing Lisp code?  And
 > could you describe the problem(s) it is meant to solve?
 >
 >> Replace 'tooltip' frame parameter with a 'tooltip'
 >> member in the frame structure.
 >
 > I don't find a `tooltip' parameter mentioned in the
 > docs (e.g. Emacs 26 pretests).  Is this related to
 > variable `tooltip-frame-parameters'?

No.  In Emacs 26 a tooltip's frame has a parameter called 'tooltip'
set to t.  But tooltip frames are hardly visible - `frame-list' and
`other-frames' don't show them - so it's unlikely that you've seen
that parameter.

 > If so, this might break code (of which I have some)
 > that uses that variable to configure tooltip frames.

`tooltip-frame-parameters' continues to work as before.

 > Does this affect use of `x-show-tip' or `tooltip-show'?

No.

 >> For modeline help-echoing have tooltips show applicable
 >> actions only.
 >
 > What does that mean?  What "inapplicable" stuff will
 > users no longer be able to see in tooltips?

For example, with emacs -Q and the mouse over the right part of the
single modeline you won't see a tooltip because the corresponding
window is already selected, occupies the whole frame and can be
neither removed nor resized.

martin

RE: Fix some tooltip related problems

[Drew Adams]

..

Thanks for those answers.

>  >> For modeline help-echoing have tooltips show applicable
>  >> actions only.
>  >
>  > What does that mean?  What "inapplicable" stuff will
>  > users no longer be able to see in tooltips?
> 
> For example, with emacs -Q and the mouse over the right part of the
> single modeline you won't see a tooltip because the corresponding
> window is already selected, occupies the whole frame and can be
> neither removed nor resized.

I guess you mean this tooltip:

 mouse-1: Select (drag to resize)
 mouse-2: Make current window occupy the whole frame
 mouse-3: Remove current window from display

As one user, in that context I'd rather still see those
mouse actions shown in a tooltip, for info/learning
purposes.  It would be good to dim them, however.

This is like showing `Edit' menu item `Cut' when the
buffer is read-only: we still show the menu item even
when it cannot be used in the current context.

It's true that for some menu items we use :visible
instead of :enable.  For the example you gave, I think
the :enable behavior is more appropriate: teach users
that it exists and tell them it is currently unavailable.

IMO, that's the right way to handle that particular
"inapplicable" action: show it, so users can learn
about those mouse actions even in that context - but
make clear that, although generally available, they
are not available currently.

So as one user I'd vote against this change, unless
I saw some good reasons for it or unless users will
somehow be given the choice.

What's the reason for this change?

What are the criteria that determine when such
"inapplicable" actions are not shown?  (I'm guessing
that the example you gave is not the only one.)

Re: Fix some tooltip related problems

[martin rudalics]

 > I guess you mean this tooltip:
 >
 >   mouse-1: Select (drag to resize)
 >   mouse-2: Make current window occupy the whole frame
 >   mouse-3: Remove current window from display
 >
 > As one user, in that context I'd rather still see those
 > mouse actions shown in a tooltip, for info/learning
 > purposes.

The info is wrong and nothing can be learned from wrong info.

 > It would be good to dim them, however.

There's no option to do that and there won't be any with system
tooltips.

 > What's the reason for this change?

To stop showing misleading information.

martin

RE: Fix some tooltip related problems

[Drew Adams]

>  > I guess you mean this tooltip:
>  >
>  >   mouse-1: Select (drag to resize)
>  >   mouse-2: Make current window occupy the whole frame
>  >   mouse-3: Remove current window from display
>  >
>  > As one user, in that context I'd rather still see those
>  > mouse actions shown in a tooltip, for info/learning
>  > purposes.
> 
> The info is wrong and nothing can be learned from wrong info.

The same is true of most (probably all) of the places
where we show a dimmed menu item: the action is
"inapplicable".  That doesn't mean that showing it is
"wrong" and that "nothing can be learned" from seeing it.

A lot CAN be learned from such info.  That's why we
(and zillions of other applications) show it - dimmed.

>  > It would be good to dim them, however.
> 
> There's no option to do that and there won't be any
> with system tooltips.

Why not?

Are you saying that this _cannot_ be done or only that
you've decided that it "won't" be done?  If the latter,
why?

>  > What's the reason for this change?
> 
> To stop showing misleading information.

See above.  It's not misleading, if you dim it.
Showing "Edit > Cut" is not misleading when "Cut"
is "inapplicable" but it is dimmed to show that
cutting is not currently available.

Re: Fix some tooltip related problems

[martin rudalics]

 > A lot CAN be learned from such info.  That's why we
 > (and zillions of other applications) show it - dimmed.

Have you ever seen one of those zillion applications show a dimmed
tooltip?

 >>   > It would be good to dim them, however.
 >>
 >> There's no option to do that and there won't be any
 >> with system tooltips.
 >
 > Why not?
 >
 > Are you saying that this _cannot_ be done or only that
 > you've decided that it "won't" be done?  If the latter,
 > why?

It cannot be done.  System tooltips have a uniform appearance.  So
dimming is not applicable for the default user on GNU/Linux - the vast
majority of Emacs users.  IIUC the same holds for Mac users.

martin

RE: Fix some tooltip related problems

[Drew Adams]

>  >>   > It would be good to dim them, however.
>  >>
>  >> There's no option to do that and there won't be any
>  >> with system tooltips.
>  >
>  > Why not?  Are you saying that this _cannot_ be done
>  > or only that you've decided that it "won't" be done?
> 
> It cannot be done.  System tooltips have a uniform appearance.  So
> dimming is not applicable for the default user on GNU/Linux - the
> vast majority of Emacs users.  IIUC the same holds for Mac users.

I see.  Well if it can't be done then it can't be done.

I have a naive question, though - your mention of "system
tooltip" isn't clear to me.

I thought that Emacs tooltips were Emacs frames.  What
prevents Emacs from doing what it wants in such a frame?
This works for me, for example:

(x-show-tip (propertize "abc" 'face '(:foreground "gray")))

What's different here from what you are talking about?

OK, I'm using MS Windows.  But does this not work also
on GNU/Linux and Mac?

And if that doesn't work on such platforms, can't we use
a ("normal") Emacs frame where such things do work?  Just
what is it that makes it impossible for Emacs to dim the
text in a tooltip?  Sorry, but this is not clear to me.

Re: Fix some tooltip related problems

[Alan Third]

On Wed, Jan 10, 2018 at 07:55:41AM -0800, Drew Adams wrote:
> (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
> 
> What's different here from what you are talking about?
> 
> OK, I'm using MS Windows.  But does this not work also
> on GNU/Linux and Mac?

This doesn’t work on the NS port. Tooltips on that platform are
neither system tooltips nor fully‐fledged frames. I think it also
doesn’t work with certain X toolkits (GTK?) where they use system
tooltips.

> And if that doesn't work on such platforms, can't we use
> a ("normal") Emacs frame where such things do work?  Just
> what is it that makes it impossible for Emacs to dim the
> text in a tooltip?  Sorry, but this is not clear to me.

It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
is standard behaviour on many platforms whereas dimming a tooltip is,
afaik, a completely novel behaviour and as a result would just be
confusing.
-- 
Alan Third

RE: Fix some tooltip related problems

[Drew Adams]

> > (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
> >
> > What's different here from what you are talking about?
> > OK, I'm using MS Windows.  But does this not work also
> > on GNU/Linux and Mac?
> 
> This doesn’t work on the NS port. Tooltips on that platform are
> neither system tooltips nor fully‐fledged frames. I think it also
> doesn’t work with certain X toolkits (GTK?) where they use system
> tooltips.

I see.

> > And if that doesn't work on such platforms, can't we use
> > a ("normal") Emacs frame where such things do work?  Just
> > what is it that makes it impossible for Emacs to dim the
> > text in a tooltip?  Sorry, but this is not clear to me.
> 
> It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
> is standard behaviour on many platforms whereas dimming a tooltip is,
> afaik, a completely novel behaviour and as a result would just be
> confusing.

1. The ability to use different Emacs faces in a tooltip
   frame is much more general than the use of that ability
   to dim the text in a tooltip.  It's a general feature.

   I didn't realize that Emacs was so limited in this regard
   on other platforms.  Thank goodness it works without a
   problem on at least some platforms (e.g. Windows).

   Given that limitation, I repeat the question: Can't we
   use a ("normal") Emacs frame, where things such as faces
   do work, to implement tooltips?

2. Wrt dimming a tooltip to show that its text, or some of it,
   applies generally, or at least in some contexts, but does
   not apply currently:

   The argument that we shouldn't do it because that would be
   "novel" isn't a good argument.  That a feature is "novel" is
   an argument neither for nor against its being added to Emacs.

   Emacs has, from the beginning, done things that weren't
   mainstream or even, yes, that were completely novel.
   There are some Emacs features that are still not found
   outside Emacs even though they've been in Emacs for decades.

   Ask yourself: How did dimming of menu items become standard
   behavior?  How did that feature ever get added to anything?
   Certainly not by someone who argued that it shouldn't be
   added because it is "novel" or is not yet standard.

   Did someone have to explain to you what a dimmed menu item
   is all about?  Is that inherently confusing the first time
   someone sees it?  I think not.  A tooltip with dimmed text
   is no more confusing.

Re: Fix some tooltip related problems

[Alan Third]

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

On Wed, Jan 10, 2018 at 01:02:42PM -0800, Drew Adams wrote:
>    Given that limitation, I repeat the question: Can't we
>    use a ("normal") Emacs frame, where things such as faces
>    do work, to implement tooltips?

I believe it should be possible now we have undecorated frames
available. I’ve made a (really bad) attempt at proving we can do it.
Patch attached.

My emacs lisp skills are rather bad, so I couldn’t work out how to get
tooltip-hide to work, or how exactly I should set the size of the
tooltip, or how to not display the modeline, but it kind of works...
Someone who knows what they’re doing should be able to make a better
fist of it than me.

One possible issue is that it might be difficult to stop frame‐based
tooltips from crossing screens on multi‐monitor setups. I know we fix
that in Objective‐C code in NS, I don’t know if lisp knows enough
about screen geometry to get round it.

(BTW, I just noticed that under NS toolbar tooltips are native, while
other tooltips aren’t.)

>    Did someone have to explain to you what a dimmed menu item
>    is all about?  Is that inherently confusing the first time
>    someone sees it?  I think not.  A tooltip with dimmed text
>    is no more confusing.

I disagree, a menu item is interactive, or not if it’s dimmed, so it
becomes clear quite quickly what dimming means. A dimmed tooltip is
still a tooltip, just a bit harder to read. It takes further action to
discover that the information its giving you isn’t currently usable.

-- 
Alan Third

[-- Attachment #2: 0001-Implement-rubbish-frame-base-tooltips.patch --]
[-- Type: text/plain, Size: 2928 bytes --]

From 36a9a38619d2b1658a2ee4b96faa89a2b17843ae Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Wed, 10 Jan 2018 23:03:36 +0000
Subject: [PATCH] Implement rubbish frame-base tooltips

---
 lisp/tooltip.el | 45 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/lisp/tooltip.el b/lisp/tooltip.el
index 81df229a13..2117d2aaa3 100644
--- a/lisp/tooltip.el
+++ b/lisp/tooltip.el
@@ -190,6 +190,8 @@ tooltip-hide-time
 
 (defvar gud-tooltip-mode) ;; Prevent warning.
 
+(defvar tooltip-frame)
+
 ;;; Event accessors
 
 (defun tooltip-event-buffer (event)
@@ -262,12 +264,41 @@ tooltip-show
 	    (setf (alist-get 'border-color params) fg))
 	  (when (stringp bg)
 	    (setf (alist-get 'background-color params) bg))
-	  (x-show-tip (propertize text 'face 'tooltip)
-		      (selected-frame)
-		      params
-		      tooltip-hide-delay
-		      tooltip-x-offset
-		      tooltip-y-offset))
+          (let* ((buf (get-buffer-create "*tooltip*"))
+                 (frame (make-frame
+                         (append
+                          `((no-focus-on-map . t)
+                            (undecorated . t)
+                            (tool-bar-lines . 0)
+	                    (menu-bar-lines . 0)
+	                    (minibuffer . nil)
+	                    (vertical-scroll-bars . nil)
+	                    (horizontal-scroll-bars . nil)
+	                    (left-fringe . 0)
+	                    (right-fringe . 0))
+                          (if (not (alist-get 'left params))
+                              `((left . ,(+ tooltip-x-offset (car (mouse-absolute-pixel-position)))))
+                            '())
+                          (if (not (alist-get 'top params))
+                              `((top . ,(+ tooltip-y-offset (cdr (mouse-absolute-pixel-position)))))
+                            '())
+                          params))))
+            (with-current-buffer buf
+              (erase-buffer)
+              (insert (propertize text 'face 'tooltip)))
+            (set-window-buffer (frame-root-window frame) buf)
+            (setq tooltip-frame frame)
+            (run-at-time tooltip-hide-delay nil
+                         (lambda () (delete-frame tooltip-frame))))
+
+
+	  ;; (x-show-tip (propertize text 'face 'tooltip)
+	  ;;             (selected-frame)
+	  ;;             params
+	  ;;             tooltip-hide-delay
+	  ;;             tooltip-x-offset
+	  ;;             tooltip-y-offset))
+          )
       (error
        (message "Error while displaying tooltip: %s" error)
        (sit-for 1)
@@ -279,6 +310,8 @@ tooltip-hide
   "Hide a tooltip, if one is displayed.
 Value is non-nil if tooltip was open."
   (tooltip-cancel-delayed-tip)
+  ;; (if (not (null tooltip-frame))
+  ;;     (delete-frame tooltip-frame))
   (when (x-hide-tip)
     (setq tooltip-hide-time (float-time))))
 
-- 
2.14.3

RE: Fix some tooltip related problems

[Drew Adams]

> >    Given that limitation, I repeat the question: Can't we
> >    use a ("normal") Emacs frame, where things such as faces
> >    do work, to implement tooltips?
> 
> I believe it should be possible now we have undecorated frames
> available. I’ve made a (really bad) attempt at proving we can do it.
> Patch attached.
>
> My emacs lisp skills are rather bad, so I couldn’t work out how to get
> tooltip-hide to work, or how exactly I should set the size of the
> tooltip, or how to not display the modeline, but it kind of works...
> Someone who knows what they’re doing should be able to make a better
> fist of it than me.

Thanks for working on this.

I would hope that whatever implementation is ultimately used
is used for the existing functions (e.g. `x-tooltip-show'),
so that nothing changes for users/Lisp.

> One possible issue is that it might be difficult to stop frame‐based
> tooltips from crossing screens on multi‐monitor setups. I know we fix
> that in Objective‐C code in NS, I don’t know if lisp knows enough
> about screen geometry to get round it.

I don't think we should _necessarily_ force all of a tooltip's
text to be on a single monitor.  Though that might make sense
in some cases in others it might not.  At most, the ability to
do that would be a nice-to-have and not something needed or to
be imposed (IMO).

Put differently, it can be useful to _be able_ to position
_any_ frame so that it does not extend across monitors, when
possible.  But that shouldn't necessarily be imposed on any
frame, including, I think a tooltip.

> >    Did someone have to explain to you what a dimmed menu item
> >    is all about?  Is that inherently confusing the first time
> >    someone sees it?  I think not.  A tooltip with dimmed text
> >    is no more confusing.
> 
> I disagree, a menu item is interactive, or not if it’s dimmed, so it
> becomes clear quite quickly what dimming means. A dimmed tooltip is
> still a tooltip, just a bit harder to read. It takes further action to
> discover that the information its giving you isn’t currently usable.

That's reasonable.  Not a big deal/difference though (IMO).

The ability to get the general info is more important than
any possible confusion (which I expect to be none) someone
might have from not immediately understanding that dim means
that trying the indicated action produces no effect.

Re: Fix some tooltip related problems

[Eli Zaretskii]

> Date: Wed, 10 Jan 2018 13:02:42 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: martin rudalics <rudalics@gmx.at>, emacs-devel <emacs-devel@gnu.org>
> 
>    Given that limitation, I repeat the question: Can't we
>    use a ("normal") Emacs frame, where things such as faces
>    do work, to implement tooltips?

We do have that capability on almost all platforms, but the default on
some of them is to use the system tooltips, and on others there's no
other way.

Re: Fix some tooltip related problems

[Yuri Khan]

On Thu, Jan 11, 2018 at 2:17 AM, Alan Third <alan@idiocy.org> wrote:

> It’s beyond me why you’d want to dim a tooltip. Dimming of menu items
> is standard behaviour on many platforms whereas dimming a tooltip is,
> afaik, a completely novel behaviour and as a result would just be
> confusing.

It might be worthwhile to look at how tooltips of other unavailable
things behave.

Case in point: A disabled button on a toolbar that shows icons only
(no text labels). The text label traditionally goes into the tooltip.
The tooltip is displayed always, no matter if the button is enabled or
disabled.

However, in that case we have a visual indication that the button is
disabled: its icon goes gray and dim. We don’t have that indication on
the modeline of the only window in an Emacs frame.

Also, this discussion assumes that we need to hide, or modify the
appearance of, the tooltip *because* the actions it describes are
unavailable. How could we change the behavior so that they would be
available even if the window is the only one in its frame?

Possible answer: Look at the splitter controls in some of Microsoft
products (Word, Visual Studio). (Or LibreOffice Calc.) The splitter is
there always, and always draggable, whether the window is split or
not. If the window is split, dragging the splitter resizes the panes.
If the window is not split, dragging the splitter splits it. If the
window is split and the user drags the splitter to either extreme end
of the range, the pane that got resized to zero is removed.

RE: Fix some tooltip related problems

[Drew Adams]

> Also, this discussion assumes that we need to hide, or modify the
> appearance of, the tooltip *because* the actions it describes are
> unavailable. How could we change the behavior so that they would be
> available even if the window is the only one in its frame?

Yes, I considered that.  Clearly, for the more specific
question about _this_ tooltip, providing different
actions in the sole-window case might be a reasonable
approach.

But that doesn't address the more general question of
describing generally-but-not-currently-available actions.
Regardless of whether alternative actions can be found
in this or that case, the question of dimmed-tooltip
usefulness remains.

Re: Fix some tooltip related problems

[martin rudalics]

 > I thought that Emacs tooltips were Emacs frames.  What
 > prevents Emacs from doing what it wants in such a frame?
 > This works for me, for example:
 >
 > (x-show-tip (propertize "abc" 'face '(:foreground "gray")))
 >
 > What's different here from what you are talking about?
 >
 > OK, I'm using MS Windows.  But does this not work also
 > on GNU/Linux and Mac?
 >
 > And if that doesn't work on such platforms, can't we use
 > a ("normal") Emacs frame where such things do work?  Just
 > what is it that makes it impossible for Emacs to dim the
 > text in a tooltip?  Sorry, but this is not clear to me.

System tooltips are lightweight objects with restricted abilities.
They have uniform appearance and the single tooltip window is usually
shared among all running programs and the operating system.

Emacs tooltips are merely an emulation of system tooltips.  Most
restrictions of system tooltips have been retrofit artificially, like
uniform faces which are built into `tooltip-show' (but can be avoided
by using `x-show-tip' as you mention above) or the fact that only one
tooltip can be present at any time.

The great disadvantage of Emacs tooltips is that they are heavyweight
precisely due to their versatility.  Showing an Emacs tooltip here on
Windows with -Q incurs an entire GC cycle.  Also, there are some minor
annoyances like the one that showing Emacs tooltips for menu items
depends on the presence of a blinking cursor.

martin

RE: Fix some tooltip related problems

[Drew Adams]

> System tooltips are lightweight objects with restricted abilities.
> They have uniform appearance and the single tooltip window is usually
> shared among all running programs and the operating system.
> 
> Emacs tooltips are merely an emulation of system tooltips.  Most
> restrictions of system tooltips have been retrofit artificially, like
> uniform faces which are built into `tooltip-show' (but can be avoided
> by using `x-show-tip' as you mention above) or the fact that only one
> tooltip can be present at any time.
> 
> The great disadvantage of Emacs tooltips is that they are heavyweight
> precisely due to their versatility.  Showing an Emacs tooltip here on
> Windows with -Q incurs an entire GC cycle.  Also, there are some minor
> annoyances like the one that showing Emacs tooltips for menu items
> depends on the presence of a blinking cursor.

Thanks for this clear background description.

If none of the limitations of system tooltips can be
eliminated easily, and none of the limitations of
non-system (i.e., "Emacs") tooltips can be eliminated
easily, can we perhaps have both, being able to choose
for any given context which to use?

Being able to use different, and multiple faces, or
images, or whatever, in a tooltip can be great for
some contexts/applications, even if it is not needed
for others.  Can we let Lisp code (and so users too)
decide, here or there, which kind of tooltip to use
(heavyweight "Emacs" or lightweight "system")?

 "The great disadvantage of Emacs tooltips is that
  they are heavyweight precisely due to their
  versatility."

Good summary.  And their great advantage is their
versatility.  Let's please offer both, if that's
not too difficult.

Re: Fix some tooltip related problems

[martin rudalics]

 > Can we let Lisp code (and so users too)
 > decide, here or there, which kind of tooltip to use
 > (heavyweight "Emacs" or lightweight "system")?

The majority of users (namely those with a GTK build) can.  Lucid and
Motif users can't because these toolkits don't support tooltips.  I
doubt that anyone has the time to set up tooltip controls on Windows.

martin

Re: Fix some tooltip related problems

[Robert Pluim]

martin rudalics <rudalics@gmx.at> writes:

> The majority of users (namely those with a GTK build) can.  Lucid and
> Motif users can't because these toolkits don't support tooltips.  I
> doubt that anyone has the time to set up tooltip controls on Windows.

How much of an outcry would there be if I proposed removing Lucid and
Motif support completely for Emacs 27, as a first step to getting rid
of the unholy mix of X and GTK we're currently doing?

Robert

Re: Fix some tooltip related problems

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 11 Jan 2018 18:19:00 +0100
> 
> How much of an outcry would there be if I proposed removing Lucid and
> Motif support completely for Emacs 27, as a first step to getting rid
> of the unholy mix of X and GTK we're currently doing?

A lot.  I'm firmly against removing toolkits to appease GTK.  I think
GTK is an unholy mess, which can some day simply stop being supported,
and we definitely shouldn't lose useful features in its favor.

Re: Fix some tooltip related problems

[martin rudalics]

 > A lot.  I'm firmly against removing toolkits to appease GTK.  I think
 > GTK is an unholy mess, which can some day simply stop being supported,
 > and we definitely shouldn't lose useful features in its favor.

Unfortunately I have to fully agree with Eli.

But I'd strongly support the removal of gtkutil.h/c in favor of the
addition of gtkfns.c, gtkterm.h/c, gtkmenu.c and maybe some others.
And I think at least one or two other developers might help us in this
regard (or they already started to implement that).

martin

Re: Fix some tooltip related problems

[Daniele Nicolodi]

On 1/11/18 10:59 AM, Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 11 Jan 2018 18:19:00 +0100
>>
>> How much of an outcry would there be if I proposed removing Lucid and
>> Motif support completely for Emacs 27, as a first step to getting rid
>> of the unholy mix of X and GTK we're currently doing?
> 
> A lot.  I'm firmly against removing toolkits to appease GTK.  I think
> GTK is an unholy mess, which can some day simply stop being supported,
> and we definitely shouldn't lose useful features in its favor.

I may have misunderstood, but isn't it strange to being worried about
GTK stopping being supported when comparing it to Motif?  I think it is
much likely that X11 will stop being supported before GTK will have this
fate.

Cheers,
Dan

Re: Fix some tooltip related problems

[Eli Zaretskii]

> From: Daniele Nicolodi <daniele@grinta.net>
> Date: Thu, 11 Jan 2018 16:33:38 -0700
> 
> > A lot.  I'm firmly against removing toolkits to appease GTK.  I think
> > GTK is an unholy mess, which can some day simply stop being supported,
> > and we definitely shouldn't lose useful features in its favor.
> 
> I may have misunderstood, but isn't it strange to being worried about
> GTK stopping being supported when comparing it to Motif?  I think it is
> much likely that X11 will stop being supported before GTK will have this
> fate.

My point is that Emacs should never put all of its eggs in the same
basket, when we consider basic software on which we rely for our
functionality.  So relying only on Motif, or only on Lucid, and
dropping all the rest, would be as wrong as dropping everything else
in favor of GTK.  Emacs should survive and remain useful even if one
of those packages becomes dead.

Re: Fix some tooltip related problems

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Date: Thu, 11 Jan 2018 18:19:00 +0100
>> 
>> How much of an outcry would there be if I proposed removing Lucid and
>> Motif support completely for Emacs 27, as a first step to getting rid
>> of the unholy mix of X and GTK we're currently doing?
>
> A lot.  I'm firmly against removing toolkits to appease GTK.  I think
> GTK is an unholy mess, which can some day simply stop being supported,
> and we definitely shouldn't lose useful features in its favor.

OK. But if we stop supporting GTK at some point, what ends up being
its replacement? I doubt we'll be able to support Lucid and Motif
forever, given that X is going to be replaced with Wayland.

Robert

Re: Fix some tooltip related problems

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 12 Jan 2018 09:40:20 +0100
> 
> > A lot.  I'm firmly against removing toolkits to appease GTK.  I think
> > GTK is an unholy mess, which can some day simply stop being supported,
> > and we definitely shouldn't lose useful features in its favor.
> 
> OK. But if we stop supporting GTK at some point, what ends up being
> its replacement? I doubt we'll be able to support Lucid and Motif
> forever, given that X is going to be replaced with Wayland.

We should indeed move to supporting Wayland natively; volunteers are
most welcome to work on that.  The Cairo support was supposed to be
the first step in that direction, but it has known bugs and needs a
lot of loving care for us to be able to turn it on by default.
Working on this requires to have experts on board that we
unfortunately don't seem to have at this time, and that gap bothers me
personally quite a lot, because I think it's a serious threat to
Emacs's future.

But in any case, we should try to keep support for toolkits for as
long as they are used/usable, precisely because the future in this
area is so uncertain and not under any control/influence of our
project.  And we should also keep the no-toolkit build alive, because
it provides an easy way for quick-and-dirty integration with any
toolkit: you just write a small set of relatively simple functions
that implement few key interfaces, and you are basically done.

IOW, we should spread our risks in this and similar areas as wide as
possible.

Re: Fix some tooltip related problems

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> OK. But if we stop supporting GTK at some point, what ends up being
>> its replacement? I doubt we'll be able to support Lucid and Motif
>> forever, given that X is going to be replaced with Wayland.
>
> We should indeed move to supporting Wayland natively; volunteers are
> most welcome to work on that.  The Cairo support was supposed to be
> the first step in that direction, but it has known bugs and needs a
> lot of loving care for us to be able to turn it on by default.
> Working on this requires to have experts on board that we
> unfortunately don't seem to have at this time, and that gap bothers me
> personally quite a lot, because I think it's a serious threat to
> Emacs's future.

I'm unclear as to how we could 'support Wayland natively' without
using some kind of toolkit for menus, scrollbars, etc.

Robert

Re: Fix some tooltip related problems

[Philipp Stephani]

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

Robert Pluim <rpluim@gmail.com> schrieb am Fr., 12. Jan. 2018 um 14:58 Uhr:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> OK. But if we stop supporting GTK at some point, what ends up being
> >> its replacement? I doubt we'll be able to support Lucid and Motif
> >> forever, given that X is going to be replaced with Wayland.
> >
> > We should indeed move to supporting Wayland natively; volunteers are
> > most welcome to work on that.  The Cairo support was supposed to be
> > the first step in that direction, but it has known bugs and needs a
> > lot of loving care for us to be able to turn it on by default.
> > Working on this requires to have experts on board that we
> > unfortunately don't seem to have at this time, and that gap bothers me
> > personally quite a lot, because I think it's a serious threat to
> > Emacs's future.
>
> I'm unclear as to how we could 'support Wayland natively' without
> using some kind of toolkit for menus, scrollbars, etc.
>

We would support Wayland by using GTK+ correctly. GTK+ already supports
Wayland; we just need to get rid of the weird GTK+/X hybrid, and write a
proper GTK+-only "terminal".

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

Re: Fix some tooltip related problems

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > How much of an outcry would there be if I proposed removing Lucid and
  > Motif support completely for Emacs 27, as a first step to getting rid
  > of the unholy mix of X and GTK we're currently doing?

Please ask this on help-gnu-emacs.
You don't get a good sample of users on this list.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.

Re: Fix some tooltip related problems

[Stefan Monnier]

> How much of an outcry would there be if I proposed removing Lucid and
> Motif support completely for Emacs 27, as a first step to getting rid
> of the unholy mix of X and GTK we're currently doing?

Personally I don't care much for the Motif support, but Lucid support is
still required for multi-display use thanks to the infamous Gtk bug.


        Stefan

Re: Fix some tooltip related problems

[Robert Pluim]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> How much of an outcry would there be if I proposed removing Lucid and
>> Motif support completely for Emacs 27, as a first step to getting rid
>> of the unholy mix of X and GTK we're currently doing?
>
> Personally I don't care much for the Motif support, but Lucid support is
> still required for multi-display use thanks to the infamous Gtk bug.

Multi-display works with GTK, it's just buggy. The level of interest
from the Gtk folks in fixing it seems as low as ever.

Robert

RE: Fix some tooltip related problems

[Drew Adams]

>  > Can we let Lisp code (and so users too)
>  > decide, here or there, which kind of tooltip to use
>  > (heavyweight "Emacs" or lightweight "system")?
> 
> The majority of users (namely those with a GTK build) can.  Lucid and
> Motif users can't because these toolkits don't support tooltips.  I
> doubt that anyone has the time to set up tooltip controls on Windows.

Dunno what that means.

1. Can users with a GTK build today use Lisp code that decides
which to use in any given (Lisp) context?  How is that done
in Lisp?

2. What do you mean by "set up tooltip controls" on Windows?
Today, on Windows you can at least use faces in tooltips.
(Dunno about using images, but I'm guessing that's OK too.)

But perhaps you mean that on Windows there are _only_
"Emacs" tooltips, not "system" tooltips?  From my point of
view that's not a problem - flexible beats inflexible.  You
say that tooltips on Windows are "heavyweight" and "incur
an entire GC cycle", but I've never noticed any performance
problem with them - on Emacs 20 through 26.

Re: Fix some tooltip related problems

[martin rudalics]

 > 1. Can users with a GTK build today use Lisp code that decides
 > which to use in any given (Lisp) context?  How is that done
 > in Lisp?

The option `x-gtk-use-system-tooltips' decides whether to use system
or Emacs tooltips.  This is a user option and should never be set by
Lisp code.

 > 2. What do you mean by "set up tooltip controls" on Windows?

Windows uses the term "tooltip controls" for its native tooltips.  In
order to use tooltip controls, an application programmer has to set
them up, that is, write the necessary API routines.

 > Today, on Windows you can at least use faces in tooltips.
 > (Dunno about using images, but I'm guessing that's OK too.)

A tooltip frame is a normal top-level frame that can be used like any
other frame.  It has some restrictions (no margins, fringes, scroll
bars) but a criminal mind might be able to relieve some of them.

 > But perhaps you mean that on Windows there are _only_
 > "Emacs" tooltips, not "system" tooltips?  From my point of
 > view that's not a problem - flexible beats inflexible.  You
 > say that tooltips on Windows are "heavyweight" and "incur
 > an entire GC cycle", but I've never noticed any performance
 > problem with them - on Emacs 20 through 26.

Probably because you don't use a battery or maybe you just don't care.

martin

RE: Fix some tooltip related problems

[Drew Adams]

>  > 1. Can users with a GTK build today use Lisp code that decides
>  > which to use in any given (Lisp) context?  How is that done
>  > in Lisp?
> 
> The option `x-gtk-use-system-tooltips' decides whether to use system
> or Emacs tooltips.  This is a user option and should never be set by
> Lisp code.

Then that doesn't satisfy what I requested:

  "being able to choose for any given context which to use"
                        ---------------------
  "Can we let Lisp code (and so users too) decide, here or
   there, which kind of tooltip to use (heavyweight "Emacs"
   or lightweight "system")?"

>  > 2. What do you mean by "set up tooltip controls" on Windows?
>
> Windows uses the term "tooltip controls" for its native tooltips.  In
> order to use tooltip controls, an application programmer has to set
> them up, that is, write the necessary API routines.

So if no one "has the time to set up tooltip controls on
Windows" then we have what we have now on Windows: "Emacs"
tooltips - which is fine.

>  > Today, on Windows you can at least use faces in tooltips.
>  > (Dunno about using images, but I'm guessing that's OK too.)
> 
> A tooltip frame is a normal top-level frame that can be used like any
> other frame.  It has some restrictions (no margins, fringes, scroll
> bars) but a criminal mind might be able to relieve some of them.

That's all good, and what I expected but wasn't sure -
"Emacs" tooltips are plenty flexible.

>  > But perhaps you mean that on Windows there are _only_
>  > "Emacs" tooltips, not "system" tooltips?  From my point of
>  > view that's not a problem - flexible beats inflexible.  You
>  > say that tooltips on Windows are "heavyweight" and "incur
>  > an entire GC cycle", but I've never noticed any performance
>  > problem with them - on Emacs 20 through 26.
> 
> Probably because you don't use a battery or maybe you just don't care.

I don't use a battery.

I guess you're suggesting that "Emacs" tooltips, which are
apparently all we have on Windows, are too slow for use with
a battery.  And you expect that no one will provide the
choice of "system" tooltips on Windows.

So from your point of view, tooltips on Windows should
typically be turned off (at least by users) when a battery
is used, so the info goes to the echo area.  That's OK.

Ignoring any battery users on Windows who don't turn off
tooltips, we have what we need on Windows.  (Yes, a Lisp
choice would be even better, but if no one provides it...)

And users on gtk-build systems can choose.  Choice should
also be available to Lisp functions, as use cases differ.
It's of course possible to let a user option allow for
Lisp control or override/prevent it, au choix.

Today, does changing the value of that user option change
the behavior dynamically?  E.g., if you did change the
value using a given Lisp function would the behavior change?

If so then some specific contexts could, by default, use
"Emacs" tooltips, while other contexts did not.

For example, tooltip-dimming for mode-line mouseover
could be done for non-Windows also, without imposing "Emacs"
tooltips everywhere.  And users could prevent that dimming
using option `x-gtk-use-system-tooltips'.

Since that's apparently possible for more than just Windows,
including for at least some GNU/Linux builds, that's what
we should do by default.  I didn't propose it earlier
because I thought you were saying that it is only Windows
that supports faces in tooltips, and I know that we don't
tailor default Emacs behavior for Windows only.

Re: Fix some tooltip related problems

[martin rudalics]

 >> The option `x-gtk-use-system-tooltips' decides whether to use system
 >> or Emacs tooltips.  This is a user option and should never be set by
 >> Lisp code.
 >
 > Then that doesn't satisfy what I requested:
 >
 >    "being able to choose for any given context which to use"
 >                          ---------------------
 >    "Can we let Lisp code (and so users too) decide, here or
 >     there, which kind of tooltip to use (heavyweight "Emacs"
 >     or lightweight "system")?"

Right.  Such decisions must be left to the user.

 > And users on gtk-build systems can choose.  Choice should
 > also be available to Lisp functions, as use cases differ.
 > It's of course possible to let a user option allow for
 > Lisp control or override/prevent it, au choix.
 >
 > Today, does changing the value of that user option change
 > the behavior dynamically?  E.g., if you did change the
 > value using a given Lisp function would the behavior change?
 >
 > If so then some specific contexts could, by default, use
 > "Emacs" tooltips, while other contexts did not.

I'd rather advise to set `x-gtk-use-system-tooltips' once in the init
file and never change it during the session.

 > For example, tooltip-dimming for mode-line mouseover
 > could be done for non-Windows also, without imposing "Emacs"
 > tooltips everywhere.  And users could prevent that dimming
 > using option `x-gtk-use-system-tooltips'.
 >
 > Since that's apparently possible for more than just Windows,
 > including for at least some GNU/Linux builds, that's what
 > we should do by default.  I didn't propose it earlier
 > because I thought you were saying that it is only Windows
 > that supports faces in tooltips, and I know that we don't
 > tailor default Emacs behavior for Windows only.

Please look into the implementation details of tooltips before
suggesting such things.

martin

RE: Fix some tooltip related problems

[Drew Adams]

>  >> The option `x-gtk-use-system-tooltips' decides whether to use system
>  >> or Emacs tooltips.  This is a user option and should never be set by
>  >> Lisp code.
>  >
>  > Then that doesn't satisfy what I requested:
>  >    "being able to choose for any given context which to use"
>  >                          ---------------------
>  >    "Can we let Lisp code (and so users too) decide, here or
>  >     there, which kind of tooltip to use (heavyweight "Emacs"
>  >     or lightweight "system")?"
> 
> Right.  Such decisions must be left to the user.

Users have the right to use Lisp.  Users have the right
to choose whether to define or use this or that command
or this or that Lisp code.

There's no contradiction between allowing Lisp code to
choose whether to use faces etc. in a given tooltip and
allowing users to choose whether to allow that and choose
whether all or none or some tooltips should allow it.

Users choose.  The existence of that user option does
not and should not preclude more choice.

The fact that we have a user option for the global choice
of all or none is a red herring in a discussion of whether
and how to let Lisp code (not just C code) take part here.

Of course it is the user who gets to decide whether any
given Lisp code does its thing, whatever that might be.

>  > And users on gtk-build systems can choose.  Choice should
>  > also be available to Lisp functions, as use cases differ.
>  > It's of course possible to let a user option allow for
>  > Lisp control or override/prevent it, au choix.
>  >
>  > Today, does changing the value of that user option change
>  > the behavior dynamically?  E.g., if you did change the
>  > value using a given Lisp function would the behavior change?
>  >
>  > If so then some specific contexts could, by default, use
>  > "Emacs" tooltips, while other contexts did not.
> 
> I'd rather advise to set `x-gtk-use-system-tooltips' once in the init
> file and never change it during the session.

You are free to give anyone any such advice, of course.
It's the individual user who should be able to choose
what she wants.

A tooltip that shows each key as you type it, in, e.g.,
a large, red face (user-configurable) can be helpful
when doing a demo or recording a demo video, to show
which keys you are pressing, at relevant places on the
screen.

There are a zillion uses for tooltips that can take
advantage of using faces (and other Emacs artifacts).

Letting a user decide when, whether, and where to take
advantage of that is normal for Emacs.  Saying that you
shouldn't be able to do that is not normal for Emacs.

Re: Fix some tooltip related problems

[Eli Zaretskii]

> Date: Mon, 08 Jan 2018 10:53:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> I intend to apply the attached patch to master.  Its ChangeLog goes
> as below.  Comments and suggestions welcome.
> 
> Thanks, martin
> 
> -------------------------------------------------------------------
> 
> Fix some tooltip related problems
> 
> Replace 'tooltip' frame parameter with a 'tooltip' member in
> the frame structure.  For GTK+ builds use 'tip_last_frame' to
> find the frame for which the currently visible tooltip was
> made.  For modeline help-echoing have tooltips show applicable
> actions only.

What would that do to Lisp code that was probing that frame parameter?
I think for backward compatibility we should pretend in
frame-parameters and frame-parameter that this parameter still exist,
at least for tooltip frames.

IOW, remove it only for internal bookkeeping.

Thanks.

Re: Fix some tooltip related problems

[martin rudalics]

 > What would that do to Lisp code that was probing that frame parameter?
 > I think for backward compatibility we should pretend in
 > frame-parameters and frame-parameter that this parameter still exist,
 > at least for tooltip frames.
 >
 > IOW, remove it only for internal bookkeeping.

How about adding it to `tooltip-frame-parameters' then?

martin

Re: Fix some tooltip related problems

[Eli Zaretskii]

> Date: Mon, 08 Jan 2018 20:06:17 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > What would that do to Lisp code that was probing that frame parameter?
>  > I think for backward compatibility we should pretend in
>  > frame-parameters and frame-parameter that this parameter still exist,
>  > at least for tooltip frames.
>  >
>  > IOW, remove it only for internal bookkeeping.
> 
> How about adding it to `tooltip-frame-parameters' then?

I don't mind, but what I meant was to allow Lisp code written to
manipulate tooltips to be able to find the 'tooltip' frame parameter
when calling frame-parameter(s) for the tooltip frames.  This should
preferably happen even if some code removes that parameter from
tooltip-frame-parameters.

Re: Fix some tooltip related problems

[martin rudalics]

 > I don't mind, but what I meant was to allow Lisp code written to
 > manipulate tooltips to be able to find the 'tooltip' frame parameter
 > when calling frame-parameter(s) for the tooltip frames.  This should
 > preferably happen even if some code removes that parameter from
 > tooltip-frame-parameters.

OK.  I'll leave it as in Emacs 26 then.

martin

Re: Fix some tooltip related problems

[martin rudalics]

 > I intend to apply the attached patch to master.  Its ChangeLog goes
 > as below.  Comments and suggestions welcome.

Installed with minor modifications.  Thanks for your comments and
suggestions.

martin