On 1 May 2018 at 05:32, David Wright <da...@lionunicorn.co.uk> wrote:
> On Tue 01 May 2018 at 00:15:24 (+0200), David Kastrup wrote: > > David Wright <da...@lionunicorn.co.uk> writes: > > > > > AFAICT the important exception that was introduced with naked > > > durations was that c 4 notates a single note whereas c4 4 notates two. > > > > There was no "exception" introduced. c 4 always indicated a single note > > and c4 4 previously was invalid input. > > There's no guarantee that a new user, or a user who has only set eyes > on notation like c4, will make the correct interpretation of, say, > c 4 4 4 when they first encounter it. Without looking it up, there's > no way of knowing whether LP would treat it as three notes or four. > > So if a new user thinks that a naked duration always specifies a note > they're likely to see the first duration in c 4 4 4 as an exception. > The ambiguity didn't arise before as there was no possibility of > seeing such a string (without throwing an error). > > Of course it wouldn't look like an exception to you or anyone who's > already familiar enough with LP syntax. Absolutely!!!!! And the problem is not really when "you see". It's when "you write". A learnear like me, after discovering the syntax "c4 4 4" will use with no problem like this: d4 c 4 4 discovering that it engraves d4 c4 c4 But starting from the moment that you say that pitches and durations can be separated by a space I don't see any way to prevent this thing. But does human would ever separate pitch from duration and write "c 4 d 4 e 8"? If not, maybe we could output some sort of warning when the code contains spaces between pitch and duration? > But the OP's doubts concerned > learners and that's why my views diverge from theirs: I would prefer > a decision (concerning durations applying only to pitches) based on > power users rather than learners. > Yes, I found this a perfectly reasonable choice! But I have no idea if it is correct :) g.
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
