bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

[Nicolas Richard]

Hi,

from emacs -Q, run the following with M-:

(progn
  (insert (make-string 500 ?x))
  (column-number-mode) ;; just to see it. plays no role.
  (beginning-of-line)
  (setq line-prefix (make-string 10 ? ))
  (visual-line-mode)
  (toggle-truncate-lines 1))

then hit C-e (end-of-visual-line) a few times. After some hits, the
cursor doesn't move anymore, although it's not at the end of the line.
On my machine, it goes to column 70, then 100, then stops there even
when hitting C-e again.

I expect emacs to scroll horizontally instead (like it does when
line-prefix is nil).

-- 
Nicolas.

bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Fri, 20 Jun 2014 19:40:24 +0200
> 
> (progn
>   (insert (make-string 500 ?x))
>   (column-number-mode) ;; just to see it. plays no role.
>   (beginning-of-line)
>   (setq line-prefix (make-string 10 ? ))
>   (visual-line-mode)
>   (toggle-truncate-lines 1))
> 
> then hit C-e (end-of-visual-line) a few times. After some hits, the
> cursor doesn't move anymore, although it's not at the end of the line.
> On my machine, it goes to column 70, then 100, then stops there even
> when hitting C-e again.
> 
> I expect emacs to scroll horizontally instead

Why do you expect that?  "Visual line" means the line that is on
display.  What isn't on display does not exist for this purpose.

Is there some real-life use case behind this?  If so, please show it.

bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

[Stefan Monnier]

> Why do you expect that?  "Visual line" means the line that is on
> display.  What isn't on display does not exist for this purpose.

Hmm... good point.  My intuitive understanding of the "visual line"
feature is to distinguish the "newlines" from the "line wraps", so when
we `truncate-lines' I'd expect the visual-line movements to be the same
as the physical line movements (tho I'd allow a distinction in the case
of line-wraps introduced via `display' of before/after-strings).


        Stefan

bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Date: Fri, 20 Jun 2014 19:40:24 +0200
>> 
>> (progn
>>   (insert (make-string 500 ?x))
>>   (column-number-mode) ;; just to see it. plays no role.
>>   (beginning-of-line)
>>   (setq line-prefix (make-string 10 ? ))
>>   (visual-line-mode)
>>   (toggle-truncate-lines 1))
>> 
>> then hit C-e (end-of-visual-line) a few times. After some hits, the
>> cursor doesn't move anymore, although it's not at the end of the line.
>> On my machine, it goes to column 70, then 100, then stops there even
>> when hitting C-e again.
>> 
>> I expect emacs to scroll horizontally instead
>
> Why do you expect that?

Because when the cursor is near the right border of the window (~ 5
characters), emacs scrolls horizontally automatically (depending on
auto-hscroll-mode). Since the end of the visual line is at the right
border of the window, emacs should put cursor there and scroll
accordingly. It does it correctly when line-prefix is nil. In the recipe
I gave, C-e fails to place point at the right border of the window.

> Is there some real-life use case behind this?  If so, please show it.

My use case is an org mode file like

* title
** title2
*** title3
| some | very | wide | org | mode | table | some | very | wide | org | mode | table | some | very | wide | org | mode | table | some | very | wide | org | mode | table | some | very | wide | org | mode | table | some | very | wide | org | mode | table | 

when org-indent-mode is activated (which adds line-prefix) and
visual-line-mode activated. If the table is very wide, it'll be wrapped
and look bad. So I toggle-truncate-lines temporarily to avoid the
wrapping, and can navigate through the table by (horizontal)
screenfuls... except for the bug.

The workaround in my use case is to temporarily turn off
visual-line-mode instead of temporarily activating truncate-lines ; but
nevertheless I think there's a bug in vertical-motion : (vertical-motion
(cons (window-width) 0)) fails to set the point at the correct position
when asked to.

-- 
Nico.

bug#17823: 24.3.91; end-of-visual-line: incorrect behaviour with truncate-lines and a line-prefix

[Eli Zaretskii]

> Date: Fri, 20 Jun 2014 21:56:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 17823@debbugs.gnu.org
> 
> > From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> > Date: Fri, 20 Jun 2014 19:40:24 +0200
> > 
> > (progn
> >   (insert (make-string 500 ?x))
> >   (column-number-mode) ;; just to see it. plays no role.
> >   (beginning-of-line)
> >   (setq line-prefix (make-string 10 ? ))
> >   (visual-line-mode)
> >   (toggle-truncate-lines 1))
> > 
> > then hit C-e (end-of-visual-line) a few times. After some hits, the
> > cursor doesn't move anymore, although it's not at the end of the line.
> > On my machine, it goes to column 70, then 100, then stops there even
> > when hitting C-e again.
> > 
> > I expect emacs to scroll horizontally instead
> 
> Why do you expect that?  "Visual line" means the line that is on
> display.  What isn't on display does not exist for this purpose.
> 
> Is there some real-life use case behind this?  If so, please show it.

Actually, no, don't bother.  I found out that this was due to the
original code in vertical-motion being incorrect due to some subtle
aspect of the display engine which the code ignored.

Fixed in revision 117277 on the emacs-24 branch.