>> With current git (commit 44f1033467a6, using Guile 2.2.7), the
>> formatting of optional Scheme function arguments in the IR looks
>> strange. [...]
>
> I'll fix that later. An issue seems like the way to go for now.
Done.
https://gitlab.com/lilypond/lilypond/-/issues/6330
Werner
Le 18/04/2022 à 11:33, Werner LEMBERG a écrit :
With current git (commit 44f1033467a6, using Guile 2.2.7), the
formatting of optional Scheme function arguments in the IR looks
strange. For example, the signature
```
(define*-public (markup->string m #:key (layout #f) (props '()))
```
With current git (commit 44f1033467a6, using Guile 2.2.7), the
formatting of optional Scheme function arguments in the IR looks
strange. For example, the signature
```
(define*-public (markup->string m #:key (layout #f) (props '()))
```
appears as
```
Function: markup->string m
Hi,
The change to add syntax highlighting in the HTML version of the
LilyPond documentation, discussed at
https://lists.gnu.org/archive/html/lilypond-user/2022-01/msg00012.html
on the lilypond-user list and in various lilypond-devel and GitLab
threads, has now landed in the source tree and will
Le 09/08/2021 à 16:21, David Kastrup a écrit :
Werner LEMBERG writes:
In `notation.pdf`, section 'A.23, Scheme functions', the function
header
(define-safe-public (check-context-path path #:optional location)
gets currently translated to
check-context-path path . lamb
>> A quick work-around is to use Guile 2.x, as Jean has reported in
>> !808...
>
> Is that actually better? Last time I had contact with Guile-2.x in
> that respect, it replaced the argument lists by generic a b c d .
> That would be different here?
I don't know. I have always used 1.x; I have
Werner LEMBERG writes:
>>> In `notation.pdf`, section 'A.23, Scheme functions', the function
>>> header
>>>
>>> (define-safe-public (check-context-path path #:optional location)
>>>
>>> gets currently translated to
>>>
>> In `notation.pdf`, section 'A.23, Scheme functions', the function
>> header
>>
>> (define-safe-public (check-context-path path #:optional location)
>>
>> gets currently translated to
>>
>> check-context-path path . lambda*:G59
A q
>> I remember faintly that you've mentioned something along this
>> direction [...]
>
> see https://gitlab.com/lilypond/lilypond/-/merge_requests/808
Ah thanks, this was it.
Werner
Werner LEMBERG writes:
> In `notation.pdf`, section 'A.23, Scheme functions', the function
> header
>
> (define-safe-public (check-context-path path #:optional location)
>
> gets currently translated to
>
> check-context-path path . lambda*:G59
>
> wh
Am Montag, dem 09.08.2021 um 06:23 + schrieb Werner LEMBERG:
> In `notation.pdf`, section 'A.23, Scheme functions', the function
> header
>
> (define-safe-public (check-context-path path #:optional location)
>
> gets currently translated to
>
> che
In `notation.pdf`, section 'A.23, Scheme functions', the function
header
(define-safe-public (check-context-path path #:optional location)
gets currently translated to
check-context-path path . lambda*:G59
which looks weird. David, in case this is unavoidable (I remember
fa
On 19/08/2020 16:43, Jonas Hahnfeld wrote:
> https://gitlab.com/lilypond/lilypond/-/merge_requests/191 switched to
> using URW++ / C059 fonts by default. However, it looks like configure
> only requires the previous default, TeX Gyre; URW++ / C059 is optional.
> Is that intended and
https://gitlab.com/lilypond/lilypond/-/merge_requests/191 switched to
using URW++ / C059 fonts by default. However, it looks like configure
only requires the previous default, TeX Gyre; URW++ / C059 is optional.
Is that intended and / or correct?
On a more general note, I wonder why the build
>
> ... but not pushed yet, it seems.
Sorry about that! I thought I did... anyway, it's pushed now.
--Owen
> Han-Wen, I decided to go for your first solution, which is now
> committed.
... but not pushed yet, it seems.
> Werner, in case you were wondering what I had previously: [...]
I saw that, thanks.
Werner
:
> On Sun, May 31, 2020 at 12:50 AM wrote:
> >
> > Date: Sat, 30 May 2020 15:41:31 -0700
> > From: Owen Lamb
> > To: Werner LEMBERG , lilypond-devel@gnu.org
> > Subject: Metafont optional parameters
> > Message-ID:
> > uf...@mail.gmail.com&
20 at 12:17 PM
> *To: *Carl Sorensen
> *Cc: *Werner LEMBERG , "lilypond-devel@gnu.org" <
> lilypond-devel@gnu.org>
> *Subject: *Re: Metafont optional parameters
>
>
>
> Hi Carl,
>
>
>
> Thanks for bringing this file to my attention. It seems to
Thank you, Werner and Han-Wen!
Han-Wen, I decided to go for your first solution, which is now committed. I
figured that eventually the argument won't have to be optional anyway, so
it would probably look cleaner in the end to have another argument in an
already-existing macro than to have a
, "lilypond-devel@gnu.org"
Subject: Re: Metafont optional parameters
Hi Carl,
Thanks for bringing this file to my attention. It seems to me, however, that
the Unicode encoding is defined in
gen-emmentaler.fontforge.py<http://gen-emmentaler.fontforge.py>, at lines 58
through 61, with a
rensen
wrote:
> On Sat, May 30, 2020 at 4:41 PM Owen Lamb wrote:
> >
> > Hi all,
> >
> > I'd like to add an optional parameter for smuflcode to fet_beginchar, so
> > that I don't have to take two lines redeclaring the variable in every
> > gly
On Sun, May 31, 2020 at 12:50 AM wrote:
>
> Date: Sat, 30 May 2020 15:41:31 -0700
> From: Owen Lamb
> To: Werner LEMBERG , lilypond-devel@gnu.org
> Subject: Metafont optional parameters
> Message-ID:
>
> Content-Type: text/plain; charset="UTF-8"
On Sun, May 31, 2020 at 12:41 AM Owen Lamb wrote:
>
> Hi all,
>
> I'd like to add an optional parameter for smuflcode to fet_beginchar, so
> that I don't have to take two lines redeclaring the variable in every
> glyph. Ideally, it won't have to be optional once
> I'd like to add an optional parameter for smuflcode to
> fet_beginchar, so that I don't have to take two lines redeclaring
> the variable in every glyph. Ideally, it won't have to be optional
> once every character has it, but in the meantime, it would hel
On Sat, May 30, 2020 at 4:41 PM Owen Lamb wrote:
>
> Hi all,
>
> I'd like to add an optional parameter for smuflcode to fet_beginchar, so
> that I don't have to take two lines redeclaring the variable in every
> glyph. Ideally, it won't have to be optional once
Hi all,
I'd like to add an optional parameter for smuflcode to fet_beginchar, so
that I don't have to take two lines redeclaring the variable in every
glyph. Ideally, it won't have to be optional once every character has it,
but in the meantime, it would help with testing indivi
LGTM
https://codereview.appspot.com/567480043/
drop the dependency entirely.
The lost coverage amounts to not checking that the produced .xml file
can be processed by dblatex...
Description:
Make dblatex an optional dependency
Commit cfa910f1c1 in 2012 made it required unless disabling the doc
build. This is an overapproximation since dblatex
LGTM
https://codereview.appspot.com/551260043/
On May 12, 2018, at 16:17, Carl Sorensen wrote:
>
> Does our code base use the optional second parameter anywhere? If not, maybe
> it would be even simpler to eliminate the optional second parameter, and just
> call
>
> warning (_f (. . .), origin);
>
> and ke
multiply in my work in progress.
I see that ::warning already accepts a location string as an optional
second parameter, so I am thinking of using that rather than creating yet
another interface. I am thinking of defining a helper function
message_location(const Input*) to be used like t
nd or create `%s' called `%s'",
ly_symbol2string (n).c_str (), id));
}
I put up with this when it was just one instance, but it’s starting to multiply
in my work in progress.
I see that ::warning already accepts a location string as an optional second
parameter, so I am thinking of
2018-04-22 19:13 GMT+02:00 Torsten Hämmerle :
> dak wrote
>> Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense
>> either way.
>
> @Harm
>
> Function F0_1(w) basically is supposed to return 0 for w = 0 and
> asymptotically approach a limit of 1 as w grows wider.
> Because atan
dak wrote
> Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense
> either way.
@Harm
Function F0_1(w) basically is supposed to return 0 for w = 0 and
asymptotically approach a limit of 1 as w grows wider.
Because atan(x) -> π/2 (i.e. 90°) as x -> infinity, the result is multip
Thomas Morley writes:
> Hi,
>
> with
> https://sourceforge.net/p/testlilyissues/issues/3088/
> I implemented \undertie markup based on Jan's proposal.
>
> I now wanted to use make-tie-stencil for other stuff and noticed some
> problems.
>
> (1)
> The local binding of slur-height, based on Jan's:
Any objections to make them optional, like:
(define* (make-my-tie-stencil
start stop thickness orientation
#:optional (height-limit 0.7) (ratio 0.33) (angularity 0.5)
)
[body]
)
(export make-my-tie-stencil)
Cheers,
Harm
_
On 2016/11/16 15:40:48, pkx166h wrote:
Push patch set 1. Then we can worry about getting the download up to
LilyPond
site afterwards. I will create a tracker to document all this.
I've pushed Patch Set 1 to staging.
commit 855e8e36a0c75aa75076fabe19aa292a6902ec96
https://codereview.appspot.c
I can upload a tarball to lilypond.org if needed.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2016/11/16 15:40:48, pkx166h wrote:
On 2016/11/16 14:35:05, trueroad_trueroad.jp wrote:
> > But, I think that the simplest way is to distribute the tarball at
the
> LilyPond site.
> > e.g.
> >
>
http://lilypond.org/downloads/gub-sources/urw-fonts/urw-core35-fonts-79bcdfb.tar.gz
> >
> > An
On 2016/11/16 14:35:05, trueroad_trueroad.jp wrote:
> But, I think that the simplest way is to distribute the tarball at
the
LilyPond site.
> e.g.
>
http://lilypond.org/downloads/gub-sources/urw-fonts/urw-core35-fonts-79bcdfb.tar.gz
>
> And change the warning message of configure script.
> e
> But, I think that the simplest way is to distribute the tarball at the
> LilyPond site.
> e.g.
> http://lilypond.org/downloads/gub-sources/urw-fonts/urw-core35-fonts-79bcdfb.tar.gz
>
> And change the warning message of configure script.
> e.g.
> (download tarball from
> http://lilypond.org/down
>> I attached the shell script which can download the 12 font files from
>
> 'http://git.ghostscript.com/?p=urw-core35-fonts.git;a=commit;h=79bcdfb34fbce12b592cce389fa7a19da6b5b018'.
>
>> Its each download URL is just link of each font file in above URL.
>> It works fine on my environment.
>
>>
On 2016/11/06 13:16:44, trueroad_trueroad.jp wrote:
> I am sorry to still talk about this, but I have been unable to work
> out
> how I could install just these fonts without having to clone the
> entire
> repo. I have looked in places like stackoverflow and the various
'git'
> sites but no one
> I am sorry to still talk about this, but I have been unable to work
> out
> how I could install just these fonts without having to clone the
> entire
> repo. I have looked in places like stackoverflow and the various 'git'
> sites but no one seems to be able to clearly state how to install just
>
rmal configure output) ...
...
checking for zip... zip
checking for rsync... rsync
configure: creating ./config.status
config.status: creating config.make
config.status: creating config.hh
WARNING: Please consider installing optional programs or files: URW++
OTF fonts (download OTF files from
'h
re script can find them.
Even if configure script cannot find them, compilation and installation
is possible since the files are optional.
Unfortunately, perhaps because those fonts are too new, not yet been
packaged.
I think that there are two ways to improve.
1. To suppress the display of warni
Hosoda-san (and perhaps others who know about font installation),
I cannot seem to be able to install 'just' a git commit (as is described
in the warning message that is posted by the makefile when you run
'configure'), I can git clone the repo of course and that works - as
long as I know where m
LGTM. Thanks for working on this.
https://codereview.appspot.com/315850043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
https://codereview.appspot.com/304200043/diff/20001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
https://codereview.appspot.com/304200043/diff/20001/Documentation/notation/rhythms.itely#newcode3436
Documentation/notation/rhythms.itely:3436: the length o
LGTM.
https://codereview.appspot.com/304200043/diff/20001/Documentation/notation/rhythms.itely
File Documentation/notation/rhythms.itely (right):
https://codereview.appspot.com/304200043/diff/20001/Documentation/notation/rhythms.itely#newcode3436
Documentation/notation/rhythms.itely:3436: the l
On 2016/07/22 07:55:54, dak wrote:
On 2016/07/22 07:41:00, http://mark_opus11.net wrote:
> On 2016/07/22 04:26:01, lemzwerg wrote:
> > LGMT. Thanks a lot!
>
> Might it be a good idea to keep one example using the old define
method, which
> is still more convenient for setting the value for mult
related. And I decided that just mentioning where
this default was stored would provide a comparatively small opening in
the can of worms.
So this was a conscious decision on my part and I'll require some
convincing to revert.
Description:
Optional fraction after \afterGrace command
\afterGrace had
On 2016/07/22 04:26:01, lemzwerg wrote:
LGMT. Thanks a lot!
Might it be a good idea to keep one example using the old define method,
which is still more convenient for setting the value for multiple usages
of \afterGrace (or globally)?
https://codereview.appspot.com/304200043/
___
LGMT. Thanks a lot!
https://codereview.appspot.com/304200043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Slightly simpler docstring revision.
-Paul
https://codereview.appspot.com/284980043/diff/20001/scm/stencil.scm
File scm/stencil.scm (right):
https://codereview.appspot.com/284980043/diff/20001/scm/stencil.scm#newcode809
scm/stencil.scm:809: and @code{'box}. Given @code{'outline} the white
back
Addressing Harm's suggestions in patch set 2.
https://codereview.appspot.com/284980043/diff/1/scm/stencil.scm
File scm/stencil.scm (right):
https://codereview.appspot.com/284980043/diff/1/scm/stencil.scm#newcode804
scm/stencil.scm:804: (define*-public (stencil-whiteout stil #:optional
(
Reviewers: ,
Message:
Please review, thanks.
-Paul
Description:
stencil.scm: make args optional in stencil-whiteout
Please review this at https://codereview.appspot.com/284980043/
Affected files (+2, -1 lines):
M scm/stencil.scm
Index: scm/stencil.scm
diff --git a/scm/stencil.scm b/scm
Hi James,
> I have opened
> https://sourceforge.net/p/testlilyissues/issues/4658/
Thanks. (I’m getting a 404 error at the moment, but I assume that’s temporary.)
Cheers,
Kieren.
Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenm
On 11/11/15 02:58, Kieren MacMillan wrote:
> Hello all,
>
> Rather than having to \revert an \override (or set of \override-s), might it
> be possible to set an optional duration for which the override would be in
> effect? e.g.
>
> \temporary #’(10 1/8) \override LyricTex
Hello all,
Rather than having to \revert an \override (or set of \override-s), might it be
possible to set an optional duration for which the override would be in effect?
e.g.
\temporary #’(10 1/8) \override LyricText.extra-offset = #’(0 . -1)
would lower the LyricText(s) for exactly 10
d...@gnu.org wrote Monday, August 03, 2015 11:42 AM
> I think we should have some table with context starters and mode change
> commands somewhere also listing (discouraged but convenient) shorthands
> like \chords, \figures, \lyrics and listing which commands start a
> different mode and which c
On 2015/08/03 11:20:37, J_lowe wrote:
Could we integrate this into
https://code.google.com/p/lilypond/issues/detail?id=3592
(save a new tracker?)
Well, "integrate" is a strong word since issue 3592 comes to bury the
shortcuts, not to praise them. So I think that this is a different
issu
On 2015/08/03 10:42:03, dak wrote:
On 2015/08/03 10:24:32, thomasmorley651 wrote:
> Can't review parser-code.
>
> Otherwise:
> Doing \layout { \context { \Lyrics ... } } will work for the Lyrics
created by
> \addlyrics as well. Thus it's more than consistent to allow \with {
... } for
> \addl
On 2015/08/03 10:24:32, thomasmorley651 wrote:
Can't review parser-code.
Otherwise:
Doing \layout { \context { \Lyrics ... } } will work for the Lyrics
created by
\addlyrics as well. Thus it's more than consistent to allow \with {
... } for
\addlyrics. I'd say it was a badly missing featur
Can't review parser-code.
Otherwise:
Doing \layout { \context { \Lyrics ... } } will work for the Lyrics
created by \addlyrics as well. Thus it's more than consistent to allow
\with { ... } for \addlyrics. I'd say it was a badly missing feature.
My point: Looks very good to me!
About Documentat
LGTM, thanks.
https://codereview.appspot.com/255610043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 2015/07/31 10:57:07, dak wrote:
https://codereview.appspot.com/259080043/diff/20001/scm/autochange.scm
File scm/autochange.scm (right):
https://codereview.appspot.com/259080043/diff/20001/scm/autochange.scm#newcode36
scm/autochange.scm:36: (cond ((ly:pitch On 2015/07/31 00:01:20, Dan Eble
https://codereview.appspot.com/259080043/diff/20001/scm/autochange.scm
File scm/autochange.scm (right):
https://codereview.appspot.com/259080043/diff/20001/scm/autochange.scm#newcode36
scm/autochange.scm:36: (cond ((ly:pitch
On 2015/07/31 00:01:20, Dan Eble wrote:
> would ly:pitch-diff simplify
Thanks Dan and David for review
https://codereview.appspot.com/259080043/diff/20001/Documentation/notation/keyboards.itely
File Documentation/notation/keyboards.itely (right):
https://codereview.appspot.com/259080043/diff/20001/Documentation/notation/keyboards.itely#newcode294
Documentation/not
https://codereview.appspot.com/259080043/diff/20001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/259080043/diff/20001/ly/music-functions-init.ly#newcode189
ly/music-functions-init.ly:189: (ly:context-mod? #{ \with {
Write (ly:context-mod?) he
https://codereview.appspot.com/259080043/diff/20001/Documentation/notation/keyboards.itely
File Documentation/notation/keyboards.itely (right):
https://codereview.appspot.com/259080043/diff/20001/Documentation/notation/keyboards.itely#newcode294
Documentation/notation/keyboards.itely:294: If the
Please review.
It's a pity that obviously putting something like #{ c' #} or #{ \clef
bass #} in music-functions-init.ly is currently not possible.
Trying so returns:
"
error: unrecognized string, not in text script or \lyricmode
c'
"
or
"
error: unknown escaped string: `\clef'
\clef treble
"
LGTM, but you probably expected that!
https://codereview.appspot.com/175810043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I don't have enough time to really review the code, but i'm glad to see
this issue being addressed - thanks!
Janek
https://codereview.appspot.com/115320043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/l
On 2013/12/13 06:47:29, lemzwerg wrote:
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073
lily/parser.yy:1073: if (!unsmob_music ($$))
> What's more annoying is that the copy&pas
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy
File lily/parser.yy (right):
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy#newcode1073
lily/parser.yy:1073: if (!unsmob_music ($$))
What's more annoying is that the copy&paste passages often use spaces
instead of tabs
his file got edited
while project-wide directory file variables told Emacs not to use tabs.
The inconsistency is somewhat annoying, but in the interest of letting
"git blame" work, gratuitous changes while moving lines around are not
a good idea.
Description:
Parser: make optional argume
As usual, thanks for working on such simplifications and clean-ups!
Inspecting the code (without really understanding it), I haven't seen
any gross irregularities, and this is probably the only thing I can
check...
https://codereview.appspot.com/41720043/diff/1/lily/parser.yy
File lily/parser.yy
LGTM
https://codereview.appspot.com/13475043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM
https://codereview.appspot.com/13475043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
LGTM.
I think it would be clearer if the descrption focused more on this
change, and a bit less on explaining context of \relative discussions.
In other words, the sentence "This is intended as a potential migration
strategy to issue 3229 where
leaving off the optional reference pitch lea
LGTM
https://codereview.appspot.com/6830043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Nov 9, 2012 at 11:16 AM, David Kastrup wrote:
Janek Warchoł writes:
On Thu, Nov 8, 2012 at 9:32 AM, Marc Hohl wrote:
For a flute, I used \clef "G^(8)" to indicate that the player may
play it
one
octave above (preferred in combination with concert flute) or as
written
(when play
Am 09.11.2012 11:12, schrieb Janek Warchoł:
Hi Marc,
On Thu, Nov 8, 2012 at 9:32 AM, Marc Hohl wrote:
Am 08.11.2012 09:22, schrieb janek.lilyp...@gmail.com:
I suppose that a parenthesized clef octavation doesn't mean that the
octavation is optional (that is, it doesn't mean "
a parenthesized clef octavation doesn't mean that the
>>>> octavation is optional (that is, it doesn't mean "you may choose to
>>>> play
>>>> it in this octave or another, whatever pleases you most"). I suppose
>>>> that a parenthes
Janek Warchoł writes:
> On Thu, Nov 8, 2012 at 9:32 AM, Marc Hohl wrote:
>>
>> Am 08.11.2012 09:22, schrieb janek.lilyp...@gmail.com:
>>> I suppose that a parenthesized clef octavation doesn't mean that the
>>> octavation is optional (that is, it doesn&#x
Hi Marc,
On Thu, Nov 8, 2012 at 9:32 AM, Marc Hohl wrote:
>
> Am 08.11.2012 09:22, schrieb janek.lilyp...@gmail.com:
>> I suppose that a parenthesized clef octavation doesn't mean that the
>> octavation is optional (that is, it doesn't mean "you may choose to pla
tation/notation/pitches.itely
File Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/6830043/diff/1/Documentation/notation/pitches.itely#newcode1156
Documentation/notation/pitches.itely:1156: Optional octavation can be
obtained by enclosing the numeric
I don't q
Am 08.11.2012 09:25, schrieb janek.lilyp...@gmail.com:
PS please add the issue number and committish of the patch introducing
this feature to the commit message of this doc patch.
http://codereview.appspot.com/6830043/
Ok, will do.
Marc
___
lilypon
e Documentation/notation/pitches.itely (right):
http://codereview.appspot.com/6830043/diff/1/Documentation/notation/pitches.itely#newcode1156
Documentation/notation/pitches.itely:1156: Optional octavation can be
obtained by enclosing the numeric
I don't quite understand this "option
PS please add the issue number and committish of the patch introducing
this feature to the commit message of this doc patch.
http://codereview.appspot.com/6830043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/lis
/6830043/diff/1/Documentation/notation/pitches.itely#newcode1156
Documentation/notation/pitches.itely:1156: Optional octavation can be
obtained by enclosing the numeric
I don't quite understand this "optional" thing. (maybe i don't
understand this notation correctly at all?)
LGTM
Trevor
http://codereview.appspot.com/6830043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Am 03.11.2012 23:20, schrieb Janek Warchoł:
On Fri, Nov 2, 2012 at 10:20 PM, Marc Hohl wrote:
Am 02.11.2012 09:58, schrieb janek.lilyp...@gmail.com:
http://codereview.appspot.com/6813044/diff/6001/lily/clef-engraver.cc#newcode125
lily/clef-engraver.cc:125: if (ly_is_procedure (formatter))
it s
On Fri, Nov 2, 2012 at 10:20 PM, Marc Hohl wrote:
> Am 02.11.2012 09:58, schrieb janek.lilyp...@gmail.com:
>> http://codereview.appspot.com/6813044/diff/6001/lily/clef-engraver.cc#newcode125
>> lily/clef-engraver.cc:125: if (ly_is_procedure (formatter))
>> it seems that octavation won't work at al
good to explain why the code doesn't
just take (15), turn it into a markup right away and append to the clef
- it uses "style" property (both in the actual code as well as in commit
message).
thanks!
Janek
http://codereview.appspot.com/6813044/diff/6001/input/regression/clef-optiona
right away and append to the clef
- it uses "style" property (both in the actual code as well as in commit
message).
thanks!
Janek
http://codereview.appspot.com/6813044/diff/6001/input/regression/clef-optional-octavation.ly
File input/regression/clef-optional-octavation.ly
case."
+ (and (symbol? c)
+ (char-upper-case? (string-ref (symbol->string c) 0
accidentalStyle =
#(define-music-function
- (parser location context style) ((symbol?) string?)
+ (parser location context style) ((context-name?) string?)
(_i "Set accidental style to @var{sty
(if name
>>> #{ \once \override $name #'color = #red $arg #}
>>> #{ \parenthesize $arg #}))
>>>
>>> \relative c' {
>>> c1
>>> \proc "NoteHead" c
>>> \proc c
>>> }
>>>
>>&g
c
>> \proc c
>> }
>>
>> Obviously I did sth wrong.
>
> Not obviously. Unobviously, however, we have the situation that
> optional arguments can only be properly checked by the parser when they
> can be parsed without lookahead, namely are a "cl
1 - 100 of 152 matches
Mail list logo
