Make fci-mode coexist better with line-move-visual

Make fci-mode coexist better with line-move-visual

[Matt McClure]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

I'm interested in isolating and fixing whatever prevents `line-move-visual`
from behaving as expected when `fci-mode` is on. Do you have more
information on what part of the C implementation behaves badly with
`fci-mode` and `line-move-visual`?

I also opened this as a GitHub issue against fci-mode.[1]

Background:

The Fill-Column-Indicator README[2] says:

> If line-move-visual is t, then vertical navigation can behave oddly in
several edge cases while fci-mode is enabled (this is due to a bug in
Emacs's C code). Accordingly, fci-mode sets line-move-visual to nil in
buffers in which it is enabled and restores it to its previous value when
disabled. This can be suppressed by setting fci-handle-line-move-visual to
nil. (But you shouldn't want to do this. There's no reason to use
line-move-visual if truncate-lines is t, and it doesn't make sense to use
something like fci-mode when truncate-lines is nil.)

This is a small test case that shows the unexpected behavior:

    $ open -n -a Emacs --args -Q --no-site-file --eval '(progn (load-file
"fill-column-indicator.el") (fci-mode) (set-variable (quote
line-move-visual) t) (insert "\n\n  \n") (goto-line 2)
(move-beginning-of-line nil) (next-line) (what-cursor-position))'

Observe that the point lands in column 2 in the above example, whereas
without `line-move-visual`, it lands in column 1 as expected:

    $ open -n -a Emacs --args -Q --no-site-file --eval '(progn (load-file
"fill-column-indicator.el") (fci-mode) (insert "\n\n  \n") (goto-line 2)
(move-beginning-of-line nil) (next-line) (what-cursor-position))'

[1]: https://github.com/alpaker/Fill-Column-Indicator/issues/35
[2]:
https://github.com/alpaker/Fill-Column-Indicator/blob/master/README.markdown#other-options


-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure

[-- Attachment #2: Type: text/html, Size: 2529 bytes --]

Re: Make fci-mode coexist better with line-move-visual

[Eli Zaretskii]

> Date: Fri, 12 Jul 2013 16:03:07 -0400
> From: Matt McClure <matthewlmcclure@gmail.com>
> 
> I'm interested in isolating and fixing whatever prevents `line-move-visual`
> from behaving as expected when `fci-mode` is on. Do you have more
> information on what part of the C implementation behaves badly with
> `fci-mode` and `line-move-visual`?

I think it's posn-at-point.  Look at what it returns at the leftmost
position of the 2nd line, and you will see why next-line moves to
column 2.

Re: Make fci-mode coexist better with line-move-visual

[Matt McClure]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Fri, Jul 12, 2013 at 4:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> I think it's posn-at-point.  Look at what it returns at the leftmost
> position of the 2nd line, and you will see why next-line moves to
> column 2.
>

Interesting. In the leftmost position on line 2, in both scenarios in my
original message, posn-at-point returns:

    (#<window 0x106810050 on *scratch*> 2 (497 . 15) 0 nil 2 (3 . 1) nil (0
. 0) (7 . 15))

I think you're saying the (COL . ROW) value (3 . 1) should be (0 . 2).
Right?

-- 
Matt McClure
http://matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure

[-- Attachment #2: Type: text/html, Size: 1090 bytes --]

Re: Make fci-mode coexist better with line-move-visual

[Eli Zaretskii]

> Date: Fri, 12 Jul 2013 17:34:29 -0400
> From: Matt McClure <matthewlmcclure@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> Interesting. In the leftmost position on line 2, in both scenarios in my
> original message, posn-at-point returns:
> 
>     (#<window 0x106810050 on *scratch*> 2 (497 . 15) 0 nil 2 (3 . 1) nil (0
> . 0) (7 . 15))
> 
> I think you're saying the (COL . ROW) value (3 . 1) should be (0 . 2).
> Right?

Yes, and (X . Y) should be (0 . 30) or something.  The value it
returns now clearly belongs to the previous line's rightmost position.