On Sun, 18 Sep 2005, Darius Blaszijk wrote:
> On Fri, 2005-09-16 at 22:17, Michael Van Canneyt wrote:
> > I'd rather you keep these todo separate. It'll slow down parsing
> > (which is already horribly slow) and I see no added value. If you must
> Could you elaborate on that?? I don't see a prob
On Fri, 2005-09-16 at 22:14, Sebastian Günther wrote:
> I think I can easily add this. I think it would be sufficient to 'just'
> support it, without usage within the doc writers?
I don't see much use in that. If text does not appear back in the
documentation then there is no point adding text.
On Fri, 2005-09-16 at 22:17, Michael Van Canneyt wrote:
> I'd rather you keep these todo separate. It'll slow down parsing
> (which is already horribly slow) and I see no added value. If you must
Could you elaborate on that?? I don't see a problem in adding a tag.
While indeed it will slow down par
Michael Van Canneyt schrieb:
>
> I'm not yet convinced that having a DB backend to FPDoc will be so trivial,
> but if you think it's easy to do: I'm all for it :-)
Okay. I'll try to have a look on this within the next days. At the
moment we have a state of emergency, as Oktoberfest just startet ;
On Sat, 17 Sep 2005, Florian Klämpfl wrote:
> Sebastian Günther wrote:
> > Florian Klämpfl schrieb:
> >
> > > I would prefer to profile the xml reader and see if we can improve it.
> >
> >
> > Yes, but I don't see this mutually exclusive :)
>
> Can somebody send me profiler output? Or how ca
Sebastian Günther wrote:
Florian Klämpfl schrieb:
I would prefer to profile the xml reader and see if we can improve it.
Yes, but I don't see this mutually exclusive :)
Can somebody send me profiler output? Or how can it be reproduced?
___
fpc-pa
On Fri, 16 Sep 2005, Sebastian Günther wrote:
> Michael Van Canneyt schrieb:
> >
> > I didn't mean the FPC implementation specifically, but XML in general
> > is slow to parse.
>
> Yes
>
>
> > I know, but this would require a major rewrite of FPDoc.
> > The TDOMElement is deeply rooted in
Michael Van Canneyt schrieb:
>
> I didn't mean the FPC implementation specifically, but XML in general
> is slow to parse.
Yes
> I know, but this would require a major rewrite of FPDoc.
> The TDOMElement is deeply rooted in the structure.
> And you need the XML anyway for transforming the ps
Florian Klämpfl schrieb:
>
> I would prefer to profile the xml reader and see if we can improve it.
Yes, but I don't see this mutually exclusive :)
- Sebastian
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mai
On Fri, 16 Sep 2005, Sebastian Günther wrote:
> Michael Van Canneyt schrieb:
> >
> > I'd rather you keep these todo separate. It'll slow down parsing
> > (which is already horribly slow)
>
> Huh? Really?
I didn't mean the FPC implementation specifically, but XML in general
is slow to parse.
Sebastian Günther wrote:
Michael Van Canneyt schrieb:
I'd rather you keep these todo separate. It'll slow down parsing
(which is already horribly slow)
Huh? Really?
A small reminder: FPDoc can support different backends, the XML storage
is just the only one currently implemented. We can tal
Michael Van Canneyt schrieb:
>
> I'd rather you keep these todo separate. It'll slow down parsing
> (which is already horribly slow)
Huh? Really?
A small reminder: FPDoc can support different backends, the XML storage
is just the only one currently implemented. We can talk about this
anytime...
On Fri, 16 Sep 2005 [EMAIL PROTECTED] wrote:
> Hi there,
>
> For Lazarus I have made a tool called LazDoc that attempts to integrate a
> documentation editing tool with the IDE. Depending on the position of the
> cursor on the source editor, the appropriate documentation tag is searched
> and t
[EMAIL PROTECTED] schrieb:
> Hi there,
>
> For Lazarus I have made a tool called LazDoc that attempts to integrate a
> documentation editing tool with the IDE. Depending on the position of the
> cursor on the source editor, the appropriate documentation tag is searched
> and then selected in the e
14 matches
Mail list logo
