On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:
\postfix: c2 d\p is unchanged
/prefix: for music functions like c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
as .clef or .times.
Have to say that I think that there will be greater confusion down to having 3
different ways to indicate a command, than there will be over what entity the
command applies to.
After all, the general form of
\command x
is easy to understand -- \command applies to the entity x, or alternatively to
any group of entities contained in brackets { }. I don't think it's confusing
in general that x could be a note or some other entity. (Are there good
examples where it _is_ confusing?)
The tricky thing is when you have something like,
c'4 \p c' c' c'
... but it's not actually as ambiguous as it seems given that all the commands
of this nature refer to a particular type of musical object (a dynamic or an
ornamentation or similar). So it's not so difficult to appreciate that
"commands of this type apply to the preceding note, others to the entity that
follows".
But if you want to remove that ambiguity, there are other ways to do it:
(1) Make a \command apply to the preceding note if there is no whitespace
separating it from the preceding note, as in c'4\p
(2) In addition to or as an alternative to the whitespace method, make it so
that if a command is preceded by a hyphen - it applies to the previous
note. This is less ambiguous than your above suggestions because it
preserves a common \backslash notation for _all_ commands while having
a clear indicator that the command applies to the preceding note.
So you could do something like:
c'4-. -\p -\< c' c' c'\!
or equivalently,
c'4-.
-\p
-\< c' c' c'\!
(3) For commands that expect to apply to the preceding entity but which are
in ambiguous form, e.g. c'4 \p, emit a warning or error asking the user
to put an unambiguous indicator in the score, i.e. a preceding - or
lack of preceding whitespace, or a following set of brackets { }.
(4) For commands that expect to apply to the _following_ entity but which
follow an earlier entity without whitespace, emit a warning asking the
user to either remove the ambiguity with a preceding - or to correct
the error by adding whitespace before the command.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
