[Top][All Lists]

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

bug#14567: These changes sometimes break plain text navigation

From: Dima Kogan
Subject: bug#14567: These changes sometimes break plain text navigation
Date: Sat, 06 Jul 2013 02:02:16 -0700
User-agent: mu4e; emacs

Hi. I'm seeing the patches meant to address this bug break plain-text
scrolling. I'm reporting this new issue here, since it seems on-topic.
I'm running a close-to-HEAD emacs on a Debian box. The most recent
change to simple.el is this:


I'm observing that under some specific conditions (ones that my .emacs
just happens to hit) C-f can get stuck scrolling text instead of going
to the next line. To make the bug happen, I do this:

1. Load a text file. This is plain ASCII. No images or unicode or
   anything interesting. A nice test case is the output of 'seq 1000'

2. Press C-f repeatedly until the point reaches the bottom of the
   screen; this works fine

3. When at the bottom of the screen C-f scrolls the text one line up,
   while keeping the point where it was in the buffer. Now the point
   gets stuck, and subsequent C-f/C-b just scroll the screen; the point
   is stuck.

The bug requires particular .emacs settings. I wittled it down to this:

    '((font . "-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1")))
 '(inhibit-startup-screen t))


The inhibit-startup-screen is there to be nicer; may not be required for
the bug. The (global-hl-line-mode) is significant. The bug doesn't
happen without it. That font is significant also. Other fonts seem to
work without the bug. I suspect the window sizes are significant as
well. I can see the bug if I launch 'emacs -geometry 30x30'. The
width/height of the emacs window as reported by xwininfo is then

This is 100% reproducible for me. I suspect it may not be so for others.
Let me know if I should run any specific tests to get to the bottom of


reply via email to

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