Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Ingo Karkat
    ... Thanks a lot. ... 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
    Message 1 of 4 , Jul 1, 2008
    • 0 Attachment
      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
      -~----------~----~----~----~------~----~------~--~---
    • mMontu
      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
      Message 2 of 4 , Apr 22, 2014
      • 0 Attachment
        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



        --
        View this message in context: http://vim.1045645.n5.nabble.com/BUG-BufReadPre-autocmd-changes-cursor-position-on-pedit-tp1206965p5721472.html
        Sent from the Vim - Dev mailing list archive at Nabble.com.

        --
        --
        You received this message from the "vim_dev" 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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/d/optout.
      Your message has been successfully submitted and would be delivered to recipients shortly.