Validation fixes in 2html
Attached patch fixes a number of bugs in TOhtml, mostly markup validation fixes for xhtml and for non-CSS generation. I've tested a small set of options on a couple of files and it looks like it doesn't break anything, but of course the potential is there. Test if you're interested, but I'm running a script that will generate with a fairly exhaustive set of options. I'll compare the output sometime tomorrow afternoon or evening to the same files generated with the unpatched version. I'll report back when I have the results but I'm pretty confident the patch can be included if I don't get back before the next beta release. -- 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 2html_validation_fixes.patch Description: Binary data
Re: [patch] remove mention of extra archive in help files
Dominique Pellé wrote:
> Hi
>
> :help version-7.3 says...
>
>
> The extra and language files are no longer distributed separately.
> The source files for all systems are included in one distribution.
>
>
> There are at least 2 help files (runtime/doc/{farsi,os_risc}.txt)
> which still mention the extra archive (now irrelevant).
> Attached patch changes it.
>
> Also, what about the following files? Should we remove them?
>
> src/README_extra.txt
> src/README_lang.txt
With the attachment this time.
-- 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 3c51864309bc runtime/doc/farsi.txt
--- a/runtime/doc/farsi.txt Fri Aug 06 20:53:49 2010 +0200
+++ b/runtime/doc/farsi.txt Fri Aug 06 22:04:26 2010 +0200
@@ -62,8 +62,8 @@
Farsi Fonts *farsi fonts*
---
-If the "extra" archive has been unpacked, the following files are found in the
-subdirectories of the '$VIM/farsi' directory:
+The following files are found in the subdirectories of the '$VIM/farsi'
+directory:
+ far-a01.pcfX Windows fonts for Unix including Linux systems
+ far-a01.bf X Windows fonts for SunOS
diff -r 3c51864309bc runtime/doc/os_risc.txt
--- a/runtime/doc/os_risc.txt Fri Aug 06 20:53:49 2010 +0200
+++ b/runtime/doc/os_risc.txt Fri Aug 06 22:04:26 2010 +0200
@@ -275,7 +275,6 @@
- Get the latest source distribution (see www.vim.org)
- Get the runtime environment files (e.g. these help files)
-- Get the "extra" archive (contains the RISC OS specific bits)
- Get the RISC OS binary distribution (if possible)
Re: E315: ml_get: invalid lnum
Dimitar DIMITROV wrote: > Hi, > > 1. :help > 2. 10GVj > 3. :ene > 4. Use to paste the text but don't do it above line 1 > 5. u > 6. Use to paste the text and do it above line 1 > 7. ddu^R > > Error message: > > E315: ml_get: invalid lnum: 3 > E315: ml_get: invalid lnum: 3 I can't reproduce it. What would be useful, is for you to put a breakpoint in a debugger at memline.c:2452 where E315 happens and send us the stack. I suspect that a plugin has an autocommand which could trigger this. Which plugins are you using? What autocommands are in your ~/.vimrc? How about also enabling plugins one at at time to see which once triggers the bug. -- 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
[patch] remove mention of extra archive in help files
Hi
:help version-7.3 says...
The extra and language files are no longer distributed separately.
The source files for all systems are included in one distribution.
There are at least 2 help files (runtime/doc/{farsi,os_risc}.txt)
which still mention the extra archive (now irrelevant).
Attached patch changes it.
Also, what about the following files? Should we remove them?
src/README_extra.txt
src/README_lang.txt
-- 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
searching for Mac non-breaking space
searching for Mac non-breaking space *[:blank:]* [:blank:] space and tab characters *[:space:]* [:space:] whitespace characters I have asked on vim-use and opinion is [:space:] will find more than [:blank:] On MacOS the non-breaking space is not found by either. Search for /\%xA0 finds the Mac non-breaking space. Can I add the Mac the non-breaking space to [:space:] ? Or do I need to do something like: [[:space:]\xA0]\+ -Bill -- 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: Vim 7.3: Python3 support
On Fri, Aug 6, 2010 at 3:16 PM, Bram Moolenaar wrote: > Roland - > > You have been quiet for a while. I still have the workaround that in > one Vim session one can only use either :python or :py3 to avoid > problems mixing the shared library. Is there a better solution? As far as I know, the only way to do this would be to run distinct processes for each interpreter in order to keep the libraries from running in the same namespace. So, any ":py*" or ":py3*" command would start a separate process, dlopen the library, load the symbols, run whatever command was requested, and then exit. -- 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
Re: GTK GUI: "columns" is sometimes set to 122 even though I set it in GUIEnter
Ron Aaron wrote: > On Thursday 05 August 2010 22:56:26 Bram Moolenaar wrote: > > > GTK resizing is hacky. I could never figure out how to do it properly. > > I'm sure that when we try to fix this problem another one will pop up. > > A simple addition of "gui_mch_update();" before doing the GUI_ENTER > autocommand seems to fix this particular issue: Well, that's a low risc change, let me include that. I'm glad it was this simple. -- Computers are useless. They can only give you answers. -- Pablo Picasso /// 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] translatable strings in src/if_py_both.h not appearing in src/po/*.po files
Hi While updating the the fr & eo translations of Vim, I noticed that several strings have disappeared from the src/po/* files. For example, string "E264: Python: Error initialising I/O objects" is missing from src/po/fr.po after I do: $ cd src/po ; make fr File src/po/Makefile does not scan src/if_py_both.h which contains strings that need translations. Attached patch fixes it. Regards -- 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 e8a81e381ad2 src/po/Makefile --- a/src/po/Makefile Thu Aug 05 22:08:47 2010 +0200 +++ b/src/po/Makefile Fri Aug 06 21:07:12 2010 +0200 @@ -251,10 +251,10 @@ # NOTE: If you get an error for gvimext.cpp not found, you need to unpack the # extra archive. # -$(PACKAGE).pot: ../*.c ../if_perl.xs ../GvimExt/gvimext.cpp ../globals.h +$(PACKAGE).pot: ../*.c ../if_perl.xs ../GvimExt/gvimext.cpp ../globals.h ../if_py_both.h cd ..; $(XGETTEXT) --default-domain=$(PACKAGE) \ --add-comments --keyword=_ --keyword=N_ \ - *.c if_perl.xs GvimExt/gvimext.cpp globals.h + *.c if_perl.xs GvimExt/gvimext.cpp globals.h if_py_both.h mv -f ../$(PACKAGE).po $(PACKAGE).pot update-po: $(LANGUAGES)
Re: [PATCH] update version in gvim manifest
Michael Wookey wrote: > --- > src/gvim.exe.mnf |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/src/gvim.exe.mnf b/src/gvim.exe.mnf > index 0033979..26ade97 100644 > --- a/src/gvim.exe.mnf > +++ b/src/gvim.exe.mnf > @@ -2,7 +2,7 @@ > manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > > processorArchitecture="*" > -version="7.2.0.0" > +version="7.3.0.0" > type="win32" > name="Vim" >/> Thanks. -- hundred-and-one symptoms of being an internet addict: 25. You believe nothing looks sexier than a man in boxer shorts illuminated only by a 17" inch svga monitor. /// 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: Vim 7.3: Python3 support
Roland - You have been quiet for a while. I still have the workaround that in one Vim session one can only use either :python or :py3 to avoid problems mixing the shared library. Is there a better solution? I hope you can come up with something really soon, since we are getting very close to the 7.3 release and I don't want to risc making changes that could crash Vim. -- hundred-and-one symptoms of being an internet addict: 26. You check your mail. It says "no new messages." So you check it again. /// 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: BUG: ``E685: Internal error: func_unref()'' when using delfunction on local function varible containing a dictionary function
Andy Wokula wrote: > Am 05.08.2010 21:56, schrieb Bram Moolenaar: > > ZyX (?) wrote: > > > >> Attached script causes a error when sourced using > >> vim -u NONE -c 'set nocompatible' -c 'so ~/tmp/vim/test-bug.vim > >> Error message: > >> Error detected while processing /home/zyx/tmp/vim/test-bug.vim: > >> line8: > >> E685: Internal error: func_unref() > >> E685: Internal error: func_unref() > >> Tested on vim-7.2.442 and vim-7.3 revision > >> 2493:ed997d0ceb2674b8fb3d707130647197c5cf8f83. > > > > I can reproduce it. I'll add it to the todo list. > > Is there any chance that bugs like this one will also be fixed > for Vim7.2? I have no plans for this. Only for "crashing bugs". 7.3 already includes a lot of bug fixes that also apply to 7.2. And this one hasn't been fixed yet! -- hundred-and-one symptoms of being an internet addict: 24. You realize there is not a sound in the house and you have no idea where your children are. /// 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: Re : E315: ml_get: invalid lnum
Dimitar Dimitrov wrote: > > > 1. :help > > > 2. 10GVj > > > 3. :ene > > > 4. Use to paste the text but don't do it above line 1 > > > 5. u > > > 6. Use to paste the text and do it above line 1 > > > 7. ddu^R > > > > > > Error message: > > > > > > E315: ml_get: invalid lnum: 3 > > > E315: ml_get: invalid lnum: 3 > > > > > > :version > > > > > > VIM - Vi IMproved 7.3d BETA (2010 Aug 4, compiled Aug 4 2010 18:38:10) > > > MS-Windows 32-bit GUI version with OLE support > > > > I don't see the error. When doing "dd", which line are you deleting? > > The last one > > > > > Did you start with "vim -u NONE"? > > I hadn't. Now I did and there is a different error. At the end we > still should have one line but all disappears. Here is how you can > reproduce it: > > gvim.exe -u NONE -U NONE > :help > yy > ^w^w > p > u > P > j > dd > u > ^r As someone already mentioned, that's intended in compatible mode. Any way you can reproduce the ml_get error without including all your plugins and vimrc file? -- Q: What is the difference betwee open-source and commercial software? A: If you have a problem with commercial software you can call a phone number and they will tell you it might be solved in a future version. For open-source software there isn't a phone number to call, but you get the solution within a day. /// 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: Updated Brazilian Portuguese translation
Eduardo Dobay wrote: > I hadn't updated the translation since I first uploaded it, so here is > a patch against the old source. > (Am I too late for 7.3?) I'll include it, thanks. -- hundred-and-one symptoms of being an internet addict: 27. You refer to your age as 3.x. /// 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: Syntax highlighting for JavaScript within JSP file
Attached is a patch that fixes syntax highlighting for JavaScript embedded within a JSP file. syntax/jsp.vim was redefining the htmlTag highlight group, but the original htmlTag group from syntax/html.vim was still defined. It took precedence, and as a result JavaScript code between
Re: Another GTK "issue" - repaint while initializing
On Aug 6, 9:46 am, ron wrote: > The GTK version shows the window being positioned and sized, etc, > *before* the "GUIEnter" event happens. This is distracting, as > sessions etc can resize the window, color schemes can be set, and so > on. The "bouncing around" of the window looks odd, and also > contributes (I think) to a slower startup than necessary. > > Is there a way to suppress all the visible drawing until after the > GUIEnter has occurred? :help GUIEnter: GUIEnterAfter starting the GUI successfully, and after opening the window. It is triggered before VimEnter when using gvim. Can be used to position the window from a .gvimrc file I would certainly not consider the GUI sucessfully started until it has been drawn at least once. I do not think what you ask can be done without changing the meaning of GUIEnter. -- 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
Another GTK "issue" - repaint while initializing
The GTK version shows the window being positioned and sized, etc, *before* the "GUIEnter" event happens. This is distracting, as sessions etc can resize the window, color schemes can be set, and so on. The "bouncing around" of the window looks odd, and also contributes (I think) to a slower startup than necessary. Is there a way to suppress all the visible drawing until after the GUIEnter has occurred? -- 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 : Re : E315: ml_get: invalid lnum
Right... Just tried: gvim.exe "+se nocp" -u NONE -U NONE None of the errors is triggered Cheers De : Lech Lorens À : vim_dev@googlegroups.com Envoyé le : Ven 6 août 2010, 11h 05min 59s Objet : Re: Re : E315: ml_get: invalid lnum On 6 August 2010 10:56, Dimitar DIMITROV wrote: > I hadn't. Now I did and there is a different error. At the end we still > should > have one line but all disappears. Here is how you can reproduce it: > > gvim.exe -u NONE -U NONE > :help > yy > ^w^w > p > u > P > j > dd > u > ^r This is not an error. This is due to Vim being run in Vi-compatible mode. Try removing 'u' from 'cpoptions'. -- Regards, Lech Lorens -- 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 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: Re : E315: ml_get: invalid lnum
On 6 August 2010 10:56, Dimitar DIMITROV wrote: > I hadn't. Now I did and there is a different error. At the end we still > should > have one line but all disappears. Here is how you can reproduce it: > > gvim.exe -u NONE -U NONE > :help > yy > ^w^w > p > u > P > j > dd > u > ^r This is not an error. This is due to Vim being run in Vi-compatible mode. Try removing 'u' from 'cpoptions'. -- Regards, Lech Lorens -- 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 about :find completion support in Vim 7.3b
On Thu, Aug 5, 2010 at 12:25 AM, Ajit Thakkar wrote:
> Nazri, for the future, you may want to try and add path completion for :cd
>
> Ajit
Here's a toy patch if you would like to try it out. Thanks for the suggestion.
I've never used 'cdpath' before.
The implementation reuses the same mechanism as the find completion.
>From my cursory tests it seems to work fine on unix for 'cdpath' values set
to default (",,"), empty (set cdpath=), and recursive (set cdpath=~/foo/**).
I'll do a quick test on windows XP ...
It doesn't work as smooth as on unix because completion list have
trailing path separators for all the directories that it found:
:cd somedirincdpath\
fails, while
:cd somedirincdpath
or
:cd somedirincdpath/
works fine.
To fix this the trailing path must be stripped for each completion item
when they are added to the completion list. Search for the comment
"/* Copy each path in files into gap */" to see where this happen.
I'm running out of time here so I'm attaching the patch as it is now,
warts and all.
nazri.
--
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
From 6ca0e09bd86271f59efe1a26d815589f284cd857 Mon Sep 17 00:00:00 2001
From: Nazri Ramliy
Date: Fri, 6 Aug 2010 17:20:00 +0800
Subject: [PATCH] cd, lcd, chdir, and lchdir completion based on 'cdpath'
---
src/ex_docmd.c |3 +--
src/ex_getln.c |6 +-
src/misc1.c| 29 +++--
src/vim.h |2 ++
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 0d91a0b..900577d 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -3472,8 +3472,7 @@ set_one_cmd_context(xp, buff)
case CMD_chdir:
case CMD_lcd:
case CMD_lchdir:
- if (xp->xp_context == EXPAND_FILES)
- xp->xp_context = EXPAND_DIRECTORIES;
+ xp->xp_context = EXPAND_DIR_IN_CDPATH;
break;
case CMD_help:
xp->xp_context = EXPAND_HELP;
diff --git a/src/ex_getln.c b/src/ex_getln.c
index 8a18a4c..b726e71 100644
--- a/src/ex_getln.c
+++ b/src/ex_getln.c
@@ -4102,6 +4102,7 @@ addstar(fname, len, context)
if (context != EXPAND_FILES
&& context != EXPAND_FILES_IN_PATH
+ && context != EXPAND_DIR_IN_CDPATH
&& context != EXPAND_SHELLCMD
&& context != EXPAND_DIRECTORIES)
{
@@ -4429,7 +4430,8 @@ ExpandFromContext(xp, pat, num_file, file, options)
if (xp->xp_context == EXPAND_FILES
|| xp->xp_context == EXPAND_DIRECTORIES
- || xp->xp_context == EXPAND_FILES_IN_PATH)
+ || xp->xp_context == EXPAND_FILES_IN_PATH
+ || xp->xp_context == EXPAND_DIR_IN_CDPATH)
{
/*
* Expand file or directory names.
@@ -4461,6 +4463,8 @@ ExpandFromContext(xp, pat, num_file, file, options)
flags |= EW_FILE;
else if (xp->xp_context == EXPAND_FILES_IN_PATH)
flags |= (EW_FILE | EW_PATH);
+ else if (xp->xp_context == EXPAND_DIR_IN_CDPATH)
+ flags |= (EW_DIR | EW_CDPATH);
else
flags = (flags | EW_DIR) & ~EW_FILE;
/* Expand wildcards, supporting %:h and the like. */
diff --git a/src/misc1.c b/src/misc1.c
index ef7c10c..a0bbc8c 100644
--- a/src/misc1.c
+++ b/src/misc1.c
@@ -9238,9 +9238,9 @@ unix_expandpath(gap, path, wildoff, flags, didstar)
#if defined(FEAT_SEARCHPATH)
static int find_previous_pathsep __ARGS((char_u *path, char_u **psep));
static int is_unique __ARGS((char_u *maybe_unique, garray_T *gap, int i));
-static void expand_path_option __ARGS((char_u *curdir, garray_T *gap));
+static void expand_option __ARGS((char_u *curdir, garray_T *gap, char_u *option));
static char_u *get_path_cutoff __ARGS((char_u *fname, garray_T *gap));
-static void uniquefy_paths __ARGS((garray_T *gap, char_u *pattern));
+static void uniquefy_paths __ARGS((garray_T *gap, char_u *pattern, char_u *option));
static int expand_in_path __ARGS((garray_T *gap, char_u *pattern, int flags));
/*
@@ -9310,12 +9310,11 @@ is_unique(maybe_unique, gap, i)
* expanding each into their equivalent path(s).
*/
static void
-expand_path_option(curdir, gap)
+expand_option(curdir, gap, path_option)
char_u *curdir;
garray_T *gap;
+char_u *path_option;
{
-char_u *path_option = *curbuf->b_p_path == NUL
- ? p_path : curbuf->b_p_path;
char_u *buf;
char_u *p;
@@ -9424,9 +9423,10 @@ get_path_cutoff(fname, gap)
* matches the pattern. Beware, this is at least O(n^2) wrt gap->ga_len.
*/
static void
-uniquefy_paths(gap, pattern)
+uniquefy_paths(gap, pattern, path_option)
garray_T *gap;
char_u *pattern;
+char_u *path_option;
{
int i;
int len;
@@ -9468,7 +9468,7 @@ uniquefy_paths(gap, pattern)
return;
mch_dirname(curdir, MAXPATHL);
-expand_path_option(curdir, &path_ga);
+expand_option(curdir, &path_ga, path_option);
for (i = 0; i < gap->ga_len; i++)
{
@@ -9582,12 +9582,17 @@ expand_in_path(
Re : E315: ml_get: invalid lnum
> Dimitar Dimitrov wrote: > > > 1. :help > > 2. 10GVj > > 3. :ene > > 4. Use to paste the text but don't do it above line 1 > > 5. u > > 6. Use to paste the text and do it above line 1 > > 7. ddu^R > > > > Error message: > > > > E315: ml_get: invalid lnum: 3 > > E315: ml_get: invalid lnum: 3 > > > > :version > > > > VIM - Vi IMproved 7.3d BETA (2010 Aug 4, compiled Aug 4 2010 18:38:10) > > MS-Windows 32-bit GUI version with OLE support > > I don't see the error. When doing "dd", which line are you deleting? The last one > > Did you start with "vim -u NONE"? I hadn't. Now I did and there is a different error. At the end we still should have one line but all disappears. Here is how you can reproduce it: gvim.exe -u NONE -U NONE :help yy ^w^w p u P j dd u ^r -- 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: BUG: ``E685: Internal error: func_unref()'' when using delfunction on local function varible containing a dictionary function
Am 05.08.2010 21:56, schrieb Bram Moolenaar: ZyX (?) wrote: Attached script causes a error when sourced using vim -u NONE -c 'set nocompatible' -c 'so ~/tmp/vim/test-bug.vim Error message: Error detected while processing /home/zyx/tmp/vim/test-bug.vim: line8: E685: Internal error: func_unref() E685: Internal error: func_unref() Tested on vim-7.2.442 and vim-7.3 revision 2493:ed997d0ceb2674b8fb3d707130647197c5cf8f83. I can reproduce it. I'll add it to the todo list. Is there any chance that bugs like this one will also be fixed for Vim7.2? -- Andy -- 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
