Next steps

[Erik Sandberg]

- I have now finished the conversion of engravers, so no non-obsolete
engraver now knows about music.
- I'd like to make translator groups take care of parent/child
relations by themselves, without relying on context. This will
eliminate Context::implementation, and the translator back-end will be
completely separated from contexts and iterators.
- Currently, music->to_event() converts its 'articulations property
from music-list to event-list, which is dirty. I want the parser to
generate 'articulations as an event list directly. A problem here is
that articulation events sometimes are stored in 'articulations of
NoteEvent and sometimes in 'elements of EventChord (<c-.> vs <c>-.)

Plan:
1. let event-chord contain a property 'events with stream-events, and
make the event-chord-iterator send those events.
2. In the parser, convert articulations from music to events, and add
them to the 'events list instead of 'elements.
3. Change music_function_event to operate on events instead of music;
create events directly in parser. I think this is a rather big step,
so I can't plan further yet.

- I'd like to build _f into warning: warning (_[f] (..)) is used in
over 150 places, while warning without _ is validly used in about 10
places. Those places can be changed into
warning ("%s", str).
Plan:
 0. write v_f, analogous to vprintf
 1. introduce a new function warningf, which takes an extra ...
parameter which it feeds through v_f.
 2. convert warning(_()) to warningf everywhere
 3. remove international.hh includes almost-everywhere
 4. junk warning and rename warningf->warning
- Similar for programming_error et al, and scheme variants such as ly:warning
- Suggestion: We could add a Message_type enum, with values {MESSAGE,
WARNING, PROGRAMMING_ERROR, ERROR}, and then add that as an optional
first parameter to message. message ("foo") and message (MESSAGE,
"foo") will be equivalent, while message(PROGRAMMING_ERROR, "foo")
will do programming_error("foo"). The point with message-type is that
it allows us to support infrequent methods such as
Input::programming_error and Grob::programming_error without code
duplication.

--
Erik