Re: [GeSHi-users] Some suggestions/questions...

[Benny B. <Ben...@gm...>]

Hello,

D.Hendriks (Dennis) schrieb:
> Hello,
>
> Recently I used GeSHi to get syntax highlighting on DokuWiki (a wiki
> system that uses GeSHi for syntax highlighting) for the Chi and CIF
> languages. These languages are not part of GeSHi, so I created chi.php
> and cif.php files. 
>   
If you like me to add them, just send a copy to Be...@ge...
> Now that I'm finished I have some questions,
> suggestions and/or possible bugs:
>
>  1. At http://qbnz.com/highlighter/geshi-doc.html, in Section 4.3.5,
>     for 'NUMBERS', the documentation refers to "If you used an array 
> below,".
>     However, the 'NUMBERS' are never explained. Only in the example php.php
>     file included in the documentation I find a 'NUMBERS' section, which 
> uses
>     constants GESHI_NUMBER_INT_BASIC etc, but that 'NUMBERS' section is not
>     explained in the documentation. Maybe it could be added?
>   
Well, that part has been subject to change in recent versions, but
basically it works the following way:
In geshi.php there's a number of Number Formats predifined. Every
predefined number format has a symbolic constant which represents a bit
in a bitfield.

For the 'NUMBERS' entry you then just bitwise OR these constants
together and GeSHi will highlight the corresponding number formats.

For the styling you do a constant => 'style' association for each format
you want to highlight. Format 0 is special in that respect that every
other format that has no explicit style definition will always use the
format given in key 0.

I hope this explains the matter a bit ;-)
>  2. Since I dind't know there was a 'NUMBERS' section at first (see 1.) I
>     didn't include it. I did however add a style (color) for it. This 
> resulted
>     in integers (like "1") to be colored with that color, but reals (like
>     "0.1e5") would not be colored (would be default color). I think it is
>     unwanted to have numbers get recognized as numbers, even if I didn't
>     specify it in the 'NUMBERS' section. The same appears to hold for
>     brackets. I didn't specify any brackets, but I did specify some 
> 'SYMBOLS'
>     like '|(', '|[', etc. They would be colored partly as symbol and partly
>     as bracket. I had to add a color for brackets (same as for symbols) to
>     give the symbol the correct color. So, I think that if I don't specify
>     something, it should be recognized, and shouldn't be colored. Why is 
> this
>     not the case? What do you think is wanted behavior and how is it 
> currently
>     implemented?
>   
I really should get ridof the bracket highlighting stuff. Symbol
Highlighting nowadays works a lot better.

For the effect you describe: If you look at the source you should see
something like "<sy0>|<br0>[</br0></sy0>" (hope you see what I mean).
The inner highlighting comes from the old bracket highlighting which for
a long time was the only way to get at least some symbols highlighted.
IDK if I already included a PARSER_CONTROL setting to only disable the
bracket stuff, if not, I really should do this :P
>  3. At http://qbnz.com/highlighter/geshi-doc.html, in Section 4.1, the
>     example php.php file is shown. The file has syntax highlighting. 
> However,
>     lines 490-586 are not highlighted...
>   
Seems the PHP Block enders are incorrectly matched within a string. Will
have a look at this. Normally this should do fine.
>  4. In the Chi and CIF languages, string literals start and end with double
>     quotes ("). The only possible escape sequences are '\n', '\t', '\", and
>     '\\'. I included the following line:
>
>         'ESCAPE_CHAR' => '\\',
>
>     in cif.php and chi.php, which gives me escape sequences. However, every
>     character after the escape character is highlighted. This is not what I
>     want for my languages. Is there any way to specify it the way I want?
>   
You might want to look at Escape Regexps. The PHP and C language files
should give you a starting point on them. (Something that isn't quite
documented either IIRC ;-))
>  5. In section 4.3.3, I would change "Keywords should be sorted in 
> ascending."
>     to "Keywords should be sorted in ascending order."
>   
Or drop that sentence since this has been obsoleted by 1.0.7.22 when
some major enhancements to the parser where made and the parser now uses
Regular Expressions internally to match keywords. I'll update the
documentation there ;-)
>  6. In section 4.3.4, there is a 'note'. The entire note is unclear to me.
>     First of all, does it apply to what is before or after the note? Does
>     it apply to 'SYMBOLS' or to 'CASE_SENSITIVE'? Also, what is ignored
>     exactly? And what is the 'setting' that is referred to?
>   
That note refers to the Symbol Highlighting introduced with 1.0.7.21.
Versions prior to 1.0.7.21 had that configuration but didn't use it.
1.0.7.21 itself used that setting, but had some serious bugs with it.
Versions after 1.0.7.21 now should correctly handle symbols (unless
something goes horribly wrong) ;-)
> I look forward to your thoughts on my questions/suggestions.
>
> Thanks in advance,
> Dennis
>   
Regards,
BenBE.