David Kastrup [Tue, 5 Mar 2013 10:33:04 +0000 (11:33 +0100)]
Issue 3225: Decouple \defaultchild from \accepts list in contexts
The definition of a Bottom context previously was a context not
accepting any subcontexts. Now it is a context without a
\defaultchild. The defaultchild of a context previously was the first
found in the \accepts list (if necessary, moving it there). While
\defaultchild was tracked in context definitions, it was not explicit
in instantiated contexts.
Decoupling those makes for more flexible arrangements of contexts.
For example, one might let Voice accept a SubVoice context without
forcing SubVoice to be created when a Bottom context is called for
when in Voice, simply by not giving Voice a \defaultchild.
David Kastrup [Wed, 27 Feb 2013 18:56:02 +0000 (19:56 +0100)]
Issue 3212: Make test-output-distance regtest contain span bars
Since span bars don't turn up in the metrics, the regtests don't show
them. To make catastrophic span bar failures show up at least
somewhere, the ever-changing test-output-distance test is made to
include them.
David Kastrup [Sun, 3 Mar 2013 11:24:32 +0000 (12:24 +0100)]
Issue 1334: A \score-lines markup list command for multi-lines embedded scores
Like the \score markup, this is not usually called by users directly
as it would require something awkward along the lines of
\score-lines ##{ \score { ... } #}
to get this through. Instead, using \score in contexts where only
markup lists are allowed will pass the action to the \score-lines
markup list command.
Note that there are as of yet no user-level commands spacing a markup
list in a way similar to the spacing inside of a \score markup.
David Kastrup [Sun, 3 Mar 2013 00:04:31 +0000 (01:04 +0100)]
Issue 3187: Ugly alignment of text and score within a markup
For \score within \markup, the reference point (usually the middle
staff line) of the lowest staff in the top system is placed on the
baseline.
This is an incompatible change, but the previous behavior (placing the
_highest_ y coordinate of the score on the baseline, disregarding the
staves) was not useful.
David Kastrup [Wed, 27 Feb 2013 00:26:14 +0000 (01:26 +0100)]
Issue 3205: opening bar check causes crash if \score contains the \midi block
This derives Bar_check_iterator from Music_iterator rather than from
Simple_music_iterator.
In
\score {
{ | d }
\midi { }
}
the bar check iterator is being called while only the \Global context
exists. That causes Score_performer::one_time_step to be called
without getting Score_performer::prepare to be called previously,
probably because the Score context is created at the wrong time. The
Score_performer is not prepared for this situation.
I have no idea how to fix Simple_music_iterator, why it exists in the
first place and is written like it is, and why this appears to work.
Mike Solomon [Tue, 5 Mar 2013 20:03:55 +0000 (21:03 +0100)]
Uses only unpure-pure containers to articulate unpure-pure relationships (issue 3199)
Previously, LilyPond used several different lists in define-grobs.scm
to define relationships between unpure and pure functions. This patch
eliminates these lists, using unpure-pure containers to articulate
these relationships.
The modifications required to implement this change are described below:
-) axis-group-interface.cc
A Scheme function is no longer needed to determine pure relevant grobs.
All grobs can have their Y-extents meaningfully pure-evaluated now. The
worst-case scenario is that they evaluate to false. Dead grobs, on the
other hand, are never pure relevant. The calls to is_live are the only
holdovers from the old pure-relevant? scheme function.
-) grob-closure.cc
We allow unpure-pure containers in simple closures.
-) grob-property.cc
call_pure_function no longer looks up a Scheme module. Because there are
no hard-coded lists in Scheme any more, the function is smaller and
writing it in C++ gets slight efficiency gains.
-) grob.cc
pure_stencil_height used to be a Scheme function in define-grobs.scm.
Because it is much simpler (it no longer makes references to lists defined
in Scheme), it can be implemented in C++.
-) pure-from-neighbor-engraver.cc
Similar to axis-group-interface.cc, the pure-relevant distinction is
no longer important.
-) side-position-interface.cc
In order to avoid issues with alterBroken, we only check pure properties
before line breaking.
-) simple-closure.cc
Simple closures were incorrectly evaluated when containing unpure-pure
containers. This rectifies that.
-) stencil-integral.cc
Several pure equivalent functions needed to be written for skylines.
-) define-grobs.scm
Multiple overrides must be changed to unpure-pure containers. Previous
hard-coded lists are all deleted and several functions moved to C++ (see
above).
-) output-lib.scm
Several common unpure-pure containers used in define-grobs.scm are
defined here. Several functions from define-grobs.scm pertaining to
grob offsets are moved to this file.
David Kastrup [Sat, 23 Feb 2013 08:56:06 +0000 (09:56 +0100)]
Issue 3201: Don't initialize dim_cache_ array via constructor syntax
This is not valid C++ and not even a documented GCC extension. It is
probabably an oversight that GCC appears to be able to interpret this
in some manner.
Also creates a custom copy constructor for Dimension_cache for the
sole purpose of being able to initialize a Dimension_cache array
element-wise from a Dimension_cache array in the copy constructor of
Grob. C++ clearly is lacking in some departments.
David Kastrup [Mon, 25 Feb 2013 10:17:02 +0000 (11:17 +0100)]
Issue 2985: lilypond: Umlauts and other special characters incorrectly exported to PDF meta data
Since recent versions of GhostScript are more likely to get along with
UTF-16BE rather than ISO-8859-1 for PDF meta strings, we just escalate
straight from ASCII to UTF16-BE.
Mike Solomon [Wed, 20 Feb 2013 05:58:02 +0000 (06:58 +0100)]
Removes pure-print-callbacks list.
LilyPond currently hardcodes certain print functions as being able
to be evaluated as 'pure', meaning that they should not result in calls
to set_property, set_object, translate_axis or suicide. This means that,
for example, if one uses a custom stencil function, the Y-extent function
for the grob must be wrapped in an unpure-pure-container in order
to return a non-empty pure_height.
The reading of these hardcoded lists results in difficult-to-maintain code.
For example, several (but not all) flag modification functions are part of
this list, causing spacing inconsistencies in certain regtests.
Using unpure-pure-containers to signify all relationships between unpure and
pure functions and eliminating the lists of pure functions in
define-grobs.scm allows the code base to be more extensible, demanding the
elaboration of unpure-pure relationships in the property-setting phase
(either in define-grobs.scm or in an override) and not using hardcoded lists.
Inversely, this also prevents deep that can creep up when a function
signified as pure turns out not to be. For example, ly:note-head::print,
marked as pure, can be made unpure if its lookup of the style,
duration-log or glyph-name properties trigger vertical alignment
(which results in a call to translate_axis). Thus, users who wish to use
this function as an unpure function now can because it is no longer
hardcoded as pure.
David Kastrup [Fri, 15 Feb 2013 12:58:16 +0000 (13:58 +0100)]
Issue 3182: Defuse the obfuscated Scheme programming contest
This merely grepped for occurences of "reduce" and replaced most of
them (and possibly the close surroundings) with something saner. The
winner definitely has been in bar-line.scm. I have not touched the
occurences in stencil.scm since it would have been like putting
lipstick on a pig: the surroundings are even worse than the calls of
reduce.
David Kastrup [Fri, 15 Feb 2013 09:50:43 +0000 (10:50 +0100)]
Issue3181: Replace several misuses of eq? on numerical values
Numerical values don't carry identity, so (eq? 0 0) may or may not
evaluate to #t. Those need to be replaced by eqv? or, where both
items are guaranteed to be a number, = .
David Kastrup [Thu, 13 Dec 2012 15:57:22 +0000 (16:57 +0100)]
Let calc-{fingering,string-number,stroke-finger}::calc-text look at event 'text
This slightly increases the number of property lookups, and the same
function can be achieved using a tweak. However, it seems more
natural to attach any overriding text (in the case of non-standard
elements like thumbs or other) directly to the event in question.
David Kastrup [Thu, 7 Feb 2013 09:18:39 +0000 (10:18 +0100)]
Issue 754: don't transpose generic property-setting music commands
The actual issue was that
\transpose c e { \transposition bes ... }
created a Midi corresponding to an instrument using a transposition of
ges, leaving the Midi unchanged. Making the generic property-setting
commands (\set and \override) impervious to transposition will also
keep \transpose from tampering with user-set values.
This is particularly important since the pitch data type in LilyPond
is also being used for signifying intervals or pitch differences
rather than absolute pitches.
David Kastrup [Mon, 4 Feb 2013 15:38:12 +0000 (16:38 +0100)]
Issue 3153: Let music inside of #{ ... #} originate from @code{location} if set
In particular with regard to point-and-click, it has been a reoccuring
complaint that music originating from #{ ... #} has the #{ ... #}
environment as its origin. This patch will make such music originate
from @code{location} if set to a valid input location.
It would seem somewhat peculiar that #{ ... #} just grabs whatever
meaning @code{location} happens to have at the current lexical level
and runs with it. However, the same is already done for
@code{parser}, so it is not really out of line.