[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doc: LM - correct @example for Tweak Command (issue 140630043 by add

From: James
Subject: Re: Doc: LM - correct @example for Tweak Command (issue 140630043 by address@hidden)
Date: Mon, 15 Sep 2014 17:52:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1


On 15/09/14 16:04, address@hidden wrote:
On 2014/09/15 13:56:55, J_lowe wrote:
On 2014/09/15 07:26:45, dak wrote:
> File Documentation/learning/tweaks.itely (right):
> Documentation/learning/tweaks.itely:453: \tweak
> @address@hidden address@hidden

> It is somewhat disconcerting that the Info page rendition (rather
> than the HTML pages) will read LAYOUTOBJECT and LAYOUT-PROPERTY
anyway, as
> that's the way @var placeholders are formatted.  Still, I think
that's probably
> the best we can do.

Would using @code{} be better - I've never dug that deep to know the
in terms of that it looks the same in PDF output?

No, @code would insinuate that this is to be used verbatim.  I think
that HTML and PDF will be pretty ok here.  It's just the info backend
that no longer reflects the Camel-and-whatever-casing.  But that does
not make the rendering wrong, just less suggestive regarding what the
result will likely look like.

> You put in address@hidden instead of @var{value}.  I think we are not
> consistent regarding that, but it is worth mentioning that something
like (see
> Learning Manual in Tweaks)

? This *is* Learning Manual in tweaks.

Yes, but different place.

If you look at the example above it is in
the TexInfo format of

...So the simple form
of the @code{\tweak} command is

\tweak @var{layout-property} address@hidden
@end example


So I just copied that.

Looking through the occurences of @var{value}, the current version has
address@hidden twice and @var{value} once.  In my book, this should be
@var{value} everywhere but possibly accompanied by some real examples
that would then usually show a # as part of value.

I have to admit that putting address@hidden would make this correspond
to the other instances.  It's just that I don't see that as correct.

If I do a grep for @var{value} on the Documentation and remove the
translations, I arrive at

@address@hidden@var{layout-property} = address@hidden
Documentation/learning/tweaks.itely:the @var{Context} context, to the
value @var{value}.
Documentation/learning/tweaks.itely:\tweak @var{layout-property}
@address@hidden @var{value}
@address@hidden #'@var{property} = address@hidden
Documentation/notation/changing-defaults.itely:for @var{name},
@var{property}, and @var{value}.  Here we only
@address@hidden #'@var{property} #'@var{subproperty} =
@address@hidden = address@hidden
Documentation/notation/changing-defaults.itely:@var{value} is a Scheme
object, which is why it must be preceded by
address@hidden@address@hidden = address@hidden
address@hidden@var{grob-property} @var{value}
Documentation/notation/changing-defaults.itely:follows @var{value} in
the music stream.
Documentation/usage/running.itely:This sets the equivalent internal
Scheme function to @var{value}.
Documentation/usage/running.itely:If a @var{value} is not supplied, then
the default value is used.  The

which, uh, points to @var{value} being quite in the minority, and the
text "@var{value} is a Scheme object, which is why it must be preceded
by" further muddifies the distinction between # being part of the
override/tweak syntax and part of the value.

Also Documentation/notation/changing-defaults.itely contains quite a
few old-syntax overrides.

I have to admit that putting @var{value} here alone will not help
consistency: this would need a more sweeping revision that replaces
"must be preceded by #" with "will usually be a Scheme value
introduced with # unless it is a LilyPond-native construct like a


Do you have any particular preference this being the Learning Manual and all?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]