The function loc_on_music has been renamed to loc_on_copy and has been
changed to create a copy for a number of different expression types.
This makes \xxx.yyy behave similar to \xxx-yyy with regard to copying
the original expression in most cases, and it also helps with default
arguments of music/void/event/scheme functions of more types than just
music.
Mark Knoop [Tue, 2 Aug 2016 09:26:46 +0000 (10:26 +0100)]
Doc: CG update Indenting with vim section
Suggestions for .vimrc did not produce correct indentation of C++
code, and also included personal and irrelevant settings such as
statusline and incsearch. I have replaced them with the settings
in the GNU GCC Wiki which do correctly indent. Also changed
suggested Scheme settings to use setlocal, and added a section of
settings for Texinfo files.
David Kastrup [Thu, 21 Jul 2016 09:51:44 +0000 (11:51 +0200)]
Issue 4941/1: Optional fraction after \afterGrace command
\afterGrace had its fraction determining the position of the aftergrace
notes hardwired to be read from the parser variable afterGraceFraction.
This change here allows for optionally specifying it right as the first
argument of the \afterGrace command.
Issue 4938 (2/3) Refactor handling of MIDI control changes
Handle the MIDI control value initialization from context properties
(Staff_performer::new_audio_staff), control value changes
(Midi_control_function_performer::announce_function_value_change), and
value conversion for output
(Midi_control_function_value_change::to_string) in the new
Midi_control_change_announcer class.
All MIDI control changes are now encoded using
{Audio,Midi}_control_change items. This change makes the old
{Audio,Midi}_control_function_value_change classes obsolete.
When optimizing, GCC now assumes the this pointer can never be null,
which is guaranteed by the language rules. Invalid programs which
assume it is OK to invoke a member function through a null
pointer (possibly relying on checks like this != NULL) may crash or
otherwise fail at run time if null pointer checks are optimized
away. With the -Wnull-dereference option the compiler tries to warn
when it detects such invalid code.
If the program cannot be fixed to remove the undefined behavior then
the option -fno-delete-null-pointer-checks can be used to disable
this optimization. That option also disables other optimizations
involving pointers, not only those involving this.
As a consequence, we cannot call a member function on a prospective null
pointer (which actually is a bad idea for a number of other reasons,
like when anything tries accessing the vtable) and then try sorting out
the condition in the routine itself.
This problem was first observed with Fedora 24. The Ubuntu GCC6
prerelease does not show this problem; presumably the respective
optimization has been disabled in the Ubuntu/Debian packaging because of
affecting other programs.
Commit-message-by: David Kastrup <dak@gnu.org> Signed-off-by: David Kastrup <dak@gnu.org>
David Kastrup [Mon, 4 Jul 2016 08:08:41 +0000 (10:08 +0200)]
Issue 4917: Remove some set_location calls from parser
Older versions of Bison (current is 3.0.4) had problems assigning
location data to rules with empty production, possibly related to the
definition of YYLLOCA_DEFAULT when N is zero.
This lead to several workarounds in the code base. A number of them
dropped through the floor in the course of refactoring without
apparent problem, and the original problem does not appear to be
reproducible with the current versions of Bison.
This removes the remaining instances. Should the original problem
reoccur at some point of time (or with some versions of Bison), it
would be noticeable as bad point-and-click messages and/or error
messages with bad location data.
Issue 4907: Midi_walker::do_start_note: skip ignored notes in stop_note_queue
For each semitone pitch value, stop_note_queue is likely supposed to
contain at most one Midi_note event with its "ignore_" flag set to
false, and the comparisons between notes of equal semitone pitch to be
always done between the input note and this unique queued note that is
not (yet) being ignored.
If notes which are already being ignored are not skipped in the loop,
the task of raising the "ignore_" flags for note events of equal
semitone pitch (overlapping in time) which stop before the maximum
stopping time of these notes may, due to breaking out of the loop,
fail to work if the queue grows to contain three or more notes of equal
semitone pitch, leading to the emission of premature "note off" events
for this pitch, as demonstrated, for example, in
<http://lists.gnu.org/archive/html/bug-lilypond/2016-06/msg00042.html>.
David Kastrup [Sat, 2 Jul 2016 23:40:04 +0000 (01:40 +0200)]
Issue 4914/2: convert-ly rule for removing Output_property_engraver
It's highly unlikely that users will redefine the Score context from
scratch, so the convert-ly rule just removes every occurence of
Output_property_engraver from user source. Obviously, when running the
rule on the LilyPond code base, we will need to fix up the Score
engraver manually to retain the Output_property_engraver .
David Kastrup [Sat, 2 Jul 2016 23:37:15 +0000 (01:37 +0200)]
Issue 4914/1: Move Output_property_engraver to Score level
This has the advantage of needing only one instantiation of the engraver
and not having \applyOutput mysteriously refrain from having an effect
in contexts without Output_property_engraver .
Due to the hierarchical nature of acknowledgers, acknowledgers in lower
contexts will now get to see the grobs before applyOutput has done its
work. However, grobs are still unfinished (except for type, properties
initialized via context properties and cause) at the time they are
announced, with other details only getting filled in by the engraver
after announcement, so the potential for trouble seems low.
Acknowledgers should usually just register a grob (or write grob data)
with any actual reading of grob data occurring at the end of the
timestep instead or in the process-acknowledged phase.
David Kastrup [Thu, 30 Jun 2016 15:26:01 +0000 (17:26 +0200)]
Issue 4911/3: Don't treat context modification identifiers special
This requires using \with before context modifications like
\RemoveEmptyStaves in order to make the syntax get along
with fewer special cases and exceptions.