Re: Python easter egg

[Werner LEMBERG]

> For added fun, also try
> 
 import antigravity

:-)

More easter eggs:

https://stackoverflow.com/questions/34472872/purpose-of-python-antigravity-module


Werner

Re: does this Slur handling look like a bug to anyone else?

[Werner LEMBERG]

> [...]
>
> Why would the Slur be positioned differently in these two cases?

Welcome to the mystery world of slur penalties, and sorry for not
having a better answer or an explanation.


Werner

Python easter egg

[Werner LEMBERG]

Something completely off-topic: In case you don't know this, try

```
$ python
>>> import this
```

Enjoy :-)


Werner

Re: regtest threshold problem

[Werner LEMBERG]

>> I'm working on a modification of `musicxml2ly` that will cause a
>> change in the result as shown by the attached images.  However, our
>> regtest classifies this as 'below threshold' and doesn't display
>> it.  [...]
> 
> Independent of improving the metrics, maybe we could improve the
> review workflow by adding dynamic control to the diff web page to
> expand or collapse the entries based on a variable threshold.

Yes, this would be a nice feature – please submit an issue for that.


Werner

regtest threshold problem

[Werner LEMBERG]

I'm working on a modification of `musicxml2ly` that will cause a
change in the result as shown by the attached images.  However, our
regtest classifies this as 'below threshold' and doesn't display it.

Does anybody have an idea how to improve this?  I'm not an expert in
image analysis, and a quick search in the internet didn't help me in
finding a good metrics.  I think we would need something that checks
whether a shape completely disappears and/or reappears in the images
(contrary to shapes that are only slightly shifted and/or distorted),
almost regardless of its size.


Werner

Re: Visual Index Manual where?

[Werner LEMBERG]

> Anyway—shouldn’t it be on
>  as
> well?

It eventually will, as soon as version 2.26 gets released.


Werner

Re: Visual Index Manual where?

[Werner LEMBERG]

> I was reading through the Changes document for 2.25.15 and wanted to
> look at the Visual Index, which it says is now included as a manual.
> However, I couldn’t find it on the overview page for the manuals nor
> as appendix to any manual that it would fit in.

Try

  lilypond.org → Manuals 2.25.15 → Visual Index


Werner

MNX online viewer available

[Werner LEMBERG]

MNX (https://w3c.github.io/mnx/docs/), the successor of MusicXML, has
reached a new milestone a few days ago: For the first time there
exists a simple, rudimentary online viewer:

  https://www.soundslice.com/mnx-viewer/

I suggest that interested people actively take part in the development
of MNX so that a future conversion from and to LilyPond source code
can be done as easily as possible, addressing the needs of LilyPond
where necessary.


Werner

Re: fundamental problem with `\autoBeamOff`

[Werner LEMBERG]

>> > Using \noBeam should let you terminate the beam early: [...]
>>
>> Very nice!  Maybe we should add your fix to the git repository?
>>
> Seems to me like we need a documentation fix.  Something like:
> 
>   A beam that is started by the autobeamer will end according to the
>   autobeaming rules in effect at the start of the beam.  If you wish
>   to terminate an autobeam early, use \noBeam after the last note
>   you want beamed.
> 
> It may be possible to change the autobeam behavior, but it would
> likely increase the computation time for autobeaming, because you
> would have to continually look at both the start and the end of the
> beam.  So I'd propose that making a function change could be a
> feature request, but the lack of documentation is a bug.

Perhaps we are miscommunicating: I'm not talking about changing the
behaviour of the `autoBeaming` property – doing so would probably
cause what you describe.  I'm talking about modifying the
`\autoBeamOff` command by inserting `<>\noBeam` (as suggested by
Aaron), which is something users have already to do if they want to
prevent auto-beaming at a particular place.  I don't see any increased
computation time for this.

Do you see *any* advantage of having `\autoBeamOff` being delayed?


Werner

Re: fundamental problem with `\autoBeamOff`

[Werner LEMBERG]

>> Consider this small example.
>> ```tex
>> {
>>   f'8 f' \autoBeamOff f' f'
>>   f' f' f' f'
>> }
>> ```
>>
>> For me it was surprising to see that `\autoBeamOff` doesn't act
>> immediately but rather two eighths later.  The documentation
>> doesn't mention this, AFAICS, and I consider this behaviour rather
>> counter-intuitive.  Could this be fixed?
> 
> It appears that intentionally the `autoBeaming` property is not
> consulted when considering whether to end a auto-beam in progress.

Thanks for digging!  I've now done some `git blame` calls and found
out that this behaviour was there from the very beginning of the
auto-beamer's existence (in 1999).  Honestly, I don't see any reason
for it – who likes delayed actions like this?

> Using \noBeam should let you terminate the beam early: [...]

Very nice!  Maybe we should add your fix to the git repository?


Werner

fundamental problem with `\autoBeamOff`

[Werner LEMBERG]

Consider this small example.

```tex
{
  f'8 f' \autoBeamOff f' f'
  f' f' f' f'
}
```

For me it was surprising to see that `\autoBeamOff` doesn't act
immediately but rather two eighths later.  The documentation doesn't
mention this, AFAICS, and I consider this behaviour rather
counter-intuitive.

Could this be fixed?


Werner

Re: revising documentation for proportional spacing

[Werner LEMBERG]

> While revising the documentation for proportional spacing [...]

This is now available as

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2279


Werner

Re: revising documentation for proportional spacing

[Werner LEMBERG]

>> ```
>> \override PaperColumn.used = ##t
>> ```
>
> I see in Spacing_engraver::stop_translation_timestep():
>
>   SCM proportional = get_property (this, "proportionalNotationDuration");
>   if (unsmob (proportional))
> {
>   set_property (musical_column, "shortest-playing-duration", 
> proportional);
>   set_property (musical_column, "shortest-starter-duration", 
> proportional);
>   set_property (musical_column, "used", SCM_BOOL_T);
>   return;
> }
>
> so it looks like you can remove it.

Thanks for confirmation.


Werner

revising documentation for proportional spacing

[Werner LEMBERG]

While revising the documentation for proportional spacing in the NR I
stumbled upon

```
\override PaperColumn.used = ##t
```

that gets mentioned without any explanation.  Looking up some
discussion in `lilypond-user` from 2006

  https://lists.gnu.org/archive/html/lilypond-user/2006-12/msg00107.html

it seems that it was necessary then.  However, the examples given in
these e-mails seem to work just fine with 2.25.13 if I omit setting
the `used` property.

Does anybody know more?  Can someone confirm this observation?


Werner

Re: strange `break-align-symbols` behaviour

[Werner LEMBERG]

>> there is no key signature at this point, right?
> 
> This is my interpretation: the key signature is removed by
> break-visibility, but the X alignment of a mark is computed before
> that happens.

Thanks.  If your interpretation is correct I consider it as
problematic, since it is not possible to control the alignment of the
`MetronomeMark` grob as intended.  In particular, specifying
`key-signature` in `break-align-symbols` effectively disables the
`non-break-align-symbols` property.

To demonstrate this please have a look at the following example; the
first line is the default as specified in `define-grobs.scm`.


 Werner


==


\version "2.25.14"

music = {
  \compressEmptyMeasures
  R1*20
  \tempo "Tempo" R1*20
  \tempo "Tempo" \key b\minor R1*20
  \tempo "Tempo" g'1 R1
}


\markup \larger \larger "MetronomeMark"

\markup \vspace #1

\markup "(break-align-symbols . (time-signature))"
\markup "(non-break-align-symbols . (paper-column-interface))"
{
  \override Score.MetronomeMark.break-align-symbols = #'(time-signature)
  \override Score.MetronomeMark.non-break-align-symbols =
#'(paper-column-interface)
  \music
}

\markup "(break-align-symbols . (key-signature))"
\markup "(non-break-align-symbols . (paper-column-interface))"
{
  \override Score.MetronomeMark.break-align-symbols = #'(key-signature)
  \override Score.MetronomeMark.non-break-align-symbols =
#'(paper-column-interface)
  \music
}

\markup "(break-align-symbols . (time-signature))"
\markup "(non-break-align-symbols . (note-column-interface 
multi-measure-rest-interface))"
{
  \override Score.MetronomeMark.break-align-symbols = #'(time-signature)
  \override Score.MetronomeMark.non-break-align-symbols =
#'(note-column-interface multi-measure-rest-interface)
  \music
}

\markup "(break-align-symbols . (key-signature))"
\markup "(non-break-align-symbols . (note-column-interface 
multi-measure-rest-interface))"
{
  \override Score.MetronomeMark.break-align-symbols = #'(key-signature)
  \override Score.MetronomeMark.non-break-align-symbols =
#'(note-column-interface multi-measure-rest-interface)
  \music
}

strange `break-align-symbols` behaviour

[Werner LEMBERG]

