»
« home   paste   Anonymous | Login | Signup for a new account 07-28-2017 16:48 CEST
 
* X »
«
GeSHi - Generic Syntax Highlighter Syntax Coloriser for PHP
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000075 [GeSHi] lang minor always 05-15-06 01:07 05-27-06 23:45
Reporter BenBE View Status public  
Assigned To nigel
Priority low Resolution fixed  
Status closed   Product Version 1.1.1alpha3
Summary 0000075: ASM-Ender in Delphi sources inside comments not ignored
Description When having an asm block with comments it is falsely ended by commented out instances of end:

Example:
http://viewcvs.omorphia.org/omorphia/library/source/OMathMatrix.pas?rev=1.20&theme=default [^]
See Routine Function MatrixDeterminant
Additional Information
Attached Files

- Relationships
child of 0000006assigned BenBE Delphi support 

- Notes
(0000367)
BenBE
05-16-06 08:22

Reminder sent to: nigel

Could you give me some hints or suggestions on how to solve this one?

This doesn't occur for comments only, but any sub-context containing the word end.
 
(0000369)
nigel
05-16-06 11:28

This is actually a bug in the geshi core.

I had a bit of a debugging session on this one. I found that it's due to the special handling for child contexts. In particular, the current special handling for child contexts is really a hangover from before the language file format change, and is not needed.

I had to fix up a couple of small things with the delimiter parsing (e.g. GESHI_CHILD_PARSE_* to get back the old behaviour, but with this bug fixed.

One thing I noticed was that, let's assume we're highlighting this Java source:

/**
 * Doxygen embedded within java
 */
import foo;

The default handling is to make the child context parse both enders. So in this case, the entire source will be doxygen/doxygen.

Say we change the delimiter handling to GESHI_CHILD_PARSE_LEFT. This means that the /** will be highlighted as doxygen. The right-hand side will be highlighted as java, so the */ will be symbols.

But say we change it to GESHI_CHILD_PARSE_RIGHT. Then the /** at the start becomes java/java/multi_comment[/start]. But after the doxygen comment is finished, the code continues not as a multi comment, but as java/java.

Now, I'm not sure about this behaviour. I don't think it's a bug really, because what has happened is that we have said "use /** to start doxygen, but if you come across this you should ALSO use the /* to start a multiline comment". Which seems silly, really. But your thoughts on this would be welcome.

I haven't committed yet. The code is still a little messy from the changes I made. But I'll commit tonight (I hope).
 
(0000375)
BenBE
05-16-06 23:04

I'm sorry, but I can't follow you completely on the last point.What are you pointing on?
 
(0000380)
nigel
05-17-06 09:38

Firstly, I committed last night.

What I mean by the point is:

Java uses doxygen as a sublanguage, using /** and */ as delimiters, right?

Current normal behaviour is that doxygen is told to parse both delimiters. So when you have this java source:

System.out.println("Hi");
/** a comment */
System.out.println("Bye");

Then doxygen gets all of/** a comment */

BUT, it's possible to say "java should handle the opener/closer/both", using the GESHI_CHILD_PARSE_* flags. So if we wanted java to parse the opener we could use GESHI_CHILD_PARSE_RIGHT - the "child" (doxygen) will parse the right delimiter (*/) and the "parent" (java) will parser the left delimiter (/**).

But if we tell java to parse the left delimiter, it will match /* and start a multiline comment (which are delimited by /* and */).

After the child is parsed, the code is not in the multiline comment, but is instead back to being java.

I think that this could be considered correct behaviour, because really what we've done is detected /** and made it doxygen/doxygen, but THEN detected the same /** again and decided that it's the start of a multiline comment. That doesn't seem right to me.

The /** still needs to be parsed - because if you imagine the case where CSS is embedded in HTML, the <style type="text/css"> is detected as the starter, and that still needs to be parsed as HTML. But I'm interested in your thoughts anyway.
 
(0000384)
BenBE
05-17-06 18:54

in case of simple languages (like Delphi) where the starts and enders of the contxt are actual reserved words of the parent it should be no problem.

For other situations like the mentioned comment styles with different headers you just could force a "style overlay" i.e. if no style information is provided for doxygen use the one given for comments. This might be interesting, but IMHO it produces to much side effects, doesn't it?
 
(0000385)
nigel
05-17-06 19:31

I don't think it would work incredibly well - there would be no point in declaring a child context and then not bothering to style it. The main issue here is whether such a wierd thing actually ever happens in a "real" language - i.e. two contexts are started with near-same delimiters, both matching in the same place.

And I have to say, that currently the parser already detects this and opts for the longer one, do /** beats /*. There's really only one winner from that situation, and it's probably silly to start assuming that actually there isn't one winner later. So I guess I'll just remember what GeSHi does (with a comment in the source perhaps), and forget about it.
 
(0000392)
BenBE
05-18-06 05:37

Yes. It just a few days ago happened to me with the preprocessor stuff *g*

And does it make sense: Yes. Think about the use for this with the Delphi language: ASM and END could then be told to be keywords of delphi/delphi while they are actually belonging to delphi/delphi/asm, but get their initial styles from delphi/delphi/keywords.

And concerning the longest match issue: It doesn't work for prefetch-patterns.
 
(0000397)
nigel
05-18-06 09:52

There's nothing I can do about the prefetch patterns - by their very nature they have no length.
 

- Issue History
Date Modified Username Field Change
05-15-06 01:07 BenBE New Issue
05-15-06 01:07 BenBE Status new => assigned
05-15-06 01:07 BenBE Assigned To  => BenBE
05-15-06 01:44 BenBE Relationship added child of 0000006
05-16-06 08:22 BenBE Issue Monitored: nigel
05-16-06 08:22 BenBE Note Added: 0000367
05-16-06 11:28 nigel Note Added: 0000369
05-16-06 11:30 nigel Assigned To BenBE => nigel
05-16-06 23:04 BenBE Note Added: 0000375
05-17-06 09:38 nigel Note Added: 0000380
05-17-06 18:54 BenBE Note Added: 0000384
05-17-06 19:31 nigel Note Added: 0000385
05-17-06 19:31 nigel Status assigned => resolved
05-17-06 19:31 nigel Resolution open => fixed
05-17-06 19:31 nigel Fixed in Version  => 1.1.1alpha5
05-18-06 05:37 BenBE Note Added: 0000392
05-18-06 09:52 nigel Note Added: 0000397
05-27-06 23:45 nigel Status resolved => closed

  


Mantis 1.0.0rc2[^]
Copyright © 2000 - 2005 Mantis Group
52 total queries executed.
38 unique queries executed.
Powered by Mantis Bugtracker