[GLISS] - alternative viewpoint

[Phil Holmes]

OK - so there's been a lot of discussion of pre- and post-fix, and a load of 
other stuff I don't understand.So I had a think about what it is about 
lilypond syntax that p**s me off.  And I concluded that it's nothing to do 
with whether we write c4 /p for a quiet crochet c, as opposed to /p 4c.  I 
really don't care.  When I was a tyro, I just read that and accepted it. 
What does get me more concerned is how hard it is to find some of the 
correct ways of tweaking output.  Using voice.SomeValue (or is it 
Voice.someValue) when it should be staff.Somevalue (or was it 
Staff.someValue) frequently results in no change to the output.  And is it 
\override or \set?  And \revert or \override back to something else.  And 
finding what comes after the \override staff.Something - is it ##f. or #'4 
or 4 or { 4} or what?

If you follow what is asked on -user, it's this stuff that causes confusion, 
not pre- or post-fix.

Now - I have no idea if this is possible or not, but when I put some of 
these complex overrides into my converter, the commands to the converter use 
a C-like syntax.  For instance, I've written a feature that allows the 
converter to scale durations:

scaleDurationsOn(n,m)

I personally think that providing more of these simple syntax features would 
make it much easier for the average user: we do have a few shortcuts of this 
type: for example:

autoBeamOff = \set autoBeaming = ##f
melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy) 
'Bottom)

Why not focus on making the slightly complex part of Lilypond much simpler 
(not the very complex, like customer scheme functions - if you can do that, 
you don't need help)?  And getting rid of case-sensitivity in a lot of this? 
And providing error messages when an override has no effect because it was 
at the voice context and should have been at staff?

--
Phil Holmes