So, when I start to implement a Pascal Parser, scanner.l and code.l are my starting points ?
Or have I do adapt own files ?

It all depends on the changes but to get a bit of an idea one can search for the word "fortran" or "python" (case independent) in the sources (as these are more distinct words).
The parser has to be registered so probably types.h, message.h, debug.h, classdef.h, util.h (and corresponding cpp files).
Besides the new parsers also some changes might be necessary in commentcn.l and pre.l
Depending on the changes made, when there will be special translations (English is the master of the translations) of terms necessary it might be necessary to add translation functions (translator....h).

As said best to search for he word "fortran" or "python" and see where potential something has to be changed.

Note creating such a parser needs an in depth knowledge of the language (in this case pascal) to be parsedand is more a question of weeks to create than of hours.

Ok. Thanks for your approach words.
I will let me the time to study the source. And it would be nice, if you have enough time, that you can give me assistancaces here and there to get involved into Doxygen. I know, I would not understand all of the inernal things... But one I have read out of posts and articles that doxygen creates a hash for its links. This is so the only one that I read out the few days I study the sources.

The problem is not about hashes etc, here the developer of a new parser has nothing to do (are existing routines that can be used), the parser developer has more to do about translating the new language into a structure that doxygen uses and get (nearly) all the syntax possibilities of the new language into this structure. Best is first to study e.g. the scanner.l or fortranscanner.l

okay. I have forget to use the lexer option %option stack.

I have fork and upload a copy of doxygen project here.
So, if you would like to have a look to the sources, you can study the files there and compare new directory files tree with yours.

Let me know if you made changes at origin point of doxygen that are relevant to parsers.

I have fork and upload a copy of doxygen project here.

This is not a fork but a copy, a fork would be much more convenient as here you could make your changes and at the end (after probably squashing the intermediate commits) make a proposed pull request, furthermore it would also be easier to update when things change in doxygen master (and you would see whether or not there are changes relevant to the parser).

So, you mean, I shall use a private branch of a Fork that depends on your git Project ?
This is possible at me.
I have only concerns with change sources. Because I am not so familar with github.com.

So I think we should split the work, like you said before with the answer to my question with the parsers.
You wrote (something wordso...) that Parser are a part and the generating of documentation is an other part.
So, we have two branches...

I will hold me on the parser, for now.
You can help me then, to combine the parser with doxygen.

Would be a good deal ?

I don't this is a good deal. I think some basic knowledge of git doesn't hurt, I'm not a big fan of git but after a while been able to cope quite well with it (in the past I used other source code control systems and they had another philosophy).

We don't have 2 branches, the generating of the documentation is one of the parts of doxygen in a "pipeline" (more ore less depicted in https://www.doxygen.nl/manual/arch.html) the scanner and code lexers are other parts in the "pipeline".

Edit
The link works, but it don't refer to the "Files Changed" Tab (what I shall openend with the link bellow):

Hey, github is cewl: I found this here
which give me a reuest pull file change versioning.
It will detailed show, what I had make of new and existing changes - very cewl.

With 2 branches, I mean the split of government a team - the one does this, the other one does that.
Please sorry for my English - I told you, it is very bad and I try my best to hold and learn coding and writing english sentences.

With deal, I don't want handle out a contract or something else.
It would mean, that you should split the work on doxygen into different places.

I can see that a minor different of user/other developers use RP's to extend or change the state of soxygen.
But no one is bound as a team member - like I can see.
It is a mixed handfull programmers, where supporting doxygen as part time scientists - but not as team.

Okay, as team member you have to hold on regulars.
And this regulars I mean with the deal.
Because you wrote on other place, that the pre-action is, to parse the sources. the post action is, that doxygen generates documentation.
For me, these steps are two branches (in 1:1 translated from german to english).

Not more, not lesser...