[Lazarus] Using FPC parser/tokenizer for code formatting
Mattias Gärtner
nc-gaertnma at netcologne.de
Mon May 31 17:56:40 CEST 2010
Zitat von Adem <listmember at letterboxes.org>:
> On 2010-05-31 16:00, Mattias Gärtner wrote:
>> Zitat von Adem <listmember at letterboxes.org>:
>>
>>> [...]
>>> How would *you* deal with macros?
>> I would not use a complete parser.
>> I would use a forgiving parser like the synedit highlighter or the
>> indentation parser of the codetools.
> Why is this emphasis on the parser being '/forgiving/'?
>
> Why wouldn't I want to know about the ugly truth that the code I
> just wrote will not compile?
>
> Why should I have to wait till I compile the rubbish I produced to
> find out that it is indeed worthless?
Why should I fix all required source files to format one selection?
IMHO a code formatter should not be as picky as a compiler and allow
to format code even if it does not compile (e.g. because it is code
for another target OS).
And I guess, even if the formatter uses the compiler parser, it will
still lack behind. Every time the compiler parser is extended the
formatter needs to be updated. I doubt that the compiler crew will
maintain the formatter, so the formatter will be broken often (and
probably often without noticing).
Using the fcl parser will at least give you helpful entries in the svn
log solely about the parser.
My conclusion:
Using the compiler parser will limit the code formatter to compilable
sources, increases maintenance cost, bites the goal of a fast
compiler, and hardly allows to format fragments. Using the fcl parser
will be easier and allows to create a more comfortable formatter.
Or do it like the codetools and write several different parsers for
the different goals.
Mattias
More information about the Lazarus
mailing list