Werner LEMBERG <w...@gnu.org> writes: >> Come to think of it, the least invasive strategy might be hybrid: >> one does not try tracking the relation between q and the preceding >> chord at all but leaves it in the input side. \relative just throws >> away the existing contents of any q it encounters and replaces it by >> the chord it considers as the previous chord itself. If it has no >> such chord available, it keeps the current one and outputs a >> warning, like the input-based q would without a reference. > > Yes!
Actually more like "no" until Issue 2070 gets passed. If there is no distinguishable difference between chords and non-chords in the music expression, \relative would have a hard time determining a "previous" chord. One could try going by "more than a single note or a single note with articulations on it" but who is going to write a convincing manual entry for that sort of thing? Or mark any chord EventChord with a field this-was-really-entered-as-a-chord-so-relative-might-consider-it-for-q. Or check whether the origin of EventChord and first entry suggest chord entry. Lots of ways to get unreliable results and/or awkward code here. My personal way of going at it would be to get 2070 passed with the default compatibility option _off_. Then at some point of time, implement \relative with the last-chord-I-saw behavior. And only if enough people complain with despair in their eyes and $$$ in their hands, actually bother about the combination of compatibility option _on_ _and_ relative _and_ q. After all, they will only need the compatibility option when they mess with EventChords themselves or got hold of code that does and that wants updating anyhow. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
