Hello,
I'm transcribing a few pieces of late Renaissance polyphony and wanted
to use the Completion_heads_engraver to automatically split long notes,
as described in the manual. But all I get is a kind of an endless loop
or something.
Lily halts at "Interpretation der Musik... [8] [16]" and no
Hi all,
after half an hour of commenting out my source file, I've at least found
out what's causing Lily to hang.
It seems durations longer than a whole note can't be splitted for any
reason.
\version "2.13.0"
<<
\time 4/2
g\longa
>>
% Same problem:
%<<
% \time 4/4
% g\breve
%>>
\layout {
I think I've found the error. In duration.cc, starting from line 37, the
left-shifting-operator << is used for some calculation.
This works, if the amount of shifted bytes is positive; otherwise the
operator returns zero.
In some cases, f.e. if r.num(); is bigger than r.den(), k is negative,
but
Hi all,
I don't completely understand the way how Duration::Duration(Rational r,
bool scale) converts a rational number into a note and dots, but
it's clear that the Completion_heads issue with splitting up breve and
longa notes was caused by the way << behaves when given a negative
number as s
Both fixed. Other comments?
>From c30a3049063acb270332d6f83a43a808a4893b16 Mon Sep 17 00:00:00 2001
From: root
Date: Thu, 26 Feb 2009 13:19:48 +0100
Subject: [PATCH] This fixes an endless loop in duration.cc:67 when Duration::Duration(Rational r, bool scale) is called
with r.num() >= 2 * r.den(
moment I can't imagine cases where this could happen.
Can't happen, AFAICT: by the definition of k, k >= -intlog2(p) and so
-k <= intlog2(p) <= log2(p). Therefore 2^{-k} <= p and so (p >> -k) ==
p*2^k >= 1. That is, you never shift everything away.
Ok, so what's the next step now?
Joe Neeman wrote:
On Thu, 2009-02-26 at 13:24 +0100, Michael Käppler wrote:
Both fixed. Other comments?
Just one: can you set the environment variables GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL so that an actual name and email show up in the patch?
Done.
>F
Hi all,
I recently noticed that ligatures are not automatically noticed as a
melismatic section. That means, I always have to
use the syntax: \[ bla \melisma bla \melismaEnd \]
However, I would consider ligatures to be melismatic in >any< case.
What's your point?
Regards,
Michael
__
Hi all,
a few days ago I asked this on the -user list and got no response:
If a melisma occurs on a word's last syllable, I want lilypond to
calculate the length of the melisma and automatically decide, whether an
extender line is appropriate or not. The user should be able to enter a
value for
Hi all,
I know that this was on the list some time ago, I remembered when
reading
http://lists.gnu.org/archive/html/lilypond-devel/2009-03/msg00238.html
Am I right that there is currently no possibility to let lilypond set
different margins for odd and even pages?
Can someone help me to further
Hi all,
after transcribing some baroque vocal and instrumental pieces I noticed
that one articulation sign is used very often, but not provided by
lilypond. It looks simply like a line, vertically placed above the note
head. One could confuse it with the \staccatissimo symbol, which looks
more
Hi Valentin,
Greetings,
here is how to achieve what you're looking for (it has been added to
the documentation snippets as well, since this notation is indeed
common):
http://lsr.dsi.unimi.it/LSR/Item?id=620
Thanks for adding this to the snippets. Maybe I'll post a better
explanation later. A
Valentin Villenave wrote:
For example, if I have understood this correctly, your snippet can't scale
the font-size according to global-staff-size at this moment.
Yes it can.
Sorry... I should have looked more carefully at this.
Also it would
be nice if LilyPond could determine the rig
Attached are two samples for long and short strokes with varying
width. The long strokes have height = staff_space, the shorter ones
height = 0.8*staff_space (is that a reasonable choice?). Each file
contains strokes of each type with ten different widths, namely
i*0.05*staff_space, for i=1,..,1
Additionately, maybe it would be nice to increase the >relative<
thickness of the stroke on smaller staff sizes as it's described in NR
4.2.1 for the Feta font. Otherwise the line will look too thin at
smaller staff sizes, I think.
Regards,
Michael
Me too, #4 or #5. But I think the long stroke could be longer, maybe
1.2*staff_space or so?
Like in the attached file? In this case, I'm inclined to favour #5 (or
maybe even #6), but I'm only judging this based on the appearance on
the screen because I don't have a good printer at hand. T
Hi all,
I'd like to test Joe's new spacing code. Has it already been merged into
master or do I have to pull from dev/jneeman?
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-d
BTW, what is the best place to report bugs with the new code? I'm
assuming that -bug is for mainstream code and problems with experimental
versions should be discussed here.
I think this thread is a good place.
Joe
Hi Joe,
many thanks at first! Great work!
I ran your new code on a se
Hi Maximilian,
1) The code in scm/page.scm is able to test whether left-margin and/or
right-margin was specified by the user in the \paper block (if this
isn't the case, the value is #f). However, the same doesn't seem to be
true for line-width because this variable _always_ has a value (i.e.,
it
This is because line-spacing is done earlier than page-spacing - Lily
needs a value for line-width when doing horizontal spacing. Therefore
line-width isn't really discarded - but later in page.scm it is
overwritten, so you can't see it in the page layout.
What I wasn't unable to figure out is
Hi all,
here is the first draft of a patch concerning the margin settings for
review. (I would like to upload it on Rietveld but I don't know how)
The goals are:
- make default margin settings accessible from *.ly stuff (now in
paper-defaults-init.ly)
- set line-width automatically depending
Mark Polesky wrote:
See CG 8.7.7 "Post patch for comments":
http://kainhofer.com/~lilypond/Documentation/contributor/Adding-or-modifying-features.htm
Thanks, Mark. I've updated my git package and installed git-web but
git-cl doesn't work for me.
Doesn't it belong to the normal git package?
Che
Neil Puttock wrote:
This and the following docstring lines are too long.
Is there a common line length for docstrings? This should also be
mentioned in the CG, I think.
+ Real paper_width = scm_to_double (lookup_variable (ly_symbol2scm
("paper-width")));
+ Real left_margin_default = scm_t
It's completely separate from git.
The easiest way to get it is to clone the repository,
git clone git://neugierig.org/git-cl.git
then add symlinks for the scripts `git-cl' and `upload.py'.
Neil (or someone), can you add this info to the CG?
For a single commit it is enough to do ju
Mark Polesky wrote:
Michael,
Don't forget, you need to mention on -devel that you've posted
to Rietveld, and include the link. You'll also need to close
it when it's approved/resolved (CG 8.7.9).
Here's Michael's patch:
http://codereview.appspot.com/104085
- Mark
Hi Mark,
first I was uns
Hi Carl,
Usually we like to keep responses to reviews on the -devel list, so I've
copied this there.
Sorry, that wasn't intended. It was late yesterday and I didn't notice I
pressed the wrong button... ;)
Oh -- I misunderstood the meaning of the FIXME.
I think I'd recommend changing the set
Hi Neil,
These are unsafe, since they return SCM_UNSPECIFIED instead of a Real
if the paper variables aren't defined; using robust_scm2double () here
will ensure a default is returned.
You can see the consequences of variable lookup failure by running
bookparts.ly
(http://git.savannah.gnu.org/g
Probably because cloning an output-def does not copy the parent_ pointer
(so recursive lookups are broken by ly:paper-params-normalize).
Joe
Thanks, Joe, for pointing this out. Now, after thinking a lot about it,
I will try a different approach and control/modify the paper values
immediat
Hmm...there's a new problem I don't understand.
If I set a breakpoint in lily-parser.cc:225 (get_paper) and call
normalize() from there, it seems that all "default" variables which are
set in paper-defaults-init.ly aren't accessible.
What's the reason for this? Are the *.ly-initfiles parsed lat
Michael Käppler wrote:
Hi Joe,
get_paper is called more than once for each paper block. The first time
is probably from parser.yy:847, which actually _creates_ the first paper
block (so no variables have been parsed at all). Perhaps a better place
for normalize() would be after parser.yy:830
Hi all,
just a minor nitpick: What is the reason that the indentation in
parser.yy seems to be different than in other C++ files?
I found it a little confusing to see that e.g. if-constructs in the
parser are indented this way:
if
{
foo;
}
And in "normal" files that way:
if
{
foo;
}
Joe Neeman wrote:
I think the concatenation happens in parser.yy:847. Rather than creating
a new paper block every time \paper is seen, we just make a clone of the
most recent \paper block and start appending stuff to it. I don't think
there's a way (in the parser, at least) to tell when we've fi
[CC to -devel]
(nobody checks the regression tests for each release, for example
-- and that's trivially done with a web browser!)
That reminds me of an idea I recently had: Wouldn't it be possible to
automatically generate a sort of "checksum" for each regression-test
output-file and compar
Reinhold Kainhofer wrote:
Isn't this exactly what we already have (make test-baseline to create the
Argh, how embarrassing! Sorry for the noise.
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/li
Hi all,
it took me quite a while but here is a new approach for review:
http://codereview.appspot.com/109051
More in a few hours.
Cheers,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-de
Hi Carl,
LGTM. I do have one comment about tests for != SCM_UNDEFINED. It think
there's less chance of confusion when testing for "undefined" rather
than "not undefined", which is "defined". The double negative (not
undefined) can potentially be confusing.
that's a good point. However, I'm goi
More in a few hours.
I won't be able to check my mail during the next week so don't expect me
to reply until then.
Anyway, I want to ask you some things before I leave.
1. Can someone run the regression test suite for me? I ask because I've
never done this and my computer is extremely slow,
Hi Neil,
1. Setting system-count = 1 causes a segfault (try running the file
Documentation/general/examples/granados.ly)
I've checked out a fresh master and it seems that it also crashes
without my patches. Can you reproduce this?
The problem occurs after page-breaking.cc:525 I think. There
Mats Bengtsson wrote:
I can process Documentation/general/examples/granados.ly without
crashes, using latest GIT version of today.
Me too, but test the following snippet:
\version "2.13.4"
\layout {
system-count = #1
}
\repeat unfold 20 { c d e f }
Regards,
Michael
___
Hi all,
here's the new version which includes all fixes but for the
"system-count=#1" issue, on which Joe can take a look on I hope.
http://codereview.appspot.com/109051/
Cheers,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http:
Hi Joe,
I agree; it seems to have no effect. It also appears not to be
duplicated in the other backends, despite the comment. Perhaps it's
obsolete code?
Maybe. I hope somebody on the list (Han-Wen?) can explain why this was
added. Is this a kind of meta-information, which is just stored in t
Hi all,
please review this patchset, which is based on my former changes:
http://codereview.appspot.com/115065
Cheers,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Patrick,
I recently noticed that /input/regression/bookparts.ly gives the warning
"Missing stencil expression: utf-8-string" what I think is related to
your patchset.
Could you please have a look at this?
Thanks,
Michael
___
lilypond-devel maili
Hi all,
Hmm... was there any progress since July on this topic?
I'd like to year if there's anything new... ;)
Cheers,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi all,
I rewrote the patchset to have less doubled scheme code and make it
extensible.
Any comments are very welcome.
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi Carl,
thanks for your review.
But the things they stand for are symbols elsewhere in the code, so I'd
prefer using symbols here.
Sure, but...
http://codereview.appspot.com/115065/diff/1001/1003#newcode232
Line 232: ((value-symbol (string->symbol (string-append (car value)
"-default")))
I you
[Forgot to cc' the list]
Hi Carl,
I agree that it's not much of a problem here, but I still think it's better
to use the LilyPond idiom assoc-get instead of the more general Scheme idiom
assoc.
dumb question: Why is assoc-get "LilyPond idiom"?
grep "(assoc " scm/* | wc - l
68
grep "(assoc-ge
Hi all,
I'm not very familiar with git for now, therefore I have got a question.
Let's assume I've checked out a fresh master/origin and did some commits
on top of it. How can I concatenate this commits in one to create only
one patch?
Regards,
Michael
___
Hi all,
thanks to Joe's latest patch concerning the system-count issue I
concatenated now all the changes in one patch and rewrote
the commit message. Could please somebody run the regression test suite
and build the docs to see if all bugs have gone.
This doesn't include the margin scaling pat
Hi Carl,
(was it your intention to discuss this off-list? I ask because you
didn't cc the list for the last two times.)
Hmmm -- I see your point.
Without looking into the code for each of those grep results, I couldn't
answer. But assoc-get is defined in LilyPond, and was certainly recommended
Hi all,
I've just removed some code from page.scm that becomes obsolete through
the patch.
I would be really happy if somebody could test this for regressions. The
problem is that for me it takes more than 12 hours to run a "make doc"
and for this time I can't do anything other.
(Just to give
Hi Carl,
LY_DEFINE (ly_assoc_get, "ly:assoc-get",
2, 1, 0,
This line is wrong; you need to have the total of these three numbers
be the total number of arguments.
Yes, I forgot to adjust this.
If you change this to 2, 2, 0, then strict-checking will be an optional
argument,
Hi Neil,
I'm fine with all your comments...
The regression test would probably benefit from being split into
several separate tests, particularly the final check-consistency
setting, which can then have #(ly:set-option 'warning-as-error #f)
added to it in anticipation of the mythical time when we
There are some subtle spacing changes in the docs, but no breakages:
quite often the line width is slightly shorter, resulting in tighter
spacing (see the PNG for expressive-headword.ly attached, which is
eleven pixels shorter than the current example on kainhofer.com).
Maybe this is the sam
Hi,
please look again.
Regards,
Michael
>From 33c05dd7df4000d7f25d2903e2555d9ca86c2e1f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 01:47:00 +0200
Subject: [PATCH] Introduce new handling for paper margin settings.
* Make default margins accessible in
You need to amend the definition of the method in lily-guile.hh, since
it's also used directly in the C++ code, with no optional arguments:
53 SCM ly_assoc_get (SCM key, SCM alist, SCM def);
Hmm... I don't exactly understand the LY_DEFINE macro. Is it possible to
implement this
with overloa
Many thanks for all helpful comments.
Attached is the revised patch.
What's the reason that chain-assoc-get is defined separately in
lily-library.scm:210, though ly_chain_assoc_get exists?
Regards,
Michael
>From 740bd0fcb035099086e9e60a325019fdf25595d4 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?
Here's the next revision.
+ string key_string = ly_scm2string (scm_object_to_string (key,
SCM_UNDEFINED));
I think it's OK to leave out the print function argument, since it's optional.
Are you sure? I tried this and IIRC it failed to compile. If I read the
guile manual correctly, it is
Sorry, silly me. :)
I think we're nearly there. I'm just about to do a regtest check just
to be sure.
Just a few remaining nitpicks:
- trailing spaces
- long lines
That should be fixed now.
Is there a default for maximum line length?
Regards,
Michael
>From baaffd7f66ef05e6adb9562272b480
Hi Neil,
There are some subtle spacing changes in the docs, but no breakages:
quite often the line width is slightly shorter, resulting in tighter
spacing (see the PNG for expressive-headword.ly attached, which is
eleven pixels shorter than the current example on kainhofer.com).
now I know wha
Hi Neil,
Thanks, it's applied.
Great. The next step is attached. Can you please run a regtest?
Regards,
Michael
>From 2aa0ede53ec2b8e03f47c3b0f525cfbc636c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sun, 13 Sep 2009 22:11:36 +0200
Subject: [PATCH] Turn assoc
I think lilypond-book inserts line-width only when 'quote' or
'lilyquote' is specified (or 'linewidth' itself, of course).
I don't think so. Look at lilypond-book.py:951. This value preserves if
no option is set. You can verify this by running this small tex file, if
you want:
\documentclass
Hi Neil,
now I know what's the reason. The attempt I made with line-width-cropping
doesn't really work,
since if there are several \paper blocks line-width-cropping affects all and
breaks the other settings.
Ah, I see.
I have to admit the lilypond-book code is very difficult to understa
Hi Neil,
Thanks, also applied (no regtest problems to report).
that's nice. Here's the next step.
Btw. what's going on with the paper-margins patch? Could you run another
regtest / doc build?
Regards,
Michael
>From 7e0190ccc76f602d1e803f15832af780d449d863 Mon Sep 17 00:00:00 2001
From: =?
Hi Neil,
Hmm, some of these don't look too secure. :)
Whoops...
(let* ((table (ly:output-def-lookup layout 'label-page-table))
- (label-page (and (list? table) (assoc label table)))
- (page-number (and label-page (cdr label-page)))
+
Hi Neil,
thanks for reviewing and applying.
I think what now should be done is to check all assoc-get calls whether
they should use strict_checking or not.
In some cases this can be quite difficult IMHO and it's a far more
time-consuming task than what I've done. Maybe Mark can do this? I think
Neil Puttock wrote:
2009/9/14 Michael Käppler :
Hmm, I can't reproduce this here. Can you try again and send me an png if it
still fails?
It's still pretty bad; see the attached image.
This is weird. I've just checked out a fresh master, did a make clean
and
Hi Neil,
now it's clear to me what happened.
I concatenated the \paper blocks of granados.ly and example-header.ily
together for testing. Because then the fixed line-width from
example-header.ily won't be overwritten by (set-paper-size), it looked
as compressed on master as on my testing branch
Hi all,
I'd like to propose the following as a possibility to provide a simple
progress indicator for the "Preprocessing graphical objects" stage.
I'm happy to read your comments.
http://codereview.appspot.com/122051
Regards,
Michael
___
lilypond-
I've just finished a regtest check and clean docs build, and as far as
I can tell, everything looks fine; there are no warnings reported for
any of the A6-size paper tests, and all the snippets I compared are
virtually indistinguishable.
Wow, unbelievable! Now ready to apply?
___
Have you tested this using an editor? I've tried a fairly long piece
No, I haven't.
using Frescobaldi and LilyPondTool, and neither likes the backspaces:
Preprocessing graphical objects... (1 %) (2 %) (3 %)
(4 %) (5 %) (6 %) (7 %) (8 %) (9
%
This comment reveals a larger issue than the code it comments, so I
suggest to move it away from lilypond-book.py and rewrite it in Git
commit message and/or an issue on the tracker.
Here you are.
Valentin, can you please open a new issue on the tracker for this?
I suggest the following mes
If my test runs are indicative of the average timings, then you might
as well junk all the stages apart from the last, since they only take
up a few seconds of the preprocessing time. Of course, that then
I can confirm this for most cases. But I've had other experiences too
AFAIK; Could you
Are there still any objections against applying?
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi all,
I'd like to know how I can do a git pull on all branches simultaneously.
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
There are a few minor nitpicks remaining with whitespace and
formatting, but I'll sort those out once I've applied the patch.
Hmm, that's bad. Can you tell me more exactly what's happened? I thought
the whitespace issues have gone since I've configured vim to
automatically remove trailing w
Hi all,
I'd like to post this patch for final review. It was already reviewed a
while ago by Carl.
It aims at scaling paper margins according to which paper size was chosen.
Hopefully no whitespace / style issues this time.
Regards,
Michael
>From e0377c12766f4820512eaa56db22af58930a1891 Mon
Hopefully no whitespace / style issues this time.
Argh... forget this.
Here's a revised version.
Cheers,
Michael
>From cf099ca1134b02a813e47109c684a8a100b04253 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default
Would you mind preparing a patch to document the changes (in
particular, right-margin)?
Here you are.
The changes that aren't applied yet (default margin scaling) are already
integrated.
Regards,
Michael
>From 6839cb0e9fa85f2ea7f1ee42faa6877408387704 Mon Sep 17 00:00:00 2001
From: =?utf-8
Hmm... no comments at all?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
I've just done a regtest check, and there are many changes.
The following warning is reported extensively:
margins do not fit with line-width, setting default values
I can send you the results or upload them somewhere if you'd like to
take a look (the compressed out/ folder is 3.6MB).
I'm
Ok, that should be fixed now. Can you please verify?
Regards,
Michael
>From 117824090d54c9607af476dee9545bd957f5ce96 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default margins depend on paper size.
* Make indent a
Hi Neil,
thanks for your review. It's all ok (Though it's hard to see how simple
it could have been with flatten-list...)
However, I don't understand the thing about the old regtests. I thought
that both page-turn-page-breaking-auto-first-page*.ly would need two
pages to demonstrate the functio
Here you are.
What about the docs patch?
Regards,
Michael
>From 3cda0a2d5326b2359784ca1e10b04b078abd2cb9 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default margins depend on paper size.
* Make indent and short-in
Hi Neil,
I hope I've lost nothing.
Regards,
Michael
>From aa34f02a9eb85aaa39d3ff45f31597d279330461 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Sat, 12 Sep 2009 21:55:17 +0200
Subject: [PATCH] Let default margins depend on paper size.
* Make indent and short-indent de
Hi Neil,
Looks fine.
Good.
Sorry to be a pain, but there's one more thing I missed: all the
regtests which rely on default settings need to reset the default
paper size, otherwise the line-width setting from the lilypond-book
preamble messes up the spacing.
Okay. I hadn't thought about t
Hi all,
please review this patch:
http://codereview.appspot.com/144049
It's aim is to provide the possibility for setting different margins on
odd and even pages.
Regards,
Michael
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.
Hi Neil,
@itemize
There are a few places where a full stop could do with an extra space,
but the rest of the patch looks fine.
You've mentioned check-consistency in the main discussion, but you
might like to add it to `Other layout variables' too.
Fixed.
Regards,
Michael
>From 0b9a3c726c5b
Now I've rebuilt the docs, I've changed my mind slightly. :)
Otherwise it would have been way too simple so I'm not surprised... :))
Better now?
Regards,
Michael
>From 227afb026946e543eafa228bd4ff42f5bb6003fa Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Fri, 30 O
http://codereview.appspot.com/144049/diff/1/2#newcode15
Line 15: binding-offset = 5 \mm
I think this deserves a separate test, otherwise it just looks the same
as an ordinary page with slightly bigger but equal margins.
Ok...
http://codereview.appspot.com/144049/diff/1/3
File lily/output-def.
n.putt...@gmail.com wrote:
Hi Michael,
This looks OK, apart from a few indentation issues. In particular, the
whole of `set-paper-dimensions' is slightly off.
Cheers,
Neil
Hi Neil,
I'm slightly unsure what to do now. Since I'm a little bit tired of this
indentation stuff I gave emacs a try (
Those comments should have double semicolons, according to Scheme style.
Ah...
Does it make sense to use this emacs script, if yes, what do I have to keep
in mind when using it?
If you're using Vim, you should be fine (though I read somewhere that
it occasionally indents Lisp and Sch
Here you are.
Regards,
Michael
>From 5deda137b69c7110b6fc02046497362788347e34 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?=
Date: Fri, 6 Nov 2009 14:25:52 +0100
Subject: [PATCH] Docs: Add documentation for paper variables involved in two-sided mode.
---
Documentation/notati
Hi Werner,
It seems that the algorithm for optimal page turning is designed for
recto and verso pages. In other words, the `first-page-number' paper
variable is also an important parameter controlling the layout.
Is this correct? However, it is mentioned nowhere.
I think this is correct. Ho
Am 06.02.2020 um 22:55 schrieb thomasmorle...@gmail.com:
https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/common-notation.itely
File Documentation/learning/common-notation.itely (right):
https://codereview.appspot.com/579280043/diff/563480043/Documentation/learning/
Am 22.04.2020 um 22:16 schrieb fedel...@gmail.com:
On 2020/04/21 16:24:47, michael.kaeppler wrote:
Hope this is the right way to submit translation fixes. Any advice is
appreciated.
I think goin' through Rietveld is overkill in this case.
You'd better send a git formatted patch to lilypond-de
Hi all,
while fixing some broken URLs in the documentation, I noticed that
some URLs do have possible line breaking points manually specified like
@uref{http://@/www@/.schemers@/.org}
Others are just plain URLs like
@uref{http://www.schemers.org/Documents/Standards/R5RS/}
Is there a reason for
Am 10.06.2020 um 11:08 schrieb Werner LEMBERG:
Is there a reason for this inconsistency? How is it supposed to be?
From what I gather, that’s merely because Werner’s been looking
elsewhere for the past 16 years :-)
https://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=cae1b39741a43547e3f4ad
Am 17.06.2020 um 10:52 schrieb Valentin Villenave:
Greetings everyone,
I’ve noticed a recent regression with `make doc’: when it reaches
Documentation/ly-examples, gs fails on a bunch of files with the
following error message:
Command: /home/work/lilypond/out/bin/lilypond -dpreview
-dresolution=
Am 11.06.2020 um 15:22 schrieb Werner LEMBERG:
I can prepare a version of the docs with all occurences of '@/'
removed and '@urefbreakstyle before' set, so that everyone can
compare and build an opinion on this.
Great, thanks in advance. I suggest that you use the `texinfo.tex`
file directly fr
1 - 100 of 279 matches
Mail list logo
