[Lazarus] lazarus Digest, Vol 143, Issue 10

[Don Siders]

>> I edit manually too. It's neither difficult nor error prone. I get
>> exactly the FP Doc markup that I feel is appropriate.

> Now we have a problem. FPDocEditor and LazDocEditor ARE distributed with
> Lazarus, and nobody is prevented from using them. So, when I modify one
> of your recent xml files using FPCDocEditor, there's a chance that
> FPDocEditor will destroy your markup...

No. It won't destroy anything. It may turn it into a unreadable mess
for the human being editing the file. But it won't lose or alter
anything beyond whitespace and indentation levels.

>  and add numerous svn diffs again.

Now this is the *real* issue, and it's one that others have brought up
as well. Consider for a moment that makeskel writes a skeleton using
an empty <short></short> element and the doc editors use the <short/>
tag. Built in diffs. And it has nothing to do with me, my selected
tool chain, or files that I have touched.

I do add blank lines and indentation. I'm not a machine... I need it.

>> I am using the IDE to navigate source and determine ancestry. I use
>> Atom to edit the FP Doc XML description files (due to its support for
>> XML syntax and "XML-completion" facilities). I use Tidy to validate
>> the XML content. I use ASpell to catch spelling mistakes and
>> fat-fingered typing.

> A long tool-chain. Only enthusiast like you will do that.

I wasn't advocating their use. The question was asked and answered. That's all.

Look. I'm not trying to be difficult. I'm not a "rock star"
programmer. So, I chose to contribute in whatever way I could. If what
I'm doing is a pain point for the project, it is easy to resolve.

> I really think that in particular FPDocEditor, maybe also LazDocEditor,
> is an important tool for the occasional user. But it should be re-worked
> to produce consistent and svn-friendly xml files.

I agree.

But I think you'll have to elaborate on the "svn-friendly" bit. For
example, I'm updating controls.xml right now. It's a 600K XML file.
The diff is at 1MB and growing. There is nothing svn-friendly about
that at all. Unless of course, you're not interested in the updates
just to keep the svn history clean and tight.
--
Don