Bug in incremental undrawing of mouseover highlighting

Bug in incremental undrawing of mouseover highlighting

[Bob Rogers]

   It seems that mouseover background highlighting is not undrawn if
replaced by the same unhighlighted text.  This happens in the CVS
version as of late on 11-Nov.  (I have seen this bug for some time now,
but only just thought of a (relatively) easy way to reproduce it.)

   To reproduce:

   1.  "emacs -Q"

   2.  "C-x d RET".  This gets a dired buffer; the exact directory
doesn't matter as long as it has at least a few files in it.  (And, for
some reason, "." and ".." don't count.)

   3.  "C-x h M-w C-x b *scratch* RET C-y M-<".  This gets a copy of the
dired buffer contents; sometimes they come with dired fontification, and
sometimes not.  The same text should be displayed in the same character
positions in both dired and *scratch* buffers.

   4.  "C-x b RET" to get back to the dired buffer, and move the mouse
over a file name so that it is highlighted in green.

   5.  "C-x b RET" to return to *scratch*.  Notice that the same
characters in the same position are still highlighted in green.

   6.  Move the mouse to a different file name.  Usually the
highlighting goes away, but sometimes it doesn't (and it doesn't
correlate with fontification).  If it does persist, type "C-x b RET" to
return once more to the dired buffer, and there will be two green file
names -- this can be repeated until every file name is green.

   7.  "C-l" (or anything else that causes redisplay from scratch) will
restore the display to normal; this is why I think it's a redisplay bug.

   My apologies if this is a known problem; I find it hard to follow the
redisplay threads, so I may have missed the relevant description.

					-- Bob Rogers
					   http://rgrjr.dyndns.org/

Re: Bug in incremental undrawing of mouseover highlighting

[David Kastrup]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

>    It seems that mouseover background highlighting is not undrawn if
> replaced by the same unhighlighted text.  This happens in the CVS
> version as of late on 11-Nov.  (I have seen this bug for some time now,
> but only just thought of a (relatively) easy way to reproduce it.)
>
>    To reproduce:
>
>    1.  "emacs -Q"
>
>    2.  "C-x d RET".  This gets a dired buffer; the exact directory
> doesn't matter as long as it has at least a few files in it.  (And, for
> some reason, "." and ".." don't count.)
>
>    3.  "C-x h M-w C-x b *scratch* RET C-y M-<".  This gets a copy of the
> dired buffer contents; sometimes they come with dired fontification, and
> sometimes not.  The same text should be displayed in the same character
> positions in both dired and *scratch* buffers.
>
>    4.  "C-x b RET" to get back to the dired buffer, and move the mouse
> over a file name so that it is highlighted in green.
>
>    5.  "C-x b RET" to return to *scratch*.  Notice that the same
> characters in the same position are still highlighted in green.
>
>    6.  Move the mouse to a different file name.  Usually the
> highlighting goes away, but sometimes it doesn't (and it doesn't
> correlate with fontification).  If it does persist, type "C-x b RET" to
> return once more to the dired buffer, and there will be two green file
> names -- this can be repeated until every file name is green.

For people wanting to debug this: I have the slight suspicion that the
problem is masked usually because some well-meaning workaround
suppresses the highlighting of partial lines that _should_ be
highlighted when a buffer pops up under the mouse cursor.  Often the
highlighting only starts once one moves the mouse cursor.  And I think
that the problem might be triggered when only parts of the line are
to be highlighted.

I have no recipe for reproduction now, this is rather irregular and
tends to occur in the newsreader for me, which means that there is no
repeatable recipe.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Bug in incremental undrawing of mouseover highlighting

[Bob Rogers]

   From: David Kastrup <dak@gnu.org>
   Date: Sun, 19 Nov 2006 23:50:32 +0100

   Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

   >    It seems that mouseover background highlighting is not undrawn if
   > replaced by the same unhighlighted text.  This happens in the CVS
   > version as of late on 11-Nov.  (I have seen this bug for some time now,
   > but only just thought of a (relatively) easy way to reproduce it.)
   >
   >    To reproduce:
   >
   >    1.  "emacs -Q"
   >
   >    2.  "C-x d RET".  This gets a dired buffer; the exact directory
   > doesn't matter as long as it has at least a few files in it.  (And, for
   > some reason, "." and ".." don't count.)
   >
   >    3.  "C-x h M-w C-x b *scratch* RET C-y M-<".  This gets a copy of the
   > dired buffer contents; sometimes they come with dired fontification, and
   > sometimes not.  The same text should be displayed in the same character
   > positions in both dired and *scratch* buffers.
   >
   >    4.  "C-x b RET" to get back to the dired buffer, and move the mouse
   > over a file name so that it is highlighted in green.
   >
   >    5.  "C-x b RET" to return to *scratch*.  Notice that the same
   > characters in the same position are still highlighted in green.
   >
   >    6.  Move the mouse to a different file name.  Usually the
   > highlighting goes away, but sometimes it doesn't (and it doesn't
   > correlate with fontification).  If it does persist, type "C-x b RET" to
   > return once more to the dired buffer, and there will be two green file
   > names -- this can be repeated until every file name is green.

   For people wanting to debug this: I have the slight suspicion that the
   problem is masked usually because some well-meaning workaround
   suppresses the highlighting of partial lines that _should_ be
   highlighted when a buffer pops up under the mouse cursor.  Often the
   highlighting only starts once one moves the mouse cursor.  And I think
   that the problem might be triggered when only parts of the line are
   to be highlighted.

   I have no recipe for reproduction now, this is rather irregular and
   tends to occur in the newsreader for me, which means that there is no
   repeatable recipe.

   -- 
   David Kastrup, Kriemhildstr. 15, 44793 Bochum

