Am 19.12.2011 04:05 schrieb Hans-Peter Diettrich drdiettri...@aol.com:
Mattias Gaertner schrieb:
I understand that conflicts can arise, when the same XML file is
modified by different means. But it is not nice when the IDE then crashes.
Can you create a stacktrace?
How?
The IDE only
On Sun, 18 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
I have done so for years, with the existing tools, using the Makefiles.
No changes were necessary.
Can you explain that a bit more? I'm not a professional commandline user,
perhaps I'm doing something stupid?
On Sat, 17 Dec 2011 17:06:21 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Mattias Gaertner schrieb:
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
The documentation related features could become Lazarus plug-ins, of
course,
Mattias Gaertner schrieb:
I understand that conflicts can arise, when the same XML file is
modified by different means. But it is not nice when the IDE then crashes.
Can you create a stacktrace?
How?
The IDE only disappears, silently, including the console window :-(
DoDi
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
ACK. There is no *need* to use MakeSkel with a project, but using this option
offers many advantages.
When we look at new packages, some general tasks come into mind:
[snip]
I'd prefer that all
Michael Van Canneyt schrieb:
When we look at new packages, some general tasks come into mind:
[snip]
I'd prefer that all beforementioned tasks can be accomplished by a
single program, by only giving it an project file, task, and
task-specific options.
Feel free to create this program.
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
The documentation related features could become Lazarus plug-ins, of
course, similar to or as an extension of the FPDoc Editor window. But
this already existing support makes it *harder* to add further
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the tasks you
outline belong in a Documentation writers IDE.
To some degree, maybe. But checking for updates should be doable by a script,
without
michael.vancann...@wisa.be schrieb:
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the
tasks you outline belong in a Documentation writers IDE.
To some degree, maybe. But checking for updates
Mattias Gaertner schrieb:
On Sat, 17 Dec 2011 15:41:32 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:
[...]
The documentation related features could become Lazarus plug-ins, of
course, similar to or as an extension of the FPDoc Editor window. But
this already existing support makes
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
michael.vancann...@wisa.be schrieb:
On Sat, 17 Dec 2011, Hans-Peter Diettrich wrote:
Michael Van Canneyt schrieb:
Feel free to create this program. If I may give some advice: the tasks
you outline belong in a Documentation writers IDE.
Michael Van Canneyt schrieb:
I have done so for years, with the existing tools, using the
Makefiles. No changes were necessary.
Can you explain that a bit more? I'm not a professional commandline
user, perhaps I'm doing something stupid?
I just do a make updatexml or make updatefclxml or
On Fri, 16 Dec 2011, Hans-Peter Diettrich wrote:
When MakeSkel shall use FPDoc projects, this can be achieved by adding
something like:
procedure LoadProject(const Arg: string);
begin
ProjectName := Arg;
Project := TFPDocProject.Create(Nil); //owner component?
With
Michael Van Canneyt schrieb:
Then the created skeletons can be added to the DescrFiles list, and
the updated project can be saved on exit.
I don't think this is good. makeskel creates a diff, you should not add
this to the list of files; instead, after it was created, it should be
merged
On Fri, 16 Dec 2011, Hans-Peter Diettrich wrote:
No. You forget that the coupling with unit names does not exist.
Please explain?
Both FPDoc and MakeSkel accept one or more --input arguments, each
representing one *unit*. When a project is used instead, either none or all
units can be
Michael Van Canneyt schrieb:
Consider an existing FPDoc project, which contains all input files and
all currently existing description files. When you want to create a
new skeleton for an not yet documented unit, how to achieve that?
Should the user copy the stored --input specification for
16 matches
Mail list logo
