[PATCH] documentation fixes
Hi Bram, Find attached a patch that corrects the following in the docs - - Tidy up the use of Tab, Tab, tab etc - Fix the highlighting for the title of getwinposx() in eval.txt. There is a missing '' at the start of the previous line to terminate the previous highlighting. - One or two minor grammatical fixes This is diffed against 7.1b.001 (CVS). cheers vimdoc.patch Description: vimdoc.patch
[SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. I've never noticed this bug before since I always rsync the runtime after a build - which therefore places an rgb.txt into my $VIMRUNTIME. Because rsync is not suitable for the Vim 7.1a runtime, rgb.txt is missing from my $VIMRUNTIME hence the issue showed itself. I just did a build of 7.0.243 (svn#261) and it also fails with the inability to understand the colour scheme - because there is no rgb.txt copied to $VIMRUNTIME! So it looks like this might have been a long standing issue. Bram - can you change the Makefile to copy rgb.txt to $VIMRUNTIME for OSX builds? Thanks for the tip Tony!
RE: [SOLVED] RE: 7.1a.001 OSX colour scheme errors?
Michael Wookey wrote: Hm... Maybe the console version checks the values of the guibg= guifg= settings even though it doesn't use them. Try dropping the attached file into your $VIMRUNTIME folder and see if it makes any difference. (See :help rgb.txt for an explanation of how Vim uses it. IIUC, on X11- and Windows-based systems, those colour names' RGB values can be obtained by querying the OS.) Ahh.. found it. 'make install' wasn't copying the 'rgb.txt' to $VIMRUNTIME. It seems that this is a bug because even on the linux machine, 'make install' doesn't copy rgb.txt either. However on the linux machine there are existing copies of rgb.txt in places like /etc/x11/rgb.txt (Ubuntu 7.04) which vim must have picked up which is why it works. The help mentions /usr/X11R6/lib/X11/ ; I found mine in /usr/share/X11 (on SuSE 10.2)... Apparently there is no single fixed location for that file. I wonder what the rule is? Any app using colour names should be able to find it after all. On Ubuntu 7.04, the following are all symlinked to /etc/X11/rgb.txt /usr/share/X11/rgb.txt /usr/lib/X11/rgb.txt On OSX, there is no rgb.txt on the system at all unless X11 is installed (which it is not by default). This is why it may be a good thing to include rgb.txt for the OSX vim builds.
RE: 7.1a.001 OSX colour scheme errors?
Has anyone else noticed this? You apparently are missing the runtime/rgb.txt file. It's part of the extra archive. Perhaps you didn't unpack it correctly? You must have unpacked it, since it contains src/gui_mac.c. And you must not change the directory structure, otherwise Vim.app can't be generated correctly. I have the rgb.txt in my build tree. Its just that 'make install' doesn't copy it over when building Vim.App. See further on in this thread with the subject [SOLVED] RE: 7.1a.001 OSX colour scheme errors?. Is it possible for you to change the Makefile to copy rgb.txt to $VIMRUNTIME during 'make install'? Thanks.
7.1a.001 OSX colour scheme errors?
Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim - /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this?
RE: 7.1a.001 OSX colour scheme errors?
A.J.Mechelynck wrote: Michael Wookey wrote: Hello vimmers, I am running 7.1a.001 on OSX and have just noticed the following from console vim (running in Terminal.app and also occurs in iTerm.app). If I change the colour scheme I receive a lot of error output. For example: :colorscheme desert Results in: Error detected while processing /Applications/Vim.app/Contents/Resources/vim/runtime/colors/desert.vim: line 27: E254: Cannot allocate color khaki E254: Cannot allocate color slategrey line 36: E254: Cannot allocate color gold line 37: E254: Cannot allocate color tan ... Other colour schemes produce similar output. The error messages have only appeared for me in console vim on OSX (10.4.9 PPC). They have not appeared in the linux or win32 console vims of 7.1a.001. GVim's on each of the platforms (OSX, linux, Win32) have worked fine. My console vim is symlinked as follows: $ ls -l `which vim` lrwxr-xr-x 1 root wheel 40 Feb 28 14:33 /usr/bin/vim - /Applications/Vim.app/Contents/MacOS/Vim These errors did not occur before 7.1a.001 and occurs on builds from CVS and SVN. The errors still occur even with starting vim with: vim -u NONE Has anyone else noticed this? These color names should be used only in the GUI. In the desert colorscheme I have (v1.1, 2004/06/13 19:30:30) they are only present in guibg= and guifg= arguments to the :hi command, which is normal. If you want to debug that problem, you may want to vimgrep your sources for the highlight command, then inspect the source to see if (as it should) it does ignore guibg= guifg= and gui= when setting highlights in Console Vim. You may restrict yourself to the modules which were actually compiled for your configure options, as shown e.g. by the contents of the objects folder (src/objects or whatever). I think I've found it.. The OSX Vim is built with FEAT_GUI_MAC always defined. This in turn forces FEAT_GUI to be defined. This is from around lines 66-102 of src/vim.h. In src/syntax.c:do_highlight() there are checks for FEAT_GUI to be defined. Items like guifg and guibg etc are conditionally compiled to only take effect if FEAT_GUI is defined (which it is in the OSX case). The call chain eventually looks like: do_highlight() color_name2handle() gui_get_color()- E254: Cannot allocate color So because FEAT_GUI is always defined on OSX, vim gets these errors for console vim. I still don't quite understand why this is causing an error when it doesn't on linux. The console linux version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 8 2007 00:27:42) Included patches: 1 Huge version with GTK2 GUI. Features included (+) or not (-): ... While the console OSX version reports: VIM - Vi IMproved 7.1a BETA (2007 May 5, compiled May 9 2007 11:33:38) MacOS X (unix) version Included patches: 1 Huge version with Carbon GUI. Features included (+) or not (-): ... So both have the GUI built in yet only the OSX version complains about the colour scheme being set.
RE: problem with win32 vim 7.1a.001
Any ideas? Maybe you can rename all your directories named Vim70 to Vim71a. Yep - that was it. C:\Vim\vim70 was renamed to C:\Vim\vim71a and all is well. Thanks! (and also thanks to Tony for the troubleshooting hints)
[PATCH] minor doc patch
Hi Bram, Find attached a patch that properly brackets the use of Enter in the docs. cheers vimdoc-enter-brackets.patch Description: vimdoc-enter-brackets.patch
problem with win32 vim 7.1a.001
Hello vim list, I've just synced up to 7.1a.001 (svn #263) and built on Win32 (MSVC). Everything builds fine and I replace my previous gvim.exe and vim.exe with the newly built versions. I also sync my runtime from ftp.nluug.nl. My vim installation is in: C:\Vim\vim70 My config is in: C:\Vim\_vimrc Additional plugins are in: C:\Vim\vimfiles\... This has always worked fine as this is the structure set up by the vim win32 installer. I now find that launching gvim/vim doesn't find my _vimrc or my vimfiles runtime. I can get it to load my _vimrc by moving it to: C:\Vim\Vim70\_vimrc However my runtime isn't picked up as :scriptnames doesn't list any plugins loaded. Is it just me or has something broken win32 vim? My previous sync was svn#254 (Vim 7.0.236) with a runtime sync from the same time and everything was fine. Any ideas?
[PATCH] minor doc typos
Attached is a small patch that fixes some minor typos in the docs. Specifically to ensure that uses of 'mousemodel' and 'wildchar' were fully quoted so that they can be jumped from. cheers vimdoc.patch Description: vimdoc.patch
RE: Win64-related patches
Hi Bram,
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
cheers
ole_register.patch
Description: ole_register.patch
RE: Win64-related patches
Hi Bram,
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
-
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
I think I've found it. In src/main.c:main(), the call to
gui_prepare()
needs to occur after set_init_1() for two reasons:
1. set_init_1() ends up initialising the options table - and therefore
p_vfile.
2. The win32 implementation of gui_mch_prepare() as called from
gui_prepare() calls ole_error() in an error path. ole_error() calls
through to EMSG2() which eventually uses p_vfile. However since
gui_prepare() is called before set_init_1(), p_vfile has not yet been
initialised.
The attached patch demonstrates the solution by moving gui_prepare()
after set_init_1().
I was over anxious! - attached is the correct patch. The gui_prepare()
must also appear before command_line_scan() so that the -register is
recognised.
cheers
ole_register_corrected.patch
Description: ole_register_corrected.patch
[PATCH] minor typo in tutor
Index: runtime/tutor/tutor === --- runtime/tutor/tutor (revision 218) +++ runtime/tutor/tutor (working copy) @@ -568,10 +568,10 @@ 4. To change every occurrence of a character string between two lines, type :#,#s/old/new/gwhere #,# are the line numbers of the range - of lines where the subsitution is to be done. + of lines where the substitution is to be done. Type :%s/old/new/g to change every occurrence in the whole file. Type :%s/old/new/gc to find every occurrence in the whole file, - with a prompt wether to substitute or not. + with a prompt whether to substitute or not. ~~ LESSON 4 SUMMARY
RE: [PATCH] minor typo in tutor
Hmm.. apologies if my mail client messed that up. Find the patch attached. cheers tutor.patch Description: tutor.patch
RE: Win64-related patches
Michael Wookey wrote:
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
Well, that may fix it, but the problem is that the order of
initializations is violated. Normally all option pointers are not
NULL.
What is the message that triggers this problem? That message should
probably be changed to mch_errmsg().
The actual error message wrapper is src/gui_w32:ole_error() which just
wraps EMSG2(). When calling gvim -register, the error propagates from
src/gui_w32.c:gui_mch_prepare().
I agree that the above patch fixes the symptom of the bug, but not the
true cause.
cheers
RE: Win64-related patches
One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim
-register',
and watch it crash while trying to display an error message.
This seems to fix the bug...
Index: src/message.c
===
--- src/message.c (revision 212)
+++ src/message.c (working copy)
@@ -2987,7 +2987,7 @@
* If 'verbosefile' is set write message in that file.
* Must come before the rest because of updating msg_col.
*/
-if (*p_vfile != NUL)
+if (p_vfile *p_vfile != NUL)
verbose_write(s, maxlen);
if (redir_fd != NULL
Index: src/misc2.c
===
--- src/misc2.c (revision 212)
+++ src/misc2.c (working copy)
@@ -1748,7 +1748,7 @@
return NULL;
}
#endif
-while ((b = *p) != NUL)
+while (p (b = *p) != NUL)
{
if (b == c)
return p;
