On Fri, 28 May 2010, Adem wrote:
Hi,
[My first post here; please be forgiving.]
Quite sometime ago I worked with Anthony (wasn't much, mainly testing and
code suggestions etc.) for a while (2002-2003) on JEDI Code Format (JCF).
At the time, especially when compared to DelForEx, JCF was noticeably slow
--basically because of internal structure design choices.
A rewrite (or, rather, a major overhaul) was needed, but now that I took a
look at v2.43 source, it seems Anthony never got round to it.
Don't get me wrong; I do understand his reasons: I, for one, didn't have a
fraction of his patience or stamina.
But, seeing the above threads about 'case higlighting' and 'using regexs for
syntax higlighting', I remebered my main complaints about JCF --that not only
was it slower than necessary, much of it was also a duplication of an already
acomplished job: Namely, duplicating what FPC already does --parsing and
tokenizing.
Given that I have some time to spare now, I would like to tackle using FPC's
own parser/tokenizer engine for a code formatter.
Trouble is, I am not familiar enough with the internals of FPC source tree;
meaning I don't even know where to begin looking for the relevant files in
the FPC tree.
Could someone point me in the right direction please.
I'd also like to hear opinions whether I should spend time on this, or even
whether it is a good idea to use FPC's parser/tokenizer engine for code
formatter.
IMHO: No.
The FPC parser/tokenizer is not very forgiving about errors in the code.
That means that as soon as an error is encountered, the parser stops
parsing. That in turn means that everything below the error will not be
formatted.
Michael.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
