LilyPond Contributor's Guide: 13.5.1 Specific GLISS issues

### 13.5.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

#### LilyPond — Contributor’s Guide