GNU bug report logs -
#34819
26.1; Blank help-echo tooltips for mode line menus
Previous Next
Reported by: Phil Sainty <psainty <at> orcon.net.nz>
Date: Mon, 11 Mar 2019 23:48:02 UTC
Severity: normal
Tags: confirmed
Merged with 33068
Found in versions 26.1, 26.1.50
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34819 in the body.
You can then email your comments to 34819 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Mon, 11 Mar 2019 23:48:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Phil Sainty <psainty <at> orcon.net.nz>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 11 Mar 2019 23:48:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 06:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 15:47:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 12 Mar 2019 12:45:58 +1300
> From: Phil Sainty <psainty <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 15:58:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 12 Mar 2019 19:28:53 +1300
> From: Phil Sainty <psainty <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 17:23:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 12 Mar 2019 17:56:56 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 34819 <at> 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.
Added tag(s) confirmed.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 12 Mar 2019 19:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 20:21:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 12 Mar 2019 21:07:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 34819 <at> debbugs.gnu.org (full text, mbox):
Bisected to c29071587c64efb30792bd72248d3c791abd9337.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 03:35:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 12 Mar 2019 17:06:10 -0400
> Cc: 34819 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 05:04:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 06:38:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 10:32:01 GMT)
Full text and
rfc822 format available.
Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):
On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 10:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 11:53:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 34819 <at> debbugs.gnu.org (full text, mbox):
On 13/03/19 11:31 PM, Eli Zaretskii wrote:
> On March 13, 2019 8:37:19 AM GMT+02:00, Phil Sainty <psainty <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 15:26:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: Daniel Colascione <dancol <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 13 Mar 2019 15:35:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 34819 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Thu, 14 Mar 2019 05:58:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Thu, 14 Mar 2019 06:07:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Phil Sainty <psainty <at> orcon.net.nz>, 34819 <at> debbugs.gnu.org, dancol <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Sat, 30 Mar 2019 09:28:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 13 Mar 2019 08:34:11 -0700
> From: dancol <at> dancol.org
> Cc: Phil Sainty <psainty <at> orcon.net.nz>, 34819 <at> debbugs.gnu.org, rgm <at> gnu.org
Ping! Any news on this?
> On Mar 13, 2019 8:25 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Phil Sainty <psainty <at> orcon.net.nz>
> > Cc: Daniel Colascione <dancol <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 02 Apr 2019 00:27:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 34819 <at> debbugs.gnu.org (full text, mbox):
merge 34819 33068
quit
Glenn Morris <rgm <at> 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.
Merged 33068 34819.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 02 Apr 2019 00:27:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 23 Apr 2019 09:22:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> That makes it the same as #33068 then, if I understand correctly.
Good catch. Do you have any ideas how to fix this?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Tue, 23 Apr 2019 10:58:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 34819 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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.
Merged 33068 34819 36298.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 19 Jun 2019 20:37:03 GMT)
Full text and
rfc822 format available.
Disconnected #36298 from all other report(s).
Request was from
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
to
control <at> debbugs.gnu.org
.
(Thu, 20 Jun 2019 02:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Thu, 20 Jun 2019 05:02:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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;
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Thu, 20 Jun 2019 09:19:01 GMT)
Full text and
rfc822 format available.
Message #79 received at 34819 <at> debbugs.gnu.org (full text, mbox):
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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Thu, 20 Jun 2019 11:05:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 34819 <at> debbugs.gnu.org (full text, mbox):
> 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 <at> math.s.chiba-u.ac.jp
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34819
; Package
emacs
.
(Wed, 26 Jun 2019 12:57:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 34819 <at> debbugs.gnu.org (full text, mbox):
On 20/06/19 11:04 PM, mituharu <at> 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
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
:
You have taken responsibility.
(Sun, 30 Jun 2019 06:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Phil Sainty <psainty <at> orcon.net.nz>
:
bug acknowledged by developer.
(Sun, 30 Jun 2019 06:32:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 34819-done <at> debbugs.gnu.org (full text, mbox):
On Wed, 26 Jun 2019 21:56:13 +0900,
Phil Sainty wrote:
>
> On 20/06/19 11:04 PM, mituharu <at> 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 <at> math.s.chiba-u.ac.jp
Reply sent
to
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
:
You have taken responsibility.
(Sun, 30 Jun 2019 06:32:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Carlos Pita <carlosjosepita <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 30 Jun 2019 06:32:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 28 Jul 2019 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 245 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.