At the start of the second alternative, we have an extra slur
start, the slur ends on beat 2, a phrasing slur starts on beat 3 and
at the end of the alternative, there is an extra slur end. Huh.
Works better with detached.
In this sentence, \phantom works quite nicely :-) This is still my
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc#newcode63
lily/self-alignment-interface.cc:63: programming_error (cannot align on
Thanks for review!
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/7533046/diff/3001/lily/self-alignment-interface.cc#newcode63
lily/self-alignment-interface.cc:63: programming_error
On 2013/03/21 08:04:42, janek wrote:
So, you think that we shouldn't report any programming error in these
alignment
funcitons since an empty extent doesn't prevent us from doing our job
(i.e.
aligning)?
Well, with an empty extent it would appear our job of aligning _self_ is
already done
On Thu, Mar 21, 2013 at 9:14 AM, d...@gnu.org wrote:
On 2013/03/21 08:04:42, janek wrote:
So, you think that we shouldn't report any programming error in these
alignment funcitons since an empty extent doesn't prevent us from
doing our job i.e. aligning)?
Well, with an empty extent it
Janek Warchoł janek.lilyp...@gmail.com writes:
On Thu, Mar 21, 2013 at 9:14 AM, d...@gnu.org wrote:
I don't know the logic of the code and its uses, so this is basically
my unqualified gut feeling and nothing else. Flagging and reporting
a problem without any user-visible consequences does
Hey all,
To prepare for 2.18, I think we can get it out fastish, but we need to more or
less freeze current master aside from bug fixes and documentation. I have a
lot of stuff on the countdown or on patch push that I'm not gonna push for a
few months until we get 2.18 out (Ferneyhough
m...@mikesolomon.org m...@mikesolomon.org writes:
Hey all,
To prepare for 2.18, I think we can get it out fastish, but we need to
more or less freeze current master aside from bug fixes and
documentation. I have a lot of stuff on the countdown or on patch
push that I'm not gonna push for a
Am 21.03.2013 19:19, schrieb m...@mikesolomon.org:
Hey all,
To prepare for 2.18, I think we can get it out fastish, but we need
to more or less freeze current master aside from bug fixes and
documentation. I have a lot of stuff on the countdown or on patch
push that I'm notgonna push for a few
Hi,
virtually all grob properties are lowercase words separated with
dashes. I think we should get rid of exceptions to this rule and make
all grob properties lowercase - here's a list of offenders:
minimum-[XY]-extent
self-alignment-[XY]
simple-Y
[XY]-extent
[XY]-offset
X-positions
Janek Warchoł janek.lilyp...@gmail.com writes:
Hi,
virtually all grob properties are lowercase words separated with
dashes. I think we should get rid of exceptions to this rule and make
all grob properties lowercase - here's a list of offenders:
minimum-[XY]-extent
self-alignment-[XY]
Hi,
On Thu, Mar 21, 2013 at 7:19 PM, m...@mikesolomon.org
m...@mikesolomon.org wrote:
To prepare for 2.18, I think we can get it out fastish, but we need to more
or less freeze current master aside from bug fixes and documentation.
I have a lot of stuff on the countdown or on patch push that
2013/3/21 David Kastrup d...@gnu.org:
Janek Warchoł janek.lilyp...@gmail.com writes:
Hi,
virtually all grob properties are lowercase words separated with
dashes. I think we should get rid of exceptions to this rule and make
all grob properties lowercase - here's a list of offenders:
13 matches
Mail list logo
