On 2014/09/15 13:56:55, J_lowe wrote:
On 2014/09/15 07:26:45, dak wrote:
>
https://codereview.appspot.com/140630043/diff/1/Documentation/learning/tweaks.itely
> File Documentation/learning/tweaks.itely (right):
>
>
https://codereview.appspot.com/140630043/diff/1/Documentation/learning/tweaks.itely#newcode453
> 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
difference
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
overly
> 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
--snip--
...So the simple form
of the @code{\tweak} command is
@example
\tweak @var{layout-property} address@hidden
@end example
--snip--
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
Documentation/learning/tweaks.itely:\override
@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
Documentation/learning/tweaks.itely:\tweak
@address@hidden @var{value}
Documentation/notation/changing-defaults.itely:\override
@address@hidden #'@var{property} = address@hidden
Documentation/notation/changing-defaults.itely:for @var{name},
@var{property}, and @var{value}. Here we only
Documentation/notation/changing-defaults.itely:\override
@address@hidden #'@var{property} #'@var{subproperty} =
address@hidden
Documentation/notation/changing-defaults.itely:\set
@address@hidden = address@hidden
Documentation/notation/changing-defaults.itely:@var{value} is a Scheme
object, which is why it must be preceded by
Documentation/notation/changing-defaults.itely:\override
address@hidden@address@hidden = address@hidden
Documentation/notation/changing-defaults.itely:\tweak
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
markup".
Sigh.