In December I asked the question below on the 'lilypond-user' list
(https://lists.gnu.org/archive/html/lilypond-user/2023-12/msg00014.html),
alas, without an answer – I try again, this time on 'lilypond-devel'.
I'm also attaching the image for completeness.

Please help.


Werner


==


Please consider this example.

```tex
\version "2.25.11"

music = {
  c'1
  \tempo "T-note" c'1
}

\markup { time-signature }
{
  \override Score.MetronomeMark.break-align-symbols =
#'(time-signature)
  \music
}

\markup { time-signature, key-signature }
{
  \override Score.MetronomeMark.break-align-symbols =
#'(time-signature key-signature)
  \music
}

\paper {
  ragged-right = ##f
}
```

I don't understand why the addition of `key-signature` to the
`break-align-symbols` list makes 'T-note' left-align to the bar line —
there is no key signature at this point, right?  IMHO, the correct
behaviour would be that 'T-note' is still aligned to the note.

What am I missing?  Or is this a bug?

Re: hel-arabic.ly

[Werner LEMBERG]

> I'm not insulting anyone.

It is not up to you to decide that.

> These are facts.

It is always possible to argue without using foul language.

> Of course if you modify certain scheme files and remove the parts
> that concern hel-arabic, it may not work.  I challenge you, my
> initial version which did not depend at all on Lilypond worked very
> well without modifying anything.  Initial hel-arabic which does not
> depend on lilypond allows you to write any Western or Arabic music,
> after which I modified it so that it integrates perfectly with
> lilypond.  hel-arabic.ly initially could be called directly, by
> putting it in the folder containing the ly file to compile.

This is not integration at all.  What you describe is an *add-on*
file, without any integration.  If you insist on that we can easily
remove `hel-arabic.ly` from LilyPond.

> I had proven at the time to James that hel-arabic.ly could be used
> without modifying anything, he had wanted the integration of this
> hel-arabic file and I was forced to modify certain scheme files to
> that the integration goes well

You were 'forced'?  I doubt that.  You could always have said 'no, I
don't want that'.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> Before offering hel-arabic.ly, I tested it for 4 years, it worked
> with all versions of lilypond.

*Here* is the fundamental error you make: `hel-arabic.ly` is *NOT* a
file that works stand-alone with all LilyPond versions!  All LilyPond
files that are part of version X.Y.Z are bound to this version.  The
official interface is

```
\include "hel-arabic.ly"
```

and you get the expected result in combination with `convert-ly`.  How
the stuff is actually implemented is not of any concern for a user.
In other words, you have to make sure that you don't have a private
`hel-arabic.ly` file somewhere that might interfere.

If you can demonstrate that an input file doesn't work correctly with
the code in the merge request, we are going to fix this.  Up to now,
however, I only see faulty tests on your side, insults, and unfounded
accusations.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

 
> Initially hel-arabic.ly is autonomous,

It no longer is, as mentioned again and again.

> [...] I will not propose it, given your lack of intellectual honesty

Others have replied to that, and I agree with them.  Your only concern
seems to be 'my file, my file', not thinking at all how to actually
*integrate* it into LilyPond.  I added backward compatibility, because
this was a real problem.  I repeatedly demonstrated to you (including
in private mail) how everything works smoothly, while you maintained
that there are problems, which is *not correct* – as you admitted by
yourself, your testing procedures were faulty.

I see that there is a severe language barrier, making it apparently
difficult for you to communicate properly in English.  However, given
that today automatic translation engines like 'Google Translate'
provide excellent results in most cases – especially for Arabic, since
this was the very first language supported by this service –, this is
no longer an excuse.

Maybe it's really better if you don't submit new code if such
communication is the result.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> \include "hel-arabic.ly"
> \version "2.23.3"
> \relative {
>   \key c \rast
>   c' d edb f | g a bdb c | eb a g f | edb  d c
>   }

You must have done something wrong; I've just downloaded the 2.24.3
binary bundle for GNU/Linux, and this code compiles fine – this means
that it works for previous versions, too.

The changes to `hel-arabic.ly` happened in version 2.25.2; earlier
versions are *not* affected.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> I did some tests on version 2.24.3,   2.21.0-1 ,  2.23.6-1
>
> it doesn't work either.

What *exactly* did you do?


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> for rast.ly
> 
> \include "hel-arabic.ly"
> \version "2.25.13"
> \relative {
>   \key c \rast
>   c' d edb f | g a bdb c | eb a g f | edb  d c
>   }
> 
> Tmust give  rast.pdf , But that's not the case

Of course not.  You are using the current development version without
my fix.  Again: please have a look at

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2268

and try the code from this MR.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> > This should ensure full backward compatibility if you process your
> > old files with `convert-ly`.
>
> Which file?

Any input file that uses `hel-arabic.ly`.

Example:

```
\version "2.24.0"

\include "hel-arabic.ly"

\relative {
  \key c \rast
  c' d edb f | g a bdb c | eb a g f | edb d c
}
```

If you process this with `convert-ly`, you get

```
\version "2.25.13"

\include "hel-arabic.ly"
\language "arabic"

\relative {
  \key c \rast
  c' d edb f | g a bdb c | eb a g f | edb d c
}
```

and this output compiles fine with the patch from

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2268

applied.  Please look at this MR and comment.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> \include "hel_arabic.ly"

It's `hel-arabic.ly`, not `hel_arabic.ly`.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

>> [...] Indeed edb and sdb are no longer recognized
> 
> It's not screwed up at all, however, current LilyPond is not
> backward compatible.  I'm already working on a patch.

Please check

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2268

This should ensure full backward compatibility if you process your old
files with `convert-ly`.


Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> In fact it no longer works, I gave the operational version of
> hel-arabic.ly and by trying to make hel-arabic.ly dependent on
> arabic.ly without consulting me, you screwed up the hel-arabic.ly
> file. I can still repair the damage if you give me the opportunity
> to do that.  Indeed edb and sdb are no longer recognized

It's not screwed up at all, however, current LilyPond is not backward
compatible.  I'm already working on a patch.


 Werner

Re: hel-arabic.ly

[Werner LEMBERG]

> Initially this file is sufficient in itself to write all Arabic
> music.

To avoid code duplication, this has been changed more than a year ago.

  
https://gitlab.com/lilypond/lilypond/-/commit/a11634b21b4ca3d8bdc627980fc7e1cf1b819e31

> I note with regret and bitterness that hel-arabic.ly was truncated.
> for example the makam rast, an important maqam of Arabic music, was
> removed hel-arabic.ly does not depend in any way on arabic.ly.

Well, `hel-arabic.ly` *does* now depend on `arabic.ly`.  Why is that a
problem?  Please elaborate.


Werner

Re: clang compiler warnings

[Werner LEMBERG]

> inline constexpr auto VPOS = vsize (-1);

This is now part of

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2267


 Werner

Re: gs 10.04 will break doc builds again

[Werner LEMBERG]

> It seems that the Ghostscript generated PDF is broken
> regardless of LilyPond or extractpdfmark.
> 
> I tested Ghostscript GIT PRERELEASE at
> commit 99b48f1992844e30ab4b05dbb2764ba99f7b66f4
> Date:   Mon Feb 19 08:33:23 2024 +
> .
> Here's results.
> 
> ```
> $ cat test.ps
> /NimbusSans-Regular findfont 14 scalefont setfont
> 50 100 moveto
> (Hello World) show
> 
> $ ./gs -q -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=test.pdf test.ps
> 
> $ qpdf --check test.pdf
> checking test.pdf
> PDF Version: 1.7
> File is not encrypted
> WARNING: test.pdf: object 6/0: error reading object: integer out of range 
> converting 889058230272 from a 8-byte signed type to a 4-byte signed type
> WARNING: test.pdf (object 9 0, offset 100): stream dictionary lacks /Length 
> key
> WARNING: test.pdf (object 9 0, offset 146): attempting to recover stream 
> length
> WARNING: test.pdf (object 9 0, offset 146): recovered stream length: 82
> File is not linearized
> qpdf: operation succeeded with warnings
> 
> $
> ```

Interesting.  I cannot reproduce this failure: if I compile current
ghostpdl 'master' (commit b809058c5ea0cc5689d8b7c15f191a440c9bb426),
everything works fine; your example PS file compiles correctly, and
'qdf --check' (built from current git) passes, too.  I'm on a
GNU/Linux box in case this matters.


Werner

gs 10.04 will break doc builds again

[Werner LEMBERG]

`gs` compiled from the current 'master' branch of the 'ghostpdl'
repository makes a doc build fail if 'extractpdfmark' gets used: In
the created `notation.pdf`, Emmentaler fonts are missing in all
included snippets.

The problem seems to be commit

```
commit 99b48f1992844e30ab4b05dbb2764ba99f7b66f4
Author: Ken Sharp 
Date:   Mon Feb 19 08:33:23 2024 +

pdfwrite - correct EmbedAllFonts=false and alter font embedding

Bug #707578 "-dEmbedAllFonts=false not behave correct after ghostscript 
version 9.55"

The bug title is incorrect. The actual bug is that 9.55 was considering
whether a CIDFont was 'symbolic' for the purposes of embedding, when
EmbedAllFonts=false. This is incorrect, CIDFonts shouldn't be treated
as 'symbolic' at all.

For complicated reasons to do with 'nearest_encoding_index', the PDF
interpreter was correctly not embedding the CIDFonts, but the test in
'font_is_symbolic' was incorrect, so we address that here.

The reason the reporter thinks it should be the other way round was due
to the fact that their test file had all CIDFonts embedded, and all the
Fonts not embedded. After running through pdfwrite this led to a PDF
file where all the fonts are embedded, but the Fonts are substittued.
By setting EMbedAllFonts=false with 9.55 they got the Fonts not embedded
and the CIDFonts embedded, which was what they wanted.

Previously (the old PostScript-based PDF itnerpreter) we couldn't
determine whether a font was embedded in the input, so we couldn't
achieve that. However, now that we have a PDF interpreter which doesn't
rely on PostScript for it's font handling we can.

So the remainder of this commit builds on the embedded detection added
to the PDF interpreter by Chris in the last couple of commits. We now
add the FONT_INFO_EMBEDDED flag to the font_info() call in the
pdf_font_embed_status() function. If EmbedAllFonts is true, the
embedding status is known (PDF interpreter *only*) and the font was
NOT embedded in the input, then we don't embed it in the output. This is
a change in behaviour, previously we would embed a substitute.

Other interpreters should not see a change in behaviour.
```

Sigh.  Masamichi-san, please have a look!


Werner

Re: clang compiler warnings

[Werner LEMBERG]

>> OK, but don't repeat the type.
>>
>>  inline constexpr auto VPOS = vsize (-1);
>>
> 
> Well. To that, yes and no. I read it better in the original way,
> [...]

I'm on Dan's side here: Using 'auto' tells me that the right-hand
side's type is exactly the one on the left-hand side, and I can stop
thinking about it immediately.


Werner

Re: clang compiler warnings

[Werner LEMBERG]

> However, I can't reproduce it, what compiler flags are you using?

According to the MacPorts log file it is the clang compiler that comes
with XCode 15.0.1 on MaOS 14.2.1.  Looking at

  https://gist.github.com/yamaya/2924292

this corresponds to

  Apple clang version 15.0.0 (clang-1500.0.40.1)

The used compiler flags are

```
CXXFLAGS='-pipe -Os -stdlib=libc++ \
  -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk \
  -arch arm64'
```

> I'm using -Wall and clang is quiet about this use case [...]
>
> Apple clang version 15.0.0 (clang-1500.1.0.2.5)

Interesting.  Maybe this warning annoyed too much people so that it
got removed in the more recent clang version you are using.

> Since vsize is just a typedef of size_t, would it make sense to use
> SIZE_MAX when defined VPOS instead of a manual cast of negative one?

This sounds sensible to me, since `size_t` is always unsigned...


Werner

clang compiler warnings

[Werner LEMBERG]

Looking at some MacPorts log files from Mac OS 14.2.1 (which uses the
system's `clang` compiler) I see

```
flower/include/flower-proto.hh:26:30:
  warning: implicit conversion changes signedness:
   'int' to 'const vsize' (aka 'const unsigned long')
   [-Wsign-conversion]
inline constexpr vsize VPOS (-1);
     ^~
```

for almost all C++ fies, making the log file quite noisy.  Dan, any
idea how to fix this gracefully?


Werner

Re: snippets HTML page broken in devel version?

[Werner LEMBERG]

> Please compare
>
>   https://lilypond.org/doc/v2.24/Documentation/snippets/fretted-strings
>
> with
>
>   https://lilypond.org/doc/v2.25/Documentation/snippets/fretted-strings
>
> All examples are missing in the the 2.25 version.  Is this expected?
>
> It seems to me this is a bug in texinfo that have been (partially?)
> fixed in version 7.1; at least I get the attached if I access
>
>   file:///.../out-www/offline-root/Documentation/snippets/fretted-strings.html
>
> (which isn't exactly what lilypond.org shows).


This is now

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


 Werner

Re: unwanted randomness while generating LilyPond output

[Werner LEMBERG]

Hello Michael,


sorry for the late reply.

> I would like to help debugging the problem. Which exact invocation
> do I have to use to replicate the EPS files you sent?

This is due to using `extractpdfmark`, which makes the build add the
options

```
-dfont-ps-resdir=$(top-build-dir)/out-fonts -O TeX-GS
```

However,...

> If I do `lilypond --eps input.ly` I get a much bigger EPS file, that
> seemingly has the fonts attached as binary data.

... it doesn't matter for the problem at hand: you also get the
differences with normal `lilypond --eps` calls.


Werner

Re: Error with make doc

[Werner LEMBERG]

Folks,


Carl wrote to me privately:

> OK, so now I have a failure:
>
> I did
>
> ```
> rm -rf build
> mkdir build
> cd build
> ../autogen.sh --currdir
> ../configure &> configure.log
> make -j10 CPU_COUNT=10 all
> make doc LANGS="en" VERBOSE=1 CPU_COUNT=10 -j10 &> make.doc.log
> ```
> And the make doc failed.

[This is based on the branch 'dev/wl/build-fixes'.]

The log file `snippet-names-c5b165525229969dd268a5b19f9f64fd.log`
contains

```
GNU LilyPond 2.25.14 (running Guile 3.0)

Forking into jobs:  (39647 39646 39645 39644 39643 39642 39641 39640 39639 
39638)
job 9 terminated with signal: 6
job 8 terminated with signal: 6
job 7 terminated with signal: 6
job 6 terminated with signal: 6
job 5 terminated with signal: 6
job 4 terminated with signal: 6
job 3 terminated with signal: 6
job 2 terminated with signal: 6
job 1 terminated with signal: 6
job 0 terminated with signal: 6
fatal error: Children (9 8 7 6 5 4 3 2 1 0) exited with errors.
```

AFAIK, signal 6 is 'SIGABRT'.

Note that the files `lilypond-multi-run-*.log` all contain

  thread_suspend failed

which seems to be a hint that we have a problem with thread support on
macOS (Carl runs on macOS Sonoma which identifies itself as Darwin
23.2 on arm64e).

Any idea how to tackle this?  BTW, `make doc` without `CPU_COUNT=10`
succeeds on his computer.


Werner

Re: Error with make doc

[Werner LEMBERG]

> I can confirm that I get the proper HTML pages, compiling with -j10
> on both make bytecode and make doc.

Great!

> It was delightful to see the proper lilypond website on my local
> file system!  Thank you so much for fixing this!

Glad that I could help.  I will now polish the MR as requested by
Jonas.

>> The last step – I hope – will be to find out why `CPU_COUNT` fails...
>>
> 
> I will see if I can make CPU_COUNT fail.  If not, I guess the build
> system is good on MacOS!

The actual question is whether it works at all, i.e., whether setting
`CPU_COUNT=10` makes your system really compile multiple `.ly` files
in parallel.  Given that I've seen

  thread_suspend failed

in your log files I suspect that LilyPOnd simply switches to serial
processing instead.  If you don't get a timing difference (which means
that my assumption is correct) I will prepare something more specific
for further tests.


Werner

Re: Error with make doc

[Werner LEMBERG]

>> systems like macOS that neither have or use '/bin/bash'.
> 
> Apple changed the default shell for new users to zsh about 5 years
> ago, but bash is still there.  I don't oppose making the build
> scripts more portable, but let's not misunderstand the situation.

OK, thanks – let's see whether the new code makes a build succeed on
Carl's computer; otherwise I have to continue my investigations.

Note that on OpenBSD, `bash` resides in `/usr/local/bin` if you
install it via `pkg_add`.


Werner

Re: Error with make doc

[Werner LEMBERG]

>> If I click on the Notation link from that page, I get to:
>>
>> out-www/offline-root/Documentation/web/notation.html
>>
>> which has no css, but has lots of links.
>
> This shouldn't happen, and it means that your documentation build is
> still not correct.

Continuing with the analysis of Carl's build tarball it seems that the
script `build-doc-tree.sh` doesn't work as expected.  I've now
converted it to a normal shell script (i.e., it no longer uses syntax
specific to bash), which should hopefully increase its portability to
systems like macOS that neither have or use '/bin/bash'.

Carl, please do another run of the following commands based on the
updated 'dev/wl/build-fixes' branch, then create and upload a tarball
of your `build` directory as before and send me a link to it.

```
./configure
make bytecode -j10 LANGS="en"
make doc LANGS="en"
```

Regarding the failing `make doc -j10`:

> > "/Users/carl/Development/lilypond/build/out/lybook-db/
> > snippet-names-c5b165525229969dd268a5b19f9f64fd.ly"' returned
> > non-zero exit status 1.
>
> Please try to find out which of the snippet files mentioned in the
> above file failed.  `*.log` files should be in directory
> `out/lybook-db`, too, and the error message should be near the end
> of one of the log files.
>
> I would need both the contents of the failing snippet file and the
> corresponding error message.

I still need this, BTW.


Werner

Re: Error with make doc

[Werner LEMBERG]

> If I click on the Notation link from that page, I get to:
> 
> out-www/offline-root/Documentation/web/notation.html
> 
> which has no css, but has lots of links.

This shouldn't happen, and it means that your documentation build is
still not correct.

> I'm happy to send a tar file of my offline-root directory and
> subdirectories if that would be helpful.

Yes, something like that would help.  However, I would like to see
your *complete* (successful) build of the `bytecode` and `doc` make
targets, with `LANGS="en"` to reduce space.  If you don't mind, please
issue the following command one level above your build directory:

  gtar cJvf build.tar.xz build

where `gtar` is GNU tar (from the 'gnutar' MacPorts package), also
assuming that your build directory is called `build`.  Upload the
created file `build.tar.xz` to a filesharing hoster of your choice and
send me the link privately so that I can download the file for further
inspection.  For me, this archive has about 206MByte.

[The `J` command makes GNU tar use the `xz` program for compression,
 which is much more efficient than the default `gz` (at the cost of
 compression speed), and which you probably have to install from
 MacPorts, too.]


Werner

Re: Error with make doc

[Werner LEMBERG]

> "/Users/carl/Development/lilypond/build/out/lybook-db/
> snippet-names-c5b165525229969dd268a5b19f9f64fd.ly"' returned
> non-zero exit status 1.

Please try to find out which of the snippet files mentioned in the
above file failed.  `*.log` files should be in directory
`out/lybook-db`, too, and the error message should be near the end of
one of the log files.

I would need both the contents of the failing snippet file and the
corresponding error message.


Werner

Re: Error with make doc

[Werner LEMBERG]

>> > I omitted the '-l' option in the cp calls in the patch.
>> >
>> > 'make doc' succeeded without any errors, so I thought I had success.  But
>> > it turns out that
>> >
>> > a) I appear not to have the .css files copied (at least the output
>> >showed no css -- just basic white screen), and
>> > b) I appear not to have the image files copied (there are no images
>> >that show up in any of the pages accessible from
>> >www-out/offline-root).

