[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11210: Windows emacs 23.4.1: scroll-conservatively > 0 results in mu

From: Bill Meier
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
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

On 4/15/2012 1:27 PM, Bill Meier wrote:
On 4/15/2012 10:43 AM, Jason Rumney wrote:
Bill Meier<address@hidden> 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

Are you using screen reader or other accessibility software?

No .....


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 ....

> 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:

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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]