Re: \incipit sometimes returns programming error
On May 27, 2022, at 10:28, Jean Abou Samra wrote: > > Le 27/05/2022 à 14:34, Dan Eble a écrit : >> I would at least like to understand whether the error message is reasonable >> first. > > Do you mean whether it is reasonable for \bar "" during a > note to trigger a programming error, or whether it is > reasonable for MensuralStaff to have "" bars by default? Harm wants to eliminate this error in a specific case: programming error: Loose column does not have right side to attach to. Is something truly wrong or are the conditions that trigger the message too broad? Maybe this case is fine and the right thing to do is to avoid logging the message. I would like to know which. — Dan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \incipit sometimes returns programming error
Le 27/05/2022 à 14:34, Dan Eble a écrit : I would at least like to understand whether the error message is reasonable first. Do you mean whether it is reasonable for \bar "" during a note to trigger a programming error, or whether it is reasonable for MensuralStaff to have "" bars by default? ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \incipit sometimes returns programming error
On May 26, 2022, at 11:36, Jean Abou Samra wrote: > I can't tell why the commit "Refactor BarLine engraving" had that > effect (and I'm not investigating). Dan, any thoughts? Should > MensuralStaff simply be changed to have measureBarType = ##f > (instead of "")? I think that measureBarType = #'() would be harmless in \incipit because there is no need to allow break points, but with so much already in flux, I would prefer not to throw in another hack. I would at least like to understand whether the error message is reasonable first. — Dan ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \incipit sometimes returns programming error
Le 26/05/2022 à 18:47, Thomas Morley a écrit :
Am Do., 26. Mai 2022 um 17:36 Uhr schrieb Jean Abou Samra :
Le 26/05/2022 à 17:12, Thomas Morley a écrit :
Hi,
consider:
\score {
\new Staff \with { instrumentName = "" } { \incipit { c'1. } R1 }
\layout {
indent = 5\cm
incipit-width = 3\cm
}
}
with recent versions it returns:
programming error: Loose column does not have right side to attach to.
First bad comit is:
commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
Author: Dan Eble
Date: Thu Mar 10 20:08:31 2022 -0500
Refactor BarLine engraving
[...]
Dan?
The example above can be fixed by inserting an explicit \bar "" at end
of incipit-music.
Cheers,
Harm
That looks like an old bug uncovered to me. \incipit
uses a MensuralStaff, and indeed I can reproduce it
with
\version "2.23.10"
\new MensuralStaff {
c'1.
}
The definition of MensuralStaff contains measureBarType = "",
and this also triggers the bug:
\version "2.23.10"
\new Staff \with {
measureBarType = ""
} {
c'1.
}
which is an instance of our old
https://gitlab.com/lilypond/lilypond/-/issues/4084
I can't tell why the commit "Refactor BarLine engraving" had that
effect (and I'm not investigating). Dan, any thoughts? Should
MensuralStaff simply be changed to have measureBarType = ##f
(instead of "")?
Jean
Currently I'm testing LSR-upgrade to current master, anticipating the
next stable. In the past doing so served me well as soon as the next
stable is actually out and updating LSR is really a TODO-NOW.
I stumbled upon a handful snippets (I may post about them, if I don't
find my way), one of them is incipit.ly,
https://lsr.di.unimi.it/LSR/Item?id=582
It works fine with 2.22. and before, I wonder why #4084 raises its
head now and not before.
Wouldn't it be a possibility to just change our `incipit':
$ git diff
diff --git a/ly/property-init.ly b/ly/property-init.ly
index f8e6ee37be..c0605757be 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -323,6 +323,7 @@ incipit =
\override InstrumentName.self-alignment-X = #align-x
\override InstrumentName.self-alignment-Y = #align-y
instrumentName = #instrument-name
+measureBarType = ##f
}
{
$incipit-music
At least it fixes the here reported bug.
It doesn't fix \new MensuralStaff { c'1. } though.
I'm for understanding what happened before changing
things.
Best,
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \incipit sometimes returns programming error
Am Do., 26. Mai 2022 um 17:36 Uhr schrieb Jean Abou Samra :
>
>
>
> Le 26/05/2022 à 17:12, Thomas Morley a écrit :
> > Hi,
> >
> > consider:
> >
> > \score {
> >\new Staff \with { instrumentName = "" } { \incipit { c'1. } R1 }
> >\layout {
> > indent = 5\cm
> > incipit-width = 3\cm
> >}
> > }
> >
> > with recent versions it returns:
> > programming error: Loose column does not have right side to attach to.
> >
> > First bad comit is:
> > commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
> > Author: Dan Eble
> > Date: Thu Mar 10 20:08:31 2022 -0500
> >
> > Refactor BarLine engraving
> > [...]
> >
> > Dan?
> >
> >
> > The example above can be fixed by inserting an explicit \bar "" at end
> > of incipit-music.
> >
> >
> > Cheers,
> >Harm
>
>
> That looks like an old bug uncovered to me. \incipit
> uses a MensuralStaff, and indeed I can reproduce it
> with
>
> \version "2.23.10"
>
> \new MensuralStaff {
>c'1.
> }
>
>
> The definition of MensuralStaff contains measureBarType = "",
> and this also triggers the bug:
>
> \version "2.23.10"
>
> \new Staff \with {
>measureBarType = ""
> } {
>c'1.
> }
>
> which is an instance of our old
>
> https://gitlab.com/lilypond/lilypond/-/issues/4084
>
> I can't tell why the commit "Refactor BarLine engraving" had that
> effect (and I'm not investigating). Dan, any thoughts? Should
> MensuralStaff simply be changed to have measureBarType = ##f
> (instead of "")?
>
> Jean
>
>
>
Currently I'm testing LSR-upgrade to current master, anticipating the
next stable. In the past doing so served me well as soon as the next
stable is actually out and updating LSR is really a TODO-NOW.
I stumbled upon a handful snippets (I may post about them, if I don't
find my way), one of them is incipit.ly,
https://lsr.di.unimi.it/LSR/Item?id=582
It works fine with 2.22. and before, I wonder why #4084 raises its
head now and not before.
Wouldn't it be a possibility to just change our `incipit':
$ git diff
diff --git a/ly/property-init.ly b/ly/property-init.ly
index f8e6ee37be..c0605757be 100644
--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -323,6 +323,7 @@ incipit =
\override InstrumentName.self-alignment-X = #align-x
\override InstrumentName.self-alignment-Y = #align-y
instrumentName = #instrument-name
+measureBarType = ##f
}
{
$incipit-music
At least it fixes the here reported bug.
Thanks,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: \incipit sometimes returns programming error
Le 26/05/2022 à 17:12, Thomas Morley a écrit :
Hi,
consider:
\score {
\new Staff \with { instrumentName = "" } { \incipit { c'1. } R1 }
\layout {
indent = 5\cm
incipit-width = 3\cm
}
}
with recent versions it returns:
programming error: Loose column does not have right side to attach to.
First bad comit is:
commit 8ae26d8330c603d249fec5953a887de9fbcbe31c
Author: Dan Eble
Date: Thu Mar 10 20:08:31 2022 -0500
Refactor BarLine engraving
[...]
Dan?
The example above can be fixed by inserting an explicit \bar "" at end
of incipit-music.
Cheers,
Harm
That looks like an old bug uncovered to me. \incipit
uses a MensuralStaff, and indeed I can reproduce it
with
\version "2.23.10"
\new MensuralStaff {
c'1.
}
The definition of MensuralStaff contains measureBarType = "",
and this also triggers the bug:
\version "2.23.10"
\new Staff \with {
measureBarType = ""
} {
c'1.
}
which is an instance of our old
https://gitlab.com/lilypond/lilypond/-/issues/4084
I can't tell why the commit "Refactor BarLine engraving" had that
effect (and I'm not investigating). Dan, any thoughts? Should
MensuralStaff simply be changed to have measureBarType = ##f
(instead of "")?
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
