GNU bug report logs - #11210
(w32-use-visible-system-caret = t) && (scroll-conservatively = 1) results in multiple cursors displayed after scrolling

Previous Next

Full log

View this message in rfc822 format

From: Bill Meier <wmeier <at> newsguy.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11210 <at> debbugs.gnu.org, Jason Rumney <jasonr <at> gnu.org>
Subject: bug#11210: Windows emacs 23.4.1: scroll-conservatively > 0 results in	multiple cursors being displayed after scrolling
Date: Thu, 19 Apr 2012 13:00:10 -0400

On 4/15/2012 1:27 PM, Bill Meier wrote:
> On 4/15/2012 10:43 AM, Jason Rumney wrote:
>> Bill Meier<wmeier <at> newsguy.com> writes:
>>
>>> If others using Windows 7 do see an empty rectangle in non-selected
>>> windows and/or are able to change the cursor config from within Emacs,
>>> then obviously there's something special/different about my
>>> configuration.
>>
>> Are you using screen reader or other accessibility software?
>>
>>
>
> No .....
>
>

Um...

After reading the code in w32term.c and checking the value of
w32-use-visible-system-caret in my Emacs, I found it had a value of 1.

So: Jason asked the right question.

It turned out that (unremembered by me) I once tried out
speech-recognition/text-to-speech which was still enabled (but not 
actually being used).

When I disabled same, my Emacs cursor was "normal" (and no artifacts 
appeared when I downarrowed off the bottom of the screen).

However, if I set w32-use-visible-system-caret to 1 and
scroll-conservatively to 1, I get artifacts.

So: this bug should actually be entitled:

(scroll-conservertively > 0) && (w32-use-visible-system-caret == 1) 
results in multiple cursors ....

Re:
> Can you run Emacs you built under a debugger?  If so, please make an
> unoptimized build ("configure --no-opt" in the nt/ directory to
> configure the package before compiling), and please show the values of
> yb and last_new on line 5021 of dispnew.c, when you press down-arrow
> on the "123" line in this recipe:

> For the record, the values I see are yb = 384 and last_new = 24.
>

I see the same values.

Note: To reliably (90% of the time) get artifacts I actually used 32 
lines as follows:
001
002
003
...
032
123

Using abc,abc,...,123 now doesn't give artifacts for some reason.
Actually: the breakpoint is never hit in this case.
So: I'm no longer sure about my originally stated test case (abc,...,123).

Note: Just for the record, I put the breakpoint at
r 100582: dispnew.c: line 5016

5016      i = first_old + 1;
5017      while (i < current_matrix->nrows - 1)

Previous Next

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