[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: Paolo Prete
Subject: Re: How to increase the distance between the last note of a measure and the following bar line
Date: Thu, 11 Nov 2021 00:11:04 +0100

(En passant: I tried \info BarLine but could not see "extra-spacing-width". See the attached debug)

But in general, I think it's not a good idea to dump these kind of doc infos as the output of a library, for several reasons.
First of all because it has limitations in formatting and in linking between different pages. The resulting output is therefore too long to read.
I think it's enough to make some adjustments to the current output of the autodoc tool.
First one would be to add, with small fonts, at the bottom of the page, a list of the pairs (as links): class/interface - overriden/implemented property, inside an expandible panel (hidden by default). 
In this way, IF I can't find an useful property in the main panel, THEN I can look at the implemented interfaces list at the bottom. At this point, if in this (short) list there's a name that looks interesting, I click on it without expanding the below panel, and I jump to the linked page. If I can't guess the right interface, I would expand the below panel and I would look more accurately in the contained (long) list. This avoids to jump forth and back from page to page.
In general, I see this as a good default choice for the autodoc of libraries, but even if it's not set as default, the command to produce a complete autodoc should be documented as well. In this library (which I made some years  ago and could not update, in the last years)

you can find a directory for the autodoc (Doxygen) and the instructions to build it. Then, it is left to the user how much complete or minimal the autodoc has to be.


On Wed, Nov 10, 2021 at 10:36 PM Jean Abou Samra <> wrote:
>> The page in the Internals Reference doesn't
>> list all the properties that the grob would
>> support, only those for which it has a specific
>> default. You have to explore the interfaces to
>> find other interesting properties that you can
>> tweak. In this case, click "Item" ("This object
>> is of class Item"). You'll find extra-spacing-width
>> in the item-interface.
> This is something I’ve asked a couple times before, but been dismissed… Maybe you can help?
> Is there an Automagic™ way to print out a “complete tree” of all properties that a grob supports, including any default values?

Sure. How about the attached?

Bear in mind that this may stop working in future
versions (in fact I have a branch somewhere that
would definitely break it if I ever manage to
complete the work).

> Thanks.
> However, when looking for a property or function that might fit what I
> need, I always check for inherited stuff. In this case, unfortunately,
> the search is a bit cumbersome and tricky and it's not the first time,
> especially when the properties are so many and I have to write the
> code quickly, that I don't find the right property.
> Suppose that an object has many settable properties: there is a main
> page of this object, let's call it "A", and other pages with inherited
> properties (B, C, D, E etc.)
> When I do a search, I first look inside A: if I don't find anything
> useful, I look in B and if I don't find anything useful here too, I go
> back to A and then I go to C etc.
> You can understand that, when there are so many properties, jumping
> back and forth from page to page is inconvenient to remember what is
> available as a sum of things. In many automatic documentation of other
> libraries I use, the inherited properties and functions are listed
> grouped (with relative links), sometimes in small format, at the
> bottom of the page to avoid this inconvenience.
> It is true that the resulting page is longer, but it is not heavier to
> read. Furthermore, in this way you can read only the names, without
> the descriptions, of these properties and this allows you to decide
> whether or not to jump to the page that defines the inherited property
> to try. Mine is a suggestion, and I think it's useful to add it to the
> documentation (or at least explain how to create this "extra"
> documentation automatically)

Would the attached mock a good way to format
this documentation in your opinion?


Attachment: debug.txt
Description: Text document

reply via email to

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