[fpc-pascal]The state of FPC (was: Synapse for FPC)

[Marco van de Voort]

> > It's a matter of taste, but don't forget otherwise you have to
> > scroll/search through the same amount of info. I really dislike units that
> > are longer than 1000-2000 lines.
> > 
> > In time Lazarus could be adapted to make things a bit easier (e.g. opening
> > all includefiles too when opening an unit, 
> 
> Lazarus opens the include files internally. I don't think that many users
> wants to open the 20 include files when opening classes.pp. They are opened
> automatically when you do for example a method jump or a find declaration or
> doubleclick on a codeexplorer item.

I think that is ok.

> I think, an overview of the include files would be nice. I think, the code
> explorer is a good place for this. Any ideas, how this information should be
> merged into the code explorer?

I think this will be a bit hard, because not only purely the sequence
matters, but also the exact place inside of the source.


OTOH, for simply moving up and down from unit into include files it could be
ok. But I'm not really that used to such visual gadgets (I prefer kbd
shortcuts), so maybe I'm not the best judge of this.
 
> > and clicking a {$I ..} line switches to it or so.
> 
> "Find declaration" and "open filename at cursor" does this.

I'd keyboard shortcut the last one, but for the rest ok:-)
  
> > [...]
> > 
> > > I think the end user would benefit from the 'preprocessed' units at
> > > release time, and the developers would keep whatever grand scheme they
> > > desire at development time.
> > 
> > How do you merge back user fixes then? Do you want to distribute each unit
> > for each platform-OS version? Would become a huge source zip then.
> 
> .. and think about bugreports and other communications referring to files
> and line numbers. This can become a tower of babel. 

Yes. The only option anyway is to provide a tool to generate such files for
own personal reference. But the human resource of the core team simply 
are not up to adding anything which isn't really absolutely essential.

And no patches will be accepted about such units, and ambigious bugreports
set to "unreproducable" or so.

> > 
> > The only systematic solution would be more people. And not in the future
> > (people have been saying that for years), but NOW.
> > 
> > Extra people don't have to be really hardcore developpers:
> > - People that get a kick out of helpdesk work can always apply ;-)
> > 	(answering questions, bugreport analysis)
> > - Intermediate users that compile a lot of Delphi code, and make a very 
> > 	precise analysis of what is wrong, and how to fix it.
> > - we still need a webmaster
> > - documentation. (Michael does this nowadays), both making it and 
> > 	proofreading.
> > - making headerconversions.
> > - making demoes
> > - be Lazarus liasions officer.
 
> :)

It is actually quite serious. 
 
> > - somebody to look into the win32 net-installer thing.

    - release engineering
    - other tools building (think about an idl2pas or so)
    - helpfile and related tools.