-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEVAwUBT+bqRJw3120Y2Wc/AQKcUgf/XUOrfQUvlhWTBfvYZ/ECMnUZEEISsnaT
ZxFOkTh9qfkI7MYY5nDcixDMhv8cznRmCEfEtV7Ool07Zam9a7Arqzv1X/w411x+
Owcb7ZAfQmOvQqS26lMFh+rh8dKYXYFFr/WClj6/PBphymPCzysgD34nsAXhGgK3
j/raWQpunj/qF4iHJGTsFH/VjDlgxLPZVpHusD3YTmnZWF7g5t372bVr34tXTYvO
DG6BpUmRbibz0yI3SZRpBTdUmkyeL/tLHtI8DjJPthXHNt3u5ykp39b8VESwH0oC
C6HlnuksuH5Hucv2K8UrrdACCU8M0dtlBPzTjMGO40vE3G9f3SxoyQ==
=L1K/
-----END PGP SIGNATURE-----
Hi,
Am 24.06.2012 07:34, schrieb Juan Pablo Carbajal:
> Hi BenBE,
>
> Thank you for your answer. We will be checking against other files asap.
> A couple of extra questions:
> - Do you know when will this file made its way to Wikimedia?
Unfortunately not. They've been behind for years, but when the next
release comes I guess they might update again. I'm not sure when they
will though.
> - Do you know who to contact in Wikipedia/media to make them aware of
> the new files?
Usually contact the authors of the SyntaxHighlight_GeSHi extension and
ask them to forward the request. They should be aware of where this
should go.
>
> Thank you.
>
> JPi
Regards,
BenBE.
>
>
> On Sat, Jun 23, 2012 at 11:43 PM, Benny Baumann <BenBE1987@gmx.net> wrote:
>> 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ë
>>>
>>
>>
>
>
>
No comments:
Post a Comment