Re: "loco" after ottava

[Thomas Morley]

Am Sa., 3. Dez. 2022 um 15:06 Uhr schrieb Jean Abou Samra <jean@abou-samra.fr>:

> -S only shows commits that changed the number of occurrences
> of the pattern, which is useful to find out when something
> was added or deleted. To find all the times a line containing
> the pattern was changed, use -G instead.

Thanks again
>
>
> > Anyway, "Add internal/external distinction to -d flags" is
> > https://gitlab.com/lilypond/lilypond/-/merge_requests/1231
> >
> >
> > That said, I researched a bit more about "check-internal-types".
> > and found we have:
> >
> > lilypond --help
> > lilypond -dhelp
> > and actually
> > lilypond -dhelp-internal
> >
> > The latter is undocumented as intended by one of the mentioned
> > patches, but shows "check-internal-types"
> >
> > I agree with separating internal/external options and not explicitley
> > documenting internal ones.
> > But not to document at all how to reach the internal ones is too much, imho.
>
>
> You can see it in "lilypond -dhelp".

Yep, that's how I found "help-internal", though I'd call that "well hidden" ;)

>
>
> > I'd vote for documenting help-internal in "Application Usage".  With a
> > short hint, something at the lines of:
> >
> > help-internal bool
> >    If bool is #t, display options for internal usage. Default: #f.
> >
> > Opinions?
>
>
>
> If the purpose of internal options is to be hidden
> from the user, why add them back in the manual?
>
> What do you find -dcheck-internal-types useful for
> as a user? *If* it has functionality useful for
> non-developers, that functionality possibly shouldn't
> be internal in the first place.

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.

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.

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

Cheers,
  Harm