[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

From: k-ohara5a5a
Subject: Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)
Date: Fri, 04 Nov 2011 06:39:56 +0000

I'll try to make a patch so that note-spacing is not affected by
potential collisions between grobs from different staff-like-contexts
(fixing the rare Lyrics-barline interaction).  Then we can restore

Net, with this patch and the other SpanBarStub patch, you've added 680
lines of code containing two new engravers, to fix issue 910 and issue
1955.  I don't like the thought of maintaining that.

What is the overall plan for the new engravers?
File input/regression/ (right):
input/regression/ texidoc = "Long lyrics
should be allowed to pass under
They do so, except in very rare cases in short examples where nothing
protrudes from the staff.

I agree it would be nice to change this, but did you really see the
problem in real music?
File lily/ (right):
lily/ vector<Grob *> pures_;
This takes the lilypond-jargon 'pure' even further from its original
inspiration (a pure function that does not depend on nor change program
What is a 'pure' when used as a noun?
File scm/define-grob-properties.scm (right):
scm/define-grob-properties.scm:583: (neighbors-filtered ,boolean?
"Callback to filter an element list.")
But 'neighbors-filtered' is not the callback, but the resulting list, is
it not?
The question I look here to answer is "how does LilyPond behave
differently if elements-filtered is changed?"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]