Indeed; I first noticed this in vm-summary-mode, where each line
represents a message.  But there the whole line is highlighted.  When I
switch from the VM summary buffer to a buffer that matches the same line
in its entirety, all mouseover highlighting is preserved; when I switch
to a buffer that matches it partially, highlighting is correctly cleared
only for those positions that must be changed to display different
characters.

					-- Bob

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

GNU Emacs 22.0.91.2 (i686-pc-linux-gnu, GTK+ Version 2.8.10) of
2006-12-07 on escher

I experience this bug fairly often in relatively mild form which is
annoying but not unbearable.  But I've just run across a severe case
of presumably the same bug.  It occurred while reading
gnu-emacs-source from Gmane with Gnus.  The article that shows the
problem is at <http://permalink.gmane.org/gmane.emacs.sources/1977>,
and here's how to reproduce it:

1. emacs -Q
2. M-: (setq gnus-select-method '(nntp "news.gmane.org")) RET
3. M-x gnus RET
4. S s gmane.emacs.sources
5. RET
6. C-s M-e [ 187: Alf-Ivar Holm RET C-f RET, i.e., go to this article
and open it.
7. In the *Article* buffer, click on the MIME part header
[2. Displaying ISO week in calendar, updated for emacs 22, 2nd try ---
application/emacs-lisp; calendar-hack.el].  You'll see that the entire
text of the attachment has mouse-face highlighting, and if you scroll
over this part the incremental undrawing bug is apparent en masse.
Now click the MIME part header again to close it, and either the
entire header or the second line of will be double.  Further clicking
to open and close the MIME part increases the number of (parts of)
headers displayed.

Steve Berman

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

Stephen Berman <Stephen.Berman@gmx.net> writes:

Stephen Berman <Stephen.Berman@gmx.net> writes:

> GNU Emacs 22.0.91.2 (i686-pc-linux-gnu, GTK+ Version 2.8.10) of
> 2006-12-07 on escher
>
> I experience this bug fairly often in relatively mild form which is
> annoying but not unbearable.  But I've just run across a severe case
> of presumably the same bug.  It occurred while reading
> gnu-emacs-source from Gmane with Gnus.  The article that shows the
> problem is at <http://permalink.gmane.org/gmane.emacs.sources/1977>,

This bug was fixed in CVS about a week ago (using CVS, I can't
reproduce it from the recipe you provided, either.)

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

On Wed, 13 Dec 2006 11:04:42 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

> This bug was fixed in CVS about a week ago (using CVS, I can't
> reproduce it from the recipe you provided, either.)

I just now updated from CVS, did 
  $ ./configure --with-x-toolkit=gtk
  $ make
  $ cd lisp
  $ make recompile EMACS=../src/emacs
  $ cd ..
  $ make
and then the recipe I gave, and I still see just what I described.  Do
you think I need to bootstrap, or is there some difference between our
configurations that explains why you don't see it?  Does anyone else
see it?

Steve Berman

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

On Thu, 14 Dec 2006 10:22:24 +0100 Stephen Berman <Stephen.Berman@gmx.net> wrote:

> On Wed, 13 Dec 2006 11:04:42 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> This bug was fixed in CVS about a week ago (using CVS, I can't
>> reproduce it from the recipe you provided, either.)
>
> I just now updated from CVS, did 
>   $ ./configure --with-x-toolkit=gtk
>   $ make
>   $ cd lisp
>   $ make recompile EMACS=../src/emacs
>   $ cd ..
>   $ make
> and then the recipe I gave, and I still see just what I described.  Do
> you think I need to bootstrap, or is there some difference between our
> configurations that explains why you don't see it?  Does anyone else
> see it?

Well, I just updated from CVS again, did 
  $ ./configure --with-x-toolkit=gtk
  $ make bootstrap
and then the recipe I gave, and I *still* see just what I described.
Does nobody else see this?

Steve Berman

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sun, 19 Nov 2006 23:50:32 +0100
> Cc: emacs-devel@gnu.org
> 
> I have no recipe for reproduction now, this is rather irregular and
> tends to occur in the newsreader for me, which means that there is no
> repeatable recipe.

I have no difficulty whatsoever reproducing this in "emacs -Q".  Just
try the recipe posted by the OP.

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

>    It seems that mouseover background highlighting is not undrawn if
> replaced by the same unhighlighted text.  This happens in the CVS
> version as of late on 11-Nov.

The problem occurs because note_mouse_highlight checks only the window
and glyph positions to see if it needs to maintain the mouse
highlight.  The relevant code is in xdisp.c:22819:

      same_region = (EQ (window, dpyinfo->mouse_face_window)
		     && vpos >= dpyinfo->mouse_face_beg_row
		     && vpos <= dpyinfo->mouse_face_end_row
		     && (vpos > dpyinfo->mouse_face_beg_row
			 || hpos >= dpyinfo->mouse_face_beg_col)
		     && (vpos < dpyinfo->mouse_face_end_row
			 || hpos < dpyinfo->mouse_face_end_col
			 || dpyinfo->mouse_face_past_end));

As far as I can tell, the simplest fix is to tell set_window_buffer to
reset the mouse face if the mouse face used to be associated with that
window.  The patch below implements this.

*** emacs/src/window.c.~1.564.~	2006-10-30 09:06:42.000000000 -0500
--- emacs/src/window.c	2006-11-20 14:13:08.000000000 -0500
***************
*** 3265,3270 ****
--- 3265,3275 ----
    struct window *w = XWINDOW (window);
    struct buffer *b = XBUFFER (buffer);
    int count = SPECPDL_INDEX ();
+ #ifdef HAVE_WINDOW_SYSTEM
+   struct frame *f = XFRAME (w->frame);
+   Display_Info *dpyinfo = (f && FRAME_X_OUTPUT (f)) ?
+     FRAME_X_DISPLAY_INFO (f) : NULL;
+ #endif
  
    w->buffer = buffer;
  
***************
*** 3345,3350 ****
--- 3350,3360 ----
  	call1 (Vrun_hooks, Qwindow_configuration_change_hook);
      }
  
+ #ifdef HAVE_WINDOW_SYSTEM
+   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
+     clear_mouse_face (dpyinfo);
+ #endif
+ 
    unbind_to (count, Qnil);
  }

