Re: \relative proposal: putting absolute pitches anywhere within \relative block using @-sign

[David Kastrup]

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