[Top][All Lists]

[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 21:37:01 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

Le 11/11/2021 à 20:15, Paolo Prete a écrit :
On Thu, Nov 11, 2021 at 7:30 PM Carl Sorensen <> wrote:

    The thought of having to make a “TimeSignature_wrap”, as opposed
    to a “Grob_wrap”, is antithetical to the LilyPond core
    principles.  We insist that, as much as possible, internals
    documentation be created from executable code, rather than
    comments about the code, because we don’t want the documentation
    to diverge from the actual code.  Thus, the interfaces listed as
    affecting BarLine don’t come from somebody keeping a list of the
    interfaces related to BarLine, they come from the
    bar_line_engraver declaring (in the C++ code) the interfaces
    actually used.  And there is virtually no static mapping.

This is not what I meant. In my idea, you don't have to touch, replace or modify the "Grob_wrap" principle of LilyPond. You just have to *add* a static wrap, and not necessarily manually: for example you can use the tool that Jean just provided. I thought that the tool  was meant for formatting the doc, because this thread belongs to the *user* lists, but once Jean clarified that "it is _not_ intended to become something outputting documentation for on-the-fly usage in editors" , then you can generate an additional *redundant* wrap with it, so to feed the autodoc tool that you want to use and that you (user) can keep aligned with the previous wrap whenever you (user) want (given that the objects don't change so often).

I think we are losing sight of the problem
at hand. The problem is designing a better
organization and layout for the Internals
Manual. It is not hard at all to do this
by just changing the autogeneration infrastructure.
The snippet I posted is in fact a remix of
that script. We can write CSS for use in Texinfo.
I don't see why we would want to complicate our
lives with different documentation tools just
for that.

At this point, what is needed is input on
precise ways to structure the information.

Best regards,

reply via email to

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