emacs-devel
[Top][All Lists]
Advanced

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

Re: position of line moves depending on visible chars


From: Eli Zaretskii
Subject: Re: position of line moves depending on visible chars
Date: Sun, 17 Jul 2016 17:07:24 +0300

> Date: Sun, 17 Jul 2016 22:31:10 +0900
> From: Yasushi SHOJI <address@hidden>
> 
> I'm seeing the position of a text line in an Emacs buffer moves up and
> down depending on chars in the visible area.
> 
> Let's say I'm running my Emacs on a system with two different fonts,
> each of which has different height in the buffer.  In my case they are
> Japanese chars and ASCII chars.
> 
> To reproduce this, put the following contents in an Emacs buffer and
> make the width of the window narrow enough, so that the last long line
> does not fit in the window.
> 
>
> ああ
> あああ
> ああああ
> あああああ
> ああああああaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> 
> Enable truncate line (M-x toggle-truncate-lines) so the longest line
> does not fold at the end.
> 
> Now, put your cursor at the last long line and do C-a / C-e to move
> back and forth.  The position of the last line moves up and down a few
> pixels depending on how much "あ" is visible/hidden. You can put more
> "あ" vertically at the point-min and you see line moves more.

This is not a bug, but the intended behavior: Emacs lays out lines
according to what is actually shown.  When you scroll the window
horizontally by typing C-e, the lines became less tall, because the
Japanese characters are not shown.

> I'm using Emacs-25 branch (80e2044a7f19719720d330e2796c9dfe5471e100)
> and this is not affect by -Q option, but rather height of fonts.  The
> master branch behaves as 25.  Emacs 24 works just fine.
> 
> Git bisect points at:
> 
> > ba5f83dfe5dea1b9dd3fca5d21384afc92cd2060 is the first bad commit
> > commit ba5f83dfe5dea1b9dd3fca5d21384afc92cd2060
> > Author: Eli Zaretskii <address@hidden>
> > Date:   Sat May 30 12:33:08 2015 +0300
> > 
> >     Fix display of cursor at end of empty lines

Yes, this is a deliberate change in behavior, as explained in the
commit log message.

Thanks.



reply via email to

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