Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux

2006-08-11 Thread Edward L. Fox

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

2006-08-11 Thread Edward L. Fox

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

2006-08-11 Thread Ali Akcaagac
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

2006-08-11 Thread Gary Johnson
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

2006-08-11 Thread A.J.Mechelynck

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

2006-08-11 Thread Yakov Lerner

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

2006-08-11 Thread mwoehlke

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

2006-08-11 Thread Bram Moolenaar

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

2006-08-11 Thread Bram Moolenaar

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

2006-08-11 Thread Bram Moolenaar

> 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

2006-08-11 Thread James Vega
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