Trevor Daniels <t.daniels <at> treda.co.uk> writes:
> So what problems do the users have, exactly? We should address this
> question first. Janek apparently has his list, which would be a good start.
> But we should not invent problems where they don't exist. I've probably
> read every email on the user list for the last 4 years, and inconsistent
> parser rules have not figured prominently.
I generally agree. But I also have sympathy for the desire to first clarify
some broader questions -- such as, in which /direction/ to straighten out the
parser when user problems require changes to the parser.
I understand that past catering to concrete user needs has gradually resulted
in a messy syntax, very difficult to import into other systems (musescore
tried), which also makes it harder to cater to some current user desires.
The readable \tempo "Adagio" 4. = 30~40 lacks the delimiters that most
computer-entry formats require, which made it unusable in a \midi block for
many years -- because LilyPond accepts decimal-point numbers in the midi block,
for probably another good reason. Without requiring delimiters it is hard to
specify exactly when LilyPond should read 4. as a duration, and when as 4.000.
One situation where LilyPond /does/ require delimiters is \chordmode { c4:8 }
The broad question is: Require delimiters to clarify context (for users,
LilyPond, and software importing LilyPond) -- more or less?
I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not
relative to key signature. We could accommodate this by re-defining pitch
names upon seeing
{ \keyAffectingEntry \d\major ... }
so that f means F-sharp and we have to type fn for F. (This requires pushing a
pitchname-table on a stack for every nested level of {} or <<>>)
Digits-in-identifiers is an often-requested feature that seems it should be
easy (if we are willing to require a space in \skip 4 and \tuplet 2/3). The
trouble is that I cannot use vn1 = {..} without either telling the lexer that
"vn" will never by a note-name in any language, or requiring some structure to
specify when music functions are done: \afterGrace ces2 des8 vn1 = c2.
I used to use \cueWhile, but then switched to your \cueDuring with the extra
parameter, and had a few mysterious errors when I forgot which one had the
extra parameter. David of course suggested I make a \cueDuring with an
optional parameter. Either way, the poor guy writing the .ly importer in
Musescore has no hope to keep up.
The broad question for these three is: Syntax that changes depending on the
definitions of the functions in the input -- good or bad?
My prediction is that LilyPond will keep its syntax that requires knowledge of
the definition of functions to be parsed correctly, thus un-importable by other
software,
.. and that LilyPond will keep its freedom from delimiters, with David pulling
LilyPond further toward scanning the input independent of context.
Others certainly frame the broad questions differently, and probably see
additional broad questions. I think we need to allow some time for compromise
on these balances between philosophy and practicality.
Many of the specific items on the GLISS list concern names of things, which I
think is independent of the broad questions, but will solve some real
problems. I was quite puzzled by a question on -user yesterday, until I
realized he had confused the purposes of Staff.keySignature versus
Staff.KeySignature.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
