vim_is_xterm() and screen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Some folks who like to use vim under GNU screen, myself included, would like the ability for vim to automatically support xterm mouse escape sequences. Would it be a workable solution for vim to include screen as one of the initial strings for terms that trigger truth for vim_is_xterm()? I'm guessing that a problem for this, might be the fact that if vim detects xterm-ish terminals, it automatically tries the t_RV sequence out, which isn't dependably valid for screen. If this is the case, perhaps there could be a vim_might_be_xterm(), which could set ttymouse to xterm, on the off-chance that the terminal may send it xterm-style mouse sequences, but leave t_RV empty so that it doesn't risk sending unrecognized stuff that the terminal may choose to display directly? The thing is, is that users of screen are able to use some other programs, such as elinks, and will wonder why vim can't work just as well. Are there any real impediments to it doing so? I suspect that my solution could actually be made much more simple by simply assuming that all terms might be xterm, thus eliminating the need to actually implement a function (just set ttymouse to xterm by default, again leaving t_RV). Thanks for your feedback. References: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214083 https://bugs.launchpad.net/ubuntu/+source/vim/+bug/113227 - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQBn/7M8hyUobTrERAh1OAJ4ryRB55gWXGwmErt2gHkSVRkIOdwCfSwi8 qD+sS9zpdm3I/Wpsp+hcWHY= =8CI4 -END PGP SIGNATURE-
Re: VimWiki - again - but with a brand new option
Am Montag, den 07.05.2007, 16:07 -0700 schrieb Ian Tegebo: The Wiki would ideally understand how to link to vim-scripts and vim-tips like vimonline currently does. As a bonus, mailing-list posts would also linkable Easy:http://en.wikipedia.org/wiki/Interwiki#Shorthand_for_non-wiki_sites For Wikia: http://www.wikia.com/wiki/Interwiki_map But this touches the critical point: The real question is, howto organize/access existing contributions (and contribution channels) from a wiki. Wikipages are generic, while tips, scripts, plugins, helpfiles etc. have more structure and - perhaps because of that - an established infrastructure. There is nothing against writing new things freely in the wiki and then, afterwards, copy them to svn or make a script/plugin/syntax-file/tutor or whatever ... Probably one could also easily write some html-form that submits a tip/script to the database on vim.org I would like to see the VimWiki as a kind of portal to the plethora of vim-related material. (Recall the slogan: Avoid redundancy!) In such a community-driven portal, each contributor has an interest to get her contribution found. Thus there is no need for a centralized management as on vim.org. A question to the experienced users/developers: How is that plethora organized internally? What are the main (most important, most popular) sections? Sebastian.
Re: Compiling vim in mingw.
Suresh Govindachar wrote:
Bram Moolenaar wrote:
Markus Trenkwalder wrote:
checked out vim-7.1a.001 today from svn (#263) and tried to
compile it with mingw-gcc and got the following error:
8
$ make -f Make_ming.mak
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG
-DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME
-DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -O3
-fomit-frame-pointer -freg-struct-return -s gui_w32.c -o
gobj/gui_w32.o gui_w32.c:236: error: redefinition of `struct
tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct
tagNMTTDISPINFOW' make: *** [gobj/gui_w32.o] Error 1 8
I get the same error message. I recursively grepped for
NMTTDISPINFO and examined the output, but did not find any
redefinition! No clue where the compiler is finding the
redefinitions.
My naive solution to this problem is:
8
--- src/gui_w32.c.000 Mon May 7 08:26:54 2007
+++ src/gui_w32.c Mon May 7 07:01:09 2007
@@ -232,7 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
-#ifndef LPNMTTDISPINFO
+#if !defined(LPNMTTDISPINFO) !defined(TOOLTIPTEXTA)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
8
What does TOOLTIPTEXTA have to do with this? I don't understand
why you try to solve it this way.
Someone else also reported this problem while it worked OK
earlier. Perhaps there is something wrong with the way you
obtained the sources?
(Tony reported working around the error message by not using svn.)
I got the sources from svn the same why I have always been getting
the sources (the whole process of get sources, build, deploy,
update runtime is automated in scripts).
The symbol is defined in mingw in the file '/include/commctrl.h' through
the file '/include/pshpack1.h'. The relevant part in mingw's version of
commctrl.h (starting at line 2368) is:
8
...
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
char szText[80];
HINSTANCE hinst;
UINT uFlags;
#if (_WIN32_IE = 0x0300)
LPARAM lParam;
#endif
} NMTTDISPINFOA, *LPNMTTDISPINFOA;
#define TOOLTIPTEXTANMTTDISPINFOA
#define LPTOOLTIPTEXTA LPNMTTDISPINFOA
...
8
So the only chance I had to detect if tagNMTTDISPINFOA is defined alredy
was to test one of the TOOLTIP macros. I know this is not the most
beautyful solution but I just wanted to show the problem and provide one
possible solution.
I'll try to compile the FTP-sources now and see if the problem still
exists there -- report will follow.
Regards
Markus
Re: Compiling vim in mingw.
Tried the ftp versions (including patch 7.1a.001) now. Same again. And
as Edward Fox told earlier the SVN repository should be almost the same
as CVS.
I also tried to find a better solution but as I could not find macro
that fits better I do also not know any alternative.
Regards
Markus
--
:wq \_ \_\_\_
\_\_ \_\_ \_\_ \_\_ \_\_
/(bb|[^b]{2})/ \_ \_ \_ \_\_\_\_\_\_ \_\_
Markus Trenkwalder \_ \_ \_\_ \_\_ \_\_
[EMAIL PROTECTED] \_ \_ \_\_ \_\_ \_\_
Fragen zu Vim? Kommen Sie zu mich, da werden Sie geholfen! :)
Re: Compiling vim in mingw.
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Tried the ftp versions (including patch 7.1a.001) now. Same again. And
as Edward Fox told earlier the SVN repository should be almost the same
as CVS.
*Almost* the same with ftp versions.
*Definitely* the same with CVS.
I also tried to find a better solution but as I could not find macro
that fits better I do also not know any alternative.
Regards
Markus
--
:wq \_ \_\_\_
\_\_ \_\_ \_\_ \_\_ \_\_
/(bb|[^b]{2})/ \_ \_ \_ \_\_\_\_\_\_ \_\_
Markus Trenkwalder \_ \_ \_\_ \_\_ \_\_
[EMAIL PROTECTED] \_ \_ \_\_ \_\_ \_\_
Fragen zu Vim? Kommen Sie zu mich, da werden Sie geholfen! :)
Re: Compiling vim in mingw.
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Edward L. Fox wrote:
On 5/8/07, Markus Trenkwalder [EMAIL PROTECTED] wrote:
Tried the ftp versions (including patch 7.1a.001) now. Same again. And
as Edward Fox told earlier the SVN repository should be almost the same
as CVS.
*Almost* the same with ftp versions.
*Definitely* the same with CVS.
Exept the revisions ;)
Including revisions. I didn't set any keywords properties at any files
within svn repository. So svn will not update any revisions. :-)
To be honest I wanted to express that with my *almost*.
Regarts
Markus
--
:wq \_ \_\_\_
\_\_ \_\_ \_\_ \_\_ \_\_
/(bb|[^b]{2})/ \_ \_ \_ \_\_\_\_\_\_ \_\_
Markus Trenkwalder \_ \_ \_\_ \_\_ \_\_
[EMAIL PROTECTED] \_ \_ \_\_ \_\_ \_\_
Fragen zu Vim? Kommen Sie zu mich, da werden Sie geholfen! :)
Re: patch 7.1a.001
Bram Moolenaar wrote: Chris Sutcliffe wrote: Hey All, Patch 7.1a.001 I managed to compile 7.1a from cvs yesterday. I went and did a cvs up to grab this patch and I am now getting this error: gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW' mingw32-make: *** [gobj/gui_w32.o] Error 1 I'm guessing it's not a result of this patch, since this patch did not affect gui_w32.c. Perhaps there was something changed in CVS (I notice the update grabbed a whole bunch of files)? I don't know what happened. When I checkout the files from CVS now I don't see a problem in gui_w32.c. Was this a temporary problem? I was able to get it to compile under cygwin using Make_cyg.mak GUI=yes by removing the two typedefs at line 236 and 247 in gui_w32.c. It would seem that the pre-processor doesn't recognise labels from a previous typedef, so the #ifndef LPNMTTDISPINFO test doesn't work as expected. Or it's something along those lines... Robert
Re: patch 7.1a.001
I was able to get it to compile under cygwin using Make_cyg.mak GUI=yes by removing the two typedefs at line 236 and 247 in gui_w32.c. It would seem that the pre-processor doesn't recognise labels from a previous typedef, so the #ifndef LPNMTTDISPINFO test doesn't work as expected. Or it's something along those lines... What I find interesting is that the #ifndef LPNMTTDISPINFO should have caught that LPNMTTDISPINFO was defined in commctrl.h which is included in gui_w48.c included prior to the #ifndef LPNMTTDISPINFO test. I managed to get it to compile by adding a #ifndef __GNUC__ (which should work with both MinGW and Cygwin) guard around lines 235 to 253 (see the attached patch). Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org gui_w32_mingw.patch Description: Binary data
Re: Vim version 7.1a BETA -- runtime files ?
Yakov Lerner wrote: On 5/5/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I compared runtime files form ftp [1] and from svn [2]. Both vims are labeled vim71a. But many runtimes are different. In svn, many files are labeled 2007. In ftp, they are 2006 versions. Why this difference in runtimes ? Yakov [1] ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 [2] https://svn.sourceforge.net/svnroot/vim/vim7 Do I need to hunt down the differences? Please give a specific example. What label are you talking about? At closer examination, differences turned out to be in $Id..$, $Revision..$ $Date...$ lines only, except for one file which has read differences: runtime/autoload/spellfile.vim -- see diffs below. By labels I meant the cvs $Id...$ keywords and other $..$ keywords. Full diffs are attached. Diffs are produced by the script diff-vim-ftp-svn.sh, also attached. Oh, the CVS version lines. I ignore them. In my opinion meta information should not be inside the file. The spellfile.vim script was changed by the one patch that went out for Vim 7.1a. Fixed a conflict with netrw changes that so far went unnoticed. So nothing to worry about. -- Ed's Radiator Shop: The Best Place in Town to Take a Leak. /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
$VIMRUNTIME problem
Hello! On RHEL4 works well! On Fedora Core 6 couldn't automatically determinte $VIMRUNTIME, lacked the last part 'vim71a' in the path when I tried to open a file (say, Foo.hs). Without initial file opening from command line works well. On mingw (Windows XP) couldn't compile the gui version with errors: gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'. Please note, that I downloaded only unix and extra packages. Sorry, I don't have enough time to dig these problems. -- Anatoli Sakhnik.
Re: patch 7.1a.001
Redirecting to the vim-dev list... What I find interesting is that the #ifndef LPNMTTDISPINFO should have caught that LPNMTTDISPINFO was defined in commctrl.h which is included in gui_w48.c included prior to the #ifndef LPNMTTDISPINFO test. As far as I know this is not true because in /usr/include/commctrl.h (or /include/commctrl.h for mingw) the LPNMTTDISPINFO is a typedef and this can't be caught by the preprocessor (correct me if I'm wrong). This may be so, I'm not sure. I managed to get it to compile by adding a #ifndef __GNUC__ (which should work with both MinGW and Cygwin) guard around lines 235 to 253 (see the attached patch). I've tried this for mingw and it works. Maybe this is the better patch for this problem. Works for me on MinGW as well (haven't tried Cygwin). Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org
7.1a patch for Mingw32
It doesn't compile under Mingw32 unless gui_w32.c is patched:
--- gui_w32.c.orig Sat May 05 04:24:58 2007
+++ gui_w32.c Tue May 08 09:01:11 2007
@@ -232,6 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
+#ifndef __MINGW32__
#ifndef LPNMTTDISPINFO
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
@@ -251,6 +252,7 @@
UINT uFlags;
LPARAM lParam;
} NMTTDISPINFOW, *LPNMTTDISPINFOW;
+#endif
#endif
#include poppack.h
Re: surprised by beta
Edward L. Fox wrote: On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version No, there won't be any tags, branches here, every thing is just going linearly, giggling. I just stumbled upon the svn update to disaster myself. Maybe its time to start getting a bit serious about project management? To the svn maintainer: The best practice is for the repository root to look something like this: /trunk (mirror of CVS, as usual) /tags (contains 7.0/ and 7.1a/ folders -- obviously these folders are static) /branches (possibly used for contribs such as patches that didn't make it into trunk (Bram's version) yet) To anyone else afflicted: To downgrade back to 7.0-stable, just do an svn update -r NNN where NNN is the revision you want to downgrade to. Check the logs for the exact revision, I don't know off hand. Cheers, -Robert
Re: $VIMRUNTIME problem
Anatoli Sakhnik wrote: Hello! On RHEL4 works well! On Fedora Core 6 couldn't automatically determinte $VIMRUNTIME, lacked the last part 'vim71a' in the path when I tried to open a file (say, Foo.hs). Without initial file opening from command line works well. On mingw (Windows XP) couldn't compile the gui version with errors: gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'. Please note, that I downloaded only unix and extra packages. Sorry, I don't have enough time to dig these problems. -- Anatoli Sakhnik. What is the output of :version in your FC6 Vim? In particular, does it include lines beginning with the following, and what do they say? fall-back for $VIM: f-b for $VIMRUNTIME: By default (i.e., if no directories were specifically specified at configure time) fall-back for $VIM is /usr/local/share/vim and f-b for $VIMRUNTIME is not shown, which makes it default (in Vim 7.1a) to $VIM/vim71a If you compile Vim yourself, installing your source in a tree rooted at something/vim71a/ then using make followed by make install, it should then install (if you use default install dirs) the binaries in /usr/local/bin and the runtimes in /usr/local/share/vim/vim71a/. This is how it happens on my SuSE 10.2 system; it oughtn't to be any different if you compile Vim yourself on FC6. Of course, you must not mix pre-compiled files from Vim 7.0 with sources from Vim 7.1a; in particular, the first 7.1a build MUST NOT be made in a directory tree with a preexisting configure.cache or a preexisting nonempty auto/ directory from 7.0; It MUST be done from scratch in a build directory tree containing ONLY fresh 7.1a sources. Best regards, Tony. -- Too much of everything is just enough. -- Bob Wier
Re: surprised by beta
On Tuesday 08 May 2007 12:04, you wrote: Edward L. Fox wrote: On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version No, there won't be any tags, branches here, every thing is just going linearly, giggling. I just stumbled upon the svn update to disaster myself. Maybe its time to start getting a bit serious about project management? To the svn maintainer: The best practice is for the repository root to look something like this: /trunk (mirror of CVS, as usual) /tags (contains 7.0/ and 7.1a/ folders -- obviously these folders are static) /branches (possibly used for contribs such as patches that didn't make it into trunk (Bram's version) yet) To anyone else afflicted: To downgrade back to 7.0-stable, just do an svn update -r NNN where NNN is the revision you want to downgrade to. Check the logs for the exact revision, I don't know off hand. Cheers, -Robert the last stable one i had was 7.0.236 -- how would you specify that? not sure i need to, the fixes to filetype.vim were trivial -- a couple of patches only partly applied left '' and '' in it sc
Re: Compiling vim in mingw.
Markus Trenkwalder wrote:
Suresh Govindachar wrote:
Bram Moolenaar wrote:
Markus Trenkwalder wrote:
checked out vim-7.1a.001 today from svn (#263) and tried to
compile it with mingw-gcc and got the following error:
8
$ make -f Make_ming.mak
gcc -c -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H
-DDYNAMIC_GETTEXT -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG
-DFEAT_GUI_W32 -DFEAT_CLIPBOARD -DFEAT_MBYTE -DFEAT_MBYTE_IME
-DDYNAMIC_IME -DDYNAMIC_ICONV -pipe -w -march=i386 -Wall -O3
-fomit-frame-pointer -freg-struct-return -s gui_w32.c -o
gobj/gui_w32.o gui_w32.c:236: error: redefinition of `struct
tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct
tagNMTTDISPINFOW' make: *** [gobj/gui_w32.o] Error 1 8
I get the same error message. I recursively grepped for
NMTTDISPINFO and examined the output, but did not find any
redefinition! No clue where the compiler is finding the
redefinitions.
My naive solution to this problem is:
8
--- src/gui_w32.c.000 Mon May 7 08:26:54 2007
+++ src/gui_w32.c Mon May 7 07:01:09 2007
@@ -232,7 +232,7 @@
LPARAM lParam;
} NMTTDISPINFO_NEW;
-#ifndef LPNMTTDISPINFO
+#if !defined(LPNMTTDISPINFO) !defined(TOOLTIPTEXTA)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
8
What does TOOLTIPTEXTA have to do with this? I don't understand
why you try to solve it this way.
Someone else also reported this problem while it worked OK
earlier. Perhaps there is something wrong with the way you
obtained the sources?
(Tony reported working around the error message by not using svn.)
I got the sources from svn the same why I have always been getting
the sources (the whole process of get sources, build, deploy,
update runtime is automated in scripts).
The symbol is defined in mingw in the file '/include/commctrl.h' through
the file '/include/pshpack1.h'. The relevant part in mingw's version of
commctrl.h (starting at line 2368) is:
8
...
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
LPSTR lpszText;
char szText[80];
HINSTANCE hinst;
UINT uFlags;
#if (_WIN32_IE = 0x0300)
LPARAM lParam;
#endif
} NMTTDISPINFOA, *LPNMTTDISPINFOA;
#define TOOLTIPTEXTANMTTDISPINFOA
#define LPTOOLTIPTEXTA LPNMTTDISPINFOA
...
8
So the only chance I had to detect if tagNMTTDISPINFOA is defined alredy
was to test one of the TOOLTIP macros. I know this is not the most
beautyful solution but I just wanted to show the problem and provide one
possible solution.
I'll try to compile the FTP-sources now and see if the problem still
exists there -- report will follow.
Pity we can't check for typedefs with the preprocessor. It indeed looks
like checking for LPTOOLTIPTEXT not being defined is the best solution,
although it looks weird. Let's add a comment that explains it:
/* Older compilers don't have LPNMTTDISPINFO[AW].
* MingW doesn't define LPNMTTDISPINFO but typedefs it. Therefore check
* LPTOOLTIPTEXT which is defined to be the same. */
#if !defined(LPNMTTDISPINFO) !defined(LPTOOLTIPTEXT)
typedef struct tagNMTTDISPINFOA {
NMHDR hdr;
Hopefully that works for everybody. And without some magic dependency
on MingW or gcc.
--
hundred-and-one symptoms of being an internet addict:
91. It's Saturday afternoon in the middle of May and you
are on computer.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: vim_is_xterm() and screen
Micah Cowan wrote: Some folks who like to use vim under GNU screen, myself included, would like the ability for vim to automatically support xterm mouse escape sequences. Would it be a workable solution for vim to include screen as one of the initial strings for terms that trigger truth for vim_is_xterm()? No, because screen is not an xterm. The screen termcap/terminfo entry differs from xterm. I'm guessing that a problem for this, might be the fact that if vim detects xterm-ish terminals, it automatically tries the t_RV sequence out, which isn't dependably valid for screen. If this is the case, perhaps there could be a vim_might_be_xterm(), which could set ttymouse to xterm, on the off-chance that the terminal may send it xterm-style mouse sequences, but leave t_RV empty so that it doesn't risk sending unrecognized stuff that the terminal may choose to display directly? The thing is, is that users of screen are able to use some other programs, such as elinks, and will wonder why vim can't work just as well. Are there any real impediments to it doing so? I suspect that my solution could actually be made much more simple by simply assuming that all terms might be xterm, thus eliminating the need to actually implement a function (just set ttymouse to xterm by default, again leaving t_RV). There doesn't appear to be a standard for mouse escape sequences. And termcap/terminfo is too limited for the features of modern terminal emulaters. That means the only choice for Vim is to implement mouse support for each terminal separately. If screen uses the same codes as xterm then this should be relatively simple. It's about time termcap/terminfo gets updated to support the features we need, instead of hacking solutions in all programs. I'm afraid I don't have time for this (the original development of termcap was closely related to the early development of vi). -- From know your smileys: :-)-O Smiling doctor with stethoscope /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: surprised by beta
Mr Toothpik wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me What errors? -- How many light bulbs does it take to change a person? /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: VimWiki - again - but with a brand new option
Ian Tegebo wrote: On 5/6/07, Sebastian Menge [EMAIL PROTECTED] wrote: Hi all Independent of the implementation used, I suggest to develop good guidelines. The Wiki should be really valuable and not redundant to vim-tips or mailing-lists. I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. Please use the wiki for tips. That is an addition to the help files. For example, I would love to be able to quickly correct spelling mistakes or contribute to plugin helpfiles a la a Wiki interface. I could then imagine updating my local helpfiles through the Wiki interface via a sync-plugin. If you see spelling mistakes in the help files please send them to me. I just fixed 250 of them, because someone send me a list. That's useful for everyone. The main goal now is to get the Vim tips collection back to live. It has been dead for three months now! Perhaps we can figure out some clever way to also make the help files available with links between the tips and the help files. Thus in the help file you would see some link that takes you to a tip associated with the text at that position. But without that the tips are still very useful. -- From know your smileys: O:-) Saint /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
Re: $VIMRUNTIME problem
Hi there! I'm sorry having troubled you. I often type `vi' instead of `vim' for brevity. Usually, I substitute the former of the system with a link to vim, but this time I missed that fact (by the way, not for the first time). So, there's no problem with linux compilation and running at all. Probably, I'll look at the problem with compilation under windows the day after tomorrow if the problem won't have been solved by that time (I have no possibility just at the moment at all). -- Anatoli Sakhnik. On 08/05/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: Anatoli Sakhnik wrote: Hello! On RHEL4 works well! On Fedora Core 6 couldn't automatically determinte $VIMRUNTIME, lacked the last part 'vim71a' in the path when I tried to open a file (say, Foo.hs). Without initial file opening from command line works well. On mingw (Windows XP) couldn't compile the gui version with errors: gui_w32.c:236: error: redefinition of `struct tagNMTTDISPINFOA' gui_w32.c:246: error: redefinition of `struct tagNMTTDISPINFOW'. Please note, that I downloaded only unix and extra packages. Sorry, I don't have enough time to dig these problems. -- Anatoli Sakhnik. What is the output of :version in your FC6 Vim? In particular, does it include lines beginning with the following, and what do they say? fall-back for $VIM: f-b for $VIMRUNTIME: By default (i.e., if no directories were specifically specified at configure time) fall-back for $VIM is /usr/local/share/vim and f-b for $VIMRUNTIME is not shown, which makes it default (in Vim 7.1a) to $VIM/vim71a If you compile Vim yourself, installing your source in a tree rooted at something/vim71a/ then using make followed by make install, it should then install (if you use default install dirs) the binaries in /usr/local/bin and the runtimes in /usr/local/share/vim/vim71a/. This is how it happens on my SuSE 10.2 system; it oughtn't to be any different if you compile Vim yourself on FC6. Of course, you must not mix pre-compiled files from Vim 7.0 with sources from Vim 7.1a; in particular, the first 7.1a build MUST NOT be made in a directory tree with a preexisting configure.cache or a preexisting nonempty auto/ directory from 7.0; It MUST be done from scratch in a build directory tree containing ONLY fresh 7.1a sources. Best regards, Tony. -- Too much of everything is just enough. -- Bob Wier
Re: surprised by beta
Bram Moolenaar wrote: Mr Toothpik wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me What errors? Bram, The SVN Repos has conflict markers left in the file filetype.vim, effectively causing syntax errors. This issue is specific to the SVN repository (CVS/FTP users unaffected). I think a conflict occurred when the 7.1a patch 1 was merged in, and that conflict was never resolved by the SVN maintainer. This conflict can be trivially fixed be removing the conflict markers (, and ==). I didn't take a close look at the issue though. -Robert
Re: surprised by beta
On Tue, May 08, 2007 at 04:50:36PM -0500, Robert Lee wrote: The SVN Repos has conflict markers left in the file filetype.vim, Sorry for the silly question, but the answer is not clear to me from your text: is your working copy that has conflict markers or the last committed version in the repository which has been committed without removing conflict markers? -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time
Re: vim_is_xterm() and screen
Doh! I accidentally sent this directly to Bram, instead of to list :/ Bram Moolenaar wrote: I'm guessing that a problem for this, might be the fact that if vim detects xterm-ish terminals, it automatically tries the t_RV sequence out, which isn't dependably valid for screen. If this is the case, perhaps there could be a vim_might_be_xterm(), which could set ttymouse to xterm, on the off-chance that the terminal may send it xterm-style mouse sequences, but leave t_RV empty so that it doesn't risk sending unrecognized stuff that the terminal may choose to display directly? The thing is, is that users of screen are able to use some other programs, such as elinks, and will wonder why vim can't work just as well. Are there any real impediments to it doing so? I suspect that my solution could actually be made much more simple by simply assuming that all terms might be xterm, thus eliminating the need to actually implement a function (just set ttymouse to xterm by default, again leaving t_RV). There doesn't appear to be a standard for mouse escape sequences. And termcap/terminfo is too limited for the features of modern terminal emulaters. That means the only choice for Vim is to implement mouse support for each terminal separately. If screen uses the same codes as xterm then this should be relatively simple. The de facto standard (aside from the limited support that /is/ offered via terminfo) would seem to be xterm... plus maybe whatever it is that gpm uses. It's about time termcap/terminfo gets updated to support the features we need, instead of hacking solutions in all programs. I'm afraid I don't have time for this (the original development of termcap was closely related to the early development of vi). But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. I agree that fixing terminfo is the right solution, but that doesn't mean you shouldn't hack the working solution in now. You have already done so, or you wouldn't have any mouse support for the various xterm-like consoles in the first place. I'd be happy to write the patch (it should be pretty straightforward); I just want to get some agreement on the correct action to take. -- Thanks, Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: vim_is_xterm() and screen
On Tue, May 08, 2007 at 03:04:10PM -0700, Micah Cowan wrote: It's about time termcap/terminfo gets updated to support the features we need, instead of hacking solutions in all programs. I'm afraid I don't have time for this (the original development of termcap was closely related to the early development of vi). But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. I agree that fixing terminfo is the right solution, but that doesn't mean you shouldn't hack the working solution in now. You have already done so, or you wouldn't have any mouse support for the various xterm-like consoles in the first place. I'd be happy to write the patch (it should be pretty straightforward); I just want to get some agreement on the correct action to take. I for one would *love* to see this. I use mrxvt all the time. The terminal codes for mrxvt are somewhere between xterm and rxvt, thus mrxvt should have its own terminal type. However a *lot* of programs (including Vim and w3m) simply refuse to use the mouse if the terminal name is not rxvt or xterm. The ugly hack used my mrxvt right now is to install it's terminfo entry under the name rxvt! Numerous mrxvt users have complained about this. It would be nice if things could be made to work correctly with other terminals. GI PS: Mrxvt's mouse reporting is the same as the old xterm style mouse reporting. -- Reading while sunbathing makes you well-red.
Re: surprised by beta
Stefano Zacchiroli wrote: On Tue, May 08, 2007 at 04:50:36PM -0500, Robert Lee wrote: The SVN Repos has conflict markers left in the file filetype.vim, Sorry for the silly question, but the answer is not clear to me from your text: is your working copy that has conflict markers or the last committed version in the repository which has been committed without removing conflict markers? I assumed the repository as I make no local changes to my checkout and didn't get any errors back from svn update. I ran the update yesterday and got r263. Everything compiled smooth, but I got errors on startup. I did an svn update -r 260 without thinking much of it (I thought maybe I compiled wrong -- and maybe I did). Revision 260 is what I was running before I did the update yesterday and is running again now without a hitch. To be honest, I never investigated the issue enough to know the exact problem, but whatever it was, it was either caused by me and is unrelated to Scott's issue, or is in the repository somewhere between r260 and r263. Based on the specific information provided by Scott, I assumed that there are markers left in the file in the repository. To check for myself, I just did a fresh checkout into a new folder of r263 and I see no markers there, so maybe I did compile wrong after all. The diff of 262:263 is gigantic at over 2mb (Bram, you've been busy!), so I don't know if I want to pour over it too much more than I have already. Scott: Do you still have the version of filetype.vim with the markers in it? I overwrote the r263 checkout I had trouble with :(. By the way, to get out of 7.1a.001 and back to 7.0.243 (which I assume is what you wanted to begin with), just use: svn update -r 261 and recompile. -Robert
Re: vim_is_xterm() and screen
Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 221. Your wife melts your keyboard in the oven.
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). Hrm, yes, that could be a problem. I'm guessing the conflict has to do with vim needing to actually signal to the terminal which style of mouse code to send? (I had forgotten that this signal was necessary, which is silly, since bad things would happen if it wasn't.) Alright, then, looks like the only way forward is to fix terminfo, as Bram has suggested. I just noticed that the screen info manual has a section on termcap extensions that it supports, including a XT boolean to indicate support for xterm mouse and OSC (with which I'm not familiar). Perhaps that would be appropriate to prod the ncurses guys to support... Except, if it really is a conflict, I'm wondering how does elinks manages to do it? -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
[Announcement] Subversion repository location changed
Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
Could you please give me the most bleeding-edge sources?
Hi Bram, I noticed that you also maintained another CVS repository besides the sf.net's CVS repository. And many changes to that internal CVS won't be applied to the sf.net's CVS repository unless a large release is to be made. In my opinion, as the SVN repository is now standardized, could you please give me the most bleeding-edge sources so that I can commit them into the trunk/ directory of the SVN repository, and some users who wish to use the unstable experimental version then can help you to test the code. Best regards, Edward L. Fox
Re: WARNING! Don't update your local svn repository now!
On 5/9/07, Edward L. Fox [EMAIL PROTECTED] wrote: Hi Vimmers, As many many people requested, I finally decide to obey the svn book's advice and will build up trunk/ tags/ and branches/. But so far as you know, sf.net's svn service is not in a good status so I'm not able to commit all changes once. So I have to commit many times to build up this structure. So, PLEASE DON'T UPDATE YOUR LOCAL SVN REPOSITORY UNTIL THE WORK IS DONE. OR YOU WILL GET A CORRUPTED VERSION. Best regards, Edward L. Fox Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Regards, Edward L. Fox
(Doc bug) Error in options.txt
One word under :help 'ttymouse' was obviously forgotten when that option got
more possible settings. See suggested patch, attached.
Best regards,
Tony.
--
You should never wear your best trousers when you go out to fight for
freedom and liberty.
-- Henrik Ibsen
*** ../vim71a/runtime/doc/options.txt Mon May 7 23:03:49 2007
--- runtime/doc/options.txt Wed May 9 03:02:49 2007
***
*** 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 05
VIM REFERENCE MANUAL by Bram Moolenaar
--- 1,4
! *options.txt* For Vim version 7.1a. Last change: 2007 May 09
VIM REFERENCE MANUAL by Bram Moolenaar
***
*** 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these three strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
--- 7031,7037
{only in Unix and VMS, doesn't work in the GUI; not
available when compiled without |+mouse|}
Name of the terminal type for which mouse codes are to be recognized.
! Currently these six strings are valid:
*xterm-mouse*
xterm xterm-like mouse handling. The mouse generates
Esc[Mscr, where scr is three bytes:
RE: [Announcement] Subversion repository location changed
Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? --Suresh
Re: vim_is_xterm() and screen
A.J.Mechelynck wrote: Micah Cowan wrote: [...] But you already have hacked support into your programs for mouse support. Now that you've done that, couldn't you just open it up a bit? Is there anything wrong with always recognizing the appropriate xterm sequences (provided that they don't first match a valid terminfo entry)? This is the approach that elinks seems to take, and I don't see any particular reason why vim couldn't do this as well. [...] There are conflicts between xterm mouse codes and DEC mouse codes. See :help 'ttymouse' for details (and, maybe, for a way of telling Vim which mouse is installed). I did some digging in the screen source code, and determined that when screen receives DECSET with one of the mouse-reporting params (9, 1000, 1001), it first checks (using the stupid name magic, unless the user happens to be using termcap instead of terminfo, and has the special screen extension for xterm included) which of the terminals connected to a session (there may be more than one) support the xterm controls, and then sets mouse mode on the terminals that have been detected as xterms corresponding to the sequence it got. Then all sequences that the terminal sends get passed through to the application. For those terminals that are not detected as xterms (have either the string xterm or rxvt in the terminal name), the mode is not sent through at all. Therefore, there would seem to be no harm whatsoever in detecting screen as an xterm-mouse-code-capable terminal, and sending the mouse-mode sequence (xterm protocol, since AFAIK screen provides no way to detect the underlying xterm version). If the underlying terminal claims to be xterm or rxvt, then the user will automatically get the benefit of mouse support without trouble; otherwise, screen will simply ignore the sequence and no harm is done to other terminals (such as unrecognized sequence-emitters, or DEC-mouse-only terminals). I propose that rather than using vim_is_xterm() to determine xterm-style mouse support, a separate function, vim_supports_xterm_mouse() [or somesuch] be used, which would currently return (vim_is_xterm() || terminal is screen). -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: surprised by beta
On Tuesday 08 May 2007 15:32, you wrote: Mr Toothpik wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me What errors? i'm sorry bram, i didn't write them down, i didn't save the buggy 'filetype.vim', i just fixed it -- my bad -- but it was obvious there was an uncommitted patch or something -- there were and in it in two places they were syntax errors, and the comments around the were something to do with mine and r263, as memory serves they were replacing coronary with coronaryRespite or whatever that thread was sc
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: [Announcement] Subversion repository location changed
On 5/9/07, Suresh Govindachar [EMAIL PROTECTED] wrote: Edward L. Fox announced: Hi Vimmers, The directories structure of the Subversion repository has been changed. Please use this command to checkout the latest sources: svn co https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 vim7 If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 Hope this change won't bother you too much. Shouldn't there be vim7.1a (the a'th candidate for 7.1) today, and eventually, when Bram releases version 7.1, vim7.1? So is the last argument to svn co correct? And isn't today's branch/trunk/whatever 7.1a rather than 7.1? 7.1, not 7.1a. Because as the alphabetical version changes so fast, personally I don't want to create too many branches for that. --Suresh
Re: surprised by beta
On 5/8/07, scott [EMAIL PROTECTED] wrote: i was surpised by the fact that simply running 'svn update' bumped me up to 7.1a -- from previous posts i had thought there was something extra that had to be done to get the beta, like create a new 71a directory or something now i've got the beta i feel committed, and will commence chasing after the errors it spews from /usr/local/share/vim/vim71a/filetype.vim when i run it -- apparently the install created the 71a directory for me i am not asking any questions here, it's more like i'm warning those who may prefer to stay with a stable version Maybe you'll be surprised again today... Don't simply svn up. Take care~
Re: VimWiki - again - but with a brand new option
On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. A wiki allows every Tom, Dick and Harry to make changes to it, whether they know what they're talking about or not. Wikis are useful, but it's difficult to ensure their correctness. Requiring Bram to vet every page before it is included in vim's help files would be an undue burden on him as well as a poor use of his time. A wiki is a good idea, but the content should be separate from the help files. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: VimWiki - again - but with a brand new option
On 5/8/07, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-05-08, Ian Tegebo [EMAIL PROTECTED] wrote: On 5/8/07, Bram Moolenaar [EMAIL PROTECTED] wrote: Ian Tegebo wrote: I would like to make another implementation independent suggestion; one could make a VimWiki more valuable by importing the _extremely_ valuable vim helpfiles into it. Please don't do this. It might sound like a nice idea, but it means making a branch that will be very hard to merge back into the help files of the distribution. I feel misunderstood but it serves me right for not saying what I mean... Synchronizing data is no fun, I agree. While I was up in the clouds I was imaging that the wiki would be the authoritative source for the helpfiles after doing an initial _import_. Then the text version would be exported as needed, e.g. end user runtime update or for a new release. This seems like a bad idea. The vim help files are an authoritative source because their content is under the control of an authority: Bram. Others are encouraged to submit patches that correct errors or clarify wording, but before any of those patches are applied, Bram looks at them to be sure they are correct and consistent with the help files' style. I was assuming the wiki that would be chosen would allow for some level of access control. I'm also assuming a group of trusted long-time users could be delegated the responsibility of administering the wiki. If Bram is the only one who should make changes to an object than I agree that those objects wouldn't be useful in a wiki. I think it's possible to have a protected part of the wiki for helpfiles that is write restricted and have another part that is more open that can easily reference those files. Of course, if the value added by more hands on the helpfiles doesn't exceed the cost in maintenance than this is a poor choice. I don't think I've really seen any issues with updates to helpfiles, they were just an example. So far I think the point was to just be able to link to parts of them more easily - I didn't really mean to dwell on the help system. I was just hoping to carry the point that wikis _can_ provide a lot of valuable function if properly cultivated. In all this I've lost track of what the purpose of a VimWiki would be. Was it just meant to host vim tips? Thinking about the format of tips now, I wonder if a blog format wouldn't be more suitable. For example, tips are posts that then have comments while most blogs have these features as well as search and RSS. VimBlog? To this end I wonder if there are enough people to support more apps given the work load the vimonline team has: Bugs https://sourceforge.net/tracker/?atid=391887group_id=27891func=browse Features https://sourceforge.net/tracker/?atid=391890group_id=27891func=browse -- Ian Tegebo
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.