As it turned out, this is another incompatibility: `cp -a` doesn't
work on macOS.

Please test

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2254

It should fix all the build problems you've reported.


Werner

Re: Error with make doc

[Werner LEMBERG]

[Carl sent me the file listing off-list, thanks!  I will analyze it in
due course.]

> [...] and make test with a single job (to avoid race conditions that
> have given me trouble in the past):

Interesting.  When is the 'past'?  This shouldn't happen today, and it
would be great if you could try a `-jXX' make option in the future so
that we can see if you really get a failure.

> now on to your requested steps:

Ah, my steps were not intended to be used additionally but instead :-)

> Everything completed without error.

This is good.

Regarding the `cp -l` issue: Irrespective of the faulty implementation
on macOS it turns out that option `-l` isn't portable at all, as I was
told by the autoconf people.  I'm going to replace it with something
else that also works across file system boundaries (which even a
working `cp -l` does not).


Werner

Re: Error with make doc

[Werner LEMBERG]

>> Please read this and check whether you are affected by this
>> problem.  In case you can confirm the issue please try whether it
>> works if you omit the `-l` option in all `cp` calls in my patch.
>
> I checked -- the results of the problem were different for me than
> for the bug report.  I got the error message, but the hard link was
> never copied (there were not two files with the same inode -- only
> the original file.

OK, so there is indeed a problem with `cp -l` on your macOS.  It's
still hard to believe.

BTW, which macOS version are you using?

> I omitted the '-l' option in the cp calls in the patch.
>
> 'make doc' succeeded without any errors, so I thought I had success.  But
> it turns out that
>
> a) I appear not to have the .css files copied (at least the output
>showed no css -- just basic white screen), and
> b) I appear not to have the image files copied (there are no images
>that show up in any of the pages accessible from
>www-out/offline-root).

It seems that my patch doesn't work as expected, or that I have missed
something.  As usual, please start from scratch and run the standard
incantation (or your adapted variation of it)

```
./configure
make bytecode -j12
make doc -j12 CPU_COUNT=12 LANGS="en"
```

(please tell me what git commit you are using so that I can try
exactly the same setup).  After finishing, please call

```
find . | gzip > find.log.gz
```

in your build directory and send me the file *privately* for further
inspection (it's about 750kByte compressed – listing approx. 16
files) and of no real interest to other readers of this list).

> Does it make sense to try again with the xargs part of the patch,
> but using the GNU cp and find?

For you personally, it certainly makes sense so that you get a
successful build.  For the LilyPond project, however, I think it's
best to use native OS tools so that the number of additional
requisites stays as small as possible.


Werner

Re: Error with make doc

[Werner LEMBERG]

> 'make doc' failed.
> 
> It appears that under some conditions, we end up with a path
> including '//'.

Multiple slashes in succession are completely harmless; they are
simply equivalent to `/`.

Doing a bit of an internet search it seems this is a bug in the `cp`
implementation on macOS (as unbelievable it may be, given that `cp` is
such a fundamental command that exists since decades):

  
https://apple.stackexchange.com/questions/464706/why-do-i-get-bad-file-descriptor-when-copying-using-hardlink-flag

Please read this and check whether you are affected by this problem.
In case you can confirm the issue please try whether it works if you
omit the `-l` option in all `cp` calls in my patch.


Werner

Re: Error with make doc

[Werner LEMBERG]

> I've attached three compressed log files.  [...]

Thanks a lot, very helpful.  Please apply the attached patch to the
top-level `GNUmakefile.in` file, then retry from scratch (including
the `configure` step); it should catch all of the three problems
you've encountered.

The `-maxdepth` and `-mindepth` options of `find` are not completely
portable according to the 'autoconf' info pages; however, we are using
them in `aclocal.m4` since ages and nobody complained, so...


Werner
diff --git a/GNUmakefile.in b/GNUmakefile.in
index 6c0e1f287d..b28130e779 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -153,7 +153,7 @@ $(outdir)/%-root/index.html: doc-build
 	mkdir -p $(dir $@)/Documentation/
 	for d in . musicxml abc2ly lilypond-book ; do \
 		mkdir -p $(dir $@)/input/regression/$${d}; \
-		cp --link -a input/regression/$${d}/out-www/*  $(dir $@)/input/regression/$${d}/ ; \
+		cp -l -a input/regression/$${d}/out-www/*  $(dir $@)/input/regression/$${d}/ ; \
 	done
 	find $(dir $@)/input/regression/ \
 		-type f \
@@ -164,18 +164,23 @@ $(outdir)/%-root/index.html: doc-build
 		-not -name '*.mxl' \
 		-not -name 'collated-files.pdf' \
 		-delete
-	cp --link -a Documentation/out-www/webdoc/* $(dir $@)/Documentation/
-	cp --link $(TOPDOC_TXT_FILES) $(dir $@)
+	cp -l -a Documentation/out-www/webdoc/* $(dir $@)/Documentation/
+	cp -l $(TOPDOC_TXT_FILES) $(dir $@)
 	# No link because the files come from the source directory.
 	cp $(addprefix $(src-dir)/,$(README_FILES)) $(dir $@)
 	$(PYTHON) $(buildscript-dir)/www_post.py $(PACKAGE_NAME) $(TOPLEVEL_VERSION) $(dir $@) "$*"
 	find $(outdir)/$*-root -type l | xargs rm -f
-	cd $(outdir)/$*-root && find -name \*.html -execdir $(buildscript-dir)/fix-docsize.sh {} +
-	$(PERL) -i -pe 's#(href)="\.\./Documentation/#\1="#g' $(dir $@)/Documentation/*html
-	$(PERL) -i -pe 's#(href)="\.\./\.\./Documentation/#\1="../#g' $(dir $@)/Documentation/*/*html
-	# Fixup links to CSS files.
-	$(PERL) -i -pe 's#(href)="css/#\1="../../Documentation/css/#g' $(dir $@)/input/regression/*html
-	$(PERL) -i -pe 's#(href)="css/#\1="../../../Documentation/css/#g' $(dir $@)/input/regression/*/*html
+	cd $(outdir)/$*-root \
+	  && find . -name "*.html" -execdir $(buildscript-dir)/fix-docsize.sh {} +
+	find $(dir $@)/Documentation -maxdepth 1 -name "*html" \
+	  | xargs $(PERL) -i -pe 's#(href)="\.\./Documentation/#\1="#g'
+	find $(dir $@)/Documentation -mindepth 2 -maxdepth 2 -name "*html" \
+	  | xargs $(PERL) -i -pe 's#(href)="\.\./\.\./Documentation/#\1="../#g'
+	# Fix up links to CSS files.
+	find $(dir $@)/input/regression -maxdepth 1 -name "*html" \
+	  | xargs $(PERL) -i -pe 's#(href)="css/#\1="../../Documentation/css/#g'
+	find $(dir $@)/input/regression -mindepth 2 -maxdepth 2 -name "*html" \
+	  | xargs $(PERL) -i -pe 's#(href)="css/#\1="../../../Documentation/css/#g'
 
 doc-build: top-doc
 	$(MAKE) out=www -C Documentation/ doc

Re: Error with texi2pdf on MacOS

[Werner LEMBERG]

> The problem was actually not that MacTeX did not support XeTeX, but
> that the MacPorts texlive-xxx did not included texlive-xetex (so
> there was no xetex in my texlive path; the xetex that was found was
> the MacTex xetex).

OK.  This was a very specific problem with your setup and does not
happen in the normal case, I think.


Werner

Re: Error with make doc

[Werner LEMBERG]

> I already had to install (via homebrew) gnu coreutils and gnu
> findutils, since the MacOS 'cp' and 'find' commands don't work the
> same as the respective GNU commands.

Please give more details.  What problems did you experience with `cp`
and `find`?  Did this happen during a call to `make ...` for LilyPond?
This should work out of the box, which essentially means that we have
to either add tests to `configure` to catch the problematic tools, or
to rewrite the commands in the makefile or scripts to avoid issues
with GNU-style usage of those tools, for example.

> I then get to a problem with perl: [...]

Interesting.  I wasn't aware that we ever call `perl` with a long list
of arguments during `make doc`.

Please repeat this with saying

```
make doc VERBOSE=1 &> make.doc.log
```

so that we can more information in the log file.  Usually, such errors
can easily be circumvented by using `xargs`.


Werner

Re: Error with texi2pdf on MacOS

[Werner LEMBERG]

>> Does compilation of this small plain TeX test document
>>
>> ```
>> \font\lh = latt1095
>> \lh ^^c1
>> \bye
>> ```
>>
>> with `xetex` actually work?
> 
> Since this short file didn't run,

Well, this explains what's going on. 

> I will run the test file.  But since you suggested this problem, I
> decided to check xetex and xdvipdfmx:
> 
> carl@carls-mbp-2 build % which xetex
> 
> /Library/TeX/texbin/xetex
> 
> carl@carls-mbp-2 build % which xdvipdfmx
> 
> /opt/local/bin/xdvipdfmx

Ouch.  You have two TeX installations in your path: MacTeX (either
installed directly or via homebrew) and 'texlive-xxx' packages from
MacPorts, and the former is apparently missing XeTeX support (for
whatever reason) since the `xdvipdfmx` binary is missing.  You have to
decide which one to use.  Given that you are mostly relying on
MacPorts it's probably simpler to use MacPorts binaries.

If you don't want delete the non-MacPorts TeX installation you should
separate it.  The simplest solution is probably to remove the symbolic
link `/Library/TeX/texbin` completely (the actual MacTeX tree is
`/usr/local/texlive/` for homebrew, too) or to remove
`/Library/TeX/texbin` from your PATH environment variable.  This makes
your MacPort's 'texlive' package the default.

[Note that I'm not a real Mac user, so please take my words with
caution – I'm mostly relying on internet information.]

> I thought it might be a good idea to just run the KPATHSEA_DEBUG on
> the test file.

Thanks, but right now this is not necessary because the problem is
obvious.

> I've attached the compressed log file from your short TeX file run
> through xetex.

Note that the attached archive is broken (and it doesn't use any
compression).  What about simply using `gzip` to compress single files
in the future?  Alternatives are `xz`, `bzip2`, or similar programs.


Werner

Re: Error with texi2pdf on MacOS

[Werner LEMBERG]

>> Please also check whether the two TFM files from the LH fonts are
>> actually valid (for example, by testing with `tftopl `).
> 
> I tested this and got no errors.  [...]

OK, thanks.  AFAICS, the `xetex` binary finds file `latt1095.tfm` but
`xdvipdfmx` (which convert's `xetex`'s output to PDF) does not.

Does compilation of this small plain TeX test document

```
\font\lh = latt1095
\lh ^^c1
\bye
```

with `xetex` actually work?

Please start again from scratch, run

```
KPATHSEA_DEBUG=44 make doc ...
```

and send the file `Documentation/out-www/en/notation.texi2pdf.log`
(compressed, since this file will be huge).


Werner

Re: Auto-resetting of context properties

[Werner LEMBERG]

> So: Wouldn't it be more consistent to turn those context properties
> that (to the user) create "one-time only effects" into persistent
> ones (so forceClef = ##t _would_ actually create a clef at each
> timestep forward) and instead create dedicated user interfaces using
> music functions, like
> 
> forceClef  = \once \set forceClef = ##t
> 
> etc.? In a similar vein, wouldn't
> 
> stanzaNumber = \set stanza = \etc (plus some extra features like
> auto-adding dots when given an integer)
> 
> be more consistent than forcing the users to remember that (and
> understand why) stanza numbers have to be created by \set'ting a
> context property?

Sounds sensible, but I can't answer whether this can be easily be
implemented.  David?


Werner

Re: Error with make doc

[Werner LEMBERG]

>> Aah, this looks like a bug in `typography-demo.ly`.  Please try the
>> following line in `typography-demo.ly` instead of the three
>> original font lines.
>>
>> ```
>> property-defaults.fonts.serif = "Linux Libertine O, Noto Serif CJK JP, Noto 
>> Serif JP, serif"
>> ```
>
> I can confirm that this change allows 'make test' to complete
> successfully.

Thanks for testing.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2244


 Werner

Re: Error with make doc

[Werner LEMBERG]

>> I installed Noto Serif JP, and added it to the fontcofig cache.
>> That got me through the previous file error.  But then I got
>> stopped on another Japanese font (I suppose this might be a Linux
>> Libertine font, but my fc-list command shows that I have them
>> installed):

Interesting.  This shouldn't happen.  The idea is that the set of
fonts used for building the documentation is closed and well-defined.
'Noto Serif JP' is intended to cover all CJK testing stuff in
LilyPond.

> I was able to successfully complete 'make test' by commenting out the
> following lines in  input/regression/typography-demo.ly:
> 
>   % Font settings for Cyrillic and Hebrew
>   % Linux Libertine fonts contain Cyrillic and Hebrew glyphs.
>   %property-defaults.fonts.serif = "Linux Libertine O,serif"
>   %property-defaults.fonts.sans = "Linux Biolinum O,sans-serif"
>   %property-defaults.fonts.typewriter = "Linux Libertine Mono O,monospace"

Aah, this looks like a bug in `typography-demo.ly`.  Please try the
following line in `typography-demo.ly` instead of the three original
font lines.

```
property-defaults.fonts.serif = "Linux Libertine O, Noto Serif CJK JP, Noto 
Serif JP, serif"
```


Werner

Re: Error with texi2pdf on MacOS

[Werner LEMBERG]

> xdvipdfmx:fatal: Unable to find TFM file "latt1095".

This shouldn't happen at all.  In file `Documentation/GNUmakefile`,
before running the compilation of the documentation files, there is
the target 'pre-pdf' that explicitly generates the necessary TFM
files for the Cyrillic LH fonts before generating any PDF output.

Hopefully, your problem is repeatable.  If it is, please start from
scratch and do something like

```
make doc -j12 CPU_COUNT=12 LANGS="en" VERBOSE=1 &> make.doc.log
```

and post the `make.doc.log` file (compressed) so that we get as much
information as possible.  Please also check whether the two TFM files
from the LH fonts are actually valid (for example, by testing with
`tftopl `).

And please also post the complete `notation.texi2pdf.log` file
(compressed, too) if you get the problem again.

The issue with `make doc` called another time seems to be incompletely
generated files caused by the first run.

Another minor issue: In your e-mails, if you paste log files into the
message, there is always an empty line between every text line, which
makes them hard to read.  Probably a line ending issue (i.e., mixing
LF and CR and/or combinations of it).  Can you fix that?


Werner

Re: Error with make doc

[Werner LEMBERG]

> carl@Carls-MBP-2 lilypond % tidy --version
> 
> HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build 6141

This explains the failure, thanks: Your `tidy` version doesn't support
HTML 5.  I've submitted an MR to catch this.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2241

> I didn't see tidy listed as a prerequisite.

It is not a prerequisite; it is simply used if available, as an
additional aid to the developers.  As it turns out, the naive test for
checking the presence of the binary is not sufficient; we must also
check for a proper version.

Please be reminded that up to now *nobody* worked on building the
(complete) documentation on the Mac!  You are effectively entering new
territory (for which I'm very thankful), and there are dragons, as
you've already found out.


Werner

Re: Error with make doc

[Werner LEMBERG]

>> Can someone remind me why the build system sets the C locale in the
>> first place?
> 
> Answering my own question: I guess it is because we can't assume the
> system has an en_US.UTF-8 locale or a C.UTF-8 locale?

Exactly.  Some time ago (see
https://lists.gnu.org/archive/html/lilypond-devel/2022-11/msg00247.html
and the following mails in the thread) I worked on fixing exactly that
(see attached old patch), but I stopped since we could then – at least
partially – circumvent the related problems.

I also stopped working on a `local-c-utf8.m4` file (also attached) to
recognize the 'C.UTF-8' and/or 'en_US.UTF-8' locales, which turned out
to be a really hard problem.

> Maybe we ought to set only LC_MESSAGES to C? It should prevent
> overriding the system locale for file names but still make logs
> output in English.

Honestly, I don't know.  The whole locale stuff is such a mess.


 Werner

From 231f5c2fba0fccf333fc7873da771fc8493b71e2 Mon Sep 17 00:00:00 2001
From: Werner Lemberg 
Date: Mon, 7 Nov 2022 09:38:17 +0100
Subject: [PATCH 1/2] generic-vars.make: Fix locale for build process
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* In non-English indices of the PDF documentation, this fixes the initials
  for entries starting with a non-ASCII character.  This is a generic
  problem with the `texindex` awk script (used by the Texinfo infrastructure
  to sort indices).

https://lists.gnu.org/archive/html/bug-texinfo/2022-11/msg8.html

* Some non-ASCII characters are now correctly displayed in info, PDF, and
  HTML output files (example: `rotated 45?` → `rotated 45°` in the
  documentation of the `\rotate` markup).

Also update documentation accordingly.
---
 Documentation/en/contributor/lsr-work.itexi | 15 -
 Documentation/en/usage/running.itely|  2 +-
 Documentation/es/usage/running.itely|  3 ++-
 Documentation/fr/usage/running.itely|  2 +-
 Documentation/it/usage/running.itely|  2 +-
 Documentation/ja/usage/running.itely|  2 +-
 make/generic-vars.make  | 25 ++---
 python/book_latex.py|  2 +-
 python/book_texinfo.py  |  2 +-
 9 files changed, 39 insertions(+), 16 deletions(-)

diff --git a/Documentation/en/contributor/lsr-work.itexi b/Documentation/en/contributor/lsr-work.itexi
index b03ebf8122..c69d8ca485 100644
--- a/Documentation/en/contributor/lsr-work.itexi
+++ b/Documentation/en/contributor/lsr-work.itexi
@@ -445,12 +445,15 @@ updating the binary running the LSR.
 
 @item
 Download the latest snippet tarball from
-@uref{https://lsr.di.unimi.it/download/} and extract it.
-The relevant files can be found in the @file{all} subdirectory.
-Make sure your shell is using an English language version, for
-example @code{LANG=en_US}, then run @command{convert-ly} on all
-the files.  Use the command-line option @code{--to=version} to
-ensure the snippets are updated to the correct stable version.
+@uref{https://lsr.di.unimi.it/download/} and extract it; the
+relevant files can be found in the @file{all} subdirectory.
+
+Now run @code{LANG=C.UTF-8 convert-ly} on all the files.  The
+@code{LANG=C.UTF-8} part sets the @code{LANG} environment variable
+to a locale with UTF-8 encoding and disabled translations while
+@command{convert-ly} gets executed.  Also use the command-line
+option @code{--to=@var{version}} to ensure the snippets are
+updated to the correct stable version.
 
 @item
 Make sure that you are using @command{convert-ly} from the latest
diff --git a/Documentation/en/usage/running.itely b/Documentation/en/usage/running.itely
index a24c7ac392..029d1ae446 100644
--- a/Documentation/en/usage/running.itely
+++ b/Documentation/en/usage/running.itely
@@ -925,7 +925,7 @@ overrides the value derived from the location of the
 @item LANG
 The language for LilyPond data sent to @code{stdout} and
 @code{stderr}, for example progress reports, warning messages, or
-debug output.  Example: @code{LANG=de}.
+debug output.  Example: @samp{LANG=de_DE.UTF-8}.
 
 @item LILYPOND_LOGLEVEL
 The default loglevel.  If LilyPond is called without an explicit
diff --git a/Documentation/es/usage/running.itely b/Documentation/es/usage/running.itely
index 7f2629cd7d..7c722c50af 100644
--- a/Documentation/es/usage/running.itely
+++ b/Documentation/es/usage/running.itely
@@ -977,7 +977,8 @@ ubicación del binario @command{lilypond}.
 @item LANG
 Idioma de los datos de LilyPond enviados a @code{stdout} y a
 @code{stderr}, por ejemplo informes del avance, mensajes de
-advertencia o salida de depuración.  Ejemplo: @code{LANG=es}.
+advertencia o salida de depuración.  Ejemplo:
+@samp{LANG=es_ES.UTF-8}.
 
 @item LILYPOND_LOGLEVEL
 Nivel de registro predeterminado.  Si LilyPond se llama sin ningún
diff --git a/Documentation/fr/usage/running.itely b/Documentation/fr/usage/running.itely
index 5295ab0638..752ace6a2a 10064

Re: Error with make doc

[Werner LEMBERG]

>> > In procedure open-file: No such file or directory:
>> > "/System/Library/Fonts/??? W4.ttc" [...]
>> >
>> > SO it looks to me like there's a problem with not getting UTF characters
>> > into the proper file name in the Scheme procedure.  Any ideas for what to
>> > do next?
>>
>> What does `fc-list` report?  Do you see correct file names?
>> (`fc-list` should come with the FontConfig library).
>
> Shows the fonts with the appropriate kana/kanji names:
>
> carl@carls-mbp-2 Fonts % fc-list | grep W4
>
> /System/Library/Fonts/ヒラギノ丸ゴ ProN W4.ttc: Hiragino Maru Gothic ProN,
> [...]

OK, thanks.  This means that there is apparently a macOS-specific
problem with either Guile or LilyPond.  For testing purposes I renamed
one of my local fonts to something containing Katakana, and my
self-compiled LilyPond binary could load this font without any glitch.

Jean, Jonas, any idea how to proceed?


Werner

Re: Error with make doc

[Werner LEMBERG]

> In procedure open-file: No such file or directory:
> "/System/Library/Fonts/??? W4.ttc"
>
> I checked out the /System/Library/Fonts directory, and found these fonts
> listed:
>
> ヒラギノ角ゴシック W3.ttc
>
> ヒラギノ角ゴシック W4.ttc
>
> SO it looks to me like there's a problem with not getting UTF characters
> into the proper file name in the Scheme procedure.  Any ideas for what to
> do next?

What does `fc-list` report?  Do you see correct file names?
(`fc-list` should come with the FontConfig library).


Werner

Re: Error with make doc

[Werner LEMBERG]

>> You have to check the log files in `lybook-db` to find the problematic
>> `.ly` file(s).  Does `make test` succeed?  You should actually try that
>> before running `make doc`...
>>
> 
> Interesting -- the CG has make doc show up before make test.  But I
> appreciate the suggestion, so I decided to restart
> 
> So I did a make clean, and then a make test.

I've never seen the errors you are reporting – as Dan writes, it may
be an issue with the `tidy` program.  However, I'm using version 5.4.0
on my GNU/Linux box while MacPorts offers the more recent version
5.8.0; maybe there is indeed a problem in the created HTML code that
wasn't detected or handled by tidy in earlier versions.

Another possibility is that macOS comes with an ancient `tidy` version
that doesn't understand HTML 5 stuff like ``, and you don't
have installed `tidy` via MacPorts at all.  In this case we have to
update the `output-distance` script to check the `tidy` version before
actually using it...


Werner

Re: Adjusting `\f`

[Werner LEMBERG]

>> "f" = #(make-music 'AbsoluteDynamicEvent
>>    'text "f"
>>    'tweaks '(((DynamicLineSpanner . horizon-padding) . 0.1)))
>> 
>> { \stemDown f'4\f f'4\p }
> 
> 
> This isn't going to work well anyway. Try it on
> 
> { \stemDown f'1\p\< \break f'2\f r2 }
> 
> There is only one DynamicLineSpanner per sequence of consecutive
> dynamics.  A tweak on \f will only affect it if the \f if the first
> element of that sequence.

Yeah, this came to my mind, too.  Thanks for confirmation.

> You probably want to change the glyph metadata, or make
> horizon-padding have an effect on DynamicText as well, or something
> in that vein.

Yep.


Werner

Re: Error with make doc

[Werner LEMBERG]

> "/Users/carl/Development/lilypond/build/out/lybook-db/
> snippet-names-ece0c512da6daf7d9aff45809ce97556.ly"' returned non-zero exit
> status 1.

You have to check the log files in `lybook-db` to find the problematic
`.ly` file(s).  Does `make test` succeed?  You should actually try that
before running `make doc`...

BTW, if you execute `make test`, you are greeted with the following
advice:

```
To begin investigating regression-test crashes, try this:

