search

ydjia / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

pedit changes cursor position when BufReadPre autocmd defined #313

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start Vim with gvim -N -u NONE -i NONE
2. Source the following minimal .vimrc:

fun! DoNothing()
  return
endfun
augroup TEST
  au!
  autocmd BufReadPre * call DoNothing()
augroup END

3. Edit a file that spans multiple screens (i.e. requires scrolling to view the 
bottom of the file).
4. Go to last line in file with G command.
5. :pedit %

What is the expected output? What do you see instead?
Expected output: file is split, with cursor on last line of the file, in the 
bottom window. Top window is a preview window showing the last line of the file.

Actual output: file is split, with cursor on FIRST line of the file, in the 
bottom window. Top window is a preview window showing the last line of the file.

What version of the product are you using? On what operating system?

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 15 2014 11:39:32)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-552
Compiled by {me}
Huge version with GUI.  Features included (+) or not (-):

Please provide any additional information below.

Note that removing the autocmd in the minimal .vimrc shows the expected 
behavior rather than the problem behavior. :pedit % is not required, just that 
the file being previewed is already open in another window. I first saw this 
happening with the autopreview feature of the TagBar plugin.

Original issue reported on code.google.com by fritzoph...@gmail.com on 12 Jan 2015 at 10:23

GoogleCodeExporter commented 9 years ago 
Are you sure the description of what you're seeing is correct?  The behavior 
I'm seeing is that the cursor is still on the last line of the buffer, but the 
last line of the buffer is now being displayed at the top of the bottom window.

That is, before ":pedit %", the cursor and last line of the buffer are at the 
bottom of the, at this point, only window.  After ":pedit %", the cursor and 
last line of the buffer are at the top of the bottom window and the last line 
of the buffer is at the bottom of the preview window.

Original comment by vega.james@gmail.com on 13 Jan 2015 at 12:21

GoogleCodeExporter commented 9 years ago 
Yes. On my machine, after the :pedit %, I see the copyright notice at the top 
of my 1400-line file, in the bottom window. In the top (preview) window I still 
see the bottom of the file where I had my cursor prior to the :pedit command. 
While stepping through at one point I saw the cursor at line 1 in window 1 when 
I used line('.') and winnr() in echo commands. I don't remember the exact 
details, however.

Original comment by fritzoph...@gmail.com on 13 Jan 2015 at 3:07

GoogleCodeExporter commented 9 years ago 
Same behavior (bottom window set to cursor on line 1, top window a preview 
window set to cursor on last line where it started) in the Vim on my home 
computer, starting from gvim -N -u NONE -i NONE and sourcing the minimal script:

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Feb 17 2014 21:27:42)
MS-Windows 32-bit GUI version
Included patches: 1-183
Compiled by {me}
Huge version with GUI.  Features included (+) or not (-):

Original comment by fritzoph...@gmail.com on 13 Jan 2015 at 3:11

GoogleCodeExporter commented 9 years ago 
I am not sure, why this happens only when an autocommand is defined, but this 
patch saves and restores the cursor position.

Original comment by chrisbr...@googlemail.com on 13 Jan 2015 at 6:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Confirmed, this seems to fix the issue.

It sounds like it's more of a band-aid than a fix, though?

Oh well, a band-aid is enough for me until an official patch comes out. :-)

Original comment by fritzoph...@gmail.com on 13 Jan 2015 at 9:15

GoogleCodeExporter commented 9 years ago 
I discovered today that although the cursor position is thankfully fixed by the 
patch, there is still an error message that pops up if my buffer is modified.

Original comment by fritzoph...@gmail.com on 15 Jan 2015 at 10:04

GoogleCodeExporter commented 9 years ago 
The error is expected since you're trying to :edit a modified buffer.

Original comment by vega.james@gmail.com on 16 Jan 2015 at 1:21

GoogleCodeExporter commented 9 years ago 
Except the buffer is already loaded so it is more like a split. AFAIK there is 
no way to open a preview window on the current buffer without triggering the 
error. and you're always opening a split so it won't be abandoning it.

Original comment by fritzoph...@gmail.com on 16 Jan 2015 at 2:37