David Kastrup <[email protected]> writes: > Mathieu Huiban <[email protected]> writes: > >>> On Thu, Sep 13, 2012 at 2:27 AM, David Kastrup <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
