changes.itely: Mention event-chord-wrap! and \eventChords.

diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index b35850445f77f86ae89c3dfa430e1c923a63ee5f..058a0d5c0edfb29cba348b0f786727ec5b268c2e 100644 (file)
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -114,11 +114,16 @@ representation: Rhythmic events like @code{LyricEvent} and
 @code{NoteEvent} are no longer wrapped in @code{EventChord} unless they
 have been actually entered as part of a chord in the input.  If you
 manipulate music expressions in Scheme, the new behavior may require
-changes in your code.  The advantages of making input and music match
-more closely are numerous: music functions previously worked differently
-when used inside or outside of chords.  Now they are the same, including
-all the possibilities of argument parsing.  You can now use music
-variables inside of chords: a construct like
+changes in your code.  Calling the music function @code{\eventChords} or
+the Scheme function @code{event-chord-wrap!}  converts to the old
+representation; using one of those might be easiest for keeping legacy
+code operative.
+
+The advantages of making input and music match more closely are
+numerous: music functions previously worked differently when used inside
+or outside of chords.  Now they are the same, including all the
+possibilities of argument parsing.  You can now use music variables
+inside of chords: a construct like
 @lilypond[verbatim,quote,ragged-right]
 tonic=fis'
 { <\tonic \transpose c g \tonic> }