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