nothingwaver...@gmail.com writes: > I can't help but suspect that several long-time unsuspecting users in > the habit of writing \relative { ... }
This has not been documented or recommended for quite a few years. > and expecting the first note to be relative to c' will upgrade to a > new version of lilypond or use someone else's machine with the newer > version and write \relative { c ... } in a new project, expecting > middle C to be printed and then be baffled at why LilyPond silent > prints tenor C instead with no explanation. For existing projects, there is convert-ly which will convert into \relative c' automatically. For new projects, declaring a new version number without reading the Changes file is a gamble. We have several other incompatible changes as well. The change to \relative was suggested to be accompanied by an extensive conversion of the documentation. This will at least provide a considerable hint about a change in that area. There is always the question about non-upwards compatible syntax changes. Why change instead of adding something new? a) it serves an existing function for which it makes no sense to offer competing interfaces b) it affects the workflow of the user c) it makes better sense than the previous function Now if we take a look at this proposal, it is a no-nonsense interface to relative notation: a) it does not require a non-note pitch to be specified b) there is no note-name or octave implicitly or explicitly involved that is not actually being played c) there is no octave specification involved that is not either a relative specification or corresponding to an actual note being played. d) there is no visual clutter from new constructs or any element with a meaning that is not already known. e) there is no redundancy requiring a user choice reflected in the music > I feel that the original proposal, as specified elsewhere, violates > the principle of least surprise for existing users starting new > projects (not using convert-ly) with the new LilyPond. How large will the damage be? A quarter of an hour? How much time will they be spending in future with LilyPond? How often do we release a major new stable release? The main problematic time will be when they are using an older version of LilyPond while consulting examples and online documentation for a newer one. That can lead to befuddlement of more than just a few minutes, and this is not exactly unheard of. If we want to clamp down on the impact of that time window, we can make the change rather silently at first: \relative without reference pitch has not been given much exposure in the last few years. If we change its behavior and don't give it much publicity, few people will notice and/or actually use it. Then we do the large change in LilyPond's codebase for actually _promoting_ this change in 2.20 or so, and hopefully not all too many people are still with 2.16 while consulting 2.20 documentation. I've not been convinced by the arguments for considering this functionality undesirable out of the box. And the incompatibility to older versions when upgrading is not really much of a concern since the variant without reference pitch has been basically deprecated for quite long. The incompatibility with older versions when _not_ upgrading is likely indeed problematic due to the "I get my documentation from search engines" mentality, and it can be defused by reserving the big publicity for later. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user