Re: vertical spacing of footnotes

[Werner LEMBERG]

>> Am I the only one who thinks users shouldn’t have to add
>> transparent letters with ascenders and descenders in order to have
>> a consistent line height?!  Working with text should not require
>> such efforts…
>
> Unfortunately, LilyPond's idea of stencils is not prepared for doing
> that automatically: a stencil is basically a drawing expression + an
> X extent + an Y extent.  The info on the lines of text that made
> this stencil, if it was made from text, is lost.  [...]

Do you remember the discussion about `\strut` on the 'lilypond-devel'
list?  I've come up with the following, which works nicely.

```
#(set-default-paper-size "a8landscape")

#(define-markup-command (strut layout props)
   ()
   #:properties ((baseline-skip))
   (let ((yext (cons (* -0.3 baseline-skip)
 (* 0.7 baseline-skip
 (ly:make-stencil
  (ly:stencil-expr (make-transparent-box-stencil '(0 . 0.05) yext))
  empty-interval
  yext)))

\book {
  \header { tagline = ##f }

  \paper {
footnote-padding = -1\mm
footnote-separator-markup =
  \markup \column {
\vspace #0.5
\fill-line { \override #'(span-factor . 1/2) \draw-hline }
\vspace #0.5
  }
  }

  \markup "time-based footnotes"
  \relative c'' {
r1 |
\footnote #'(-0.5 . -1)
  \markup { \strut "Meter change." } Staff.TimeSignature
\time 3/4
\footnote #'(1 . -1)
  \markup { \strut "Chord stem." } Stem
4 q q
\footnote #'(-0.5 . 2)
  \markup { \strut "Bar line." } Staff.BarLine
q q
\footnote #'(0.5 . -1)
  \markup { \strut "Key change." } Staff.KeySignature
\key c \minor
q
  }
}
```

There are some problems, though.

* In what context are footnote texts handled?  I want to globally
  adjust `baseline-skip` for my (redefined) `\strut` function, but I'm
  not able to do it.

* `footnote-padding` is completely undocumented, as are the following
  footnote parameters:

footnote-footer-padding
footnote-number-raise
footnote-stencil
number-footnote-table
footnote-numbering-function (at least there is a regtest)

* Too bad that `footnote-padding` is also applied between the footnote
  separator and the first footnote, which necessitates a redefinition
  of the footnote separator markup.

