* bug#20677: tooltips generate garbage @ 2015-05-27 21:40 Angelo Graziosi 2015-05-28 2:43 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-05-27 21:40 UTC (permalink / raw To: 20677 After tooltips show up, they do not disappear moving the mouse but leave garbage in the Emacs frame. I see this (on GNU/Linux, GTK build) in recent Emacs master. This DID NOT happen with the builds I did a few week ago (May 13). Usually "emacs -Q" is enough to see this issue. It seems a redrawing problem because when I click on the upper-right '-' button which reduce Emacs to an icon in status bar and then re-enlarging, the garbage disappears (but re-appears if the mouse pointer is over an element which needs a tooltip). Ciao, Angelo. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-05-27 21:40 bug#20677: tooltips generate garbage Angelo Graziosi @ 2015-05-28 2:43 ` Eli Zaretskii 2015-06-01 11:46 ` Angelo Graziosi 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-05-28 2:43 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677 > Date: Wed, 27 May 2015 23:40:33 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > > After tooltips show up, they do not disappear moving the mouse but leave > garbage in the Emacs frame. > > I see this (on GNU/Linux, GTK build) in recent Emacs master. > > This DID NOT happen with the builds I did a few week ago (May 13). Please try bisecting, as I don't see it here. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-05-28 2:43 ` Eli Zaretskii @ 2015-06-01 11:46 ` Angelo Graziosi 2015-06-01 14:36 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-06-01 11:46 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, jan.h.d Il 28/05/2015 04:43, Eli Zaretskii ha scritto: >> Date: Wed, 27 May 2015 23:40:33 +0200 >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> >> After tooltips show up, they do not disappear moving the mouse but leave >> garbage in the Emacs frame. >> >> I see this (on GNU/Linux, GTK build) in recent Emacs master. >> >> This DID NOT happen with the builds I did a few week ago (May 13). > > Please try bisecting, as I don't see it here. > OK. This master, http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01) works as expected. Instead the next, http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635) shows the tooltip garbage I described. For what I can see, the issue regards only the GTK build on GNU/Linux (Linux Mint 17.1 64 bit, with GTK+ 3.10) Ciao, Angelo. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 11:46 ` Angelo Graziosi @ 2015-06-01 14:36 ` Eli Zaretskii 2015-06-01 15:58 ` Angelo Graziosi 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-01 14:36 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677, jan.h.d > Date: Mon, 01 Jun 2015 13:46:54 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se > > OK. This master, > > > http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz > > (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01) > > works as expected. > > Instead the next, > > > http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz > > (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635) > > shows the tooltip garbage I described. > > For what I can see, the issue regards only the GTK build on GNU/Linux > (Linux Mint 17.1 64 bit, with GTK+ 3.10) Looks like the Cairo merge caused this. Jan, could you take a look, please? Thanks. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 14:36 ` Eli Zaretskii @ 2015-06-01 15:58 ` Angelo Graziosi 2015-06-01 16:19 ` Eli Zaretskii 2015-06-02 0:31 ` Wolfgang Jenkner 0 siblings, 2 replies; 35+ messages in thread From: Angelo Graziosi @ 2015-06-01 15:58 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, jan.h.d Il 01/06/2015 16:36, Eli Zaretskii ha scritto: >> Date: Mon, 01 Jun 2015 13:46:54 +0200 >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se >> >> OK. This master, >> >> >> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-7ac84a2570e1268cc040fcd529508307b2b22c01.tar.gz >> >> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=7ac84a2570e1268cc040fcd529508307b2b22c01) >> >> works as expected. >> >> Instead the next, >> >> >> http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-ee14727ce033bae3bc11af35e7843604e5a5e635.tar.gz >> >> (http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ee14727ce033bae3bc11af35e7843604e5a5e635) >> >> shows the tooltip garbage I described. >> >> For what I can see, the issue regards only the GTK build on GNU/Linux >> (Linux Mint 17.1 64 bit, with GTK+ 3.10) > > Looks like the Cairo merge caused this. Jan, could you take a look, > please? Hmm... given the issue and looking at the changes, this caught my attention: --- a/src/gtkutil.c +++ b/src/gtkutil.c @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f, above. */ oldw += (scale - 1) * oldw; oldx -= (scale - 1) * oldw; - x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), - oldx, oldy, oldw, oldh); + x_clear_area (f, oldx, oldy, oldw, oldh); maybe, on linux+X Emacs needs something like this # if def(...X11..) [...] x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... #else x_clear_area (f, oldx, oldy, oldw, oldh)... #endif Ciao, Angelo. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 15:58 ` Angelo Graziosi @ 2015-06-01 16:19 ` Eli Zaretskii 2015-06-01 21:55 ` Angelo Graziosi 2015-06-02 0:31 ` Wolfgang Jenkner 1 sibling, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-01 16:19 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677, jan.h.d > Date: Mon, 01 Jun 2015 17:58:36 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se > > Hmm... given the issue and looking at the changes, this caught my attention: > > --- a/src/gtkutil.c > +++ b/src/gtkutil.c > @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f, > above. */ > oldw += (scale - 1) * oldw; > oldx -= (scale - 1) * oldw; > - x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), > - oldx, oldy, oldw, oldh); > + x_clear_area (f, oldx, oldy, oldw, oldh); > > maybe, on linux+X Emacs needs something like this > > # if def(...X11..) > [...] > x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... > #else > x_clear_area (f, oldx, oldy, oldw, oldh)... > #endif No, the calling sequence of x_clear_area has changed, so that change was correct, I think. Are you saying that reverting it makes tooltips work again? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 16:19 ` Eli Zaretskii @ 2015-06-01 21:55 ` Angelo Graziosi 2015-06-02 2:33 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-06-01 21:55 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, jan.h.d Il 01/06/2015 18:19, Eli Zaretskii ha scritto: >> Date: Mon, 01 Jun 2015 17:58:36 +0200 >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se >> >> Hmm... given the issue and looking at the changes, this caught my attention: >> >> --- a/src/gtkutil.c >> +++ b/src/gtkutil.c >> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f, >> above. */ >> oldw += (scale - 1) * oldw; >> oldx -= (scale - 1) * oldw; >> - x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), >> - oldx, oldy, oldw, oldh); >> + x_clear_area (f, oldx, oldy, oldw, oldh); >> >> maybe, on linux+X Emacs needs something like this >> >> # if def(...X11..) >> [...] >> x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... >> #else >> x_clear_area (f, oldx, oldy, oldw, oldh)... >> #endif > > No, the calling sequence of x_clear_area has changed, so that change > was correct, I think. Are you saying that reverting it makes tooltips > work again? Really I didn't tested that.. Eventually, I will test that over the next few days.. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 21:55 ` Angelo Graziosi @ 2015-06-02 2:33 ` Eli Zaretskii 2015-06-02 9:23 ` Angelo Graziosi 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 2:33 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677 > Date: Mon, 01 Jun 2015 23:55:55 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se > > Il 01/06/2015 18:19, Eli Zaretskii ha scritto: > >> Date: Mon, 01 Jun 2015 17:58:36 +0200 > >> From: Angelo Graziosi <angelo.graziosi@alice.it> > >> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se > >> > >> Hmm... given the issue and looking at the changes, this caught my attention: > >> > >> --- a/src/gtkutil.c > >> +++ b/src/gtkutil.c > >> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f, > >> above. */ > >> oldw += (scale - 1) * oldw; > >> oldx -= (scale - 1) * oldw; > >> - x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), > >> - oldx, oldy, oldw, oldh); > >> + x_clear_area (f, oldx, oldy, oldw, oldh); > >> > >> maybe, on linux+X Emacs needs something like this > >> > >> # if def(...X11..) > >> [...] > >> x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... > >> #else > >> x_clear_area (f, oldx, oldy, oldw, oldh)... > >> #endif > > > > No, the calling sequence of x_clear_area has changed, so that change > > was correct, I think. Are you saying that reverting it makes tooltips > > work again? > > Really I didn't tested that.. Eventually, I will test that over the next > few days.. Can you show a screenshot of the bad tooltip display? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 2:33 ` Eli Zaretskii @ 2015-06-02 9:23 ` Angelo Graziosi 2015-06-02 9:35 ` Angelo Graziosi 0 siblings, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-06-02 9:23 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677 [-- Attachment #1: Type: text/plain, Size: 1520 bytes --] Il 02/06/2015 04:33, Eli Zaretskii ha scritto: >> Date: Mon, 01 Jun 2015 23:55:55 +0200 >> From: Angelo Graziosi <angelo.graziosi@alice.it> >> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se >> >> Il 01/06/2015 18:19, Eli Zaretskii ha scritto: >>>> Date: Mon, 01 Jun 2015 17:58:36 +0200 >>>> From: Angelo Graziosi <angelo.graziosi@alice.it> >>>> CC: 20677@debbugs.gnu.org, jan.h.d@swipnet.se >>>> >>>> Hmm... given the issue and looking at the changes, this caught my attention: >>>> >>>> --- a/src/gtkutil.c >>>> +++ b/src/gtkutil.c >>>> @@ -3824,8 +3824,7 @@ xg_update_scrollbar_pos (struct frame *f, >>>> above. */ >>>> oldw += (scale - 1) * oldw; >>>> oldx -= (scale - 1) * oldw; >>>> - x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), >>>> - oldx, oldy, oldw, oldh); >>>> + x_clear_area (f, oldx, oldy, oldw, oldh); >>>> >>>> maybe, on linux+X Emacs needs something like this >>>> >>>> # if def(...X11..) >>>> [...] >>>> x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... >>>> #else >>>> x_clear_area (f, oldx, oldy, oldw, oldh)... >>>> #endif >>> >>> No, the calling sequence of x_clear_area has changed, so that change >>> was correct, I think. Are you saying that reverting it makes tooltips >>> work again? >> >> Really I didn't tested that.. Eventually, I will test that over the next >> few days.. > > Can you show a screenshot of the bad tooltip display? > Attached. (Schermata2.png is with "emacs -Q &") [-- Attachment #2: screenshot.tar.gz --] [-- Type: application/gzip, Size: 179367 bytes --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 9:23 ` Angelo Graziosi @ 2015-06-02 9:35 ` Angelo Graziosi 2015-06-02 14:57 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-06-02 9:35 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677 Il 02/06/2015 11:23, Angelo Graziosi ha scritto: > > > Il 02/06/2015 04:33, Eli Zaretskii ha scritto: >> >> Can you show a screenshot of the bad tooltip display? >> > > Attached. (Schermata2.png is with "emacs -Q &") Just for clarification... When I move the mouse pointer over an icon which has a tooltip, this is shown correctly. It is when I move the pointer so that the tooltip should be "closed" that it, partially, remains as shown by screenshots I sent. Whit "emacs -Q" It is a bit more complicated to reproduce the issue: only the tooltips of a few icons give it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 9:35 ` Angelo Graziosi @ 2015-06-02 14:57 ` Eli Zaretskii 2015-06-02 15:31 ` Michael Heerdegen 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 14:57 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677 > Date: Tue, 02 Jun 2015 11:35:02 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > CC: 20677@debbugs.gnu.org > > > Attached. (Schermata2.png is with "emacs -Q &") > > Just for clarification... > > When I move the mouse pointer over an icon which has a tooltip, this is > shown correctly. It is when I move the pointer so that the tooltip > should be "closed" that it, partially, remains as shown by screenshots I > sent. Yes, that's what I deduced from your screenshots, thanks. So it probably means the problem is with x-hide-tip, not with x-show-tip. Somehow, we don't redraw the parts of the frame that were overlaid with the tooltip, when the tip pops down, and the artifacts from the tooltip display stay on screen. Does Emacs clean up the display if you type "M-x redraw-display RET" after the tip pops down? What about covering the frame with the tip artifacts with another frame, then uncovering it -- does the frame get redrawn automatically, and does that remove the artifacts? Finally, can you try setting x-gtk-use-system-tooltips to nil, and see if that makes the problem go away? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 14:57 ` Eli Zaretskii @ 2015-06-02 15:31 ` Michael Heerdegen 2015-06-02 15:39 ` Michael Heerdegen 2015-06-02 16:02 ` Eli Zaretskii 0 siblings, 2 replies; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 15:31 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, Angelo Graziosi Hello Eli, I see this problem, too. Quickly tested your questions with my configuration. > Does Emacs clean up the display if you type "M-x redraw-display RET" > after the tip pops down? Yes. > What about covering the frame with the tip artifacts with another > frame, then uncovering it -- does the frame get redrawn automatically, > and does that remove the artifacts? Yes, it does. Switching to another frame also removes the artifacts. > Finally, can you try setting x-gtk-use-system-tooltips to nil, and see > if that makes the problem go away? Yes, that helps. Reverting 7927a4 as suggested somewhere else in this thread also fixes the problem for me. Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 15:31 ` Michael Heerdegen @ 2015-06-02 15:39 ` Michael Heerdegen 2015-06-02 15:54 ` Michael Heerdegen 2015-06-02 16:02 ` Eli Zaretskii 1 sibling, 1 reply; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 15:39 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, Angelo Graziosi Michael Heerdegen <michael_heerdegen@web.de> writes: > Reverting 7927a4 as suggested somewhere else in this thread also fixes > the problem for me. Mmh, wait, I tested too superficially. Reverting this change and "make" doesn't make a difference. Will try again with "make bootstrap"... ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 15:39 ` Michael Heerdegen @ 2015-06-02 15:54 ` Michael Heerdegen 2015-06-02 16:16 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 15:54 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, Angelo Graziosi Michael Heerdegen <michael_heerdegen@web.de> writes: > Mmh, wait, I tested too superficially. Reverting this change and "make" > doesn't make a difference. Will try again with "make bootstrap"... ... no, reverting that change _doesn't_ make a difference here. BTW, in dired, I can always reproduce the problem by hovering with the mouse. Where text is displayed, the artifact is not visible, only on regions where the buffer is empty. OTOH, in *Packages*, tooltips don't leave artifacts at all. Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 15:54 ` Michael Heerdegen @ 2015-06-02 16:16 ` Eli Zaretskii 2015-06-02 16:33 ` Michael Heerdegen ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 16:16 UTC (permalink / raw To: Michael Heerdegen; +Cc: 20677, angelo.graziosi > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: 20677@debbugs.gnu.org, Angelo Graziosi <angelo.graziosi@alice.it> > Date: Tue, 02 Jun 2015 17:54:27 +0200 > > Michael Heerdegen <michael_heerdegen@web.de> writes: > > > Mmh, wait, I tested too superficially. Reverting this change and "make" > > doesn't make a difference. Will try again with "make bootstrap"... > > ... no, reverting that change _doesn't_ make a difference here. Does it even compile? I think it shouldn't compile. Or maybe I'm missing something. > BTW, in dired, I can always reproduce the problem by hovering with the > mouse. Where text is displayed, the artifact is not visible, only on > regions where the buffer is empty. So this probably means we don't clear the area that was obscured by the tip, we only redisplay the text in the obscured region. Does this match what you see? Can you see whether Emacs gets an expose event when the tip pops down? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:16 ` Eli Zaretskii @ 2015-06-02 16:33 ` Michael Heerdegen 2015-06-02 19:08 ` Eli Zaretskii 2015-06-02 17:06 ` Michael Heerdegen 2015-06-02 17:08 ` Wolfgang Jenkner 2 siblings, 1 reply; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 16:33 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, angelo.graziosi Eli Zaretskii <eliz@gnu.org> writes: > Does it even compile? I think it shouldn't compile. Or maybe I'm > missing something. I tried "make" again, and it compiles. I'm now trying bootstrapping again to see if I missed an error message. > So this probably means we don't clear the area that was obscured by > the tip, we only redisplay the text in the obscured region. Does this > match what you see? Could be. Testing with a buffer in fundamental-mode and M-: (insert (propertize "test" 'help-echo "-----------------")) seems to confirm this when I add more text etc. > Can you see whether Emacs gets an expose event when the tip pops down? Sorry, you've found my limit in understanding. How can check that? Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:33 ` Michael Heerdegen @ 2015-06-02 19:08 ` Eli Zaretskii 2015-06-03 7:01 ` YAMAMOTO Mitsuharu 2015-06-03 16:10 ` Michael Heerdegen 0 siblings, 2 replies; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 19:08 UTC (permalink / raw To: Michael Heerdegen; +Cc: 20677, angelo.graziosi > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: 20677@debbugs.gnu.org, angelo.graziosi@alice.it > Date: Tue, 02 Jun 2015 18:33:56 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Does it even compile? I think it shouldn't compile. Or maybe I'm > > missing something. > > I tried "make" again, and it compiles. I'm now trying bootstrapping > again to see if I missed an error message. The code is in non-GTK portion, so the compiler doesn't see it when you build with GTK. That's why it doesn't complain in that configuration, and that's why reverting that change cannot have any effect on the GTK build. > > Can you see whether Emacs gets an expose event when the tip pops down? > > Sorry, you've found my limit in understanding. How can check that? The function expose_frame (defined in xdisp.c) should be called when such an event comes in. If your Emacs was configured with --enable-checking='yes,glyphs', then you can see the fact that the function is called announced on stderr after invoking "M-x trace-redisplay RET". (If you do that, I suggest to turn off blink-cursor-mode first, to reduce clutter from redisplay cycles induced by the blinking.) Alternatively, put a breakpoint at entry to expose_frame, and see if it's called when the tip pops down. The call should come from handle_one_xevent in xterm.c, where you will see that the call to x_clear_area is not done in the Cairo build -- this could be the culprit, perhaps at least when the GTK tooltip was just popped down. Caveat: please note that I have no idea what does using Cairo change in how Emacs interacts with X, I'm just making stabs in the dark at this point. Thanks. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 19:08 ` Eli Zaretskii @ 2015-06-03 7:01 ` YAMAMOTO Mitsuharu 2015-06-03 13:51 ` Angelo Graziosi 2015-06-03 16:10 ` Michael Heerdegen 1 sibling, 1 reply; 35+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-06-03 7:01 UTC (permalink / raw To: Eli Zaretskii; +Cc: Michael Heerdegen, 20677, angelo.graziosi >>>>> On Tue, 02 Jun 2015 22:08:59 +0300, Eli Zaretskii <eliz@gnu.org> said: >> > Can you see whether Emacs gets an expose event when the tip pops down? >> >> Sorry, you've found my limit in understanding. How can check that? > The function expose_frame (defined in xdisp.c) should be called when > such an event comes in. Could those who see this problem try the following patches, one at a time? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp [FIRST] diff --git a/src/xterm.c b/src/xterm.c index 25c0d87..691ede5 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -7668,7 +7668,7 @@ handle_one_xevent (struct x_display_info *dpyinfo, } else { -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO) +#ifdef USE_GTK /* This seems to be needed for GTK 2.6 and later, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398. */ x_clear_area (f, [SECOND] diff --git a/src/xterm.c b/src/xterm.c index 25c0d87..32d4d3a 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -7668,12 +7668,14 @@ handle_one_xevent (struct x_display_info *dpyinfo, } else { -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO) +#ifdef USE_GTK /* This seems to be needed for GTK 2.6 and later, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398. */ - x_clear_area (f, - event->xexpose.x, event->xexpose.y, - event->xexpose.width, event->xexpose.height); + x_clear_area1 (event->xexpose.display, + event->xexpose.window, + event->xexpose.x, event->xexpose.y, + event->xexpose.width, event->xexpose.height, + False); #endif expose_frame (f, event->xexpose.x, event->xexpose.y, event->xexpose.width, event->xexpose.height); ^ permalink raw reply related [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-03 7:01 ` YAMAMOTO Mitsuharu @ 2015-06-03 13:51 ` Angelo Graziosi 0 siblings, 0 replies; 35+ messages in thread From: Angelo Graziosi @ 2015-06-03 13:51 UTC (permalink / raw To: YAMAMOTO Mitsuharu, Eli Zaretskii; +Cc: Michael Heerdegen, 20677 Il 03/06/2015 09:01, YAMAMOTO Mitsuharu ha scritto: >>>>>> On Tue, 02 Jun 2015 22:08:59 +0300, Eli Zaretskii <eliz@gnu.org> said: > >>>> Can you see whether Emacs gets an expose event when the tip pops down? >>> >>> Sorry, you've found my limit in understanding. How can check that? > >> The function expose_frame (defined in xdisp.c) should be called when >> such an event comes in. > > Could those who see this problem try the following patches, one at a > time? Here (GNU/Linux Mint 17.1 Mate 64bit) both patches seem to work fine! Ciao, Angelo. > > [FIRST] > diff --git a/src/xterm.c b/src/xterm.c > index 25c0d87..691ede5 100644 > --- a/src/xterm.c > +++ b/src/xterm.c > @@ -7668,7 +7668,7 @@ handle_one_xevent (struct x_display_info *dpyinfo, > } > else > { > -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO) > +#ifdef USE_GTK > /* This seems to be needed for GTK 2.6 and later, see > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398. */ > x_clear_area (f, > > > [SECOND] > diff --git a/src/xterm.c b/src/xterm.c > index 25c0d87..32d4d3a 100644 > --- a/src/xterm.c > +++ b/src/xterm.c > @@ -7668,12 +7668,14 @@ handle_one_xevent (struct x_display_info *dpyinfo, > } > else > { > -#if defined (USE_GTK) && ! defined (HAVE_GTK3) && ! defined (USE_CAIRO) > +#ifdef USE_GTK > /* This seems to be needed for GTK 2.6 and later, see > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15398. */ > - x_clear_area (f, > - event->xexpose.x, event->xexpose.y, > - event->xexpose.width, event->xexpose.height); > + x_clear_area1 (event->xexpose.display, > + event->xexpose.window, > + event->xexpose.x, event->xexpose.y, > + event->xexpose.width, event->xexpose.height, > + False); > #endif > expose_frame (f, event->xexpose.x, event->xexpose.y, > event->xexpose.width, event->xexpose.height); > ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 19:08 ` Eli Zaretskii 2015-06-03 7:01 ` YAMAMOTO Mitsuharu @ 2015-06-03 16:10 ` Michael Heerdegen 2015-06-03 16:43 ` Eli Zaretskii 1 sibling, 1 reply; 35+ messages in thread From: Michael Heerdegen @ 2015-06-03 16:10 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, angelo.graziosi Eli Zaretskii <eliz@gnu.org> writes: > > > Can you see whether Emacs gets an expose event when the tip pops > > > down? > If your Emacs was configured with --enable-checking='yes,glyphs', then > you can see the fact that the function is called announced on stderr > after invoking "M-x trace-redisplay RET". (If you do that, I suggest > to turn off blink-cursor-mode first, to reduce clutter from redisplay > cycles induced by the blinking.) I tried just that. Whenever the tip pops down, I get one expose_frame followed by one expose_window. Regards, Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-03 16:10 ` Michael Heerdegen @ 2015-06-03 16:43 ` Eli Zaretskii 2015-06-03 17:02 ` Michael Heerdegen 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-03 16:43 UTC (permalink / raw To: Michael Heerdegen; +Cc: 20677, angelo.graziosi > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: 20677@debbugs.gnu.org, angelo.graziosi@alice.it > Date: Wed, 03 Jun 2015 18:10:00 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > > > Can you see whether Emacs gets an expose event when the tip pops > > > > down? > > > If your Emacs was configured with --enable-checking='yes,glyphs', then > > you can see the fact that the function is called announced on stderr > > after invoking "M-x trace-redisplay RET". (If you do that, I suggest > > to turn off blink-cursor-mode first, to reduce clutter from redisplay > > cycles induced by the blinking.) > > I tried just that. Whenever the tip pops down, I get one expose_frame > followed by one expose_window. And the patches proposed by Yamamoto-san, do they fix the problem for you as well? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-03 16:43 ` Eli Zaretskii @ 2015-06-03 17:02 ` Michael Heerdegen 2015-06-03 19:14 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Michael Heerdegen @ 2015-06-03 17:02 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, angelo.graziosi Eli Zaretskii <eliz@gnu.org> writes: > And the patches proposed by Yamamoto-san, do they fix the problem for > you as well? Yes, both patches fix the problem for me. Like before, I tested with the tooltips in a dired buffer. Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-03 17:02 ` Michael Heerdegen @ 2015-06-03 19:14 ` Eli Zaretskii 2015-06-04 5:25 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-03 19:14 UTC (permalink / raw To: Michael Heerdegen; +Cc: 20677, angelo.graziosi > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: 20677@debbugs.gnu.org, angelo.graziosi@alice.it > Date: Wed, 03 Jun 2015 19:02:55 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > > And the patches proposed by Yamamoto-san, do they fix the problem for > > you as well? > > Yes, both patches fix the problem for me. Like before, I tested with the > tooltips in a dired buffer. Thanks. So which one of them is better, and should be pushed? ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-03 19:14 ` Eli Zaretskii @ 2015-06-04 5:25 ` YAMAMOTO Mitsuharu 2015-06-04 15:37 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-06-04 5:25 UTC (permalink / raw To: Eli Zaretskii; +Cc: Michael Heerdegen, 20677, Jan D., angelo.graziosi >>>>> On Wed, 03 Jun 2015 22:14:45 +0300, Eli Zaretskii <eliz@gnu.org> said: >>> And the patches proposed by Yamamoto-san, do they fix the problem >>> for you as well? >> >> Yes, both patches fix the problem for me. Like before, I tested >> with the tooltips in a dired buffer. > Thanks. > So which one of them is better, and should be pushed? Thanks for testing. The second one is closer to the code before the cairo merge, but the first would be better if it works. Jan, do you have any comments about this? I guess some experimental code has been accidentally slipped in, but just in case you have any intentions or ideas especially about newer versions of GTK+... YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-04 5:25 ` YAMAMOTO Mitsuharu @ 2015-06-04 15:37 ` Eli Zaretskii 2015-06-05 0:50 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2015-06-04 15:37 UTC (permalink / raw To: YAMAMOTO Mitsuharu; +Cc: michael_heerdegen, 20677, jan.h.d, angelo.graziosi > Date: Thu, 04 Jun 2015 14:25:28 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: Michael Heerdegen <michael_heerdegen@web.de>, > 20677@debbugs.gnu.org, > angelo.graziosi@alice.it, "Jan D." <jan.h.d@swipnet.se> > > >> Yes, both patches fix the problem for me. Like before, I tested > >> with the tooltips in a dired buffer. > > > Thanks. > > > So which one of them is better, and should be pushed? > > Thanks for testing. The second one is closer to the code before the > cairo merge, but the first would be better if it works. I agree that the first patch looks better, as x_clear_area1 sounds like a helper function. So I suggest that we push that in a couple of days. Thanks. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-04 15:37 ` Eli Zaretskii @ 2015-06-05 0:50 ` YAMAMOTO Mitsuharu 2015-06-05 7:04 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: YAMAMOTO Mitsuharu @ 2015-06-05 0:50 UTC (permalink / raw To: Eli Zaretskii; +Cc: michael_heerdegen, 20677-done, angelo.graziosi >>>>> On Thu, 04 Jun 2015 18:37:51 +0300, Eli Zaretskii <eliz@gnu.org> said: >> > So which one of them is better, and should be pushed? >> >> Thanks for testing. The second one is closer to the code before >> the cairo merge, but the first would be better if it works. > I agree that the first patch looks better, as x_clear_area1 sounds > like a helper function. So I suggest that we push that in a couple > of days. I pushed the first patch in dcf18b5. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-05 0:50 ` YAMAMOTO Mitsuharu @ 2015-06-05 7:04 ` Eli Zaretskii 0 siblings, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2015-06-05 7:04 UTC (permalink / raw To: YAMAMOTO Mitsuharu; +Cc: michael_heerdegen, 20677, angelo.graziosi > Date: Fri, 05 Jun 2015 09:50:13 +0900 > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> > Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, > michael_heerdegen@web.de, > 20677-done@debbugs.gnu.org, > angelo.graziosi@alice.it > > >>>>> On Thu, 04 Jun 2015 18:37:51 +0300, Eli Zaretskii <eliz@gnu.org> said: > > >> > So which one of them is better, and should be pushed? > >> > >> Thanks for testing. The second one is closer to the code before > >> the cairo merge, but the first would be better if it works. > > > I agree that the first patch looks better, as x_clear_area1 sounds > > like a helper function. So I suggest that we push that in a couple > > of days. > > I pushed the first patch in dcf18b5. Thanks. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:16 ` Eli Zaretskii 2015-06-02 16:33 ` Michael Heerdegen @ 2015-06-02 17:06 ` Michael Heerdegen 2015-06-02 17:08 ` Wolfgang Jenkner 2 siblings, 0 replies; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 17:06 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, angelo.graziosi Eli Zaretskii <eliz@gnu.org> writes: > Does it even compile? I think it shouldn't compile. Or maybe I'm > missing something. I guess I was not reverting what you had in mind. I was reverting 7927a4a - probably not the commit you were speaking about. Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:16 ` Eli Zaretskii 2015-06-02 16:33 ` Michael Heerdegen 2015-06-02 17:06 ` Michael Heerdegen @ 2015-06-02 17:08 ` Wolfgang Jenkner 2 siblings, 0 replies; 35+ messages in thread From: Wolfgang Jenkner @ 2015-06-02 17:08 UTC (permalink / raw To: Eli Zaretskii; +Cc: Michael Heerdegen, 20677, angelo.graziosi On Tue, Jun 02 2015, Eli Zaretskii wrote: > Or maybe I'm missing something. Yes, the surrounding preprocessor conditional... (the commit message hints at that as well). ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 15:31 ` Michael Heerdegen 2015-06-02 15:39 ` Michael Heerdegen @ 2015-06-02 16:02 ` Eli Zaretskii 2015-06-02 16:14 ` Michael Heerdegen 2015-06-02 17:04 ` Angelo Graziosi 1 sibling, 2 replies; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 16:02 UTC (permalink / raw To: Michael Heerdegen; +Cc: 20677, angelo.graziosi > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: Angelo Graziosi <angelo.graziosi@alice.it>, 20677@debbugs.gnu.org > Date: Tue, 02 Jun 2015 17:31:55 +0200 > > I see this problem, too. Quickly tested your questions with my > configuration. Thanks. > > Does Emacs clean up the display if you type "M-x redraw-display RET" > > after the tip pops down? > > Yes. > > > What about covering the frame with the tip artifacts with another > > frame, then uncovering it -- does the frame get redrawn automatically, > > and does that remove the artifacts? > > Yes, it does. Switching to another frame also removes the artifacts. > > > Finally, can you try setting x-gtk-use-system-tooltips to nil, and see > > if that makes the problem go away? > > Yes, that helps. OK, so it seems my guess was correct: we don't redraw the portions of display that were obscured by the tooltip. > Reverting 7927a4 as suggested somewhere else in this thread also fixes > the problem for me. I don't understand this. After reverting it, what does "git diff" say about the differences between what you have and current master HEAD? If it's just the diffs below (which is the reverse of what I see if I type "git show 7927a4"), then how can the result work, when x_clear_area now has this signature: void x_clear_area (struct frame *f, int x, int y, int width, int height); IOW, reverting 7927a4 seems to cause us call x_clear_area with a wrong argument list. How does this even compile? What am I missing? diff --git a/src/xfns.c b/src/xfns.c index 5ac58e9..16a568e 100644 --- a/src/xfns.c +++ b/src/xfns.c @@ -1084,7 +1084,8 @@ struct x_display_info * y = FRAME_TOP_MARGIN_HEIGHT (f); block_input (); - x_clear_area (f, 0, y, width, height); + x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), + 0, y, width, height); unblock_input (); } @@ -1095,8 +1094,7 @@ struct x_display_info * height = nlines * FRAME_LINE_HEIGHT (f) - y; block_input (); - x_clear_area (f, 0, y, width, height); + x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), + 0, y, width, height); unblock_input (); } ^ permalink raw reply related [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:02 ` Eli Zaretskii @ 2015-06-02 16:14 ` Michael Heerdegen 2015-06-02 17:04 ` Angelo Graziosi 1 sibling, 0 replies; 35+ messages in thread From: Michael Heerdegen @ 2015-06-02 16:14 UTC (permalink / raw To: Eli Zaretskii; +Cc: 20677, angelo.graziosi Eli Zaretskii <eliz@gnu.org> writes: > > Reverting 7927a4 as suggested somewhere else in this thread also > > fixes the problem for me. > > I don't understand this. Yip, I was wrong, sorry for the confusion... Michael. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 16:02 ` Eli Zaretskii 2015-06-02 16:14 ` Michael Heerdegen @ 2015-06-02 17:04 ` Angelo Graziosi 2015-06-02 18:56 ` Eli Zaretskii 1 sibling, 1 reply; 35+ messages in thread From: Angelo Graziosi @ 2015-06-02 17:04 UTC (permalink / raw To: Eli Zaretskii, Michael Heerdegen; +Cc: 20677 Il 02/06/2015 18:02, Eli Zaretskii ha scritto: > > IOW, reverting 7927a4 seems to cause us call x_clear_area with a wrong > argument list. How does this even compile? What am I missing? I tried this in gtkutil.c + x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), + oldx, oldy, oldw, oldh); - x_clear_area (f, oldx, oldy, oldw, oldh); and it didn't compile (wrong number of arguments)... I don't understand this: > > diff --git a/src/xfns.c b/src/xfns.c > index 5ac58e9..16a568e 100644 > --- a/src/xfns.c > +++ b/src/xfns.c > @@ -1084,7 +1084,8 @@ struct x_display_info * > y = FRAME_TOP_MARGIN_HEIGHT (f); > > block_input (); > - x_clear_area (f, 0, y, width, height); > + x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), > + 0, y, width, height); > unblock_input (); > } > > @@ -1095,8 +1094,7 @@ struct x_display_info * > height = nlines * FRAME_LINE_HEIGHT (f) - y; > > block_input (); > - x_clear_area (f, 0, y, width, height); > + x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), > + 0, y, width, height); > unblock_input (); > } remember that 79bbe53a991007036ce9bcf897a4ce1371f516ea 2015-05-23 09:21:27 (GMT) works as expected, while ee14727ce033bae3bc11af35e7843604e5a5e635 2015-05-23 10:27:56 (GMT) shows the issue, and ee14727ce033bae3bc1... has already xfns.c with that above (+) code.. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 17:04 ` Angelo Graziosi @ 2015-06-02 18:56 ` Eli Zaretskii 0 siblings, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2015-06-02 18:56 UTC (permalink / raw To: Angelo Graziosi; +Cc: michael_heerdegen, 20677 > Date: Tue, 02 Jun 2015 19:04:39 +0200 > From: Angelo Graziosi <angelo.graziosi@alice.it> > CC: 20677@debbugs.gnu.org > > remember that > > 79bbe53a991007036ce9bcf897a4ce1371f516ea 2015-05-23 09:21:27 (GMT) > > works as expected, while > > ee14727ce033bae3bc11af35e7843604e5a5e635 2015-05-23 10:27:56 (GMT) > > shows the issue, and ee14727ce033bae3bc1... has already xfns.c with that > above (+) code.. AFAIU, the changes between these two commits include the entire Cairo merge, so I see no way to use this information to find the problem in an efficient way. For all I know, it could simply be an omission in the Cairo related code, not something introduced by the merge. The only way of finding the problem is debug this in the current codebase. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-01 15:58 ` Angelo Graziosi 2015-06-01 16:19 ` Eli Zaretskii @ 2015-06-02 0:31 ` Wolfgang Jenkner 2015-06-02 9:21 ` Angelo Graziosi 1 sibling, 1 reply; 35+ messages in thread From: Wolfgang Jenkner @ 2015-06-02 0:31 UTC (permalink / raw To: Angelo Graziosi; +Cc: 20677, jan.h.d On Mon, Jun 01 2015, Angelo Graziosi wrote: > maybe, on linux+X Emacs needs something like this > > # if def(...X11..) > [...] > x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... The commit log says (USE_CAIRO): Default to yes for Gtk+ 3. Add code to test for cairo, So I guess x_clear_area uses the new cairo specific code in your case. You could try to configure --without-cairo. ^ permalink raw reply [flat|nested] 35+ messages in thread
* bug#20677: tooltips generate garbage 2015-06-02 0:31 ` Wolfgang Jenkner @ 2015-06-02 9:21 ` Angelo Graziosi 0 siblings, 0 replies; 35+ messages in thread From: Angelo Graziosi @ 2015-06-02 9:21 UTC (permalink / raw To: Wolfgang Jenkner; +Cc: 20677, jan.h.d Il 02/06/2015 02:31, Wolfgang Jenkner ha scritto: > On Mon, Jun 01 2015, Angelo Graziosi wrote: > >> maybe, on linux+X Emacs needs something like this >> >> # if def(...X11..) >> [...] >> x_clear_area (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f)... > > > The commit log says > > (USE_CAIRO): Default to yes for Gtk+ 3. Add code to test for cairo, > > So I guess x_clear_area uses the new cairo specific code in your case. > > You could try to configure --without-cairo. > I tried that but doesn't work.. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2015-06-05 7:04 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-05-27 21:40 bug#20677: tooltips generate garbage Angelo Graziosi 2015-05-28 2:43 ` Eli Zaretskii 2015-06-01 11:46 ` Angelo Graziosi 2015-06-01 14:36 ` Eli Zaretskii 2015-06-01 15:58 ` Angelo Graziosi 2015-06-01 16:19 ` Eli Zaretskii 2015-06-01 21:55 ` Angelo Graziosi 2015-06-02 2:33 ` Eli Zaretskii 2015-06-02 9:23 ` Angelo Graziosi 2015-06-02 9:35 ` Angelo Graziosi 2015-06-02 14:57 ` Eli Zaretskii 2015-06-02 15:31 ` Michael Heerdegen 2015-06-02 15:39 ` Michael Heerdegen 2015-06-02 15:54 ` Michael Heerdegen 2015-06-02 16:16 ` Eli Zaretskii 2015-06-02 16:33 ` Michael Heerdegen 2015-06-02 19:08 ` Eli Zaretskii 2015-06-03 7:01 ` YAMAMOTO Mitsuharu 2015-06-03 13:51 ` Angelo Graziosi 2015-06-03 16:10 ` Michael Heerdegen 2015-06-03 16:43 ` Eli Zaretskii 2015-06-03 17:02 ` Michael Heerdegen 2015-06-03 19:14 ` Eli Zaretskii 2015-06-04 5:25 ` YAMAMOTO Mitsuharu 2015-06-04 15:37 ` Eli Zaretskii 2015-06-05 0:50 ` YAMAMOTO Mitsuharu 2015-06-05 7:04 ` Eli Zaretskii 2015-06-02 17:06 ` Michael Heerdegen 2015-06-02 17:08 ` Wolfgang Jenkner 2015-06-02 16:02 ` Eli Zaretskii 2015-06-02 16:14 ` Michael Heerdegen 2015-06-02 17:04 ` Angelo Graziosi 2015-06-02 18:56 ` Eli Zaretskii 2015-06-02 0:31 ` Wolfgang Jenkner 2015-06-02 9:21 ` Angelo Graziosi
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.