gVim 7.2 --remote-tab-silent command line interpretation bug
Hi!
If I'm trying to open a file like this:
gvim.exe --remote-tab-silent c:\MP3\XXX\LIZA MINNELLI\(1989)
RESULTS\info.txt
gVim tries to open \MP3\XXX\LIZA MINNELLI(1989) RESULTS\info.txt
resulting in a new file.
If I'm trying to open the same file without the --remote-tab-silent
option the info.txt file is opened as expected.
It seems, when the --remote-tab-silent option is used, the '\('
combination is counted as an escape-sequence, and this is wrong.
Can we consider this as a bug?
gVim 7.2, Win Vista HP SP1.
--
Best regards,
Valery Kondakoff
PGP key:
http://pool.sks-keyservers.net:11371/pks/lookup?op=getsearch=0xEEDF8590
np: Liza Minnelli'1989 (Results) - Rent
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: gVim 7.2 --remote-tab-silent command line interpretation bug
I usually use right button menu to open file in new tab, try this:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\*\shell\Edit with Vim(V)]
[HKEY_CLASSES_ROOT\*\shell\Edit with Vim(V)\command]
@=\D:\\Program Files\\Vim\\vim72\\gvim.exe\ -p --remote-tab-silent \%1\
\%*\
---
save as *.reg then import.
--
Hi!
If I'm trying to open a file like this:
gvim.exe --remote-tab-silent c:\MP3\XXX\LIZA MINNELLI\(1989)
RESULTS\info.txt
gVim tries to open \MP3\XXX\LIZA MINNELLI(1989) RESULTS\info.txt
resulting in a new file.
If I'm trying to open the same file without the --remote-tab-silent
option the info.txt file is opened as expected.
It seems, when the --remote-tab-silent option is used, the '\('
combination is counted as an escape-sequence, and this is wrong.
Can we consider this as a bug?
gVim 7.2, Win Vista HP SP1.
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Fix for crash in eval.c
Hi Bram On 05.05.2009, at 03:41, Bram Moolenaar wrote: Nico Weber wrote: Valgrind memory checker finds several errors in vim-7.2 (patches 1-148) with the reproduction steps described at http://groups.google.com/group/vim_mac/browse_thread/thread/4e0149ff4f84e3d3 : ==33469== Invalid read of size 4 ==33469==at 0x2D451: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) ==33469== ==33469== Invalid write of size 4 ==33469==at 0x2D459: dict_unref (eval.c:6709) ==33469==by 0x3E4E7: clear_tv (eval.c:18558) ==33469==by 0x3F09B: vars_clear_ext (eval.c:18994) ==33469==by 0x4382B: free_funccal (eval.c:21466) ==33469==by 0x2D240: garbage_collect (eval.c:6595) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469== Address 0x7c290f0 is 0 bytes inside a block of size 176 free'd ==33469==at 0x25661B: free (vg_replace_malloc.c:322) ==33469==by 0xCDBDC: vim_free (misc2.c:1638) ==33469==by 0x2D59B: dict_free (eval.c:6753) ==33469==by 0x2D176: garbage_collect (eval.c:6559) ==33469==by 0x8D92E: before_blocking (getchar.c:1473) ==33469==by 0x10764F: mch_inchar (os_unix.c:385) ==33469==by 0x176A06: ui_inchar (ui.c:193) ==33469==by 0x8FFD1: inchar (getchar.c:2959) ==33469==by 0x8FB64: vgetorpeek (getchar.c:2735) ==33469==by 0x8DAA3: vgetc (getchar.c:1552) ==33469==by 0x8E05D: safe_vgetc (getchar.c:1757) ==33469==by 0xDC89D: normal_cmd (normal.c:653) I'm very glad you managed to pinpoint the problem and fix it. I'll check the details and include the patch. Thanks! as Dominique pointed out, while this patch fixes a double free(), it introduces a memory leak. The leak is smaller in the improved patch, but it's still there. Now, a leak is arguably better than a crash, but I wouldn't include this patch yet :-/ If you happen to know why the dicts copied by foo.vim are not freed with the second version of my patch, that would be great. Else, I will take another look next weekend. Nico --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
On May 4, 10:50 pm, Dominique Pellé dominique.pe...@gmail.com wrote: _Lone wrote: On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote: _Lone wrote: I have modified the patch. The name is now margincolumn. The behavior is: 'mc' = 0 - off 'mc' 0 - highlightes the column. 'mc' 0 - makes 'mc' = 'tw + 1' and highlightes that column. I also updated the related documentation is option.txt. Thanks _Lone I've tested your updated patch with Vim-7.2.166 on Linux x86. So far it works as it should. No problem to report. I also think that the idea mentioned earlier in this thread to support multiple margincolumns is a good one. For example:set mc=40,80 It can be handy when editing files with multiple columns. Thanks -- Dominique Hi Dominique, Could you please try cursor column without the patch and see what that does? I implemented the margincolumn to behave similar to cursorcolumn so I think they both would behave the same. But still it would be good to check without margincolumn patch to make sure there is no regression. I am not sure how to handle multi-byte characters. My experience is limited with that. Anyone has any suggestions? Thanks _Lone Confirmed: Pristine Vim-7.2.166 has the same odd behavior when doing :set cuc with characters using 2 display cells (utf-8 on Linux with xterm as well as with gvim (GTK2). So this behavior is not introduced by the margincolumn patch. See this screenshot with gvim-7.2.166 GTK2: http://dominique.pelle.free.fr/pic/gvim-cuc.png cursorcolumn is supposed to be highlighted in grey. The cuc is not highlighted in some lines. The red square at the top is the location of the cursor. -- Dominique- Hide quoted text - - Show quoted text - Thanks for the confirmation that this is not a regression. I feel that multi-column character bug needs to be fixed separately and it would be a little tricky to fix this because of the way 'cursorcolumn' highlighting works. Bram - Does the 'margincolumn' patch fits the need? If there is any other feedback please let me know? The following are the two things that probably needs to be considered in future: 1. Highlighting of multi-column characters for both CUC and MC. 2. Support for margin-column to contain multiple values to highlight various columns. Thanks _Lone --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
Dennis Benzinger wrote: Am 01.05.2009 21:23, Matt Wozniski schrieb: [...] I agree. I think that 'guidecolumn' is a much better name. [...] Me too. Also, I agree with Gary - it's not inconceivable that someone might want two guides at different spots representing different things, which would mean that the margincolumn name is much more misleading. [...] Because of the possibility to support multiple guides I suggest using a string option with comma separated values. For example: :set guidecolumn=10,15,20,tw,wm tw and wm would set a guide at textwidth resp. wrapmargin. This makes it easy to add and remove guides with -= and +=. And then of course also make it possible to set the color for each column separately. And how about setting the column two characters before 'textwidth'? There are always more features to ask for. Let's stick to one column. -- A hamburger walks into a bar, and the bartender says: I'm sorry, but we don't serve food here. /// Bram Moolenaar -- b...@moolenaar.net -- 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 -~--~~~~--~~--~--~---
comma in $HOME bug?
Vim doesn't seem to handle a comma in $HOME at all. In this case, $HOME = /u/hordijk,spin strace shows that Vim seems to be doing some odd parsing around the comma: stat64(/u/hordijk/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) stat64(spin/.vim/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) Anybody else experience a similar issue, or I am the only one with a comma in their homedir? :) - michael --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: comma in $HOME bug?
On Tue, May 5, 2009 at 12:50 PM, Michael Hordijk wrote: Vim doesn't seem to handle a comma in $HOME at all. In this case, $HOME = /u/hordijk,spin strace shows that Vim seems to be doing some odd parsing around the comma: stat64(/u/hordijk/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) stat64(spin/.vim/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) Anybody else experience a similar issue, or I am the only one with a comma in their homedir? :) Vim uses a comma separated list of directories to search for runtime files. Your home directory is added to that list, but appears as two elements instead of one, because of the comma in it. I doubt there's any way to get around this. You *might* be able to hack things to make it work, but it would be ugly. In general, I would think that comma is one of those strange characters that you shouldn't embed in $HOME, like : and ; ~Matt --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Add support for guidecolumn in VIM
Pankaj Garg wrote: On May 4, 10:50 pm, Dominique Pellé dominique.pe...@gmail.com wrote: _Lone wrote: On May 2, 11:32 pm, Dominique Pellé dominique.pe...@gmail.com wrote: _Lone wrote: I have modified the patch. The name is now margincolumn. The behavior is: 'mc' = 0 - off 'mc' 0 - highlightes the column. 'mc' 0 - makes 'mc' = 'tw + 1' and highlightes that column. I also updated the related documentation is option.txt. Thanks _Lone I've tested your updated patch with Vim-7.2.166 on Linux x86. So far it works as it should. No problem to report. I also think that the idea mentioned earlier in this thread to support multiple margincolumns is a good one. For example:set mc=40,80 It can be handy when editing files with multiple columns. Thanks -- Dominique Hi Dominique, Could you please try cursor column without the patch and see what that does? I implemented the margincolumn to behave similar to cursorcolumn so I think they both would behave the same. But still it would be good to check without margincolumn patch to make sure there is no regression. I am not sure how to handle multi-byte characters. My experience is limited with that. Anyone has any suggestions? Thanks _Lone Confirmed: Pristine Vim-7.2.166 has the same odd behavior when doing :set cuc with characters using 2 display cells (utf-8 on Linux with xterm as well as with gvim (GTK2). So this behavior is not introduced by the margincolumn patch. See this screenshot with gvim-7.2.166 GTK2: http://dominique.pelle.free.fr/pic/gvim-cuc.png cursorcolumn is supposed to be highlighted in grey. The cuc is not highlighted in some lines. The red square at the top is the location of the cursor. -- Dominique- Hide quoted text - - Show quoted text - Thanks for the confirmation that this is not a regression. I feel that multi-column character bug needs to be fixed separately and it would be a little tricky to fix this because of the way 'cursorcolumn' highlighting works. Bram - Does the 'margincolumn' patch fits the need? If there is any other feedback please let me know? The following are the two things that probably needs to be considered in future: 1. Highlighting of multi-column characters for both CUC and MC. 2. Support for margin-column to contain multiple values to highlight various columns. I don't have time to look into this soon, thus use comments from others. This is a new feature and needs a bit of trying out anyway. The wide character problem is a separate one. But if you can solve it for 'cuc' as well that would be nice. -- ROBIN: The what? ARTHUR: The Holy Hand Grenade of Antioch. 'Tis one of the sacred relics Brother Maynard always carries with him. ALL:Yes. Of course. ARTHUR: (shouting) Bring up the Holy Hand Grenade! Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@moolenaar.net -- 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 -~--~~~~--~~--~--~---
Re: comma in $HOME bug?
On 05/05/2009 01:04 PM, Matt Wozniski wrote: On Tue, May 5, 2009 at 12:50 PM, Michael Hordijk wrote: Vim doesn't seem to handle a comma in $HOME at all. In this case, $HOME = /u/hordijk,spin strace shows that Vim seems to be doing some odd parsing around the comma: stat64(/u/hordijk/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) stat64(spin/.vim/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) Anybody else experience a similar issue, or I am the only one with a comma in their homedir? :) Vim uses a comma separated list of directories to search for runtime files. Your home directory is added to that list, but appears as two elements instead of one, because of the comma in it. I doubt there's any way to get around this. You *might* be able to hack things to make it work, but it would be ugly. In general, I would think that comma is one of those strange characters that you shouldn't embed in $HOME, like : and ; Of course, that would be very unfortunate, as we do some things with automount and such that comma's are in a lot of directory names. In the three years of working with this, Vim is the first application that seems to have a problem with it. That being said, normally when an application has a problem with certain characters in a string, said characters are escaped before they're used. Some parts of Vim work fine with HOME='/u/hordijk\,spin' but then other parts break. I'm thinking that Vim, if it finds a comma in $HOME, should escape it before adding it to an internal structure that it expects to be comma delimited. If Vim has a concept of escaping, then it should be easy. If not, it would probably be more involved. - michael --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: comma in $HOME bug?
Michael Hordijk wrote: On 05/05/2009 01:04 PM, Matt Wozniski wrote: On Tue, May 5, 2009 at 12:50 PM, Michael Hordijk wrote: Vim doesn't seem to handle a comma in $HOME at all. In this case, $HOME = /u/hordijk,spin strace shows that Vim seems to be doing some odd parsing around the comma: stat64(/u/hordijk/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) stat64(spin/.vim/syntax/synload.vim, 0xbfa03e9c) = -1 ENOENT (No such file or directory) Anybody else experience a similar issue, or I am the only one with a comma in their homedir? :) Vim uses a comma separated list of directories to search for runtime files. Your home directory is added to that list, but appears as two elements instead of one, because of the comma in it. I doubt there's any way to get around this. You *might* be able to hack things to make it work, but it would be ugly. In general, I would think that comma is one of those strange characters that you shouldn't embed in $HOME, like : and ; Of course, that would be very unfortunate, as we do some things with automount and such that comma's are in a lot of directory names. In the three years of working with this, Vim is the first application that seems to have a problem with it. That being said, normally when an application has a problem with certain characters in a string, said characters are escaped before they're used. Some parts of Vim work fine with HOME='/u/hordijk\,spin' but then other parts break. I'm thinking that Vim, if it finds a comma in $HOME, should escape it before adding it to an internal structure that it expects to be comma delimited. If Vim has a concept of escaping, then it should be easy. If not, it would probably be more involved. The special characters in $HOME should indeed be escaped. I can only think of a comma being special here. You can work around it by explicitly setting the options that use $HOME in their default value. -- An indication you must be a manager: You believe you never have any problems in your life, just issues and improvement opportunities. /// Bram Moolenaar -- b...@moolenaar.net -- 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 -~--~~~~--~~--~--~---
Small change to i_CTRL-X_CTRL-L documentation
The attached patch to Vim's documentation mentions when it is possible to insert consecutive lines by pressing CTRL-X CTRL-L repeatedly. -- Cheers, Lech --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~--- diff --git a/runtime/doc/insert.txt b/runtime/doc/insert.txt index c4910a2..f73b6f9 100644 --- a/runtime/doc/insert.txt +++ b/runtime/doc/insert.txt @@ -661,7 +661,8 @@ CTRL-X CTRL-L Search backwards for a line that starts with the CTRL-N Search forward for next matching line. This line replaces the previous matching line. - CTRL-X CTRL-L After expanding a line you can additionally get the + CTRL-X CTRL-L After expanding a line, if the line has been completed + from a loaded buffer, you can additionally get the line next to it by typing CTRL-X CTRL-L again, unless a double CTRL-X is used.