misleading install instruction in emacs/mac/INSTALL

[Gilbert Harman]

On a new intel iMac running Mac OS system 10.4.8, from the files in the new
pretest tarball:

In seeming accordance with the instructions in emacs/mac/INSTALL,
I ran:

./configure --with-x --enable-carbon-app
make
sudo make install

This produced a version that appears to run OK in the Mac window system but
/usr/local/bin/emacs did not run in X windows.  Apparently it is necessary
to do two installations, one using

./configure --enable-carbon-app

the other using

./configure --with-X --without-carbon-app

  Gil

Re: misleading install instruction in emacs/mac/INSTALL

[Richard Stallman]

    This produced a version that appears to run OK in the Mac window system but
    /usr/local/bin/emacs did not run in X windows.  Apparently it is necessary
    to do two installations, one using

Would someone please clarify the instructions?

Re: misleading install instruction in emacs/mac/INSTALL

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 21 Nov 2006 02:47:56 -0500, Richard Stallman <rms@gnu.org> said:

>     This produced a version that appears to run OK in the Mac window
> system but /usr/local/bin/emacs did not run in X windows.
> Apparently it is necessary to do two installations, one using

> Would someone please clarify the instructions?

Does the following change make things clear?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: mac/INSTALL
===================================================================
RCS file: /cvsroot/emacs/emacs/mac/INSTALL,v
retrieving revision 1.27
diff -c -r1.27 INSTALL
*** mac/INSTALL	8 Nov 2006 08:03:21 -0000	1.27
--- mac/INSTALL	22 Nov 2006 08:19:14 -0000
***************
*** 43,65 ****
  -k' instead of `make' and safely ignore the error messages and use the
  existing info files.
  
! After Emacs is installed, you can run it by typing `emacs -nw' from a
! terminal (make sure your path contains /usr/local/bin) or by
! double-clicking on /Applications/Emacs.app in the Finder.  To start
! Emacs as a GUI application from the terminal, the pathname to the
! executable in the bundle, i.e.,
  
    /Application/Emacs.app/Contents/MacOS/Emacs
  
  must be typed to the shell to enable Emacs to locate its resources
! correctly.  You may want to create a symlink or alias to this path to
! quickly access both the terminal and GUI versions.
! 
! If you are building Emacs to run on Mac OS X and X Window System,
! instead of typing `./configure' above, type
  
    ./configure --with-x
  
  
  To use colors in a terminal, put the following lines in the file
  ~/.termcap and log in again.
--- 43,73 ----
  -k' instead of `make' and safely ignore the error messages and use the
  existing info files.
  
! After Emacs is installed, you can run a text-only terminal version by
! typing `emacs' from a terminal (make sure your path contains
! /usr/local/bin) or a GUI application by double-clicking on
! /Applications/Emacs.app in the Finder.  Even in the text-only terminal
! version, some Carbon-specific functions such as `mac-set-file-creator'
! are meaningful.
! 
! To start Emacs as a GUI application from the terminal, the pathname to
! the executable in the bundle, i.e.,
  
    /Application/Emacs.app/Contents/MacOS/Emacs
  
  must be typed to the shell to enable Emacs to locate its resources
! correctly.  You may want to create an alias to this path to quickly
! access both the terminal and GUI versions.  You can optionally specify
! some standard Emacs options when invoking Emacs in this way.
! 
! Emacs on Mac OS X is not configured to use X11 unless either it is
! requested or the use of Carbon is disabled explicitly.  So, if you are
! building Emacs to run on X Window System, you need to specify like:
  
    ./configure --with-x
  
+ Note that Carbon-specific functions mentioned above are not available
+ on the X11-enabled build.
  
  To use colors in a terminal, put the following lines in the file
  ~/.termcap and log in again.

Re: misleading install instruction in emacs/mac/INSTALL

[Gilbert Harman]

