Re: adds documentation for the new bar line interface (issue 6742061)

[marc]

On 2012/10/23 23:22:03, J_lowe wrote:

One typo so, as we need to fix this, I also included a minor grammar

change.


Otherwise LGTM.



https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely

File Documentation/notation/rhythms.itely (right):



https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely#newcode2815

Documentation/notation/rhythms.itely:2815: The @code{"="} bar line

provides the

double span bar line used
...bar line, used in combination...


Done.


https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely#newcode2821

Documentation/notation/rhythms.itely:2821: are useful to distinguish

bar lines

with identical appearance
...to distinguish those with identical...


Done.

Thanks for your comments and improvements!



https://codereview.appspot.com/6742061/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2917: Extend \keepWithTag to allow multiple tags (issue 6744070)

[marc]

On 2012/10/23 19:45:15, dak wrote:

On 2012/10/23 19:05:09, marc wrote:
> Hey, that was quick! Thanks for solving this issue - LGTM!



Well, there is no regtest and no documentation, so it is not like

there is

nothing left to do.


That's right – we had this discussion before concerning new
features and the documentation part. The 'LGTM' is just meant
for the code you uploaded for review – I like the way you
rework parts of lilypond on-the-fly while adding new features
instead of just adding a lot of new stuff (as I had probably
done it).

  And to be honest, the usual "to check this feature, you

have used some code and could equally well turn this into a regtest"

does not

even apply.  I haven't checked anything.


This cannot be seen by reviewing this patch alone, so I had
to trust on you ;-)



http://codereview.appspot.com/6744070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

PATCH: Countdown to 20121025

[Colin Campbell]

For 20:00 MDT Thursday October 25

Enhancement:
Issue 2920 
: Patch: Revert 
"Archive baselines in LILYPOND_BASELINES directory if specified" - R 
6709073 
Issue 2917 
: Extend 
\keepWithTag to allow multiple tags - R 6744070 

Issue 2898 
: Patch: Fix 
unproper nesting of various property overrides - R6685044 

Issue 2445 
: Center a 
number above a measure - R 6730044 
Issue 2883 
: Patch: Make 
arguments like Context.GrobName accessible as symbol lists - R 6651053 



Cheers,
Colin

--
I've learned that you shouldn't go through life with a catcher's mitt on both 
hands. You need to be able to throw something back.
-Maya Angelou, poet (1928- )

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: glossary - add 'high bass clef'

[James]

Arnold

I think this might be better on dev list than bug so I am ccing dev in
case you are not subscribed to that list yet.

On 23 October 2012 12:54, ArnoldTheresius  wrote:
> James wrote
>> Hello,
>>
>> ...
>>
>> Well I have applied this patch and I am not sure it is appropriate for
>> the glossary, perhaps the explanation, but the example is far too
>> complex for our documentation - perhaps as a snippet maybe.
>>
>> Also you have not followed really any of our style guidelines in the
>> Contributor's Guide (line lengths, texinfo syntax, @lilypond
>> [variables] etc. so there is still a fair amount of work to do here
>> before it will even be considered.
>>
>> So, I can do this for you (shepherd your patch) or you are more than
>> welcome to use our git-cl and patch review process yourself until you
>> need to push it, when you will need to prepare a properly formatted
>> git patch that is easy to apply etc (i notice your $LILYPOND_GIT
>> variable is not the standard one, making it slightly more work for
>> those that need to apply it - I am no expert but managed to work it
>> out). I don't want to discourage you from submitting patches, but we
>> do have a well defined (if slightly idiosyncratic work-flow - so I am
>> told, I only know LilyPond so cannot comment)
>>
>> If you do choose to do this yourself you should read our Contributor's
>> Guide and follow the style guidelines there, and I suggest that you
>> take the huge example out, cut it right back as you can and include it
>> as a snippet.
>>
>> See:
>>
>> http://lilypond.org/doc/v2.16/Documentation/contributor/documentation-work
>>
>> and
>>
>> http://lilypond.org/doc/v2.16/Documentation/contributor/summary-for-experienced-developers
>> (the reviews section specifically).
>>
>> James
>>
>> ___
>> bug-lilypond mailing list
>
>> bug-lilypond@
>
>> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
> Well,
>
> I noticed, the example is quite huge. But I'm not sure, can it be understood
> without example?
> If so, we can completely remove the snippets.

Yes this is best. There is no reason why you cannot include an
@seealso section with a snippet, however this should be done as a
separate patch. Snippets are a bit more complex than normal doc edits
(or rather there are more things to consider). So i would for now
forgo the snippet and the @seealso section and just get the text in.
Then once you are ok with the process we can add a new snippet and
then add the @seealso reference in the glossary to complete the cross
reference.

>
> I think the line length of 80 characters was succeded only in the
> 'snippets'.

The specified line length is 72 characters (66 preferred).

>
> What could a 'separate snippet' want to tell? Perhaps "How to build a pitch
> usage chart manually".

Snippets are designed for more complex examples (for example we don't
use \overrides or \tweak-like examples in the core documentation if we
can avoid it - these are created as snippets and referred to at the
end of the section in the @seealso part, likewise massive amounts of
Scheme code have no business being the core documentation for general
examples either, again the snippets are the place for this).

This is all explained in the Documentation guidelines and policy in
the Contributor's Guide.

So I suggest that if you want to show your high bass clef that you
give as simple as an example as you can (remove any extraneous code)
and submit that as a snippet/new for the documentation. You 'chart'
might be better added to the Lilypond Snippet Repository directly -
see

http://lsr.dsi.unimi.it/LSR/html/whatsthis.html

