Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
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? [...] 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~ [...] Regards, Edward L. Fox
Re: failure notice
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? [...] 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~ [...] Regards, Edward L. Fox
Vim updates
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
Vim's mch_FullName() function and ClearCase versioned file names
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.
I've used autocommands like this one,
au BufRead *@@/main* exe "doau BufRead " .
\ strpart(expand(""),0,stridx(expand(""),"@@"))
to solve the problem of getting filetype.vim to recognize the file
types of version-extended file names, but I haven't been able to
come up with anything that will force Vim to use the
version-extended file name for the buffer name when the full path to
the file is given.
Sd does anyone here have any thoughts on this, such as an
autocommand or an alternative implementation of mch_FullName()?
Regards
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Wireless Division
| Spokane, Washington, USA
Re: failure notice
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. Best regards, Tony.
Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
On 8/12/06, mwoehlke <[EMAIL PROTECTED]> wrote: Bram Moolenaar wrote: > hundred-and-one symptoms of being an internet addict: > 256. You are able to write down over 250 symptoms of being an internet > addict, even though they only asked for 101. So where is the complete list? ;-) I believe the list can't be complete because people invent new ways of internet addiction every day. 258. You are subscribed to mailing list for every piece of software you use. 259. You collect hilarious signatures from all 250 mailing lists you are subscribed to. Yakov
Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
Bram Moolenaar wrote: hundred-and-one symptoms of being an internet addict: 256. You are able to write down over 250 symptoms of being an internet addict, even though they only asked for 101. So where is the complete list? ;-) FIXME and XXX are two common keywords used to mark broken or incomplete code not only since XXX as a sex reference would grab everbodys attention but simply due to the fact that Vim would highlight these words. -- Hendrik Scholz ...and those of us that use KATE (I use VIM for one-off edits, and when I'm not working on my local box) simply edit alerts.xml :-) -- Matthew "We're all mad here. I'm mad. You're mad... You must be, or you wouldn't have come here." -- The Cheshire Cat
Re: failure notice
Edward L. Fox wrote: > Sorry for sending this mail for the second time because my previous > mail with attachment was rejected by the mail daemon. :-( > > On 8/11/06, Bram Moolenaar <[EMAIL PROTECTED]> 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? > In the past two by "system encoding"? How does Vim see this? years > (or more), all gvim users in mainland China should add the following > two lines in their .vimrc if they are using Linux with GBK encoding: > > set enc=cp936 > so $VIMRUNTIME/delmenu.vim > so $VIMRUNTIME/menu.vim > > That's why I had wanted to change the encoding value in menu.vim. :-) > > > If the intention is to have the default for 'encoding' use something > > specific in $LANG then this must be done in enc_locale() in src/mbyte.c > > I modified mbyte.c, added "gbk" as an alias of "cp936", then the > menubar was displayed properly with the unmodified menu.vim. But there > is still some problem with the toolbar - every last character of the > tooltip becomes two question marks. I'm trying to debug the code and > will send you another patch as soon as I solve the problem. Hope you > can offer me some hints, too. :-) 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. -- hundred-and-one symptoms of being an internet addict: 115. You are late picking up your kid from school and try to explain to the teacher you were stuck in Web traffic. /// 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///
Patch 7.0.051
Patch 7.0.051 (after 7.0.44)
Problem:The Perl interface doesn't compile or doesn't work properly.
Solution: Remove the spaces before #ifdef and avoid an empty line above it.
Files: src/if_perl.xs
*** ../vim-7.0.050/src/if_perl.xs Tue Aug 8 16:47:38 2006
--- src/if_perl.xs Fri Aug 11 22:51:01 2006
***
*** 1068,1098
line = SvPV(ST(i),PL_na);
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
{
! #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
! #endif
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
!
! #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
! #endif
}
}
}
--- 1068,1097
line = SvPV(ST(i),PL_na);
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
{
! #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
buf_T *save_curbuf = curbuf;
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
! #endif
if (u_savesub(lnum) == OK)
{
ml_replace(lnum, (char_u *)line, TRUE);
changed_bytes(lnum, 0);
}
! #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
! #endif
}
}
}
***
*** 1130,1144
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count)
{
buf_T *save_curbuf = curbuf;
! #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
! #endif
if (u_savedel(lnum, 1) == OK)
{
ml_delete(lnum, 0);
--- 1129,1143
if (lnum > 0 && lnum <= vimbuf->b_ml.ml_line_count)
{
buf_T *save_curbuf = curbuf;
! #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
curbuf = vimbuf;
curwin->w_buffer = vimbuf;
! #endif
if (u_savedel(lnum, 1) == OK)
{
ml_delete(lnum, 0);
***
*** 1146,1159
if (save_curbuf == curbuf)
check_cursor();
}
! #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
! #endif
update_curbuf(VALID);
}
}
--- 1145,1158
if (save_curbuf == curbuf)
check_cursor();
}
! #ifdef FEAT_AUTOCMD
/* restore curwin/curbuf and a few other things */
aucmd_restbuf(&aco);
/* Careful: autocommands may have made "vimbuf" invalid! */
! #else
curwin->w_buffer = save_curbuf;
curbuf = save_curbuf;
! #endif
update_curbuf(VALID);
}
}
***
*** 1180,1210
line = SvPV(ST(i),PL_na);
if (lnum >= 0 && lnum <= vimbuf->b_ml.ml_line_count && line != NULL)
{
! #ifdef FEAT_AUTOCMD
aco_save_T aco;
/* set curwin/curbuf for "vimbuf" and save some things */
aucmd_prepbuf(&aco, vimbuf);
! #else
buf
RE: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux
> Bram, you have an overflow in your signature :) > > -- > > hundred-and-one symptoms of being an internet addict: > > 102. When filling out your driver's license application, you give > > your IP address. hundred-and-one symptoms of being an internet addict: 256. You are able to write down over 250 symptoms of being an internet addict, even though they only asked for 101. -- FIXME and XXX are two common keywords used to mark broken or incomplete code not only since XXX as a sex reference would grab everbodys attention but simply due to the fact that Vim would highlight these words. -- Hendrik Scholz /// 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: Invoke _gvimrc.vim / unexpected expansions
On Fri, Aug 11, 2006 at 08:43:10AM +0200, jandl wrote: > Dear colleagues, > I have 2 problems with gvim > > 1/ when I start gvim in Windows XP (double click on icon), gvim opens > without invoking the _gvimrc.vim. I have _gvimrc.vim located in > c:\programs\vim. I have also tried to put _gvimrc.vim into > c:\programs\vim\vim70 but it was not automatically started from there > either. > > 2/ I am using gvim for edition my latex files and have the Latex-Suite > as an add-in. That has generated some conflict: whenever I press a '.' > I get '=SmartDots()'. > > Here is my _gvimrc.vim: > [snip] > " To use it, copy it to > " for Unix and OS/2: ~/.gvimrc > " for Amiga: s:.gvimrc > " for MS-DOS and Win32: $VIM\_gvimrc As your _gvimrc says, there should be no ".vim" extension on your _gvimrc (or _vimrc). :) That will fix 1). As for 2), you may have to edit the plugin to change that mapping so it doesn't override a normal Vim command. James -- GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature
