https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc
File lily/lyric-extender.cc (right):
https://codereview.appspot.com/313240043/diff/21/lily/lyric-extender.cc#newcode63
lily/lyric-extender.cc:63: while (hs && robust_scm2double
(heads[hs-1]->get_property
On
Hi,
Am 06.02.2017 um 20:08 schrieb d...@gnu.org:
> https://codereview.appspot.com/313240043/diff/21/scm/define-grob-properties.scm#newcode188
>
> scm/define-grob-properties.scm:188: (collapse-length ,ly:dimension? "An
> automatically generated
> collapse-width maybe? Length is more like a
It's not really clear to me where I am supposed to go from here with
what I proposed. I lean towards going back to creating my own version
of this again since this one contains so much stuff that does not ring a
bell with me.
On 2017/02/06 11:02:56, akobel wrote:
Version 2017-02-04 by David
Not "by David" but "by Kurt". David merely rebased Kurt's new version.
https://codereview.appspot.com/313240043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://codereview.appspot.com/313240043/diff/180001/lily/lyric-extender.cc
File lily/lyric-extender.cc (right):
https://codereview.appspot.com/313240043/diff/180001/lily/lyric-extender.cc#newcode62
lily/lyric-extender.cc:62: while (hs && robust_scm2double
(heads[hs-1]->get_property
This
https://codereview.appspot.com/313240043/diff/40001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/313240043/diff/40001/lily/self-alignment-interface.cc#newcode61
lily/self-alignment-interface.cc:61: return scm_from_double (-
Am 18.01.2017 um 09:28 schrieb d...@gnu.org:
https://codereview.appspot.com/313240043/diff/160001/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/313240043/diff/160001/lily/parser.yy#newcode3107
lily/parser.yy:3107: $$ = $1;
That looks like strange fallback behavior.
https://codereview.appspot.com/313240043/diff/160001/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/313240043/diff/160001/lily/parser.yy#newcode3107
lily/parser.yy:3107: $$ = $1;
That looks like strange fallback behavior. EXTENDER likely has a value
of
A happy new one, everybody!
On 2017-01-01 16:39, Knut Petersen wrote:
Hi everybody!
Attached find a new version of the autoextender patch set.
Thanks Knut. Just uploaded to Rietveld.
(In fact, sorry for double-posting it; I deleted my first upload a
minute ago after I recognized that I
Hi everybody!
Attached find a new version of the autoextender patch set.
@Alexander:
I cannot think of anything easier to type than "", so it's still there ;-)
@David:
has_interface (me) does not work, internal_... is
needed in lily/self-alignment-interface.cc.
music-functions.scm changed
Am 27.12.2016 um 03:01 schrieb perpeduumimmob...@gmail.com:
On 2016/12/26 19:14:00, pkx166h wrote:
On 2016/12/25 21:53:55, akobel wrote:
> Bottom line: I withdraw both proposals.
Can you then re-submit a new patch or delete the one(s) that are
invalid?
Sorry, I'm a bit drawn up between my
On 2016/12/26 19:14:00, pkx166h wrote:
On 2016/12/25 21:53:55, akobel wrote:
> Bottom line: I withdraw both proposals.
Can you then re-submit a new patch or delete the one(s) that are
invalid?
Sorry, I'm a bit drawn up between my position as the Rietveld-proxy of
Knut and my own
On 2016/12/25 21:53:55, akobel wrote:
On 2016/12/25 15:43:05, Knut_Petersen_t-online.de wrote:
> Hi everybody!
>
> > I'm only 90% happy about "" and \markup\null...
> > For dynamic spanners and hairpins, we have \! to end them
prematurely
> > before a "natural" end event appears. Is this
On 2016/12/25 15:43:05, Knut_Petersen_t-online.de wrote:
Hi everybody!
> I'm only 90% happy about "" and \markup\null...
> For dynamic spanners and hairpins, we have \! to end them
prematurely
> before a "natural" end event appears. Is this similar enough to
warrant
> the use of the same
On 2016/12/25 14:03:09, akobel wrote:
Tell parser to ignore "__" token
I apologize if I am misjudging this change based on the headline alone,
but if a token serves no purpose (my assumption), then rather than
ignoring it, shouldn’t the parser treat it as it would any other
unexpected input
https://codereview.appspot.com/313240043/diff/40001/lily/self-alignment-interface.cc
File lily/self-alignment-interface.cc (right):
https://codereview.appspot.com/313240043/diff/40001/lily/self-alignment-interface.cc#newcode61
lily/self-alignment-interface.cc:61: return scm_from_double (-
Hi everybody!
I'm only 90% happy about "" and \markup\null...
For dynamic spanners and hairpins, we have \! to end them prematurely
before a "natural" end event appears. Is this similar enough to warrant
the use of the same token (i.e., \! would be translated to empty lyrics
with a
https://codereview.appspot.com/313240043/diff/40001/Documentation/notation/vocal.itely
File Documentation/notation/vocal.itely (right):
https://codereview.appspot.com/313240043/diff/40001/Documentation/notation/vocal.itely#newcode842
Documentation/notation/vocal.itely:842: @samp{ \markup\null }
LGTM, with the trivial suggestions indicated below to the NR, but I'm
not competent to check the code sections.
The use of "__" has been expunged completely: should we not retain a
brief mention perhaps for use when the user has turned auto extenders
off?
Trevor
Reviewers: ,
Message:
For the sake of completeness: deserves an entry in changes.tely (TBD
when the syntax discussion is over that I expect to start some time
soon...)
Description:
Automatic LyricExtenders
As written and communicated by Knut Peterson.
For reference, see the threads
20 matches
Mail list logo
