Re: Issue 1110 in lilypond: Wrong octave of repetition chord with \relative and #{ #} syntax

[David Kastrup]

Werner LEMBERG <address@hidden> 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