Re: PATCH: Doc: Reorganize music functions material.

Le 26 avr. 2010 à 19:46, Carl Sorensen a écrit : > The problem is that the #{ throws off the emacs Scheme editor (at least I > assume that's what happens). > > So there are two reasonably compliant choices for indentation. > > #(define-music-function (parser location args) >

Re: PATCH: Doc: Reorganize music functions material.

Nicolas Sceaux wrote: > Actually, a nice indentation would be: > > #(define-music-function (parser location args) > (arg-type-predicates) >body) > > or: > > #(define-music-function > (parser location args) > (arg-type-predicates) >body) I much prefer the second of these two

Re: *-headword.ly files look weird

On Mon, Apr 26, 2010 at 10:37:18PM -0700, Mark Polesky wrote: > Why are so many of the Documentation/snippets/new/*-headword.ly > files coded in absolute mode with one note per line? I don't know; what does the git history say? You do realize that the exact input for the headwords are almost the

Learning 3.4.5 Scores and parts, and \include in Learning ?

WTM is this hidden under 3.4 Extending the templates ? I recall that it needed to be rewritten, but it bounced around a few places in Learning... but I think the current location is quite sub-optimal. Does anybody want to look into this in detail and propose another location? It used to be part

Re: Learning 3.4.5 Scores and parts, and \include in Learning ?

Hi Graham (et al.), > WTM is this hidden under 3.4 Extending the templates ? No M-ing good reason, that's for sure. > Anyway, is there a volunteer to investigate these issues? I can do it. Cheers, Kieren. ___ lilypond-devel mailing list lilypond-de

order of engravers

Talking about http://code.google.com/p/lilypond/issues/detail?id=673 problem with order of \consists On Tue, Apr 27, 2010 at 1:38 PM, Kieren MacMillan wrote: > Reviewing the situation, I'm not sure I *need* to send a patch: the Learning > [!!] page > >     >

Re: PATCH: Doc: Reorganize music functions material.

On 4/27/10 1:44 AM, "Nicolas Sceaux" wrote: > > Actually, a nice indentation would be: > > #(define-music-function (parser location args) > (arg-type-predicates) >body) > > or: > > #(define-music-function > (parser location args) > (arg-type-predicates) >body) > I

Re: PATCH: Doc: Reorganize music functions material.

Hi Carl et al, > I believe that this indentation scheme is more consistent with standard > Scheme indentation than the other. (parser location args) is at the same > list level as (arg-type-predicates) so it should have the same or higher > indentation, not lower. > > I like this, and would be v

Re: [PATCH] Re: syntax change for \cresc

2010/4/26 Reinhold Kainhofer : > Absolutely. You can't imagine how long i fought to find proper ways > to align "pp" and "pp sempre" properly with each other! How interesting! Do you use Graham's function or do you have something "on your own"? I hoped normal markups to align automatically besid

Overriding tagline in a custom init file?

I'm currently trying to create some pdf examples for my LAC presentation using a make file that calls musicxml2ly on the xml file and then lilypond to generate the pdf output. Unfortunately, this will always place the tagline at the bottom of each pdf, so the "clipped" pdfs will still be almost

Re: Overriding tagline in a custom init file?

On Tue, Apr 27, 2010 at 07:28:03PM +0200, Reinhold Kainhofer wrote: > Since the .ly files are auto-generated, it's not so easy to modify them, so > I'm trying the init file approach: > lilypond --init=myinit.ly -dbackend=eps -dno-aux-files --pdf test.ly I've done this kind of thing with cat.

Re: two-week Report warning

Op vrijdag 16-04-2010 om 13:00 uur [tijdzone +0200], schreef Reinhold Kainhofer: > On May 3 and 4, I'll be at the Linux Audio Conference in Utrecht / > Netherlands, where I'll present two papers: I'm looking at possibilities to be there on Monday or Tuesday, hoping to see you there. Jan. -- J

PATCH: Eliminate PDF deletion in Windows

Lilypond would attempt to delete the output PDF before overwriting it in Windows (but no other platforms). This is unnecessary and causes problems with certain PDF viewers, e.g. Sumatra, where the PDF is kept open in a way that allows overwriting but not deletion. See also the discussion on bug-l

PATCH: Doc: Clarify \relative inside \repeat issue.

It struck me that there are more options for dealing with the "\relative inside \repeat" issue. Can someone look over this to make sure I'm not doing anything sacrililygious? - Mark From c3fad3258734b7632d9e7cde7bb414ca07d593fe Mon Sep 17 00:00:00 2001 From: Mark Polesky Date: Tue, 27 Ap