Re: "loco" after ottava

[Jean Abou Samra]

Le 03/12/2022 à 15:41, Thomas Morley a écrit :
> Granted, if I use -dcheck-internal-types I mostly wear my developer
> hat. But sometimes I use it even for huge custom codings as part of
> debugging processes.



Why? What does it catch?

In my view, warnings about a property being set on a grob
that has no interface for it are nothing you need to care
about as a user. This check merely helps ensuring that the
IR remains complete when developers add features. I see no
reason why it would be bad to set a property on a grob even
if it doesn't have an interface declaring this property,
if you set another property in this grob to something that
will read it. For example, it's a common pattern to set
stencil to #ly:text-interface::print and text to some markup,
even on grobs that don't have text-interface. That's fine.
On the other hand, if you change the stencil default for
a given grob to #ly:text-interface::print in the source,
you shouldn't forget to add text-interface to that grob.

The other thing check-internal-types catches is callbacks
returning a value of the wrong type, but I have never
encountered this case AFAIR.


> That said, we not only want to attract new users but new developers, too.
> Some of them may not be experienced programmers but musicians with
> some interest in coding (like me).
> Playing hide and seek with them may not be appreciated...
> We could place the info about -dhelp-internal in CG, but that would
> spread "help-infos" over two manuals.
> Thus I prefer my suggestion above.


Consider me indifferent.



> Also, hiding internal things from mere users would arguable lead to a
> very small IR.
> We could just delete all internal grob and context properties.
> Which would be a very bad thing, if I think back how often I used them...



I view internal properties and internal options differently.
LilyPond has a blurry line between users and developers.
"Internal" for properties draws a line between advanced users
and other users. Internal properties are thing that you can
use if you know how to use them from Scheme and (like many
Scheme things) accept the lesser degree of stability that
you can expect from them. In contrast, for me, the options
currently listed as "internal" really only make sense if
you are a contributor working on the source, e.g.,
debug-gc-assert-parsed-dead catches low-level garbage
collection problems, debug-parser is only useful if you
know your way around the Bison / C++ parser, etc.


Jean

OpenPGP_signature
Description: OpenPGP digital signature