search

fanicy / vim

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

gVim does not jump to given linennumber if already at end of file #290

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. gvim +G file.txt
2. gvim +{linenumber} file.txt

What is the expected output? What do you see instead?
The cursor does not move but should move to the supplied line number.

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

gVim 7.4.514 on Windows 7 64bit.

Please provide any additional information below.

Original issue reported on code.google.com by enno.na...@gmail.com on 1 Dec 2014 at 11:38

GoogleCodeExporter commented 9 years ago 
Well, the confusion is that gvim +... file.txt waits for a normal mode command 
and not for an exe command as the Vim doc says. (So step 1. already builds upon 
this bug.)

Original comment by enno.na...@gmail.com on 1 Dec 2014 at 1:47

GoogleCodeExporter commented 9 years ago 
I don't understand your comment. gvim +... file.txt uses the supplied command 
as an ex command, not a normal-mode command. This is exactly as the Vim doc 
says. When I run your "gvim +G file.txt" command I get an error: "E492: Not an 
editor command: G". Furthermore, by default Vim does not remember the position 
a file was left in. So starting Vim, moving to the end of the file, closing 
Vim, re-opening Vim on the file, will by default start at the first line in the 
file, not the last line in the file. Your own customizations are moving the 
cursor to the previous position on Vim startup; if you're having problems with 
that movement, then that's a problem in your setup, not a problem in Vim.

Original comment by benjamin...@rockwellcollins.com on 1 Dec 2014 at 6:08

GoogleCodeExporter commented 9 years ago 
Vim 7.4 works correctly with +[<number>] here (if no number is given, Vim jumps 
to the last line number). I cannot reproduce the problem. Does it happen if you 
start vim -u NONE -N +2
?

Original comment by chrisbr...@googlemail.com on 1 Dec 2014 at 7:42

GoogleCodeExporter commented 9 years ago 
Thanks for your feedback. This was discussed on vim_dev at

https://groups.google.com/forum/#!topic/vim_dev/49jGSpM4I7I

The following minimal .vimrc.light allows for reproducing:

set nocompatible 
filetype plugin indent on 
syntax enable 

runtime! macros/editexisting.vim 

set nocompatible 
filetype plugin indent on 
syntax enable 

runtime! macros/editexisting.vim 

nnoremap : ,

--

It is unexpected that a normal mode mapping interferes because the user sends 
no normal mode key sequences in neither command 

 gvim -n -u ~/.vimrc.light -U NONE --servername GVIMTEST +5 file.txt 
 gvim -n -u ~/.vimrc.light -U NONE --servername GVIMTEST +1 file.txt

Original comment by enno.na...@gmail.com on 2 Dec 2014 at 4:05

GoogleCodeExporter commented 9 years ago 
See discussion at vim_dev mailing list 
https://groups.google.com/forum/#!topic/vim_dev/49jGSpM4I7I

So closing as invalid.

Original comment by chrisbr...@googlemail.com on 4 Dec 2014 at 9:44

GoogleCodeExporter commented 9 years ago 
Though using

  nnoremap : ,

without an accompanying mapping like

  nnoremap , :

to swap two keys is probably a bad idea, the actual reason for the
misbehaving lies in line 115 of editexisting.vim -- instead of

  exe "normal " . a:command

it should better read

    exe "normal! " . a:command

Original comment by jottka...@googlemail.com on 5 Dec 2014 at 7:20