Pierre Perol-Schneider | 4 Sep 10:17 2015

'TabStaff' & 'RemoveEmptyStaves'

Hi Squad,

Following a french discussion:

\version "2.18.2"
%\version "2.19.25" %% <= or

ma-musique = {
  \repeat unfold 4 c'1 \break
  \repeat unfold 4 r1 \break
  \repeat unfold 4 c'1

\new TabStaff \ma-musique

%% The 'Default_bar_line_engraver' seems to bug
%% in case of 'TabStaff' with a 'RemoveEmptyStaves' context:
\new TabStaff \with { \RemoveEmptyStaves } \ma-musique

I did not find any registered issues.

Simon Albrecht | 4 Sep 02:01 2015

Ties within chords inconsistency


consider the following example:
\version "2.19.25"

\new Voice << { c''^~ c'' } { a'_~ a' } >>

\new Voice << { <c''^~> c'' } { <a'_~> a' } >>

{ <c''^~ a'_~> <c'' a'> }

Contrary to (at least my) expectation the first example gives

tie-within-chord.ly:6:33 <0>: warning: Two simultaneous tie events, 
junking this one

\new Voice << { c''^~ c'' } { a'

_~ a' } >>

and applies the first tie to both notes.
The other two give correct output, and it would serve consistency and 
predictability if the first did also.

Possibly related: <http://sourceforge.net/p/testlilyissues/issues/2240/>.

Yours, Simon
(Continue reading)

Thomas Morley | 4 Sep 01:53 2015

strange result for escaping "\" with other font-name


trying to escape "\" in a string leads to strange results, for some
Example below was ok with 2.18.2

\version "2.19.26"

\markup \override #'(font-name . "Times New Roman") "\\<==what?"

bug-lilypond mailing list
bug-lilypond <at> gnu.org
cpkc | 1 Sep 02:44 2015


On 2015-08-31 06:27 AM, Trevor Daniels wrote:
> Colin Campbell wrote Monday, August 31, 2015 1:03 PM
> I had started to catch up on verifying issues, as there is a bit of a
> backlog. Shall I carry on until Trevor starts the final migration, or
> pause until after the migration is complete?
> BTW, it turns out that SF ID and display name are separate values, so
> for the record: "John Zebedee" and "Colin Campbell" are the same person.
> I'd prefer you to continue.  All your changes should migrate correctly.
> Trevor

So mote it be, Trevor. I'll chip away at the backlog as time permits.


It is inaccurate to say I hate everything. I am strongly in favor of 
common sense, common honesty, and common decency. This makes me forever 
ineligible for public office.
-H.L. Mencken, writer, editor, and critic (1880-1956)
Phil Holmes | 31 Aug 16:34 2015

Fw: 2.19.26 regtests

Could someone create a bug on the new issue tracker to track this bug, 

Phil Holmes

----- Original Message ----- 
From: "Masamichi HOSODA" <trueroad <at> sea.plala.or.jp>
To: <dak <at> gnu.org>
Cc: <lilypond-devel <at> gnu.org>
Sent: Monday, August 31, 2015 3:17 PM
Subject: Re: 2.19.26 regtests

>>>>There's lots of differences, presumably down to font changes,
>>> Also sans \bold and \italic do not seem to work in
>>> font-family-override.ly
>> Well, I call uh-oh.  It will probably take a few more unstable releases
>> to shake out the problems from the font setup changes.
> Probably, it caused by URW fonts problem and/or Pango version.
> In my experiment, with newest URW fonts release (commit date is 
> 2015-08-28)
> and newest Pango (version 1.36.8, 2014-09), there is no problem.
> Attached file is the result.
> First, the previous URW fonts release (commit date is 2015-08-25) seems 
(Continue reading)

Martin Tarenskeen | 31 Aug 12:55 2015

inconsistent handling of articulations with slurs


Try to compile the following example:


\version "2.19.25"

\relative {
   d''-.( d-. d-. d-.)
   d-_( d-_ d-_ d-_)
   d--( d-- d-- d--)
   d-^( d-^ d-^ d-^)
   d-+( d-+ d-+ d-+)
   d-!( d-! d-! d-!)
   d->( d-> d-> d->)
   \override Slur.outside-staff-priority = #500
   d-.( d-. d-. d-.)
   d-_( d-_ d-_ d-_)
   d--( d-- d-- d--)
   d-^( d-^ d-^ d-^)
   d-+( d-+ d-+ d-+)
   d-!( d-! d-! d-!)
   d->( d-> d-> d->)


(Continue reading)

Trevor Daniels | 30 Aug 18:12 2015

Bug Squad invited to join Allura

 <at> Bug Squad

The new Issues DB at SourceForge is live and has been updated by James to reflect the current state of
patches.  There are a few new issues that are yet to be added, in particular the ones Simon raised on the bug
list.  These will now need to be given new serial numbers as James has bagged the ones Simon chose.

So, to enable you to complete the updating and to continue your maintenance of the Issues DB I suggest you now
go to


click on "Join" at top right and register as a member.  Then send me the username you've chosen so I can add you
as a developer.  If you are spam-averse I suggest you use a disposable email address so you can make a clean
break after we move to Savannah.

The intention is to migrate the data from SF (not GC) to Savannah, so any work you do now will be preserved, DV.

James | 30 Aug 14:47 2015

Re: Allura at SF is ready

Hello Trevor,

Some comments if I may be so bold.

1. I think it would be useful to have 'Searches' (defined on that left
hand side panel) for each of the Patch states


At the moment we have 'Review' only.

The 'Fixed' search

2. It seems that the 'Needs' field is mandatory and this is going to be
misleading I think. For example if you look at the new issue I entered


This has a 'Needs: design' tag which is inappropriate (and incorrect).

Otherwise it seems simple enough.

Thank you.

(Continue reading)

Thomas Morley | 30 Aug 13:21 2015

[New Issue] Implement new markup-command combine-list

Status: Started
Omner:  thomasmorley65 <at> gmail.com
Type: Enhancement
Patch: new
Rietveld issue: 264960043
Issue description:
    Implement new markup-command combine-list

    Allows for \markup \combine-list { a list }
David Kastrup | 30 Aug 11:07 2015

Bad LSR snippet.

commit 8ffecf6be17c6ec2ff87cf31873121a8cce29b09
Author: Phil Holmes <mail <at> philholmes.net>
Date:   Thu Jul 24 15:17:57 2014 +0100

    Import snippets from LSR and delete initial batch in snippets/new



by replacing

    \override Stem.neutral-direction = #'()



which is absolutely not the same and does not work.  Do people not
actually test their changes?

So at any rate, this should be fixed in the LSR.  It would appear to be
snippet 751 <URL:http://lsr.di.unimi.it/LSR/Item?id=751>.


David Kastrup
David Kastrup | 28 Aug 22:47 2015

[New Issue] NR Changing Defaults: Explain sticky contexts accurately

Status: Started
Omner:  dak <at> gnu.org
Type: Documentation
Patch: new
Rietveld issue: 260960043 (https://codereview.appspot.com/260960043)
Issue description:
  NR Changing Defaults: Explain sticky contexts accurately


David Kastrup