Re: Vim updates
On Sun, 2006-08-13 at 00:04 +0200, Bram Moolenaar wrote: > Previously Tony made patched versions available. He stopped doing that > when his computer broke down. Perhaps someone else can volunteer to do > this now. Hello Bram, I got a few replies to this request already and what Steve has to offer looks quite interesting to me. I only need to figure out (pretty soon) in how differently his setup stuff works from the one you offered. He mentioned NSIS-Install vs. Nullsoft Installer. What matters for me at the end is that I get the same files, same installation to use VIM at the end. mfg, Ali Akcaagac
Re: Vim updates
Bram Moolenaar wrote: Ali Akcaagac wrote: On my home Linux system I can easily compile and install every patch you release for Vim, same applies for the MorphOS versions that I from time to time create and release for our users but for Windows - which I need to use at work - I am stuck with the *.exe setup files as found on vim.org and thus can not test updates to report back problems or give feedback. Now the patchlevel has reached .051. Is there by any chance a way to release full binary "setup" snapshots of vim ? Say is there a way or automate process that might generate a setup say once a week and put it up on vim.org ? I don't make executables for every patched version. It simply takes too much time to do this for every patch. I'm currently checking in every patch in CVS, that already is a huge slowdown. Previously Tony made patched versions available. He stopped doing that when his computer broke down. Perhaps someone else can volunteer to do this now. Steve Hall has picked up the tools fallen from my hands ;-), and does it better than I ever did, see my earlier post on this thread. Best regards, Tony.
Re: failure notice
Bram Moolenaar wrote: Tony Mechelynck wrote: Bram Moolenaar wrote: Edward L. Fox wrote: [...] The menu.vim file should never change 'encoding'. It should load menus that are appropriate for the current 'encoding' and language. But gvim doesn't support an encoding named 'gbk'. If the system encoding is 'gbk', the menu and toolbar get malformed. What do you mean by "system encoding"? How does Vim see this? [...] I "think" he means the charset part of the "system locale", as used to set 'encoding' before sourcing the [._]vimrc. $LC_CTYPE maybe? On my Windows system "gvim -u NONE" shows all strings preset to 'French_Belgium.1252' and gvim starts up in French and Latin1; on Linux I have $LC_CTYPE='en_US.UTF-8', the rest empty in bash, set to "C" in gvim, and gvim starts up in English and in UTF-8. IIRC, Edward had zh_CN.gbk and his gvim started in Chinese with unreadable menus and tooltips. Making "gbk" an alias for "cp936" solved the menu problem, but only partially the tooltip problem. I suspect a byte-counting bug in one or more of the routines responsible for the tooltips' storage and display, manifesting on multibyte locales like CP936. If this is on Unix, I don't think that cp936 is completely supported. I can make gbk an alias for cp936, but I don't think it will help much. Edward had it on Windows. From ":help encoding-values" I gather that "Chinese" and "prc" are alias to cp936 / euc-cn. Maybe gbk and gb18030 can be added to the "family"? Best regards, Tony.
Re: failure notice
Tony Mechelynck wrote: > Bram Moolenaar wrote: > > Edward L. Fox wrote: > [...] > >>> The menu.vim file should never change 'encoding'. It should load menus > >>> that are appropriate for the current 'encoding' and language. > >> But gvim doesn't support an encoding named 'gbk'. If the system > >> encoding is 'gbk', the menu and toolbar get malformed. > > > > What do you mean by "system encoding"? How does Vim see this? > [...] > > I "think" he means the charset part of the "system locale", as used to > set 'encoding' before sourcing the [._]vimrc. $LC_CTYPE maybe? On my > Windows system "gvim -u NONE" shows all strings preset to > 'French_Belgium.1252' and gvim starts up in French and Latin1; on Linux > I have $LC_CTYPE='en_US.UTF-8', the rest empty in bash, set to "C" in > gvim, and gvim starts up in English and in UTF-8. IIRC, Edward had > zh_CN.gbk and his gvim started in Chinese with unreadable menus and > tooltips. Making "gbk" an alias for "cp936" solved the menu problem, but > only partially the tooltip problem. I suspect a byte-counting bug in one > or more of the routines responsible for the tooltips' storage and > display, manifesting on multibyte locales like CP936. If this is on Unix, I don't think that cp936 is completely supported. I can make gbk an alias for cp936, but I don't think it will help much. -- hundred-and-one symptoms of being an internet addict: 125. You begin to wonder how often it REALLY is necessary to get up and shower or bathe. /// 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 updates
Ali Akcaagac wrote: > On my home Linux system I can easily compile and install every patch you > release for Vim, same applies for the MorphOS versions that I from time > to time create and release for our users but for Windows - which I need > to use at work - I am stuck with the *.exe setup files as found on > vim.org and thus can not test updates to report back problems or give > feedback. Now the patchlevel has reached .051. > > Is there by any chance a way to release full binary "setup" snapshots of > vim ? Say is there a way or automate process that might generate a setup > say once a week and put it up on vim.org ? I don't make executables for every patched version. It simply takes too much time to do this for every patch. I'm currently checking in every patch in CVS, that already is a huge slowdown. Previously Tony made patched versions available. He stopped doing that when his computer broke down. Perhaps someone else can volunteer to do this now. -- hundred-and-one symptoms of being an internet addict: 124. You begin conversations with, "Who is your internet service provider?" /// 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: failure notice
Edward L. Fox wrote: > On 8/12/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > [...] > > > But gvim doesn't support an encoding named 'gbk'. If the system > > > encoding is 'gbk', the menu and toolbar get malformed. > > > > What do you mean by "system encoding"? How does Vim see this? > > I meant the $LANG variable. > > GBK is right an alias of cp936, so it is proper to add this alias > entry into mbyte.c. But the situation with GB18030 was much more > complicated and the current version of gvim is not able to handle it > correctly. About GB18030 there is another long and not-so-funny but > ridiculous story. If you like, I can tell you the detailed GOSSIP > later... > > Because over 99% part of GB18030 and GBK is the same, and the > remaining part is too difficult to handle, I want to set GB18030 as > another alias of cp936. Do you think it is OK? I can alias gbk and gb18030 to cp936. But does setting 'encoding' to cp936 really work on a non-Windows system? If not then the alias won't help. > > [...] > > > > You may have uncovered a bug that went unnoticed so far. Please try to > > discover what causes this problem. I can't guess why the last character > > is messed up, looks strange. > > In fact this bug was noticed years before. But most of the Chinese > people decided to tolerate this situation. Anyway, I'm going to work > on~ Yeah, I have noticed that Asian people don't often report problems. Fixing them would still be nice! -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? /// 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's mch_FullName() function and ClearCase versioned file names
On 8/12/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> > > If you open a file under ClearCase using the full path name and a > version extension, e.g., > > /project/xyz/system/src/bar.c@@/main/42 If I'm not mistaken, 42 is version name here, and your problem is that such pathname does not have .c extension. How about creating "automatic" symlinks: have autocommand autocreate symlinks these lines: :au BufNew /project/xyz/system/src/*.v*.c :!ver=`basename .c | sed 's/^.*\.v//'`; base=`basename .c | sed 's/\.v[0-9]*\$//`; ln -s /project/xyz/system/src/\$base.c@@/main/\$ver This is untested, but the idea is that when you open % vim bar.v42.c the proper symlink is automatically created to version 42 of bar.c This solves the problem of proper extension and of ugly @@ filenames. Yakov
Re: BCC 5.5 build is broken (but here is a fix)
Mark S. Williams wrote:
Thanks, Tony.
I did some digging. The change in question was in svn revision 57. It
appears to have introduced some sort of order-of-declaration problem
between BCC and the rest of the world. ;-)
Below is an svn patch that works for me, and the svn diff for if_ole.cpp.
Cheers,
-Mark
svn patch:
Index: if_ole.cpp
===
--- if_ole.cpp (revision 63)
+++ if_ole.cpp (working copy)
@@ -13,14 +13,19 @@
* See os_mswin.c for the client side.
*/
+#ifndef __BORLANDC__
extern "C" {
#include "vim.h"
}
+#endif
#include
#include
extern "C" {
+#ifdef __BORLANDC__
+#include "vim.h"
+#endif
extern HWND s_hwnd;
extern HWND vim_parent_hwnd;
}
The diff from revision 56:
D:\vim7\vim7\src>svn diff --revision 56:63 if_ole.cpp
Index: if_ole.cpp
===
--- if_ole.cpp (revision 56)
+++ if_ole.cpp (revision 63)
@@ -13,11 +13,14 @@
* See os_mswin.c for the client side.
*/
+extern "C" {
+#include "vim.h"
+}
+
#include
#include
extern "C" {
-#include "vim.h"
extern HWND s_hwnd;
extern HWND vim_parent_hwnd;
}
Hm. Bram must have had a reason to move vim.h up in the first place.
Let's look at the patches' README... I guess the change corresponds to
the following patch:
1741 7.0.045 (extra) Win32: MSVC 2005 compiler warnings for OLE version
Let's dig the patch headers... Yeah, that's it:
Patch 7.0.045 (extra)
Problem:Win32: Warnings when compiling OLE version with MSVC 2005.
Solution: Move including vim.h to before windows.h. (Ilya Bobir)
Files: src/if_ole.cpp
I wonder what it is, that MSVC needs vim.h before windows.h, and BCC
needs it after... And if the "right" order varies from one compiler to
the next, I wonder what is best for gcc... Well, Steve already compiled
a 7.0.51 for Windows with gcc, apparently without problems. Is anyone
actually _using_ that OLE interface? Do the OLE functions work (after
patch 45)? And which compiler was used?
Best regards,
Tony.
Re: BCC 5.5 build is broken (but here is a fix)
Thanks, Tony.
I did some digging. The change in question was in svn revision 57. It
appears to have introduced some sort of order-of-declaration problem
between BCC and the rest of the world. ;-)
Below is an svn patch that works for me, and the svn diff for if_ole.cpp.
Cheers,
-Mark
svn patch:
Index: if_ole.cpp
===
--- if_ole.cpp (revision 63)
+++ if_ole.cpp (working copy)
@@ -13,14 +13,19 @@
* See os_mswin.c for the client side.
*/
+#ifndef __BORLANDC__
extern "C" {
#include "vim.h"
}
+#endif
#include
#include
extern "C" {
+#ifdef __BORLANDC__
+#include "vim.h"
+#endif
extern HWND s_hwnd;
extern HWND vim_parent_hwnd;
}
The diff from revision 56:
D:\vim7\vim7\src>svn diff --revision 56:63 if_ole.cpp
Index: if_ole.cpp
===
--- if_ole.cpp (revision 56)
+++ if_ole.cpp (revision 63)
@@ -13,11 +13,14 @@
* See os_mswin.c for the client side.
*/
+extern "C" {
+#include "vim.h"
+}
+
#include
#include
extern "C" {
-#include "vim.h"
extern HWND s_hwnd;
extern HWND vim_parent_hwnd;
}
A.J.Mechelynck wrote:
Mark S. Williams wrote:
Hello all,
I've been successfully building Vim 7 using BCC 5.5, but it seems a
recent update has broken it:
D:\vim7>build
U vim7\configure
U vim7\runtime\plugin\matchparen.vim
U vim7\runtime\autoload\gzip.vim
U vim7\runtime\scripts.vim
U vim7\src\netbeans.c
U vim7\src\option.c
U vim7\src\if_perl.xs
U vim7\src\if_ole.cpp
U vim7\src\version.c
U vim7\src\configure
Checked out revision 63.
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
if_ole.cpp:
Error E2132 d:\borland\bcc55\include\stdlib.h 434: Templates and
overloaded operators cannot have C linkage
Error E2040 d:\borland\bcc55\include\stdlib.h 434: Declaration
terminated incorrectly
Error E2190 d:\borland\bcc55\include\stdlib.h 498: Unexpected }
Error E2316 d:\borland\bcc55\include\stdlib.h 505: '_argc' is not a
member of 'std'
Error E2272 d:\borland\bcc55\include\stdlib.h 505: Identifier expected
Error E2316 d:\borland\bcc55\include\stdlib.h 506: '_argv' is not a
member of 'std'
Error E2272 d:\borland\bcc55\include\stdlib.h 506: Identifier expected
Error E2316 d:\borland\bcc55\include\stdlib.h 603: 'min' is not a
member of 'std'
Error E2272 d:\borland\bcc55\include\stdlib.h 603: Identifier expected
Error E2316 d:\borland\bcc55\include\stdlib.h 604: 'max' is not a
member of 'std'
Error E2272 d:\borland\bcc55\include\stdlib.h 604: Identifier expected
*** 11 errors in Compile ***
** error 1 ** deleting WIN32\oleobj\if_ole.obj
Cheers,
-Mark
What surprises me is that all the errors above appears to be in
stdlib.h, a Borland source file, not in a Vim source file. If it were a
collision between a declaration in a Vim source and a declaration in a
system C file, the messages ought to be more explicit. You might try and
see what is declared ar line 434 of stdlib.h to see what the error might
be (if there is one) in the Vim source.
I've had trouble building with BCC32 in the past. Trouble enough that
I've switched to cygwin, see
http://users.skynet.be/antoine.mechelynck/vim/compile.htm . However,
nowadays Steve Hall is distributing upgraded Vim installers for Windows
(currently 7.0.51), see
https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721
so if the executables contained therein include what you need, maybe you
don't have to compile at all anymore. :-) You may see the ":version"
text by clicking on "Notes" next to the version number; basically it's a
big GUI version, +ole -mzscheme +perl/dyn +python/dyn +ruby/dyn
+tcl/dyn. A similar console version is included.
Best regards,
Tony.
Re: Vim's mch_FullName() function and ClearCase versioned file names
On 8/12/06, Gary Johnson <[EMAIL PROTECTED]> wrote:
I just finished troubleshooting a problem that had several
contributing factors, one of which was the way Vim's mch_FullName()
function behaves with ClearCase versioned file names.
If you open a file under ClearCase using the full path name and a
version extension, e.g.,
/project/xyz/system/src/bar.c@@/main/42
Vim will ask mch_FullName() for the full name of that file.
mch_FullName() will then extract everything to the left of the last
'/' as the directory containing the file and chdir() to that
directory, e.g.,
chdir("/project/xyz/system/src/bar.c@@/main")
mch_FullName() then calls getcwd() to determine the operating
system's name for that directory, which from ClearCase is
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
mch_FullName() then puts back the trailing "file name" of "42" in
this case and returns the full file name as
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main/42
This is the name that is then given to the buffer used for that file
and which appears in the status line.
This is a valid file name which points to the correct file and works
with most external commands. However, it does not work with those
external commands or Vim autocommands whose behavior depend on the
file name suffix. It's also really ugly in the status line.
How about using a symlink ?
Regarding statusline, you can use custom statusline
and replace %f to %{MyFilename()} which knows to handle @@.
Yakov
Re: BCC 5.5 build is broken
Mark S. Williams wrote: Hello all, I've been successfully building Vim 7 using BCC 5.5, but it seems a recent update has broken it: D:\vim7>build U vim7\configure U vim7\runtime\plugin\matchparen.vim U vim7\runtime\autoload\gzip.vim U vim7\runtime\scripts.vim U vim7\src\netbeans.c U vim7\src\option.c U vim7\src\if_perl.xs U vim7\src\if_ole.cpp U vim7\src\version.c U vim7\src\configure Checked out revision 63. Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland if_ole.cpp: Error E2132 d:\borland\bcc55\include\stdlib.h 434: Templates and overloaded operators cannot have C linkage Error E2040 d:\borland\bcc55\include\stdlib.h 434: Declaration terminated incorrectly Error E2190 d:\borland\bcc55\include\stdlib.h 498: Unexpected } Error E2316 d:\borland\bcc55\include\stdlib.h 505: '_argc' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 505: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 506: '_argv' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 506: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 603: 'min' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 603: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 604: 'max' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 604: Identifier expected *** 11 errors in Compile *** ** error 1 ** deleting WIN32\oleobj\if_ole.obj Cheers, -Mark What surprises me is that all the errors above appears to be in stdlib.h, a Borland source file, not in a Vim source file. If it were a collision between a declaration in a Vim source and a declaration in a system C file, the messages ought to be more explicit. You might try and see what is declared ar line 434 of stdlib.h to see what the error might be (if there is one) in the Vim source. I've had trouble building with BCC32 in the past. Trouble enough that I've switched to cygwin, see http://users.skynet.be/antoine.mechelynck/vim/compile.htm . However, nowadays Steve Hall is distributing upgraded Vim installers for Windows (currently 7.0.51), see https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721 so if the executables contained therein include what you need, maybe you don't have to compile at all anymore. :-) You may see the ":version" text by clicking on "Notes" next to the version number; basically it's a big GUI version, +ole -mzscheme +perl/dyn +python/dyn +ruby/dyn +tcl/dyn. A similar console version is included. Best regards, Tony.
BCC 5.5 build is broken
Hello all, I've been successfully building Vim 7 using BCC 5.5, but it seems a recent update has broken it: D:\vim7>build U vim7\configure U vim7\runtime\plugin\matchparen.vim U vim7\runtime\autoload\gzip.vim U vim7\runtime\scripts.vim U vim7\src\netbeans.c U vim7\src\option.c U vim7\src\if_perl.xs U vim7\src\if_ole.cpp U vim7\src\version.c U vim7\src\configure Checked out revision 63. Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland if_ole.cpp: Error E2132 d:\borland\bcc55\include\stdlib.h 434: Templates and overloaded operators cannot have C linkage Error E2040 d:\borland\bcc55\include\stdlib.h 434: Declaration terminated incorrectly Error E2190 d:\borland\bcc55\include\stdlib.h 498: Unexpected } Error E2316 d:\borland\bcc55\include\stdlib.h 505: '_argc' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 505: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 506: '_argv' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 506: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 603: 'min' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 603: Identifier expected Error E2316 d:\borland\bcc55\include\stdlib.h 604: 'max' is not a member of 'std' Error E2272 d:\borland\bcc55\include\stdlib.h 604: Identifier expected *** 11 errors in Compile *** ** error 1 ** deleting WIN32\oleobj\if_ole.obj Cheers, -Mark
Re: Vim updates
Ali Akcaagac wrote: Hello Bram, On my home Linux system I can easily compile and install every patch you release for Vim, same applies for the MorphOS versions that I from time to time create and release for our users but for Windows - which I need to use at work - I am stuck with the *.exe setup files as found on vim.org and thus can not test updates to report back problems or give feedback. Now the patchlevel has reached .051. Is there by any chance a way to release full binary "setup" snapshots of vim ? Say is there a way or automate process that might generate a setup say once a week and put it up on vim.org ? mfg, Ali Akcaagac For Windows, Steve Hall has an automated process which generates a full upgraded installer; he uploads the latter (currently at 7.0.051, I just checked) at https://sourceforge.net/project/showfiles.php?group_id=43866&package_id=39721 Best regards, Tony.
Re: failure notice
Hi Bram,
On 8/12/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
[...]
You may have uncovered a bug that went unnoticed so far. Please try to
discover what causes this problem. I can't guess why the last character
is messed up, looks strange.
I think I solved the problem! That was caused by iconv.
size_t iconv(iconv_t cd,
char **inbuf, size_t *inbytesleft,
char **outbuf, size_t *outbytesleft);
The parameter "inbytesleft" and "outbytesleft" should all include the
trailing '\0' byte. In the previous version of gvim, we passed the
parameter as the length of the string, excluding the trailing '\0'. So
it is 1 byte less than the correct value.
As we know, every Chinese character is presented with 2 bytes in GBK encoding:
AABBCCDD
\--/
4 characters
Because we passed the parameter as the length of the string (8 in this
example), so iconv treated the input string as 1 byte less (7 in this
example), then the 2nd but last letter was not able to be converted
because it is only half of a character, so gvim changed it to a
question mark:
AABBCC?D
After that, gvim tried to convert the remaining 1 byte to the target
encoding but also failed. Then vim changed it to a question mark, too.
AABBCC??
That is why every last character of the tooltip became 2 question
marks. Menu doesn't get malformed because most of the menu items are
not ended with a Chinese character. In fact, some menu item ends with
Chinese character also get malformed.
[...]
It's quite simple after finding out the problem. Here is the patch, in
which I also alias GBK and GB18030 to cp936. That solved the previous
problem I requested:
*** src/mbyte.c2006-05-14 20:32:49.0 +0800
--- ../vim7.build/vim7/src/mbyte.c 2006-08-12 19:22:06.0 +0800
***
*** 372,377
--- 372,379
{"5601", IDX_EUC_KR},/* Sun: KS C 5601 */
{"euccn", IDX_EUC_CN},
{"gb2312",IDX_EUC_CN},
+ {"gbk", IDX_CP936},
+ {"gb18030", IDX_CP936},
{"euctw", IDX_EUC_TW},
#if defined(WIN3264) || defined(WIN32UNIX) || defined(MACOS)
{"japan", IDX_CP932},
***
*** 3250,3256
}
to = (char *)result + done;
! tolen = len - done - 2;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp->vc_fd, (void *)&from, &fromlen, &to, &tolen)
--- 3252,3259
}
to = (char *)result + done;
! tolen = len - done - 1;
! ++fromlen;
/* Avoid a warning for systems with a wrong iconv() prototype by
* casting the second argument to void *. */
if (iconv(vcp->vc_fd, (void *)&from, &fromlen, &to, &tolen)
Best Regards,
Edward L. Fox
