Re: `@lilycode` for highlighting LilyPond code snippets

[Werner LEMBERG]

> ```
> blabla @lilycode{\relative { c'2 e }} blabla
> ```
> 
> Example 2:
> 
> ```
> blabla
> 
> @lilycode
> \relative { c'2 e {
> @end lilycode
> ```
> 
> While the use for the block command version (`@lilycode ... @end
> lilycode`) should be clear, the main question is what policy we are
> going to recommend for the inline version: I suggest to apply
> `@lilycode` only if highlighting has some useful effects, which
> means that in most cases it should be rather *not* used because
> inline code is very short.  Has anyone a suggestion for a better
> formulation, or better constraints?

Another issue has come up in the discussion of MR 1753, namely whether
`@lilycode` should actually be named `@lilypond[code]`.  There are
four proposals, and I would like to hear opinions.

  https://gitlab.com/lilypond/lilypond/-/merge_requests/1753

(0) Two preliminaries.

    * The discussed command can be used both inline

       ```
       @lilypond{...}
       ```

       or as a block environment

       ```
       @lilypond
       ...
       @end lilypond
       ```

    * The discussed command only exists for `lilypond-book`'s Texinfo
      backend; it is an internal command only to be used for
      LilyPond's documentation.

(1) For orthogonality and consistency, use `@lilypond[code]`.

    Pro: The command reuses a lot of the snippet infrastructure that
    is already used behind `@lilypond`.  It implements syntax
    highlighting in the same way as the `verbatim` option.

    Cons: More characters to type, also using `[` and `]`, which are
    hard to use on non-US keyboards.  See also the 'pro' section of
    (2).

(2) Stay with `@lilycode`.

    Pro: The command is actually a variation of `@code`, not
    `@lilypond`, thus its name; it's rather short and easy to type;
    you can use even invalid LilyPond syntax in its argument; it won't
    collide with `lilypond-book`'s `--filter` command line option.
    There also exists the command `@musicxmlfile`, which is a
    precedent because it doesn't use the 'lilypond' namespace.

    Cons: It uses the 'lily' as the namespace, which is not consistent
    with the already existing commands `@lilypond` and
    `@lilypondfile`.  There is already the precedent of
    `@lilypond[fragment]`, which also accepts invalid LilyPond code
    (because it needs some fixed boilerplate code before and after).

(3) Use `@lilypondcode`.

    Pro: This fullfils the 'lilypond' namespace issue and thus blends
    in to existing commands.

    Cons: More characters to type, which is tedious if you have to
    write a lot of documentation.

(4) Introduce short aliases `@ly`, `@lyfile, `@lycode` (or
    `@ly[code]`).

    Pro: Short.

    Cons: Might collide with user-defined Texinfo macros.

Please comment!


   Werner