Thomas Morley <thomasmorle...@gmail.com> writes: > If I understand correctly your proposal is that > > \language "english" > > m = { ff' f' fs' } > > \m > \follow fs \m > \follow ff \m > > will be printed different.
Well, it would be more likely \follow <fs> \m \follow <ff> \m here. That would be _one_ basic idea of implementation. This one would mark non-explicit pitches c d e f g a b specially so that \follow can distinguish them from cn dn en fn gn an bn. The "unspecificness" would be kept in the music. How and when should it get resolved when there is no \follow involved at all? What happens if we \transpose music containing unspecific pitches? Another implementation would be to keep the music expressions unambiguous and instead use a different notename language variant, perhaps invoking it like \language \key a \major "english" which will redefine all "unspecific" note names in correspondence with the key. Or maybe just \languagekey a \major That will basically make the typical document be written in a large variety of notename languages which makes for a lot of fun when editing and/or copy/pasting motives around. In particular, editing functionality like that of Frescobaldi (which may be asked to transpose passages for the user) will become unreliable, and the inability of an external tool to figure out the right pitches without context of course is matched by a similar potential for confusing users. > In my thinking that's absolute crude. > Though, obviously there are other opinions about that. > > Patches are always welcome. But one needs to be warned that they may meet resistance to acceptance, so there is some sense in figuring out the other developers' opinions before investing a lot of work, at least if one's ultimate goal is the inclusion as an integral part of the standard LilyPond distribution. A somewhat smaller but comparable can of worms is \relative mode. A frequent topic on the mailing list is "how do I make my music functions work in \relative mode?" and often answers are not straightforward. Many LSR snippets work only either in absolute mode or in relative mode, and not necessarily reliably so. So it is pretty much established that the music-based approach comes with a healthy load of problems, and the input language based approach, while condensing most of the problems in one place, makes source code management a headache because each source code passage comes with its own associated input language. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user