Saturday, May 22, 2010

Re: Cursor column on line 1 not remembered

On 22/03/10 20:50, Brett Stahlman wrote:
>
> ...[snip]...
>
>>> Just to be clear... The version in my .vimrc appears to be correct...
>>
>>> autocmd BufReadPost *
>>> \ if line("'\"")> 0&& line("'\"")<= line("$") |
>>> \ exe "normal g`\"" |
>>> \ endif
>>
>>> ...yet I still experience the issue.
>>
>> In your own .vimrc? or in a system-wide vimrc? Maybe there are two
>> commands being processed.
>>
>> Either way, do you see anything odd in the output of:
>>
>> :au BufReadPost *
>
> There is only my own .vimrc, and it matches the output of BufReadPost:
>
>
> --- Auto-Commands ---
> filetypedetect BufRead
> * if !did_filetype()&& expand("<amatch>") !~
> g:ft_ignore_pat | runtime! scripts.vim | endif
> * if !did_filetype()&& expand("<amatch>") !~
> g:ft_ignore_pat&& (getline(1) =~ '^#' || getline(2) =~ '^#' ||
> getline(3) =~ '^#'^I|| getline(4) =~ '^#' || getline(5) =~ '^#') |
> setf conf | endif
> BufRead
> * if line("'\"")> 0&& line("'\"")<= line("$") | exe
> "normal g`\"" | endif
>
> I know this autocommand is correct, not only by inspection, but also
> because the cursor position jumps to the end of line 1 when I do...
> :doau BufReadPost *
> ...after the file has loaded. I loaded the file with verbose=9 to see
> whether there were something that might be clobbering the position,
> but didn't notice anything suspicious. Here's the output, beginning
> with the cursor restoration autocommand (<<< >>> comments
> interspersed):
>
> Executing BufRead Auto commands for "*"
> autocommand if line("'\"")> 0&& line("'\"")<= line("$") | exe
> "normal g`\"" | endif
>
> <<< I verified with echomsg that col("'\"") is correct at this point
>>>>
>
> Executing BufEnter Auto commands for "*"
> autocommand call s:checkForBrowse(expand("<amatch>"))
>
> Executing BufEnter Auto commands for "*"
> autocommand silent call<SID>MRUPush()
>
> Executing CursorMoved Auto commands for "*"
> autocommand call s:Highlight_Matching_Pair()
>
> <<< Cursor is at beginning of line at this point>>>
>
> <<< However, doing...
> doau BufReadPost *
> ...at this point moves the cursor to the end of the line
>>>>
>
> Brett Stahlman
>
>
>>
>> Maybe something else is resetting the position as well.
>>
>> --
>> Best,
>> Ben- Hide quoted text -
>>
>> - Show quoted text -
>

Just FYI, the autocommand as present in the latest vimrc_example.vim for
Vim 7.3a (and in the help for the line() function) compares line(1)
against > 1 which means that if the cursor was on line 1 the g`" will be
skipped and the cursor won't move from line 1 column 1. I guess this is
a bug, though the comment above it seems to imply that it's intentional.
Here's the code (lines 65-67 and 72-82):

" Put these in an autocmd group, so that we can delete them easily.
augroup vimrcEx
au!
[...]
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event
handler
" (happens when dropping a file on gvim).
" Also don't do it when the mark is in the first line, that is the
default
" position when opening a file.
autocmd BufReadPost *
\ if line("'\"") > 1 && line("'\"") <= line("$") |
\ exe "normal! g`\"" |
\ endif

augroup END

According to the Mercurial log, the latest change to that file was in
changeset 7bc41231fbc7 dated Wed Jan 06 20:54:52 2010 +0100 in the
default branch. That was a huge changeset concerning 233 runtime files.
However the "Last Change" near the top of the file says 2008 Dec 17 --
almost one year earlier.

Best regards,
Tony.
--
Ah, but the choice of dreams to live,
there's the rub.

For all dreams are not equal,
some exit to nightmare
most end with the dreamer

But at least one must be lived ... and died.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

No comments: