>> > [dev@lilydev:lilypond-git]$ git fsck
>> > Segmentation faultrectories: 45% (116/256)
>>
>> Ouch. I've never experienced such a thing with git. Maybe
>> something is broken with your installation? Does removing and
>> installing again help?
>
> Do you mean removing git itself? I'd like to
>> 0deb785f64 Update texinfo.tex from Texinfo git master branch
>
> not sure about this one...
IMHO this should be skipped. Instead, right before the 2.20 release,
the newest `texinfo.tex` from texinfo's git master branch should be
used.
>> 804faebc79 Issue 5481/1: main.cc, relocate.cc: Minor
> Below is the console output. Any ideas?
Clone the repository anew, and everything should be fine again.
It seems that git has been upgraded on Savannah; a comparison between
the old and the new clone shows a lot of differences in the `.git'
directory...
Maybe they forgot to set a compatibil
Most developers expect that you can easily adjust C++ compiler flags
in a GNU package using CXXFLAGS. With LilyPond, however, this is
quite problematic. Reason is that it internally uses the following
variables to compute the final list of compiler flags (see files
`c++-vars.make` and `aclocal.
>> This is very, very non-standard and completely undocumented.
>
> Not completely undocumented. The CG has said to run configure with
> --disable-optimising for as long as I can remember.
I don't mean this option but the fact that CXXFLAGS as set by the user
gets almost completely overwritten
Folks,
the music engraving conference in Salzburg (January 17.-19.) aims to
present as much note engraving programs as possible. While some
companies send representatives (e.g., Dorico, Capella, Finale) – some
even with talks – we don't have something similar for LilyPond in the
main part of th
> I notice, upwards in the log, that
>
> Invoking "t1asm feta11.pt1 feta11.pfb"...
> mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find
> another way to convert feta11.pt1 to feta11.pfb
>
>
> despite I've t1utils-1.41-1.fc31.x86_64 installed.
Can you execute t1asm?
t1as
> which t1asm
> /usr/bin/t1asm
>
> so I don't see any reason why, just at once, it failed at running…
> after a good sleeping night!
Strange indeed. Can you temporarily replace `mf2pt1` with a script
that calls `strace`? Something like
strace mf2pt1 ... &> ~/mf2pt1.strace.log
You could the
>> Strange indeed. Can you temporarily replace `mf2pt1` with a script
>> that calls `strace`? Something like
>>strace mf2pt1 ... &> ~/mf2pt1.strace.log
>> You could then investigate in more detail which files `mf2pt1` tries
>> to open and/or execute.
>>
>
> [jcharles@pc1 mf]$ strace mf2pt
>> Please try again with
>>strace -ff -o ~/mf2pt1.strace mf2pt1 feta11.mf
>> so that we can see the strace messages from `t1asm` also. Note that
>> you will get at least two files called `mf2pt1.strace.X`, where
>> `X` is a process ID.
>>
>
> Four log-files were created, and the 3
> New:
>
> 5633 musicxml: Replace new module by type() builtin - Jonas Hahnfeld
> https://sourceforge.net/p/testlilyissues/issues/5633
> http://codereview.appspot.com/555070043
>
> 5632 Replace string exceptions by RuntimeError - Jonas Hahnfeld
> https://sourceforge.net/p/testlilyissues/is
>> Is there a specific reason that issue #5621 is not on this list?
>
> If there exists a patchset on Rietveld, neither is it linked to on
> Sourceforge nor is 5621 set to Patch:new.
Oops. Silly me. Here it is now.
https://codereview.appspot.com/553290043
Werner
> Thanks for your answer, I managed to install Lilypond from macports,
> it works like a charm. We could include a note in the
> website/documentation about this workaround, what do you think?
Could you provide a patch to either the .html page or the
corresponding .texi file? (The latter might
>>Sure! IIUC, I need to upload the patch to the code review tool and
>>update the issue tracker? If so, could you (or someone else) give
>>my account yassinec write access to the issue tracker? Otherwise I
>>can send the patch by email
Both is OK.
> I've added yassinec to the issue tracker wi
>> 2. ./configure found mpost but it's complaining about missing
>>metapost CTAN package. Should I be worried about this error?
Yes, you should be worried if you are building lilypond. It means
that the `mpost` binary could be found, but not its basic input files
like `mfplain.mp`.
>>Ca
Hello Han-Wen,
> I'll be at the Salzburg music engraving event.
now registered :-)
> I was wondering if there is anything regarding LilyPond that you
> want my input on.
Being at the conference for the discussions and talks on Sunday is
already a big bonus. I'm sure there will be a lot of q
This looks interesting!
https://lgtm.com/projects/g/lilypond/lilypond
Werner
> `configure` should warn or bail on incompatible flex versions. I
> suggest we add a version check in configure.ac to ensure that flex
> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
> actually works).
What you suggest wouldn't work as expected. There is no guarantee
that
[Sorry for this off-topic message, but it's really urgent...]
Hello Kieren,
did you receive my recent e-mail messages that I sent to
?
Werner
>> There is no guarantee that `FlexLexer.h` found during compilation
>> is the one that is used by a recent flex version. Unfortunately,
>> `FlexLexer.h` doesn't contain any version information, so it is
>> really impossible to protect against this situation automatically.
>
> Akim Demaille made
> There is one lingering problem: when LilyPond calls Guile, Guile is
> not finding the library files specified in load-extension
> expressions, even though they *should* be in the right place.
> Before I go too crazy searching, does anyone know what controls this
> path choice? I'm assuming it
>> It seems you have to set LDTL_LIBRARY_PATH.
Typo! I mean LTDL_LIBRARY_PATH/
> I saw that, of course, but I’m not sure what that variable even is.
> In particular, I have no reason to believe that it affects Guile’s
> load path...but I’ll try it and see.
It's documented in the guile manual,
> 11:15 Frescobaldi
> 15:30 openLilyLib
> 16:00 edition-engraver
Program changed accordingly; I now use »Vormittag« and »Nachmittag« as
block names.
Werner
> I assume that many of the talks and discussions would be interesting
> for lots of developers who cannot come. Is there a possibility to
> document the unconference day, f.e. by recording video and
> distributing it (if not public then protected by password that only
> users asking for it get
> While that may be true, there are already GNU projects using GitHub
> as their host, for example gnucash and gnuradio.
Gnucash uses github as a mirror only, see
https://wiki.gnucash.org/wiki/Git#code.gnucash.org
But gnuradio admittedly uses github. I'm 100% sure that if RMS knew
that he w
I'm going to call
git push --mirror g...@github.com:lilypond/lilypond.git
to update the github mirror. However, this will cause the following
changes:
To github.com:lilypond/lilypond.git
- [deleted] refs/changes/31/482031/1
- [deleted] refs/changes/31/482031/m
It's January. This means we should run
make grand-replace
David K, do you have objections, especially w.r.t. cherry-picking?
Werner
> So go wild.
Thanks. Copyright years are now updated in staging.
Werner
>> To github.com:lilypond/lilypond.git
>> - [deleted] stable/2.18
>> * [new branch]origin/stable/0.0 -> origin/stable/0.0
>
> It looks like you are trying to push a normal clone of the savannah
> repo, where as you should be pushing from something that was cloned
> as
>
>Send an email (must be less than 64 KB) to
> briefly explaining your work, with the
> patch files attached. Translators should send patches to
> . After your patches are reviewed, the
> developers may push one or more of them to the main repository or
> discuss them with you.
Han-Wen has
>> Han-Wen has recently pushed a bunch of changes directly to
>> Rietveld, most of them quite uncontroversial. I assume that this
>> is as good as an e-mail :-)
>>
>> I thus suggest that after his patches have been reviewed,
>
> How are they going to get reviewed when there is nothing pointing
> Trivial things from a developer with push access can be just pushed.
> Complex or otherwise contential things warrant a chance for
> developers to take a look at it. "Half a chance" seems an
> unnecessary complication.
Anyway, I was misled. Han-Wen actually *did* create proper SF issues,
whi
>> At any rate: we haven't had a protocol for patches not going
>> through the regular process. Maybe we should use the
>> Signed-off-by: convention for such patches, including the original
>> submitter and the LGTM votes? It's probably mostly psychological,
>> but it suggests a bit of accounta
> Almost exactly a year ago, there was a sizable "Please test gub"
> effort initiated by Knut Petersen.
By the way: Any idea what has happened with Knut? He doesn't respond
even to private e-mails since a few months...
Werner
> A problem with the policy "trivial things can just be pushed" is
> that "trivial" is open for interpretation.
Of course, but this shouldn't be a hindrance.
> Even a change that was intended to affect only comments could have a
> bad impact if, say, it inserts an accidental stray character and
> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
>
> https://codereview.appspot.com/579240043/
Thanks for taking care of Han-Wen's patches. My back is still not OK;
I must avoid sitting too much in front of the computer currently...
Before adding it to the bug tracker I want to check this group's
knowledge whether there is a reason that French beams are longer than
normal:
\relative c'' {
r16 f d f
\override Stem.french-beaming = ##t
r16 f d f
}
Looking into scores from French publishers this behaviour seems
> What is "french beaming" supposed to do/be?
No stems within the beam.
Werner
> The minimum length of the stem of the middle note is forcing the
> beams down.
Sounds sensible. Can you provide a patch to fix that? The minimum
stem length for french beams must be handled identically to the
non-french case.
Werner
> I'm going to call
>
> git push --mirror g...@github.com:lilypond/lilypond.git
>
> to update the github mirror. However, this will cause the following
> changes:
I've now done a push, and it seems to have worked correctly. Please
check.
Werner
> I put up a .clang-format code that mostly mimicks our style at
>
> https://codereview.appspot.com/561340043
>
> I have a lot of good experience with automating code formatting. It
> removes drudgery for code authors, obviates discussions over style
> in code review, and generally elevates
> * statically linked binaries of clang-format are available here:
> https://github.com/angular/clang-format/tree/master/bin ;
Aaah! This is very nice, thanks.
> 1. Recognize clang-format as a "good enough", so I can use it
> locally on my diffs and not get reviews on style.
I did a quick vie
[Being on the return from Hawaii I'm late with everything, so please
don't be surprised if I answer to stuff that has already been
discussed to death.]
> The preamble and intent is one thing; adding a corrective committee
> with the authority to enact punishments based on anonymous reports
> i
David,
> [...] the principal impact to be expected on LilyPond development
> appears to have an official body entitled to censure my behavior and
> eventually, out of a sense of duty, remove me.
I won't definitely do that.
> The general stance of the GNU project on its internal lists is to
>
> I'd like to recommend that everyone argues with him [David K.], if
> you think he is wrong. Otherwise take his posts literal and _not_
> offending.
That's it.
Werner
> As said before off-list, thanks a lot for all the work you've been
> doing.
Yes. Thanks, James!
Werner
Hello Federico,
> I'm testing a translation patch and I cannot understand which
> mistake is causing the following error:
AFAIK, the problematic error message is the following:
> .../Documentation/out-www/it/it/usage/updating.texi:14: This command
> can appear only outside of any environment, n
> > On lilypond-user-fr, a user wonders about this:
> >
> > \version "2.23.6"
> >
> > {
> >\override NoteHead.style = #'petrucci
> >c'8
> >\override NoteHead.style = #'blackpetrucci
> >c'8
> > }
> >
> >
> > If you zoom on the o
> The syntax highlighting patch is back. I have pushed the latest
> version to the GitLab MR (as a reminder, this is
> https://gitlab.com/lilypond/lilypond/-/merge_requests/1019). You
> can find the new demo here:
Congrats! Overall, it looks very nice to me.
Werner
> My idea for this would be
>
> @lilypond[verbatimonly,quote]
>
> [...]
This is an excellent suggestion!
> So that is doable, but as you can see there is a fair bit of work to
> invest, especially for changing many instances of @example to
> @lilypond[verbatimonly,quote] ...
>
> $ git grep "@
> OK, putting on my list, but I still plan to do the Scheme lexer
> improvements before that (and it definitely deserves a separate
> merge request anyway).
Thanks.
> If you want to have a go in the mean time, feel free :-)
Probably not in the nearer future :-)
Werner
Given that LilyPond uses Unicode exclusively I wonder whether we
should rename
ly:wide-char->utf-8
to
ly:unicode->utf-8
or something similar. 'Wide character' is too broad a term IMHO, and
the function doesn't do any character set conversions.
Werner
>> Given that LilyPond uses Unicode exclusively I wonder whether we
>> should rename
>>
>>ly:wide-char->utf-8
>>
>> to
>>
>>ly:unicode->utf-8
>>
>> or something similar. 'Wide character' is too broad a term IMHO, and
>> the function doesn't do any character set conversions.
>
> We are m
> [...] we will be able to spell (ly:wide-char->utf-8 1234) as either
> (integer->char 1234) or (for literals which is the majority of
> cases) #\x4d2 (where 4d2 is the hex representation for the number
> that has the decimal representation 1234).
In other words, the function will become obsolet
> In the archives I read from David in 2016:
>
> “I cannot exactly blame Ian Hulin for stopping to
> contribute (and I don't actually know whether he is
> still alive).”
>
> https://lists.gnu.org/archive/html/lilypond-devel/2016-05/msg00077.html
>
> Saddeningly, Ian seems to have died aged
Folks,
Merge request
https://gitlab.com/lilypond/lilypond/-/merge_requests/1210
is now mature enough to produce LilyPond documentation with syntax B/W
highlighting of LilyPond code in PDF output.[*] You can find the
Learning Manual as an example at
https://gitlab.com/lilypond/lilypond/u
[First of all: Thanks, Jonas, for releasing 2.22.2 today!]
I guess most people like me lack the skills to give helpful comments,
so they stay silent. The only part where I can voice an opinion is
the following.
>> Meanwhile, please take a look at reality: Linux distributions are
>> switching
> I haven't worked wirh TexInfo markup before, however it occurs to me
> that lisp is regular enough that with some effort one could hope to
> scrape out a majority of the function definitions and then use such
> a database to touch up the help source?
Having a script that converts `@code` to, s
> See https://gitlab.com/hahnjo/lilypond/-/commits/guile2-bytecode Let
> me know if this is miraculously sufficient to make people happy and
> I can open a merge request.
For me, this looks very good, thanks.
Werner
>> [First of all: Thanks, Jonas, for releasing 2.22.2 today!]
>
> [Well, I didn't do this alone, Phil does most of the actual release
> procedure like editing the right files that both of us keep
> forgetting and things like that]
D'oh, sorry for that omission, Phil – many cudos to you, too!
> I believe that these pdf documents are a significant improvement. I
> love them.
Good to hear, thanks.
> I do not see the need to use the syntax highlighting in the text
> references. In fact, I think the syntax highlighting in the text
> references would get in the way.
Could you explain
[git commit e51c3e033564d84a687eea86832563197e8a9815]
In the NR section 'Footnotes in stand-alone text with automatic marks'
the following example is given.
```
\book {
\header { tagline = ##f }
\markup {
"A simple"
\footnote "tune" \italic " By me"
"is shown below. It is a"
[git commit 3cdce08c24d3cef7f242214f2b48763242a2ead6]
Please have a look at the output of
```
\new Score \with {
\consists "Balloon_engraver"
} \new Staff {
\balloonGrobText LedgerLineSpanner #'(1 . 1) "ledger line"
c'''1
\balloonGrobText LedgerLineSpanner #'(1 . -1) "ledger line"
c''
> Aren't ledger lines printed as a singular stencil for the entire
> line? If so, it would make sense that the origin of the stencil
> aligns with the staff symbol. It would also mean there is only one
> grob to attach a balloon to.
Aah, ok. I didn't know that (or skipped or forgot a correspo
Given that we have
CenteredBarNumber → CenteredBarNumberLineSpanner
DynamicTextSpanner
DynamicText
Hairpin→ DynamicLineSpanner
SostenutoPedal → SostenutoPedalLineSpanner
SustainPedal → SustainPedalLineSpanner
UnaCordaPedal → UnaCordaPedalLineSpanner
I wo
>> SostenutoPedal → SostenutoPedalLineSpanner
>> SustainPedal → SustainPedalLineSpanner
>> UnaCordaPedal → UnaCordaPedalLineSpanner
>
> Does "Spanner" add anything to "Line" in these cases, or is it like,
> "I brought down that wolf-animal with my rifle-object mere seconds
> bef
> I went and learned about Scheme. Obv the classic reference would be
> SICP (Structure and Intepretation of Computer programs) But as I was
> reading stuff I stumbled into this pdf by Prof Wilson of
> UTexas/Austin [...]
Link, please.
Werner
> %%
> % \includescore{PossibleExtension}
> %%
>
> [...]
Ouch, this is ugly LaTeX code. Besides the formatting, it will
exhaust TeX's macro stack, AFAI
> The (pdf|Xe|(dvi)?Lua)?(La)?TeX experts in the room are going to
> find this question ridiculous, but anyway: how do I use the code
> here?
>
> https://lilypond.org/doc/v2.23/Documentation/usage/sharing-the-table-of-contents.html
Here is an enhanced replacement. For simplicity I didn't conve
> It seems to me most natural the TeX would be having the last word
> (if you'll look after the lame pun there), and thereby lilypond
> should indirect somewhat its internal sense of page numbering, so
> that some negotiation can happen wrt to where things are...
>
> It seems to me this discussi
>> https://lilypond.org/doc/v2.23/Documentation/usage/sharing-the-table-of-contents.html
>
> Here is an enhanced replacement.
Here is an even more enhanced replacement that allows formatting
commands in the TOC entries, for example
```
2, section, 1, {\emph{B}}, toc97
```
Werner
> [...] I'd like to manage the releases for some time now.
+1, and thanks!
Werner
Hello Tom,
in 1998 you introduced the 'oldEE' accordion symbol to LilyPond's
Emmentaler font. Since some time we are wondering where this symbol
comes from; we weren't able to find any reference to it. Could you
please tell us where you got this from?
Werner
> I've finished mapping the last five glyph categories: Mensural,
> Neomensural, Petrucci, Solesmes, and Kievan. Of those, only the
> Mensural and Neomensural glyphs provided much trouble, but as
> always, extra pairs of eyes are encouraged to spot typos and other
> mistakes or give suggestions t
> A convert-ly rule would probably not be possible given the
> limited power of regular expressions. As such, \partial might
> need to support both duration and music arguments. Initially I
> thought this might not be possible, given that a naked duration
> can be treated as
>>> * A glyph should be created for SMuFL's clefChangeCombining
>>> character.
>>
>> Really? Why?
>
> I was following precedent. Bravura includes it, even though it's a
> zero-width empty character.
OK.
>> If this is correct, no glyph is needed at all.
This was a bit sloppy. I meant 'no ne
> Lilypond handles slanted Beams in a geometrically weird way, that
> is, the thickness is not measured as the shortest distance between
> the opposing sides of the boundary, but as vertical distance. This
> results in Beams getting optically thinner and closer the higher the
> slope is. But we
[782f5528e0, using a self-compiled, static version of Guile 2.2.7]
While working on some LilyPond Scheme code I made a typo in file
`define-markup-commands.scm`. While executing `lilypond -V` (after
`make install`) to process my `.ly` file I get the following
backtrace.
```
19 (ly:boo
> Byte-compilation, I guess. I seem to recall that Guile 2 uses
> primitive-eval to run code that is not byte-compiled, and this loses
> the location information. Generally speaking, running code without
> compilation seems to be preserved for the sake of eval but not
> well-supported at all. T
>> IMHO, this is completely useless. There is not a single hint to
>> the location of the error – why does Guile treat
>> `define-markup-commands.scm` as an 'unknown file'?
>>
>> What am I missing?
>
> That the error does not _occur_ in define-markup-commands.scm?
> define-markup-command is a ma
>> * The compilation output says, for example,
>>
>> ```
>> ;;; compiling
>> /home/wl/lilypond/out/share/lilypond/current/scm/lily/graphviz.scm
>> ;;; compiled
>> /home/wl/lilypond/out/share/lilypond/current/guile/ccache/2.2-LE-8-3.A/home/wl/lilypond/scm/graphviz.scm.go
>> ```
>>
>> T
Jean:
>>This is strange: What does '2.2-LE-8-3.A' mean? Why do I get two
>>paths concatenated? Additionally, the `.go` files are put into
>>`/home/wl/lilypond/scm/out`
>
> Because of Lilypond's functions exported from C++, which are added
> only when running Lilypond but are neede
>> Over the years, I've become extremely wary of syntactic sugar: it
>> adds an extra barrier to usage/development because everyone not
>> only has to learn Scheme, they also have to learn the (lilypond
>> specific) idioms involved.
>
> I'm curious you say that, since my experience is precisely t
> I have searched most of my accordion literature, both old and modern
> norwegian and german publications, some old sovjet accordion books
> and old american publications like the one I sent you a snapshot of
> earlier. I only find the (R) and (*) symbols in the publications
> from Alfred Music
> In that case, I propose the SMuFL name for the glyph be
> accdnClosedSwitchOld, [...]
Sounds reasonable.
Werner
With current git (commit 44f1033467a6, using Guile 2.2.7), the
formatting of optional Scheme function arguments in the IR looks
strange. For example, the signature
```
(define*-public (markup->string m #:key (layout #f) (props '()))
```
appears as
```
Function: markup->string m #:#:layout #:#
>> With current git (commit 44f1033467a6, using Guile 2.2.7), the
>> formatting of optional Scheme function arguments in the IR looks
>> strange. [...]
>
> I'll fix that later. An issue seems like the way to go for now.
Done.
https://gitlab.com/lilypond/lilypond/-/issues/6330
Werner
> \new Staff not \new "Staff"
> \override NoteHead.color not \override "NoteHead"."color"
> \repeat volta not \repeat "volta"
> \change Staff not \change "Staff"
>
> OK to drop that policy? I can easily make a patch to sed out all
> existing occurrences
>> currently I'm updating all LSR-files to work with 2.22.
>
> Btw, current state:
> I converted all lsr-snippets to 2.22., inserted those from
> Documentation/snippets/new, fixed all crashes and most warnings:
>
> No ERRORs
> Some 'programming error's for engravers-one-by-one.ly, on purpose,
>
> Well, I'm an unsophisticated Emacs user, so I'd appreciate thoughts
> from Werner or David.
Mhmm, I don't use Emacs for editing LilyPond input files, so I don't
have an opinion here.
What I can imagine is to have, say, a git repository, and the CG
containing a link to that.
Werner
>> I think it's not really used at the moment because the LilyPond
>> version is 8 years old. I at least will definitely use it more when
>> it gets updated to 2.22.
>
> It has been already updated.
This is excellent news! However,
https://lsr.di.unimi.it/LSR/html/contributing.html
still s
>> All snippets are updated.
>
> Thanks a lot, Harm!
+1. Good job!
Werner
>> Currently homebrew provides Lilypond 2.22.2 for Apple Silicon,
>> that is what I am using.
>
> Did you try running the x86_64 binaries via Apple's Rosetta tool? That
> might be a bit slower than native executables, but given that Homebrew
> builds 2.22.2 without Guile bytecode, it might actu
>> Note that the MacPorts port of LilyPond 2.22.2 already uses Guile
>> 2.2 bytecode and provides a binary for Apple Silicon, too.
>>
>> https://ports.macports.org/port/lilypond/details/
>
> No, the 2.22.2 version uses Guile 1.8 as can be easily seen from the
> dependencies. Even if it used G
können
> als ich. Willkommen bei Lilypond!
Und wenn Sie Hilfe vor Ort brauchen: Sowohl Lukas-Fabian Moser als
auch ich sind am Mozarteum tätig – und Valentin Petzel sitzt ebenfalls
in Salzurg :-)
Werner Lemberg
Folks,
Jonas and I have an intense (and very exhausting) discussion where to
add kerning data. I want to hear more opinions whether I should go
'route one' (which I prefer) or 'route two' (which Jonas prefers).
Please have a look at MR 1368
https://gitlab.com/lilypond/lilypond/-/merge_requ
> Werner instead wants all outlines in one file, all kerning info in a
> separate file, all OT features in their own file and so on.
This is not correct. I would *love* to be able to have everything in
`.mf` files if it made sense. However, it doesn't. As mentioned in
the very beginning of th
Folks,
this e-mail is cross-posted to two lists since the problems are
relevant to both LilyPond and FontConfig, and I hope that I can get
comments from both sides.
I've just had a very nasty experience with FontConfig on my GNU/Linux
box that cost me hours of checking my own changes for bugs b
>> Does lilypond want one or more of their lists to be one of the
>> initial group to move to mailman 3?
>
> Yes, I'd be in favor of doing that. Others, what do you
> think?
I support that, at least for 'lilypond-devel'.
Werner
> The PO template that is the basis for PO files needs to be updated
> at every release by notifying the coordinator of the release.
> That's a maintenance cost. Right now, we're not paying it, and the
> result is that the PO template any translators would base their work
> on is from LilyPond 2.
901 - 1000 of 3522 matches
Mail list logo
