Re: [GeSHi-devel] new language file GNU/Octave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBT+Y4aJw3120Y2Wc/AQKhnQgAiecUHsEmhrZOaDdm3IUg1UoiU1brnGw8
mG21x926GVSkgAdI7nayRUbloa9v5WA5nNnlUDYtJyRuvMZuTYarVeQGjG8Xn2/5
51EbvoTjqAuO9/9NnJ0lBBIACCtBpUrAQlusw3Gbjkn1KZa3sSUs8uJ8eXqbmcTU
H8qkQ6hUk3gztM3RTf4p6Qlgr1EmR09+Z9KqzSbgynMtCLellTrqffRXLcvJKyxq
DF9NEItsh3p2LMVqRfzYM3QtxHn/CTtb7PTwcO4+urjOOOruJnJSbhdej9byWW6L
5Ah4kxg4g1fm4dTFRdOGghl0Odkpwy+BlRbRKbBEtGivzg/dhlcpSA==
=Y91n
-----END PGP SIGNATURE-----
Hi Carnë,

I did quite some work for about 10 language files recently at the GPN12
in Kassel and also had a look at your language file there. I mostly made
language files compliant there and less had a deeper look into eachone's
highlighting, thus I'd suggest you grab a copy of the language file from
the SVN repository of GESHi or check out the highlighting at
http://qbnz.com/. If you find anything still wrong it'd be nice to get
some examples with those problems and a short description of what
exactly the correct highlighting should be.

Best regards,
BenBE.

Am 18.06.2012 19:06, schrieb Carnë Draug:
> On 30 May 2012 21:22, Benny Baumann <BenBE1987@gmx.net> wrote:
>> Hi,
>>
>> thank you for this language file.
>>
>> Am 28.05.2012 13:20, schrieb Carnë Draug:
>>> On 25 May 2012 17:37, Carnë Draug <carandraug+dev@gmail.com> wrote:
>>>> Hi everyone
>>>>
>>>> me and Juan Carbajal have wrote a language file to highlight
>>>> GNU/octave source code that is attached.
>>>>
>>>> There is only one problem that we could not fix with adding URLS. We
>>>> have 10 different groups on KEYWORDS, 5 of them with rules for URLs.
>>>> The rule is the same for all of them. However, 1 of them (the very
>>>> first) doesn't work.
>>>>
>>>> The following code:
>>>> uint32
>>>> cell
>>>>
>>>> creates
>>>> function/uint32.html">uint32
>>>> function/cell.html">cell
>>>>
>>>> with links for
>>>> http://octave.sourceforge.net/octave/%3Cspan%20class=
>>>> http://octave.sourceforge.net/octave/%3Cspan%20class=
>>>>
>>>> The really weird thing is that keywords from the other lists, even
>>>> though having the same style and URL rule, work normally.
>>>
>>> Hi everyone
>>>
>>> I managed to fix the problem on the file but I think it is also a bug
>>> with GeSHi. The problem is that one of the keywords (function) is also
>>> a word on the URL. The keyword function was on the element #4. The
>>> only words that were giving me a problem were on element #1. When I
>>> swapped those two, the problem went away. Still, this sounds like a
>>> bug to me.
>> Yes and no. The problem lies a bit in how the parser works internally.
>> Basically it's a quite sophisticated find&replace with some minor tweaks
>> to give priority to some things over others. While this works for most
>> things it inevitably produces the issue of "rehighlighting" the
>> generated code. This can usually be avoided by two means:
>> 1. Swapping the order of things so the offending keywords don't make it
>> into the code before they should be actually highlighted. That's what
>> swapping the groups did.
>>
>> 2. Making the rules which determine where a keyword is allowed more
>> strict than the defaults. This does not fix the problem of the word
>> being there but will usually be enough to avoid the already present word
>> in the URL being picked up.
>>>
>>> Another problem I noticed, shows up when one of the keywords is DOT,
>>> whcich will also break the URLs (since the actual dots are replaced by
>>> <DOT> and then highlighted. Again this will only happen for the
>>> elements that have smaller key # than the one with the keyword DOT). I
>>> noticed this since octave actually has a function `dot', and before I
>>> made the match case sensitive, this also broke the highlighting.
>> GeSHi uses the order of the declared keyword indices as the order in
>> which to highlight things. Thus if you define keyword groups with
>> indices 42,1,2,3,4 it will happyly highlight group 42 first even though
>> it numerically is last in the order.
>>>
>>> Should I report this bug somewhere? I do not know how to code PHP,
>>> fixing this is beyond my abilities.
>> Well, that's a known problem and is a problem with the way theparser
>> works (see above). There's also <PIPE which is the internal keyword for
>> the | character ;-)
>>>
>>> Anyway, please see attached the final version of the octave.php
>>> language file and I hope it's acceptable for inclusion on GeSHi. It
>>> passes on langcheck.php file amd we tried to leave useful comments on
>>> the file which should hopefully make clear what each option we made.
>> I'll have a look atit and I guess it will be available in the repository
>> soon.
>
> Hi Ben
>
> any news on this? Did you had time to look into it? If there is
> anything I can do to make this easier, please do let me know.
>
> Thank you,
> Carnë
>