Le 11/11/2021 à 17:11, Carl Sorensen a écrit :
*From: *Paolo Prete <paolopr...@gmail.com>
*Date: *Thursday, November 11, 2021 at 9:07 AM
*To: *Jean Abou Samra <j...@abou-samra.fr>
*Cc: *Carl Sorensen <c_soren...@byu.edu>, Kieren MacMillan
<kieren_macmil...@sympatico.ca>, Lilypond-User Mailing List
<lilypond-user@gnu.org>
*Subject: *Re: How to increase the distance between the last note of a
measure and the following bar line
I am not managing to convey my meaning across. The
Scheme example was _not_ intended to become something
outputting documentation for on-the-fly usage in editors.
It was meant to be a proof-of-concept for retrieving
and structuring the information (rather than formatting
it) in a way that could be reused in the autogeneration
process that outputs the official Internals Reference.
Our autogeneration script is written in Scheme.
I see. Is the autogeneration script made from scratch, or does it feed
some preexisting tool, that inspects a set of files, for autodoc?
I mean: in case of C++ code, Doxygen is (more or less) simply fed by a
set of options and then, voila, the autodoc is generated.
If not, I wonder as well if is it possible to use an alternative to
the previous script and generate the autodoc by pointing to the src
dir with some tool.
The problem is that part of the source files to be explored are
written in Scheme, and part are in C++. I don’t know of any existing
tool that works with both languages.
So we have a custom documentation tool, written in Scheme.
The standard autodocumentation tools wouldn't help
much either.
- The bulk of the work is extracting information from
LilyPond's internals. Take predicates. Their mapping
to names is maintained in the code, so we would have
to make the tool aware of our predicates.
- Our concepts of "grobs", "interfaces", "engravers",
"contexts", etc. are not understood by tools that
work in terms of "classes", "methods", "members"
and such.
- All styles (like CSS stylesheets) are tailored for
texi2html and shared across all the documentation.
The tool in question would necessarily have to generate
Texinfo input. Doxygen and GTK-doc can't do that
(Sphinx can).
Overall, LilyPond's code base is quite special in
a number of regards and existing autodocumentation
tools are not suited well to it.
While I wouldn't be against moving to a different
documentation tool (with a marked preference for Sphinx),
we would have to do it for all of the documentation at
once, it would be a big change, and it would not really
reduce the amount of scripting required to generate
the Internals (which is not all that much of a hassle
in the end).
Best regards,
Jean