Symmetric slur input (was: [GLISS] differentiating pre/post/neutral commands)

[David Kastrup]

David Kastrup <address@hidden> writes:

> 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.

For a testbed for this, check out Issue 3487
<URL:http://code.google.com/p/lilypond/issues/detail?id=3487>.

-- 
David Kastrup