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.
