Re: Concatenate two performed actions into one (to make it repeatable by '.' and undoable at once)
2014-04-06 23:09 GMT+04:00 Bram Moolenaar b...@moolenaar.net: Ben Fritz wrote: On Sunday, April 6, 2014 6:42:35 AM UTC-5, Bram Moolenaar wrote: The problem is that there will not be a standard way how to apply those two changes. If it's just two inserts after another it would be possible, but in general the cursor would have moved somewhere else and perhaps indent depends on the indent of another line. Most likely the solution lies in repeating what the plugin does by invoking the plugin again. Instead of trying to record and replay what the plugin ended up doing. So the redo buffer would contain whatever triggered the plugin, and redo would trigger the plugin again. How do these kind of plugins get triggered anyway? Insert mode mapping? Would be good to start with a relevant example. At its heart, this kind of plugin is an insert-mode mapping, where when you press ( you get () instead, with the cursor in between. To get it to work with the '.' operator, it also needs mappings for Esc and some other commands so it can invoke repeat.vim. But for undo/redo, there was not any known solution last I knew. I guess Justin may have found something as he posted earlier. I haven't seen it working in practice yet, I will probably try it out later this week. The difficulty is that EVERY cursor movement in insert-mode will break the undo sequence and there is no way around it. It would be nice to have some sort of movement command within a line that would not break the undo sequence, or an explicit command to join two arbitrary edits, or a command from normal mode that would start insert mode and join the resulting insert to the last undo in the chain. Adding these commands will make life more complicated. I think the solution would be to have a different kind of map, which indicates that undo is not to be split, and what the map results in should not be added to the redo buffer. Instead, what triggered the map is to be added to the redo buffer. So that redo-ing it will trigger the map again. This won't be easy, it probably requires adding markers in the typeahead buffer and redo buffer, but it's certainly better than adding a bunch of strange commands to move around without splitting undo/redo. Actually, vim already supports complicated undo/redo: say, if file was changed externally, Vim asks if it should reload it. If user answers yes, vim loads file, compare it with buffer contents, and all of changes are written as just single action. Here, when user wants to join several actions, we need for the same, plus repeating it with a dot. About repeating with a dot: repeat.vim is not an option here: it is useful when I have exact mapping to be repeated. But here I must repeat all that user typed before plugin pressed Left key, and after it too, so, I have to remap all the thousand ways of quitting insert mode, and then give to repeat.vim all that user just typed. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: German Spellfile Session management
Am Freitag, 4. April 2014 23:00:22 UTC+2 schrieb Enno: Am Freitag, 4. April 2014 16:50:37 UTC+2 schrieb Bram Moolenaar: Enno Nagel wrote: Le vendredi 28 mars 2014 23:31:51 UTC+1, Enno a écrit : When restoring a session with spelllang=de, encoding = utf-8 and a nonempty german spellfile de.utf-8.add , the de.utf-8.spl is not read. This problem does not occur when - set spell spelllang=de is invoked manually, - for other languages. Tested for English and Portuguese. This might be caused by vim automatically storing the user dictionary in this format: setlocal spellfile=~\\.vim\\spell\\de.utf-8.add Even if the explicit path to the home dir is given. So can you remove the problem by editing that line? I would be surprised, unless you change your home directory, which is unexpected. I add that I have to set the spellfile explicitely, because I use Vundle, which otherwise would place it in the vundle folder. It works without a problem if not restoring sessions though. What if you manually edit a session file, can you fix the problem? -- In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, The Hitchhiker's Guide to the Galaxy has already supplanted the great Encyclopedia Galactica as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older, more pedestrian work in two important respects. First, it is slightly cheaper; and second, it has the words DON'T PANIC inscribed in large friendly letters on its cover. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// @Bram: I cannot fix the problem by hardcoding the path. The path is automatically encoded to set spellfile+=~/.vim/spell/de.utf-8.add , even if set explicitely in the makeview file, as checked by Set Spellfile. The problem occurs only as soons as I change Spelllang by a Loadview command. Otherwise it works fine. @Christian: The path is correct but has to be explicitely set by the user if Vundle is used. Vundle sets Spellfile to the .vim/bundle/vundle folder. It would be good if one could set a spellfile dictionary in vim. This Vundle issue https://github.com/gmarik/Vundle.vim/issues/127 describes the issue. I meant spellfile directory, not dictionary. See also https://github.com/gmarik/Vundle.vim/issues/417 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
vim crash when refer result via systemlist()
systemlist() that added on 7.4.248 make incorrect reference of list. Below is a patch. Please check and include. diff -r dd44a527c2bd src/eval.c --- a/src/eval.cSun Apr 06 21:34:04 2014 +0200 +++ b/src/eval.cWed Apr 09 19:05:42 2014 +0900 @@ -18356,6 +18356,7 @@ list_append(list, li); } + ++list-lv_refcount; rettv-v_type = VAR_LIST; rettv-vval.v_list = list; list = NULL; -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim crash when refer result via systemlist()
Ah, sorry I was confused. But this contains a bug. I'll write a patch soon. -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim crash when refer result via systemlist()
STRCPY/STRNCPY doesn't copy bytes after 0x00. diff -r dd44a527c2bd src/eval.c --- a/src/eval.cSun Apr 06 21:34:04 2014 +0200 +++ b/src/eval.cWed Apr 09 19:53:47 2014 +0900 @@ -18319,7 +18319,7 @@ char_u *s = NULL; char_u *start; char_u *end; - char_u *p; + char_u *p, *t; int i; res = get_cmd_output(get_tv_string(argvars[0]), infile, @@ -18337,13 +18337,13 @@ for (end = start; i len *end != NL; ++end) ++i; - s = vim_strnsave(start, (int)(end - start)); + s = alloc((unsigned)(end - start + 1)); if (s == NULL) goto errret; - for (p = s, end = s + (end - start); p end; ++p) - if (*p == NUL) - *p = NL; + for (p = s, end = s + (end - start), t = start; p end; ++p, ++t) + *p = *t == NUL ? NL : *t; + *p= NUL; li = listitem_alloc(); if (li == NULL) @@ -18356,6 +18356,7 @@ list_append(list, li); } + ++list-lv_refcount; rettv-v_type = VAR_LIST; rettv-vval.v_list = list; list = NULL; -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim crash when refer result via systemlist()
Yasuhiro Matsumoto wrote: systemlist() that added on 7.4.248 make incorrect reference of list. Below is a patch. Please check and include. Thanks! -- I started out with nothing, and I still have most of it. -- Michael Davis -- Tonight Show /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
SL6.4: can't compile os_unix.c due to patch#238
Hello: I'm getting some compiler errors with Scientific Linux 6.4: os_unix.c|2879 error| 'XATTR_NAME_SMACK' undeclared (first use in this function) os_unix.c|2879 error| (Each undeclared identifier is reported only once os_unix.c|2879 error| for each function it appears in.) os_unix.c|2880 error| 'XATTR_NAME_SMACKEXEC' undeclared (first use in this function) os_unix.c|2881 error| 'XATTR_NAME_SMACKMMAP' undeclared (first use in this function) This is configured with: ./configure --with-features=huge --enable-gui=yes --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-rubyinterp Regards, Chip Campbell -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: SL6.4: can't compile os_unix.c due to patch#238
On Wed, Apr 9, 2014 at 4:07 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: Hello: I'm getting some compiler errors with Scientific Linux 6.4: This is configured with: ./configure --with-features=huge --enable-gui=yes --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-rubyinterp You can get around this by adding --disable-smack on the configure line. Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: VIM 7.4.244 Fails to Compile on Red Hat Enterprise Linux Server release 5.9 (Tikanga)
On Saturday, 5 April 2014 20:02:23 UTC+1, Bram Moolenaar wrote: Ed Brown wrote: I'm not an autotools expert by any stretch of the imagination. I've not included a patch. But here are the details: undefining HAVE_SMACK in config.h does fix the issue. ./configure --prefix=/usr/local --enable-perlinterp --enable-tclinterp --enable-pythoninterp --with-python-config-dir=/usr/local/lib/python2.7/config --with-features=huge gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/os_unix.o os_unix.c os_unix.c: In function ‘mch_copy_sec’: os_unix.c:2820: error: ‘XATTR_NAME_SMACK’ undeclared (first use in this function) os_unix.c:2820: error: (Each undeclared identifier is reported only once os_unix.c:2820: error: for each function it appears in.) os_unix.c:2821: error: ‘XATTR_NAME_SMACKEXEC’ undeclared (first use in this function) os_unix.c:2822: error: ‘XATTR_NAME_SMACKMMAP’ undeclared (first use in this function) make[1]: *** [objects/os_unix.o] Error 1 make[1]: Leaving directory `/users/wcadmin/eb15792/vim-7.4.244/src' make: *** [first] Error 2 Configure checks for the linux/xattr.h file to exist. Does yours not contain XATTR_NAME_SMACK, XATTR_NAME_SMACKEXEC and XATTR_NAME_SMACKMMAP? What does it define then? Or what other include file defines them? -- If you put 7 of the most talented OSS developers in a room for a week and asked them to fix a bug in a spreadsheet program, in 1 week you'd have 2 new mail readers and a text-based web browser. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// I have the same problem on Scientific Linux 6.4 (based on RHEL 6.4). I have attached my /usr/include/linux/xattr.h file, which doesn't define the macros you referenced. A quick grep in this directory suggests that these macros are not defined anywhere... -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. /* File: linux/xattr.h Extended attributes handling. Copyright (C) 2001 by Andreas Gruenbacher a.gruenbac...@computer.org Copyright (c) 2001-2002 Silicon Graphics, Inc. All Rights Reserved. Copyright (c) 2004 Red Hat, Inc., James Morris jmor...@redhat.com */ #ifndef _LINUX_XATTR_H #define _LINUX_XATTR_H #define XATTR_CREATE 0x1 /* set value, fail if attr already exists */ #define XATTR_REPLACE 0x2 /* set value, fail if attr does not exist */ #endif /* _LINUX_XATTR_H */
Re: Issue 215 in vim: ft=sh highlighting thinks . is a valid character in variable names.
Updates: Status: Started Owner: drc...@campbellfamily.biz Comment #6 on issue 215 by drc...@campbellfamily.biz: ft=sh highlighting thinks . is a valid character in variable names. http://code.google.com/p/vim/issues/detail?id=215 Please try syntax/sh.vim v133, available at my website as http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH I haven't inflicted it on Bram and the broader vim community yet, so I'm still entertaining feedback on it. Gary: g:sh_noisk affects whether or not syntax/sh.vim will change isk for that buffer. When one does a dw while atop a foo.bar using ksh, one wants foo.bar to be deleted, not just the foo or bar. It doesn't affect shVariable highlighting, as your experiments noted. ewtoombs: you have a common misperception about the popularity of bash vs ksh; although bash is more common than ksh, posix is largely the same as ksh, and hence shares (mostly) the same highlighting as does ksh. The posix shell is also very popular. -- 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 215 in vim: ft=sh highlighting thinks . is a valid character in variable names.
Comment #7 on issue 215 by gary@gmail.com: ft=sh highlighting thinks . is a valid character in variable names. http://code.google.com/p/vim/issues/detail?id=215 Thanks for the new version. With syntax/sh.vim v133, the line FOO.BAR=hello (without the quotes) has only BAR highlighted. However, the line FOO,BAR=hello has all of FOO,BAR highlighted as shVariable. A bash variable name cannot contain a comma, either. Regards, Gary -- 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Issue 218 in vim: gVim docked window in Windows 7 rebounding on vsplit
Status: New Owner: Labels: Type-Defect Priority-Medium New issue 218 by gmagg...@gmail.com: gVim docked window in Windows 7 rebounding on vsplit http://code.google.com/p/vim/issues/detail?id=218 Hello, I'm using gVim 7.4 on Windows 7 and it happens this to me this: 1. I launch gVim -u NONE and an OS-window opens at (let's call it so) initial position 2. I press WinL + left to position/accomodate the gVim OS-window on the left half side of the monitor (using Windows 7's window manager docking feature) 3. I :vsplit, which also leads to a new scrollbar appearing on the left. At the same time this makes the gVim OS-windows to rebound, detaching from the Monitor left side and returning to the initial position Thanks and greetings -- 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 215 in vim: ft=sh highlighting thinks . is a valid character in variable names.
Comment #8 on issue 215 by drc...@campbellfamily.biz: ft=sh highlighting thinks . is a valid character in variable names. http://code.google.com/p/vim/issues/detail?id=215 Thanks, Gary -- I'm not sure why that comma was there, even for the ksh/posix shells. So, its gone! Well, in v134, anyway. -- 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 -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: SL6.4: can't compile os_unix.c due to patch#238
Christ van Willegen wrote: On Wed, Apr 9, 2014 at 4:07 PM, Charles Campbell charles.e.campb...@nasa.gov wrote: Hello: I'm getting some compiler errors with Scientific Linux 6.4: This is configured with: ./configure --with-features=huge --enable-gui=yes --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-rubyinterp You can get around this by adding --disable-smack on the configure line. Thank you -- vim now compiles, but this situation should really be handled by configure. Regards, Chip Campbell -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
.git Overhead in Vim Plugins
I found that the script in my plugins take up a fairly small space compared to the .git folder during a disk cleanup. Though it is still small enough for it to be ignored during the process, I wonder what can be done to trim it. For example, syntastic. The .git folder is 3.2 MB, while the plugin itself is only 0.8 MB altogether, only 1/4 of the .git folder. An extreme example would be unite.vim, whose .git folder is 8.8 MB but its latest content is only 0.9 MB. I use Windows 8 and it boots on a 60 GB SSD, so although this is not troublesome at the time, it still bothers me a bit. How fast does this ratio grow? Can I configure git or Neobundle or Vundle to trim it down instead of manually (or with script) deleting all the .git folder myself? What's the risk of deleting them besides loss of commit history? Thank you, Lou Yufan -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
