Yes
Thanks again
I think I just found the same thing >>
C:\Users\SB186007\Documents\vim\vim\src\ascii.h (2 hits)
Line 42: #define POUND 0xA3
Line 126: #define POUND '\xA3'
case '#':
#if POUND != '#'
case POUND: /* pound sign (sometimes equal to '#') */
#endif
The above is definitely ASCII-CENTRIC and is not cross-platform
Yup (#) = 0x7B
//* #
6654744
11C0B00
-----Original Message-----
From: Tony Mechelynck [mailto:[email protected]]
Sent: Thursday, December 15, 2011 10:19 PM
To: Bovy, Stephen
Cc: [email protected]
Subject: Re: ERROR CCN3052 ./normal.c:8344 Duplicate case label for value 163.
Labels must be unique.
On 16/12/11 05:35, Bovy, Stephen wrote:
> Line 8344 is in a switch statement at line 7809 whose range includes
> lines 7810 to 8362
>
> Ohh
>
> I do not think it is a compiler bug :)
>
> The above switch/case statement has a lot of hard-coded #define
> constants
>
> I think one of those constants is hiding the duplicate (163) value !!!
>
> Which is probably an ascii/ebcdic translation problem or an ascii
> ebcdic overlap
Ah, that would be a possibility. 163 would be 0xA3 (is that really 't'
on EBCDIC? hm, maybe; 'T' would be 0xE3 IIRC, and A3 == E3 xor 40). OK, let's
see what Vim with cscope tells me about its own source
switch (cap->nchar)
7815: Ctrl_A
defined in ascii.h lines 52 and 133
1 (line 52) for non-EBCDIC
0x01 (line 133) for EBCDIC
7923: K_BS
defined in keymap.h line 368
TERMCAP2KEY('k', 'b') i.e. the t_kb termcap entry
7928: Ctrl_H
defined in ascii.h lines 59 and 140
8 (line 59) for non-EBCDIC
0x16 (line 140) for EBCDIC
then at normal.c line 7932, changed to Ctrl_V for EBCDIC
Ctrl_V for EBCDIC is 0x32 (ascii.h line 154)
7946: K_DOWN
defined in keymap.h line 275
TERMCAP2KEY('k', 'd') i.e. termcap t_kd
7965: K_UP
keymap.h line 274
TERMCAP2KEY('k', 'u') t_ku
8000: K_HOME
keymap.h line 374
TERMCAP2KEY('k', 'h') t_kh
8001: K_KHOME
keymap.h line 375
TERMCAP2KEY('K', '1') t_K1
8066: K_END
keymap.h line 378
TERMCAP2KEY('@', '7') t_@7
8067: K_KEND
keymap.h line 379
TERMCAP2KEY('K', '4') t_K4
8127: POUND I think we got it!
ascii.h lines 42 and 126
0xA3 (line 42) for non-EBCDIC
'\xA3' (line 126) for EBCDIC
8129: Ctrl_RSB
ascii.h lines 80 and 160
19 (line 80) for non-EBCDIC
0x1D (line 160) for EBCDIC
8149: Ctrl_G
ascii.h lines 58 and 139
7 (line 58) for non-EBCDIC
0x2F (line 139) for EBCDIC
The rest are one-character literals.
IIUC the termcap entries (defined by keymap.h via TERMCAP2KEY(char,
char) are resolved at run-time when the 'term' option is set (at startup, or
also later if changed).
POUND (0xA3 on non-EBCDIC) displays as £ (the British pound sign) on my system.
I think it's very wrong that it should display as t on EBCDIC.
OTOH normal.c line 8127 says that POUND is sometimes the same as '#'
(number sign). If that's the case on EBCDIC, then I think the fix is
simple: change ascii.h line 126 to say '#' (or its hex equivalent) and the dup
will disappear by virtue of line 8127 of normal.h being preprocessed away when
POUND equals '#'.
Any fix should of course be sent to Bram Moolenaar [email protected] in the
form of a context diff (and, I suppose, preferably in Latin1 encoding).
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
245. You use Real Audio to listen to a radio station from a distant
city rather than turn on your stereo system.
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
