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.