Re: Possible feature request for 'q' shorthand or tie syntax

[David Kastrup]

Marc Hohl <address@hidden> writes:

> Am 23.09.2012 14:40, schrieb James:
>>
>> From a novice's point of view q on the face of it is handy, but handy
>> in the sense that some of the LSR hacks are handy, it just seems so
>> unlike/inconsistent with any of the other commands we use in LP. I
>> don't personally have any feelings about whether q is good/bad, I can
>> see it certainly makes typing quicker, what I was wondering was is the
>> q 'function' holding back and/or preventing other parts of the .ly
>> language from being improved/more streamlined in the lexer & parser
>> work that David is working on.
> Good point. And basically, I support the idea of enhancing the
> \repeat ... { stuff } construct – I merely wanted to show that
> there are situations where the repeat construct would not work.

Just in case people are worrying about q: I have pretty much expunged
all of its involvement with the parser.  It is not a maintenance burden
either.  The code supporting it is quite separate from the parser itself
and runs either when explicitly called, or when music is placed in a
score.  Regarding future parser work, this is a non-issue.

Making isolated durations carry meaning, in contrast, would consist of
one external component similar to q, but it would also heavily involve
the parser itself.  The challenge would not be in what to create in the
music expression either: like with q, something quite straightforward
would likely work fine.  The challenge would be to deal with all the
resulting ambiguities in a manner that makes sense to parser and humans
alike.

-- 
David Kastrup