Yes, that is better.

 Gil


YAMAMOTO Mitsuharu wrote:

>>>>>> On Tue, 21 Nov 2006 02:47:56 -0500, Richard Stallman <rms@gnu.org> said:
> 
>>     This produced a version that appears to run OK in the Mac window
>> system but /usr/local/bin/emacs did not run in X windows.
>> Apparently it is necessary to do two installations, one using
> 
>> Would someone please clarify the instructions?
> 
> Does the following change make things clear?
> 
>     YAMAMOTO Mitsuharu
> mituharu@math.s.chiba-u.ac.jp
> ....

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 20 Nov 2006 14:22:47 -0500
> Cc: emacs-devel@gnu.org
> 
> *** emacs/src/window.c.~1.564.~	2006-10-30 09:06:42.000000000 -0500
> --- emacs/src/window.c	2006-11-20 14:13:08.000000000 -0500
> ***************
> *** 3265,3270 ****
> --- 3265,3275 ----
>     struct window *w = XWINDOW (window);
>     struct buffer *b = XBUFFER (buffer);
>     int count = SPECPDL_INDEX ();
> + #ifdef HAVE_WINDOW_SYSTEM
> +   struct frame *f = XFRAME (w->frame);
> +   Display_Info *dpyinfo = (f && FRAME_X_OUTPUT (f)) ?
> +     FRAME_X_DISPLAY_INFO (f) : NULL;
> + #endif
>   
>     w->buffer = buffer;
>   
> ***************
> *** 3345,3350 ****
> --- 3350,3360 ----
>   	call1 (Vrun_hooks, Qwindow_configuration_change_hook);
>       }
>   
> + #ifdef HAVE_WINDOW_SYSTEM
> +   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
> +     clear_mouse_face (dpyinfo);
> + #endif
> + 
>     unbind_to (count, Qnil);
>   }

Are these #ifdef's really right?  The mouse highlight is supported not
only in builds that define HAVE_WINDOW_SYSTEM.

Re: Bug in incremental undrawing of mouseover highlighting

[Bob Rogers]

   From: Chong Yidong <cyd@stupidchicken.com>
   Date: Mon, 20 Nov 2006 14:22:47 -0500

   Bob Rogers <rogers-emacs@rgrjr.dyndns.org> writes:

   >    It seems that mouseover background highlighting is not undrawn if
   > replaced by the same unhighlighted text.  This happens in the CVS
   > version as of late on 11-Nov.

   The problem occurs because note_mouse_highlight checks only the window
   and glyph positions to see if it needs to maintain the mouse
   highlight . . .

   As far as I can tell, the simplest fix is to tell set_window_buffer to
   reset the mouse face if the mouse face used to be associated with that
   window.  The patch below implements this.

It works for me; thanks!

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Mon, 20 Nov 2006 22:36:22 +0200

   Are these #ifdef's really right?  The mouse highlight is supported not
   only in builds that define HAVE_WINDOW_SYSTEM.

How would I test this?  Mouse highlighting doesn't seem to work in
either xterm or the KDE "Konsole" (with the "-nw" switch, of course).
Or would I have to disable HAVE_WINDOW_SYSTEM first?

					-- Bob

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> Date: Tue, 21 Nov 2006 23:06:27 -0500
> From: Bob Rogers <rogers-emacs@rgrjr.dyndns.org>
> CC: emacs-devel@gnu.org
> 
>    From: Eli Zaretskii <eliz@gnu.org>
>    Date: Mon, 20 Nov 2006 22:36:22 +0200
> 
>    Are these #ifdef's really right?  The mouse highlight is supported not
>    only in builds that define HAVE_WINDOW_SYSTEM.
> 
> How would I test this?  Mouse highlighting doesn't seem to work in
> either xterm or the KDE "Konsole" (with the "-nw" switch, of course).
> Or would I have to disable HAVE_WINDOW_SYSTEM first?

You cannot test that on GNU/Linux systems, since there only graphics
displays support mouse highlight for now.

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> + #ifdef HAVE_WINDOW_SYSTEM
>> +   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
>> +     clear_mouse_face (dpyinfo);
>> + #endif
>> + 
>
> Are these #ifdef's really right?  The mouse highlight is supported not
> only in builds that define HAVE_WINDOW_SYSTEM.

note_mouse_highlight is only defined inside HAVE_WINDOW_SYSTEM.

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> Cc: rogers-emacs@rgrjr.dyndns.org,  emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Wed, 22 Nov 2006 10:07:55 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> + #ifdef HAVE_WINDOW_SYSTEM
> >> +   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
> >> +     clear_mouse_face (dpyinfo);
> >> + #endif
> >> + 
> >
> > Are these #ifdef's really right?  The mouse highlight is supported not
> > only in builds that define HAVE_WINDOW_SYSTEM.
> 
> note_mouse_highlight is only defined inside HAVE_WINDOW_SYSTEM.

That's true, but you weren't modifying note_mouse_highlight, you
referenced dpyinfo->mouse_face_window.  You will see that at least
src/msdos.c manipulates dpyinfo->mouse_face_window.  The MSDOS build
supports mouse highlight, but does not define HAVE_WINDOW_SYSTEM, and
set_window_buffer, where you suggested to make the change, is compiled
into the MSDOS port.

