Re: failure notice
On 8/13/06, A.J.Mechelynck [EMAIL PROTECTED] wrote: [...] 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? I'm using Debian Etch. But I had a look at the Windoze system and found that cp936 is supported well in both Linux and Windoze, however, GBK is not supported by any of them. euc-cn is an alias of GB2312, which is only a subset of GBK. So we should not put them together. GB18030 is not exactly the same with GBK but 99% of them is the same, the remaining different part is cared by nobody in the world, and is very very complicated and very very difficult to support. Moreover, very few X servers support this encoding. So I suggest to alias GB18030 to cp936, too, simply and wrongly. :-) After having discussed about the charset, I think it's right time to do some work on the malformed characters in the toolbar tooltips. I made a patch and solved the problem yesterday (or at least it was seemed to be solved). Can anybody review my changes and give some suggestions? Thanks. http://groups.yahoo.com/group/vim/message/72396 Best regards, Tony.
Re: failure notice
[removed the Vim maillist, this is development only] Edward L. Fox wrote: 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. This is not quite so. iconv() does not require the terminating NUL (it can also be used to convert part of a string). If it does require the NUL then iconv() is broken. That's unlikely though. Your change suggests that the length that is passed should be one more. Thus only one byte of the last double-byte character is currently converted. I can't quickly figure out where the wrong length is computed or passed. You probably already know the call stack, please have a look at where the length comes from. It's probably an off-by-one error somewhere. -- hundred-and-one symptoms of being an internet addict: 129. You cancel your newspaper subscription. /// 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
Tony - 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. Right, I actually already have this linked on the download page, but it's not very noticable. I'll make this clearer. - Bram -- hundred-and-one symptoms of being an internet addict: 130. You can't get out of your desk even if it's time to eat or time to go to the bathroom. /// 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: BCC 5.5 build is broken (but here is a fix)
Mark S. Williams wrote: 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. Thanks for finding and fixing the problem. I'll send out a patch for it. -- In a world without fences, who needs Gates and Windows? /// 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
On 8/13/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
[removed the Vim maillist, this is development only]
Edward L. Fox wrote:
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.
This is not quite so. iconv() does not require the terminating NUL (it
can also be used to convert part of a string). If it does require the
NUL then iconv() is broken. That's unlikely though.
I wrote a short piece of testing code to test iconv with Chinese
characters. The fact is, if the last character is a Chinese character,
it is always malformed after converting. So I think it should be
necessary to pass the length including the trailing '\0' to iconv.
8
#include iconv.h
int main(void)
{
char inbuffer[256];
char outbuffer[256];
int fd;
fd = iconv_open(cp936, euc-cn);
for (;;)
{
int inlength, outlength;
char *inptr, *outptr;
gets(inbuffer);
inlength = strlen(inbuffer);
outlength = 256;
if (inlength == 0)
break;
inptr = inbuffer;
outptr = outbuffer;
iconv(fd, inptr, inlength, outptr, outlength);
printf(%s\n, outbuffer);
}
iconv_close(fd);
return 0;
}
8
Your change suggests that the length that is passed should be one more.
Thus only one byte of the last double-byte character is currently
converted. I can't quickly figure out where the wrong length is
computed or passed. You probably already know the call stack, please
have a look at where the length comes from. It's probably an off-by-one
error somewhere.
I traced the code again and again but nothing special happened. You
called string_convert and pass 0 as the length of the string, so in
string_convert_ext you calculates the length of the string with
STRLEN, then call iconv_string, last iconv. There is nothing wrong
with the length anywhere. So... Maybe it is still iconv's fault.
[...]
Regards,
Edward L. Fox
Re: failure notice
[...] I traced the code again and again but nothing special happened. You called string_convert and pass 0 as the length of the string, so in string_convert_ext you calculates the length of the string with STRLEN, then call iconv_string, last iconv. There is nothing wrong with the length anywhere. So... Maybe it is still iconv's fault. Sorry all. I did more tests and searched more documents and found that it was a bug of libiconv, not gvim. The problem occurs only when converting gb2312 to gbk. I'm trying to debug libiconv... [...] Ashamed Edward L. Fox
Re: Patch 7.0.051
Hi Bram Patch 7.0.051 (after 7.0.44) Thanks! That resolved my problem! Best regards Mathias
Re: Vim updates
On Sat, 2006-08-12 at 09:48 -0400, Steve Hall wrote: It uses my own configuration of the Nullsoft Installer (NSIS) instead of relying on Vim's NSIS-install.exe combo, but it otherwise contains gvim.exe, vim.exe, gvimext.dll, plus all the standard and runtime files current as of build date. Version output is given in the Notes link at each file. Hmmm, I just downloaded that file and I am not really convinced by it. It's not the same as the releases Bram does. The Menu entries in the Windows Start Menu are not identical, The colorful green icons are missing, even the name convention used gVim 7.x for example is not there. Looking deeper into c:\programs\vim I see the directory populated with plenty other directories while my previous Vim installation has just 2 or 3 iirc. Even the dir name is not Vim it's in lower case letters. I get a dialog all the time starting Vim saying I have to register vim. I therefore decided to go back to plain 7.0 release version of gVim for Windows. mfg, Ali Akcaagac
Re: Vim's mch_FullName() function and ClearCase versioned file names
On 2006-08-12, Yakov Lerner [EMAIL PROTECTED] wrote:
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 ?
That would work. It could be messy figuring out where to put it
where its name would be unique, but not impossible.
Regarding statusline, you can use custom statusline
and replace %f to %{MyFilename()} which knows to handle @@.
Good idea. There's even a ClearCase command that can convert from
one form of the file name to another.
On 2006-08-12, Yakov Lerner [EMAIL PROTECTED] wrote:
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 afile .c
| sed 's/^.*\.v//'`; base=`basename afile .c | sed
's/\.v[0-9]*\$//`; ln -s /project/xyz/system/src/\$base.c@@/main/\$ver
afile
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.
Hmm. That could work. Thanks.
One of the situations in which I've had trouble giving a
properly-extended file name to an external program is when I've used
the ClearCase Vtree Browser to select a C file to opened in Vim,
then tried to run 'lint' on the file. In that case, I could modify
my :Lint command to create a temporary file with the proper suffix,
either as a copy of the file in the Vim buffer or as a symbolic link
from the ClearCase file as in your suggestion.
I've also come up with a solution for part of the problem, that of
Vim's insistence on converting a name like
/project/xyz/system/src/bar.c@@/main/42
(through chdir() and getcwd()) to a name like
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
Using the following autocommand seems to fix that by restoring the
original file name. I thought I had tried this solution before and
it didn't work, but it seems to work now, so I must have had
something set differently before.
au VimEnter /view/*@@/* silent windo
\ exe 'file' system('cleartool des -short -cview '.expand(%).'')
The windo command covers the case where vim was invoked as vimdiff
to compare two ClearCase versions.
Thanks again,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: Vim's mch_FullName() function and ClearCase versioned file names
Gary Johnson wrote:
[...]
I've also come up with a solution for part of the problem, that of
Vim's insistence on converting a name like
/project/xyz/system/src/bar.c@@/main/42
(through chdir() and getcwd()) to a name like
/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main
Using the following autocommand seems to fix that by restoring the
original file name. I thought I had tried this solution before and
it didn't work, but it seems to work now, so I must have had
something set differently before.
au VimEnter /view/*@@/* silent windo
\ exe 'file' system('cleartool des -short -cview '.expand(%).'')
The windo command covers the case where vim was invoked as vimdiff
to compare two ClearCase versions.
Thanks again,
Gary
VimEnter doesn't cover the case when you :edit or :view (etc.) the
file after starting Vim. Maybe:
:au BufReadPost /view/*@@/* silent exe 'file' system(...etc...)
Best regards,
Tony.
Re: Vim updates
On Sun 13-Aug-06 7:41pm -0600, Steve Hall wrote: A normal full install should have all or nearly all these (at least my install here on Fedora Core 5 does): vim70/autoload/ colors/ compiler/ doc/ ftplugin/ icons/ indent/ keymap/ lang/ macros/ plugin/ print/ spell/ syntax/ tools/ tutor/ This is fairly close to what installs on a Win system. We don't have icon/ but do have nsis/ and src/. Also the print/ directory isn't standard with a Win installation - it tagged along when I updated my runtime files with runtime/dos on the FTP site. I see bitmaps/ is not included there also. Gvim, at startup, checks for 20 separate .bmp files for each directory in 'rtp'. Not a startup speed enhancement. Is there a way to shut this bitmaps searching off? -- Best regards, Bill
Re: Vim updates
Bill McCarthy wrote: On Sun 13-Aug-06 7:41pm -0600, Steve Hall wrote: A normal full install should have all or nearly all these (at least my install here on Fedora Core 5 does): vim70/autoload/ colors/ compiler/ doc/ ftplugin/ icons/ indent/ keymap/ lang/ macros/ plugin/ print/ spell/ syntax/ tools/ tutor/ This is fairly close to what installs on a Win system. We don't have icon/ but do have nsis/ and src/. Also the print/ directory isn't standard with a Win installation - it tagged along when I updated my runtime files with runtime/dos on the FTP site. I see bitmaps/ is not included there also. Gvim, at startup, checks for 20 separate .bmp files for each directory in 'rtp'. Not a startup speed enhancement. Is there a way to shut this bitmaps searching off? src/ shouldn't be part of your production installation. You need it to compile Vim, but that should be done elsewhere than where Vim will reside for day-to-day editing. For instance, a typical production installation of Vim will reside in C:\Program Files\vim\vim70 and its subdirectories. To compile Vim, I keep the source safely apart (so if the compile fails, my production Vim doesn't get clobbered), for instance in C:\Documents and Settings\Tony\compile\vim\vim70 and its subdirectories. The letter has, among others, a runtime subdirectory for the runtime files, and a src subdirectory for the source, both of which have further subdirectories. The former should have neither src/ nor runtime/ in it. On my Linux system, $VIM/vim70/print contains only *.ps files. These should, I suppose, not be required on a normal Windows installation since on Windows the :hardcopy command doesn't use PostScript. Searching for *.bmp files is normal; it's explained as item 3 under :help toolbar-icons. If your 'rtp' directories don't have bitmap/ subdirectories, or if the latter are empty, the search should proceed rather quickly, and then you should get the built-in icons. Creating an empty bitmaps/ subdirectory in $VIMRUNTIME may or may not make the GUI startup marginally faster or slower. But this also brings us to another point: if you have bitmaps/ subdirectories with nonstandard icons in some of the 'rtp' directories, these nonstandard icons will replace the default ones on yout toolbar. There are two ways to altogether avoid searching for these icons: a) :set toolbar=text displays text-only toolbar buttons, with no icons; b) :set guioptions-=T suppresses the toolbar completely. These can be placed in your gvimrc if you have one, or (bracketed by 'if has(gui_running)') in your vimrc. Best regards, Tony.
