As far as I can see, there is very little hope for LilyPond making the right
decision about this chord entered in note mode. The first note is not the
root of the chord, so it would require substantial computation time to try
to identify the chord properly (and there's no guarantee that the proper
chord identification is unique, based upon just the set of notes). I'm not
even proposing to *try* to attack this problem.
As far as my current plan goes, this chord would be identified as a D chord
of some type, as is the current practice in LilyPond. If the root and
inversion have not been identified (which they will not be when chords are
entered in note mode), then the first note in the chord is identified as the
root, which gives weird chord names.
Rendering chords written as chord names (des2:m5/d) would of
course be simpler.
Yes, and that functionality is not currently as strong as we'd like it to
be, I think. That's what I'm proposing to rework, when I get the chance.
I agree with this.
Couldn't there be an 'automatic chord mode' and an 'mode which just
display the chord names', not the notes?
What do you mean by 'automatic chord mode', and 'mode which just displays
the chord names'?
We currently have a context which just displays the chord names. It's
called ChordNames.
We *don't* have a mode which just *accepts* chord names. We have a mode
(chord mode) that accepts a root, a modifier, a maximum chord step, and can
add, remove, and modify chord steps, including moving a pitch to the bass or
adding a pitch to the bass. This mode does not use "chord names" per se,
because chord names tend to be ambiguous (all one needs to do is look at the
variety of names for a given chord as defined by a set of pitches to see
this). Parsers tend not to deal well with ambiguities, so what we have is a
completely non-ambiguous input format. Someone who understands the
chordmode input format can look at a chordmode expression and determine
exactly what pitches are intended to be included in the chord.