grep -L systems.texi out/lybook-testdb/*/*log | sed s/log/ly/g | xargs grep 
-H sourcefilename

Matching lines may provide original test source file names.
The .ly files in which they appear are preprocessed test input.
The corresponding .log files may have errors or warnings.

If the above is not helpful, try sifting through this:

find out/lybook-testdb -name "*.log" | xargs grep -H "\(error\|warning\)"
```

which can also be used for finding problems with `make doc` (but you
have to replace `lybook-testdb` with `lybook-db` in the above
commands).


Werner

Re: Adjusting `\f`

[Werner LEMBERG]

> I would like to change the definition of `\f` to something like this
>
> ```tex
> "f" = #(make-music 'AbsoluteDynamicEvent
>'text "f"
>'tweaks '(((DynamicLineSpanner . horizon-padding) . 0.1)))
>
> { \stemDown f'4\f f'4\p }
> ```
>
> to handle issue #4159.
>
> However, if I do the above the `horizon-padding` property can no
> longer be overridden with `\tweak` or `\override`.  How can I fix
> that?  In other words, I would like to set the `horizon-padding`
> property for `\f` as if I provided a default value for the
> `DynamicLineSpanner` grob in `define-grobs.scm`.

After some more thinking I couldn't find a solution to this problem.
Any ideas?

I thought about adding a new event property parallel to `tweaks`, say,
`defaults`, that works exactly in the same way but only sets a given
grob property if `tweaks` doesn't contain it.  I could then say

```
"f" = #(make-music 'AbsoluteDynamicEvent
   'text "f"
   'defaults '(((DynamicLineSpanner . horizon-padding) . 0.1)))

{ \stemDown \tweak DynamicLineSpanner.horizon-padding 0 f'4\f f'4\p }
```

successfully, but calling `\once\override
DynamicLineSpanner.horizon-padding = 0` would still not work.

I could further restrict `defaults` so that it would only be used if a
property is not set at all, neither in `define-grobs.scm`, nor via
`tweaks` or `\override`.  I'm not sure, however, whether this makes
sense in the long run, i.e., whether this is just an ad-hoc solution
to this particular problem, or whether there are more situations that
would benefit from such a feature.


Werner

Adjusting `\f`

[Werner LEMBERG]

I would like to change the definition of `\f` to something like this

```tex
"f" = #(make-music 'AbsoluteDynamicEvent
   'text "f"
   'tweaks '(((DynamicLineSpanner . horizon-padding) . 0.1)))

{ \stemDown f'4\f f'4\p }
```

to handle issue #4159.

However, if I do the above the `horizon-padding` property can no
longer be overridden with `\tweak` or `\override`.  How can I fix
that?  In other words, I would like to set the `horizon-padding`
property for `\f` as if I provided a default value for the
`DynamicLineSpanner` grob in `define-grobs.scm`.


Werner

Re: how to assign a Scheme procedure to an SCM variable?

[Werner LEMBERG]

> You can't -- scm_boolean_p is a C function, not a Guile function.
> (It's sort of like trying to access a chocolate as a chocolate box.)
> What you can do is to import boolean? from Guile using
> lily-imports.cc.

That worked, thanks!


Werner

how to assign a Scheme procedure to an SCM variable?

[Werner LEMBERG]

Folks,


I ask for help with a Guile question.

Naively, I tried

```
SCM proc = scm_boolean_p;
```

However, this bombs out with

```
error: cannot convert 'scm_unused_struct* (*)(SCM)'
   {aka 'scm_unused_struct* (*)(scm_unused_struct*)'}
   to 'SCM' {aka 'scm_unused_struct*'}
```

What is the correct way to assign a built-in procedure like `boolean?`
(i.e., `scm_boolean_p`) to a variable of type `SCM`?


Werner

Re: numbers

[Werner LEMBERG]

>> Well, both `#+3` and `#-3` work, so it might be tempting to assume
>> that `+3` and `-3` also work (outside of `\markup`).
> 
> So does ##e+3.0 and so does #3/1 so should we be supporting those as
> well?

The former?  Rather not.  The latter, maybe.  I can imagine that
people would like to say

```
\magnifyStaff 2/3
```

However, given that this representation no longer looks like a 'normal
number' for most people, I think it is fully sufficient to use the
already working

```
\magnifyStaff #2/3
```

instead.


Werner

Re: numbers

[Werner LEMBERG]

>> Can you imagine any other use for `+` right before numbers?
>> Otherwise I suggest to make it work, to provide the least surprise
>> for users.
> 
> Do we say anywhere that `+` is a sign in LilyPond syntax?  Where
> does the surprise come from?

Well, both `#+3` and `#-3` work, so it might be tempting to assume
that `+3` and `-3` also work (outside of `\markup`).


Werner

Re: numbers

[Werner LEMBERG]

>> This works:
>>
>> ```
>> { \ottava -1 c }
>> ```
>>
>> while this fails:
>>
>> ```
>> { \ottava +1 c'' }
>> ```
>>
>> Is there a technical reason for it?
>
> As far as LilyPond is concerned, `+` is not a part of numbers.  Is
> there a compelling argument for wasting syntactic elements on doing
> nothing?

I think that 'wasting' is too harsh a statement.  In comparison to
other syntactical elements (together with the interpretation of Scheme
code), a change to support `+` has no significant impact, AFAICS.

Can you imagine any other use for `+` right before numbers?  Otherwise
I suggest to make it work, to provide the least surprise for users.


Werner

numbers

[Werner LEMBERG]

This works:

```
{ \ottava -1 c }
```

while this fails:

```
{ \ottava +1 c'' }
```

Is there a technical reason for it?


Werner

Re: clefs, time signatures, and key signatures

[Werner LEMBERG]

>>> please have a look at Merge Request 2188 and comment there on how
>>> to proceed with the new distances between clefs and time
>>> signatures, together with the new distances between clefs and key
>>> signatures.
>>> 
>>>   https://gitlab.com/lilypond/lilypond/-/merge_requests/2188
>>> 
>>> The question is whether the new distances should be based on the
>>> widest standard clef glyph (which is the alto clef, and which is
>>> done currently in the MR), or whether they should be based on the
>>> most common one, the treble clef.
> 
> A few people responded, and the opinions are exactly 50:50.  It
> would be great if more people could chime in!

Thanks for all who commented.  There was a slight preference for a
wider setting.  For this reason I now suggest a compromise as a final
resolution, namely to make the bass clef invariant, which in turn
minimizes the differences of the other main clefs (treble and alto);
see attached image.  Doing so, the probably most used scores with a
violin and a bass clef (e.g., for piano music) stay unaffected.

If there aren't any serious complaints, I'm going to commit this.


Werner

Re: Can't automatically merge

[Werner LEMBERG]

> (In cases like these, please cc me directly; then the email will
> land in my inbox and I may react faster...)

OK, thanks.

> I disabled Dan's and Karlin's runner.  Can you please restart it and
> then ping me so I can re-enable? If possible, maybe also update the
> runner version...

The first merge request finished automatically; I've started the
second one (!2195) right now.


 Werner

Re: Can't automatically merge

[Werner LEMBERG]

>>> Looks like it was fixed?
>>> https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7
>> 
>> Yep, thanks.
> 
> I spoke too early – it's still not working properly.

On this page I read:

  For self-hosted runners, the previous workaround may need to be
  re-applied as we have updated GitLab.com certificate.  Please see
  possible workarounds in
  gitlab.com/gitlab-com/gl-infra/production/-/issues/17265

Jonas?


Werner

Re: Can't automatically merge

[Werner LEMBERG]

>> Looks like it was fixed?
>> https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7
> 
> Yep, thanks.

I spoke too early – it's still not working properly.


Werner

Re: Can't automatically merge

[Werner LEMBERG]

> Looks like it was fixed?
> https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7

Yep, thanks.


Werner

Can't automatically merge

[Werner LEMBERG]

It seems that merging is currently not working; gitlab reports

  fatal: unable to access 'https://gitlab.com/lilypond/lilypond.git/':
SSL certificate problem: self-signed certificate in certificate
chain

Do we have to do something?


Werner

Re: `set-global-staff-size` fails within `\book`

[Werner LEMBERG]

> IMHO the documentation is wrong. Everything's in the name.
> set-global-staff-size sets the *global* staff size. Per-\book is not
> global.

Thanks to all who answered.  I've submitted an MR to improve the
documentation.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2200


Werner

Re: `set-global-staff-size` fails within `\book`

[Werner LEMBERG]

>> Consider this snippet.
>> 
>> ```
>> \book {
>>   #(set-global-staff-size 20)
>>   { c' }
>> }
>> 
>> \book {
>>   #(set-global-staff-size 10)
>>   { c' }
>> }
>> ```

I played a bit more with this, and I've found that
`set-global-staff-size` affects the *next* book block, which is, well,
unexpected.

```
\book {
  \markup "30"
  #(set-global-staff-size 30)
  { c' }
}

\book {
  \markup "10"
  #(set-global-staff-size 10)
  { c' }
}

\book {
  \markup "10"
  #(set-global-staff-size 10)
  { c' }
}
```


Werner

Re: `set-global-staff-size` fails within `\book`

[Werner LEMBERG]

Six weeks ago I asked the following, without getting a response:

> Consider this snippet.
> 
> ```
> \book {
>   #(set-global-staff-size 20)
>   { c' }
> }
> 
> \book {
>   #(set-global-staff-size 10)
>   { c' }
> }
> ```
> 
> Section 'Setting the staff size' in the NR says
> 
>   To set the staff size globally for all scores in a file (or in a
>   \book block, to be precise), use set-global-staff-size [...]
> 
> This implies that `set-global-staff-size` is restricted to `\book`
> if used within.
> 
> However, the above example fails: In both created PDF files, the
> staff size is 20pt, which means that the second call to
> `set-global-staff-size` does nothing.
> 
> What is wrong?  The documentation or LilyPond's behaviour?

Any takers who has some insight?


Werner

Re: clefs, time signatures, and key signatures

[Werner LEMBERG]

> I think that the distances between the clef and the sigs are improved

Thanks, but which variant do you prefer?  The first image or the second
image in

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2188

?

Werner

Re: clefs, time signatures, and key signatures

[Werner LEMBERG]

> I’ve just looked at the images and especially w/r to the Alto clef I
> strongly prefer the new spacing.  For the others there are spots
> where I’m not sure it is too tight but overall the new spacing
> appears to be more balanced.
> 
> I thus think the new spacing is better overall.

Thanks, but I would like to know whether you prefer the top
(alto-based) or bottom (treble-based) image on

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2188


Werner

Re: clefs, time signatures, and key signatures

[Werner LEMBERG]

>> please have a look at Merge Request 2188 and comment there on how
>> to proceed with the new distances between clefs and time
>> signatures, together with the new distances between clefs and key
>> signatures.
>> 
>>   https://gitlab.com/lilypond/lilypond/-/merge_requests/2188
>> 
>> The question is whether the new distances should be based on the
>> widest standard clef glyph (which is the alto clef, and which is
>> done currently in the MR), or whether they should be based on the
>> most common one, the treble clef.
> 
> For better comparison, I've updated/added the screenshots in the MR
> so that you can do a blink-comparison of the images.

A few people responded, and the opinions are exactly 50:50.  It would
be great if more people could chime in!


Werner

Re: clefs, time signatures, and key signatures

[Werner LEMBERG]

> please have a look at Merge Request 2188 and comment there on how to
> proceed with the new distances between clefs and time signatures,
> together with the new distances between clefs and key signatures.
> 
>   https://gitlab.com/lilypond/lilypond/-/merge_requests/2188
> 
> The question is whether the new distances should be based on the
> widest standard clef glyph (which is the alto clef, and which is
> done currently in the MR), or whether they should be based on the
> most common one, the treble clef.

For better comparison, I've updated/added the screenshots in the MR so
that you can do a blink-comparison of the images.


Werner

Re: [RFC] Transition to Guile 3.0

[Werner LEMBERG]

>> then remove automatic detection of Guile 2.2 from configure.
> 
> I did not yet upload a merge request to make Guile 3.0 the default
> for all builds: After more thought, I believe it's better to do this
> together with the removal of automatic configure support for Guile
> 2.2, to avoid the situation where we assume that Guile 3.0 is the
> default, but building from source will gracefully configure with
> Guile 2.2, for example because the system is missing the development
> package for Guile 3.0...

+1


Werner

clefs, time signatures, and key signatures

[Werner LEMBERG]

Folks,


please have a look at Merge Request 2188 and comment there on how to
proceed with the new distances between clefs and time signatures,
together with the new distances between clefs and key signatures.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/2188

The question is whether the new distances should be based on the
widest standard clef glyph (which is the alto clef, and which is done
currently in the MR), or whether they should be based on the most
common one, the treble clef.


Werner

Re: Make `Beam.positions = #beam::slope-like-broken-parts` the default?

[Werner LEMBERG]

>> The positioning of broken beams becomes so much better IMHO if
>> `Beam.positions = #beam::slope-like-broken-parts` gets used (of
>> course this is undocumented...)
>>
>> Have a look at the images from the regtest
>> `beam-broken-classic.ly`.  Is there any reason to not make this the
>> default?
>
> I think I would prefer this as the default.

Well, I think the reason is issue #3415, which I've just discovered...

I guess it's a minor fix (taking care of a border case not covered in
the regtest), but it has to be done.


Werner

Make `Beam.positions = #beam::slope-like-broken-parts` the default?

[Werner LEMBERG]

The positioning of broken beams becomes so much better IMHO if
`Beam.positions = #beam::slope-like-broken-parts` gets used (of course
this is undocumented...)

Have a look at the images from the regtest `beam-broken-classic.ly`.
Is there any reason to not make this the default?


Werner

Re: Plan for LilyPond 2.24.3 and Transition to Guile 3.0

[Werner LEMBERG]

>> Step 1: Officially support Guile 3.0 and add optional CI testing I
>> opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162
>> to add some compatibility with earlier versions of Guile 3.0 and
>> then implement detection support in configure. It also creates
>> Docker images and adds optional CI testing, as we had it for the
>> transition to Guile 2.2.
> 
> The MR is nominally on countdown right now, do we have a consensus
> on this?

+1 from me.

> Please ping me on other fixes that you think should be part of 2.24.3,

Perhaps !2093, !2105, !2137 (if of relevance), and !2152.


Werner

Re: [RFC] Transition to Guile 3.0

[Werner LEMBERG]

>> Please let me know of your comments!
> 
> I'm very happy that you got Guile 3.0 working on Windows. Kudos for
> that (and I guess we need to send big thanks to Mike Gran too).

+1

> What I don't really understand is why you want to add compatibility
> with Guile 3.0.x for small x.  [...]

I think what Jonas does is the right way – support for Guile 3 in
general to accommodate with as many distributions as possible.


Werner

`set-global-staff-size` fails within `\book`

[Werner LEMBERG]

Consider this snippet.

```
\book {
  #(set-global-staff-size 20)
  { c' }
}

\book {
  #(set-global-staff-size 10)
  { c' }
}
```

Section 'Setting the staff size' in the NR says

  To set the staff size globally for all scores in a file (or in a
  \book block, to be precise), use set-global-staff-size [...]

This implies that `set-global-staff-size` is restricted to `\book` if
used within.

However, the above example fails: In both created PDF files, the staff
size is 20pt, which means that the second call to
`set-global-staff-size` does nothing.

What is wrong?  The documentation or LilyPond's behaviour?


Werner

Re: Multiple clefs in one Staff

[Werner LEMBERG]

>> Having this functionality is certainly useful for Piano music.
>> However, it's quite rare, and an LSR snippet should be sufficient
>> (possibly integrated into LilyPond's documentation).
> 
> I see that you have shown an example that repeats the clef for every
> measure.  If that's the convention, the approach in my code is not
> likely helpful.

I think there is not a universal convention whether the small bass
clef gets repeated or not.  It probably depends on the situation.

> Correction: it is easy to make it do that.

Excellent, thanks!


Werner

Re: Multiple clefs in one Staff

[Werner LEMBERG]

> Inspired by
> 
> 
> Should we be offering something like that?

What exactly do you mean with 'offering'?

Having this functionality is certainly useful for Piano music.
However, it's quite rare, and an LSR snippet should be sufficient
(possibly integrated into LilyPond's documentation).


Werner

Re: bizarre behaviour of `output-filename`

[Werner LEMBERG]

>> Some debugging shows it seems to be the latter: All top-level
>> definitions are available as paper variables within a book's paper
>> block, together with all paper variables of the top-level paper
>> block:
>> 
>> Is this really intentional?
> 
> https://gitlab.com/lilypond/lilypond/-/issues/5917
> https://codereview.appspot.com/567450043

Really?  I would never have expected that this quite innocent-looking
patch makes top-level definitions (outside of any block) available as
paper variables within `\book`.  The comment in `book.cc` only talks
about `\header` blocks.  How does this influence stuff outside of
`\header`?  And how does it influence `\paper`?

In case this patch is really the cause, can the behaviour be
restricted to `\header` blocks as announced in the commit message?


Werner

Scheme: Using brackets in addition to parentheses

[Werner LEMBERG]

As I've just discovered, brackets work the same as parentheses in
Scheme expressions:

```
#[set-global-staff-size 26]

{ c' }
```

Guile allows this by default; the read option `square-brackets` is
active for compatibility with R6RS.

Shall we use and advertise this?  Some user Scheme code could probably
be made more readable:

```
(let [(foo ...)
  (bar ...)]
  ...)

(cond
  [question1 expression1]   
  [question2 expression2]   
  [question3 expression3]   
  [else  expression4])
```


Werner

Re: bizarre behaviour of `output-filename`

[Werner LEMBERG]

> I consider it bizarre that the top-level variable `output-filename`
> is only considered in a `\book` block where the paper variable
> `output-suffix` is also set, contrary to `output-suffix`.  Why is
> `output-filename` considered at all?  Where in the code is this
> read?  AFAIK, top-level variables are read with `ly:parser-lookup`,
> and I can't find this for `output-filename`.
>
> Or is this an inheritance thing?  Does a `\book` block inherit all
> top-level expressions and convert them to paper variables?

Some debugging shows it seems to be the latter: All top-level
definitions are available as paper variables within a book's paper
block, together with all paper variables of the top-level paper block:
Executing

```
foo = "FOO"

\paper {
  bar = "BAR"
}

\book {
  #(ly:message "paper variable 'foo': ~a\n"
(paper-variable $current-book 'foo))
  #(ly:message "paper variable 'bar': ~a\n"
(paper-variable $current-book 'bar))
  { c' }
}
```

yields

```
paper variable 'foo': FOO
paper variable 'bar': BAR
```

Is this really intentional?


Werner

bizarre behaviour of `output-filename`

[Werner LEMBERG]

Consider this input file called `c.ly`:

```
output-filename = "foo"
output-suffix = "bar"

\book {
  \paper {
output-suffix = "baz"
  }
  { c' }
}

\book {
  { c' }
}

\book {
  { c' }
}
```

The created output files are

  foo-baz.pdf
  c-bar.pdf
  c-bar-1.pdf

I consider it bizarre that the top-level variable `output-filename` is
only considered in a `\book` block where the paper variable
`output-suffix` is also set, contrary to `output-suffix`.  Why is
`output-filename` considered at all?  Where in the code is this read?
AFAIK, top-level variables are read with `ly:parser-lookup`, and I
can't find this for `output-filename`.

Or is this an inheritance thing?  Does a `\book` block inherit all
top-level expressions and convert them to paper variables?


Werner

horizontal vs. vertical padding

[Werner LEMBERG]

I try to provide a patch for issue #2185.  The given solution simply
reduces `Fingering.padding` from 0.5 to 0.3.  However, this affects
both horizontal and vertical padding, which is not what I want.  I
only want to change the horizontal padding, but it seems that we don't
have a property for that.  How could this be achieved with the
existing machinery?  Otherwise, would it be sensible to introduce new
properties `padding-x` and `padding-y` that get considered if
`padding` is not set?


Werner

Re: Windows locale support

[Werner LEMBERG]

> Le dimanche 15 octobre 2023 à 18:39 +0000, Werner LEMBERG a écrit :
>
>> does localization of, say, `lilypond --help` work on Windows?  I've
>> tested LilyPond 2.25.9 within `cmd.exe` of a US version of
>> Windows 10 (i.e., the standard language and region setup is for the
>> USA), and I can't make it output anything else but US English.  It
>> doesn't react to setting any of the `LANGUAGE`, `LANG`, or
>> `LC_MESSAGES` environment variables.
>> 
>> Looking into the source code I don't see that we are disabling
>> gettext support on Windows.  What am I missing?
> 
> I don't believe Windows uses these environment variables to specify
> locales.

Well, I read nothing in the documentation of 'gettext' that those
variables are ignored on Windows.

Bruno, can you comment and/or have a look, please?  A Windows package
of LilyPond (which can be installed in any directory) is available at

  https://lilypond.org/development.html

> Have you tried changing the language of the whole system?

No, I didn't, and I don't want to.  I'm just following the
instructions in the Usage Manual

  https://lilypond.org/doc/v2.25/Documentation/usage/environment-variables

to check whether they are valid for Windows, too.


Werner

Windows locale support

[Werner LEMBERG]

Folks,


does localization of, say, `lilypond --help` work on Windows?  I've
tested LilyPond 2.25.9 within `cmd.exe` of a US version of Windows 10
(i.e., the standard language and region setup is for the USA), and I
can't make it output anything else but US English.  It doesn't react
to setting any of the `LANGUAGE`, `LANG`, or `LC_MESSAGES` environment
variables.

Looking into the source code I don't see that we are disabling gettext
support on Windows.  What am I missing?


Werner

Re: How some "Joe Users" perceive LilyPond installation

[Werner LEMBERG]

> Below is the copy of a discussion on the LilyPond Facebook group
> that I found interesting.  Just food for thought.  [...]

Thanks, Jean.  I was almost tempted to answer on Facebook some hours
ago, but I refrained because my answer would not have being useful in
any way :-) Let's just conclude that there is going to be one more
happy Dorico user.

What you have already implemented in Frescobaldi, i.e., an
auto-installer for LilyPond, is the way to go, I believe.  BTW, can
you estimate a release date of Frescobaldi that has this new feature?


Werner

unnecessary line in `define-context-properties.scm`?

[Werner LEMBERG]

I wonder whether line 35 in file `define-context-properties.scm` is
necessary.  AFAICS, the `map` call in functions
`all-user-translation-properties` and
`all-internal-translation-properties`, together with the following

```
(define-public all-translation-properties
  (append all-user-translation-properties
  all-internal-translation-properties))
```

completely construct `all-translation-properties`.  Why the additional
`set!`?


Werner