lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GLISS] differentiating pre/post/neutral commands


From: David Kastrup
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Date: Mon, 17 Sep 2012 21:01:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Mathieu Huiban <address@hidden> writes:

>> On Thu, Sep 13, 2012 at 2:27 AM, David Kastrup <address@hidden> wrote:
>>
>>> I don't think that distributing ( and ) between standalone event and
>>> post-event respectively is a concept that will carry the day
>>> sufficiently to be given a chance at a comeback.  It would make
>>> (c (d) e)
>>> visually confusing.  While neither the current
>>> c( d)( e)
>>> nor the standalone event version
>>> (c )(d )e
>>> will win a price for prettiness, they both beat (c (d) e) in conveying
>>> meaning rather than looking pleasing.
>
> What about considering ( as a post-event and ) as a standalone event ?
>      c( )d( )e  is symmetric and very clear.

Huh.  It would mean that you could put directionals ^ and _ before (
where you need them too, without needing to extend their meaning to
non-postevents.  The underlying music expressions would suffer from
asymmetry: this might make programmatic manipulation somewhat less
convenient.

But one could place things like s4( ) into parallel music without
needing s1*0 or similar at the end to anchor ).

For starting from scratch, this idea would certainly have appeal.  Like
Han-Wen mentioned previously, when one really wanted to go for it, it
would make sense to look at the effect this would have on the source of
a large complex piece.  I might at occasion take a look at what it would
entail to do this switch from user code: at the moment, I think that the
respective syntactic categories are hardwired into the parser which
makes fooling around with such ideas harder than necessary.

But it does indeed look like something that could be an interesting
tradeoff between visual and functional symmetry.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]