On 27/01/10 21:10, [email protected] wrote:
Hello.
When I want to use EUC-JP Hankaku Katakana character in 'listchars',
It doesn't work.
The 'listchars' accepts the EUC-JP Hankaku Katakana character (0x8e 0xNN),
because it has a single width on screen.
(dbcs_char2cells returns 1 for the Katakana, because the first byte is 0x8e)
But in display phase, the next 0xNN character is displayed WITHOUT 0x8e.
It messes up a vim screen / terminal emulator.
The 0x8e character should be displayed prior to the 0xNN.
Here is a simple patch to fix it.
I'm not sure that the patch is a good fix, but it works fine for me.
Regards,
kikuchan
--- screen.c 2009-12-05 04:45:05.000000000 +0900
+++ screen.c 2009-12-05 04:46:19.000000000 +0900
@@ -4620,8 +4620,10 @@
#endif
ScreenLines[off] = c;
#ifdef FEAT_MBYTE
- if (enc_dbcs == DBCS_JPNU)
+ if (enc_dbcs == DBCS_JPNU) {
+ if (((c>> 8)& 0xFF) == 0x8e) ScreenLines[off] = 0x8e;
ScreenLines2[off] = mb_c& 0xff;
+ }
else if (enc_utf8)
{
if (mb_utf8)
I don't know if the patch is the best one, but I have a small
coding-style nit: Bram always puts the opening brace on its own line (as
shown in the "after-context" above), and writes only one statement per
line (see ":help coding-style"). Also, I think it's better to avoid
mixing upper- and lower-case hex digits in the same statement:
personally I use [0-9A-F] but Bram seems to prefer [0-9a-f].
if (enc_dbcs == DBCS_JPNU)
{
if ((c & 0xff00) = 0x8e00)
ScreenLines[off] = 0x8e;
ScreenLines2[off] = mb_c & 0xff;
}
else if (enc_utf8)
etc.
Best regards,
Tony.
--
We have only two things to worry about: That things will never get
back to normal, and that they already have.
--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
