Le 24 nov. 2009 à 17:51, d...@gnu.org a écrit :
> It would make sense to apply http://codereview.appspot.com/160048>
> first and make this patch work on top of that.
>
> There may be cases where a separate property-bind like this is useful in
> called routines, and the markup commands from the me
It would make sense to apply http://codereview.appspot.com/160048>
first and make this patch work on top of that.
There may be cases where a separate property-bind like this is useful in
called routines, and the markup commands from the mentioned patch might
make use of it for implementing #:prop
On 11/23/09 2:41 PM, "Valentin Villenave" wrote:
> On Mon, Nov 23, 2009 at 3:23 AM, Carl Sorensen wrote:
>> The way we indicate a variable name in the documentation is not with CAPS or
>> with 'single quotes' but with @var{macro}.
>
> That (unfortunately) doesn't seem to apply in music-funct
On Mon, Nov 23, 2009 at 3:23 AM, Carl Sorensen wrote:
> The way we indicate a variable name in the documentation is not with CAPS or
> with 'single quotes' but with @var{macro}.
That (unfortunately) doesn't seem to apply in music-functions.scm:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a
Le 23 nov. 2009 à 03:23, Carl Sorensen a écrit :
>
> I think that what Graham meant was you should use @var{props} instead of
> `props'.
Yes, I've finally understood what Graham meant, but after I've sent that
stupid message :)
___
lilypond-devel ma
On 11/22/09 10:50 AM, "Nicolas Sceaux" wrote:
> Le 22 nov. 2009 à 17:10, Graham Percival a écrit :
>
>> On Sun, Nov 22, 2009 at 3:37 PM, wrote:
>>> As I'm not (obviously) a native English speaker, comments on style are
>>> most welcome.
>>
>> Whenever I try to publish my comments, I get a
Le 22 nov. 2009 à 17:10, Graham Percival a écrit :
> On Sun, Nov 22, 2009 at 3:37 PM, wrote:
>> As I'm not (obviously) a native English speaker, comments on style are
>> most welcome.
>
> Whenever I try to publish my comments, I get a 500 server error. :(
> I'll summarize them below:
> - use @
Nicolas,
I'm now having similar problems on Rietveld as Graham.
First five lines of your docstring in scm/markup.scm in the
property-bind macro should say:
"Search properties in `props', and bind each property symbol to a
corresponding value, or to a default if a value is not found.
props: a
Thank you Ian for the careful review.
Nicolas
http://codereview.appspot.com/157133/diff/1/2
File Documentation/extending/programming-interface.itely (right):
http://codereview.appspot.com/157133/diff/1/2#newcode1045
Documentation/extending/programming-interface.itely:1045: The
@code{layout} a
Nicolas,
These are mainly stylistic changes. Please double-check to ensure I
haven't changed the meaning of what you intended.
Cheers,
Ian
http://codereview.appspot.com/157133/diff/1/2
File Documentation/extending/programming-interface.itely (right):
http://codereview.appspot.com/157133/diff/
On Sun, Nov 22, 2009 at 3:37 PM, wrote:
> As I'm not (obviously) a native English speaker, comments on style are
> most welcome.
Whenever I try to publish my comments, I get a 500 server error. :(
I'll summarize them below:
- use @var{foo} for variable names. This applies to both the .itely
fi
Reviewers: ,
Message:
Hi,
This patch improves (as I hope) the documentation on markup command
definition, by using more complete examples. It also tries to address
an issue that was raised on -devel, concerning the different syntax
between built-in and user-defined markup command definition.
A
12 matches
Mail list logo