Just curious: Are there (active) lilypond developers who aren't
listening to lilypond-bug?
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Do you actually expect the vertical formatting of the snippet below as
shown in the attached PDF?
Werner
==
\version "2.13.10"
\paper {
ragged-last-bottom = ##f
}
<<
\new Staff \relative {
f4 f f f |
f4 f f
>> Do you actually expect the vertical formatting of the snippet below
>> as shown in the attached PDF?
>
> I wouldn't say I expected it, but I can certainly explain it: it's
> an inconsistent handling of two related corner cases. When a loose
> line appears at the bottom of the page, we try to po
>> It would make life a bit easier for testers who are directly
>> compiling from git if the SHA1 number (perhaps the first eight
>> digits only) could be shown in the output of
>>
>> lilypond --version
>>
>> Any chance to add this?
>
> The common way is to do something like "$(shell git descr
Han-Wen,
do you remember why the dynamic signs `m' and `p' have a different
height? Ditto for essentially all other dynamic signs. At small
resolutions this looks really bad due to the PostScript hints applied
by FontForge...
Werner
___
lilyp
Folks,
why can I say
\new PianoStaff \with {
\override StaffGrouper
#'between-staff-spacing #'minimum-distance = #20
} ...
but not
\new Staff \with {
\override VerticalAxisGroup
#'next-staff-spacing #'minimum-distance = #20
} ...
?
The latter gives this warning:
>> Would it be a good idea to *draw* these angle brackets instead of
>> using glyphs from a font? I'm thinking that there would be fewer
>> problems that way.
>
> Or maybe we could add a set of angle brackets to the Emmentaler
> font, and use those instead?
I can imagine that we want to have angl
> Would it be a good idea to *draw* these angle brackets instead of
> using glyphs from a font?
Yes. The angle brackets in TeX Gyre Schola (which will eventually
become part of the LilyPond distribution and replace the New Century
Schoolbook fonts) are not too nice IMHO.
Werner
_
>> why can I say
>>
>> \new PianoStaff \with {
>> \override StaffGrouper
>> #'between-staff-spacing #'minimum-distance = #20
>> } ...
>>
>> but not
>>
>> \new Staff \with {
>> \override VerticalAxisGroup
>> #'next-staff-spacing #'minimum-distance = #20
>> } ...
>
> Becau
>> Is there a chance that you would consider this character for
>> inclusion in LilyPond 2.13?
>
> If Werner's OK with that, I'll open a feature request on the
> tracker.
Please go ahead.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.
> -) Compiling the font gives some warnings:
>
> Invoking "fontforge -script feta26.pe feta26.pfb"...
> Copyright (c) 2000-2009 by George Williams.
> Executable based on sources from 22:35 GMT 22-Jun-2009.
> Library based on sources from 22:35 GMT 22-Jun-2009.
> Internal Error in sc
>> [Not tested yet the actual changes.] Is your fontforge version
>> compiled with --enable-double?
>
> I use fontforge out of the box from my ubuntu distro. I don't know
> how it is built.
Since you get warnings even without your changes, you haven't
--enable-double. I strongly suggest to get
> Thus, the slash of the character sticks out of the bounding box by
> some amount.
This might cause problems if images are converted to, say, cropped PNG
images. You must assure somehow that the slash won't get cut off.
Everything else looks fine! BTW, I don't get any warning from my
fontforg
>> This might cause problems if images are converted to, say, cropped
>> PNG images. You must assure somehow that the slash won't get cut
>> off.
>
> [...] Furthermore, if I understand your comment correctly, even
> something like the coda or snappizzicato characters could have the
> semi-circles
Another nasty cutoff -- already in the PDF snippet as found in out-www
(attached for convenience) -- can be seen if you look at the output of
snippet/string-quartet-template-simple.ly
The lowest part of the system bracket is missing.
Werner
lily-6fc0ab3e-1.pdf
Description: Adobe PDF do
[git 04213e5e]
The file snippet/displaying-complex-chords.ly isn't formatted
correctly: The sharp sign overlaps with the chord.
Has there been any change recently to lilypond which causes this
regression? Obviously some time ago this snippet gave correct
results...
Werner
___
>> #'minimum-distance = #3.2
> ... and for everyone who is just as lazy as I am: Attached is a
> sample file so that you don't have to try to create a minimal
> example yourself...
Thanks. IMHO the distance between lyrics lines is slightly too big.
Werner
___
> Here's a file with all different spacings from 2.0 to 4.0...
Thanks again. I like 2.5 most.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>> Perhaps I'm wrong, and the whole thing is a non-issue: ghostscript
>> can compute the exact bounding box of an EPS file, AFAIK, taking
>> care of the real dimensions of all glyphs (relying on the outlines
>> instead of the metrics).
>
> I don't know what ghostscript can do, but even if it canno
> In define-markup-commands.scm, there are references to things like
> wordwrap-internal-markup-list and
> make-wordwrap-internal-markup-list. For example, in the function
> define-builtin-markup-list-command, there is the application
> (make-wordwrap-internal-markup-list #t args). I can not fin
> see the german wikipedia
>
> http://de.wikipedia.org/wiki/LilyPond
>
> too bad it's under dispute.
Is it? I don't see such a remark. It is only stated that the picture
shows copyrighted material which can only be cited legally as a very
small snippet.
Werner
> In answer to any question about using such examples in the LilyPond
> documentation (Jan and Werner haven't raised the issue, but I'm
> certain that many readers will be wondering about this), my position
> has not changed: The official LilyPond documentation should not
> include any material whi
>>> Yeah, but that's what gives our mailing lists this particular
>>> charming je-ne-sais-quoi isn't it? :-)
>>
>> That's what you get when you-know-who starts it. :-)
>
> I didn't.
:-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.o
> see
>
> http://codereview.appspot.com/246041
>
> for an even less hacky install.
Very nice. The renaming is a good thing IMHO.
> I had a brief look at the doc of how the fonts are created. You may
> want to look into learning MetaFont - it matches pretty well how you
> created the fonts,
[git commit 829d4293]
Building lilypond with g++ 4.5 fails:
spacing-spanner.cc: In static member function 'static std::vector
Spacing_spanner::get_columns(Grob*)'
spacing-spanner.cc:52:35: error: expected primary-expression before '*' token
spacing-spanner.cc:52:36: error: expected primar
>> I had an idea for an improvement upon your lillypad program. I have
>> a lot of poor quality music scans that I want to convert into your
>> system and was wondering if there is already someone working on
>> making a version that would convert scans into lili files.
>
> automatic recognition o
> Please apply, and cherry-pick to 2.12?
I've just applied the patch (to the current development branch only).
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>>> For selfdescribing glyphs, is the following somewhat defensive
>>> approach sensible, or should 𝄞 be equivalent to the whole \clef
>>> "G" sequence?
>>>
>>> If the latter, it would need modifying the parser, right? That
>>> would have the advantage that note lengths like 𝅘𝅥𝅰 could also be
>>> em
> I'm OK with that, but I still have the concern of documenting it.
> What do we need to do to make sure that the documentation works
> properly?
Good question. I have no real answer.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.or
> this is a general cleanup of Font_metric related code.
Looks good.
> there are some backward incompatible changes (removal of SCM
> functions), but I believe it should be safe, because the functions
> were not useful, little used anyway.
In case someone has been using them, are there workarou
> So, do you all think that we should only go with \with?
\with is fine for me.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue #218 [center staccato over stem instead of notehead] has been
tagged as `fixed' which I consider premature. IMHO, staccato dots
over beams or stems should be *automatically* shifted to the right
position. It's very tedious to handle this manually, and currently I
can't think of any reason
>> Issue #218 [center staccato over stem instead of notehead] has been
>> tagged as `fixed' which I consider premature. IMHO, staccato dots
>> over beams or stems should be *automatically* shifted to the right
>> position. It's very tedious to handle this manually, and currently
>> I can't think
>> The solution is definitely too generic. Look at the attached
>> example. The `toward-stem-shift' applies to all Script grobs which
>> is clearly wrong. In particular, accents shouldn't be shifted at
>> all. Depending on the articulation symbol we need different
>> values.
>
> We already hav
> This is my first time working on the font building system, so I may have
> made some mistakes.
>
> Could someone who is familiar with the font system verify that I've done
> things right?
This looks very nice! I have only two minor formatting nits:
. It seems that you sometimes use spaces
>> . It seems that you sometimes use spaces where you should use
>> tabs.
>
> When should I use tabs instead of spaces?
Just follow the tab/spacing conventions in the file you are changing.
IIRC, `.mf' files use tabs consequently.
Werner
___
> the "LaTeX" syntax for lilypond-book happens to be something like
>
> \begin[verbatim,fragment]{lilypond}
> \relative c' { c << { d e } { b c } >> }
> \end{lilypond}
>
> Unfortunately, this is quite annoying since actual optional
> arguments for environments come _after_ the environment name
> 2. Shadow the default alist entry in default-script-alist:
>
> \layout {
> \context {
> \Score
> scriptDefinitions =
> #(cons
> `("tenuto"
> . ((script-stencil . (feta . ("tenuto" . "tenuto")))
>(quantize-position . #t)
>(avoid-slur . inside)
> install-info complains about lack of 'This file documents' on
> out/lilypond-web.info, so here is the patch.
Uh, oh. Please add a comment right before this phrase to indicate
that it must not be removed or reworded.
Werner
___
lilypond-devel
> I thought that make distclean would put my build tree in the same
> state as it would be in a freshly cloned repository.
Do `git status' to find out whether there are still additional files
in your repository after `make distclean'. Of course, this doesn't
show the files which are ignored by p
Have you seen this announcement on planet.gnu.org?
Werner
==
GNU Denemo participates in Google's Summer of Code 2010 with one project:
A MusicXML Importer.
Google Summer of Code is a global program that offers student
> >
I like this
> c\chord #'(1 3 5 7 11)
I like this too.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>>
>> I like this
>
> Why instead of ?
Honestly, I'm just looking at the syntax form, not how to use it. It
simply looks good to me from a syntactical point of view. Whether
it's praktical or not, I don't know. I've never used chord mode.
Werner
___
[2.13.11; AFAIK, nothing has changed in more recent versions w.r.t.
this problem]
Look at the attached example file and its PDF output. This
title = "ABCDEDCBA"
and this
title = \markup { \fill-line { "ABCDEDCBA" } }
should have the same horizontal position, IMHO. However, this is not
>> This seems to be a bug...
>
> Yes, \fill-line doesn't like being nested:
> http://code.google.com/p/lilypond/issues/detail?id=382
Thanks. However, this is only part of the problem. What I would
really like to do is to insert some vertical space. However, doing
subtitle = \markup { \vspac
>> Thanks. However, this is only part of the problem. What I would
>> really like to do is to insert some vertical space.
>
> Look for "put-mm" in the archive.
Nice, thanks! Somehow I missed this completely inspite of reading
virtually all emails concerning lilypond. I wonder whether this
sh
>> I wonder whether this should be added to the documentation...
>
> Please, please, don't ever wonder about this. If anybody finds
> anything in the archives that might possibly be useful: add it to
> LSR. Don't stop to wonder. Don't think. Do not pass go. Just add
> it to LSR.
Adding to t
>> There are undoubtedly others that feel the same way.
>
> There is no shortage of them: they are easier to recruit than
> coders.
Please, PLEASE! All parties, calm down! Meanwhile the list members
should know how to tackle David; basically, I don't see hostility in
his replies but rather the
>> It looks like \vspace has horizontal extent, which is skewing the
>> text string.
>
> Thomas morgan fixed the analogous problem with hspace earlier.
> Patch posted on Rietveld:
>
> http://codereview.appspot.com/40122
Are you sure this is a link to the right patch set? I see nothing
related
> Try this one instead:
>
>
> http://codereview.appspot.com/1089041
Thanks. Is this change sufficient? Or does the presence of this
token (I mean the \vspace itself, regardless of its dimensions)
trigger an insertion of a space between this and the next element of
the argument list of fill-lin
>> This is a serious question I'd like to ask you. If you were the
>> king of LilyPond, what would you establish as the workflow? I'd
>> really like to hear your opinion.
>
> I'd not prohibit any work flow that can be maintained with
> single-line git commands. That includes posting patch seri
> So how about the ultimate tweak: using a separate engraver? We
> can't have overlapping slurs with a single engraver, for example.
> But if we write something like
>
>
>
> and use @1 with the scope of a tweak, and let it use the engraver of
> subvoice 1 (a subvoice having its own engraver
>> I like this. Up to now noone had ever such an idea, and your
>
> This is false.
Sorry. I've then missed the discussion (or ignored it unconsciously).
> I had the idea earlier and unleashed it on the world. It was called
> the Thread context, and it was a disaster, because it would die or
Folks,
using pdfsizeopt (http://code.google.com/p/pdfsizeopt/) it is
possible, for example, to reduce the size of `notation.pdf' from
24MByte to 15MByte. I consider this quite impressive.
[All used components of pdfsizeopt are freely available, but one of
them (Multivalent) is not free in the
Look at the attached image. Isn't it possible to virtually split a
volta bracket into three parts, namely left, middle, and right,
___ __ _
|1. ++|
where the middle part has a much smaller vertical extension than the
left and right part? Th
> Perhaps make a bug report so that this suggestion does not get lost?
> Makes perfect sense to me.
Done, issue #1097.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> * Why are many lines wrapped at 60-80 (while some at 100)?
> * This makes reading the code hard, console mode wrapping
> * seems deprecated to me (especially on my 24'' monitor). I
> * think that 95-110 chars/line are better in most cases then
> * wrapping @ 80.
I
> This is a feature I've wanted to add to LilyPond for a while, and I've
> posted a patch set on Rietveld:
>
> http://codereview.appspot.com/1730044/show
>
> Any comments are appreciated, especially regarding the syntactic
> requirements of the new command.
Looks good to me. It would be nice i
>> Looks good to me. It would be nice if I could say
>>
>> \path #0.25 #'miter #'square ##f #samplePath
>>
>> instead of using numbers for the second and third parameter. Is this
>> possible?
>
> How about defining constants path:miter and path:square instead? Then
> \path does not need speci
>> From a syntactical point of view, I can't see an immediate benefit of
>> saying
>>
>> #path:miter
>>
>> instead of
>>
>> #'miter
>
> Hm? Could you explain what constitutes a "syntactical point of
> view" in your book?
I probably misformulated. I simply mean that the `path:' prefix is an
The organ template given in `fundamental.itely' lacks an important
property, namely the limited stretchability of the pedal staff.
Without this, the distance of the pedal staff w.r.t. the other two
staves can become far too big.
I thus suggest that it looks like this:
<<
\new PianoStaff <<
>> PS: I would *really* like to override just the stretchability by
>> saying
>>
>> \override VerticalAxisGroup
>> #'next-staff-spacing #'stretchability = #5
>>
>> instead of specifying all properties of `next-staff-spacing'. Is
>> this already possible? Otherwise,
>> Unfortunately, this (IMHO absolutely necessary) setup no longer
>> qualifies the organ template to be part of `fundamental.italy', I
>> believe...
>
> If this setup is truly "absolutely necessary", might it be worth
> adding to one of the ly/ files? \organSpacing, or something like
> that?
W
What do you think about moving
Documentation/contributor
Documentation/css
Documentation/essay
...
to
Documentation/en/contributor
Documentation/en/css
Documentation/en/essay
...
for orthogonality with the other languages? Additionally, the
`Documentation' directory is already
> The organ template given in `fundamental.itely' lacks an important
> property, namely the limited stretchability of the pedal staff.
> Without this, the distance of the pedal staff w.r.t. the other two
> staves can become far too big.
Here's a documentation patch.
Werner
> The patch looks fine, but as this is the only place in Learning that
> mentions sub-properties and stretchability of staves there should be
> index entries for these two concepts.
Done.
Werner
==
--- fundamental.itely
Currently, if I say
info lilypond
I'm forwarded to `lilypond-usage'. If I say
info LilyPond
I'm forwarded to `lilypond-notation'. Is this really intentional?
IMHO it's silly to get different targets depending on whether to use
uppercase and/or lowercase letters.
If possible, I would lik
Can the new beaming algorithm handle issue #11 gracefully? Currently,
the result is still incorrect.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I don't like typos, so find attached a patch (against git master) to
> fix them in the English manual. Tried to omit all controversial
> bits, but just in case, I'd be happy to redo.
Applied, thanks!
> If you are interested in more: There are typos in the English part
> of translated manuals;
> > Additionally, we want two spaces after a full stop in the source
> > documentation files.
>
> Ah, well, lemme see what I can do.
:-) We have a style guide; say `info lilypond-contributor' (I just
see that there isn't a proper menu entry for it in the `dir' file) and
go to the `Text formatting
> Actually I am not sure that 'i.e.,' is necessary. 'i.e,' is not
> correct, so 'i.e.' without a comma is fine as far as I know.
Well, `i.e.' is a shorthand for the Latin `id est' which translates to
`that is', and for the latter, you always need a comma after the `is'
if you continue with a sent
> Here we go with spacing after end of sentence.
Thanks a lot! Applied to git. It's really great that you have
obviously far too much time for providing such patches :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists
>> Should it be wrapped in a full review process?
>
> I think so. The full review process for removing old stuff is
> generally very short and sweet (post the patch, somebody important
> says OK), so I don't think it hurts a bit to do it.
Well, IMHO, for trivial things: Just do it!
Werner
[Wearing the FreeType maintainer hat]
>> I see a really weird C++ construct in this (short) file:
What's the problem?
>> lily/freetype-error.cc
>>
>>
>> const struct Freetype_error_message
>> {
>> FT_Error err_code;
>> const char* err_msg;
>> } ft_errors[] =
>>
>> #include
>>
>> As a C programmer, it took me about 30 seconds (or less) to twig what it
>> was doing.
>
> Could you take 120 seconds or so to explain what it's doing? I'm
> supposed to be teaching first-year C programming, and I haven't run
> across this before.
Here is the documentation from fterrors.h:
> My siblings and I used to entertain a communication style full with
> insults and deprecatory remarks, sort of like a playful reminiscence
> of times when we were still kids. And of course, the more of us
> were present at some occasion, the more fun we had.
Indeed. My children and I are also
> I must not be understanding this correctly, [...]
You must not? Interesting. :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
>> I've attached fontforge images of two broken glyphs;
BTW, this mail sits in the mailing list queue since the images are
rather large...
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypon
I wrote:
> I've attached fontforge images of two broken glyphs; [...]
Listmaster, please approve this mail sitting in the queue!
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> Can you open an issue directly on the tracker and post your
> attachments there?
Done. It's issue #1335.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> I did the faulty varsegno sign. I read the tracker and wanted to
> reproduce your observations, but I am unable to run mf2pt1, this
> command doesn't seem to exist. How can I obtain it?
It's part of lilypond. Here the relevant lines from my log file
during `make all' (slightly adapted):
in
> So the advice
> ---
> The recommended calling sequence of mf2pt1 is
>
> mf2pt1 --rounding=0.0001
>
> You need mf2pt1 version 2.1 or newer.
> ---
> in README should read
>
> cd mf/
> ln -s out/mf2pt1.mem .
> FONTFORGE=foo ../scripts/build/out/mf2pt1 --rounding=0.0001 feta13
Yes. For deve
>> Um, that's what I tried before, but I still got intersections
>> (which were smaller than before, but still visible in fontforge at
>> 200%), so I had to introduce the tensions.
>
> When I applied and tested your patch, there were still grazing
> intersections visible in fontforge at 400%.
>
>
>> Don't use `penstroke' but `fill'.
>
> That was my thought, when looking at the glyph. Find the
> intersections, and draw the relevant paths for the entire outline
> and subtract the relevant paths for the holes.
This is probably overkill. FontForge is quite good in doing this for
you, provi
> Here's a patch for the accordion push symbol.
This looks fine.
> It would have been simpler if I had just drawn two straight lines:
>
> draw z1
> -- z2;
>
> draw z3
> -- z2;
>
>
> This would seem to be allowed by the instructions in README, but I
> get the sense that mf2tp1 reall
>> This is probably overkill. FontForge is quite good in doing this for
>> you, provided the intersections are well defined. `fill' is necessary
>> because you can't exactly control the direction of the outline by
>> using `penstroke'.
>
> But if I change from penstroke to fill, using zkr to go a
> + ... {dir (180 - loopangle)}z7e{dir (180 - loopangle)}
This is too much :-) The following
+ ... z7e{dir (180 - loopangle)}
is sufficient. A new patch attached (to preserve tabs for dull mail
programs).
Werner
--- feta-scripts.mf.old 2010-10-17 13:40:03.0
> The README also says that we shouldn't apply transformations to
> fills, but instead transform the path then fill the path. The
> current varsegno transforms the penstroke, which I think is contrary
> to this instruction.
Yep. For this glyph it works accidentally. Thanks for noticing, I've
m
> why does LyricText #'font-series default to #'bold-narrow?
This looks like an oversight. The change is from 2004 where TeX has
been still used as the output device.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu
In the documentation, there is an example how to convert a texinfo
file to a newer version:
convert-ly --from=... --to=... --no-version *.itely
A similar command can be used for lilypond-book input files:
convert-ly --from=... --to=... --no-version *.tex
What I consider problematic is that
>> To sum up: Keywords like `orientation' are far too frequent in
>> normal text to be handled without protection if convert-ly is
>> applied to lilypond-book (or texinfo) input.
>
> I'm fine with this being a command-line option to convert-ly.
> Actually, this could even be the default -- as long
[current git]
It seems that it is not possible to have a comment within #{ ... #}.
In this example
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music ; $
#}
)
\relative {
\T { c c c }
}
lilypond complains about
>> It seems that it is not possible to have a comment within #{ ... #}.
>
> I believe it is (using %, as you point out).
Have you tried it? For me, it doesn't work.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.
> This does work:
>
> foo =
> #(define-music-function (parser location music) (ly:music?)
>#{ $music % comment
>#})
>
> { \foo a }
Interesting. This
T = #(define-music-function (parser location music) (ly:music?)
#{
\times 2/3 $music % $
#}
)
>>> The README also says that we shouldn't apply transformations to
>>> fills, but instead transform the path then fill the path. The
>>> current varsegno transforms the penstroke, which I think is
>>> contrary to this instruction.
>>>
>> Yep. For this glyph it works accidentally. Thanks f
> \language italiano (like \clef treble) is very consistent. So
> you've convinced me that a string argument is OK.
Mhmm, in the documentation, please use
\language "italiano"
instead. Even newcomers must get used to it...
Werner
___
lilypo
>> This looks like an oversight. The change is from 2004 where TeX
>> has been still used as the output device.
>
> Ok. So #'medium should be correct now?
Yes. Patch applied, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
>> Don't say @co...@var{...}} but @var{...}.
>
> Hmm, have I misinterpreted Mark's post here?:
>
> http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00285.html
Well, have a look at section A.17 (Scheme functions) and see how
function names and arguments are formatted. Mark is referri
The doc string of ly:gulp-file doesn't document `size'.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
The doc string of ly:score-set-header! doesn't document `module', and
it's quite cryptic what this argument is good for.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
1401 - 1500 of 3522 matches
Mail list logo
