GNU bug report logs - #17588
24.3.91; mouse-face glitchy

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17588 in the body.
You can then email your comments to 17588 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.91; mouse-face glitchy
Date: Sun, 25 May 2014 15:04:18 -0400 (EDT)

[Message part 1 (text/plain, inline)]

    emacs -q
    M-: (run-at-time nil 0.01
                     (lambda ()
                       (with-current-buffer (get-buffer-create "rms")
                         (with-silent-modifications
                           (dotimes (_ 10)
                             (insert (if (= (random 2) 1) "gpl" "fsf") "\n")))
                         (when (> (- (point-max) (point-min)) 100)
                           (delete-region (point-min) (+ (point-min) 100)))))) RET
    C-x 2
    C-x 3
    C-x b rms RET
    C-x o
    C-x b rms2 RET
    C-x o
    C-x b rms2 RET
    M-: (dotimes (i 1000)
          (insert (propertize (format "%3d%3d%3d" i i i)
                              'mouse-face 'highlight)
                  "\n")) RET
    # Move your mouse pointer around within the rms2 windows and the
    # modeline of the rms window.

I see two glitches with regard to mouse-face highlighting.  Either there
is no highlighting at all or the font does not switch back to the
regular one after leaving the connected highlight region.

[bug.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

This recipe is not exactly reliable.  It usually takes up to 20 seconds
of mouse movement to trigger the issue here.  Some scrolling helps.

I realise my recipe puts a lot of pressure on the display engine.  When
reducing the timer's REPEAT value, the issue does not vanish but is
harder to reproduce.  My real use-case, which provokes this issue after
a few minutes, is a process filter which updates the buffer of a window
exactly once a second.

When applying this recipe to 24.3 on the same system using the same
libraries for building the binary, there are some glitches.  Most
notably the mouse face of mode-line-buffer-identification is not reset
reliably.  Yet 24.3.91 is a lot worse than 24.3.  IMO this is a
regression.

    In GNU Emacs 24.3.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
    Repository revision: 117154 eliz <at> gnu.org-20140525141846-w6719v7ajcd3tbkk
    Windowing system distributor `The X.Org Foundation', version 11.0.11204000

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Sun, 25 May 2014 22:25:31 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Sun, 25 May 2014 15:04:18 -0400 (EDT)
> 
>     emacs -q
>     M-: (run-at-time nil 0.01
>                      (lambda ()
>                        (with-current-buffer (get-buffer-create "rms")
>                          (with-silent-modifications
>                            (dotimes (_ 10)
>                              (insert (if (= (random 2) 1) "gpl" "fsf") "\n")))
>                          (when (> (- (point-max) (point-min)) 100)
>                            (delete-region (point-min) (+ (point-min) 100)))))) RET
>     C-x 2
>     C-x 3
>     C-x b rms RET
>     C-x o
>     C-x b rms2 RET
>     C-x o
>     C-x b rms2 RET
>     M-: (dotimes (i 1000)
>           (insert (propertize (format "%3d%3d%3d" i i i)
>                               'mouse-face 'highlight)
>                   "\n")) RET
>     # Move your mouse pointer around within the rms2 windows and the
>     # modeline of the rms window.
> 
> I see two glitches with regard to mouse-face highlighting.  Either there
> is no highlighting at all or the font does not switch back to the
> regular one after leaving the connected highlight region.
> 
> This recipe is not exactly reliable.  It usually takes up to 20 seconds
> of mouse movement to trigger the issue here.  Some scrolling helps.
> 
> I realise my recipe puts a lot of pressure on the display engine.  When
> reducing the timer's REPEAT value, the issue does not vanish but is
> harder to reproduce.  My real use-case, which provokes this issue after
> a few minutes, is a process filter which updates the buffer of a window
> exactly once a second.
> 
> When applying this recipe to 24.3 on the same system using the same
> libraries for building the binary, there are some glitches.  Most
> notably the mouse face of mode-line-buffer-identification is not reset
> reliably.  Yet 24.3.91 is a lot worse than 24.3.  IMO this is a
> regression.

I see no problems with this recipe on my system.  Maybe my machine is
faster than yours.

In general, each redisplay requires removing the mouse-highlight and
then re-applying it, so if Emacs cannot keep up, you might see
annoyingly visible flickering or even such extreme effects as you
describe.  There's nothing new here.

May I ask what is the real-life situation where you need to refresh
the display at such high frequency?

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Sun, 25 May 2014 16:04:43 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
> In general, each redisplay requires removing the mouse-highlight and
> then re-applying it, so if Emacs cannot keep up, you might see
> annoyingly visible flickering or even such extreme effects as you
> describe.  There's nothing new here.

There is no flickering.  The artefacts are permanent.

It can work just fine.  Something triggers the issue.  After triggering,
scrolling or resizing windows of the affected frame usually make the
artefacts disappear again and highlighting works just fine.

The window configuration of my recipe is important, too.  Using just one
rms2 window makes it impossible to reproduce this issue here.

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Sun, 25 May 2014 15:04:18 -0400 (EDT)
[...]
>> My real use-case, which provokes this issue after a few minutes, is a
>> process filter which updates the buffer of a window exactly once a
>> second.
[...]
> May I ask what is the real-life situation where you need to refresh
> the display at such high frequency?

I do not think updating a window once a second is unreasonable.  I have
never seen this issue with 24.3.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 05:38:01 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Sun, 25 May 2014 16:04:43 -0400 (EDT)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > In general, each redisplay requires removing the mouse-highlight and
> > then re-applying it, so if Emacs cannot keep up, you might see
> > annoyingly visible flickering or even such extreme effects as you
> > describe.  There's nothing new here.
> 
> There is no flickering.  The artefacts are permanent.
> 
> It can work just fine.  Something triggers the issue.  After triggering,
> scrolling or resizing windows of the affected frame usually make the
> artefacts disappear again and highlighting works just fine.
> 
> The window configuration of my recipe is important, too.  Using just one
> rms2 window makes it impossible to reproduce this issue here.
> 
> > From: Christopher Schmidt <ch <at> ristopher.com>
> > Date: Sun, 25 May 2014 15:04:18 -0400 (EDT)
> [...]
> >> My real use-case, which provokes this issue after a few minutes, is a
> >> process filter which updates the buffer of a window exactly once a
> >> second.
> [...]
> > May I ask what is the real-life situation where you need to refresh
> > the display at such high frequency?
> 
> I do not think updating a window once a second is unreasonable.  I have
> never seen this issue with 24.3.

Well, I don't see any issues now, either.  Perhaps some other factor
is at work here.

How was your Emacs built?  (The information collected by
'report-emacs-bug' was not present in your report.)

Also, can you try running this on some other machine, perhaps a faster
one?

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 04:35:18 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
> How was your Emacs built?  (The information collected by
> 'report-emacs-bug' was not present in your report.)

No explicit configuration options were used.

I used a recent build of the emacs-24 branch for this report.  AFAICT
bug reports via M-x report-emacs-bug RET in emacs-24 do not expose
configuration features beyond what is in system-configuration-options.

Using the trunk, where I can reproduce this issue with my recipe as
well, I get

    Configured features:
    XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY LIBSELINUX LIBXML2
    FREETYPE XFT ZLIB

This is what configure says:

    Configured for `x86_64-unknown-linux-gnu'.

      Where should the build process find the source code?    .
      What compiler should emacs be built with?               gcc -std=gnu99 -g3 -O2
      Should Emacs use the GNU version of malloc?             yes
          (Using Doug Lea's new malloc from the GNU C Library.)
      Should Emacs use a relocating allocator for buffers?    no
      Should Emacs use mmap(2) for buffer allocation?         no
      What window system should Emacs use?                    x11
      What toolkit should Emacs use?                          GTK2
      Where do we find X Windows header files?                Standard dirs
      Where do we find X Windows libraries?                   Standard dirs
      Does Emacs use -lXaw3d?                                 no
      Does Emacs use -lXpm?                                   yes
      Does Emacs use -ljpeg?                                  yes
      Does Emacs use -ltiff?                                  yes
      Does Emacs use a gif library?                           yes -lgif
      Does Emacs use a png library?                           yes -lpng12 -lz -lm
      Does Emacs use -lrsvg-2?                                no
      Does Emacs use imagemagick?                             no
      Does Emacs support sound?                               yes
      Does Emacs use -lgpm?                                   no
      Does Emacs use -ldbus?                                  yes
      Does Emacs use -lgconf?                                 no
      Does Emacs use GSettings?                               yes
      Does Emacs use a file notification library?             yes -lgio (gfile)
      Does Emacs use access control lists?                    no
      Does Emacs use -lselinux?                               yes
      Does Emacs use -lgnutls?                                no
      Does Emacs use -lxml2?                                  yes
      Does Emacs use -lfreetype?                              yes
      Does Emacs use -lm17n-flt?                              no
      Does Emacs use -lotf?                                   no
      Does Emacs use -lxft?                                   yes
      Does Emacs directly use zlib?                           yes
      Does Emacs use toolkit scroll bars?                     yes

My environment specs can be found in the initial message:

    In GNU Emacs 24.3.91.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
    Repository revision: 117154 eliz <at> gnu.org-20140525141846-w6719v7ajcd3tbkk
    Windowing system distributor `The X.Org Foundation', version 11.0.11204000

This is a Debian GNU/Linux "wheezy" system.  This issue can be
reproduced with GTK+ 3, too.

> Also, can you try running this on some other machine, perhaps a faster
> one?

I do not have access to any other machine with a window system at the
moment.

This one:

    $ grep "model name" /proc/cpuinfo | uniq
    model name	: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 18:37:27 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Mon, 26 May 2014 04:35:18 -0400 (EDT)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > How was your Emacs built?  (The information collected by
> > 'report-emacs-bug' was not present in your report.)
> 
> No explicit configuration options were used.
> 
> I used a recent build of the emacs-24 branch for this report.  AFAICT
> bug reports via M-x report-emacs-bug RET in emacs-24 do not expose
> configuration features beyond what is in system-configuration-options.

Sorry, I didn't see the telltale "Configured with:" heading, and
assumed that you elided that part.  That heading is present in the
branch version as well.

> I do not have access to any other machine with a window system at the
> moment.
> 
> This one:
> 
>     $ grep "model name" /proc/cpuinfo | uniq
>     model name	: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

This is even slightly better than mine (Core i7-2600 CPU @ 3.40).  And
on top of that, your build is optimized, so should be roughly twice
faster than what I'm running.

IOW, this is hardly about CPU power, at least not as far as Emacs's
application thread is concerned.  It is also probably X specific.

Can you see how much of your CPU resources are busy when you run the
recipe?  When I run it here, I see about 12% to 25% of a single
execution unit occupied by Emacs.  Do you see something different, and
do you see some other process (e.g., the X server) pegging the CPU,
perhaps?

Another thought is to see whether the function that paints and clears
the mouse highlight is called when it should be.  You could add some
printf to note_mouse_highlight, where it calls show_mouse_face and
clear_mouse_face, and see if the corresponding print-outs are visible
when they should be.  E.g., if you move the mouse pointer from one
line of text with mouse face to another, you should see a call that
clears mouse face on the previous line and shows it on the current
one.

Thanks.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 16:17:11 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
> Another thought is to see whether the function that paints and clears
> the mouse highlight is called when it should be.  You could add some
> printf to note_mouse_highlight, where it calls show_mouse_face and
> clear_mouse_face, and see if the corresponding print-outs are visible
> when they should be.  E.g., if you move the mouse pointer from one
> line of text with mouse face to another, you should see a call that
> clears mouse face on the previous line and shows it on the current
> one.

It does not look like there are calls missing.

Whenever the faulty behaviour is present, in clear_mouse_face
NILP (hlinfo->mouse_face_window) is always true and therefore the
highlighting is not cleared.

clear_mouse_face w/ bug:

    (gdb) p *hlinfo
     {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 37,
      mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0,
      mouse_face_window = 12026738, mouse_face_face_id = 34, mouse_face_overlay = 12026738,
      mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = -1, mouse_face_mouse_y = -1,
      mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false}
    (gdb) p NILP (hlinfo->mouse_face_window)
     true

clear_mouse_face w/o bug:

    (gdb) p *hlinfo
     {mouse_face_beg_row = 8, mouse_face_beg_col = 0, mouse_face_beg_x = 0,
      mouse_face_end_row = 8, mouse_face_end_col = 9, mouse_face_end_x = 81,
      mouse_face_window = 18061725, mouse_face_face_id = 25, mouse_face_overlay = 12026738,
      mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = 394, mouse_face_mouse_y = 393,
      mouse_face_past_end = false, mouse_face_defer = false,
      mouse_face_hidden = false}
    (gdb) p NILP (hlinfo->mouse_face_window)
     false

Message #26 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <ch <at> ristopher.com>, 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 22:45:11 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Well, I don't see any issues now, either.  Perhaps some other factor
> is at work here.
>
> How was your Emacs built?  (The information collected by
> 'report-emacs-bug' was not present in your report.)
>
> Also, can you try running this on some other machine, perhaps a faster
> one?

FWIW, when I follow the recipe, I see exactly the behavior as
Christopher described.  I have a recent build of the emacs-24 branch on
Debian,

(emacs-version) => "GNU Emacs 24.3.91.1
  (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
  of 2014-05-25 on drachen"

The artifacts in the mode-line/ outdated mouse highlighting stay there
for minutes, until I e.g. switch to a different window.

Michael.

Message #29 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <ch <at> ristopher.com>, 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Mon, 26 May 2014 23:17:19 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> (emacs-version) => "GNU Emacs 24.3.91.1
>   (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
>   of 2014-05-25 on drachen"

I have rebuilt Emacs with the lucid X toolkit.  There is no
difference with that build, it shows exactly the same symptoms.

Michael.

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 05:40:40 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Mon, 26 May 2014 16:17:11 -0400 (EDT)
> 
> It does not look like there are calls missing.
> 
> Whenever the faulty behaviour is present, in clear_mouse_face
> NILP (hlinfo->mouse_face_window) is always true and therefore the
> highlighting is not cleared.

Which faulty behavior: the one when there's no highlighting at all, or
the one when it's present, but not cleared when the mouse pointer
moves off the text?

> clear_mouse_face w/o bug:

"w/o bug" meaning what? a different Emacs version or the same version,
but when it behaves correctly?

Message #35 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: ch <at> ristopher.com, 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 05:42:41 +0300

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: Christopher Schmidt <ch <at> ristopher.com>,  17588 <at> debbugs.gnu.org
> Date: Mon, 26 May 2014 23:17:19 +0200
> 
> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> 
> > (emacs-version) => "GNU Emacs 24.3.91.1
> >   (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
> >   of 2014-05-25 on drachen"
> 
> I have rebuilt Emacs with the lucid X toolkit.  There is no
> difference with that build, it shows exactly the same symptoms.

That's expected: mouse highlight is an Emacs features, for which we
use no toolkit-specific tricks.

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 03:21:26 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Christopher Schmidt <ch <at> ristopher.com>
>> Date: Mon, 26 May 2014 16:17:11 -0400 (EDT)
>> Whenever the faulty behaviour is present, in clear_mouse_face
>> NILP (hlinfo->mouse_face_window) is always true and therefore the
>> highlighting is not cleared.
>
> Which faulty behavior: the one when there's no highlighting at all, or
> the one when it's present, but not cleared when the mouse pointer
> moves off the text?

The window, in which I moved my mouse pointer around, had working
highlighting that was not cleared.

Most of the time both issues are present.  That is, in one window
highlighting is present but not cleared whereas in another one there is
no highlighting at all.

>> clear_mouse_face w/o bug:
>
> "w/o bug" meaning what? a different Emacs version or the same version,
> but when it behaves correctly?

That is from the very same process that exposed the issue but then
recovered somehow.

Message #41 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Christopher Schmidt <ch <at> ristopher.com>
Cc: 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 15:09:30 +0200

> I see no problems with this recipe on my system.  Maybe my machine is
> faster than yours.

It doesn't happen on my Windows builds and I have no clue why.  But I can
reproduce it with my Debian build.

martin

Message #44 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: ch <at> ristopher.com, 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 18:33:32 +0300

> Date: Tue, 27 May 2014 15:09:30 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 17588 <at> debbugs.gnu.org
> 
> > I see no problems with this recipe on my system.  Maybe my machine is
> > faster than yours.
> 
> It doesn't happen on my Windows builds and I have no clue why.  But I can
> reproduce it with my Debian build.

Because it's X-specific.

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 19:04:12 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Tue, 27 May 2014 03:21:26 -0400 (EDT)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> From: Christopher Schmidt <ch <at> ristopher.com>
> >> Date: Mon, 26 May 2014 16:17:11 -0400 (EDT)
> >> Whenever the faulty behaviour is present, in clear_mouse_face
> >> NILP (hlinfo->mouse_face_window) is always true and therefore the
> >> highlighting is not cleared.
> >
> > Which faulty behavior: the one when there's no highlighting at all, or
> > the one when it's present, but not cleared when the mouse pointer
> > moves off the text?
> 
> The window, in which I moved my mouse pointer around, had working
> highlighting that was not cleared.

OK.

> Most of the time both issues are present.  That is, in one window
> highlighting is present but not cleared whereas in another one there is
> no highlighting at all.

Let me see if I understand this part correctly: when you move the
mouse pointer in one window showing the buffer rms2, the highlighting
is shown, but is never removed when the mouse moves from one line to
another.  When you move the mouse into another window showing the same
rms2 buffer, and let the mouse pointer in that other window hover
above the text with mouse face, the highlighting there is never shown.
Is that correct?

> >> clear_mouse_face w/o bug:
> >
> > "w/o bug" meaning what? a different Emacs version or the same version,
> > but when it behaves correctly?
> 
> That is from the very same process that exposed the issue but then
> recovered somehow.

OK, thanks.

The data you show in the debugger, viz.:

> clear_mouse_face w/ bug:
> 
>     (gdb) p *hlinfo
>      {mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 37,
>       mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0,
>       mouse_face_window = 12026738, mouse_face_face_id = 34, mouse_face_overlay = 12026738,
>       mouse_face_mouse_frame = 0x1129898, mouse_face_mouse_x = -1, mouse_face_mouse_y = -1,
>       mouse_face_past_end = false, mouse_face_defer = false, mouse_face_hidden = false}
>     (gdb) p NILP (hlinfo->mouse_face_window)
>      true

includes peculiar values -1 for both mouse_face_mouse_x and
mouse_face_mouse_y.  AFAICS, there's only one way to get these values:
if clear_mouse_face is called via note_mouse_highlight from this
function in xterm.c:

  static int
  note_mouse_movement (struct frame *frame, const XMotionEvent *event)
  {
    XRectangle *r;
    struct x_display_info *dpyinfo;

    if (!FRAME_X_OUTPUT (frame))
      return 0;

    dpyinfo = FRAME_DISPLAY_INFO (frame);
    dpyinfo->last_mouse_movement_time = event->time;
    dpyinfo->last_mouse_motion_frame = frame;
    dpyinfo->last_mouse_motion_x = event->x;
    dpyinfo->last_mouse_motion_y = event->y;

    if (event->window != FRAME_X_WINDOW (frame))
      {
	frame->mouse_moved = 1;
	dpyinfo->last_mouse_scroll_bar = NULL;
	note_mouse_highlight (frame, -1, -1);  <<<<<<<<<<<<<<<<<<<<<<<<<
	dpyinfo->last_mouse_glyph_frame = NULL;
	return 1;
      }

Can you see if clear_mouse_face is ever called from any other place,
when the highlighting isn't cleared when you move the mouse pointer to
another line of text in the same window?  If there _are_ any other
places from which clear_mouse_face is called, could you please show
the full contents of the hlinfo struct when it arrives in
clear_mouse_face in those other call sequences?

FWIW, the corresponding code on w32 is never executed when I run your
recipe and move inside and between the two windows that display the
rms2 buffer.

Message #50 received at 17588 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christopher Schmidt <ch <at> ristopher.com>, 17588 <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Tue, 27 May 2014 19:09:00 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Let me see if I understand this part correctly: when you move the
> mouse pointer in one window showing the buffer rms2, the highlighting
> is shown, but is never removed when the mouse moves from one line to
> another.  When you move the mouse into another window showing the same
> rms2 buffer, and let the mouse pointer in that other window hover
> above the text with mouse face, the highlighting there is never shown.
> Is that correct?

That's exactly what I see.  Let me add that in the window showing the
rms2 buffer where no mouse face is ever visible (it is the window
showing rms2 that is not the selected window), the text flickers a bit
all the time, in a very high frequency.  It seems to be redrawn all the
time.

Michael.

Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Wed, 28 May 2014 08:27:57 -0400 (EDT)

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

Thanks a lot for your help.

> Can you see if clear_mouse_face is ever called from any other place,
> when the highlighting isn't cleared when you move the mouse pointer to
> another line of text in the same window?  If there _are_ any other
> places from which clear_mouse_face is called, could you please show
> the full contents of the hlinfo struct when it arrives in
> clear_mouse_face in those other call sequences?

[backtrace1 (application/octet-stream, attachment)]

[backtrace2 (application/octet-stream, attachment)]

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Wed, 28 May 2014 21:39:45 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Wed, 28 May 2014 08:27:57 -0400 (EDT)
> 
> (gdb) bt
> #0  clear_mouse_face (hlinfo=hlinfo <at> entry=0x1394780)
>     at xdisp.c:27495
> #1  0x0000000000457fef in note_mouse_highlight (
>     f=f <at> entry=0x1129898, x=494, y=378) at xdisp.c:28812
                           ^^^^^
Does this large value of x make sense?  AFAIU, you are in the lower
window showing the buffer rms2, and you move the mouse above the text
in that window.  The text lines in that buffer are very short, so I
wonder how come you get such a large value of the x coordinate.

> #2  0x00000000004b4b86 in note_mouse_movement (
>     frame=frame <at> entry=0x1129898, 
>     event=event <at> entry=0x7fffffffda70) at xterm.c:3887
> #3  0x00000000004bcb09 in handle_one_xevent (
>     dpyinfo=dpyinfo <at> entry=0x13946e0, 
>     event=event <at> entry=0x7fffffffda70, 
>     finish=finish <at> entry=0xb071e0, hold_quit=0x7fffffffdc90)
>     at xterm.c:6644
> #4  0x00000000004be320 in event_handler_gdk (
>     gxev=0x7fffffffda70, ev=<optimized out>, 
>     data=<optimized out>) at xterm.c:5720
> [...]
> (gdb) bt
> #0  clear_mouse_face (hlinfo=hlinfo <at> entry=0x1394780)
>     at xdisp.c:27495
> #1  0x0000000000457fef in note_mouse_highlight (f=0x1129898, 
>     x=62, y=468) at xdisp.c:28812
> #2  0x00000000004b4af1 in XTframe_up_to_date (f=<optimized out>)
>     at xterm.c:628

OK, so clear_mouse_face calls also come from event_handler_gdk and
from XTframe_up_to_date.

So are you saying that clear_mouse_face is never called with non-nil
hlinfo->mouse_face_window?  IOW, if you put a conditional breakpoint
in clear_mouse_face, like this:

  (gdb) break clear_mouse_face if hlinfo->mouse_face_window != Qnil

then this breakpoint never breaks, is that right?  If so, I'd like to
see which code resets mouse_face_window to nil, after it is set by
show_mouse_face.  (We know that it must be set by show_mouse_face
because you do see the highlighting when the mouse is above text with
mouse-face.)  To this end, set a breakpoint in show_mouse_face, like
this:

  (gdb) break show_mouse_face if draw == DRAW_MOUSE_FACE

When this breaks, put a watchpoint on the mouse_face_window field,
like this:

  (gdb) watch -location hlinfo->mouse_face_window
  (gdb) commands
    > bt
    > continue
    > end
  (gdb)

Then disable or delete the breakpoint in show_mouse_face, and let
Emacs run with the "continue" command.  You should see the watchpoint
trigger when a new line of text is highlighted as result of moving the
mouse, in which case mouse_face_window will get a non-nil value.  And
you should also see the watchpoint trigger in some other place, where
mouse_face_window will be reset to nil (whose value in your case seems
to be 12026738).  This code that resets mouse_face_window to nil is
the one we are looking for.

Another piece of interesting information is whether this code from
note_mouse_highlight:

  /* Which window is that in?  */
  window = window_from_coordinates (f, x, y, &part, 1);

ever returns a value of 'window' that is not nil?  It would be
interesting to see the values of x and y at this point when you move
the mouse from one line of text to another, and
window_from_coordinates returns nil.

Thanks.

Message #59 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Wed, 28 May 2014 16:15:25 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Christopher Schmidt <ch <at> ristopher.com>
>> Date: Wed, 28 May 2014 08:27:57 -0400 (EDT)
>>
>> (gdb) bt
>> #0  clear_mouse_face (hlinfo=hlinfo <at> entry=0x1394780)
>>     at xdisp.c:27495
>> #1  0x0000000000457fef in note_mouse_highlight (
>>     f=f <at> entry=0x1129898, x=494, y=378) at xdisp.c:28812
>                            ^^^^^
> Does this large value of x make sense?  AFAIU, you are in the lower
> window showing the buffer rms2, and you move the mouse above the text
> in that window.  The text lines in that buffer are very short, so I
> wonder how come you get such a large value of the x coordinate.

You've got me there.

This is what I use for testing:

    (run-at-time nil 0.01
                 (lambda ()
                   (with-current-buffer (get-buffer-create "rms")
                     (with-silent-modifications
                       (dotimes (_ 10)
                         (insert (if (= (random 2) 1) "gpl" "fsf") "\n"))
                       (when (> (- (point-max) (point-min)) 100)
                         (delete-region (point-min) (+ (point-min) 100)))))))
    (with-current-buffer (get-buffer-create "rms2")
      (dotimes (i 1000)
        (insert (propertize (format "%3d%3d%3d" i i i)
                            'mouse-face 'highlight)
                "\n")))
    (with-selected-window (split-window-below)
      (with-selected-window (split-window-right)
        (switch-to-buffer "rms2"))
      (switch-to-buffer "rms2"))
    (with-selected-window (split-window-right)
      (switch-to-buffer "rms"))

The snippet is loaded at startup via the --load option.  As startup.el
claims the first window to display the initial buffer, I switched to a
four window setup.

> So are you saying that clear_mouse_face is never called with non-nil
> hlinfo->mouse_face_window?  IOW, if you put a conditional breakpoint
> in clear_mouse_face, like this:
>
>   (gdb) break clear_mouse_face if hlinfo->mouse_face_window != Qnil
>
> then this breakpoint never breaks, is that right?

Yes, it never breaks.

> If so, I'd like to see which code resets mouse_face_window to nil,
> after it is set by show_mouse_face.  (We know that it must be set by
> show_mouse_face because you do see the highlighting when the mouse is
> above text with mouse-face.)  To this end, set a breakpoint in
> show_mouse_face, like this:
>
>   (gdb) break show_mouse_face if draw == DRAW_MOUSE_FACE

The watchpoint is triggered in turns as part of the following two
contexts.  Qnil is 12026738.

    Hardware watchpoint 12: -location hlinfo->mouse_face_window

    Old value = 12026738
    New value = 18193773
    mouse_face_from_buffer_pos (disp_string=12026738, after_string=12026738,
        before_string=12026738, end_charpos=<optimized out>, start_charpos=6711,
        mouse_charpos=6717, hlinfo=<optimized out>, window=18193773) at xdisp.c:28062
    28062                                       !hlinfo->mouse_face_hidden, -1);
    #0  mouse_face_from_buffer_pos (disp_string=12026738, after_string=12026738,
        before_string=12026738, end_charpos=<optimized out>, start_charpos=6711,
        mouse_charpos=6717, hlinfo=<optimized out>, window=18193773) at xdisp.c:28062
    #1  note_mouse_highlight (f=f <at> entry=0x1129898, x=<optimized out>,
        y=<optimized out>) at xdisp.c:29151
    #2  0x00000000004b4b86 in note_mouse_movement (frame=frame <at> entry=0x1129898,
        event=event <at> entry=0x7fffffffdc80) at xterm.c:3887
    #3  0x00000000004bcb09 in handle_one_xevent (dpyinfo=dpyinfo <at> entry=0x1396000,
        event=event <at> entry=0x7fffffffdc80, finish=finish <at> entry=0xb071e0,
        hold_quit=0x7fffffffdea0) at xterm.c:6644
    #4  0x00000000004be320 in event_handler_gdk (gxev=0x7fffffffdc80,
        ev=<optimized out>, data=<optimized out>) at xterm.c:5720
    #5  0x00007ffff65cca2a in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
    #6  0x00007ffff65ce6f6 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
    #7  0x00007ffff65ce77e in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
    #8  0x00007ffff4a89355 in g_main_context_dispatch ()
       from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    #9  0x00007ffff4a89688 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    #10 0x00007ffff4a89744 in g_main_context_iteration ()
       from /lib/x86_64-linux-gnu/libglib-2.0.so.0
    #11 0x00007ffff69609a1 in gtk_main_iteration ()
       from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
    #12 0x00000000004b6d82 in XTread_socket (terminal=<optimized out>,
        hold_quit=0x7fffffffdea0) at xterm.c:7013
    #13 0x00000000004e8be1 in gobble_input () at keyboard.c:6849
    #14 0x00000000004e8605 in handle_async_input () at keyboard.c:7089
    #15 process_pending_signals () at keyboard.c:7103
    #16 0x0000000000590e6e in wait_reading_process_output (
        time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0,
        read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true,
        wait_for_cell=12026738, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
        at process.c:4340
    #17 0x000000000041f363 in sit_for (timeout=<optimized out>,
        reading=reading <at> entry=true, display_option=display_option <at> entry=1)
        at dispnew.c:5805
    #18 0x00000000004eca63 in read_char (commandflag=1, map=map <at> entry=19249734,
        prev_event=12026738, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffe58b,
        end_time=end_time <at> entry=0x0) at keyboard.c:2809
    #19 0x00000000004edc75 in read_key_sequence (keybuf=keybuf <at> entry=0x7fffffffe660,
        prompt=12026738, dont_downcase_last=dont_downcase_last <at> entry=false,
        can_return_switch_frame=can_return_switch_frame <at> entry=true,
        fix_current_buffer=fix_current_buffer <at> entry=true,
        prevent_redisplay=prevent_redisplay <at> entry=false, bufsize=30) at keyboard.c:9087
    #20 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452
    #21 0x0000000000550977 in internal_condition_case (
        bfun=bfun <at> entry=0x4ef760 <command_loop_1>, handlers=<optimized out>,
        hfun=hfun <at> entry=0x4e6bf0 <cmd_error>) at eval.c:1354
    #22 0x00000000004e234e in command_loop_2 (ignore=ignore <at> entry=12026738)
        at keyboard.c:1177
    #23 0x000000000055085b in internal_catch (tag=12073890,
        func=func <at> entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118
    #24 0x00000000004e6807 in command_loop () at keyboard.c:1156
    #25 recursive_edit_1 () at keyboard.c:777
    #26 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848
    #27 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at
    emacs.c:1646


    Hardware watchpoint 12: -location hlinfo->mouse_face_window

    Old value = 18193773
    New value = 12026738
    reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
    2725            hlinfo->mouse_face_overlay = Qnil;
    #0  reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
    #1  x_update_window_end (w=0x1139998, cursor_on_p=<optimized out>,
        mouse_face_overwritten_p=<optimized out>) at xterm.c:600
    #2  0x000000000041b17d in update_window (w=w <at> entry=0x1139998,
        force_p=<optimized out>, force_p <at> entry=true) at dispnew.c:3486
    #3  0x000000000041c3fb in update_window_tree (w=0x1139998,
        force_p=force_p <at> entry=true) at dispnew.c:3161
    #4  0x000000000041c3ee in update_window_tree (w=0x1144a48,
        force_p=force_p <at> entry=true) at dispnew.c:3159
    #5  0x000000000041c3ee in update_window_tree (w=w <at> entry=0x1148c60,
        force_p=force_p <at> entry=true) at dispnew.c:3159
    #6  0x000000000041e59d in update_frame (f=0x1129898, force_p=<optimized out>,
        inhibit_hairy_id_p=<optimized out>) at dispnew.c:3059
    #7  0x000000000044c0df in redisplay_internal () at xdisp.c:13844
    #8  0x000000000044e0d0 in redisplay_preserve_echo_area (
        from_where=from_where <at> entry=9) at xdisp.c:14058
    #9  0x00000000005902a8 in wait_reading_process_output (
        time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0,
        read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true,
        wait_for_cell=12026738, wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0)
        at process.c:4398
    #10 0x000000000041f363 in sit_for (timeout=<optimized out>,
        reading=reading <at> entry=true, display_option=display_option <at> entry=1)
        at dispnew.c:5805
    #11 0x00000000004eca63 in read_char (commandflag=1, map=map <at> entry=19249734,
        prev_event=12026738, used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffe58b,
        end_time=end_time <at> entry=0x0) at keyboard.c:2809
    #12 0x00000000004edc75 in read_key_sequence (keybuf=keybuf <at> entry=0x7fffffffe660,
        prompt=12026738, dont_downcase_last=dont_downcase_last <at> entry=false,
        can_return_switch_frame=can_return_switch_frame <at> entry=true,
        fix_current_buffer=fix_current_buffer <at> entry=true,
        prevent_redisplay=prevent_redisplay <at> entry=false, bufsize=30) at keyboard.c:9087
    #13 0x00000000004ef950 in command_loop_1 () at keyboard.c:1452
    #14 0x0000000000550977 in internal_condition_case (
        bfun=bfun <at> entry=0x4ef760 <command_loop_1>, handlers=<optimized out>,
        hfun=hfun <at> entry=0x4e6bf0 <cmd_error>) at eval.c:1354
    #15 0x00000000004e234e in command_loop_2 (ignore=ignore <at> entry=12026738)
        at keyboard.c:1177
    #16 0x000000000055085b in internal_catch (tag=12073890,
        func=func <at> entry=0x4e2330 <command_loop_2>, arg=12026738) at eval.c:1118
    #17 0x00000000004e6807 in command_loop () at keyboard.c:1156
    #18 recursive_edit_1 () at keyboard.c:777
    #19 0x00000000004e6b20 in Frecursive_edit () at keyboard.c:848
    #20 0x0000000000415ab9 in main (argc=0, argv=0x7fffffffe9a8) at emacs.c:1646

Message #62 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Thu, 29 May 2014 18:56:49 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Wed, 28 May 2014 16:15:25 -0400 (EDT)
> 
> > So are you saying that clear_mouse_face is never called with non-nil
> > hlinfo->mouse_face_window?  IOW, if you put a conditional breakpoint
> > in clear_mouse_face, like this:
> >
> >   (gdb) break clear_mouse_face if hlinfo->mouse_face_window != Qnil
> >
> > then this breakpoint never breaks, is that right?
> 
> Yes, it never breaks.
> 
> > If so, I'd like to see which code resets mouse_face_window to nil,
> > after it is set by show_mouse_face.  (We know that it must be set by
> > show_mouse_face because you do see the highlighting when the mouse is
> > above text with mouse-face.)  To this end, set a breakpoint in
> > show_mouse_face, like this:
> >
> >   (gdb) break show_mouse_face if draw == DRAW_MOUSE_FACE
> 
> The watchpoint is triggered in turns as part of the following two
> contexts.  Qnil is 12026738.
> 
>     Hardware watchpoint 12: -location hlinfo->mouse_face_window
> 
>     Old value = 12026738
>     New value = 18193773
>     mouse_face_from_buffer_pos (disp_string=12026738, after_string=12026738,
>         before_string=12026738, end_charpos=<optimized out>, start_charpos=6711,
>         mouse_charpos=6717, hlinfo=<optimized out>, window=18193773) at xdisp.c:28062
>     28062                                       !hlinfo->mouse_face_hidden, -1);

This is where the mouse highlight is turned on.

>     Hardware watchpoint 12: -location hlinfo->mouse_face_window
> 
>     Old value = 18193773
>     New value = 12026738
>     reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
>     2725            hlinfo->mouse_face_overlay = Qnil;
>     #0  reset_mouse_highlight (hlinfo=0x13960a0) at dispextern.h:2725
>     #1  x_update_window_end (w=0x1139998, cursor_on_p=<optimized out>,
>         mouse_face_overwritten_p=<optimized out>) at xterm.c:600
>     #2  0x000000000041b17d in update_window (w=w <at> entry=0x1139998,
>         force_p=<optimized out>, force_p <at> entry=true) at dispnew.c:3486

And this seems to be our villain.  Does the patch below help?

=== modified file 'src/xterm.c'
--- src/xterm.c	2014-04-17 09:07:58 +0000
+++ src/xterm.c	2014-05-29 15:54:27 +0000
@@ -597,7 +597,13 @@ x_update_window_end (struct window *w, b
   /* If a row with mouse-face was overwritten, arrange for
      XTframe_up_to_date to redisplay the mouse highlight.  */
   if (mouse_face_overwritten_p)
-    reset_mouse_highlight (MOUSE_HL_INFO (XFRAME (w->frame)));
+    {
+      Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (XFRAME (w->frame));
+
+      hlinfo->mouse_face_beg_row = hlinfo->mouse_face_beg_col = -1;
+      hlinfo->mouse_face_end_row = hlinfo->mouse_face_end_col = -1;
+      hlinfo->mouse_face_window = Qnil;
+    }
 }
 
 

Message #65 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Schmidt <ch <at> ristopher.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Thu, 29 May 2014 12:14:52 -0400 (EDT)

Eli Zaretskii <eliz <at> gnu.org> writes:
> And this seems to be our villain.  Does the patch below help?

Yes, it fixes the problem.

Thank you very much for your work, Eli.

Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christopher Schmidt <ch <at> ristopher.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Thu, 29 May 2014 19:49:56 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Thu, 29 May 2014 12:14:52 -0400 (EDT)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > And this seems to be our villain.  Does the patch below help?
> 
> Yes, it fixes the problem.

Great, committed to emacs-24 branch as revision 117171.

> Thank you very much for your work, Eli.

Thanks for your great help.

Message #73 received at 17588-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: 17588-done <at> debbugs.gnu.org
Subject: Re: bug#17588: 24.3.91; mouse-face glitchy
Date: Thu, 29 May 2014 19:51:35 +0300

> From: Christopher Schmidt <ch <at> ristopher.com>
> Date: Thu, 29 May 2014 12:14:52 -0400 (EDT)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > And this seems to be our villain.  Does the patch below help?
> 
> Yes, it fixes the problem.

Great, committed to emacs-24 branch as revision 117171.

> Thank you very much for your work, Eli.

Thanks for your great help.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.