Graham Percival wrote Saturday, January 16, 2010 10:26 PM
One idea that I've been considering for over a year is making a
social mailing list for lilypond developers.
Is there any interest in this?
Yeah - sounds fun. I miss the banter between
you and Valentin. And, more importantly,
i thinke there is a remainder from earlier versions in the notation
reference:
4.6.2 Changing spacing
between-system-space = #0.1
should be replaced by
between-system-spacing = #0.1
(version 2.13.11)
--
View this message in context:
Am 16.01.2010, 12:32 Uhr, schrieb Reinhold Kainhofer
reinh...@kainhofer.com:
There are some other issues I notice with the layout:
1) For my taste the piece names are too close to the previous score (and
too far away from the one they are attached to).
2) The distance between the last
Patrick,
I'm a bit confused by some of the changes to the git commands for
release/unstable. Doesn't
git merge release/unstable
produce the ugly (and pointless) merge remote branch in the git
history for master? I'd rather avoid that, and I thought that
git cherry-pick release/unstable
On Sat, Jan 16, 2010 at 06:19:08PM -0700, Carl Sorensen wrote:
On 1/16/10 11:14 AM, pound...@lineone.net pound...@lineone.net wrote:
When building LilyPond I was confused that the general build
instructions (3.1.3) were different from the instructions for building
on a Virtual Machine
On 2010-01-17, Graham Percival wrote:
Patrick,
I'm a bit confused by some of the changes to the git commands for
release/unstable. Doesn't
git merge release/unstable
produce the ugly (and pointless) merge remote branch in the git
history for master? I'd rather avoid that, and I thought
If you get a build error while processing the docs (even with just
plain make), do a
make -C scripts
and then
make
again. The build system doesn't pick up my latest change automatically.
Cheers,
- Graham
___
lilypond-devel mailing list
On Sun, Jan 17, 2010 at 6:27 PM, Patrick McCarty pnor...@gmail.com wrote:
On 2010-01-17, Graham Percival wrote:
I'm a bit confused by some of the changes to the git commands for
release/unstable.
It's a trade-off.
Ah, ok. I now agree that the merge is the better option.
[1] In case of a