Re: Bug in incremental undrawing of mouseover highlighting

[Nick Roberts]

 > > > Are these #ifdef's really right?  The mouse highlight is supported not
 > > > only in builds that define HAVE_WINDOW_SYSTEM.
 > > 
 > > note_mouse_highlight is only defined inside HAVE_WINDOW_SYSTEM.
 > 
 > That's true, but you weren't modifying note_mouse_highlight, you
 > referenced dpyinfo->mouse_face_window.  You will see that at least
 > src/msdos.c manipulates dpyinfo->mouse_face_window.  The MSDOS build
 > supports mouse highlight, but does not define HAVE_WINDOW_SYSTEM, and
 > set_window_buffer, where you suggested to make the change, is compiled
 > into the MSDOS port.

Does MSDOS know where the mouse is?  Or is it like a text terminal on Unix?  If
it's the latter then I don't see why the MSDOS build should support mouse
highlight at all.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 23 Nov 2006 12:57:06 +1300
> Cc: Chong Yidong <cyd@stupidchicken.com>,
> 	rogers-emacs@rgrjr.dyndns.org, emacs-devel@gnu.org
> 
> Does MSDOS know where the mouse is?

Of course, it does.  Witness the various mouse_* functions on msdos.c.

It also supports drop-down and pop-up menus.

> Or is it like a text terminal on Unix?

It's actually the other way around: the Unix text terminal support for
faces in Emacs is modeled after the MSDOS port, which was the first
one to support colors on an otherwise text-mode display.

Re: Bug in incremental undrawing of mouseover highlighting

[Nick Roberts]

Eli Zaretskii writes:
 > > From: Nick Roberts <nickrob@snap.net.nz>
 > > Date: Thu, 23 Nov 2006 12:57:06 +1300
 > > Cc: Chong Yidong <cyd@stupidchicken.com>,
 > > 	rogers-emacs@rgrjr.dyndns.org, emacs-devel@gnu.org
 > > 
 > > Does MSDOS know where the mouse is?
 > 
 > Of course, it does.  Witness the various mouse_* functions on msdos.c.

There's no of course about it and the functions in msdos.c might just be
for mouse click events.

 > It also supports drop-down and pop-up menus.

Yes but for mouse highlighting, specifically, MSDOS has to know where the mouse
is _in between_ click events.  Does it? (AFAIK this is why highlighting won't
work on an xterm although you can certainly click on mouse sensitive parts of
the screen using xt-mouse.el).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Thu, 23 Nov 2006 17:50:39 +1300
> Cc: cyd@stupidchicken.com, emacs-devel@gnu.org
>  > > 
>  > > Does MSDOS know where the mouse is?
>  > 
>  > Of course, it does.  Witness the various mouse_* functions on msdos.c.
> 
> There's no of course about it and the functions in msdos.c might just be
> for mouse click events.

Nick, I know you can read C code, that's why I said what I said; sorry
if it sounded argumentative or offensive, but msdos.c does include
functions like `mouse_moveto(x,y)', `mouse_check_moved()', etc.  And
if you search for "highlight", you will find a full-blown support for
mouse highlight.

> Yes but for mouse highlighting, specifically, MSDOS has to know where the mouse
> is _in between_ click events.  Does it?

Yes, it does.

Re: Bug in incremental undrawing of mouseover highlighting

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 20 Nov 2006 14:22:47 -0500, Chong Yidong <cyd@stupidchicken.com> said:

> + #ifdef HAVE_WINDOW_SYSTEM
> +   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
> +     clear_mouse_face (dpyinfo);
> + #endif
> + 
>     unbind_to (count, Qnil);
>   }

This clear_mouse_face call is not protected by BLOCK_INPUT.  Is it OK
to refer to dpyinfo in window.c in the first place?  Such tasks seem
to be done in xdisp.c usually.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>>>>>> On Mon, 20 Nov 2006 14:22:47 -0500, Chong Yidong <cyd@stupidchicken.com> said:
>
>> + #ifdef HAVE_WINDOW_SYSTEM
>> +   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
>> +     clear_mouse_face (dpyinfo);
>> + #endif
>> + 
>>     unbind_to (count, Qnil);
>>   }
>
> This clear_mouse_face call is not protected by BLOCK_INPUT.

Thanks, fixed.

> Is it OK to refer to dpyinfo in window.c in the first place?  Such
> tasks seem to be done in xdisp.c usually.

It is used in frame.c and several other files.  I couldn't find any
cleaner non-invasive solution.

Re: Bug in incremental undrawing of mouseover highlighting

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 24 Nov 2006 23:18:51 -0500, Chong Yidong <cyd@stupidchicken.com> said:

>> Is it OK to refer to dpyinfo in window.c in the first place?  Such
>> tasks seem to be done in xdisp.c usually.

> It is used in frame.c and several other files.

Multiple places in these files.  But no place other than your change
in window.c.

> I couldn't find any cleaner non-invasive solution.

I'm not a redisplay expert, but I suspect whether this is a right fix.
I think the usual way is to set some flag in set_window_buffer, and
let some redisplay routine check the flag.  Also, I think this is a
bad timing to commit such a change for a non-critical bug without
approval by some expert.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> Date: Sat, 25 Nov 2006 16:28:04 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Bob Rogers <rogers-emacs@rgrjr.dyndns.org>, emacs-devel@gnu.org
> 
> Also, I think this is a bad timing to commit such a change for a
> non-critical bug without approval by some expert.

