Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
On 2014/07/27 21:31:52, Keith wrote: On 2014/07/27 11:50:17, dak wrote: > https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787 > ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete > 'rhythmic-head-interface > Ugh. This looks incredibly ugly. I guess I lack a sense of aesthetics for Scheme code; I thought it was rather pretty. The ugliness has nothing to do with the programming language involved. The ugliness is with messing up the whole grob definition of a NoteHead (which is fixed to the degree of being documented in the Internals Reference) inside of a particular context. > It would make more sense to make rhythmic-head-interface get along without Rhythmic_column_engraver It is easy to make the rest of the code accept an object with rhythmic-head-interface that is unattached to any Rhythmic_Column (just removing a test and warning in rest-collision.cc as I recall). The thing I didn't like about that was changing completely unrelated code to accommodate the weirdness of NullVoice. I don't see anything wrong with letting code work in more combinations than originally envisioned. Where is the point in having separate building blocks if you can only assemble them in a single way? > If we really, really cannot make do otherwise, we could design substitute > engravers that mostly do the same job but without producing output. I mean, > Midi has to produce the same timing for Lyrics and manages with a vastly > simplified set of performers. My first inclination was to make an engraver that merely sets melismaBusy and lets the Lyrics attach to PaperColumns, but then we would need to synchronize that engraver with what Tie_engraver, etc., do if there is ever a change, The point would be to stop the Tie_engraver from bothering about melismaBusy at all. and the current gives NoteHeads with real extents to which the Lyrics can line up exactly as if there was a printed note. But isn't NullVoice for faking lyrics to a synthetic voice that is _not_ actually being printed? That would imply that we want to rather align to the existing NoteHeads/NoteColumns rather than the NullVoice one. And even if there are no actual notes (like in a chant situation), we'd rather align on a well-spaced pattern rather than one based on imaginary noteheads, optical stem adjustments and what not. https://codereview.appspot.com/117050043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: minor revisions to Easier Editing (issue 118350043 by colinpkcampb...@gmail.com)
On 2014/07/27 08:22:47, uliska wrote: Apart from my comment LGTM Good feedback, Urs, and thanks. Changed patchset uploaded. https://codereview.appspot.com/118350043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by janek.lilyp...@gmail.com)
On Sun, 27 Jul 2014 09:44:22 -0700, wrote: On 2014/07/26 21:36:12, Keith wrote: On 2014/07/26 06:49:41, janek wrote: > > Setting TextScript.cross-staff property to #f is required to ensure > that there are no collisions between TextScripts and cross-staff notes: The concept of a "cross-staff note" seems strange. It appeared with the change for issue 2527 https://codereview.appspot.com/6827072#msg13 Hmm. Do i see correctly that the patch in https://codereview.appspot.com/6827072 was then partially reverted with commit 7891600a5dd421c1f25776ea3b405c64f4f14752 ? Right. NoteColumns are no longer cross-staff. If we mark TextScript.cross-staff=#t it collides with /any/ note. Cross-staff things are skipped during outside-staff placement axis-group-interface.cc:939 (though it seems they could, with more code, be placed relative to their parent staff, without being included in the parent staff's skyline). Most things that go cross-staff use the side-position-interface to avoid collisions, but the engraver for TextScripts does not put anything into its 'support' list so that method has no effect. I think the example of issue 1300 succeeds only because TextScript is put in a ScriptColumn with the accent. It collides in the stable release if there is no accent, or a trill in place of the accent. define-grob-properties says 'cross-staff' means that the object can change shape or move relative to its parent, depending on how staves are spaced on the page. TextScripts do not yet respond to staff-spacing, except when they are in a ScriptColumn that knows how to avoid a cross-staff beam, and that case seems inconsistent. Shall i revert commit 2371d6ba3b62d4d6dc349ab50fa0d76eadfba044 for now? I don't know. The case of issue 1300 was not a realistic input, and similar cases fail in the stable build. On the other hand, from the tracker issue, it looks like your commit doesn't provide us with any improvements. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 4024: Clarify break-align symbols and space-alist args in IR. (issue 114160044 by markpole...@gmail.com)
Reviewers: , Message: Since no one reviewed this patch, I'm setting its status back to review. I'll push it next countdown if I all remains quiet. Thanks, Mark Description: Things take so long to understand when they're not documented! Issue 4024 on the tracker: http://code.google.com/p/lilypond/issues/detail?id=4024 Please review this at https://codereview.appspot.com/114160044/ Affected files (+123, -62 lines): M lily/break-alignment-interface.cc M scm/define-grob-properties.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
On 2014/07/27 11:50:17, dak wrote: https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787 ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete 'rhythmic-head-interface Ugh. This looks incredibly ugly. I guess I lack a sense of aesthetics for Scheme code; I thought it was rather pretty. It would make more sense to make rhythmic-head-interface get along without Rhythmic_column_engraver It is easy to make the rest of the code accept an object with rhythmic-head-interface that is unattached to any Rhythmic_Column (just removing a test and warning in rest-collision.cc as I recall). The thing I didn't like about that was changing completely unrelated code to accommodate the weirdness of NullVoice. If we really, really cannot make do otherwise, we could design substitute engravers that mostly do the same job but without producing output. I mean, Midi has to produce the same timing for Lyrics and manages with a vastly simplified set of performers. My first inclination was to make an engraver that merely sets melismaBusy and lets the Lyrics attach to PaperColumns, but then we would need to synchronize that engraver with what Tie_engraver, etc., do if there is ever a change, and the current gives NoteHeads with real extents to which the Lyrics can line up exactly as if there was a printed note. https://codereview.appspot.com/117050043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
Reviewers: janek, dak,
Message:
On 2014/07/27 11:25:41, janek wrote:
https://codereview.appspot.com/117050043/diff/40001/input/regression/lyric-combine-nullvoice.ly#newcode15
input/regression/lyric-combine-nullvoice.ly:15: >> }
This regtest is nice, but as far as i can see it doesn't check whether
issue
3825 has been fixed - i.e. the output looks the same before and after
the change
in the code.
Oops. Putting the tie into the rhythm covered up the problem of issue
3825.
I have extended the test a little so that it demonstrates each of the
reported issues.
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787
ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete
'rhythmic-head-interface
What about making NullVoice \accepted not by \Staff, but by \Score
(like
Devnull)? From my test it seems that it would work and we wouldn't
have to care
about Rhythmic_column_engraver.
That works, unless people setting Lyrics move engravers around in ways
that I haven't considered.
It seems we need to make NoteHead objects with the proper extent so they
are fully equivalent to notes for Lyrics alignment, but invisible and
non-interacting with the rest of the layout. Putting these NoteHeads in
the Score, where no other layout is looking for them, is simpler than
having the NoteHeads tell every other engraver "I am not the kind of
NoteHead that you are looking for."
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode798
ly/engraver-init.ly:798: \omit AccidentalSuggestion
I think these are unneeded anyway.
So long as Accidental_engraver stays out of \Score.
We could keep some of these overrides just in the engravers are moved
around, but ket's test and review it without the defensive \overrides.
Description:
Simplify the NullVoice context
issues 3834 3825 3734
Please review this at https://codereview.appspot.com/117050043/
Affected files (+29, -62 lines):
M Documentation/notation/vocal.itely
A input/regression/lyric-combine-nullvoice.ly
M ly/engraver-init.ly
M ly/performer-init.ly
Index: Documentation/notation/vocal.itely
diff --git a/Documentation/notation/vocal.itely
b/Documentation/notation/vocal.itely
index
187e10566f2970b358bce44a92f543ae645e25b5..2a3f89d7eccb2c3f6d7ab3d79c1a6ce87d6b1077
100644
--- a/Documentation/notation/vocal.itely
+++ b/Documentation/notation/vocal.itely
@@ -1682,13 +1682,6 @@ words = \lyricmode { la __ la __ }
>>
@end lilypond
-The @code{NullVoice} context must be placed within a @code{Staff}
-context and contain notes that are already being displayed in that staff
and that are also in the same octave. Otherwise the
-@code{NullVoice} may interact with the printed voices in
-unexpected ways. For example, arbitrary notes in the
-@code{NullVoice} may cause accidentals to appear (or disappear) on
-the staff.
-
This method also can be used with the @code{\partcombine}
function, which does not allow lyrics on its own:
@@ -1724,23 +1717,13 @@ aligner = \relative { b'8( c d c) d( d d d) }
words = \lyricmode { la __ la __ }
\new ChoirStaff <<
- \new Staff <<
-\soprano
-\new NullVoice = "aligner" \aligner
- >>
+ \new Staff \soprano
+ \new NullVoice = "aligner" \aligner
\new Lyrics \lyricsto "aligner" \words
\new Staff \partcombine \altoOne \altoTwo
>>
@end lilypond
-However, note that in the second half of the measure above, the
-notes in the @code{NullVoice} context reflect the rhythm of the
-lower staff, but they do not deviate from the single pitch being
-displayed in the staff to which the @code{NullVoice} belongs.
-While not actually required in this particular example, it is a
-good idea in general to enter the notes in this way.
-
-
@node Stanzas
@subsection Stanzas
Index: input/regression/lyric-combine-nullvoice.ly
diff --git a/input/regression/lyric-combine-nullvoice.ly
b/input/regression/lyric-combine-nullvoice.ly
new file mode 100644
index
..0592dc4e409a1461fd1821b7773ccf963228a656
--- /dev/null
+++ b/input/regression/lyric-combine-nullvoice.ly
@@ -0,0 +1,15 @@
+\version "2.19.11"
+\header {
+ texidoc ="Lyrics can be aligned to a @code{NullVoice} context,
+ which prints no notes, with the usual mechanisms for melismata."
+}
+\paper { ragged-right = ##f }
+\score { <<
+ \new Staff <<
+{ c''4. g'8 c''2 | g'8( f' g'4)~ g'2 } \\
+{ c'4 b c'8 e' g' e' | c'1 }
+\new NullVoice = "nv" {
+ \autoBeamOff c4 r16 b,8. c8[ e8 g8 e8] | g8( f g4)~ g2 }
+ >>
+ \new Lyrics \lyricsto "nv" { free a -- lign -- ment }
+>> }
Index: ly/engraver-init.ly
diff --git a/ly/engraver-init.ly b/ly/engraver-init.ly
index
ec34cd64c33fa1187504bfc9ebd02f5a14ec4768..e386ee45e91f4eb0a64d6c61190b2ff852ba6edd
100644
--- a/ly/engraver-init.ly
+++ b/ly/engraver-init.ly
@@ -99,7 +99,6 @@
\defaultchild "Voice"
\accepts "Voice"
\accepts "CueVoice"
- \accepts "NullVoice"
\description "Handles clefs, bar
Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by janek.lilyp...@gmail.com)
On 2014/07/26 21:36:12, Keith wrote: On 2014/07/26 06:49:41, janek wrote: > > Setting TextScript.cross-staff property to #f is required to ensure > that there are no collisions between TextScripts and cross-staff notes: > (see also beam-cross-staff-auto-knee.ly) > > As far as I can see, we don't want TextScript.cross-staff to be true > in any situation, because it would result in unwanted collisions. > The old setting for TextScript.cross-staff was put there to solve issue 1300. Almost everything has changed since then in the code that spaces things around staves, but with TextScript.cross-staff = #f the text collides with the accent in that example. Oops, i should have checked that myself! I apologize. The concept of a "cross-staff note" seems strange. It appeared with the change for issue 2527 https://codereview.appspot.com/6827072#msg13 That patch made Scripts reference NoteColumns, rather than PaperColumns for their placement -- very similar to the change here -- but Scripts can be cross-staff without hitting note-heads. Can you reconcile this patch and https://codereview.appspot.com/6827072 ? Hmm. Do i see correctly that the patch in https://codereview.appspot.com/6827072 was then partially reverted with commit 7891600a5dd421c1f25776ea3b405c64f4f14752 ? I'll investigate this, but since the weekend is about to end (and the next one will already be busy for me), it will take me an unpredictable amount of time to get this done. Shall i revert commit 2371d6ba3b62d4d6dc349ab50fa0d76eadfba044 for now? Thanks for spotting this. Janek https://codereview.appspot.com/106640043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build
Janek Warchoł writes: > 2014-07-27 13:49 GMT+02:00 Phil Holmes : >> Folks, >> >> Most people realise that me general schedule is to make and upload a GUB >> build every two weeks - normally on a Sunday afternoon. I'm postponing >> this week's until next Sunday - I'm away all afternoon and evening so >> starting them is a problem, and I'm nearly up to my broadband limit for >> the month, and an upload will likely take me over. > ok. Anyway, thanks a lot for your continuous work! It's good to have > you care about releases :) Well, most developers probably don't notice or bother much about regular developer releases. However, it is quite noticeable how often bug reports or questions on the user list are made in reference to the latest developer release. Particularly for Windows users, compiling LilyPond themselves is not a realistic option. So the regular releases are important to keep our ongoing work well-tested and maintaining a community of users willing to work with the newest developments, partly because of independent improvements, partly because of providing fixes for problems they reported themselves. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB build
ok. Anyway, thanks a lot for your continuous work! It's good to have you care about releases :) Janek 2014-07-27 13:49 GMT+02:00 Phil Holmes : > Folks, > > Most people realise that me general schedule is to make and upload a GUB > build every two weeks - normally on a Sunday afternoon. I'm postponing > this week's until next Sunday - I'm away all afternoon and evening so > starting them is a problem, and I'm nearly up to my broadband limit for > the month, and an upload will likely take me over. > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly File ly/engraver-init.ly (right): https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787 ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete 'rhythmic-head-interface On 2014/07/27 11:25:41, janek wrote: What about making NullVoice \accepted not by \Staff, but by \Score (like Devnull)? From my test it seems that it would work and we wouldn't have to care about Rhythmic_column_engraver. Ugh. This looks incredibly ugly. No code elsewhere messes with the basic underlying grob properties, and overriding a nested property to boot is a recipe for trouble. We really, really should not be doing something like that. It would make more sense to make rhythmic-head-interface get along without Rhythmic_column_engraver or otherwise fix things to work properly when a number of engravers are being removed. If we really, really cannot make do otherwise, we could design substitute engravers that mostly do the same job but without producing output. I mean, Midi has to produce the same timing for Lyrics and manages with a vastly simplified set of performers. It's even conceivable to tie the lyrics and other stuff together with translators that are basically decoupled from the engravers/performers doing the actual grobs or sobs (or what we call the sound equivalent of a grob). We could use those for every output then. For example, if we have some separate translator producing artificial tie STOP events (and catering for tieWaitForNote and similar), we'd run less of a danger that Midi and PDF get out of synch. And custom engravers making use of that info would become simpler. That way we don't need to reimplement the synhronization yet another time if we add, say, MusicXML output. https://codereview.appspot.com/117050043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB build
Folks, Most people realise that me general schedule is to make and upload a GUB build every two weeks - normally on a Sunday afternoon. I'm postponing this week's until next Sunday - I'm away all afternoon and evening so starting them is a problem, and I'm nearly up to my broadband limit for the month, and an upload will likely take me over. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
thank you! (was: PATCHES: Countdown for July 30th 2014)
Hi all, let me use this opportunity to thank James for his work on shepherding and testing LilyPond patches. This is very helpful, and appreciated! cheers, Janek 2014-07-27 6:14 GMT+02:00 James : > Hello, > > Here is the current patch countdown list. The next countdown will be on > July 30th. > > You can always view the most current countdown list here: > http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch > > > > > PUSH: > > Mark Polesky: Make list of `non-staff lines' easier to find in IR. > http://code.google.com/p/lilypond/issues/detail?id=4026 > > Mark Polesky: Clarify break-align symbols and space-alist args in IR. > http://code.google.com/p/lilypond/issues/detail?id=4024 > > James Lowe: Patch: Doc: NR - Pitches.itely - dodecaphonic-no-repeat text alt > http://code.google.com/p/lilypond/issues/detail?id=4023 > > David Kastrup: Patch: Remove obsolete restrictions from > define-*-function docstrings > http://code.google.com/p/lilypond/issues/detail?id=4021 > > David Kastrup: Binding-offset when used with two-sided causes unexpected > result when globally changing staff size > http://code.google.com/p/lilypond/issues/detail?id=4019 > > James Lowe: Patch: CG: Update of Patchy instructions > http://code.google.com/p/lilypond/issues/detail?id=4013 > > Keith OHara: weird attachment of Lyrics to NullVoice in polyphony > http://code.google.com/p/lilypond/issues/detail?id=3825 > > > > > COUNTDOWN: > > James Lowe: Create Texinfo @multitable entries for the > articulations.Appendix > http://code.google.com/p/lilypond/issues/detail?id=1189 > > > > > REVIEW: > > Janek Warchoł: Patch: Remove warning when there are no noteheads to > attach lyrics to. > http://code.google.com/p/lilypond/issues/detail?id=4029 > > James Lowe: Patch: Add an expert font tree interface > http://code.google.com/p/lilypond/issues/detail?id=4014 > > > > > NEW: > > Colin Campbell: Patch: DOC: minor revisions to Easier Editing > http://code.google.com/p/lilypond/issues/detail?id=4031 > > Janek Warchoł: Patch: Allow specifying different alignment for grob and > its parent > http://code.google.com/p/lilypond/issues/detail?id=4022 > > > > > WAITING: > > Urs Liska: Patch: Issue 3916: Add \alternatingTimeSignatures > http://code.google.com/p/lilypond/issues/detail?id=3918 > > Janek Warchoł: Positioning of "8" under clef symbol in G_8 clef > http://code.google.com/p/lilypond/issues/detail?id=3186 > > Mike Solomon: Patch: Prevents vertical axis groups with empty skylines > http://code.google.com/p/lilypond/issues/detail?id=3156 > > Mike Solomon: Patch: Removes the translate_axis call from > axis-group-interface outside-staff positioning. > http://code.google.com/p/lilypond/issues/detail?id=3134 > > David Kastrup: Patch: Implement music functions in Scheme rather than C++ > http://code.google.com/p/lilypond/issues/detail?id=2716 > > > > > Thank you, > James > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
@Dan: FYI, Keith has put up a patch that simplifies and improves NullVoice context - it should fix all the problems that we know of. It is currently being discussed at https://codereview.appspot.com/117050043 best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
Hi Keith,
your changes look good overall, but i think that NullVoice could be
simplified even further - see below.
thanks for your work!
https://codereview.appspot.com/117050043/diff/40001/input/regression/lyric-combine-nullvoice.ly
File input/regression/lyric-combine-nullvoice.ly (right):
https://codereview.appspot.com/117050043/diff/40001/input/regression/lyric-combine-nullvoice.ly#newcode12
input/regression/lyric-combine-nullvoice.ly:12: \autoBeamOff c4 r16
b,16~ b,8 c8[ e8 g8 e8] | g4( f4) g2 }
It seems that the closing slur is one note too early.
https://codereview.appspot.com/117050043/diff/40001/input/regression/lyric-combine-nullvoice.ly#newcode14
input/regression/lyric-combine-nullvoice.ly:14: \new Lyrics \lyricsto
"nv" { free a -- lign -- ment }
Shouldn't there be a lyric extender at the end?
https://codereview.appspot.com/117050043/diff/40001/input/regression/lyric-combine-nullvoice.ly#newcode15
input/regression/lyric-combine-nullvoice.ly:15: >> }
This regtest is nice, but as far as i can see it doesn't check whether
issue 3825 has been fixed - i.e. the output looks the same before and
after the change in the code. I think we should add the example from
issue 3825 verbatim (as another regtest), and have a regtest
corresponding to issue 3834.
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly
File ly/engraver-init.ly (right):
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode787
ly/engraver-init.ly:787: \override NoteHead.meta.interfaces = #(delete
'rhythmic-head-interface
What about making NullVoice \accepted not by \Staff, but by \Score (like
Devnull)? From my test it seems that it would work and we wouldn't have
to care about Rhythmic_column_engraver.
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode794
ly/engraver-init.ly:794: squashedPosition = 0
This should also become unneeded if we "move" NullVoice from Staff to
Score.
https://codereview.appspot.com/117050043/diff/40001/ly/engraver-init.ly#newcode798
ly/engraver-init.ly:798: \omit AccidentalSuggestion
I think these are unneeded anyway.
https://codereview.appspot.com/117050043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Remove warning when there are no noteheads to attach lyrics to. (issue 120200043 by janek.lilyp...@gmail.com)
Reviewers: ,
Message:
Pushed as
commit 476687b992c1c0d551b0d425e5ece78c39cfc3ef
Author: Janek Warchoł
Date: Sat Jul 26 09:00:39 2014 +0200
Remove warning when there are no noteheads to attach lyrics to.
The warning was added to address issue 248, but it is now moot after
issue 3254 (c73b41b3e7be6d7): attaching lyrics to a note-less
context
(like Devnull) is perfectly legal now.
Description:
Remove warning when there are no noteheads to attach lyrics to.
The warning was added to address issue 248, but it is now moot after
issue 3254 (c73b41b3e7be6d7): attaching lyrics to a note-less context
(like Devnull) is perfectly legal now.
Please review this at https://codereview.appspot.com/120200043/
Affected files (+0, -4 lines):
M lily/lyric-engraver.cc
Index: lily/lyric-engraver.cc
diff --git a/lily/lyric-engraver.cc b/lily/lyric-engraver.cc
index
1cbaffeb7d5376f7301cbdbcefc2301c28503d23..bbe15845a61a77379c070b6839637d69c4c1a507
100644
--- a/lily/lyric-engraver.cc
+++ b/lily/lyric-engraver.cc
@@ -174,24 +174,20 @@ Lyric_engraver::stop_translation_timestep ()
Grob *head = get_current_note_head (voice, include_grace_notes);
if (head)
{
text_->set_parent (head->get_parent(X_AXIS), X_AXIS);
if (melisma_busy (voice)
&& !to_boolean (get_property ("ignoreMelismata")))
text_->set_property ("self-alignment-X",
get_property
("lyricMelismaAlignment"));
}
- else
-text_->warning (_ ("Aligning lyric syllables to notes was
requested,"
- " but there are no notes in the specified
context."
- " Syllable will be attached to a
PaperColumn instead."));
}
last_text_ = text_;
text_ = 0;
}
event_ = 0;
}
ADD_TRANSLATOR (Lyric_engraver,
/* doc */
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
Mark Polesky writes: > Ha! My old repo stops a day before that change. No wonder I abandoned > it... Okay, when I have some time I'll start updating the small handful of > mislabeled committishes. It's not that many. Here are the tags that apparently have a history ending in the fred starting commit, keeping it alive in our repository. git tag --contains 0ff96d5d41379dbb968507fd848642da518dc50b release/1.5.59 release/1.5.60 release/1.5.71 release/1.7.25 release/1.7.28 release/1.7.29 release/1.9.5 release/2.1.10 release/2.1.11 release/2.1.12 release/2.1.13 release/2.1.14 release/2.1.15 release/2.1.16 release/2.1.17 release/2.1.18 release/2.1.19 release/2.1.20 release/2.1.21 release/2.1.22 release/2.1.27 release/2.1.3 release/2.1.36 release/2.1.4 release/2.1.5 release/2.1.6 release/2.1.7 release/2.1.8 release/2.1.9 release/2.3.12 release/2.3.24 release/2.3.9 release/2.5.23 release/2.5.32 release/2.6.4 release/2.7.16 release/2.7.2 release/2.7.20 release/2.7.38 release/2.8.2 start So what's up with them? Jan, any idea? Apparently you did the conversion. If I use git tag -l --contains 0ff96d5d41379dbb968507fd848642da518dc50b -n I get release/1.5.59 This commit was manufactured by cvs2svn to create tag 'lilypond_1_5_59'. release/1.5.60 This commit was manufactured by cvs2svn to create tag 'lilypond_1_5_60'. release/1.5.71 This commit was manufactured by cvs2svn to create tag 'lilypond_1_5_71'. release/1.7.25 This commit was manufactured by cvs2svn to create tag 'lilypond_1_7_25'. release/1.7.28 This commit was manufactured by cvs2svn to create tag 'lilypond_1_7_28'. release/1.7.29 This commit was manufactured by cvs2svn to create tag 'lilypond_1_7_29'. release/1.9.5 This commit was manufactured by cvs2svn to create tag 'lilypond_1_9_5'. release/2.1.10 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_10'. release/2.1.11 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_11'. release/2.1.12 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_12'. release/2.1.13 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_13'. release/2.1.14 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_14'. release/2.1.15 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_15'. release/2.1.16 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_16'. release/2.1.17 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_17'. release/2.1.18 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_18'. release/2.1.19 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_19'. release/2.1.20 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_20'. release/2.1.21 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_21'. release/2.1.22 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_22'. release/2.1.27 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_27'. release/2.1.3 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_3'. release/2.1.36 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_36'. release/2.1.4 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_4'. release/2.1.5 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_5'. release/2.1.6 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_6'. release/2.1.7 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_7'. release/2.1.8 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_8'. release/2.1.9 This commit was manufactured by cvs2svn to create tag 'lilypond_2_1_9'. release/2.3.12 This commit was manufactured by cvs2svn to create tag 'lilypond_2_3_12'. release/2.3.24 This commit was manufactured by cvs2svn to create tag 'lilypond_2_3_24'. release/2.3.9 This commit was manufactured by cvs2svn to create tag 'lilypond_2_3_9'. release/2.5.23 This commit was manufactured by cvs2svn to create tag 'lilypond_2_5_23'. release/2.5.32 This commit was manufactured by cvs2svn to create tag 'lilypond_2_5_32'. release/2.6.4 This commit was manufactured by cvs2svn to create tag 'lilypond_2_6_4'. release/2.7.16 This commit was manufactured by cvs2svn to create tag 'lilypond_2_7_16'. release/2.7.2 This commit was manufactured by cvs2svn to create tag 'lilypond_2_7_2'. release/2.7.20 This commit was manufactured by cvs2svn to create tag 'lilypond_2_7_20'. release/2.7.38 This commit was manufactured by cvs2svn to create tag 'lilypond_2_7_38'. release/2.8.2 This commit was manufactured by cvs2svn to create tag 'lilypond_2_8_2'. start This commit was manufactured by cvs2svn to create tag 'start'. So it seems likely that those are left from some earlier conversion. If I read "man git-tag" below "DISCUSSION", it would seem like retagging is an ugly thing once tags
Re: Have git SHA1 ID's changed in the last 5 years?
Mark Polesky writes: > David Kastrup wrote: >> but in my repository no commits authored by fred, > > Really? Can you try > a281aedda8d5ea550f8b851822315cf154acee52 ? commit a281aedda8d5ea550f8b851822315cf154acee52 Author: fred Date: Wed Mar 27 02:56:08 2002 + lilypond-1.5.47 But if I do git log --reverse a281aedda8d5ea550f8b851822315cf154acee52..origin the list starts with commit 4f4ad24a3bfeb77cfd0ecca104319607bfd28a63 Author: Han-Wen Nienhuys Date: Wed Oct 9 14:04:46 1996 +0100 Initial. commit 675bd3e6ea001c3af033b51a6e2eeab6a5809e86 Author: Han-Wen Nienhuys Date: Wed Oct 9 14:04:47 1996 +0200 release: 0.0.1 commit 727cdcbadf23c1986b0aed547aa645c9813f351b Author: Han-Wen Nienhuys Date: Tue Oct 22 22:09:43 1996 +0200 release: 0.0.2 which strongly suggests that origin and the given commit do not have a common history in the repository. So why is a281aedda8d5ea550f8b851822315cf154acee52 still in there? If I do git log --reverse a281aedda8d5 I get commit 0ff96d5d41379dbb968507fd848642da518dc50b Author: fred Date: Tue Jul 18 00:23:16 1995 + lilypond-1.0.1 commit 93d1d90d4645fc0f64ae310e0df224f00228ee78 Author: fred Date: Thu Sep 21 11:20:44 1995 + lilypond-1.0.1 as the purported starting point of the respective history. Usually that kind of history would have fallen by the wayside during garbage collection. It turns out that git log --remotes --reverse starts with commit 4f4ad24a3bfeb77cfd0ecca104319607bfd28a63 Author: Han-Wen Nienhuys Date: Wed Oct 9 14:04:46 1996 +0100 Initial. while git log --all --reverse starts with commit 0ff96d5d41379dbb968507fd848642da518dc50b Author: fred Date: Tue Jul 18 00:23:16 1995 + lilypond-1.0.1 here. So apparently I have _local_ references that keep the old history alive. If I do git log --all --reverse --source then my history starts with commit 0ff96d5d41379dbb968507fd848642da518dc50b refs/tags/release/1.7.25 Author: fred Date: Tue Jul 18 00:23:16 1995 + lilypond-1.0.1 So it is tags which keep the old history from getting garbage collected. git tag -n 1000 | less shows up quite a few strange tag annotations. Huh. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
Ha! My old repo stops a day before that change. No wonder I abandoned it... Okay, when I have some time I'll start updating the small handful of mislabeled committishes. It's not that many. Thanks, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
David Kastrup wrote: > but in my repository no commits authored by fred, Really? Can you try a281aedda8d5ea550f8b851822315cf154acee52 ? fred even appears as an author on the savannah repo: http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=a281aed although strangely it looks like there are hundreds and hundreds of commits in the space of 2 days... Anyway, my old repo stops at Mar 21 2010, with what is now referenced as: Doc: [fr] add `0' as missing git committish. Fixes check-translation barf. authorJan Nieuwenhuizen Sun, 21 Mar 2010 14:28:48 + (15:28 +0100) committer Jan Nieuwenhuizen Sun, 21 Mar 2010 14:28:48 + (15:28 +0100) commiteb2006bdcd2e7ac3d5aa213b1a05a640ae1b933b My old repo lists this commit as c22572a6185db965bbaa4bb8af17a29bdc78bacf My new repo, which does list "fred" as an author, was created on Jun 27 2013. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: minor revisions to Easier Editing (issue 118350043 by colinpkcampb...@gmail.com)
Apart from my comment LGTM https://codereview.appspot.com/118350043/diff/1/Documentation/web/introduction.itexi File Documentation/web/introduction.itexi (right): https://codereview.appspot.com/118350043/diff/1/Documentation/web/introduction.itexi#newcode1221 Documentation/web/introduction.itexi:1221: features added and enhanced particularly for LilyPond. It is easy to use Do you think it is relevant (today) that Frescobaldi has a LilyKDE history? And actually it is not _developed_ from LilyKDE: Frescobaldi 2 is a replacement for Frescobaldi 1, which was renamed from LilyKDE, which (IIRC) was either an extension or a development from Kite. https://codereview.appspot.com/118350043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
Benkő Pál writes: > 2014-07-27 9:54 GMT+02:00 David Kastrup : >> Benkő Pál writes: >> Okay, so I'm not crazy. I happened to keep an old repo from four years ago, and as you can see from the attached image, the two histories are not the same, and neither are the commit SHA1 IDs... How did this happen, and could it happen again? >>> >>> could you track down the first divergence and/or give more info >>> about those repositories? I've tried to check the commits >>> shown in your attached picture, but couldn't find any. >>> in fact the authors are quite suspicious, in my repo there's >>> no commit from fred, neither any from 1999-10-05. >> >> In ~/.mailmap I see a line >> >> Han-Wen Nienhuys and Jan Nieuwenhuizen # see note below >> >> but in my repository no commits authored by fred, so this suggests to me >> someone rewriting the history of the repository at some point of time in >> order to get rid of nonsensical author attributions. > > well, the difference in dates is still to be explained. 1.3.0 happened on > 1999-10-26 with 3a0e9efb7f067e5b334ba0596b95e15d96d7cc49, > matching neither of Mark's repos. Well, the solution would appear to be in the archives indeed. Check out http://lists.gnu.org/archive/html/lilypond-devel/2010-03/msg00303.html> and followups. So it would appear that indeed the old SHA1 sums are in need of repair. If anybody does that, I'd strongly recommend quoting several more characters of the full SHA1 since obviously the LilyPond repository is growing all the time and thus short identifiers that were at some point of time unambiguous can stop being so. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
2014-07-27 9:54 GMT+02:00 David Kastrup : > Benkő Pál writes: > >>> Okay, so I'm not crazy. I happened to keep an old repo from >>> four years ago, and as you can see from the attached image, >>> the two histories are not the same, and neither are the >>> commit SHA1 IDs... How did this happen, and could it happen >>> again? >> >> could you track down the first divergence and/or give more info >> about those repositories? I've tried to check the commits >> shown in your attached picture, but couldn't find any. >> in fact the authors are quite suspicious, in my repo there's >> no commit from fred, neither any from 1999-10-05. > > In ~/.mailmap I see a line > > Han-Wen Nienhuys and Jan Nieuwenhuizen # see note below > > but in my repository no commits authored by fred, so this suggests to me > someone rewriting the history of the repository at some point of time in > order to get rid of nonsensical author attributions. well, the difference in dates is still to be explained. 1.3.0 happened on 1999-10-26 with 3a0e9efb7f067e5b334ba0596b95e15d96d7cc49, matching neither of Mark's repos. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
Benkő Pál writes: >> Okay, so I'm not crazy. I happened to keep an old repo from >> four years ago, and as you can see from the attached image, >> the two histories are not the same, and neither are the >> commit SHA1 IDs... How did this happen, and could it happen >> again? > > could you track down the first divergence and/or give more info > about those repositories? I've tried to check the commits > shown in your attached picture, but couldn't find any. > in fact the authors are quite suspicious, in my repo there's > no commit from fred, neither any from 1999-10-05. In ~/.mailmap I see a line Han-Wen Nienhuys and Jan Nieuwenhuizen # see note below but in my repository no commits authored by fred, so this suggests to me someone rewriting the history of the repository at some point of time in order to get rid of nonsensical author attributions. Maybe something can be found in the developer list archive? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Have git SHA1 ID's changed in the last 5 years?
> Okay, so I'm not crazy. I happened to keep an old repo from > four years ago, and as you can see from the attached image, > the two histories are not the same, and neither are the > commit SHA1 IDs... How did this happen, and could it happen > again? could you track down the first divergence and/or give more info about those repositories? I've tried to check the commits shown in your attached picture, but couldn't find any. in fact the authors are quite suspicious, in my repo there's no commit from fred, neither any from 1999-10-05. history from 1.2.12 to 1.2.13 looks like $ git log -4 release/1.2.13 commit 0cf97b5cdceecbba937f43ac827f4065aad5001e Author: Han-Wen Nienhuys Date: Mon Oct 11 11:47:55 1999 +0200 release: 1.2.13 commit e319b8b2e19181a6e0864139bd94a36d66adb602 Author: Jan Nieuwenhuizen Date: Sun Oct 10 17:19:11 1999 +0200 patch::: 1.2.12.jcn2 pl 12.jcn2 - smobs commit b4c9fbc328f1e9681b0c582bae7be61a451a43d0 Author: Jan Nieuwenhuizen Date: Wed Oct 6 10:57:49 1999 +0200 patch::: 1.2.12.jcn1 pl 12.jcn1 - auto-knees, input/test/auto-knee.ly commit 1a71119277d04b287b3a976c526adba6500239c6 Author: Han-Wen Nienhuys Date: Mon Oct 4 13:37:38 1999 +0200 release: 1.2.12 $ (and that matches that seen at http://git.savannah.gnu.org/gitweb/?p=lilypond.git&a=search&h=0cf97b5cdceecbba937f43ac827f4065aad5001e&st=commit&s=1.2.12 ) p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
