> Hi
> I had this strange behavior again this afternoon, so I was editing a
> file, that was being modified by a java process who was writing in it.
> And I don't know what happens (maybe a mousse scroll or something like
> that) and the whole part before the line is erased and I got :
> g`" instead.
>
> I have been able to take a picture with my phone (they are so paranoid
> in my firm that I avoided to make a screenshot sent by email) it can
> be seen here:
> http://www.flickr.com/photos/69121410@N06/6284304680/in/photostream/lightbox/
>
> I tried :redraw, CTrl-L nothing to do.
> The strange thing is that the file is not written, cause when I close
> it vim doesn't ask me if I want to save, and re-opening bring it back
> to me.
>
> Any ideas ?
To me it looks like it's a malfunctioning autocmd, which doesn't
anticipate being called when it's being called. (Pretty sure 'autoread'
doesn't kick in in Insert mode.)
As pointed out in:
:help g`
g`"
jumps to the last known position in a file. So, it's commonly added to
systemwide /etc/vimrc autocmds so that opening a file again will start
you in the same place you were at when you last stopped editing it.
A common example is included in the example rc, IIRC. On Gentoo, it's:
" [...inside augroup gentoo]
" When editing a file, always jump to the last cursor position
autocmd BufReadPost *
\ if ! exists("g:leave_my_cursor_position_alone") |
\ if line("'\"") > 0 && line ("'\"") <= line("$") |
\ exe "normal g'\"" |
\ endif |
\ endif
Not sure, but I think this one would be okay regardless of the context.
Maybe you have something simpler, like:
au BufReadPost * normal g`"
Or maybe you have some other command that tries to reread the buffer,
even when in Insert mode. (Which then triggers the bad behavior of the
other command.)
--
Best,
Ben
--
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:
Post a Comment