I don't consider myself much of a redisplay expert, but I did express
a (different) concern for the patch as posted, a concern that
seemingly had no effect whatsoever.

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

>> Also, I think this is a bad timing to commit such a change for a
>> non-critical bug without approval by some expert.

If anyone has a suggestion for a cleaner non-invasive change, it would
be welcome.  I'm also agreeable to postphoning this bugfix till after
the release, if it is considered unsafe.

> I don't consider myself much of a redisplay expert, but I did express
> a (different) concern for the patch as posted, a concern that
> seemingly had no effect whatsoever.

It's still unclear, from the messages you sent, whether this bug can
happen outside of HAVE_WINDOW_SYSTEM.  The bugfix is meant to plug a
loophole in the code in note_mouse_highlight that computes whether or
not the mouse highlight has been updated, which is only present for
HAVE_WINDOW_SYSTEM.  (It is possible to change note_mouse_highlight
itself, e.g. by introducing dpyinfo->mouse_face_buffer.  This turns
out, however, to be a fairly intricate change.)

Re: Bug in incremental undrawing of mouseover highlighting

[Eli Zaretskii]

> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
> 	  rogers-emacs@rgrjr.dyndns.org,  emacs-devel@gnu.org
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 25 Nov 2006 11:18:14 -0500
> 
> > I don't consider myself much of a redisplay expert, but I did express
> > a (different) concern for the patch as posted, a concern that
> > seemingly had no effect whatsoever.
> 
> It's still unclear, from the messages you sent, whether this bug can
> happen outside of HAVE_WINDOW_SYSTEM.  The bugfix is meant to plug a
> loophole in the code in note_mouse_highlight that computes whether or
> not the mouse highlight has been updated, which is only present for
> HAVE_WINDOW_SYSTEM.

You will see that the same code is duplicated, more or less, in
msdos.c, beginning at line 1612.  That is why I thought the same
problem could happen there, and that is why I was bothered by the fact
that the fix was only applied to builds that define
HAVE_WINDOW_SYSTEM.

Meanwhile, I've built an MSDOS port of Emacs 22.0.91 and found I
couldn't reproduce the original problem in it.  So I guess the issue
of whether the same fix should be applied to the MSDOS port can now be
closed.

As to the concerns expressed by Yamamoto Mitsuharu, I would also
suggest that a redisplay expert looks into them.

Re: Bug in incremental undrawing of mouseover highlighting

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

> As to the concerns expressed by Yamamoto Mitsuharu, I would also
> suggest that a redisplay expert looks into them.

Chong's patch may not be the cleanest approach, but I think it is ok.

However, it may be better to move the setup of dpyinfo into the
BLOCK_INPUT region, like this:

*** window.c	26 Nov 2006 12:21:36 +0100	1.566
--- window.c	26 Nov 2006 20:02:48 +0100	
***************
*** 3267,3274 ****
    int count = SPECPDL_INDEX ();
  #ifdef HAVE_WINDOW_SYSTEM
    struct frame *f = XFRAME (w->frame);
!   Display_Info *dpyinfo = (f && FRAME_X_OUTPUT (f)) ?
!     FRAME_X_DISPLAY_INFO (f) : NULL;
  #endif
  
    w->buffer = buffer;
--- 3267,3273 ----
    int count = SPECPDL_INDEX ();
  #ifdef HAVE_WINDOW_SYSTEM
    struct frame *f = XFRAME (w->frame);
!   Display_Info *dpyinfo;
  #endif
  
    w->buffer = buffer;
***************
*** 3352,3358 ****
  
  #ifdef HAVE_WINDOW_SYSTEM
    BLOCK_INPUT;
!   if (dpyinfo && EQ (window, dpyinfo->mouse_face_window))
      clear_mouse_face (dpyinfo);
    UNBLOCK_INPUT;
  #endif
--- 3351,3359 ----
  
  #ifdef HAVE_WINDOW_SYSTEM
    BLOCK_INPUT;
!   if (f && FRAME_X_OUTPUT (f)
!       && (dpyinfo = FRAME_X_DISPLAY_INFO (f))
!       && EQ (window, dpyinfo->mouse_face_window))
      clear_mouse_face (dpyinfo);
    UNBLOCK_INPUT;
  #endif


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in incremental undrawing of mouseover highlighting

[Richard Stallman]

       4.  "C-x b RET" to get back to the dired buffer, and move the mouse
    over a file name so that it is highlighted in green.

       5.  "C-x b RET" to return to *scratch*.  Notice that the same
    characters in the same position are still highlighted in green.

       6.  Move the mouse to a different file name.  Usually the
    highlighting goes away, but sometimes it doesn't (and it doesn't
    correlate with fontification).  If it does persist, type "C-x b RET" to
    return once more to the dired buffer, and there will be two green file
    names -- this can be repeated until every file name is green.

This does not fail for me in the latest sources.  Does it still fail
for you with the latest sources?

(Yanking is supposed to delete the properties that would cause
mouse-highlighting, and yanking into *scratch* should also delete
face properties.)

Re: Bug in incremental undrawing of mouseover highlighting

