"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>
>  > "reliable" means that using it does not crash the Windows port.
>
> Oof!  That hurts.  It's not something I can fix.
>
>  > Further features of the XEmacs model I remember were:
>  > 
>  > a) it pops up with a noticeable time delay (likely X overhead for frame
>  > creation) during which XEmacs is non-responsive
>
> IIRC that's broken by design (you need to hover over the object for a
> second or XEmacs decides it was an accident and you didn't want a
> tip).

The time delay before XEmacs decides to pop up the tooltip is fine.  The
non-responsiveness while it works on the popup isn't.

>  > b) it steals the keyboard focus on mouse-over-frame window managers
>  > if you have bad luck (move the mouse cursor at the wrong time/the
>  > wrong direction)
>
> I think I fixed that.
>
>  > c) it comes with frame decorations
>
> I definitely fixed that.

It has been some time since I bothered checking since we stopped
enabling XEmacs tooltips in preview-latex after numerous user
complaints.

>  > All of Emacs' standard menu entries have tooltips (I don't even
>  > think that XEmacs supports menu entries with tooltips)
>
> I'll look at that.

Even if you choose not to implement them in menu entries, it would make
things easier for package developers if the menu system did not reject
the :help specifications but just ignored them.

That would obviate the need for something like

    TeX-menu-with-help is a Lisp macro in `tex.el'.

    (TeX-menu-with-help MENU)

    Compatibility macro that removes :help entries if on XEmacs.
    Also does other stuff.

> Thank you for your careful report.

Not particularly careful, just working from memory.  The ultimate metric
is "does not get in the way".  Once that metric is reached, one can
enable them by default.  We finally had to disable tooltips for the
XEmacs port because we got too many user complaints.  I'll leave it to
XEmacs proper to change the default.