BUG: BufReadPre autocmd changes cursor position on :pedit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BUG: BufReadPre autocmd changes cursor position on :pedit

Ingo Karkat

Hello VIM developers,

I found a small bug in :pedit when one wants to clone the current buffer to the
preview window _and_ there is a :autocmd for the 'BufReadPre' event; in that
case, the cursor jumps to the first line of the original window instead of
remaining at the same position.
In my case, the bug manifests itself due to DrChip's 'LargeFile.vim' plugin
(vimscript#1506), which defines an ':au BufReadPre *'. I was working on an
elaborate mapping that included ':pedit %' and relied on the cursor not moving.

Steps to reproduce:

gvim -N -u NONE
" Just open a file with a couple of lines and go to the end.
:e + $VIMRUNTIME/vimrc_example.vim
:echo line('.')
94
:pedit %
:echo line('.')
94
" Okay, still at the end.
:pclose
:au BufReadPre * let g:isExecuted = 1
:pedit %
" By now, the cursor has jumped to the first line in the original window;
" the same happens with :pedit, but not with :pedit <any other file>.
:echo line('.')
1
" The help says the cursor position shouldn't change.
:help :pedit
[...] The current window and cursor position isn't changed.

I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big version)
on openSUSE 10.3/x86.

-- best regards, ingo

PS: I rewrote my mapping to use bufnr() / :buffer to open the same file in the
preview window; but now I have to work around the fact that there is no :popen
command to open a blank preview window. Why is that one missing?

/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --

             The Martian canals were the Martians' last ditch effort.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG: BufReadPre autocmd changes cursor position on :pedit

Bram Moolenaar


Ingo Karkat wrote:

> Hello VIM developers,
>
> I found a small bug in :pedit when one wants to clone the current
> buffer to the preview window _and_ there is a :autocmd for the
> 'BufReadPre' event; in that case, the cursor jumps to the first line
> of the original window instead of remaining at the same position.
> In my case, the bug manifests itself due to DrChip's 'LargeFile.vim'
> plugin (vimscript#1506), which defines an ':au BufReadPre *'. I was
> working on an elaborate mapping that included ':pedit %' and relied on
> the cursor not moving.
>
> Steps to reproduce:
>
> gvim -N -u NONE
> " Just open a file with a couple of lines and go to the end.
> :e + $VIMRUNTIME/vimrc_example.vim
> :echo line('.')
> 94
> :pedit %
> :echo line('.')
> 94
> " Okay, still at the end.
> :pclose
> :au BufReadPre * let g:isExecuted = 1
> :pedit %
> " By now, the cursor has jumped to the first line in the original window;
> " the same happens with :pedit, but not with :pedit <any other file>.
> :echo line('.')
> 1
> " The help says the cursor position shouldn't change.
> :help :pedit
> [...] The current window and cursor position isn't changed.
>
> I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big
> version) on openSUSE 10.3/x86.

I can reproduce it.  I'll add a remark to the todo list.

> -- best regards, ingo
>
> PS: I rewrote my mapping to use bufnr() / :buffer to open the same
> file in the preview window; but now I have to work around the fact
> that there is no :popen command to open a blank preview window. Why is
> that one missing?

Why would you want to preview nothing?

--
hundred-and-one symptoms of being an internet addict:
128. You can access the Net -- via your portable and cellular phone.

 /// Bram Moolenaar -- [hidden email] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG: BufReadPre autocmd changes cursor position on :pedit

Ingo Karkat

On 01-Jul-08 21:34, Bram Moolenaar wrote:

>
> Ingo Karkat wrote:
>
>> Hello VIM developers,
>>
>> I found a small bug in :pedit when one wants to clone the current
>> buffer to the preview window _and_ there is a :autocmd for the
>> 'BufReadPre' event; in that case, the cursor jumps to the first line
>> of the original window instead of remaining at the same position.
>> In my case, the bug manifests itself due to DrChip's 'LargeFile.vim'
>> plugin (vimscript#1506), which defines an ':au BufReadPre *'. I was
>> working on an elaborate mapping that included ':pedit %' and relied on
>> the cursor not moving.
>>
>> Steps to reproduce:
>>
>> gvim -N -u NONE
>> " Just open a file with a couple of lines and go to the end.
>> :e + $VIMRUNTIME/vimrc_example.vim
>> :echo line('.')
>> 94
>> :pedit %
>> :echo line('.')
>> 94
>> " Okay, still at the end.
>> :pclose
>> :au BufReadPre * let g:isExecuted = 1
>> :pedit %
>> " By now, the cursor has jumped to the first line in the original window;
>> " the same happens with :pedit, but not with :pedit <any other file>.
>> :echo line('.')
>> 1
>> " The help says the cursor position shouldn't change.
>> :help :pedit
>> [...] The current window and cursor position isn't changed.
>>
>> I can reproduce this with VIM 7.1 on Windows and with VIM 7.2a.10 (Big
>> version) on openSUSE 10.3/x86.
>
> I can reproduce it.  I'll add a remark to the todo list.

Thanks a lot.

>> PS: I rewrote my mapping to use bufnr() / :buffer to open the same
>> file in the preview window; but now I have to work around the fact
>> that there is no :popen command to open a blank preview window. Why is
>> that one missing?
>
> Why would you want to preview nothing?

I'm using the preview window as a kind of "Singleton" window: There's only one
(in a tab page), and I set up custom mappings to "push" various content to it;
for example, clone the current buffer to it. The disadvantage of :pedit (in
addition to the bug I reported) is that it warns "no write since last change",
or discards changed (:pedit!). So, I'm doing this instead:

     let l:bufnum = bufnr('')
     try
        " If the preview window is open, just go there.
        wincmd P
     catch /^Vim\%((\a\+)\)\=:E441/
        " Else, temporarily open a dummy file. (There's no :popen command.)
        silent pedit +setlocal\ buftype=nofile\ bufhidden=wipe\ nobuflisted\ noswapfile
[No\ Name]
        wincmd P
     endtry
     " Load the current buffer in the preview window, if it's not already there.
     if bufnr('') != l:bufnum
        silent execute l:bufnum . 'buffer'
     endif

Another use case for :popen I can think of is to display text that is not loaded
from an actual file, but auto-generated from a VIM script, using
'buftype=nofile' etc. Many plugins (like taglist, bufexplorer, ...) set up such
custom buffers, and implement this Singleton-ness by themselves, as they only
want one instance of the buffer displayed at any time. For plugins, that may be
okay; for my own personal mappings, I'd like to reuse the existing commands that
efficiently deal with (going to and from, closing, ...) the preview window.

-- regards, ingo

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG: BufReadPre autocmd changes cursor position on :pedit

mMontu
This post has NOT been accepted by the mailing list yet.
In reply to this post by Bram Moolenaar
On Vim 7.4 this problem is documented on :help todo

":pedit %" with a BufReadPre autocommand causes the cursor to move to the
first line. (Ingo Karkat, 2008 Jul 1)  Ian Kelling is working on this.

But the bug has somehow propagated to :edit command:

gvim -N -u NONE
" Just open a file with a couple of lines and go to the end.
:e + $VIMRUNTIME/vimrc_example.vim
:echo line('.')
:split
:windo echo line('.')
96
96
" Okay, both windows still at the end.
:au BufReadPre * let g:isExecuted = 1
:edit
" By now, the cursor has jumped to the first line in the original window
:windo echo line('.')
1
96

regards
Loading...