Be aware though that this is currently running LilyPond 2.14.x code,
it is a bit behind current LilyPond stable, but will get there
eventually.


>
> I did try to use only the syntax I found in the '.tely' file, but I did not
> look (deeply) into the documentation contributors guide. Sorry for that.

That's ok, as I said, we are quite fastidious about this so as to keep
everyone as consistent as possible. Everything about the doc is
autobuilt (including the whole website) based on the texinfo code,
make doc can take a long time on many machines and if this breaks for
any reason it means we cannot get *any* documentation on the
lilypond.org site, hence the 'rules' in the Contributor's Guide.

There are a few of us who will and can help you, so please don't get
frustrated if you find people pointing out that you didn't do X or you
must do Y at first. The contributor's guide, while seemingly a lot to
read, is actually a very good reference when you cannot remember all
the rules.

>
> To upload contributions by myself: My computer I'm working with lilypond is
> not connected to any network. (For that reason I prefer the PDF of the
> handbooks to the HTML version)

Right, but the documents are all built from one source, so this is why
we care about formatting and syntax etc. Everything (HTML and PDF)
must build.

> So at f

Re: adds documentation for the new bar line interface (issue 6742061)

[pkx166h]

One typo so, as we need to fix this, I also included a minor grammar
change.

Otherwise LGTM.




https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely#newcode2815
Documentation/notation/rhythms.itely:2815: The @code{"="} bar line
provides the double span bar line used
...bar line, used in combination...

https://codereview.appspot.com/6742061/diff/10001/Documentation/notation/rhythms.itely#newcode2821
Documentation/notation/rhythms.itely:2821: are useful to distinguish bar
lines with identical appearance
...to distinguish those with identical...

https://codereview.appspot.com/6742061/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2917: Extend \keepWithTag to allow multiple tags (issue 6744070)

[dak]

On 2012/10/23 19:05:09, marc wrote:

Hey, that was quick! Thanks for solving this issue - LGTM!


Well, there is no regtest and no documentation, so it is not like there
is nothing left to do.  And to be honest, the usual "to check this
feature, you have used some code and could equally well turn this into a
regtest" does not even apply.  I haven't checked anything.

http://codereview.appspot.com/6744070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2917: Extend \keepWithTag to allow multiple tags (issue 6744070)

[marc]

Hey, that was quick! Thanks for solving this issue - LGTM!



http://codereview.appspot.com/6744070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: prevent collision of ligatures and next note (issue 6740046)

[benko . pal]

hi Janek,


Pal, could you add some comments and a more descriptive commit

message?  I see

the code, and it seems to make sense, but i don't understand the

"why's".  For

example, why the parameters should be passed in a different way?


in C++ there should be a good reason to pass complex structures like
std::vector by value, not by reference to const; in this case
there's no such reason, pass-by-reference works perfectly.


I also think that it'd be a good idea to add a regtest, even if it's

imperfect

(just write a comment inside it, so that everyone envestigating it

will be

warned that some unexpected results may occur).


the problem is that I really can't predict _when_ unexpected results can
and when can't occur.  I tried to come up with the Tiniest example and
I'm sure my example in the attachment to
http://code.google.com/p/lilypond/issues/detail?id=2914
is not the tiniest possible that demonstrates the problem.  put
otherwise, working all right with previous versions is just as
unexpected for me as producing a collision.


http://codereview.appspot.com/6740046/diff/1/lily/mensural-ligature-engraver.cc

File lily/mensural-ligature-engraver.cc (right):



http://codereview.appspot.com/6740046/diff/1/lily/mensural-ligature-engraver.cc#newcode428

lily/mensural-ligature-engraver.cc:428: if (size_t const dot_count =
Rhythmic_head::dot_count (current))
Is this related to the ligature collision problem or just a by-the-way

fix?

it _was_ related (see usage of dot_count lower); I hope the new
organization is cleaner.

p

http://codereview.appspot.com/6740046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: adds documentation for the new bar line interface (issue 6742061)

[marc]

On 2012/10/23 09:03:32, J_lowe wrote:

Mark,



Nearly there.


Hey, sounds prominsing ;-)



Some more general comments - some are Doc Policy, some are my own

views on how

to organize this section, also can you make sure you use two spaces

after a full

point (full stop) as this is also the CG policy (even if it does go

against

every grain in my typographically-based bones!).



James



https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely

File Documentation/notation/rhythms.itely (right):



https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2693

Documentation/notation/rhythms.itely:2693: Further details of this

notation are

explained in @ref{Typesetting Kievan square notation}.
Make sure you only use max 72 chars per line and dont break @ref{...}

over two

lines



http://lilypond.org/doc/v2.16/Documentation/contributor/syntax-survey#cross-references


Causes problems in texinfo output


Ok.


https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2780

Documentation/notation/rhythms.itely:2780: \defineBarLine

@var{bartype}

