>> 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
Le 10/02/2022 à 08:26, Werner LEMBERG a écrit :
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
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
Here is the current countdown list.
The next countdown will be February 11th.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!1180 cairo: tweak output log message & drop superfluous showpage. -
Han-Wen
Le 09/02/2022 à 20:13, Valentin Petzel a écrit :
Hello Jean,
That sounds interesting. Maybe one way to do this would be allowing nested
\contexts? For example
\layout {
\context {
\StaffGroup
\context {
\Staff
something
}}}
to specifically target contexts that are children of other context.
Am Samstag, dem 29.01.2022 um 17:18 +0100 schrieb Walter Garcia-Fontes:
> I'm following the official procedure to ask for commit access and
> join the developer team.
>
> I am a contributor to the translations. I have contributed all the
> patches for the Catalan translation, which is quite
Hello Jean,
That sounds interesting. Maybe one way to do this would be allowing nested
\contexts? For example
\layout {
\context {
\StaffGroup
\context {
\Staff
something
}}}
to specifically target contexts that are children of other context. This way it
would be possible to have
\new
Hi all,
> I have a vague dream that it could also work in
> intermediate contexts.
Nice!!
Kieren.
Le 09/02/2022 à 16:40, Valentin Petzel a écrit :
Hello Jean,
2.23 would only provide such an alias if an earlier version was specified. So a
user can only keep using ParenthesisItem when explicitely stating that he'd be
using an old version of the language.
Thus this would also not at all
Valentin Petzel writes:
> Hello,
>
> while paper blocks can be specified in books and bookparts, layout
> blocks cannot. This makes having different default layouts for
> multiple books or bookparts quite a hassle, as it requires specifying
> it for each score. Also this makes having different
> Le 09/02/2022 15:24, Kieren MacMillan a écrit :
>
>
> Hi Valentin,
>
> > Also this makes having different stylesheets for different bookparts quite
> > impossible.
> >
> > So I want to ask if there is any reason against allowing layout blocks in
> > books and bookparts, having them
Hello Jean, hello everyone,
this does sound like a good idea. But what I've been thinking about for a while
is: For many incompabilities Lilypond could very well know how to handle
things. With things like music functions or grobs changing names we could
simply have a set of includes to make
Hi Valentin,
> Also this makes having different stylesheets for different bookparts quite
> impossible.
>
> So I want to ask if there is any reason against allowing layout blocks in
> books and bookparts, having them override the default layout for that book or
> bookpart.
>
> If not, would
Hello Jean,
2.23 would only provide such an alias if an earlier version was specified. So a
user can only keep using ParenthesisItem when explicitely stating that he'd be
using an old version of the language.
Thus this would also not at all affect recent files.
The problem is that Lilypond
> Le 09/02/2022 15:15, Valentin Petzel a écrit :
>
>
> Hello Jean, hello everyone,
>
> this does sound like a good idea. But what I've been thinking about for a
> while is: For many incompabilities Lilypond could very well know how to
> handle things. With things like music functions or
Hello,
while paper blocks can be specified in books and bookparts, layout blocks
cannot. This makes having different default layouts for multiple books or
bookparts quite a hassle, as it requires specifying it for each score. Also
this makes having different stylesheets for different bookparts
Sorry for cluttering the list, but the problem is actually with the way
FontConfig 2.13.94 is packaged on NixOS. I'll report it on their Github.
Thanks for the amazing work again.
On Wed, Feb 9, 2022 at 3:59 PM Omid Mo'menzadeh
wrote:
> OK, it seems that I have found where the problem is. I
OK, it seems that I have found where the problem is. I built LilyPond
against FontConfig 2.13.1, and it works just like the official binary. But
the version built against FontConfig 2.13.94 and Guile 2.2 emits the same
warning I mentioned. There seems to be some sort of soft incompatibility
with
I can confirm that this is a packaging issue now. I patched the official
binary to see the glibc on my system, and it works without any warnings.
It's also considerably faster than my own compiled version (4.31s vs. 6.43s
on a single file).
I suppose I should go on debugging this on my own, but
Am Mittwoch, dem 09.02.2022 um 12:50 +0330 schrieb Omid Mo'menzadeh:
> It works with Guile 2.2, but with a lot of the mentioned warnings.
> The .nix files I attached describe a recipe for building LilyPond,
> and two packages are built in the shell.nix file, so yes, I am
> building both, using the
It works with Guile 2.2, but with a lot of the mentioned warnings. The .nix
files I attached describe a recipe for building LilyPond, and two packages
are built in the shell.nix file, so yes, I am building both, using the same
recipe, but one with Guile 1.8, and one with Guile 2.2. Both are using
21 matches
Mail list logo