* If there were a context, I could apply Valentin's 'replace' trick:

  ```
  \override TextScript.before-line-breaking =
#(lambda (grob)
   (ly:grob-set-property!
 grob 'text
 (markup #:replace
 `(("@" . ,#{ \markup{ \strut } #}))
 (ly:grob-property grob 'text
  ```

  [I'm aware that in this case `before-line-breaking` is probably not
   correct, but...]

  which would simplify the above footnote entries to

  ```
  \footnote #'(-0.5 . -1) "@Meter change." Staff.TimeSignature
  ```


Werner

Endnotes vis-à-vis footnotes

[Adam M. Griggs]

Werner's message here on footnote spacing has reminded me of something I
sometimes wish I had in LilyPond: endnotes.

Whereas footnotes are printed at the base of each page, endnotes would
appear in a block at the end of the score by default, with \pageBreak
optional. Also, their appearance could be delayed so as to accommodate
multi-movement works or even whole volumes without interruption.

There could be dozens or even hundreds of endnotes and so, like the ToC,
the endnote block would spill over to subsequent pages gracefully.

I see Urs commented on the possibility in relation to ScholarLY here:
https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00229.html

Is there any current interest from the LilyPond userbase?

Re: vertical spacing of footnotes

[Jean Abou Samra]

Le lundi 13 février 2023 à 19:37 -0500, kie...@kierenmacmillan.info a écrit :

> Am I the only one who thinks users shouldn’t have to add transparent  
> letters with ascenders and descenders in order to have a consistent line  
> height?! Working with text should not require such efforts…


Unfortunately, LilyPond's idea of stencils is not prepared for doing
that automatically: a stencil is basically a drawing expression + an
X extent + an Y extent. The info on the lines of text that made
this stencil, if it was made from text, is lost.

It'd be possible to add an option for making equal spacing between the 
baselines of footnote lines, but it'd be a crutch: it would handle footnotes 
extending on multiple lines poorly.

The real fix would be changing the `Stencil` class to include an additional 
data member
that would be the extent from the baseline of the first line of text to the 
baseline of
the last line of text. Expect a lot of work though: all stencil operations
would have to be modified to account for it.


signature.asc
Description: This is a digitally signed message part

Re: vertical spacing of footnotes

[kieren]

Hi all,


As can be seen in the attached image, the vertical distances between
the footnotes are not identical.  What is the recommended way to fix
this?


Looks like this is due to the presence or absence of descenders.

If you added something like "\transparent q" to the end of the markup, 
it should ensure lines without descenders will have the same height as 
those with them.


Am I the only one who thinks users shouldn’t have to add transparent 
letters with ascenders and descenders in order to have a consistent line 
height?! Working with text should not require such efforts…


Kieren

Re: Slurs inside or outside beamed notes

[GMX]

Yes, Gould does say to always place a slur outside a beam.  And I’m fine with 
that being Lilypond’s default behavior.  But I’d love the ability to tell 
Lilypond to place slurs inside of beams (when possible).

I do have one hymnal that prints slurs inside beams.  I suspect that this 
choice was related to the decision to also beam notes into beats, which I also 
prefer, but isn’t done by any of the other hymnals I have.  So one hymnal puts 
slurs inside beams, but the others only beam slurred notes (and don’t print the 
slur at all).

David

> On Feb 13, 2023, at 2:16 PM, Brian Barker  wrote:
> 
> At 11:47 13/02/2023 -0800, Aaron Hill wrote:
>> I am quite used to LilyPond's default handling of slurs with them positioned 
>> next to the beam, but should I be following the source engraving with the 
>> slurs sit inside so they are closer to the note heads? Does Gould offer 
>> advice on this?
> 
> To your latter question, yes: she says "[The slur] should always remain 
> outside a beam" (Behind Bars, p. 111).
> 
> Brian Barker 
> 
> 

Re: Slurs inside or outside beamed notes

[Brian Barker]

At 11:47 13/02/2023 -0800, Aaron Hill wrote:
I am quite used to LilyPond's default handling of slurs with them 
positioned next to the beam, but should I be following the source 
engraving with the slurs sit inside so they are closer to the note 
heads? Does Gould offer advice on this?


To your latter question, yes: she says "[The slur] should always 
remain outside a beam" (Behind Bars, p. 111).


Brian Barker 

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Jean Abou Samra]

Le lundi 13 février 2023 à 12:02 -0500, Kevin Cole a écrit :

> That's okay too... as long as, when I ask a question, the answer isn't  
> always "upgrade".


To speak for myself: If you say in your post “I know that this feature is in 
the latest stable
version but I can't/don't want to upgrade because of X”, I will try to
help you with whatever version you have. But otherwise, yes, I will always
recommend upgrading to the latest stable version. What is bad about that?
One a stable version is out, everybody will unlearn now outdated practices
and learn new ones, so you will get better support for it even if you don't
count the new features and fixes.

The latest two stable releases took a total of 3 years, so it's not exactly
like we're asking everyone to upgrade every week.



signature.asc
Description: This is a digitally signed message part

Re: vertical spacing of footnotes

[Aaron Hill]

On 2023-02-13 11:36 am, Werner LEMBERG wrote:

As can be seen in the attached image, the vertical distances between
the footnotes are not identical.  What is the recommended way to fix
this?


Looks like this is due to the presence or absence of descenders.

If you added something like "\transparent q" to the end of the markup, 
it should ensure lines without descenders will have the same height as 
those with them.



-- Aaron Hill

Slurs inside or outside beamed notes

[Aaron Hill]

Attached is an image showing an excerpt from a reference score as well 
as output from LilyPond.


I am quite used to LilyPond's default handling of slurs with them 
positioned next to the beam, but should I be following the source 
engraving with the slurs sit inside so they are closer to the note 
heads?  Does Gould offer advice on this?



-- Aaron Hill

vertical spacing of footnotes

[Werner LEMBERG]

Consider this example.

```
#(set-default-paper-size "a8landscape")

\book {
  \header { tagline = ##f }
  \markup "time-based footnotes"
  \relative c'' {
r1 |
\footnote #'(-0.5 . -1) "Meter change." Staff.TimeSignature
\time 3/4
\footnote #'(1 . -1) "Chord stem." Stem
4 q q
\footnote #'(-0.5 . 2) "Bar line." Staff.BarLine
q q
\footnote #'(0.5 . -1) "Key change." Staff.KeySignature
\key c \minor
q
  }
}
```

As can be seen in the attached image, the vertical distances between
the footnotes are not identical.  What is the recommended way to fix
this?


Werner

Re: `\afterGrace` and clef problem

[David Kastrup]

Jean Abou Samra  writes:

> Le lundi 13 février 2023 à 18:08 +0100, David Kastrup a écrit :
>> That begs the question whether it would make sense to restrict  
>> afterGrace scales to values below 1.  But I think that making syntactic  
>> decisions based on values rather than types is really icky.  It is  
>> probably a bad idea to make syntactic decisions that one would not  
>> expect a syntax highlighter to be able to figure out.
>
>
> You are being self-consistent.
>
> [https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050](https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050)

The worst in that respect on my conscience I remember right now is the
difference between

(ly:make-moment 1 1) and (ly:make-moment 1 -1)

-- 
David Kastrup

Re: `\afterGrace` and clef problem

[Jean Abou Samra]

Le lundi 13 février 2023 à 18:08 +0100, David Kastrup a écrit :
> That begs the question whether it would make sense to restrict  
> afterGrace scales to values below 1.  But I think that making syntactic  
> decisions based on values rather than types is really icky.  It is  
> probably a bad idea to make syntactic decisions that one would not  
> expect a syntax highlighter to be able to figure out.


You are being self-consistent.

[https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050](https://gitlab.com/lilypond/lilypond/-/merge_requests/951#note_696966050)


signature.asc
Description: This is a digitally signed message part

Re: `\afterGrace` and clef problem

[David Kastrup]

Lukas-Fabian Moser  writes:

> Hi Werner,
>
>>> Alternatively you may try to use \afterGrace to insert the \clef
>>> before the bar line, although this would probably require some
>>> manual spacing too.
>> This doesn't work at all: `\afterGrace` doesn't accept a clef, as the
>> image shows.
>
> afterGrace is defined as
>
> #(define-music-function (fraction main grace) ((scale?) ly:music?
>  ly:music?) ...)
>
> You write
>
> \afterGrace 1 { s8 \clef "bass" } | c,1
>
> but 1 is a valid scale? because of
>
> (define-public (scale? x)
>   (or (and (rational? x) (exact? x) (not (negative? x)))
>   (fraction? x)
>   (and (ly:moment? x) (scale? (ly:moment-main x)
>
> in scm/c++.scm.

That begs the question whether it would make sense to restrict
afterGrace scales to values below 1.  But I think that making syntactic
decisions based on values rather than types is really icky.  It is
probably a bad idea to make syntactic decisions that one would not
expect a syntax highlighter to be able to figure out.

-- 
David Kastrup

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Kevin Cole]

On Mon, Feb 13, 2023 at 12:00 PM Saul Tobin  wrote:

> Many users have old projects on very old versions of Lilypond, and sometimes 
> you just want to make a small edit, not update your whole project to use the 
> new version. It's important for documentation to be available.

That's okay too... as long as, when I ask a question, the answer isn't
always "upgrade".

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Kevin Cole]

On Mon, Feb 13, 2023 at 11:55 AM Jean Abou Samra  wrote:
>
> Le lundi 13 février 2023 à 11:40 -0500, Kevin Cole a écrit :
>
> The point I was trying to make was "Does there REALLY need to be
> documentation for versions 2.13 to 2.25?  Maybe 2.20 to 2.25 would
> suffice."
>
> I'm not sure it would help with Qwant/DuckDuckGo/Google searches since we are 
> already marking the old documentation pages with 'Disallow' in robots.txt, 
> which is supposed to prevent Web crawlers from indexing them. Would 
> completely removing the old pages work better, or just turn the search 
> results into 404s instead of outdated documentation?

Ah. I was unaware of the robots.txt -- though sometimes I wonder if
web crawlers pay any attention.

> In any case, the ideal solution would be a client-side search button in the 
> documentation instead of the current Google search button.

THAT, on the other hand, would be wonderful!

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Saul Tobin]

Many users have old projects on very old versions of Lilypond, and
sometimes you just want to make a small edit, not update your whole project
to use the new version. It's important for documentation to be available.

On Mon, Feb 13, 2023, 8:41 AM Kevin Cole  wrote:

> On Mon, Feb 13, 2023 at 11:33 AM Lukas-Fabian Moser  wrote:
> >
> > Hi Kevin,
> >
> > > On the other hand, I strongly favor sticking with a distribution's
> > > package rather than starting every day with a "git pull". So, I'm
> > > always slightly behind the latest and greatest.
> >
> > Just for the record: Your description omits the (actually quite
> > convenient) middle between the two extremes: Namely, that it's quite
> > easy to keep up with current LilyPond development by downloading and
> > using the respective (unstable) builds that are released every few weeks
> > to months.
>
> The point I was trying to make was "Does there REALLY need to be
> documentation for versions 2.13 to 2.25?  Maybe 2.20 to 2.25 would
> suffice."
>
>

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Jean Abou Samra]

Le lundi 13 février 2023 à 11:40 -0500, Kevin Cole a écrit :

> The point I was trying to make was "Does there REALLY need to be  
> documentation for versions 2.13 to 2.25?  Maybe 2.20 to 2.25 would  
> suffice."


I'm not sure it would help with Qwant/DuckDuckGo/Google
searches since we are already marking the old documentation
pages with 'Disallow' in `robots.txt`, which is supposed
to prevent Web crawlers from indexing them. Would completely
removing the old pages work better, or just turn the
search results into 404s instead of outdated documentation?

In any case, the ideal solution would be a client-side search
button in the documentation instead of the current Google
search button.


signature.asc
Description: This is a digitally signed message part

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Jean Abou Samra]

Le lundi 13 février 2023 à 17:37 +0100, Lukas-Fabian Moser a écrit :
> Hi,
> 
> > From [https://lilypond.org/help-us.html](https://lilypond.org/help-us.html)
> >   
> >
> > “Mailing list support: answer questions from fellow   users. (This 
> > may entail helping them navigate the online   documentation; in 
> > such cases it may sometimes be appropriate   to point them to 
> > version-agnostic URL paths such as 
> > ``[/latest/](https://lilypond.org/doc/latest/Documentation/notation) or 
> > ``[/stable/](https://lilypond.org/doc/stable/Documentation/notation),   
> > which are automatically redirected.)”
> 
> Thanks for pointing this out, I never knew about this.  
> But: If I open 
> [https://lilypond.org/doc/stable/Documentation/notation/proportional-notation.html](https://lilypond.org/doc/stable/Documentation/notation/proportional-notation.html),
>I get redirected to 
> [http://lilypond.org/doc/v2.24/Documentation/notation/proportional-notation.html](http://lilypond.org/doc/v2.24/Documentation/notation/proportional-notation.html)
>- so if I copy the URL from my browser into an e-mail, I'm with a  
>  version-specific link again.  
> Wouldn't it be better (if that's at all possible) if the URL   display in 
> the browser could keep the explicit "stable" /   "latest", and in turn 
> add a button returning a permanent link to   the page as currently 
> displayed (which then contains the explicit   version and language tag)?  



Personally, I've long stopped using those links anyway. The problem
is that when we make changes to the documentation, they turn into broken links.
It's actually worse than that: assuming that your browser language is English,
if a node is renamed in the English documentation, then a link with /latest/
will start displaying in a random non-English language because at least some
of the translations (but usually these days, all translations but the French 
one)
are lagging behind.

[https://lists.gnu.org/archive/html/bug-lilypond/2022-10/msg00025.html](https://lists.gnu.org/archive/html/bug-lilypond/2022-10/msg00025.html)

Much better would be a warning at the top of outdated documentation pages
advising to go to the stable version documentation, like you can see on
a number of projects, e.g.,

[https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Preface.html#Preface](https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Preface.html#Preface)


or

[https://tox.wiki/en/3.11.1/](https://tox.wiki/en/3.11.1/)



signature.asc
Description: This is a digitally signed message part

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Kevin Cole]

On Mon, Feb 13, 2023 at 11:33 AM Lukas-Fabian Moser  wrote:
>
> Hi Kevin,
>
> > On the other hand, I strongly favor sticking with a distribution's
> > package rather than starting every day with a "git pull". So, I'm
> > always slightly behind the latest and greatest.
>
> Just for the record: Your description omits the (actually quite
> convenient) middle between the two extremes: Namely, that it's quite
> easy to keep up with current LilyPond development by downloading and
> using the respective (unstable) builds that are released every few weeks
> to months.

The point I was trying to make was "Does there REALLY need to be
documentation for versions 2.13 to 2.25?  Maybe 2.20 to 2.25 would
suffice."

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Lukas-Fabian Moser]

Hi,


From https://lilypond.org/help-us.html

“Mailing list support: answer questions from fellow users. (This may 
entail helping them navigate the online documentation; in such cases 
it may sometimes be appropriate to point them to version-agnostic URL 
paths such as |/latest/| 
or|/stable/| 
, which are 
automatically redirected.)”


Thanks for pointing this out, I never knew about this.

But: If I open 
https://lilypond.org/doc/stable/Documentation/notation/proportional-notation.html, 
I get redirected to 
http://lilypond.org/doc/v2.24/Documentation/notation/proportional-notation.html 
- so if I copy the URL from my browser into an e-mail, I'm with a 
version-specific link again.


Wouldn't it be better (if that's at all possible) if the URL display in 
the browser could keep the explicit "stable" / "latest", and in turn add 
a button returning a permanent link to the page as currently displayed 
(which then contains the explicit version and language tag)?


Lukas

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Lukas-Fabian Moser]

Hi Kevin,


On the other hand, I strongly favor sticking with a distribution's
package rather than starting every day with a "git pull". So, I'm
always slightly behind the latest and greatest.


Just for the record: Your description omits the (actually quite 
convenient) middle between the two extremes: Namely, that it's quite 
easy to keep up with current LilyPond development by downloading and 
using the respective (unstable) builds that are released every few weeks 
to months.


Distribution packages often are lagging behind quite a bit, while doing 
"git pull" (and self-compiling) is much more complicated to set up.


The naming of the development releases as "unstable" is a bit 
misleading: They are unstable more in the sense that features might 
change back and forth (which sometimes, but not often, happens), not 
that they are much more likely to burn your computer than the "stable" 
releases. Actually, the quite rigorous testing standard we have for 
merging code contributions by developers goes a long way to ensure that 
even the daily current master (the one from git pull and self-compiling) 
is usually perfectly fine for everyday production use.


Lukas

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Kevin Cole]

In the past, when I've asked a question, the answer has often been a
gentle RTFM with a link to the appropriate info, followed by "Oh.
You're using the version from four days ago, rather than the version
du jour. That documentation doesn't apply to your version." (Yes, I
know, a bit of an exaggeration.)

If the later is truly the case, then it seems the same argument should
apply to documentation and having documentation for versions 2.13,
2.14, 2.15, 2.16, 2.17, 2.18, 2.19, 2.20, 2.21, 2.22, 2.23, 2.24, and
2.25 on the site seems a tad ridiculous when questions to the list
often elicit a response akin to "You're not using a new enough version
of the software".

Perhaps a bit of pruning / archiving elsewhere / referring people to
git commits / wiki diff's for older versions of the documentation is
in order... Anything from keeping search engines from cataloging way
too much and then confusing various versions into a single mess.

On the other hand, I strongly favor sticking with a distribution's
package rather than starting every day with a "git pull". So, I'm
always slightly behind the latest and greatest. Still, having 13
versions on the same site seems  a bit of overkill.

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Jean Abou Samra]

Le lundi 13 février 2023 à 09:42 -0600, David Wright a écrit :

> Very tangential to this, a URL like:
> 
>   
> [https://lists.gnu.org/archive/html/lilypond-user/recent](https://lists.gnu.org/archive/html/lilypond-user/recent)
> 
> that would redirect to:
> 
>   
> [https://lists.gnu.org/archive/html/lilypond-user/2023-02/threads.html](https://lists.gnu.org/archive/html/lilypond-user/2023-02/threads.html)
> 
> for whatever the current month is, would allow it to be bookmarked.  
> ("Recent" might be less confusing than "latest", because of the  
> other use of that term, as above.)
> 
> What think you?


Unfortunately, list admins don't have the power to change how
these archives are made. That is controlled on the general level
of GNU's list server.

The admin of that server said he was planning to put in place
a different archiving system anyway.


signature.asc
Description: This is a digitally signed message part

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[David Wright]

On Mon 13 Feb 2023 at 15:58:42 (+0100), Jean Abou Samra wrote:
> Mailing list support: answer questions from fellow users.
> (This may entail helping them navigate the online documentation;
> in such cases it may sometimes be appropriate to point them to
> version-agnostic URL paths such as /latest/ or /stable/, which
> are automatically redirected.)

Very tangential to this, a URL like:

  https://lists.gnu.org/archive/html/lilypond-user/recent

that would redirect to:

  https://lists.gnu.org/archive/html/lilypond-user/2023-02/threads.html

for whatever the current month is, would allow it to be bookmarked.
("Recent" might be less confusing than "latest", because of the
other use of that term, as above.)

What think you?

Cheers,
David.

Re: Documentation: Should we possibly have aliases for current stable and current devel?

[Jean Abou Samra]

Le 13 févr. 2023 à 15:51, Valentin Petzel  a écrit :Hello Pondmates!I’ve been wondering recently: When acessing the documentation we are usually acessing a specific version, we have something likelilypond.org/doc/v2.xy/whateverThis seems to mess with Google’s page scoring quite a bit. Now if I were a new user, oblivious to how certain things work (or a long time user, forgetting how some specific things are done) a fast way to get there would be to ask your local search machine.But this will then often direct the user to the wrong version. If I were to search for "lilypond beams" Google would send me to the docs for 2.21 (Qwant and bing both give me 2.23 and 2.22 as top results, very nice!).This will make looking up things harder for users who might be confused about a lot already. So I suppose it might make sense to have some Documentation aliases for the current stable and the current devel versions. Something likelilypond.org/doc/stable/whateverandlilypond.org/doc/devel/whateverThis might over time lead to google & co sending users to the current docs by default and not the one from now again over a year ago.Just recently we had a list entry about Mensurstriche, where the user tried to use the approach given in the 2.22 manual, while the new 2.24 documentation has the much better way this can be done now in 2.24.What is you people’s take on this idea?From https://lilypond.org/help-us.html“Mailing list support: answer questions from fellow users. (This may entail helping them navigate the online documentation; in such cases it may sometimes be appropriate to point them to version-agnostic URL paths such as /latest/ or /stable/, which are automatically redirected.)”

signature.asc
Description: Binary data

Documentation: Should we possibly have aliases for current stable and current devel?

[Valentin Petzel]

Hello Pondmates!

I’ve been wondering recently: When acessing the documentation we are usually 
acessing a specific version, we have something like

lilypond.org/doc/v2.xy/whatever

This seems to mess with Google’s page scoring quite a bit. Now if I were a new 
user, oblivious to how certain things work (or a long time user, forgetting 
how some specific things are done) a fast way to get there would be to ask your 
local search machine.

But this will then often direct the user to the wrong version. If I were to 
search for "lilypond beams" Google would send me to the docs for 2.21 (Qwant 
and bing both give me 2.23 and 2.22 as top results, very nice!).

This will make looking up things harder for users who might be confused about 
a lot already. So I suppose it might make sense to have some Documentation 
aliases for the current stable and the current devel versions. Something like

lilypond.org/doc/stable/whatever

and

lilypond.org/doc/devel/whatever

This might over time lead to google & co sending users to the current docs by 
default and not the one from now again over a year ago.

Just recently we had a list entry about Mensurstriche, where the user tried to 
use the approach given in the 2.22 manual, while the new 2.24 documentation 
has the much better way this can be done now in 2.24.

What is you people’s take on this idea?

Cheers,
Valentin

signature.asc
Description: This is a digitally signed message part.

Re: `\afterGrace` and clef problem

[Werner LEMBERG]

> That is because you are using 1 instead of a note name such as c'1. after-
> grace does not handle this mechanism.

Thanks (and thanks to Lukas, too)!

> Instead of manually extra-offsetting the Clefs you might also do
> something along the lines of [...]

Nice!  I will use that.


Werner

Re: `\afterGrace` and clef problem

[Valentin Petzel]

That is because you are using 1 instead of a note name such as c'1. after-
grace does not handle this mechanism.

You can see here that this does work, but it does produce less optimal 
spacing:

\relative c' {
  <<
\new Staff { \afterGrace f1 { e16[ f] } | g1 }
\new Staff { #(define afterGraceFraction (cons 15 16))
 \afterGrace c1 \clef "bass" | c,1 }
  >>
}

Instead of manually extra-offsetting the Clefs you might also do something 
along the lines of

\relative c' {
  <<
{ \afterGrace f1 { e16[ f] } | g1 }
{ 1
  \once\override Staff.Clef.X-extent =
  #(lambda (grob)
 (let* ((stc (ly:grob-property grob 'stencil))
(ext (ly:stencil-extent stc X)))
   ; Add default BarLine extra-space to Clef (1.0)
   (ly:grob-set-property! grob 'extra-offset (cons (- (1+ (cdr ext))) 
0))
   #f))
  \clef "bass" | c,1 }
  >>
}


Cheers,
Valentin

Am Montag, 13. Februar 2023, 09:12:26 CET schrieb Werner LEMBERG:
> This doesn't work at all: `\afterGrace` doesn't accept a clef, as the
> image shows.



signature.asc
Description: This is a digitally signed message part.

Re: `StaffGroup` influences spacing of `DynamicText`

[Werner LEMBERG]

>> Can someone please explain to me why the 'p sub.' in the first
>> system is badly spaced compared to the second one?  How can I avoid
>> this?  Actually, this smells like a bug...
> 
> You can read your own answer to this question here:
> 
> https://gitlab.com/lilypond/lilypond/-/issues/6350

D'oh, thanks.  Alz, alz, I'm getting old...


Werner

Re: `StaffGroup` influences spacing of `DynamicText`

[Jean Abou Samra]

Le lundi 13 février 2023 à 10:48 +, Werner LEMBERG a écrit :
> ```
> 
> Can someone please explain to me why the 'p sub.' in the first system
> is badly spaced compared to the second one?  How can I avoid this?
> Actually, this smells like a bug...


You can read your own answer to this question here:

https://gitlab.com/lilypond/lilypond/-/issues/6350


signature.asc
Description: This is a digitally signed message part

`StaffGroup` influences spacing of `DynamicText`

[Werner LEMBERG]

Can someone please explain to me why the 'p sub.' in the first system
is badly spaced compared to the second one?  How can I avoid this?
Actually, this smells like a bug...

```
\version "2.25.2"

psub = \tweak DynamicText.self-alignment-X #-0.7
   #(make-dynamic-script
  #{ \markup { \dynamic "p" \normal-text \italic "sub." } #})

\score {
  \new StaffGroup <<
\context Staff = "x" {
  f'8 f' f' f' f' f' f' f'\psub
  f'4 f' f' f'
}
\context Staff = "x" { s1*2 }
  >>
}

\score {
  <<
\context Staff = "x" {
  f'8 f' f' f' f' f' f' f'\psub
  f'4 f' f' f'
}
\context Staff = "x" { s1*2 }
  >>
}
```


Werner

Re: `\afterGrace` and clef problem

[Lukas-Fabian Moser]

Hi Werner,


Alternatively you may try to use \afterGrace to insert the \clef
before the bar line, although this would probably require some
manual spacing too.

This doesn't work at all: `\afterGrace` doesn't accept a clef, as the
image shows.


afterGrace is defined as

#(define-music-function (fraction main grace) ((scale?) ly:music? 
ly:music?) ...)


You write

\afterGrace 1 { s8 \clef "bass" } | c,1

but 1 is a valid scale? because of

(define-public (scale? x)
  (or (and (rational? x) (exact? x) (not (negative? x)))
  (fraction? x)
  (and (ly:moment? x) (scale? (ly:moment-main x)

in scm/c++.scm.

Lukas

Re: `\afterGrace` and clef problem

[Werner LEMBERG]

> [...] I'm rather inclined to count the behaviour of `space-alist`
> for clefs as a buglet: It doesn't make sense allowing the clef to
> move 'under' other notes in different staves while its `space-alist`
> values are applied globally to all staves.

This is now issue #6529.

  https://gitlab.com/lilypond/lilypond/-/issues/6529


 Werner

Re: `\afterGrace` and clef problem

[Werner LEMBERG]

Hello Valentin,


> My suggestion to getting around this would be the tell Lilypond that
> the clef stencil is in fact narrower than it actually is, which will
> allow the Clef stencil to protrude arbitrarily much: [...]

Thanks!  Interestingly, the clef still gets some extra horizontal
space, which is especially undesirable
for `\afterGrace`.  This extra space can be suppressed by setting

```
\once\override Staff.Clef.space-alist.staff-bar = #'(extra-space . 0)
```

but this moves the clef too near to the bar line.  I'm rather inclined
to count the behaviour of `space-alist` for clefs as a buglet: It
doesn't make sense allowing the clef to move 'under' other notes in
different staves while its `space-alist` values are applied globally
to all staves.

The best (optical) solution that I have found so far is to disable
`X-extent` completely, shifting the clef to the left using
`extra-offset`.


> Alternatively you may try to use \afterGrace to insert the \clef
> before the bar line, although this would probably require some
> manual spacing too.

This doesn't work at all: `\afterGrace` doesn't accept a clef, as the
image shows.

```
\markup "no clef change"

\relative c' {
  <<
{ \afterGrace f1 { e16[ f] } | g1 }
{ 1 | 1 }
  >>
}

\markup "lambda for X-extent"

\relative c' {
  <<
{ \afterGrace f1 { e16[ f] } | g1 }
{ 1
  \once\override Staff.Clef.X-extent =
  #(lambda (grob)
 (let* ((stc (ly:grob-property grob 'stencil))
(ext (ly:stencil-extent stc X))
(mod-ext (cons (cdr ext) (cdr ext
   mod-ext))
  \clef "bass" | c,1 }
  >>
}

\markup "X-extent = ##f and extra-offset"

\relative c' {
  <<
{ \afterGrace f1 { e16[ f] } | g1 }
{ 1
  \once\override Staff.Clef.X-extent = ##f
  \once\override Staff.Clef.extra-offset = #'(-2.9 . 0)
  \clef "bass" | c,1 }
  >>
}

\markup "clef change in \afterGrace"

\relative c' {
  <<
\new Staff { \afterGrace f1 { e16[ f] } | g1 }
\new Staff { \afterGrace 1 { s8 \clef "bass" } | c,1 }
  >>
}
```


Werner