Hi, Enno schrieb am 02.12.2014 um 16:13: > Le mardi 2 décembre 2014 15:34:09 UTC+1, Enno a écrit : >> Le lundi 1 décembre 2014 12:39:10 UTC+1, [email protected] a écrit : >>> Status: New >>> Owner: ---- >>> Labels: Type-Defect Priority-Medium >>> >>> New issue 290 by [email protected]: gVim does not jump to given >>> linennumber if already at end of file >>> https://code.google.com/p/vim/issues/detail?id=290 >>> >>> 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. >>> >>> >>> >>> -- >>> You received this message because this project is configured to send all >>> issue notifications to this address. >>> You may adjust your notification preferences at: >>> https://code.google.com/hosting/settings >> >> Thanks again, it is indeed only >> >> nnoremap : , >> >> that causes the issue in editexisting.vim and your fix resolves it. >> >> 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
here is a summary of what I guess from reading the editexisting.vim script and searching through the help files. I did not look at the actual source code. If the variable v:swapcommand is defined its content is sent to the already running server in line 55 of editexisting.vim. After that its content is executed as a normal mode command, this time by the server in line 115 of editexisting.vim. First I did not understand how this would relate to the +1 argument you provided on the second call of gvim, but after reading through the results of :helpgrep v:swapcommand (especially the one in version7.txt for patch 7.0.219) I think I understand it now: First Vim detects that a swap file exists. From the first + or -c command line argument it constructs a normal mode command which can be sent to an already running server through a call of remote_expr(). In your case this means something like ":1<CR>" is constructed. The server receives this command and tries to execute it with the command exe "normal " . a:command in line 115 of editexisting.vim. Now, you have mapped ":" to mean "," and the :normal command (without the exclamation mark) takes normal mode mappings into account. Thus the actual command that is execute is ,1<CR> This command will fail in most cases because you probably have not executed one of the commands f, t, F, or T before. The fix is to use exe "normal! " . a:command in the editexisting.vim script instead. The exclamation mark tells the :normal command to disregard mappings and use the original meaning of the provided commands. > Even with your patched version and without the offending > > nnoremap : , > > there are issues: for example > > gvim -n -u ~\.vimrc.light +5 -c bd file.txt > > will work fine and delete the current buffer, but > > gvim -n -u ~\.vimrc.light +5 -c split file.txt > > does nothing. Expected: splits current window. > > Just as > > gvim -n -u ~\.vimrc.light +split file.txt > > that again works fine. Actually, I doubt the "-c bd" really worked. Even without it :buffers only lists one buffer after executing the second command. The summary for patch 7.0.219 also states that v:swapcommand is set to <quote>the first "+123" or "-c" command line argument</quote>. You can check which command is sent to the server if you insert the line echomsg 'a:comamnd = ' . a:command before or after line 115 of editexisting.vim. In my tests it was either ":5^M" or ":split^M", depending on which command I supplied as the first one. Regards, Jürgen -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. (Calvin) -- -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
