Hi, the default chord repeat code contains stuff like
;; If previous-chord has an length property, then it means that it ;; has been processed by a music iterator. In other words, the chord ;; has been memorized from an other music block, which is certainly not ;; what the user has intended, as anywy the result will be buggy. ;; In that case, raise a warning. Ok, this is all sort of madness. Music functions are _free_ to change their arguments and quite a number of them do, not just \relative. It does not do to keep just a pointer to a chord since by the time one actually uses it, it can be trashed in a number of ways. Having a music iterator run over it is just one of many possibilities. Copying the whole chord just because it might get used is expensive and unnecessary. _If_ we try doing this in the parser (and I don't see a really good other place that is reasonably convenient for the user), we should not copy the chord, but just the list of pitches. After all, this is what the documentation of q as far as I can see _claims_ is copied. There is the added complication that a chord can contain more than just pitches: it is possible to have drum types instead. And of course anything sneaked in as rhythmic events via music functions. Of course, when running through \relative or a similarly applied music function that runs over a whole expression in one go would be able to work just with pointers. I have taken a look at the regtests and rest of LilyPond. The only cases where q is being used is either inside of \relative or explicitly for testing absolute mode. So I lean towards removing repeated chord tracking from the parser altogether. You would need to explicitly run a music function for doing the last chord substitutions. to_relative could be made to set a flag when encountering a repeated chord, so that \relative would automatically run the repeated chord substitutor at the end when it was required. That would mean _no_ problems with chords changing under the parser, _no_ need to extract pitches or other information just-in-case, no input syntax change when used simultanously with \relative, and no performance impact when the user does not actually use that feature. It would also reopen the door to extract more than just pitches. The bad news is that absolute pitch friends would have to call the \q function (any better name for it?) explicitly. Since q is an input convenience, and relative pitch is also an input convenience, I don't think that there would be much of an affected user base. Machine-generated output would rarely have to use q. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel