»
« home   paste   Anonymous | Login | Signup for a new account 09-22-2017 15:32 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
0000011 [GeSHi] lang minor always 10-21-05 12:22 12-11-05 22:28
Reporter nigel View Status public  
Assigned To BenBE
Priority normal Resolution fixed  
Status closed   Product Version 1.1.0alpha6
Summary 0000011: "default" keyword after property context is not highlighted
Description The "default" keyword is only supposed to be highlighted immediately after a property context.

e.g.: property A[X: Integer; Y: Integer; Z: Integer]: String read GetA stored False nodefault; default;

The property context goes until the semi-colon after nodefault and then halts. The default after it needs to be highlighted though.
Additional Information I'm not sure whether this is fixable at this time. Ben, it's up to you to decide how you can fix it and what data you'll need to have available.

e.g.: you could try changing the end for a property context.

Or you could use the new GeSHiCodeParser stuff to do it. But you might need more information to be given to you that way, since the property context is aliased to delphi so you can't really tell when the property context ends.
Attached Files

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

related to 0000026closed BenBE Context-Dependent discarding of keywords 
child of 0000006assigned BenBE Delphi support 
child of 0000033assigned BenBE Highlight Labels after certain instructions 

- Notes
(0000007)
BenBE
10-21-05 22:06

Is there a way yet to get the next symbol\identifier following a context ender?

If so: What method to use for it?
 
(0000013)
nigel
10-22-05 00:26

This is the problem ;) - what context ender??

Because we happily aliased property context to delphi, we can't actually tell where the end of a property context is anymore, because by the time it gets to the GeSHiCodeParser all the parser sees is the delphi stuff!

e.g.: property foo; default; (ignore that it might not be valid delphi)

So first the context-tree stuff is loaded, and the "property" context is named as delphi/delphi.

Then the code is parsed:

property: delphi/delphi/keywords
foo: delphi/delphi
;: dephi/delphi/ctrlsym
default: delphi/delphi (not keyword of course, since we haven't put it as a keyword)
;: delphi/delphi/ctrlsym

And then the GeSHiCodeParser gets each token in turn, but cannot tell where the property context was.

Us using the aliasing for this is still a good idea I think - it gives the correct solution to the problem, except for this one small case.

I wonder if perhaps there is a way to pass the knowledge to the code parser that in fact the token it's parsing is actually aliased. If that was done then it would be easy to highlight the default keyword: if the last token was aliased to the property context, and this token is "default", then highlight it.

I might look into doing that, if you can't think of anything else.

Alternatively, you could just make "default" a keyword and turn a blind eye to the cases where it's highlighted incorrectly. It's up to you.
 
(0000017)
BenBE
10-22-05 07:18

At first: The given example is just syntactic correct delphi ;-)

Well, For this problem I'd suggest providing the parser with exactly two information:

1. Highlighting context
2. Code context

What do they mean:
The highlighting context is just what you've written below in your example. Thus there's no problem with that.

The (little bit) mor complicated part will be the second: The Code context. It will represent the actual context path that source information (without aliasing) are taken from. Now the problem:

For the example below it's simple (given both context names):
Sym Highlighting Code
property: delphi/delphi/keywords delphi/delphi/property/keyword
foo: delphi/delphi delphi/delphi/property
;: dephi/delphi/ctrlsym delphi/delphi/property/ctrlsym
default: delphi/delphi/property/keyword delphi/delphi/property/keyword
;: delphi/delphi/ctrlsym delphi/delphi/property/ctrlsym

This for the easy part.

The more complicated one will go for example with PHP inside a HTML document.
In this case there are TWO (or more) possible ways:
1. use the path relative to context nesting html/html/php/php/something
2. use the path absolut to the language root php/php/something

Both have their advantages, but I can't tell what will cause less trouble. Although they are "helpers" for code context distinguishing "only" and only used to detect in what specific code segment the parser actually is. Thus IMHO the second should do for most cases. The decision is up to you anyway :P
 
(0000019)
nigel
10-22-05 12:41

Only the second one is possible anyway, I think. I tried the first one a while ago with "namespace support" - this was the ability to highlight PHP embedded in one part of the document differently from PHP embedded in the other part. So PHP in CSS (itself in HTML) could be different from PHP in just HTML.

Passing the real name (non-aliased) through seems like the way to go. So you'll get tokens coming through with extra data.

I'm going to change the third parameter of GeSHiCodeParser::parseToken() to be an array of data, one index can be the real name if any. Another can be the URL, which is what the third parameter currently is anyway.
 
(0000056)
BenBE
11-20-05 03:14

Could you tell me some starting points on how to write the "default"-detection? I could not find to get a way into the API. :(
 
(0000059)
nigel
11-20-05 16:36

Well I haven't actually written that code yet. I've been a little slack recently!

But I plan on modifying some of the CodeParser code to do it. When I do I'll give you instructions on how it should be able to be done.
 
(0000070)
nigel
11-26-05 16:34

I've done the necessary modifications, and now you should be able to fix this. In addition, I've put preliminary support in the class.delphicodeparser.php class.

I left a TODO in there for you that details a problem with my quick-hack method - the _defaultFlag is not reset soon enough, meaning that code like this:

property foo nodefault; // default

Looks dumb because the "default" is highlighted despite being in a comment. I'll leave it as an exercise for you to fix (this being your bug anyway!).
 
(0000082)
BenBE
12-03-05 02:21

The highlighting should work now. Even the default in following contexts is now handled correctly AFAIK.
 
(0000092)
nigel
12-04-05 13:12

Looks good to me.
 
(0000123)
nigel
12-11-05 22:28

Issue closed.
 

- Issue History
Date Modified Username Field Change
10-21-05 12:22 nigel New Issue
10-21-05 12:22 nigel Status new => assigned
10-21-05 12:22 nigel Assigned To  => BenBE
10-21-05 12:23 nigel Relationship added child of 0000006
10-21-05 22:06 BenBE Note Added: 0000007
10-22-05 00:26 nigel Note Added: 0000013
10-22-05 07:18 BenBE Note Added: 0000017
10-22-05 12:41 nigel Note Added: 0000019
11-20-05 03:14 BenBE Note Added: 0000056
11-20-05 16:36 nigel Note Added: 0000059
11-26-05 16:34 nigel Note Added: 0000070
12-01-05 07:37 BenBE Relationship added related to 0000026
12-03-05 02:21 BenBE Status assigned => resolved
12-03-05 02:21 BenBE Fixed in Version  => 1.1.1alpha3
12-03-05 02:21 BenBE Resolution open => fixed
12-03-05 02:21 BenBE Note Added: 0000082
12-04-05 09:40 BenBE Relationship added child of 0000033
12-04-05 13:12 nigel Note Added: 0000092
12-11-05 22:28 nigel Status resolved => closed
12-11-05 22:28 nigel Note Added: 0000123

  


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