* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
@ 2019-03-11 23:45 Phil Sainty
2019-03-12 6:28 ` Phil Sainty
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Phil Sainty @ 2019-03-11 23:45 UTC (permalink / raw)
To: 34819
Following from:
https://lists.gnu.org/archive/html/emacs-devel/2019-03/msg00324.html
Recipe from emacs -Q (and --with-x-toolkit=lucid)
* M-x text-mode
* Mouse 1 click on "Text" in the mode line to open the menu
* Hover over any of the menu items until the tooltip appears
For me, this produces tooltips of the appropriate dimensions, but the
text itself is not visible.
When I use the top menu bar instead of the mode line, the tooltip text
is visible.
I note also that if I simply hover over "Text" in the mode line, the
"Major mode" tooltip appears with visible text; however if I click-and-
hold the mouse button *before* the tooltip has had time to appear, then
it will be blank when it does appear (over the top of the menu).
-Phil
In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll
bars)
of 2018-10-23 built on hal
Windowing system distributor 'The X.Org Foundation', version
11.0.11906000
System Description: Ubuntu 18.04.2 LTS
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
Using vacuous schema
Quit [2 times]
Configured using:
'configure --prefix=/home/phil/emacs/26/26.1/usr/local
--with-x-toolkit=lucid --without-sound'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK DBUS GSETTINGS NOTIFY GNUTLS
LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 THREADS LCMS2
Important settings:
value of $LANG: en_NZ.UTF-8
locale-coding-system: utf-8-unix
Major mode: nXML
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils rng-xsd xsd-regexp rng-cmpct rng-nxml
rng-valid rng-loc rng-uri rng-parse nxml-parse rng-match rng-dt rng-util
rng-pttrn nxml-ns easymenu nxml-mode nxml-outln nxml-rap sgml-mode seq
byte-opt gv bytecomp byte-compile cconv dom cl-loaddefs cl-lib nxml-util
nxml-enc xmltok dired dired-loaddefs advice elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 114978 10197)
(symbols 48 22012 1)
(miscs 40 116 126)
(strings 32 34678 2181)
(string-bytes 1 892076)
(vectors 16 17344)
(vector-slots 8 521397 14092)
(floats 8 68 61)
(intervals 56 338 0)
(buffers 992 17))
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-11 23:45 bug#34819: 26.1; Blank help-echo tooltips for mode line menus Phil Sainty
@ 2019-03-12 6:28 ` Phil Sainty
2019-03-12 15:56 ` Eli Zaretskii
2019-03-12 15:45 ` Eli Zaretskii
2019-03-12 21:06 ` Glenn Morris
2 siblings, 1 reply; 25+ messages in thread
From: Phil Sainty @ 2019-03-12 6:28 UTC (permalink / raw)
To: 34819
In fact that recipe was more complex than required.
I'd used text-mode because I'd noted that it had tooltips for its
menu -- but so does lisp-interaction-mode, I now realise. So from
emacs -Q we can go directly to the major mode menu in the mode line,
without changing the major modes at all. The same issue still occurs.
Likewise, the line-number-mode menu and the "All" to the left of
that both exhibit the same behaviours.
-Phil
On 2019-03-12 12:45, Phil Sainty wrote:
> Recipe from emacs -Q (and --with-x-toolkit=lucid)
>
> * M-x text-mode
> * Mouse 1 click on "Text" in the mode line to open the menu
> * Hover over any of the menu items until the tooltip appears
>
> For me, this produces tooltips of the appropriate dimensions, but the
> text itself is not visible.
>
> When I use the top menu bar instead of the mode line, the tooltip text
> is visible.
>
> I note also that if I simply hover over "Text" in the mode line, the
> "Major mode" tooltip appears with visible text; however if I click-and-
> hold the mouse button *before* the tooltip has had time to appear, then
> it will be blank when it does appear (over the top of the menu).
>
>
> -Phil
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-12 6:28 ` Phil Sainty
@ 2019-03-12 15:56 ` Eli Zaretskii
2019-03-12 17:21 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-12 15:56 UTC (permalink / raw)
To: Phil Sainty; +Cc: 34819
> Date: Tue, 12 Mar 2019 19:28:53 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
>
> In fact that recipe was more complex than required.
>
> I'd used text-mode because I'd noted that it had tooltips for its
> menu -- but so does lisp-interaction-mode, I now realise. So from
> emacs -Q we can go directly to the major mode menu in the mode line,
> without changing the major modes at all. The same issue still occurs.
What happens if you click C-mouse-3? Does the menu that pops up have
valid help-echo or doesn't it?
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-12 15:56 ` Eli Zaretskii
@ 2019-03-12 17:21 ` Eli Zaretskii
2019-03-12 20:20 ` Phil Sainty
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-12 17:21 UTC (permalink / raw)
To: psainty; +Cc: 34819
> Date: Tue, 12 Mar 2019 17:56:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 34819@debbugs.gnu.org
>
> What happens if you click C-mouse-3?
To clarify: I meant click C-mouse-3 on the text area of a window that
displays *scratch*. It should pop up the menu of Lisp interaction
mode.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-12 17:21 ` Eli Zaretskii
@ 2019-03-12 20:20 ` Phil Sainty
0 siblings, 0 replies; 25+ messages in thread
From: Phil Sainty @ 2019-03-12 20:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 34819
On 2019-03-13 06:21, Eli Zaretskii wrote:
>> What happens if you click C-mouse-3?
>
> To clarify: I meant click C-mouse-3 on the text area of a window that
> displays *scratch*. It should pop up the menu of Lisp interaction
> mode.
Blank tooltips again when the menu is accessed this way.
-Phil
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-11 23:45 bug#34819: 26.1; Blank help-echo tooltips for mode line menus Phil Sainty
2019-03-12 6:28 ` Phil Sainty
@ 2019-03-12 15:45 ` Eli Zaretskii
2019-03-12 21:06 ` Glenn Morris
2 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-12 15:45 UTC (permalink / raw)
To: Phil Sainty; +Cc: 34819
> Date: Tue, 12 Mar 2019 12:45:58 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
>
> Recipe from emacs -Q (and --with-x-toolkit=lucid)
>
> * M-x text-mode
> * Mouse 1 click on "Text" in the mode line to open the menu
> * Hover over any of the menu items until the tooltip appears
>
> For me, this produces tooltips of the appropriate dimensions, but the
> text itself is not visible.
I can only suggest to step with a debugger through x-show-tip and see
what's going on there. It's hard to understand how come the frame is
shown, but the text produced by the same function is invisible. Maybe
we are missing some X wizardry in that function.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-11 23:45 bug#34819: 26.1; Blank help-echo tooltips for mode line menus Phil Sainty
2019-03-12 6:28 ` Phil Sainty
2019-03-12 15:45 ` Eli Zaretskii
@ 2019-03-12 21:06 ` Glenn Morris
2019-03-13 3:34 ` Eli Zaretskii
2019-03-13 6:37 ` Phil Sainty
2 siblings, 2 replies; 25+ messages in thread
From: Glenn Morris @ 2019-03-12 21:06 UTC (permalink / raw)
To: Phil Sainty; +Cc: 34819
Bisected to c29071587c64efb30792bd72248d3c791abd9337.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-12 21:06 ` Glenn Morris
@ 2019-03-13 3:34 ` Eli Zaretskii
2019-03-13 5:03 ` Phil Sainty
2019-03-13 6:37 ` Phil Sainty
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-13 3:34 UTC (permalink / raw)
To: Glenn Morris; +Cc: psainty, 34819
> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 12 Mar 2019 17:06:10 -0400
> Cc: 34819@debbugs.gnu.org
>
> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
So the problem can be solved by adding (inhibit-double-buffering . t)
to tooltip-frame-parameters? If so, I think we want this on the
release branch.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 3:34 ` Eli Zaretskii
@ 2019-03-13 5:03 ` Phil Sainty
0 siblings, 0 replies; 25+ messages in thread
From: Phil Sainty @ 2019-03-13 5:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 34819
On 2019-03-13 16:34, Eli Zaretskii wrote:
>> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
>
> So the problem can be solved by adding (inhibit-double-buffering . t)
> to tooltip-frame-parameters?
Sadly not. Starting a new emacs instance with the following did not
not have any apparent effect on the issue.
(custom-set-variables
'(tooltip-frame-parameters
(quote
((name . "tooltip")
(internal-border-width . 2)
(border-width . 1)
(no-special-glyphs . t)
(inhibit-double-buffering . t)))))
I also tried (set-frame-parameter nil 'inhibit-double-buffering t)
in the main frame, just in case that had an effect, but it did not.
-Phil
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-12 21:06 ` Glenn Morris
2019-03-13 3:34 ` Eli Zaretskii
@ 2019-03-13 6:37 ` Phil Sainty
2019-03-13 10:31 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: Phil Sainty @ 2019-03-13 6:37 UTC (permalink / raw)
To: Glenn Morris; +Cc: 34819
On 2019-03-13 10:06, Glenn Morris wrote:
> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
I can confirm that for the current master, if I comment out parts
of configure.ac as below before building, the problem goes away.
### Use Xdbe (-lXdbe) if available
HAVE_XDBE=no
### if test "${HAVE_X11}" = "yes"; then
### AC_CHECK_HEADER(X11/extensions/Xdbe.h,
### [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName, HAVE_XDBE=yes)],
### [],
### [#include <X11/Xlib.h>
### ])
### if test $HAVE_XDBE = yes; then
### XDBE_LIBS=-lXext
### fi
### if test $HAVE_XDBE = yes; then
### AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe
extension.])
### fi
### fi
AC_SUBST(XDBE_CFLAGS)
AC_SUBST(XDBE_LIBS)
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 6:37 ` Phil Sainty
@ 2019-03-13 10:31 ` Eli Zaretskii
2019-03-13 11:52 ` Phil Sainty
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-13 10:31 UTC (permalink / raw)
To: 34819, psainty, rgm
On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
> On 2019-03-13 10:06, Glenn Morris wrote:
> > Bisected to c29071587c64efb30792bd72248d3c791abd9337.
>
> I can confirm that for the current master, if I comment out parts
> of configure.ac as below before building, the problem goes away.
>
>
> ### Use Xdbe (-lXdbe) if available
> HAVE_XDBE=no
> ### if test "${HAVE_X11}" = "yes"; then
> ### AC_CHECK_HEADER(X11/extensions/Xdbe.h,
> ### [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName,
> HAVE_XDBE=yes)],
> ### [],
> ### [#include <X11/Xlib.h>
> ### ])
> ### if test $HAVE_XDBE = yes; then
> ### XDBE_LIBS=-lXext
> ### fi
> ### if test $HAVE_XDBE = yes; then
> ### AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe
> extension.])
> ### fi
> ### fi
> AC_SUBST(XDBE_CFLAGS)
> AC_SUBST(XDBE_LIBS)
Which probably means the root cause is not double buffering itself, but some other change included in that commit. I wonder if you can audit the changes and try to identify potential culprits.
Thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 10:31 ` Eli Zaretskii
@ 2019-03-13 11:52 ` Phil Sainty
2019-03-13 15:25 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Phil Sainty @ 2019-03-13 11:52 UTC (permalink / raw)
To: Eli Zaretskii, 34819, rgm
On 13/03/19 11:31 PM, Eli Zaretskii wrote:
> On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty@orcon.net.nz> wrote:
>> On 2019-03-13 10:06, Glenn Morris wrote:
>>> Bisected to c29071587c64efb30792bd72248d3c791abd9337.
>>
>> I can confirm that for the current master, if I comment out parts
>> of configure.ac as below before building, the problem goes away.
>>
>> ### Use Xdbe (-lXdbe) if available
>> HAVE_XDBE=no
>> ### if test "${HAVE_X11}" = "yes"; then
>> ### AC_CHECK_HEADER(X11/extensions/Xdbe.h,
>> ### [AC_CHECK_LIB(Xext, XdbeAllocateBackBufferName, HAVE_XDBE=yes)],
>> ### [],
>> ### [#include <X11/Xlib.h>
>> ### ])
>> ### if test $HAVE_XDBE = yes; then
>> ### XDBE_LIBS=-lXext
>> ### fi
>> ### if test $HAVE_XDBE = yes; then
>> ### AC_DEFINE(HAVE_XDBE, 1, [Define to 1 if you have the Xdbe extension.])
>> ### fi
>> ### fi
>> AC_SUBST(XDBE_CFLAGS)
>> AC_SUBST(XDBE_LIBS)
>
> Which probably means the root cause is not double buffering itself,
> but some other change included in that commit. I wonder if you can
> audit the changes and try to identify potential culprits.
That code is well outside of my areas of expertise, so I'm not confident
that I'd figure it out very easily.
I'm CCing this to Daniel Colascione -- I don't imagine anyone else is
more familiar with that code than he is, so if anyone can intuitively
narrow down the possible culprits here, it would likely be him.
(Daniel, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34819 for full
context.)
-Phil
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 11:52 ` Phil Sainty
@ 2019-03-13 15:25 ` Eli Zaretskii
2019-03-13 15:34 ` dancol
2019-03-14 5:57 ` Glenn Morris
0 siblings, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-13 15:25 UTC (permalink / raw)
To: Phil Sainty; +Cc: 34819
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Daniel Colascione <dancol@dancol.org>
> Date: Thu, 14 Mar 2019 00:52:43 +1300
>
> > Which probably means the root cause is not double buffering itself,
> > but some other change included in that commit. I wonder if you can
> > audit the changes and try to identify potential culprits.
>
> That code is well outside of my areas of expertise, so I'm not confident
> that I'd figure it out very easily.
>
> I'm CCing this to Daniel Colascione -- I don't imagine anyone else is
> more familiar with that code than he is, so if anyone can intuitively
> narrow down the possible culprits here, it would likely be him.
Btw, I reckon this doesn't happen in the GTK build? What if you set
x-gtk-use-system-tooltips to a nil value -- does the problem happen in
the GTK build as well then?
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 15:25 ` Eli Zaretskii
@ 2019-03-13 15:34 ` dancol
2019-03-30 9:27 ` Eli Zaretskii
2019-03-14 5:57 ` Glenn Morris
1 sibling, 1 reply; 25+ messages in thread
From: dancol @ 2019-03-13 15:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Phil Sainty, 34819
[-- Attachment #1: Type: text/html, Size: 1601 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 15:34 ` dancol
@ 2019-03-30 9:27 ` Eli Zaretskii
0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-30 9:27 UTC (permalink / raw)
To: dancol; +Cc: psainty, 34819
> Date: Wed, 13 Mar 2019 08:34:11 -0700
> From: dancol@dancol.org
> Cc: Phil Sainty <psainty@orcon.net.nz>, 34819@debbugs.gnu.org, rgm@gnu.org
Ping! Any news on this?
> On Mar 13, 2019 8:25 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Phil Sainty <psainty@orcon.net.nz>
> > Cc: Daniel Colascione <dancol@dancol.org>
> > Date: Thu, 14 Mar 2019 00:52:43 +1300
> >
> > > Which probably means the root cause is not double buffering itself,
> > > but some other change included in that commit. I wonder if you can
> > > audit the changes and try to identify potential culprits.
> >
> > That code is well outside of my areas of expertise, so I'm not confident
> > that I'd figure it out very easily.
> >
> > I'm CCing this to Daniel Colascione -- I don't imagine anyone else is
> > more familiar with that code than he is, so if anyone can intuitively
> > narrow down the possible culprits here, it would likely be him.
>
> Btw, I reckon this doesn't happen in the GTK build? What if you set
> x-gtk-use-system-tooltips to a nil value -- does the problem happen in
>
> Thanks. I'll take a look.
>
> the GTK build as well then?
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-13 15:25 ` Eli Zaretskii
2019-03-13 15:34 ` dancol
@ 2019-03-14 5:57 ` Glenn Morris
2019-03-14 6:06 ` Eli Zaretskii
2019-04-02 0:26 ` Noam Postavsky
1 sibling, 2 replies; 25+ messages in thread
From: Glenn Morris @ 2019-03-14 5:57 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Phil Sainty, 34819
Eli Zaretskii wrote:
> What if you set x-gtk-use-system-tooltips to a nil value -- does the
> problem happen in the GTK build as well then?
Yes.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-14 5:57 ` Glenn Morris
@ 2019-03-14 6:06 ` Eli Zaretskii
2019-04-02 0:26 ` Noam Postavsky
1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2019-03-14 6:06 UTC (permalink / raw)
To: Glenn Morris; +Cc: psainty, 34819
> From: Glenn Morris <rgm@gnu.org>
> Cc: Phil Sainty <psainty@orcon.net.nz>, 34819@debbugs.gnu.org, dancol@dancol.org
> Date: Thu, 14 Mar 2019 01:57:03 -0400
>
> Eli Zaretskii wrote:
>
> > What if you set x-gtk-use-system-tooltips to a nil value -- does the
> > problem happen in the GTK build as well then?
>
> Yes.
Thanks, then this seems to be a general problem with tooltips produced
by Emacs on X.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-03-14 5:57 ` Glenn Morris
2019-03-14 6:06 ` Eli Zaretskii
@ 2019-04-02 0:26 ` Noam Postavsky
2019-04-23 9:21 ` martin rudalics
1 sibling, 1 reply; 25+ messages in thread
From: Noam Postavsky @ 2019-04-02 0:26 UTC (permalink / raw)
To: Glenn Morris; +Cc: Phil Sainty, 34819
merge 34819 33068
quit
Glenn Morris <rgm@gnu.org> writes:
> Eli Zaretskii wrote:
>
>> What if you set x-gtk-use-system-tooltips to a nil value -- does the
>> problem happen in the GTK build as well then?
>
> Yes.
That makes it the same as #33068 then, if I understand correctly.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-04-02 0:26 ` Noam Postavsky
@ 2019-04-23 9:21 ` martin rudalics
2019-04-23 10:57 ` Noam Postavsky
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2019-04-23 9:21 UTC (permalink / raw)
To: Noam Postavsky, Glenn Morris; +Cc: Phil Sainty, 34819
> That makes it the same as #33068 then, if I understand correctly.
Good catch. Do you have any ideas how to fix this?
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-04-23 9:21 ` martin rudalics
@ 2019-04-23 10:57 ` Noam Postavsky
2019-06-20 5:01 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 25+ messages in thread
From: Noam Postavsky @ 2019-04-23 10:57 UTC (permalink / raw)
To: martin rudalics; +Cc: Phil Sainty, 34819
martin rudalics <rudalics@gmx.at> writes:
>> That makes it the same as #33068 then, if I understand correctly.
>
> Good catch. Do you have any ideas how to fix this?
No clue, sorry.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-04-23 10:57 ` Noam Postavsky
@ 2019-06-20 5:01 ` YAMAMOTO Mitsuharu
2019-06-20 9:17 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 25+ messages in thread
From: YAMAMOTO Mitsuharu @ 2019-06-20 5:01 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Phil Sainty, 34819
The contents of the tooltip seems to be usually shown by the
flush_dirty_back_buffers call from handle_one_xevent. But the control
does not go back to read_socket_hook during menu tracking, so
flush_dirty_back_buffers is not called in such a case.
The patch below would work. The first hunk is not directly related to
this bug, but would be preferable. Note that cairo drawing needs
further fixes, so please try it without enabling cairo.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
diff --git a/src/xfns.c b/src/xfns.c
index c9fe3e11f2d..fb30a2f440a 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -6288,6 +6288,10 @@ x_create_tip_frame (struct x_display_info *dpyinfo, Lisp_Object parms)
f->output_data.x->parent_desc = FRAME_DISPLAY_INFO (f)->root_window;
+ gui_default_parameter (f, parms, Qinhibit_double_buffering, Qnil,
+ "inhibitDoubleBuffering", "InhibitDoubleBuffering",
+ RES_TYPE_BOOLEAN);
+
gui_figure_window_size (f, parms, false, &x_width, &x_height);
{
@@ -6958,6 +6962,7 @@ Text larger than the specified size is clipped. */)
w->must_be_updated_p = true;
update_single_window (w);
+ flush_frame (tip_f);
set_buffer_internal_1 (old_buffer);
unbind_to (count_1, Qnil);
windows_or_buffers_changed = old_windows_or_buffers_changed;
^ permalink raw reply related [flat|nested] 25+ messages in thread* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-06-20 5:01 ` YAMAMOTO Mitsuharu
@ 2019-06-20 9:17 ` YAMAMOTO Mitsuharu
2019-06-20 11:04 ` mituharu
0 siblings, 1 reply; 25+ messages in thread
From: YAMAMOTO Mitsuharu @ 2019-06-20 9:17 UTC (permalink / raw)
To: Noam Postavsky; +Cc: Phil Sainty, 34819
On Thu, 20 Jun 2019 14:01:54 +0900,
YAMAMOTO Mitsuharu wrote:
>
> The contents of the tooltip seems to be usually shown by the
> flush_dirty_back_buffers call from handle_one_xevent. But the control
> does not go back to read_socket_hook during menu tracking, so
> flush_dirty_back_buffers is not called in such a case.
The argument was too rough, actually. During menu tracking,
handle_one_xevent is called via popup_get_selection and
x_dispatch_event. Difference should come from other places.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-06-20 9:17 ` YAMAMOTO Mitsuharu
@ 2019-06-20 11:04 ` mituharu
2019-06-26 12:56 ` Phil Sainty
0 siblings, 1 reply; 25+ messages in thread
From: mituharu @ 2019-06-20 11:04 UTC (permalink / raw)
To: Noam Postavsky, Phil Sainty, 34819
> On Thu, 20 Jun 2019 14:01:54 +0900,
> YAMAMOTO Mitsuharu wrote:
>>
>> The contents of the tooltip seems to be usually shown by the
>> flush_dirty_back_buffers call from handle_one_xevent. But the control
>> does not go back to read_socket_hook during menu tracking, so
>> flush_dirty_back_buffers is not called in such a case.
>
> The argument was too rough, actually. During menu tracking,
> handle_one_xevent is called via popup_get_selection and
> x_dispatch_event. Difference should come from other places.
It turns out the contents of the tooltip is usually shown by
unblock_buffer_flips in double-buffer setting. Calls to
flush_dirty_back_buffers do not contribute to tooltip display
because FRAME_GARBAGED_P is set for the tooltip frame.
I think the patch I posted previously does the right thing.
Please try it.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-06-20 11:04 ` mituharu
@ 2019-06-26 12:56 ` Phil Sainty
2019-06-30 6:31 ` YAMAMOTO Mitsuharu
0 siblings, 1 reply; 25+ messages in thread
From: Phil Sainty @ 2019-06-26 12:56 UTC (permalink / raw)
To: mituharu; +Cc: 34819, Noam Postavsky
On 20/06/19 11:04 PM, mituharu@math.s.chiba-u.ac.jp wrote:
> I think the patch I posted previously does the right thing.
> Please try it.
Thanks; I've just built and tested with this patch, and it does
indeed seem to resolve the problem.
I'm not able to review the code change, but all my previous test
cases are now displaying their tooltips correctly.
-Phil
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#34819: 26.1; Blank help-echo tooltips for mode line menus
2019-06-26 12:56 ` Phil Sainty
@ 2019-06-30 6:31 ` YAMAMOTO Mitsuharu
0 siblings, 0 replies; 25+ messages in thread
From: YAMAMOTO Mitsuharu @ 2019-06-30 6:31 UTC (permalink / raw)
To: Phil Sainty; +Cc: 34819-done, Noam Postavsky
On Wed, 26 Jun 2019 21:56:13 +0900,
Phil Sainty wrote:
>
> On 20/06/19 11:04 PM, mituharu@math.s.chiba-u.ac.jp wrote:
> > I think the patch I posted previously does the right thing.
> > Please try it.
>
> Thanks; I've just built and tested with this patch, and it does
> indeed seem to resolve the problem.
>
> I'm not able to review the code change, but all my previous test
> cases are now displaying their tooltips correctly.
Thanks for testing. I've pushed the patch to master as 82d6b390b5e
(flush_frame part) and 4a5a74a07ff (inhibit-double-buffering part).
Closing the bug.
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2019-06-30 6:31 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-11 23:45 bug#34819: 26.1; Blank help-echo tooltips for mode line menus Phil Sainty
2019-03-12 6:28 ` Phil Sainty
2019-03-12 15:56 ` Eli Zaretskii
2019-03-12 17:21 ` Eli Zaretskii
2019-03-12 20:20 ` Phil Sainty
2019-03-12 15:45 ` Eli Zaretskii
2019-03-12 21:06 ` Glenn Morris
2019-03-13 3:34 ` Eli Zaretskii
2019-03-13 5:03 ` Phil Sainty
2019-03-13 6:37 ` Phil Sainty
2019-03-13 10:31 ` Eli Zaretskii
2019-03-13 11:52 ` Phil Sainty
2019-03-13 15:25 ` Eli Zaretskii
2019-03-13 15:34 ` dancol
2019-03-30 9:27 ` Eli Zaretskii
2019-03-14 5:57 ` Glenn Morris
2019-03-14 6:06 ` Eli Zaretskii
2019-04-02 0:26 ` Noam Postavsky
2019-04-23 9:21 ` martin rudalics
2019-04-23 10:57 ` Noam Postavsky
2019-06-20 5:01 ` YAMAMOTO Mitsuharu
2019-06-20 9:17 ` YAMAMOTO Mitsuharu
2019-06-20 11:04 ` mituharu
2019-06-26 12:56 ` Phil Sainty
2019-06-30 6:31 ` YAMAMOTO Mitsuharu
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).