Am 14.09.2012 19:10, schrieb m...@mikesolomon.org:
On 14 sept. 2012, at 19:56, Phil Holmes <em...@philholmes.net> wrote:
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?
+1
What I'd like to add: some kind of style files (as Janek proposed at
Waltrop) similar to
LaTeX packages.
If I write music for guitar, I need other settings than for a SATB choir.
Enabling them by
\include "guitarSettings"
\include "choirSettings" \with { \SATBoptions }
or something similar would improve the situation a lot without
rethinking the whole syntax in detail.
I completely agree with Phil. Reading the user list, it is comparatively rare that people seem to get hung
up on pre-and-post stuff. What'd really help is "did you mean to do thing X?" or "thing Y
will have no effect - consider doing Z" or even a "?" token one can put before or after an
object to have help messages printed to the logfile as well as detailed information about the command in
question and what it applies to.
+1, too.
Regards,
Marc
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel