all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Po Lu <luangruo@yahoo.com>
Cc: "clement.pitclaudel@live.com" <clement.pitclaudel@live.com>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	"23341@debbugs.gnu.org" <23341@debbugs.gnu.org>
Subject: bug#23341: x-show-tip does not respect the value of tooltip-hide-delay, and the default tooltip timeout isn't configurable
Date: Mon, 2 May 2022 14:53:57 +0000	[thread overview]
Message-ID: <SJ0PR10MB54881D3FEA3BA72950E8C344F3C19@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <871qxcps0w.fsf@yahoo.com>

> > Lots of things can happen unpredictably with
> > frames, per different window managers.
> 
> Not if you use `tooltip-show', I think.

That's like saying "not if you use `forward-char'.
`tooltip-show' doesn't let you do what `x-show-tip'
does.  That's what this discussion is about (IMHO).

> > And invisible frames are used seldom - so
> > much so that Emacs has even (misguidedly)
> > toyed with the idea of getting rid of their
> > support.
> >
> > But pray, please do elaborate?  What's so
> > special about tooltips here?
> 
> Tooltips are made transient for the frame they are displayed in.
> Compositing managers look at the WM_TRANSIENT_FOR property on tooltip
> frames (which are a special kind of frame created without any widgets
> that are always override redirect) to determine how to display the
> tooltip.  Those frames are also displayed outside the usual redisplay
> machinery, and only once, inside `x-show-tip'.

If `tooltip-show' can use `x-show-tip' then so
can user code.  That's the point.  Whatever
guidance applies to _how_ `tooltip-show' uses
`x-show-tip' - whatever super-careful, wise,
limited use is deemed necessary or desirable,
can be made just as well by user code.

Make that guidance explicit, and please be sure
to make clear just what is really necessary and
what is extra, helpful, nice-to-know guidance.

That will add, not subtract, from Emacs.

> > Please consider documenting it, whatever
> > it is - especially the "dangerous" bit.
> >
> > And if this happens with tooltips then what
> > makes you think it's limited to the use of
> > `x-show-tip'?  Just what is `x-show-tip'-
> > specific?
> 
> That cannot happen with `tooltip-show'.

See above.  If that's the case then it means
that `tooltip-show' uses `x-show-tip' in a
particular way.  Document that guidance.
That's all that's needed (if really needed).

> > Some things?  In 'params'?  (PARMS maybe?)
> >
> > Any crash is an Emacs bug (in C code).  Needs to
> > be fixed, regardless of who's authorized to use
> > `x-show-tip'.
> 
> So crashing on some kinds of invalid bytecode is
> an Emacs bug, for that same reason?

Emacs has long held that _any_ crash is an
Emacs bug, yes.  If nothing else, Emacs should
catch the error and handle it more gracefully
than an out-and-out crash.

> > If there are problems/gotchas/bugs/mysteries wrt
> > PARMS, or anything else your vague response is
> > meant to intimate, please fix or document them.
> 
> `tool-bar-position' is one example of such a problematic frame
> parameter, and there are many others, but I never enumerated all of
> them.

Enumerate them.  Or not, if you can't.  That's
the proper approach.  What's good for the
`tooltip-show' goose's use of `x-show-tip' is
also good for user uses of `x-show-tip'.

> Lisp code should _never_ manipulate tooltip frames.
> They are special on
> the C level in that many assumptions (such as there being a GTK or Xt
> widget for each frame), or that the frame has at least one window that
> isn't a "pseudo window" do not hold.  This is also why we bend over
> backwards to not make tooltip frames visible to Lisp inside frame lists
> and probably the display-buffer stuff as well.

Again, whatever is sane for `tooltip-show's use
of `x-show-tip' is just as sane for user use of
it.  The same caveats and guidance, if any,
apply - equally.  There's nothing magical about
Lisp function `tooltip-show'.

> > There's no difference in this regard between what
> > "core Emacs developers" need (and need to know)
> > when using `x-show-tip' and what other Emacs
> > developers need (i.e., users who develop 3rd-party
> > libraries) need.
> >
> > Fix it or document it.  That's the proper response
> > for something useful that (you think) has problems.
> 
> It is documented.  The doc string says:
> 
>   This is an internal function; Lisp code should call `tooltip-show'.

That's misguided.  Let's not promulgate the old
user/developer divide from the 1960s.

That's not doc of how to use it.  If that's the
only thing you can say, then remove its use
from `tooltip-show' - the same considerations
apply.

If you have something useful to say, about how
`x-show-tip' should (let only must) be used,
then provide users with that guidance.  That's
what "fix it or document it" means.





  reply	other threads:[~2022-05-02 14:53 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-23  2:47 bug#23341: x-show-tip does not respect the value of tooltip-hide-delay, and the default tooltip timeout isn't configurable Clément Pit--Claudel
2016-04-23  6:53 ` Eli Zaretskii
2016-04-23 14:22   ` Clément Pit--Claudel
2016-04-23 14:36     ` Eli Zaretskii
2016-04-23 15:26       ` Clément Pit--Claudel
2016-04-23 17:54         ` Eli Zaretskii
2016-04-23 22:33           ` Clément Pit--Claudel
2016-04-24  6:08             ` Eli Zaretskii
2016-04-24 14:43               ` Clément Pit--Claudel
2016-04-24 15:59                 ` Eli Zaretskii
2016-04-23  8:13 ` martin rudalics
2016-04-23 14:27   ` Clément Pit--Claudel
2016-04-23 17:08     ` martin rudalics
2016-04-23 17:26       ` Clément Pit--Claudel
2016-04-24  8:40         ` martin rudalics
2016-04-24 14:40           ` Clément Pit--Claudel
2016-04-24 15:57             ` Eli Zaretskii
2016-04-24 16:30               ` Clément Pit--Claudel
2016-04-26  6:35                 ` martin rudalics
2016-04-26 11:25                   ` Dmitry Gutov
2022-04-30 15:10 ` Lars Ingebrigtsen
2022-04-30 15:30   ` Eli Zaretskii
2022-04-30 15:38     ` Lars Ingebrigtsen
2022-04-30 16:01       ` Eli Zaretskii
2022-04-30 16:22         ` Lars Ingebrigtsen
2022-04-30 16:50           ` Eli Zaretskii
2022-05-01  0:12           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01  8:37             ` Lars Ingebrigtsen
2022-05-01  9:19               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01  9:53                 ` Lars Ingebrigtsen
2022-05-01 10:38                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 10:39                     ` Lars Ingebrigtsen
2022-05-01 11:00                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 11:42                         ` Lars Ingebrigtsen
2022-05-01 12:56                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-01 16:19                             ` Drew Adams
2022-05-02  0:35                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-02  2:19                                 ` Drew Adams
2022-05-02  2:50                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-02 14:53                                     ` Drew Adams [this message]
2022-05-03  0:22                                       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-03  1:32                                         ` Drew Adams
2022-05-03  2:01                                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-03  4:16                                             ` Drew Adams
2022-05-03  4:44                                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB54881D3FEA3BA72950E8C344F3C19@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=23341@debbugs.gnu.org \
    --cc=clement.pitclaudel@live.com \
    --cc=larsi@gnus.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.