#'(@var{bar-line-at-end-of-line} @var{bar-line-at-begin-of-line}
@var{span-bar-line})
You probably aught to shorten the variable names for the doc (even if

the

function names internally are called this, most users don't care and

you always

have the @ref{} under the @seealso  at the end of the section to link

to the ly:

file for those that are really curious.



@var{type} @var{end} @var{begin} @var{span} else if you do end up

going over 72

chars, break and indent the line as you would a lilypond example.



Makes it clearer for readers.


Ok, will do.


https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2784

Documentation/notation/rhythms.itely:2784: @samp{\bar "bartype"}.
Use @code{\bar} @var{bartype}


Ok. I found examples where @samp is used in similar circumstances,
but I trust you on this.


https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2792

Documentation/notation/rhythms.itely:2792: bar line.
Move the Para above the previous (just after the @example).



The @code{\defineBarline} variables can include the @q{empty} string

@code{""},

which is equivalent to an invisible bar line being printed.  Or they

can be set

to @code{#f} which prints no bar line at all.



--



The implication being that an invisible bar line uses normal

padding/spacing.

This also saves you repeating all the @var{}s again.



https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2822

Documentation/notation/rhythms.itely:2822: s1 \bar "]" \mark \markup {
\typewriter "]" }
I am guessing that \typewriter is used here to prevent century

schoolbook and so

make the characters more obvious, however there is no need if you use

the normal

@lilypond[verbatim, quote etc.] as this *is* printed in 'typewriter'

font in the

doc (and is why we do this), so you can rmeove all the \mark \markup {

} from

this if you use the correct @lilypond variables.


I used typewriter and did not use verbatim, because I have to
define several bar lines which clutters the output IMHO.

But in combination with the proposed reordering, it may make more
sense.





Also, could we move this whole @lilypond section right up to  the

(almost)

start, under the para



'After the definiton, the new bar line can be used by @samp{\bar

"bartype"}.'


---



That way we get right to the point and then can do the detail

afterwards, so to

speak. It's not complicated to understand and so the finer points can

be

explained as the reader reads through.



https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2828

Documentation/notation/rhythms.itely:2828: combination with the segno

sign. It

is not recommended for use as
could we have a short reason it is not recommended? Else I always just

say 'Do

not use '. I prefer to be led than given choice if it's that

subtle or there

is no explanation on why I might not 'prefer' to do something.


The reason is that the "=" is spaced according to the width of
the "S" sign; if you use this as a normal bar line, the internal
spacing in combination with the bar line padding looks way too ugly.

But I see your point: this explanation is probably too complicated;
I'll go for 'Do not use ...'


https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2829

Documentation/notation/rhythms.itely:2829: a standalone double thin

bar line;

here, @samp{\bar "||"} is
... here, @code{\bar} @var{"||"} is ...



https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2832

Documentation/notation/rhythms.itely:2832: The @code{"-"} sign

distinguishes bar

lines with
The @code{"-"} sign separates (?). Could we have an @lilypond example

New bar line interface: adds volta bracket regtest; minor changes (issue 6737051)

[janek . lilypond]

LGTM, i think.
best,
Janek

http://codereview.appspot.com/6737051/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Create \temporary for doing overrides without pop-first set (issue 6687044)

[janek . lilypond]

pushed as 5c4b80afe97acbe20199a3aa71a0d63172112f23

David, please close this issue.

thanks!
Janek

http://codereview.appspot.com/6687044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: prevent collision of ligatures and next note (issue 6740046)

[janek . lilypond]

(as you may know, i dedicate all my code reviews to Graham the
Magnificent :D)

Pal, could you add some comments and a more descriptive commit message?
I see the code, and it seems to make sense, but i don't understand the
"why's".  For example, why the parameters should be passed in a
different way?

I also think that it'd be a good idea to add a regtest, even if it's
imperfect (just write a comment inside it, so that everyone
envestigating it will be warned that some unexpected results may occur).

cheers,
Janek


http://codereview.appspot.com/6740046/diff/1/lily/mensural-ligature-engraver.cc
File lily/mensural-ligature-engraver.cc (right):

http://codereview.appspot.com/6740046/diff/1/lily/mensural-ligature-engraver.cc#newcode428
lily/mensural-ligature-engraver.cc:428: if (size_t const dot_count =
Rhythmic_head::dot_count (current))
Is this related to the ligature collision problem or just a by-the-way
fix?

http://codereview.appspot.com/6740046/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 2917: Extend \keepWithTag to allow multiple tags (issue 6744070)

[dak]

Reviewers: lemzwerg,

Message:
On 2012/10/23 11:19:59, lemzwerg wrote:

LGTM.  Any convert rules necessary?


Well, I abolish list-or-symbol? here on the assumption that nobody used
this peculiar and mostly ill-advised predicate.  That is somewhat
optimistic.  Converting list-or-symbol? automatically to
symbol-list-or-symbol?, however, would silently change its meaning.  So
I'd not really be all that comfortable with that.  If that predicate is
indeed needed, it is trivial to write.  One could retain it under the
old name, but it really is too unspecific to be of good use.

Description:
Issue 2917: Extend \keepWithTag to allow multiple tags

Also extends \removeWithTag accordingly.


There are also a few other commits from issue 2883 drawn in.  The set
is slightly larger than necessary for this issue, but I wanted to
avoid having to manually resolve merge conflicts.

Replace the rather fuzzy list-or-symbol? with symbol-list-or-symbol?

list-or-symbol? was previously used in the meaning of
symbol-list-or-symbol? only, and there is no point in not checking the
list members for actually being symbols, in order to avoid ugly
surprises later.

Add symbol-list-or-music? predicate

This is of interest for commands like \hide which accept either music
(to see an override) or a grob specification like Accidental or
Voice.Accidental.

Add symbol-list? predicate

Please review this at http://codereview.appspot.com/6744070/

Affected files:
  M ly/music-functions-init.ly
  M ly/property-init.ly
  M scm/c++.scm
  M scm/lily.scm


Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
4fa31929d4ef9e2188ba5745612b092c870143e7..597a67673781f2ee32c2c637e2340fa66d2a0963  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -523,15 +523,21 @@ instrumentSwitch =


 keepWithTag =
-#(define-music-function (parser location tag music) (symbol? ly:music?)
-   (_i "Include only elements of @var{music} that are tagged with  
@var{tag}.")

+#(define-music-function (parser location tag music)
+   (symbol-list-or-symbol? ly:music?)
+   (_i "Include only elements of @var{music} that are either untagged
+or tagged with one of the tags in @var{tag}.  @var{tag} may be either
+a single symbol or a list of symbols.")
(music-filter
-(lambda (m)
-  (let* ((tags (ly:music-property m 'tags))
-(res (memq tag tags)))
-   (or
-(eq? tags '())
-res)))
+(if (symbol? tag)
+(lambda (m)
+  (let ((music-tags (ly:music-property m 'tags)))
+(or (null? music-tags)
+(memq tag music-tags
+(lambda (m)
+  (let ((music-tags (ly:music-property m 'tags)))
+(or (null? music-tags)
+(any (lambda (t) (memq t music-tags)) tag)
 music))

 key =
@@ -1019,13 +1025,19 @@ relative =
   'element music))

 removeWithTag =
-#(define-music-function (parser location tag music) (symbol? ly:music?)
-   (_i "Remove elements of @var{music} that are tagged with @var{tag}.")
+#(define-music-function (parser location tag music)
+   (symbol-list-or-symbol? ly:music?)
+   (_i "Remove elements of @var{music} that are tagged with one of the
+tags in @var{tag}.  @var{tag} may be either a single symbol or a list
+of symbols.")
(music-filter
-(lambda (m)
-  (let* ((tags (ly:music-property m 'tags))
-(res (memq tag tags)))
-   (not res)))
+(if (symbol? tag)
+(lambda (m)
+  (not (memq tag (ly:music-property m 'tags
+(lambda (m)
+  (let ((music-tags (ly:music-property m 'tags)))
+(or (null? music-tags)
+(not (any (lambda (t) (memq t music-tags)) tag))
 music))

 resetRelativeOctave =
@@ -1227,7 +1239,7 @@ the `parameters' assoc list.")

 styledNoteHeads =
 #(define-music-function (parser location style heads music)
-   (symbol? list-or-symbol? ly:music?)
+   (symbol? symbol-list-or-symbol? ly:music?)
(_i "Set @var{heads} in @var{music} to @var{style}.")
(style-note-heads heads style music))

Index: ly/property-init.ly
diff --git a/ly/property-init.ly b/ly/property-init.ly
index  
269648639b7d81b54b53b37aeb72cddf470b3a46..8e87421f74b467d2370a27437abaed8c68e21614  
100644

--- a/ly/property-init.ly
+++ b/ly/property-init.ly
@@ -376,7 +376,7 @@ back to the lilypond source statement.")
(make-music 'SequentialMusic 'void #t))

 pointAndClickTypes =
-#(define-void-function (parser location types) (list-or-symbol?)
+#(define-void-function (parser location types) (symbol-list-or-symbol?)
   (_i "Set a type or list of types (such as @code{#'note-event}) for which  
point-and-click info is generated.")

   (ly:set-option 'point-and-click types))

Index: scm/c++.scm
diff --git a/scm/c++.scm b/scm/c++.scm
index  
444a3e9ba6534b9201c26937785bcbb4fc9e6a5d..8d1df2aed7487b22c742780e4f73c0c12833fbd2  
100644

--- a/scm/c++.scm
+++ b/scm/c++.scm
@@ -48,6 +48,14 @

Issue 2917: Extend \keepWithTag to allow multiple tags (issue 6744070)

[lemzwerg]

LGTM.  Any convert rules necessary?


http://codereview.appspot.com/6744070/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Revert "Archive baselines in LILYPOND_BASELINES directory if specified" (issue 6709073)

[lemzwerg]

LGTM.

http://codereview.appspot.com/6709073/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[David Kastrup]

Werner LEMBERG  writes:

>> out=test \
>> local-test
>> /bin/sh: 1: local-test: not found
>> make: *** [test] Error 127
>
> Thanks, I'll upload a fixed patch with patchy.  However, you are going
> to remove some stuff from GNUmakefile, right?  Then I'll wait.

It would make sense to do this before the reformatting.  We have enough
dead code flying around.  I'll submit a proposal shortly.  Just need to
find the original issue.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[Werner LEMBERG]

> out=test \
> local-test
> /bin/sh: 1: local-test: not found
> make: *** [test] Error 127

Thanks, I'll upload a fixed patch with patchy.  However, you are going
to remove some stuff from GNUmakefile, right?  Then I'll wait.

> I am backing this change out of staging again.

Thanks again.  Imagine some ashes on my head.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[David Kastrup]

Werner LEMBERG  writes:

>> I have run my own copy of patchy-merge, and it failed because of
>> typos in the Makefile,
>
> Details, please.

I already sent the details previous to writing the quoted mail above,
but looking at the list archives it would appear that Gmane swallowed
them as Spam or TOFU or whatever.

I resent the original message directly to the list server, and it looks
like this time it got through.  Depending on what happens with the copy
on Gmane, it may appear twice for that reason.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[David Kastrup]

David Kastrup  writes:

> Werner LEMBERG  writes:
>
>> Folks,
>>
>>
>> as discussed some weeks ago, I've now pushed the reformatted
>> GNUmakefile to staging.  There are only whitespace changes.
>
> Is there anything wrong with our review system?  If you feel there is,
> how about at least posting the patch for review on the list before
> pushing?
>
> Things like
>
> +TOPDOC_TXT_FILES = \
> +  $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/, \
> +  $(addsuffix .txt, \
> +  $(TOPDOC_FILES)))
> +IN_FILES := \
> +  $(call src-wildcard, \
> + *.in)
>
> are quite beyond the scope of discussion and I don't see that they
> improve either readability nor reduce the potential for merge conflicts.
> And things like
>
> +STEPMAKE_TEMPLATES = \
> +  po \
> +  install \
> +  toplevel 
> +LOCALSTEPMAKE_TEMPLATES = \
> +  lilypond
>
> are ugly without an additional empty line.  Stuff like
>
> -   $(MAKE) local-dist $(distdir)
> +   $(MAKE) local-dist \
> +   $(distdir)
>
> makes little sense: why split a simple command into two lines if after
> the split both the first as well as the second line are special (one
> starts with $(MAKE) and the other does not end with \)?  Absolutely no
> gain in readability or mergeability.
>
> And that's just from glancing over the first few lines.  More important:
> you are changing a core part of the build system.  You _intend_ this
> change not to contain any functional differences, but a rather thorough
> way to be reasonably sure that you were successful in every detail is
> our regtest system.  Which does not just check, from a clean slate, that
> everything compiles, but also that the results from the regtests stay
> the same.
>
> The staging merge does not guarantee the same.  It is, speaking in the
> words of chairman Percival, a safety net, not a trampoline.

Oh you must be kidding me.

From: d...@gnu.org (David Kastrup)
To: d...@gnu.org
Date: Tue, 23 Oct 2012 10:32:45 +0200 (CEST) (23 minutes, 21 seconds ago)

From: patchy
Reply-To: lilypond-devel@gnu.org
To: lilypond-a...@gnu.org
Cc: lilypond-devel@gnu.org
Date: Tue, 23 Oct 2012 10:32:45 +0200
User-Agent: Patchy - LilyPond autobuild
Subject: Patchy email

08:19:28 (UTC) Begin LilyPond compile, previous commit at   
c5dd62ea78a8790465b8427febec71ff0ee21fdc
08:19:38 Merged staging, now at:c5dd62ea78a8790465b8427febec71ff0ee21fdc
08:19:40Success:./autogen.sh --noconfigure
08:20:04Success:/tmp/lilypond-autobuild/configure 
--disable-optimising
08:20:12Success:nice make clean
08:25:42Success:nice make -j3
08:32:45 *** FAILED BUILD ***
nice make test -j3
Previous good commit:   c7d55b2b61d7cf5310c40b6e76fb31a482f812f1
Current broken commit:  c5dd62ea78a8790465b8427febec71ff0ee21fdc
08:32:45 *** FAILED STEP ***
merge from staging
Failed runner: nice make test -j3
See the log file log-staging-nice-make-test--j3.txt
08:32:45 Traceback (most recent call last):
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
523, in handle_staging
self.build (issue_id=issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
323, in build
issue_id)
  File 
"/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py", line 
266, in runner
raise FailedCommand ("Failed runner: %s\nSee the log file %s" % (command, 
this_logfilename))
FailedCommand: Failed runner: nice make test -j3
See the log file log-staging-nice-make-test--j3.txt


make --no-builtin-rules -C input/regression/lilypond-book 
make[1]: Entering directory 
`/tmp/build-lilypond-autobuild/input/regression/lilypond-book'
/tmp/lilypond-autobuild/./input/regression/lilypond-book/GNUmakefile:24: 
warning: overriding commands for target `out/collated-files.list'
/tmp/lilypond-autobuild/./make/lysdoc-rules.make:6: warning: ignoring old 
commands for target `out/collated-files.list'
true
make[1]: Leaving directory 
`/tmp/build-lilypond-autobuild/input/regression/lilypond-book'
out=test \
local-test
/bin/sh: 1: local-test: not found
make: *** [test] Error 127


Werner, can you _please_, _please_, _please_ not consider our review
system optional?  I have no idea why you think it appropriate to commit
changes to the toplevel build system you have not even tested yourself
completely.

I am backing this change out of staging again.  I actually don't usually
run staging-patchy myself because of its time hit, but this time I
wanted to be on the safe side before starting additional merge work to
avoid having to redo it.  Seems like it was a smart investment of time.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[Federico Bruni]

2012/10/23 James :
> Do all browsers accept output in SVG what about PDF readers?
>

I think that it should be limited to html.
The main problem is IE, because the basic support was added only in version 9:
http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Support_for_SVG_in_web_browsers

But there are some turnarounds.

> I'm rather sceptical about SVG output only that we do get occasionally
> gripes about LilyPond SVG output and Inkscape (for example), implying
> that our SVG backend (or whatever it is) is not 100% perfect, at least
> PNGs are 'just' images.

My suggestion was just about having an option to compile images in the
doc as SVG.
Just to see what can happen..

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[Werner LEMBERG]

> I have run my own copy of patchy-merge, and it failed because of
> typos in the Makefile,

Details, please.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[Werner LEMBERG]

>> as discussed some weeks ago, I've now pushed the reformatted
>> GNUmakefile to staging.  There are only whitespace changes.
>
> Is there anything wrong with our review system?  If you feel there
> is, how about at least posting the patch for review on the list
> before pushing?

It *has* been posted for review, and I got positive responses only.
The only issue was that committing should be delayed until 1.16 is
out.

> +TOPDOC_TXT_FILES = \
> +  $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/, \
> +  $(addsuffix .txt, \
> +  $(TOPDOC_FILES)))
> +IN_FILES := \
> +  $(call src-wildcard, \
> + *.in)
>
> are quite beyond the scope of discussion and I don't see that they
> improve either readability nor reduce the potential for merge
> conflicts.

For me, they do.  Everything which brings the line length *in a
systematic manner* below 80 characters is good.

> And things like
>
> +STEPMAKE_TEMPLATES = \
> +  po \
> +  install \
> +  toplevel
> +LOCALSTEPMAKE_TEMPLATES = \
> +  lilypond
>
> are ugly without an additional empty line.

Well, there was no empty line before either.  Feel free to add one.

>  Stuff like
>
> -   $(MAKE) local-dist $(distdir)
> +   $(MAKE) local-dist \
> +   $(distdir)
>
> makes little sense: why split a simple command into two lines if
> after the split both the first as well as the second line are
> special (one starts with $(MAKE) and the other does not end with \)?
> Absolutely no gain in readability or mergeability.

I disagree.  The main point of a more vertical formatting is that
future changes can be easily followed.  Just think of adding another
target.  Overlong lines don't work nicely with diff output; sometimes
I search a minute in the gitk window before I find the tiny
difference.

I now believe that the stuff in GNUmakefile.in is `smooth', this is,
the overall appearance is quite similar.  Additionally, I'm quite
certain that there is *no* chance to ever find a formatting which
pleases everyone.

> You _intend_ this change not to contain any functional differences,
> but a rather thorough way to be reasonably sure that you were
> successful in every detail is our regtest system.

You have a point.  I forgot this, sorry.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[David Kastrup]

James  writes:

> Hello,
>
> On 23 October 2012 08:26, David Kastrup  wrote:
>> Werner LEMBERG  writes:
>>
>>> Folks,
>>>
>>>
>>> as discussed some weeks ago, I've now pushed the reformatted
>>> GNUmakefile to staging.  There are only whitespace changes.
>>
>> Is there anything wrong with our review system?  If you feel there is,
>> how about at least posting the patch for review on the list before
>> pushing?
> ...
>
> Should I defer patchy merge? I see that this has been pushed to
> staging and I have just upgraded my main server to Xubuntu 12.10
> (hence the reason nothing has been merged yet). I have to go out for a
> few hours now, so let me know and I can either kick of a merge
> immediately when I get back or put it back on my normal 2 hour cycle.

No need to do that.  I have run my own copy of patchy-merge, and it
failed because of typos in the Makefile, so I backed the change out
again.  While we gain a short breathing pause, perhaps we should revert

commit 2ab98854c8f67c0edf5bc655a45aa6226e2caca9
Author: David Kastrup 
Date:   Tue Mar 20 12:32:10 2012 +0100

Archive baselines in LILYPOND_BASELINES directory if specified

while we still have time?  I made this change when I was mostly
responsible for running Patchy, and it is incompatible with the current
Patchy caching system.  I don't think anybody except myself has ever
used it.  It may be nice for making quick comparisons against several
test baselines, but it is not really documented and it would seem that
people use their own stuff for that kind of thing.

So it is likely to be dead code by now, and after a reformatting patch
is applied, it will be rather harder to remove again.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[James]

Hello,

On 23 October 2012 08:26, David Kastrup  wrote:
> Werner LEMBERG  writes:
>
>> Folks,
>>
>>
>> as discussed some weeks ago, I've now pushed the reformatted
>> GNUmakefile to staging.  There are only whitespace changes.
>
> Is there anything wrong with our review system?  If you feel there is,
> how about at least posting the patch for review on the list before
> pushing?
...

Should I defer patchy merge? I see that this has been pushed to
staging and I have just upgraded my main server to Xubuntu 12.10
(hence the reason nothing has been merged yet). I have to go out for a
few hours now, so let me know and I can either kick of a merge
immediately when I get back or put it back on my normal 2 hour cycle.

james

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[James]

Hello,

On 23 October 2012 10:05, Federico Bruni  wrote:
> 2012/10/23 David Kastrup :
>> Texinfo does not support SVG as far as I know.  And neither do typical
>> info readers like Emacs if I remember correctly.
>
> This page seems to confirm your statement:
> http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Image-Syntax.html#Image-Syntax
>
> But then what about this?
>
> "BTW, as for the HTML, if you want to use your .svg's, add one more optional
> argument:
> @image{foo.svg}"
>

Do all browsers accept output in SVG what about PDF readers?

I'm rather sceptical about SVG output only that we do get occasionally
gripes about LilyPond SVG output and Inkscape (for example), implying
that our SVG backend (or whatever it is) is not 100% perfect, at least
PNGs are 'just' images.

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[Federico Bruni]

2012/10/23 David Kastrup :
> Texinfo does not support SVG as far as I know.  And neither do typical
> info readers like Emacs if I remember correctly.

This page seems to confirm your statement:
http://www.gnu.org/software/texinfo/manual/texinfo/html_node/Image-Syntax.html#Image-Syntax

But then what about this?

"BTW, as for the HTML, if you want to use your .svg's, add one more optional
argument:
@image{foo.svg}"

http://lists.gnu.org/archive/html/help-texinfo/2011-10/msg7.html

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: adds documentation for the new bar line interface (issue 6742061)

[pkx166h]

Mark,

Nearly there.

Some more general comments - some are Doc Policy, some are my own views
on how to organize this section, also can you make sure you use two
spaces after a full point (full stop) as this is also the CG policy
(even if it does go against every grain in my typographically-based
bones!).

James


https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2693
Documentation/notation/rhythms.itely:2693: Further details of this
notation are explained in @ref{Typesetting Kievan square notation}.
Make sure you only use max 72 chars per line and dont break @ref{...}
over two lines

http://lilypond.org/doc/v2.16/Documentation/contributor/syntax-survey#cross-references

Causes problems in texinfo output

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2780
Documentation/notation/rhythms.itely:2780: \defineBarLine @var{bartype}
#'(@var{bar-line-at-end-of-line} @var{bar-line-at-begin-of-line}
@var{span-bar-line})
You probably aught to shorten the variable names for the doc (even if
the function names internally are called this, most users don't care and
you always have the @ref{} under the @seealso  at the end of the section
to link to the ly: file for those that are really curious.

@var{type} @var{end} @var{begin} @var{span} else if you do end up going
over 72 chars, break and indent the line as you would a lilypond
example.

Makes it clearer for readers.

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2784
Documentation/notation/rhythms.itely:2784: @samp{\bar "bartype"}.
Use @code{\bar} @var{bartype}

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2792
Documentation/notation/rhythms.itely:2792: bar line.
Move the Para above the previous (just after the @example).

The @code{\defineBarline} variables can include the @q{empty} string
@code{""},
which is equivalent to an invisible bar line being printed.  Or they can
be set
to @code{#f} which prints no bar line at all.

--

The implication being that an invisible bar line uses normal
padding/spacing.
This also saves you repeating all the @var{}s again.

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2822
Documentation/notation/rhythms.itely:2822: s1 \bar "]" \mark \markup {
\typewriter "]" }
I am guessing that \typewriter is used here to prevent century
schoolbook and so make the characters more obvious, however there is no
need if you use the normal @lilypond[verbatim, quote etc.] as this *is*
printed in 'typewriter' font in the doc (and is why we do this), so you
can rmeove all the \mark \markup { } from this if you use the correct
@lilypond variables.

Also, could we move this whole @lilypond section right up to  the
(almost) start, under the para

'After the definiton, the new bar line can be used by @samp{\bar
"bartype"}.'

---

That way we get right to the point and then can do the detail
afterwards, so to speak. It's not complicated to understand and so the
finer points can be explained as the reader reads through.

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2828
Documentation/notation/rhythms.itely:2828: combination with the segno
sign. It is not recommended for use as
could we have a short reason it is not recommended? Else I always just
say 'Do not use '. I prefer to be led than given choice if it's that
subtle or there is no explanation on why I might not 'prefer' to do
something.

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2829
Documentation/notation/rhythms.itely:2829: a standalone double thin bar
line; here, @samp{\bar "||"} is
... here, @code{\bar} @var{"||"} is ...

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2832
Documentation/notation/rhythms.itely:2832: The @code{"-"} sign
distinguishes bar lines with
The @code{"-"} sign separates (?). Could we have an @lilypond example
here to show like you do with the @code{" "} example below?

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2854
Documentation/notation/rhythms.itely:2854: If additional elements are
needed, Lilypond provides a simple
LilyPond not Lilypond.

https://codereview.appspot.com/6742061/diff/8001/Documentation/notation/rhythms.itely#newcode2856
Documentation/notation/rhythms.itely:2856: bar lines, see file
@file{scm/bar-line.scm}.
Add this @file{} reference to an @seealso at the end.

See:
http://lilypond.org/doc/v2.16/Documentation/contributor/syntax-survey#cross-references

and

http://lilypond.org/doc/v2.16/Documentation/contributor/section-organization

https://codereview.appspot.com/6742061/

_

Re: svg output

[David Kastrup]

Federico Bruni  writes:

> 2012/10/23 Joram Berger :
>> Ok, I've overlooked that.
>> Btw: SVG output is really nice!
>
> I agree.
> Personally, I'd love to see it used in the documentation. I wonder if
> it's possible to build the documentation using SVGs instead of PNGs..
> The documentation would be lighter, faster when browsed online and it
> would be possible to immagine advanced features (e.g. point-and-click
> from image to source through some javascript).
>
> Possible cons:
> - browser compatibility (sensible persons care for it, but I'm not
> sensible... especially when it's about _that_ browser)
> - output bugs in SVG? I have no idea if here's any, but this would be
> the most serious drawback I can think of

Texinfo does not support SVG as far as I know.  And neither do typical
info readers like Emacs if I remember correctly.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[Federico Bruni]

2012/10/23 Joram Berger :
> Ok, I've overlooked that.
> Btw: SVG output is really nice!

I agree.
Personally, I'd love to see it used in the documentation. I wonder if
it's possible to build the documentation using SVGs instead of PNGs..
The documentation would be lighter, faster when browsed online and it
would be possible to immagine advanced features (e.g. point-and-click
from image to source through some javascript).

Possible cons:
- browser compatibility (sensible persons care for it, but I'm not
sensible... especially when it's about _that_ browser)
- output bugs in SVG? I have no idea if here's any, but this would be
the most serious drawback I can think of

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PossibleSpam] Re: [PossibleSpam] Re: 2.16.1

[David Kastrup]

Francisco Vila  writes:

> 2012/10/23 David Kastrup :
>> Well, LilyPond could see a problem in connection with issue 2883.  Not
>> because of a Spanish version of changes.tely but because of outdated
>> syntax in the Spanish version, syntax that just was not present in the
>> English version, and that did not get converted with convert-ly.
>
> Well, the Spanish version in translation branch matches the English
> version in translation branch. Any changes in the original are usually
> announced by our 'make check-translation' script. While I was in
> translation branch, no change was made to the original, and therefore
> no changes were announced. This all comes from the lack of a
> translation branch for master/staging forked at the moment stable was
> forked. If translators are stuck with stable-translation,
> master/staging gets rapidly outdated. I have pushed to staging without
> the safety net.

Uhm, the above was not an accusation, just an explanation of the
circumstances that made it desirable from a technical standpoint to get
some elements of translation into staging already.  It was clear that
there would be a point of time when we would want to switch over, and it
is just that work on issue 2883 rang the bell and said "please start
now".  In a way, that is nice since it saves us from having to make an
arbitrary decision of when to switch.

That you are the only translator hit with changes.tely because you are
the only one who ever worked on a translation of it does not mean that
you are to blame for anything.  I would have fixed this myself, but my
mastery of Spanish is non-existent.  I would not have been sure to leave
the file in a correct state with regard to its contents.

Issue 2883 will require a lot of heavy lifting from our developers and
documenters, and it will also imply changes for users, even though with
a large amount of backward compatibility.  It was planned as a much more
confined change, but it would not have made sense to not actually use
the new possibilities for simplifying things elsewhere.

Again, thanks for your part on the translation side for getting this
change moved into a position where we can tackle it.  It has passed the
review pretty soon, but up to now has failed on the documentation build,
simply because of our decision to not have translators work on two
versions at once.  That decision was quite reasonable, and now it is
becoming reasonable to switch, and I am glad that the translation team
is being remarkably responsive to problems that are in no way their
fault but that can be addressed by them.

Thanks!

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PossibleSpam] Re: [PossibleSpam] Re: 2.16.1

[Francisco Vila]

2012/10/23 David Kastrup :
> Well, LilyPond could see a problem in connection with issue 2883.  Not
> because of a Spanish version of changes.tely but because of outdated
> syntax in the Spanish version, syntax that just was not present in the
> English version, and that did not get converted with convert-ly.

Well, the Spanish version in translation branch matches the English
version in translation branch. Any changes in the original are usually
announced by our 'make check-translation' script. While I was in
translation branch, no change was made to the original, and therefore
no changes were announced. This all comes from the lack of a
translation branch for master/staging forked at the moment stable was
forked. If translators are stuck with stable-translation,
master/staging gets rapidly outdated. I have pushed to staging without
the safety net.

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: reformatted GNUmakefile pushed to staging

[David Kastrup]

Werner LEMBERG  writes:

> Folks,
>
>
> as discussed some weeks ago, I've now pushed the reformatted
> GNUmakefile to staging.  There are only whitespace changes.

Is there anything wrong with our review system?  If you feel there is,
how about at least posting the patch for review on the list before
pushing?

Things like

+TOPDOC_TXT_FILES = \
+  $(addprefix $(top-build-dir)/Documentation/topdocs/$(outdir)/, \
+  $(addsuffix .txt, \
+  $(TOPDOC_FILES)))
+IN_FILES := \
+  $(call src-wildcard, \
+ *.in)

are quite beyond the scope of discussion and I don't see that they
improve either readability nor reduce the potential for merge conflicts.
And things like

+STEPMAKE_TEMPLATES = \
+  po \
+  install \
+  toplevel 
+LOCALSTEPMAKE_TEMPLATES = \
+  lilypond

are ugly without an additional empty line.  Stuff like

-   $(MAKE) local-dist $(distdir)
+   $(MAKE) local-dist \
+   $(distdir)

makes little sense: why split a simple command into two lines if after
the split both the first as well as the second line are special (one
starts with $(MAKE) and the other does not end with \)?  Absolutely no
gain in readability or mergeability.

And that's just from glancing over the first few lines.  More important:
you are changing a core part of the build system.  You _intend_ this
change not to contain any functional differences, but a rather thorough
way to be reasonably sure that you were successful in every detail is
our regtest system.  Which does not just check, from a clean slate, that
everything compiles, but also that the results from the regtests stay
the same.

The staging merge does not guarantee the same.  It is, speaking in the
words of chairman Percival, a safety net, not a trampoline.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: NR 5.3 Add \single command (issue 6742057)

[marc]

On 2012/10/20 17:52:29, J_lowe wrote:

Here is the first draft of reworking NR 5.3 while adding the \single

command.

James,

I like the changes very much – the restructuring makes the
doc more readable and understandable IMHO.


I _expect_ to have lots of edits and go through a few iterations of

this, the

point is to get something moving in terms of updating this section,

especially

with recent discussions about the new commands (\single, \omit, \no

etc.) where

it was evident that some were unhappy about it.



I don't claim to understand many of the finer points so I have not

added any new

information (apart from the \single command) but have rearranged this

section in

a more logical order and removed some (I think) unnecessary cruft,

repetition,

syntactically poor grammar. Of course this is all my own opinion, but

I saw no

point in just tacking yet another subsubheading on to the end of this

section

just to tick the 'I have documented \single' box.


+1


The @lilypond examples are as they were before as I'd like to at least

get the

technical descriptions right before I attempt to put some better

@lilypond

examples - for example make some less complex and include more for

commands like

\single and \tweak especially.


+1

Some more examples for \single would be great!

Regards,

Marc


http://codereview.appspot.com/6742057/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[Joram Berger]

Am 23.10.2012 09:08, Federico Bruni:
> 2012/10/23 Joram Berger :
>> Even though things are perhaps a little bit different, I would suggest
>> to include svg (or the whole backend-options) into formats, if possible.
>> Because thats essentially what the user wants: get the output in the
>> format svg.
> 
> there's an old issue still open for this:
> http://code.google.com/p/lilypond/issues/detail?id=967

Ok, I've overlooked that.
Btw: SVG output is really nice!

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: svg output

[Federico Bruni]

2012/10/23 Joram Berger :
> Even though things are perhaps a little bit different, I would suggest
> to include svg (or the whole backend-options) into formats, if possible.
> Because thats essentially what the user wants: get the output in the
> format svg.

there's an old issue still open for this:
http://code.google.com/p/lilypond/issues/detail?id=967

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel