When opening a utf-8 file that doesn't have a byte order mark the cursor position is set to the first wide character rather the the last cursor position from when the file was last opened. Reproducible: Always Steps to Reproduce: 1. Open a utf8 encoded file that doesn't have a byte order mark. Example file in xxd format: 0000000: 410a 420a c2a9 0a44 0a45 0a A.B....D.E. 2. Position the cursor on a line that has only ascii characters. 3. Reopen the file. Actual Results: The cursor has been positioned on the first non-ascii character in the document. Expected Results: Cursor position should have been placed on the line it was last on. I believe this behavior is due to one of Gentoo's custom autocmd in /etc/vim/vimrc. Namely: autocmd BufReadPost * \ if exists("g:added_fenc_utf8") && &fileencoding == "utf-8" && \ ! &bomb && search('[\x80-\xFF]','w') == 0 && &modifiable | \ set fileencoding= | \ endif In particular I think that the search function is moving the cursor after the last cursor position BufReadPost has already run. One workaround is to position this code above the last cursor position code so that last cursor position get's run last. However I assume this would still mess up the cursor position even if some has g:leave_my_cursor_position_alone defined.
(In reply to comment #0) > In particular I think that the search function is moving the cursor after the > last cursor position BufReadPost has already run. Yes, that's exactly what's happening, good catch! > One workaround is to position this code above the last cursor position code so > that last cursor position get's run last. However I assume this would still > mess up the cursor position even if some has g:leave_my_cursor_position_alone > defined. Actually if I just change the flags of the search() function from 'w' to 'nw' ('n' meaning "do Not move the cursor"), we have the perfect solution. I didn't think this was worth a revbump which would force everyone to reinstall their current vim-core, and this bug only affects users who are not running a UTF-8 locale, so I have just fixed this in-place. (In other words, you will need to manually re-emerge app-editors/vim-core to get this fix once it hits your local rsync mirrors, or just edit /etc/vim/vimrc yourself since it's a pretty quick fix) Thanks again for the report and excellent investigation into the cause!
*** Bug 321425 has been marked as a duplicate of this bug. ***
