Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. TTFN Mike -- Sign at Proctologist's office: Parking in Rear
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 18:37: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. Mea culpa, you are right. Add an ll to the above list. What are not valid is lul. Ah, whew, my faith in standards is restored. :-) Thanks for following up. -- Matthew Ok, so the quotes aren't entirely original.
Re: Possible addition to the c.vim and perl.vim syntax files
Mark Manning did utter on 10/09/2006 23:52: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart=0x\x*[g-zG-Z] end=\W Two issues - you most likely want to add underscore to the range since it should be \w less the valid hex digits (the difference between 0x88_65 and 0x88-65 will then highlight), and you need to be able to allow for the unsigned and long integer suffixes are part of the hex value, e.g. 0x88ul The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) TTFN Mike -- I am Homer of Borg! Prepare to be... Ooo! Donuts!
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: Mark Manning wrote: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart=0x\x*[g-zG-Z] end=\W The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. Mike -- I made that part of the program bullet proof, but not 2x4 proof!
Re: Possible addition to the c.vim and perl.vim syntax files
Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. Microsoft's compiler, being the non-standard aberration it is, of course uses 'i64' for 64-bit integral constants. I don't think we need to worry about supporting _that_ :-). -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
On 9/11/06, mwoehlke [EMAIL PROTECTED] wrote: mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. For the literature, see /The C Programming Language/, Second Edition, Section A2.5.1, Integer Constants, p. 193. nikolai
Re: Possible addition to the c.vim and perl.vim syntax files
Nikolai Weibull wrote: On 9/11/06, mwoehlke [EMAIL PROTECTED] wrote: mwoehlke wrote: Mike Williams wrote: mwoehlke did utter on 11/09/2006 17:44: Bram Moolenaar wrote: I don't know what the rules are in all kinds of C, but at least things like 0x0L, 0x0u, 0x0UL are valid. Using a match instead of region would be simpler. If one takes KATE's c.xml as canonical, supported suffixes (but not necessarily on all build configurations) are all combinations of 'U', 'L' and 'L', with no mention of 'u'. That makes: ULL, LUL, LLU, LL, UL, LU, L and U. As a regexp, 'U?L?L?|L?(UL|LU)'. Standard C only allows the following suffixes (in lower or uppercase): u, ul, ull, l, lu, and llu. D'oh! I looked again, and I see that c.xml says 'insensitive=TRUE', so all of the above are case-insensitive. But you are saying that 'ull'/'llu' are supported, but NOT 'll'? That can't be right? I would not be surprised if 'lul' is not well-supported, however. ...and I don't think it is. According to a cross-platform-support header we use, 'LL' is supported on the default compilers for HPUX, Linux, Irix, and Solaris (in 32-bit mode); possibly others as well. For the literature, see /The C Programming Language/, Second Edition, Section A2.5.1, Integer Constants, p. 193. Since none of the standards are freely available (not that I can see, anyway), all I can tell you is what is widely supported, and 'll' seems to qualify. -- Matthew KATE: Awesome Text Editor
Re: Possible addition to the c.vim and perl.vim syntax files
Ok, please find attached my corrections to the c.vim file. (Diff
instructions.) Many thanks go to Tony for his invaluable help.
Especially with the diff command.
Synopsis:
Because hex values have the suffixes and the underscores it took a while
to come up with something which would handle all of the various aspects
of and combinations of items. My simplest effort would catch the errors
but would also catch the unwanted errors as well. (ie: It was catching
errors it should not have caught because they were not errors reallys.)
Even this solution is not perfect because in some of the test cases the
trailing ul would sometimes turn light blue (which is - I believe
standard text/instructions in my color scheme) instead of the entire
number being bold white (my set-up for errors). Still, the hex values
would completely show up as an error. Which was my main goal.
Changes:
The main changes are that there is now a cHex and a cHexError. These
have been inserted into the same locations as cOctal and cOctalError
respectively. Although cHex only takes one line, the cHexError required
four separate lines. I've left the old cNumber line for catching
hexidecimal numbers in the file. I've tested these changes on about ten
different lines of code. So feedback is welcome if, for some reason,
you find they do not work properly.
Mark
*** c.vim Mon Sep 11 23:56:51 2006
--- /home/Mark/ftp/vim70/runtime/syntax/c.vim Mon May 1 03:39:56 2006
***
*** 67,73
catch errors caused by wrong parenthesis and brackets
also accept % for {, % for }, : for [ and : for ] (C99)
But avoid matching ::.
! syn cluster cParenGroup
contains=cParenError,cIncluded,cSpecial,cCommentSkip,cCommentString,cComment2String,@cCommentGroup,cCommentStartError,cUserCont,cUserLabel,cBitField,cCommentSkip,cOctalZero,cCppOut,cCppOut2,cCppSkip,cFormat,cNumber,cFloat,cHex,cOctal,cOctalError,cHexError,cNumbersCom
if exists(c_no_curly_error)
syn region cParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
cCppParen: same as cParen but ends at end-of-line; used in cDefine
--- 67,73
catch errors caused by wrong parenthesis and brackets
also accept % for {, % for }, : for [ and : for ] (C99)
But avoid matching ::.
! syn cluster cParenGroup
contains=cParenError,cIncluded,cSpecial,cCommentSkip,cCommentString,cComment2String,@cCommentGroup,cCommentStartError,cUserCont,cUserLabel,cBitField,cCommentSkip,cOctalZero,cCppOut,cCppOut2,cCppSkip,cFormat,cNumber,cFloat,cOctal,cOctalError,cNumbersCom
if exists(c_no_curly_error)
syn region cParen transparent start='(' end=')'
contains=ALLBUT,@cParenGroup,cCppParen,cCppString,@Spell
cCppParen: same as cParen but ends at end-of-line; used in cDefine
***
*** 94,106
integer number, or floating point number without a dot and with f.
syn case ignore
! syn match cNumbersdisplay transparent \\d\|\.\d
contains=cNumber,cFloat,cOctalError,cHexError,cOctal,cHex
Same, but without octal error (for comments)
! syn match cNumbersCom display contained transparent \\d\|\.\d
contains=cNumber,cFloat,cOctal,cHex
syn match cNumber display contained \d\+\(u\=l\{0,2}\|ll\=u\)\
hex number
! syn matchcNumber display contained
0x\x\+\(u\=l\{0,2}\|ll\=u\)\
! syn match cHexdisplay contained
0x\(\x\|_\x\)\+\(u\=l\{0,2}\|ll\=u\)\
Flag the first zero of an octal number as something special
syn match cOctal display contained
0\o\+\(u\=l\{0,2}\|ll\=u\)\ contains=cOctalZero
syn match cOctalZero display contained \0
--- 94,105
integer number, or floating point number without a dot and with f.
syn case ignore
! syn match cNumbersdisplay transparent \\d\|\.\d
contains=cNumber,cFloat,cOctalError,cOctal
Same, but without octal error (for comments)
! syn match cNumbersCom display contained transparent \\d\|\.\d
contains=cNumber,cFloat,cOctal
syn match cNumber display contained \d\+\(u\=l\{0,2}\|ll\=u\)\
hex number
! syn match cNumber display contained
0x\x\+\(u\=l\{0,2}\|ll\=u\)\
Flag the first zero of an octal number as something special
syn match cOctal display contained
0\o\+\(u\=l\{0,2}\|ll\=u\)\ contains=cOctalZero
syn match cOctalZero display contained \0
***
*** 119,130
endif
flag an octal number with wrong digits
! syn match cOctalError display contained 0\o+[89a-zA-Z]\+\d*
! syn matchcHexError display contained
0x!\(\x\+\(u\=l\{0,2}\|ll\=u\)\\)\|0x!\(\x\+\(_\x\x\)\+\(u\=l\{0,2}\|ll\=u\)\\)
! syn match cHexError display contained
0x\(\x\|_\x\)\+[g-km-tv-zG-KM-TV-Z]\+\(u\=l\{0,2}\|ll\=u\)\?
! syn match cHexError display contained
0x[g-zG-Z]\+\(\x\|_\x\)\+\(u\=l\{0,2}\|ll\=u\)\?
! syn match cHexError
Possible addition to the c.vim and perl.vim syntax files
I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart=0x\x*[g-zG-Z] end=\W The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) Mark
Re: Possible addition to the c.vim and perl.vim syntax files
On 9/11/06, Mark Manning [EMAIL PROTECTED] wrote: I saw in the c.vim that there was an error statement for octal numbers. There isn't one for hex numbers so I made one really quickly. If you want, just put it into the c.vim file. :-) The test: syn regioncHexErrorstart=0x\x*[g-zG-Z] end=\W The highlight command: hi link cHexError cError Of course, this needs to be approved by Bram first though. :-) Good idea. But then, why not to add error syntax for decimal numbers ? I think it is also not present. Yakov