[Bob Rogers]

   From: Richard Stallman <rms@gnu.org>
   Date: Mon, 25 Dec 2006 21:26:20 -0500

	  4.  "C-x b RET" to get back to the dired buffer, and move the mouse
       over a file name so that it is highlighted in green.

	  5.  "C-x b RET" to return to *scratch*.  Notice that the same
       characters in the same position are still highlighted in green.

	  6.  Move the mouse to a different file name.  Usually the
       highlighting goes away, but sometimes it doesn't (and it doesn't
       correlate with fontification).  If it does persist, type "C-x b RET" to
       return once more to the dired buffer, and there will be two green file
       names -- this can be repeated until every file name is green.

   This does not fail for me in the latest sources.  Does it still fail
   for you with the latest sources?

It does work correctly.

   (Yanking is supposed to delete the properties that would cause
   mouse-highlighting, and yanking into *scratch* should also delete
   face properties.)

There weren't any properties on the yanked text in the other buffer,
AFAICS; it was that the dired highlight wasn't being undrawn if the
displayed text was the same in both buffers, regardless of properties.

					-- Bob

Re: Bug in incremental undrawing of mouseover highlighting

[Richard Stallman]

Thanks for confirming that this is fixed.

Re: Bug in incremental undrawing of mouseover highlighting

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Thanks for confirming that this is fixed.

Actually, it is NOT fixed.

Following the original recipe, it is easy to see the bug:

