lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to increase the distance between the last note of a measure and


From: Jean Abou Samra
Subject: Re: How to increase the distance between the last note of a measure and the following bar line
Date: Thu, 11 Nov 2021 17:33:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

Le 11/11/2021 à 17:11, Carl Sorensen a écrit :

*From: *Paolo Prete <paolopr976@gmail.com>
*Date: *Thursday, November 11, 2021 at 9:07 AM
*To: *Jean Abou Samra <jean@abou-samra.fr>
*Cc: *Carl Sorensen <c_sorensen@byu.edu>, Kieren MacMillan <kieren_macmillan@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]