On Jan 2, 2022, at 17:59, Valentin Petzel wrote:
>
> Is there a good reason why we limit the scheme handles for find_context to
> finding above and only by context name (and not id)? If not I’d revise this,
> as
> the context id based approach would require such functionality.
The answer is u
The big difference here is that with the context names one would need to
redefine the whole grid whenever something changes. Meanwhile the id way allows
for each context to chime in and out on the grid without knowing what else is
on the grid. This gets really useful when we do things like parts
Am Sonntag, dem 02.01.2022 um 11:51 + schrieb James:
> Happy New Year everyone!
>
> Here is the current patch countdown list. The next countdown is
> scheduled for January 4th, although now having seen the sheer number of
> MRs I wonder if I should add another day?
>
> Let me know. I'll ass
> While translating I saw that the tag recognized by
> lilypond-book is called environment (as \lilypond{} in LaTeX).
> Wouldn't it be more correct to call it tag?
>
> Here's the part of the Usage manual where HTML is discussed:
> https://gitlab.com/lilypond/lilypond/-/blob/master/Documentation
Le 02/01/2022 à 09:20, Valentin Petzel a écrit :
Sorry, that was not meant that way. This was intended to demonstrate the
usefulness of having such an id for the line, no matter if it is a separate
property or a value of details.
(Having one id property for all grobs does seem reasonable.)
About
Hi
While translating I saw that the tag recognized by
lilypond-book is called environment (as \lilypond{} in LaTeX).
Wouldn't it be more correct to call it tag?
Here's the part of the Usage manual where HTML is discussed:
https://gitlab.com/lilypond/lilypond/-/blob/master/Documentation/en/usa
Happy New Year everyone!
Here is the current patch countdown list. The next countdown is
scheduled for January 4th, although now having seen the sheer number of
MRs I wonder if I should add another day?
Let me know. I'll assume silence means the 4th is OK.
A list of all merge requests can b
Sorry, that was not meant that way. This was intended to demonstrate the
usefulness of having such an id for the line, no matter if it is a separate
property or a value of details.
(Having one id property for all grobs does seem reasonable.)
About the other thing: It gets more complicated for bo
