Hi Neil
On 28. apr. 2008, at 01:22, Neil Puttock wrote:
Since there's a 'to-barline property now, I wonder whether
hairpinToBarline is deprecated; it's not documented in the internals
reference under Dynamic_engraver, and there's a bit of code in
dynamic-spanner.cc which is annotated 'backwards
Graham Percival <[EMAIL PROTECTED]> writes:
> No. Since I said that I'd wait until Monday, and I guess it's
> Monday somewhere in the world.
>
> Most of David's arguments were actually in /favor/ of removing @lsr; he
> just didn't realize that @lsr produced a reference instead of the
> actual sni
On Sun, 27 Apr 2008 20:43:20 +0200
John Mandereau <[EMAIL PROTECTED]> wrote:
> Le samedi 26 avril 2008 __ 03:53 -0700, Graham Percival a __crit :
> > right? Why would the formatting be different in the Snippet
> > document than in the manuals? Just make it
> > @emph{\NAME\}
> > or something like
On Sun, 27 Apr 2008 19:43:58 +0200
"Valentin Villenave" <[EMAIL PROTECTED]> wrote:
> 2008/4/27 Nicolas Sceaux <[EMAIL PROTECTED]>:
>
> > I've just committed a patch regarding builtin markup commands
> > documentation. It adds categories and property listing.
> >
> > Someone should set all mark
On Sun, Apr 27, 2008 at 10:33 PM, John Mandereau <[EMAIL PROTECTED]>
wrote:
> Graham Percival wrote:
> > On Fri, 25 Apr 2008 23:12:26 +1000
> > "Joe Neeman" <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Apr 25, 2008 at 10:57 PM, John Mandereau
> > > <[EMAIL PROTECTED]> wrote:
> > >
> > > > Incomple
Hi Patrick,
2008/4/27 Patrick McCarty <[EMAIL PROTECTED]>:
> Should the hairpinToBarline context property be set to true by
> default? In ly/engraver-init.ly, I see that it's set to true, but in
> the default output, this property is set to false. Compare this
> snippet,
>
> \relative c'' {
Should the hairpinToBarline context property be set to true by
default? In ly/engraver-init.ly, I see that it's set to true, but in
the default output, this property is set to false. Compare this
snippet,
\relative c'' {
e4\< e2. e1\!
\set hairpinToBarline = ##f
e4\< e2. e1\!
}
with this
On Sun, 27 Apr 2008 13:16:57 +0200
John Mandereau <[EMAIL PROTECTED]> wrote:
> Graham Percival wrote:
> > Compromise: could makelsr.py ignore
> > % GDB: ...
> > lines? That way we could tag snippet authorship with
> > % GDB: Thanks to Foo Bar for this snippet
> > without cluttering up the officia
On Sun, 27 Apr 2008 13:16:57 +0200
John Mandereau <[EMAIL PROTECTED]> wrote:
> Graham Percival wrote:
> > We like to indicate the authors of snippets in LSR (or at least,
> > some people do, and I'm not prepared to argue against this point),
> > but I don't want individual names in the docs. (thi
Le samedi 26 avril 2008 à 03:53 -0700, Graham Percival a écrit :
> On Fri, 25 Apr 2008 15:05:40 +0200
> John Mandereau <[EMAIL PROTECTED]> wrote:
>
> > > Sorry, why do we need a CMD? We should use the same formatting
> > > for all of them, so an argument-less command like [doctitle]
> > > should
On 2008/04/26, Han-Wen Nienhuys wrote:
> you added some scripts to buildscripts/ recently. Some of them don't
> follow coding style. Can you fix that? The 8 space indent is the main
> problem (it should be 4)
Do you mean "one year ago" with "recently"? I wrote the scripts with
TAB indentation m
Graham Percival wrote:
> On Fri, 25 Apr 2008 23:12:26 +1000
> "Joe Neeman" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Apr 25, 2008 at 10:57 PM, John Mandereau
> > <[EMAIL PROTECTED]> wrote:
> >
> > > Incomplete test-clean and web-clean can be cumbersome when you're
> > > working on C++ code, but it
Graham Percival wrote:
> We like to indicate the authors of snippets in LSR (or at least,
> some people do, and I'm not prepared to argue against this point),
> but I don't want individual names in the docs. (this would
> quickly get ridiculous)
>
> Compromise: could makelsr.py ignore
> % GDB: .
2008/4/27 Nicolas Sceaux <[EMAIL PROTECTED]>:
> I've just committed a patch regarding builtin markup commands
> documentation. It adds categories and property listing.
>
> Someone should set all markup commands categories (I've set most of
> them to "other"). Several categories may be attribut
> Compiles fine with texi2html (apart from a
> typo - "oder" should be "or", I think.
Oops :-) Fixed in git, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Hi,
I've just committed a patch regarding builtin markup commands
documentation. It adds categories and property listing.
Someone should set all markup commands categories (I've set most of
them to "other"). Several categories may be attributed to a command,
by using a list of symbols, eg: (musi
Compiles fine with texi2html (apart from a
typo - "oder" should be "or", I think.
Trevor
- Original Message -
From: "Werner LEMBERG" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Sunday, April 27, 2008 1:47 PM
Subject: Re: limitations of define-markup-command -- undocumented y
> I can't find Hai-Peng's originial request, so I can't respond to it
> as I'd like.
Maybe on lilypond-user?
> However, since there are scheme arguments to the markup, it would
> seem that if there is a need for more arguments, one could simply
> pass the arguments as a single scheme list, then
> -Original Message-
> From: Werner LEMBERG [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 27, 2008 1:00 AM
> To: lilypond-devel@gnu.org
> Subject: limitations of define-markup-command -- undocumented yet
>
>
>
> [So there's indeed no MARKUP_HEAD_SCM0_SCM1_SCM2_SCM3 as
> Hai-Peng would
> Could you dump this info somewhere in NR 7.4 Markup programmer
> interface ? (it's programming-interface.itely)
Done. Please check whether it compiles correctly (I have no time to
build lilypond currently).
Werner
___
lilypond-devel mailing l
Yikes, this is beyond me. Could you dump this info somewhere in
NR 7.4 Markup programmer interface ?
(it's programming-interface.itely)
It will be at least three months before GDP gets around to this
chapter, so I don't think it's worth keeping it on somebody's todo
list.
Cheers,
- Graham
On S
As a follow-up to my answer of Hai-Peng's problem I wonder whether the
parser limitations of define-markup-command are documented somewhere,
this is, which exact combination of arguments are supported (in the
docs of 2.11.42 this is missing).
Looking into parser.yy, I see these combinations:
%
22 matches
Mail list logo
