Bug in Vim window height calculation with 'winfixheight'
Hi, I see the following problem with the 'winfixheight' option. 1. Open two vertically split windows :vsplit 2. Open a horizontally split window with the 'winfixheight' option: :botright 5new :setlocal winfixheight 3. Open another horizontally split window and close it: :botright new :close Repeat step 3 few times. You will notice that every time the window is closed, the height of the window with the 'winfixheight' option will increase. I expected that the height of this window will remain the same. This problem is not seen if instead of two windows at the top, only one window is used in the above steps. I see the above problem using Vim 7.2. - Yegappan -- 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
Re: Multiple conceals collapse to single character
Bram Moolenaar wrote:
Charles Campbell wrote:
I tried the following trick:
syn match texGreek '\\alpha\>' contained conceal cchar=á nextgroup=texGreek2
syn match texGreek2 '\\alpha\>' contained conceal cchar=á nextgroup=texGreek
So $\alpha\alpha$ has the first \alpha as texGreek, and the second one
as texGreek2 . Unfortunately, although the syntax highlighting treated
the two differently, the conceal code still merges the two, using only
the one á instead of what I'd hoped (áá).
Makes sense. We can get the ID of the syntax item, and use a change in
that as a signal to display the conceal character.
I have implemented that, please try it out and let us know.
If this doesn't work as intended, we should roll it back.
Soon we can't make incompatible changes, thus please let's figure out
how this should work very soon!
Hello, Bram!
I've attached a modified syntax/tex.vim which makes a start at
supporting Greek, subscripts, and superscripts. Its not complete:
* I haven't supported a^{b*c} for example; I'll have to try making
regions for superscripts and for subscripts. Probably I can do
something about this.
* Some symbols just aren't available via utf-8; for example, Euler's
equation: e^{i \pi} = -1 ; there's no superscripted or subscripted
Greek available. (AFAIK)
* Subscripts are even more restrictive in utf-8; there's a good set of
superscripted a-zA-W (missing the q and Q, though), but for scripts,
only aeiou and 0-9 are available (again, AFAIK).
* I haven't begun accent support; I think utf-8 does a very good job of
supporting accented characters, and that's next on my expanding list
of things to do for syntax/tex.vim
This trick doubles the amount of syntax rules, of course, so IMHO its
not ideal, but its working! Thank you for the modification.
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
Re: [patch] fixed memory leak in :find
2010/7/23 Dominique Pellé : > Hi > > I see a memory leak in Vim-7.3b BETA (2376:878562053ba3) > when doing :find I knew you would! > Fixed in attached patch. > > -- Dominique Thanks for fixing my leak :) btw, I'm still working on fixing the issues mentioned in [1] that is related to the find/sfind/tabfind completion. nazri. [1] http://article.gmane.org/gmane.editors.vim.devel/27120 -- 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
Re: Patch to support horizontal mouse wheel
On Jul 20, 2010, at 3:58 PM, björn wrote: > Bram: could you indicate if there is any chance this is making it for > 7.3 (or at all)? It seems this feature would mostly be used by Mac > users (since "all" Macs have horizontal scrolling abilities) and a few > users have asked for this feature. If you'd rather hold off merging > this patch I'll merge it with the MacVim source code so that it gets > tested properly and then you can take a look at it later. Note that pretty much all Intel laptops w/ a Synaptics touchpad can do horizontal scrolling as well. Many newer mice do too. So I think it would be good to include it in mainline. Tom -- 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
Unsubscribe
Unsubscribe John Maclean MSc (DIC) blackberry PIN 222C6738 -- 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
cchar of conceal support multiple characters
I would love to see cchar support multiple characters, e.g. one could do: syntax match Indent '' conceal cchar=|\ \ \ syntax match Indent '' conceal cchar= to have something like lcs tab option with non-tabs. I can also see uses in LaTeX. Also currently, there is no mechanism to be able to put in a tab (space works as 'cchar= '). «$2» Matt Spear b...@google.com -- 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
conceal and cchar multiple characters, and tab failing
I would love to see cchar support multiple characters, e.g. one could do: syntax match Indent '' conceal cchar=|\ \ \ \ syntax match Indent '' conceal cchar=\ \ \ \ \ \ \ \ to have something like lcs tab option with non-tabs. I can also see uses in LaTeX. Also currently, there is no mechanism to be able to put in a tab (space works as 'cchar= '). -- 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
[patch] fixed memory leak in :find
Hi
I see a memory leak in Vim-7.3b BETA (2376:878562053ba3)
when doing :find
==5706== 88 bytes in 2 blocks are definitely lost in loss record 92 of 117
==5706==at 0x4024F70: malloc (vg_replace_malloc.c:236)
==5706==by 0x813778A: lalloc (misc2.c:920)
==5706==by 0x817C667: vim_regcomp (regexp.c:1063)
==5706==by 0x8135A9F: uniquefy_paths (misc1.c:9370)
==5706==by 0x8135FB8: gen_expand_wildcards (misc1.c:9587)
==5706==by 0x8134F6F: expand_wildcards (misc1.c:8568)
==5706==by 0x8134F1E: expand_wildcards_eval (misc1.c:8539)
==5706==by 0x80DF179: ExpandFromContext (ex_getln.c:4464)
==5706==by 0x80DEE62: expand_cmdline (ex_getln.c:4356)
==5706==by 0x80DE33A: showmatches (ex_getln.c:3858)
==5706==by 0x80DA4D3: getcmdline (ex_getln.c:1167)
==5706==by 0x80DBA38: getexline (ex_getln.c:2129)
==5706==by 0x80C5EAD: do_cmdline (ex_docmd.c:1018)
==5706==by 0x814DDE9: nv_colon (normal.c:5295)
==5706==by 0x814751F: normal_cmd (normal.c:1188)
==5706==by 0x8108F38: main_loop (main.c:1256)
==5706==by 0x810898F: main (main.c:964)
Fixed in attached patch.
-- Dominique
--
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
diff -r 878562053ba3 src/misc1.c
--- a/src/misc1.c Thu Jul 22 22:30:23 2010 +0200
+++ b/src/misc1.c Thu Jul 22 23:47:35 2010 +0200
@@ -9306,7 +9306,7 @@
}
/*
- * Remove adjecent duplicate entries from "gap", which is a list of file names
+ * Remove adjacent duplicate entries from "gap", which is a list of file names
* in allocated memory.
*/
static void
@@ -9354,7 +9354,7 @@
/*
* We need to prepend a '*' at the beginning of file_pattern so that the
* regex matches anywhere in the path. FIXME: is this valid for all
- * possible pattern?
+ * possible patterns?
*/
len = (int)STRLEN(pattern);
file_pattern = alloc(len + 2);
@@ -9391,6 +9391,7 @@
}
}
+vim_free(regmatch.regprog);
if (sort_again)
{
sort_strings(fnames, gap->ga_len);
Re: [patch] Titles for quickfix / location list windows
On 21-Jul-2010 Bram Moolenaar wrote:
>
> It would be possible to add a statusline item for this, like %h.
[...]
> Note that I'm including less changes now, and nothing that looks
> "dangerous" or needs to be discussed first.
I followed your excellent advice with a window variable. This made the
whole thing much simpler (the patch is almost 50% smaller than the
previous one).
Since you disliked the repeated code calling buf_spname(), I reverted
buf_spname() to the original shape, which means that no more memory
allocations are needed.
The only thing that is being done now is that the command which produces
a list of errors is remembered along with the quickfix list and when
a quickfix window is opened, the command name is copied to the
w:quickfix_title variable.
Since I also added a flag for the 'statusline' variable, I added a file
ftplugin/qf.vim, which sets 'statusline' for quickfix windows so that
the value of w:quickfix_title is displayed.
The patch is against changeset 878562053b.
--
Cheers,
Lech
--
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
diff --git a/runtime/doc/options.txt b/runtime/doc/options.txt
index 297939f..3ab472d 100644
--- a/runtime/doc/options.txt
+++ b/runtime/doc/options.txt
@@ -6499,6 +6499,7 @@ A jump table for the options with a short description can be found at |Q_op|.
y F Type of file in the buffer, e.g., "[vim]". See 'filetype'.
Y F Type of file in the buffer, e.g., ",VIM". See 'filetype'.
{not available when compiled without |+autocmd| feature}
+ q S "[Quickfix List]", "[Location List]" or empty.
k S Value of "b:keymap_name" or 'keymap' when |:lmap| mappings are
being used: ""
n N Buffer number.
diff --git a/runtime/doc/quickfix.txt b/runtime/doc/quickfix.txt
index d710e97..972ebd8 100644
--- a/runtime/doc/quickfix.txt
+++ b/runtime/doc/quickfix.txt
@@ -301,7 +301,7 @@ use this code: >
=
2. The error window *quickfix-window*
- *:cope* *:copen*
+ *:cope* *:copen* *w:quickfix_title*
:cope[n] [height] Open a window to show the current list of errors.
When [height] is given, the window becomes that high
(if there is room). Otherwise the window is made ten
@@ -310,7 +310,11 @@ use this code: >
'buftype' equal to "quickfix". Don't change this!
If there already is a quickfix window, it will be made
the current window. It is not possible to open a
- second quickfix window.
+ second quickfix window. The window will have the
+ w:quickfix_title variable set which will indicate the
+ command that produced the quickfix list. This can be
+ used to compose a custom status line if the value of
+ 'statusline' is adjusted properly.
*:lop* *:lopen*
:lop[en] [height] Open a window to show the location list for the
diff --git a/runtime/doc/tags b/runtime/doc/tags
index e36c6a4..1c870b5 100644
--- a/runtime/doc/tags
+++ b/runtime/doc/tags
@@ -8280,6 +8280,7 @@ vt100-function-keys term.txt /*vt100-function-keys*
w motion.txt /*w*
w32-clientserver remote.txt /*w32-clientserver*
w:current_syntax syntax.txt /*w:current_syntax*
+w:quickfix_title quickfix.txt /*w:quickfix_title*
w:var eval.txt /*w:var*
warningmsg-variable eval.txt /*warningmsg-variable*
white-space pattern.txt /*white-space*
diff --git a/runtime/ftplugin/qf.vim b/runtime/ftplugin/qf.vim
new file mode 100644
index 000..f1d0922
--- /dev/null
+++ b/runtime/ftplugin/qf.vim
@@ -0,0 +1,16 @@
+" Vim filetype plugin file
+" Language: Vim's quickfix window
+" Maintainer: Lech Lorens
+" Last Changed: 22 Jul 2010
+
+if exists("b:did_ftplugin")
+ finish
+endif
+
+" Don't load another plugin for this buffer
+let b:did_ftplugin = 1
+
+let b:undo_ftplugin = "setl stl<"
+
+" Display the command that produced the list in the quickfix window:
+setlocal stl=%q%{exists('w:quickfix_title')?\ '\ '.w:quickfix_title\ :\ ''}
diff --git a/src/buffer.c b/src/buffer.c
index a8808d3..191e2dd 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -3869,6 +3869,13 @@ build_stl_str_hl(wp, out, outlen, fmt, use_sandbox, fillchar, maxwidth, hltab, t
str = (char_u *)((opt == STL_PREVIEWFLAG_ALT) ? ",PRV"
: _("[Preview]"));
break;
+
+ case STL_QUICKFIX:
+ if (bt_quickfix(wp->w_buffer))
+ str = (char_u *)wp->w_llist_ref
+ ? _("[Location List]")
+ : _("[Quickfix List]");
+ break;
#endif
case STL_MODIFIED:
diff --git a/src/eval.c b/src/eval.c
index a819373..226705e 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -395,7 +395,6 @@ static void list_vim_vars __ARGS((int *first));
static void list_script_vars __ARGS((int *first));
static void list_func_vars __ARGS((int *first));
static char_u *list_arg_vars __ARGS((exarg_T *eap, char_u *arg, int *first));
-static char_u *ex_let_one __ARGS((char_u *a
Beep on exit
There appeared one annoying thing in vim-7.3 (starting even from alpha). Every time I quit the editor, it beeps. 1) 'visualbell' is set. 2) 't_vb' is reset. In fact, when I set it to A, I see that character is printed on excessive , but Vim still beeps on exit. 3) I'm sure this isn't about plugins and configuration, because vim-7.2 didn't beep, and I tried to remove .vim and .vimrc The system is Fedora 13. How can I debug the problem? What other piece of code can print BELL? -- 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
Re: What about Ruby 1.9 native support?
On Thu, Jul 22, 2010 at 5:25 PM, Ciss wrote: > Hello, can you include patch in vim, which add Ruby 1.9 support? > Ruby 1.9 5-10x faster then ruby 1.8 Ruby 1.9 support has been in Vim since 7.2 patch 361, although there were some initial problems so there were some patches released after that to clean things up. Building 7.2 with all the patches applied or 7.3 beta will give you ruby 1.9 support. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- 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
What about Ruby 1.9 native support?
Hello, can you include patch in vim, which add Ruby 1.9 support? Ruby 1.9 5-10x faster then ruby 1.8 -- 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
Re: Linking errors when compiled with both python and python3
On Thu, Jul 22, 2010 at 4:29 PM, Bram Moolenaar wrote: > > James Vega wrote: > >> On Thu, Jul 22, 2010 at 12:36:27AM -0700, Nico Raffo wrote: >> > If Vim is compiled with both --enable-pythoninterp and --enable- >> > python3interp, errors occur when importing many python modules. To >> > reproduce, compile as described then try something like: >> > >> > :py import termios >> > or >> > :py3 import termios >> > >> > Which gives the error: >> > >> > ImportError: /usr/lib/python3.1/lib-dynload/termios.so: undefined >> > symbol: PyExc_TypeError >> > >> > This doesn't happen with all modules. Mostly just those with odd .so >> > files. >> >> I had been meaning to check whether something like that would happen >> with the Python interfaces. I saw something similar when testing the >> Perl interface. Does the attached patch fix it? > > Thanks, I'll include it. It fixes the problem on my system. The attached patch corrects how DYNAMIC_PYTHON_DLL is specified so that it correctly includes the SONAME (libpython2.6.so.1 instead of libpython2.6.so). The former is always available while the latter is typically only available when the relevant -dev package is installed. I'm looking into the crash that was reported as well, but I'm not sure if that can be avoided as long as both interpreters are getting loaded. At a quick glance, it seems like if_python may not be handling locking properly. I'll dig into this some more later tonight. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- 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 dyn-python.diff Description: Binary data
Re: Dynamic loading for Perl
Hi, Dynamic loading of Perl does not work on Mac OS X. I did some digging around and the problem is that dlopen() doesn't find "libperl.dylib". Apparently this dylib is hidden under /System/Library/Perl/lib/5.10/libperl.dylib The easy fix would be to patch configure.in to include the full path when setting DYNAMIC_PERL_DLL instead of just "libperl.dylib", but I don't know how to get the path. Is there some "Perl-way" of doing this? (I tried using $vi_cv_perllib but it points to the wrong directory.) Björn -- 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
Re: conceal and modifiable
On 2010-07-22, Benjamin R. Haskell wrote: > On Thu, 22 Jul 2010, Jakson A. Aquino wrote: > > > Hello! > > > > I tested the conceal feature and noted that the concealed text of help > > files are "shown" in the cursor line (actually the character isn't > > visible since foreground and background colors are the same). > > Shouldn't the text be completely concealed since the buffer is > > nomodifiable? I'm using vim and vim-gtk: > > > > VIM - Vi IMproved 7.3b BETA (2010 Jul 18, compiled Jul 22 2010 14:13:18) > > AFAIK, there's no such feature of 'conceal'. (IIUC, The current line > won't be concealed regardless of the 'modifiable' setting.) But, I'd > second a motion to add that. It seems like it'd be useful. It would be nice. As it is, many of the lines in help files jiggle back and forth as the cursor moves through them. It's very distracting. I would rather have the markup characters not concealed at all. Regards, Gary -- 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
Re: conceal and modifiable
Jackson Aquino wrote: > I tested the conceal feature and noted that the concealed text of help > files are "shown" in the cursor line (actually the character isn't > visible since foreground and background colors are the same). > Shouldn't the text be completely concealed since the buffer is > nomodifiable? I'm using vim and vim-gtk: > > VIM - Vi IMproved 7.3b BETA (2010 Jul 18, compiled Jul 22 2010 14:13:18) It was like that for a little while, but it causes the problem that copying text didn't work correctly when searching. I thought of keeping the conceal if the cursor is in the first column, but when using ":help tag" commands it would not help. Another solution would be to have an option 'concealcursor', that is automatically reset as soon as you do anything else than moving the cursor around. Searches would still end in the wrong position though. Positioning the cursor correctly will be difficult to implement. An inefficient solution would be to redraw the cursor line on every cursor move, and let the display function correct the cursor column, since it encounters the column while going through the text. This would then be controlled by the 'concealcursor' option. -- An indication you must be a manager: You give constructive feedback to your dog. /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Linking errors when compiled with both python and python3
Nico Raffo wrote: > On Jul 22, 5:18 am, James Vega wrote: > > On Thu, Jul 22, 2010 at 12:36:27AM -0700, Nico Raffo wrote: > > > If Vim is compiled with both --enable-pythoninterp and --enable- > > > python3interp, errors occur when importing many python modules. To > > > reproduce, compile as described then try something like: > > > > > :py import termios > > > > I had been meaning to check whether something like that would happen with > > the > > Python interfaces. I saw something similar when testing the Perl interface. > > Does the attached patch fix it? > > > > Thanks. This gets us half way there. I now can import termios with > both versions of python installed. However if you import it from both > during one Vim session then Vim crashes and freezes my terminal. > > To reproduce, compile the latest with --enable-pythoninterp and -- > enable-python3interp and with James' patch. Launch Vim and run > > :py import termios > :py3 import termios > > Vim: Caught deadly signal ABRT > > At this point Vim is gone and my gnome terminal has to be killed. I also see the crash. I can recover the terminal (by starting Vim again). The output is: *** glibc detected *** ./vim: free(): invalid pointer: 0xb76990e0 *** === Backtrace: = /lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x1053591] /lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x1054de8] /lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x1057ecd] /usr/lib/libpython2.6.so(PyObject_Free+0x54)[0x4168ea4] /usr/lib/libpython2.6.so(+0x9d213)[0x4190213] /usr/lib/libpython3.1.so(PyUnicode_InternInPlace+0xd6)[0x11ca576] /usr/lib/libpython3.1.so(PyUnicode_InternFromString+0x33)[0x11d17e3] /usr/lib/libpython3.1.so(+0x785d8)[0x11ba5d8] /usr/lib/libpython3.1.so(PyType_Ready+0x87)[0x11bf7c7] /usr/lib/libpython3.1.so(_Py_ReadyTypes+0xa4)[0x11ac174] /usr/lib/libpython3.1.so(Py_InitializeEx+0x86)[0x1218ff6] /usr/lib/libpython3.1.so(Py_Initialize+0x1e)[0x12195ae] ./vim[0x8211611] ./vim[0x821167c] ./vim(ex_py3+0x41)[0x821179c] ./vim[0x80c89d9] ./vim(do_cmdline+0x944)[0x80c62b2] ./vim[0x814db42] ./vim(normal_cmd+0xf59)[0x8147278] ./vim(main_loop+0x584)[0x8109079] ./vim(main+0xd7c)[0x8108ad0] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xffebd6] ./vim[0x8073f71] In gdb the stack trace is: #0 0x0012d422 in __kernel_vsyscall () #1 0x00a14651 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00a17a82 in *__GI_abort () at abort.c:92 #3 0x00a4b49d in __libc_message (do_abort=2, fmt=0xb1ff98 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0x00a55591 in malloc_printerr (action=, str=0x6 , ptr=0xb7dbe0e0) at malloc.c:6264 #5 0x00a56de8 in _int_free (av=, p=) at malloc.c:4792 #6 0x00a59ecd in *__GI___libc_free (mem=0xb7dbe0e0) at malloc.c:3738 #7 0x00f65ea4 in PyObject_Free () from /usr/lib/libpython2.6.so #8 0x00f8d213 in ?? () from /usr/lib/libpython2.6.so #9 0x0136f576 in PyUnicode_InternInPlace () from /usr/lib/libpython3.1.so #10 0x013767e3 in PyUnicode_InternFromString () from /usr/lib/libpython3.1.so #11 0x0135f5d8 in ?? () from /usr/lib/libpython3.1.so #12 0x013647c7 in PyType_Ready () from /usr/lib/libpython3.1.so #13 0x01351174 in _Py_ReadyTypes () from /usr/lib/libpython3.1.so #14 0x013bdff6 in Py_InitializeEx () from /usr/lib/libpython3.1.so #15 0x013be5ae in Py_Initialize () from /usr/lib/libpython3.1.so #16 0x08211611 in Python3_Init () at if_python3.c:527 #17 0x0821167c in DoPy3Command (eap=0xbfffee8c, cmd=0x83cf76c "import termios") at if_python3.c:588 #18 0x0821179c in ex_py3 (eap=0xbfffee8c) at if_python3.c:643 #19 0x080c89d9 in do_one_cmd (cmdlinep=0xb040, sourcing=0, cstack=0xb048, fgetline=0x80dbb9d , cookie=0x0) at ex_docmd.c:2656 #20 0x080c62b2 in do_cmdline (cmdline=0x0, getline=0x80dbb9d , cookie=0x0, flags=0) at ex_docmd.c:1122 #21 0x0814db42 in nv_colon (cap=0xb3ac) at normal.c:5295 #22 0x08147278 in normal_cmd (oap=0xb46c, toplevel=1) at normal.c:1188 #23 0x08109079 in main_loop (cmdwin=0, noexmode=0) at main.c:1256 #24 0x08108ad0 in main (argc=1, argv=0xb6b4) at main.c:964 That it jumps from libpython3.1.so to a function in libpython2.6.so looks bad. -- BROTHER MAYNARD: Armaments Chapter Two Verses Nine to Twenty One. ANOTHER MONK:And St. Attila raised his hand grenade up on high saying "O Lord bless this thy hand grenade that with it thou mayest blow thine enemies to tiny bits, in thy mercy. "and the Lord did grin and people did feast upon the lambs and sloths and carp and anchovies and orang-utans and breakfast cereals and fruit bats and... BROTHER MAYNARD: Skip a bit brother ... "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/ \\\ \\\
Re: Multiple conceals collapse to single character
Charles Campbell wrote: > Vince Negri wrote: > > From: Ben Fritz [mailto:fritzophre...@gmail.com] > > > > > >> On Jul 10, 1:18 pm, "Benjamin R. Haskell" wrote: > >> > >>> Multiple conceal matches/regions get collapsed into a single character. > >>> I'm not sure if this is intended, but it is certainly confusing. > >>> > > > >> I think it is intended, for use cases like multiple invisible markers > >> to provide syntax highlighting to otherwise plain text (e.g. > >> TxtFormat, AnsiiEsc). However, I think we should allow other use cases > >> such as Greek characters in Tex, which could be VERY useful and > >> probably not that much harder to implement. > >> > > > > It is a little harder than you might initially think, because conceal lets > > syntax highlighting do most of the dirty work for it - so as it stands, > > a succession of single to-be-replaced characters is presented to the engine > > as > > a single region of "concealed text". But now that conceal is officially in > > the tree, it becomes more possible to propose changes to the syntax > > highlighting > > code that might facilitate your TeX usage example. > > > Hello! > > I tried the following trick: > > syn match texGreek '\\alpha\>' contained conceal cchar=á nextgroup=texGreek2 > syn match texGreek2 '\\alpha\>' contained conceal cchar=á nextgroup=texGreek > > So $\alpha\alpha$ has the first \alpha as texGreek, and the second one > as texGreek2 . Unfortunately, although the syntax highlighting treated > the two differently, the conceal code still merges the two, using only > the one á instead of what I'd hoped (áá). Makes sense. We can get the ID of the syntax item, and use a change in that as a signal to display the conceal character. I have implemented that, please try it out and let us know. If this doesn't work as intended, we should roll it back. Soon we can't make incompatible changes, thus please let's figure out how this should work very soon! -- MONK: ... and the Lord spake, saying, "First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shalt be the number thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe, who being naughty in my sight, shall snuff it. "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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Linking errors when compiled with both python and python3
James Vega wrote: > On Thu, Jul 22, 2010 at 12:36:27AM -0700, Nico Raffo wrote: > > If Vim is compiled with both --enable-pythoninterp and --enable- > > python3interp, errors occur when importing many python modules. To > > reproduce, compile as described then try something like: > > > > :py import termios > > or > > :py3 import termios > > > > Which gives the error: > > > > ImportError: /usr/lib/python3.1/lib-dynload/termios.so: undefined > > symbol: PyExc_TypeError > > > > This doesn't happen with all modules. Mostly just those with odd .so > > files. > > I had been meaning to check whether something like that would happen > with the Python interfaces. I saw something similar when testing the > Perl interface. Does the attached patch fix it? Thanks, I'll include it. It fixes the problem on my system. -- Compilation process failed successfully. /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: question for strdisplaywidth()
Yukihiro Nakadaira wrote:
> Is this correct behavior?
>
> :echo strdisplaywidth("x", 0)
> 1
> :echo strdisplaywidth("x", 1)
> 2
> :echo strdisplaywidth("x", 2)
> 3
>
> I expected all returns 1.
That's a bug. I'll fix it.
--
Arthur pulls Pin out. The MONK blesses the grenade as ...
ARTHUR: (quietly) One, two, five ...
GALAHAD: Three, sir!
ARTHUR: Three.
"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.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Re: Dynamic loading for Perl
Luis Carvalho wrote: > Bram Moolenaar wrote: > > > I suppose it will now be easy to support --enable-pythoninterp=dynamic > > and --enable-python3interp=dynamic > > > > We could wait for people to test this, but on the other hand if we want > > to do the same for ruby/tcl/mzscheme we need to do it now, next week I > > won't include patches like this. > > In the same vein, I'll attaching a patch that adds dynamic support for > the Lua interface. I won't be able to test it in Windows until next > week. I'm taking the opportunity to also patch the help file. Thanks, I'll include it. I don't mind if the Lua interface is broken, before this release there was nothing anyway. -- 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Re: Wrong reference to netrw.vim in autocmd.txt
Peter - > I just noticed that autocmd.txt references $VIMRUNTIME/plugin/netrw.vim > which doesn't exist. This is with the latest Vim 7.3 from the mercurial > repository (I upgraded to check this, the upgrade from 7.2 -> 7.3 went > flawless BTW thanks to http://www.vim.org/mercurial.php). I guess the > filename should be netrwPlugin.vim instead? Attached is a patch that > fixes this. Thanks, I'll include the fix. Not sure if netrw is such a good example now, it has become very complex. - Bram -- User: I'm having problems with my text editor. Help desk: Which editor are you using? User: I don't know, but it's version VI (pronounced: 6). Help desk: Oh, then you should upgrade to version VIM (pronounced: 994). /// 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Patch to strip -arch flags when compiling with Perl on Mac OS X
Hi, Perl is suffering from the same problem as Ruby in that it includes "-arch" flags in LDFLAGS and CFLAGS when compiling on Mac OS X. These flags should only be present when explicitly compiling for multiple (or specific) architectures and causes problems in other situations. The attached patch to configure.in strips these flags in the same way as we already do for Ruby. I also updated the Ruby portion to strip "-arch x86_64" in addition to "ppc" and "i386". This patch only affects the configure script on Mac OS X. Björn -- 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 0001-Strip-arch-from-Perl-flags.patch Description: Binary data
Re: conceal and modifiable
On Thu, 22 Jul 2010, Jakson A. Aquino wrote: > Hello! > > I tested the conceal feature and noted that the concealed text of help > files are "shown" in the cursor line (actually the character isn't > visible since foreground and background colors are the same). > Shouldn't the text be completely concealed since the buffer is > nomodifiable? I'm using vim and vim-gtk: > > VIM - Vi IMproved 7.3b BETA (2010 Jul 18, compiled Jul 22 2010 14:13:18) AFAIK, there's no such feature of 'conceal'. (IIUC, The current line won't be concealed regardless of the 'modifiable' setting.) But, I'd second a motion to add that. It seems like it'd be useful. -- Best, Ben -- 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
conceal and modifiable
Hello! I tested the conceal feature and noted that the concealed text of help files are "shown" in the cursor line (actually the character isn't visible since foreground and background colors are the same). Shouldn't the text be completely concealed since the buffer is nomodifiable? I'm using vim and vim-gtk: VIM - Vi IMproved 7.3b BETA (2010 Jul 18, compiled Jul 22 2010 14:13:18) Thanks, Jakson Aquino -- 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
Re: Linking errors when compiled with both python and python3
On Jul 22, 5:18 am, James Vega wrote: > On Thu, Jul 22, 2010 at 12:36:27AM -0700, Nico Raffo wrote: > > If Vim is compiled with both --enable-pythoninterp and --enable- > > python3interp, errors occur when importing many python modules. To > > reproduce, compile as described then try something like: > > > :py import termios > > I had been meaning to check whether something like that would happen with the > Python interfaces. I saw something similar when testing the Perl interface. > Does the attached patch fix it? > Thanks. This gets us half way there. I now can import termios with both versions of python installed. However if you import it from both during one Vim session then Vim crashes and freezes my terminal. To reproduce, compile the latest with --enable-pythoninterp and -- enable-python3interp and with James' patch. Launch Vim and run :py import termios :py3 import termios Vim: Caught deadly signal ABRT At this point Vim is gone and my gnome terminal has to be killed. Nico -- 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
Re: Multiple conceals collapse to single character
Vince Negri wrote: From: Ben Fritz [mailto:fritzophre...@gmail.com] On Jul 10, 1:18 pm, "Benjamin R. Haskell" wrote: Multiple conceal matches/regions get collapsed into a single character. I'm not sure if this is intended, but it is certainly confusing. I think it is intended, for use cases like multiple invisible markers to provide syntax highlighting to otherwise plain text (e.g. TxtFormat, AnsiiEsc). However, I think we should allow other use cases such as Greek characters in Tex, which could be VERY useful and probably not that much harder to implement. It is a little harder than you might initially think, because conceal lets syntax highlighting do most of the dirty work for it - so as it stands, a succession of single to-be-replaced characters is presented to the engine as a single region of "concealed text". But now that conceal is officially in the tree, it becomes more possible to propose changes to the syntax highlighting code that might facilitate your TeX usage example. Hello! I tried the following trick: syn match texGreek '\\alpha\>' contained conceal cchar=α nextgroup=texGreek2 syn match texGreek2 '\\alpha\>' contained conceal cchar=α nextgroup=texGreek So $\alpha\alpha$ has the first \alpha as texGreek, and the second one as texGreek2 . Unfortunately, although the syntax highlighting treated the two differently, the conceal code still merges the two, using only the one α instead of what I'd hoped (αα). 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
question for strdisplaywidth()
Is this correct behavior?
:echo strdisplaywidth("x", 0)
1
:echo strdisplaywidth("x", 1)
2
:echo strdisplaywidth("x", 2)
3
I expected all returns 1.
--
Yukihiro Nakadaira - yukihiro.nakada...@gmail.com
--
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
Re: Dynamic loading for Perl
Bram Moolenaar wrote:
> I suppose it will now be easy to support --enable-pythoninterp=dynamic
> and --enable-python3interp=dynamic
>
> We could wait for people to test this, but on the other hand if we want
> to do the same for ruby/tcl/mzscheme we need to do it now, next week I
> won't include patches like this.
In the same vein, I'll attaching a patch that adds dynamic support for the Lua
interface. I won't be able to test it in Windows until next week. I'm taking
the opportunity to also patch the help file.
Cheers,
Luis
--
Computers are useless. They can only give you answers.
-- Pablo Picasso
--
Luis Carvalho (Kozure)
lua -e 'print((("lexcarva...@no.gmail.spam.com"):gsub("(%u+%.)","")))'
--
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
--- vim.orig/src/Makefile 2010-07-21 19:24:21.112479023 -0300
+++ vim/src/Makefile 2010-07-21 18:01:18.635456732 -0300
@@ -1314,7 +1314,7 @@
.SUFFIXES: .c .o .pro
PRE_DEFS = -Iproto $(DEFS) $(GUI_DEFS) $(GUI_IPATH) $(CPPFLAGS) $(EXTRA_IPATHS)
-POST_DEFS = $(X_CFLAGS) $(LUA_CFLAGS) $(MZSCHEME_CFLAGS) $(TCL_CFLAGS) $(RUBY_CFLAGS) $(EXTRA_DEFS)
+POST_DEFS = $(X_CFLAGS) $(MZSCHEME_CFLAGS) $(TCL_CFLAGS) $(RUBY_CFLAGS) $(EXTRA_DEFS)
ALL_CFLAGS = $(PRE_DEFS) $(CFLAGS) $(PROFILE_CFLAGS) $(POST_DEFS)
@@ -2488,7 +2488,7 @@
$(CCC) -o $@ if_xcmdsrv.c
objects/if_lua.o: if_lua.c
- $(CCC) -o $@ if_lua.c
+ $(CCC) $(LUA_CFLAGS) -o $@ if_lua.c
objects/if_mzsch.o: if_mzsch.c $(MZSCHEME_EXTRA)
$(CCC) -o $@ $(MZSCHEME_CFLAGS_EXTRA) if_mzsch.c
--- vim.orig/src/config.h.in 2010-07-21 19:24:22.927516762 -0300
+++ vim/src/config.h.in 2010-07-21 18:03:00.340489646 -0300
@@ -319,6 +319,9 @@
/* Define if you want to include the Lua interpreter. */
#undef FEAT_LUA
+/* Define for linking via dlopen() or LoadLibrary() */
+#undef DYNAMIC_LUA
+
/* Define if you want to include the MzScheme interpreter. */
#undef FEAT_MZSCHEME
--- vim.orig/src/configure.in 2010-07-21 19:24:20.199472694 -0300
+++ vim/src/configure.in 2010-07-21 19:13:47.696263464 -0300
@@ -413,11 +413,11 @@
dnl Check for Lua feature.
AC_MSG_CHECKING(--enable-luainterp argument)
AC_ARG_ENABLE(luainterp,
- [ --enable-luainterp Include Lua interpreter.], ,
+ [ --enable-luainterp[=OPTS] Include Lua interpreter. [default=no] [OPTS=no/yes/dynamic]], ,
[enable_luainterp="no"])
AC_MSG_RESULT($enable_luainterp)
-if test "$enable_luainterp" = "yes"; then
+if test "$enable_luainterp" = "yes" -o "$enable_luainterp" = "dynamic"; then
dnl -- find the lua executable
AC_SUBST(vi_cv_path_lua)
@@ -477,6 +477,11 @@
LUA_OBJ="objects/if_lua.o"
LUA_PRO="if_lua.pro"
AC_DEFINE(FEAT_LUA)
+if test "$enable_luainterp" = "dynamic"; then
+ AC_DEFINE(DYNAMIC_LUA)
+ LUA_LIBS=""
+ LUA_CFLAGS="-DDYNAMIC_LUA_DLL=\\\"liblua${vi_cv_version_lua}.so\\\" $LUA_CFLAGS"
+fi
fi
AC_SUBST(LUA_SRC)
AC_SUBST(LUA_OBJ)
--- vim.orig/src/if_lua.c 2010-07-21 19:24:21.292455466 -0300
+++ vim/src/if_lua.c 2010-07-22 10:32:45.396540334 -0300
@@ -41,6 +41,19 @@
#ifdef DYNAMIC_LUA
+
+#ifndef WIN3264
+#include
+#define HANDLE void*
+#define load_dll(n) dlopen((n), RTLD_LAZY|RTLD_GLOBAL)
+#define symbol_from_dll dlsym
+#define close_dll dlclose
+#else
+#define load_dll LoadLibrary
+#define symbol_from_dll GetProcAddress
+#define close_dll FreeLibrary
+#endif
+
/* lauxlib */
#define luaL_register dll_luaL_register
#define luaL_typerror dll_luaL_typerror
@@ -227,14 +240,14 @@
{NULL, NULL}
};
-static HINSTANCE hinstLua = 0;
+static HANDLE hinstLua = NULL;
static void
end_dynamic_lua(void)
{
if (hinstLua)
{
- FreeLibrary(hinstLua);
+close_dll(hinstLua);
hinstLua = 0;
}
}
@@ -244,7 +257,7 @@
{
const luaV_Reg *reg;
if (hinstLua) return OK;
-hinstLua = LoadLibrary(libname);
+hinstLua = load_dll(libname);
if (!hinstLua)
{
if (verbose)
@@ -253,8 +266,8 @@
}
for (reg = luaV_dll; reg->func; reg++)
{
- if ((*reg->func = GetProcAddress(hinstLua, reg->name)) == NULL) {
- FreeLibrary(hinstLua);
+ if ((*reg->func = symbol_from_dll(hinstLua, reg->name)) == NULL) {
+close_dll(hinstLua);
hinstLua = 0;
if (verbose)
EMSG2(_(e_loadfunc), reg->name);
--- vim.orig/runtime/doc/if_lua.txt 2010-07-21 19:24:25.299476540 -0300
+++ vim/runtime/doc/if_lua.txt 2010-07-22 10:07:29.127454922 -0300
@@ -1,4 +1,4 @@
-*if_lua.txt*For Vim version 7.3b. Last change: 2008 Aug 31
+*if_lua.txt* For Vim version 7.3. Last change: 2010 Jul 22
VIM REFERENCE MANUALby Luis Carvalho
@@ -56,7 +56,7 @@
<
*:luado*
-:[range]luado {body} Execute Lua function$function (line)${body}$end$ for
+:[range]luado {body} Execute Lua function "function (line) {body} end" for
each line in the [range], with the function argument
being set
Re: Linking errors when compiled with both python and python3
On Thu, Jul 22, 2010 at 12:36:27AM -0700, Nico Raffo wrote: > If Vim is compiled with both --enable-pythoninterp and --enable- > python3interp, errors occur when importing many python modules. To > reproduce, compile as described then try something like: > > :py import termios > or > :py3 import termios > > Which gives the error: > > ImportError: /usr/lib/python3.1/lib-dynload/termios.so: undefined > symbol: PyExc_TypeError > > This doesn't happen with all modules. Mostly just those with odd .so > files. I had been meaning to check whether something like that would happen with the Python interfaces. I saw something similar when testing the Perl interface. Does the attached patch fix it? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega diff --git a/src/if_python.c b/src/if_python.c --- a/src/if_python.c +++ b/src/if_python.c @@ -96,11 +96,11 @@ # define HINSTANCE long_u /* for generating prototypes */ # endif -#ifndef _WIN32 +#ifndef WIN3264 # include # define FARPROC void* # define HINSTANCE void* -# define load_dll(n) dlopen((n),RTLD_LAZY) +# define load_dll(n) dlopen((n),RTLD_LAZY|RTLD_GLOBAL) # define close_dll dlclose # define symbol_from_dll dlsym #else diff --git a/src/if_python3.c b/src/if_python3.c --- a/src/if_python3.c +++ b/src/if_python3.c @@ -70,11 +70,11 @@ #if defined(DYNAMIC_PYTHON3) -#ifndef _WIN32 +#ifndef WIN3264 #include #define FARPROC void* #define HINSTANCE void* -#define load_dll(n) dlopen((n),RTLD_LAZY) +#define load_dll(n) dlopen((n),RTLD_LAZY|RTLD_GLOBAL) #define close_dll dlclose #define symbol_from_dll dlsym #else signature.asc Description: Digital signature
Re: Compilation issues with revision 2368:435b5c6a5191
On 7/21/10 3:57 PM, Chris Sutcliffe wrote: GVim fails to compile with revision 2368:435b5c6a5191 under MinGW: It turns out this was the result of an incorrect patch to w32api that I was testing. Once removing the incorrect patch GVim compiles as expected. Sorry for the noise. Chris -- 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
Re: Dynamic loading for Perl
James Vega wrote: > On Wed, Jul 21, 2010 at 4:58 PM, Christian J. Robinson > wrote: > > On Wed, Jul 21, 2010 at 2:08 PM, Bram Moolenaar wrote: > >> > >> We could wait for people to test this, but on the other hand if we > >> want to do the same for ruby/tcl/mzscheme we need to do it now, next > >> week I won't include patches like this. > > > > It broke compiling using Make_cyg.mak for me. (Just to be sure I did > > an "hg update -C".) > > Oops. Looks like I was using the wrong "building on Windows" check. > The attached patch should fix it, as that's what the Python modules are > using. Thanks. I think using WIN3264 is a little bit better. Trying to avoid all the different symbols that compiler define and use the one defined in vim.h. I have included this change now. -- 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. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
Linking errors when compiled with both python and python3
If Vim is compiled with both --enable-pythoninterp and --enable- python3interp, errors occur when importing many python modules. To reproduce, compile as described then try something like: :py import termios or :py3 import termios Which gives the error: ImportError: /usr/lib/python3.1/lib-dynload/termios.so: undefined symbol: PyExc_TypeError This doesn't happen with all modules. Mostly just those with odd .so files. The modules will import fine outside of Vim, or if python 2 or python 3 is compiled into Vim individually. I attempted adding some more compiler flags as suggested at the bottom of http://docs.python.org/extending/embedding.html without much luck. Nico -- 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
