[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary of \relative { q } ... analysis.
From: |
David Kastrup |
Subject: |
Re: Summary of \relative { q } ... analysis. |
Date: |
Fri, 27 Jan 2012 14:20:23 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) |
Carl Sorensen <address@hidden> writes:
> As I've been watching this thread, the idea came to me that perhaps we
> ought to do away with q and replace it with a naked duration.
Same issues as with q regarding the lifetime of input, so this
suggestion is more or less orthogonal to the problems I discussed except
for picking option 1.
> So what if a naked duration just meant to repeat the previous chord or
> note, with the given duration, i.e.
>
> {c4 d e 8 <c e g>8 4}
>
> Would be equivalent to
>
> {c4 d4 e4 e8 <c e g>8 <c e g>4}
Spaces are not relevant in the parser (and since $x needs to get
separated from further input by a space, this is actually not just a
technicality). So the above input is already valid and equivalent to
{c4 d e8 <c e g>8 4}
I think that this is a bit of a drawback... Now you might want to
change this into "naked durations _not_ possibly belonging to the
previous input element". In my opinion, we have more than enough
ambiguities in the LilyPond grammar already. I don't really like that.
> It also makes the syntax work on both chords and non-chords, which
> seems to me to be a reasonable design objective.
Uh, the previous discussion revolving around q has made quite explicit
that people don't _want_ that, and q was explicitly changed at one time
in order to not do it. It is common to have a fat chord (cumbersome to
enter) followed by a brief monophonic phrase of one or two notes, then
the same fat chord again. Involving non-chords does not actually save
typing (c or q is pretty much the same effort).
> It treats durations and pitches in the input stream in an equivalent
> manner. It has the potential downfall of making the input stream more
> confusing to read.
For humans _and_ LilyPond.
Let's not get there.
--
David Kastrup
Re: Plans for changing chord repeat implementations, David Kastrup, 2012/01/28