> I experience this bug fairly often in relatively mild form which is
> annoying but not unbearable.  But I've just run across a severe case
> of presumably the same bug.  It occurred while reading
> gnu-emacs-source from Gmane with Gnus.  The article that shows the
> problem is at <http://permalink.gmane.org/gmane.emacs.sources/1977>,
> and here's how to reproduce it:
>  
> 1. emacs -Q
> 2. M-: (setq gnus-select-method '(nntp "news.gmane.org")) RET
> 3. M-x gnus RET
> 4. S s gmane.emacs.sources
> 5. RET
> 6. C-s M-e [ 187: Alf-Ivar Holm RET C-f RET, i.e., go to this article
> and open it.
> 7. In the *Article* buffer, click on the MIME part header
> [2. Displaying ISO week in calendar, updated for emacs 22, 2nd try ---
> application/emacs-lisp; calendar-hack.el].  You'll see that the entire
> text of the attachment has mouse-face highlighting, and if you scroll
> over this part the incremental undrawing bug is apparent en masse.
> Now click the MIME part header again to close it, and either the
> entire header or the second line of will be double.  Further clicking
> to open and close the MIME part increases the number of (parts of)
> headers displayed.


I see all of the reported problems!

I pressed SPC to see the MIME part header, then clicked on it, and
moved the mouse over the expanded attachment text to highlight it,
I then pressed SPC a couple of times to scroll the buffer, and pressed DEL
to get back to the MIME header - and clicked it .. and the last line
is shown three times.

And there are lots of mouse-highlight artifacts.

This is probably a problem with scrolling through multiline
mouse-hightlight which spans multiple pages.

Chong, could you take another look at it?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Bug in incremental undrawing of mouseover highlighting

[Michael Mauger]

Kim F. Storm wrote:
> 
> Richard Stallman <rms@gnu.org> writes:
> 
>> Thanks for confirming that this is fixed.
> 
> Actually, it is NOT fixed.
> 
> Following the original recipe, it is easy to see the bug:
> 
> -- (snip) ---
> 
> This is probably a problem with scrolling through multiline
> mouse-hightlight which spans multiple pages.
> 
> Chong, could you take another look at it?
> 
> 

This seems to be similar to problem reported on October (see thread
"mouse-face redisplay messy on Windows XP x64 Edition", on
emacs-pretest-bug) which you felt was not worth fixing at this time.  Now, I
would love to see this fixed but let's make sure its a priority before the
release.  
-- 
View this message in context: http://www.nabble.com/Bug-in-incremental-undrawing-of-mouseover-highlighting-tf2665757.html#a8170867
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: Bug in incremental undrawing of mouseover highlighting

[Chong Yidong]

I have an idea about the origin of the various mouse-highlighting bugs
recently discussed on this list.

When redisplay_window is called, we call try_window, try_window_id,
and/or try_window_reusing_current_matrix depending on some complicated
logic that I haven't fully digested.  The latter two functions take
care to call clear_mouse_face_window before changing the current
matrix, but try_window does not, which I think causes the
mouse-highlighting information to be clobbered.

I am not sure what the best fix is.  One possibility is to
call clear_window_mouse_face at various places before calling
try_window, if that step is necessary.  The following patch implements
the latter approach, and seems to fix both bugs I'm aware of (the M-x
shell bug and the M-x calendar bug).

Another possibility is to call clear_window_mouse_face at the start of
try_window.  This may be cleaner, but one the other hand it may not be
necessary to do this for all calls to try_window.

I don't know the code well enough to ensure that all possible
scenarios are handled, so could someone could look over this and
comment?

*** emacs/src/xdisp.c.~1.1136.~	2007-01-17 22:03:21.000000000 -0500
--- emacs/src/xdisp.c	2007-01-19 10:22:02.000000000 -0500
***************
*** 13003,13008 ****
--- 13003,13013 ----
        else if (CHARPOS (startp) > ZV)
  	SET_TEXT_POS (startp, ZV, ZV_BYTE);
  
+       /* Clear any existing mouse face before redisplay.  */
+       update_begin (f);
+       rif->clear_window_mouse_face (w);
+       update_end (f);
+ 
        /* Redisplay, then check if cursor has been set during the
  	 redisplay.  Give up if new fonts were loaded.  */
        val = try_window (window, startp, 1);
***************
*** 13177,13182 ****
--- 13182,13192 ----
  	       = try_window_reusing_current_matrix (w)))
  	{
  	  IF_DEBUG (debug_method_add (w, "1"));
+ 
+ 	  update_begin (f);
+ 	  rif->clear_window_mouse_face (w);
+ 	  update_end (f);
+ 
  	  if (try_window (window, startp, 1) < 0)
  	    /* -1 means we need to scroll.
  	       0 means we need new matrices, but fonts_changed_p
***************
*** 13230,13235 ****
--- 13240,13250 ----
        && CHARPOS (startp) >= BEGV
        && CHARPOS (startp) <= ZV)
      {
+       /* Clear any existing mouse face before scrolling.  */
+       update_begin (f);
+       rif->clear_window_mouse_face (w);
+       update_end (f);
+ 
        /* The function returns -1 if new fonts were loaded, 1 if
  	 successful, 0 if not successful.  */
        int rc = try_scrolling (window, just_this_one_p,

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

On Fri, 19 Jan 2007 10:33:14 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

> I have an idea about the origin of the various mouse-highlighting bugs
> recently discussed on this list.

I applied your patch to CVS sources from 2007-01-19 and with it I
cannot reproduce the severe incremental undrawing I reported (see
http://permalink.gmane.org/gmane.emacs.devel/63681).  In my build from
those sources without the patch, I still get the bug.  Moreover, with
the patch I haven't observed the mild form I mentioned (I don't have a
precise recipe for reproducing that, but just experimented with
patched and unpatched Emacsen from otherwise identical source code).
So this fix seems to DTRT on this point.  (The patch does not fix the
second problem I mentioned: "Now click the MIME part header again to
close it, and either the entire header or the second line of will be
double.  Further clicking to open and close the MIME part increases
the number of (parts of) headers displayed.")

Steve Berman

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

On Sat, 20 Jan 2007 22:40:20 +0100 Stephen Berman
<Stephen.Berman@gmx.net> wrote: 

> Moreover, with the patch I haven't observed the mild form I
> mentioned (I don't have a precise recipe for reproducing that, but
> just experimented with patched and unpatched Emacsen from otherwise
> identical source code).

After seeing the problem Nick Roberts reported in the thread
"Flickering mouse-face" also in my patched Emacs, I did further
experimenting and did observe the milder form of incremental undrawing
with the patch.  I also have a somewhat unstable recipe for
reproducing it.  Currently, I see the problem with the following shows
(using the patch to xdisp.c applied in revision 1.1137):

1. emacs -Q

2. M-: (setq gnus-select-method '(nntp "news.gmane.org")) RET

3. M-x gnus RET

4. S s gmane.emacs.devel

5. Press RET on this group and at the prompt "How many articless from
gmane.emacs.devel (default 64519):" type 1000 RET

NB: The rest of this recipe depends on the top line in the Gnus
Summary buffer being this:
 . [ 273: Lennart Borgman        ] File name completion in *Shell* on w32

6. Put the mouse pointer between `[' and `]' on this line, so that
mouse-face highlighting is displayed.

7. Type `C-s 1 5 l :' and the C-g.  Now you will see mouse-face
highlighting in the first also in the space between `]' and `F', and
when you mouse the mouse pointer, that space still shows mouse-face.

Given this problem and the new problem reported by Nick Roberts, it
seems this patch is insufficient.

Steve Berman

Re: Bug in incremental undrawing of mouseover highlighting

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

I continue to see manifestations of a redisplay bug with mouseover
highlighting in Gnus Summary buffers.  It happens fairly seldom and I
cannot reproduce it.  It happened again today on GNU Emacs 23.0.50.3
(i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2007-11-06 on escher, and I
made a screen shot, attached below.  As the image illustrates, only one
character width is involved, and this is always how it shows up now and
for many months (whereas earlier manifestations usually involved several
character widths, usually with non-highlighted gaps).  The image
suggests that the position of the remnant mouseover highlighting was
occupied by the cursor, but I am sure of this.

Steve Berman


[-- Attachment #2: remnant mouseover highlighting --]
[-- Type: image/png, Size: 4047 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Bug in incremental undrawing of mouseover highlighting

[John Paul Wallington]

Chong Yidong <cyd@stupidchicken.com> writes:

> I don't know the code well enough to ensure that all possible
> scenarios are handled, so could someone could look over this and
> comment?
>
> *** emacs/src/xdisp.c.~1.1136.~	2007-01-17 22:03:21.000000000 -0500
> --- emacs/src/xdisp.c	2007-01-19 10:22:02.000000000 -0500

I don't understand the code but I'm having the same problem with
leftover mouse highlight turds in the Gnus Summary buffer that I had
on Windows in October (see
http://www.shootybangbang.com/redisplay-mouse-face-bug.png) on my
GNU/Linux system too, now.  Installing your patch gets rid of them; I
haven't seen one since.