Re: Display engine bugs

[Juri Linkov]

address@hidden (Kim F. Storm) writes:
> Juri Linkov <address@hidden> writes:
>
>> I found some bugs related to text displaying:
>
> Thanks for your reports.
>
> You forgot to tell which version and system you use though.

My configuration is the most standard one:

_Version_: GNU Emacs 21.3.50 (i686-pc-linux-gnu) of 2003-11-11 CVS HEAD
_Command line_: emacs -q --no-site-file --eval "(blink-cursor-mode 0)"

> I'm looking into these problems, and have made some small progress...
>
>> 1. When a point is located on the second line from the bottom of the
>> window, then scrolling down one line (e.g. by C-u 1 M-x scroll-down)
>> moves point to the beginning of the current line.  This is a bug
>> because the current line becomes the last line of the window and it
>> remains visible, but its point moves to the line beginning.  
>
> I can reproduce this.  No fix yet.
>
>> I have also a related feature request: to preserve column position
>> if a line becomes invisible after scrolling, i.e. to move point to
>> the same column of the previous visible line instead of jumping to
>> the line beginning as it does now.
>
> This is a bit unclear -- how does scrolling make a line invisible?

Sorry if I was unclear.  Scrolling current window one line down makes
the last line invisible, because it moves off the screen.  If point
was located on the last line, then after scrolling the point is moved
to the beginning of the previous line, which becomes the window's last
line.  What I suggest is to move point to the previous line to the
same column were point was located on the last line before scrolling.
I think this is the most reasonable behavior, because it is very
similar to simple point movement (e.g. by C-p) where the point moves
exactly vertically over the current column, or at the end of the line
if it is not long enough.  I even believe that you could find such a
proper place in the code where adding this feature will simultaneously
fix the related bug.

>> 2. Scrolling the buffer screenfully with text in a proportional font
>> sometimes moves a point into center of window instead of moving it
>> into first or last window line.  Sometimes scrolling down towards the
>> beginning of the buffer stops on the last line of the first screen
>> and don't move further and don't signal an error.
>
> Haven't looked at this yet.  A complete, self-contained test case would help!

Try to scroll down (i.e. toward the beginning) a large multi-screen
Info node with titles in variable-pitch faces.  On some pages the
point jumps into center instead of remaining on the last line.
I suspect that culprit is the partially visible last line (perhaps
it's somehow related to the first bug above).

>> 3. When window is split vertically (e.g. by C-x 2), the cursor
>> (hollow box) don't appear immediately in the non-selected window.
>> It appears here only after pressing some key or after some timeout.
>
> This doesn't happen to me.  
>
> What happens if you start
>         emacs -q --eval '(blink-cursor-mode -1)'

Actually it only happens with blinking cursor turned off, because
first blink displays the cursor in the non-selected window.  So,
no blinking, no displaying.  And it happens only after the second call
of split-window, i.e.

emacs -q --no-site-file --eval "(blink-cursor-mode 0)"
C-x 2 C-x 1 C-x 2

>> 4. "Black hole"
>> 5. Next bug can be reproduced by evaluating the following line:
[4 & 5 are fixed now]

On my first post I wanted to report yet another bug, but I doubt
that it can be easily repeated.  But anyhow even if you will be unable
to repeat it, maybe at least from the description you will get a clue
what is wrong:

6. To repeat this bug you will need to start unclutter (unclutter is
X application that removes the mouse cursor from the screen after a
given timeout) with:

unclutter -root -idle 1&

Then create a new Emacs frame, but place the mouse cursor on the
original Emacs frame with which Emacs was started.  When mouse cursor
is removed from screen by unclutter, then Emacs selects the original
frame, but input focus remains in the new frame (however, I can't tell
exactly what actually happens).  Seems this is Emacs bug, because it
can be repeated with different window managers which place input focus
on window only after mouse click (i.e. don't change input focus
immediately after moving mouse into another window).

-- 
http://www.jurta.org/emacs/