[ << Administrative policies ]	[Top][Contents][Index][ ? ]			[ GNU Free Documentation License >> ]
[ < Grand LilyPond Input Syntax Standardization (GLISS) ]		[  Up : Grand LilyPond Input Syntax Standardization (GLISS) ]	[ Unsorted policies > ]

14.6.1 Specific GLISS issues

• add regtests for every piece of syntax (not one-command-per-file, but making a few files which, between them, use every single piece of syntax.) This is a great test for convert-ly.
• should GLISS cover suggested conventions? (indentation, one-bar-per-line, etc – the kind of stuff we list for the lilypond formatting in the docs ?)
• how much (if any) syntactic sugar should we add? i.e.

    \instrumentName #'foo
  % instead of
    \set Staff.instrumentName
  

  ? Carl: maybe yes, Neil: no. (for example, it fails for pianostaff)

• the values that are used as arguments to common used overrides. Sometimes they are a symbol (e.g. #’around), sometimes a predefined variable referring to a Scheme value or object (e.g. #LEFT, #all-visible ). The main trouble is that for novice users it is not clear when there should be an apostrophe and when not.
• When do we need -\command and when is it just \command ?
• Command-line options to the lilypond binary. -dfoo counts as a tweak; we won’t be trying to pin those down.

• \layout {
    \context { \Score
  % vs.
  \layout {
    \context {
      \Score
  

• If would be pedagogically simpler to realize this difference if the syntax was separate if you define a context from scratch (as is the case with \RemoveEmptyStaffContext) or if it’s defined by adding onto an existing context. For example, a syntax like

  \context{
   % Copy the current settings of the Staff context:
   \use Staff
   % do whatever additional settings
  }
  %%% could be used to distinguish from
  \context{
   % Take settings from a variable:
   \Variable
   % do whatever additional settings
  }
  
  %%% and
  
  \context{
   % Start from scratch:
   \type ...
   \name ...
   \consists ...
   ...
  }
  

• Capitalization of identifiers: \VoiceOne ?

• %%% Allow
  { music expression } * 4
  %%% instead of
  \repeat unfold 4 { music expression }
  

  ? patch here:

  http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00467.html

• Personally, I find it easier to understand when there’s a repeated 8 in the half-bar position; it’s much easier to see that you have two groups of 4:

  c8 c c c c8 c c c
  %%% instead of one group of eight:
  c8 c c c c c c c
  

• trivially simple bar-lines:

  c1 | c1 |

  encourage, allow, or discourage, or disallow?

• indentation of \\ inside a {} construct.
• barline checks at the end of line should be preceded by at least 2 spaces? barline checks should line up if possible (i.e. if you can use less than 4, 8, X empty spaces before a barline check to make them line up?)
• Why doesn’t \transpose respect \relative mode?
• on \score vs. \new Score

  But in the light of a consistent syntax and semantic, I see no reason (from the users POV) to disallow it. After all, the real top-level context is a \book {}, isn’t it, and I don’t see a point in disallowing a \new Score construct just like \new Staff.

  From a syntactical POV, I see the following pros for \new Score: - You can write \with { ... } for every other context but \Score, which (for consistency) should also work with \new Score. - When there’s a \new Foo Bar, there’s also a \context Foo Bar, which makes the same as a parallel instantiation of all Bar’s. - [Quoting Rune from http://www.mail-archive.com/lilypond-devel@gnu.org/msg14713.html "I know that the \score-statement is a syntactical construct, but I think it would be nice to hide this fact from the users. I think we could make the use of score-block much more intuitive if changing the syntax to \new \Score and adding an implicit sequential-statement to the score."

• Discussion on http://code.google.com/p/lilypond/issues/detail?id=1322 about \new vs. \context.
• Let users add their own items to the parser? comment 11 on: http://code.google.com/p/lilypond/issues/detail?id=1322
• should engravers be pluralized (note_heads_engraver) or not (note_head_engraver) ?
• should we allow numbers in identifier names? Issue: http://code.google.com/p/lilypond/issues/detail?id=1670
• should we officially allow accented characters? in general, how do we feel about utf-8 stuff?
• for the sake of completeness/simplicity, what about *disallowing* the "one-note" form of a music expression? i.e. only allowing stuff like

    \transpose c d { e1 }
    \transpose c d << e1 >>
  

  and never allowing

    \transpose c d e1
  

• What should be the officially encouraged way of writing music for transposing instruments? Maybe it should be simplified? See http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00130.html

---

[ << Administrative policies ]	[Top][Contents][Index][ ? ]			[ GNU Free Documentation License >> ]
[ < Grand LilyPond Input Syntax Standardization (GLISS) ]		[  Up : Grand LilyPond Input Syntax Standardization (GLISS) ]	[ Unsorted policies > ]

<< Back to Documentation Index

LilyPond — Contributor’s Guide