Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by janek.lilyp...@gmail.com)
Pushed as
commit 2371d6ba3b62d4d6dc349ab50fa0d76eadfba044
Author: Janek Warchoł
Date: Sun Jun 29 18:25:04 2014 +0200
Issue 4005: Set X-parent of TextScript to NoteColumn instead of
PaperColumn
This makes TextScripts consistent with DynamicTexts and LyricTexts.
This is a follow-up to commit 59a842eba0f7ad78289a58a (Issue 2245).
Setting TextScript.cross-staff property to #f is required to ensure
that there are no collisions between TextScripts and cross-staff
notes:
\context PianoStaff <<
\new Staff = "up" {
b8[
\change Staff="down"
d'] ^"text"
}
\new Staff = "down" {
\clef bass
s4
}
>>
(see also beam-cross-staff-auto-knee.ly)
As far as I can see, we don't want TextScript.cross-staff to be true
in any situation, because it would result in unwanted collisions.
Why it worked before: cross-staff property in this example evaluated
to #f,
but only because of a bug in Script_interface::calc_cross_staff.
That
function should have marked the TextScript as cross-staff if the
stem
of the note to which TextScript was attached was cross-staff, but it
didn't work correctly because it expected the parent of the
TextScript
to be a NoteColumn, while it actually was a PaperColumn. When I
changed
the parent to be a NoteColumn, the function started working
correctly
and marked the TextScript as cross-staff, so I had to change the
default
value of the property.
thanks!
https://codereview.appspot.com/106640043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some working grob properties are unlisted?
David Nalesnik wrote: >> I noticed that the 'baseline-skip property works with the >> InstrumentName grob, which confuses me, because in the IR >> entry for IntsrumentName, none of the supported interfaces >> listed at the bottom provide the 'baseline-skip property. > > The stencil for InstrumentName is created by > system-start-text::print, which calls grob-interpret-markup, > which in turn calls ly:text-interface::interpret-markup with > layout information from the grob. So shouldn't we then add text-interface to the list of interfaces at the bottom of the InstrumentName IR page? http://lilypond.org/doc/v2.19/Documentation/internals/instrumentname How is that list even generated? I can't figure it out from the source code. Thanks very much, Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some working grob properties are unlisted?
On Fri, Jul 25, 2014 at 4:27 PM, David Nalesnik wrote: > > > Personally, I've long wondered whether interfaces serve any purpose other > than for acknowledging grobs in engravers. > > (well, and in generating documentation...) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bounty] context generating function - how to get context def from its name?
2014-07-25 21:34 GMT+02:00 David Kastrup :
> Janek Warchoł writes:
>
>> newInstrument =
>> #(define-scheme-function
>> (parser location instrName parentName settings)(string? ly:context-mod?)
>> ;; ...
>> #{
>> \layout {
>> \context {
> $(module-ref (current-module) (string->symbol parentName))
Ha!
Exactly as i thought: as a higher-level mage than me, you know more
(and more powerful) magic incantations than i do. Kudos!
>> ;; create "instrNameStaff" context, derived from "parentNameStaff",
>> ;; with default child "instrNameVoice", and modifications specified
>> ;; in "settings" argument
> \name #instrName
> \defaultchild #instrNameVoice
> #settings
>> }
>> \context {
>> ;; create "instrNameVoice" context, derived from "parentNameVoice",
>> }
>> }
>> #})
>>
>> I managed to write a function that does something like this, but I
>> have two problems:
>> 1) inside the function, i don't know how to get a context definition
>> from its name (i.e. from a string). Right now i have to pass parent
>> contexts' definitions as separate arguments, but this means that i
>> have three arguments instead of one.
>> 2) i didn't manage to get midi stuff done inside the same function as
>> the layout stuff - but i think that i'll be able to solve that if i
>> have a solution to 1).
>
> You basically need to collect just the context definitions and apply
> those (a context definition is applied by looking up its \name and
> overwriting the variable with that name).
>
> Frankly, I am tempted to create something like
> #{
>\output {
> \context ...
> xxx = 3\cm
>}
> #}
>
> that will either execute a number of assignments or alternatively return
> an anonymous lambda or define-void-function doing the same so that you
> can easily splice it into different output definitions.
>
> Something like that would apparently serve a need.
I don't fully understand this yet, but for now i'm very happy that I
have a better version of the function (see attached) :)
I haven't gotten rid of all the duplication yet, but the user
interface at least seems nice!
Any further improvements are welcome! It would be great if you managed
to fix \addlyrics so that it would work nice with these custom
contexts (see comments in the attachment) - i'd gladly give another
€15 for that (or maybe more...).
thanks & good night for now! :)
Janek
\version "2.19.10"
% Create a new xxxStaff and xxxVoice contexts with specified settings,
% derived from specified yyyStaff and yyyVoice contexts.
% TODO:
%
% 1) make \addLyrics smarter so that it could be used here (see test below)
%
% 2) remove code duplication; general cleanup.
newLayoutInstrument =
#(define-scheme-function
(parser location name parent-name group-name staff-settings voice-settings)
(string? string? string? ly:context-mod? ly:context-mod?)
(let* ((staff-name (string-append name "Staff"))
(voice-name (string-append name "Voice"))
(parent-name (if (string=? parent-name "default") "" parent-name))
(parent-staff-name (string-append parent-name "Staff"))
(parent-voice-name (string-append parent-name "Voice")))
(ly:parser-define! parser '$defaultlayout
#{
\layout {
\context {
$(module-ref (current-module) (string->symbol group-name))
\accepts #staff-name
}
\context {
$(module-ref (current-module) (string->symbol parent-staff-name))
\name #staff-name
\alias #parent-staff-name
% is it possible to make it accept Voices of derived instruments?
\accepts #voice-name
\defaultchild #voice-name
#staff-settings
}
\context {
$(module-ref (current-module) (string->symbol parent-voice-name))
\name #voice-name
\alias #parent-voice-name
#voice-settings
}
}
#})
;; UGH! code duplication!
(ly:parser-define! parser '$defaultmidi
#{
\midi {
\context {
$(module-ref (current-module) (string->symbol group-name))
\accepts #staff-name
}
\context {
$(module-ref (current-module) (string->symbol parent-staff-name))
\name #staff-name
\alias #parent-staff-name
% is it possible to make it accept Voices of derived instruments?
\accepts #voice-name
\defaultchild #voice-name
#staff-settings
}
\context {
$(module-ref (current-module) (string->symbol parent-voice-name))
\name #voice-name
\alias #parent-voice-name
#voice-settings
}
}
#})))
% define "instruments" - one generic and another one derived:
\newLayoutInstrument "Vocal" "default" "
Re: some working grob properties are unlisted?
On Fri, Jul 25, 2014 at 4:27 PM, David Nalesnik
wrote:
>
>
> \version "2.19.10"
>
> #(define (pr grob)
>(let* ((layout (ly:grob-layout grob))
> (defs (ly:output-def-lookup layout 'text-font-defaults))
> (props (ly:grob-alist-chain grob defs)))
> (format #t "immutable properties of grob: ~a~%~%~%" (car props))
> (format #t "mutable properties of grob: ~a~%~%~%" (cadr props))
> (format #t "font defaults: ~a~%~%~%" (caddr props)) ; or defs
> ))
>
> \new Staff \with {
> \override InstrumentName.baseline-skip = #10
> \once \override InstrumentName.after-line-breaking = #pr
> instrumentName = \markup { \column { Viola d'Amore } }
> shortInstrumentName = #"Vln. "
> }
> {
> c4.. g'16 c4.. g'16 | c1
>
missing } ...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: some working grob properties are unlisted?
Hi Mark,
On Tue, Jul 22, 2014 at 4:09 PM, Mark Polesky wrote:
> I noticed that the 'baseline-skip property works with the
> InstrumentName grob, which confuses me, because in the IR
> entry for IntsrumentName, none of the supported interfaces
> listed at the bottom provide the 'baseline-skip property.
>
>
The stencil for InstrumentName is created by system-start-text::print,
which calls grob-interpret-markup, which in turn calls
ly:text-interface::interpret-markup with layout information from the grob.
You can see the information that gets passed there with the following:
\version "2.19.10"
#(define (pr grob)
(let* ((layout (ly:grob-layout grob))
(defs (ly:output-def-lookup layout 'text-font-defaults))
(props (ly:grob-alist-chain grob defs)))
(format #t "immutable properties of grob: ~a~%~%~%" (car props))
(format #t "mutable properties of grob: ~a~%~%~%" (cadr props))
(format #t "font defaults: ~a~%~%~%" (caddr props)) ; or defs
))
\new Staff \with {
\override InstrumentName.baseline-skip = #10
\once \override InstrumentName.after-line-breaking = #pr
instrumentName = \markup { \column { Viola d'Amore } }
shortInstrumentName = #"Vln. "
}
{
c4.. g'16 c4.. g'16 | c1
An entry for 'baseline-skip is added to the mutable properties by the
override, and there is a value in 'text-font-defaults.
> But more importantly, how does a property work when it's not
> provided by any of the grob's interfaces? Ambiguities like
> that bother me.
>
>
I have no good answer for this. But note the following, which uses an
invented property which is part of no interface:
http://www.mail-archive.com/lilypond-user%40gnu.org/msg81852.html
Personally, I've long wondered whether interfaces serve any purpose other
than for acknowledging grobs in engravers.
Hope this leads to a better answer!
David
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bounty] context generating function - how to get context def from its name?
Janek Warchoł writes:
> newInstrument =
> #(define-scheme-function
> (parser location instrName parentName settings)(string? ly:context-mod?)
> ;; ...
> #{
> \layout {
> \context {
$(module-ref (current-module) (string->symbol parentName))
> ;; create "instrNameStaff" context, derived from "parentNameStaff",
> ;; with default child "instrNameVoice", and modifications specified
> ;; in "settings" argument
\name #instrName
\defaultchild #instrNameVoice
#settings
> }
> \context {
> ;; create "instrNameVoice" context, derived from "parentNameVoice",
> }
> }
> #})
>
> I managed to write a function that does something like this, but I
> have two problems:
> 1) inside the function, i don't know how to get a context definition
> from its name (i.e. from a string). Right now i have to pass parent
> contexts' definitions as separate arguments, but this means that i
> have three arguments instead of one.
> 2) i didn't manage to get midi stuff done inside the same function as
> the layout stuff - but i think that i'll be able to solve that if i
> have a solution to 1).
You basically need to collect just the context definitions and apply
those (a context definition is applied by looking up its \name and
overwriting the variable with that name).
Frankly, I am tempted to create something like
#{
\output {
\context ...
xxx = 3\cm
}
#}
that will either execute a number of assignments or alternatively return
an anonymous lambda or define-void-function doing the same so that you
can easily splice it into different output definitions.
Something like that would apparently serve a need.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [bounty] context generating function - how to get context def from its name?
And the missing attachment.
2014-07-25 20:03 GMT+02:00 Janek Warchoł :
> Hi all,
>
> i got stuck when working on a function that creates custom context
> definitions. The idea is to have a function \newInstrument that would
> take a list of settings and create new customized xxxStaff and
> xxxVoice contexts - something like this:
>
> newInstrument =
> #(define-scheme-function
> (parser location instrName parentName settings)(string? ly:context-mod?)
> ;; ...
> #{
> \layout {
> \context {
> ;; create "instrNameStaff" context, derived from "parentNameStaff",
> ;; with default child "instrNameVoice", and modifications specified
> ;; in "settings" argument
> }
> \context {
> ;; create "instrNameVoice" context, derived from "parentNameVoice",
> }
> }
> #})
>
> As you can see, i want to be able to specify the "parent" instrument
> from which the new instrument will "inherit" settings. For example, i
> want to define a "Vocals" instrument (=> VocalsStaff and VocalsVoice
> contexts, derived from Staff and Voice, respectively) and a "Soprano"
> instrument derived from "Vocals" (=> SopranoStaff and SopranoVoice
> contexts, derived from VocalsStaff and VocalsVoice, respectively).
>
> I managed to write a function that does something like this, but I
> have two problems:
> 1) inside the function, i don't know how to get a context definition
> from its name (i.e. from a string). Right now i have to pass parent
> contexts' definitions as separate arguments, but this means that i
> have three arguments instead of one.
> 2) i didn't manage to get midi stuff done inside the same function as
> the layout stuff - but i think that i'll be able to solve that if i
> have a solution to 1).
>
> I offer €25 bounty for solving 1). I may also offer a bounty for 2)
> if i won't manage to do it myself :)
> See the attachment for the code that i already have.
>
> best,
> Janek
\version "2.19.10"
% Create a new xxxStaff and xxxVoice contexts with specified settings,
% derived from specified yyyStaff and yyyVoice contexts.
%
% TODO: instead of having 3 arguments: (parentstaff, parentvoice, parentname)
% the function should take just parentname and get parentstaff and parentvoice
% from that.
newLayoutInstrument =
#(define-scheme-function
(parser location name parentstaff parentvoice parentname grouping staffsettings voicesettings)
(string? ly:context-def? ly:context-def? string? ly:context-def? ly:context-mod? ly:context-mod?)
(let ((staffname (string-append name "Staff"))
(voicename (string-append name "Voice"))
(parentstaffname (string-append parentname "Staff"))
(parentvoicename (string-append parentname "Voice")))
#{
\layout {
\context {
#grouping
\accepts #staffname
}
\context {
#parentstaff
\name #staffname
\alias #parentstaffname
\accepts #voicename % is it possible to make it accept Voices of derived instruments?
\defaultchild #voicename
#staffsettings
}
\context {
#parentvoice
\name #voicename
\alias #parentvoicename
#voicesettings
}
}
#}))
% UGH!!! CODE DUPLICATION!!!
% This function is almost identical to the one above - obviously, they should be merged,
% but I didn't yet find a way to put both \layout and \midi stuff into one function :(
newMidiInstrument =
#(define-scheme-function
(parser location name parentstaff parentvoice parentname grouping staffsettings voicesettings)
(string? ly:context-def? ly:context-def? string? ly:context-def? ly:context-mod? ly:context-mod?)
(let ((staffname (string-append name "Staff"))
(voicename (string-append name "Voice"))
(parentstaffname (string-append parentname "Staff"))
(parentvoicename (string-append parentname "Voice")))
#{
\midi {
\context {
#grouping
\accepts #staffname
}
\context {
#parentstaff
\name #staffname
\alias #parentstaffname
\accepts #voicename
\defaultchild #voicename
#staffsettings
}
\context {
#parentvoice
\name #voicename
\alias #parentvoicename
#voicesettings
}
}
#}))
% define "instruments" - one generic and another one derived:
\layout {
\newLayoutInstrument "Vocal" \Staff \Voice "" \ChoirStaff
\with {
\consists "Ambitus_engraver"
instrumentName = "Vocals"
shortInstrumentName = "Voc."
\dynamicUp
\tupletUp
}
\with { }
}
\midi {
\newMidiInstrument "Vocal" \Staff \Voice "" \ChoirStaff
\with {
\remove "Staff_performer"
}
\with {
\consists "Staff_performer"
midiInstrument = "voice oohs"
}
}
\layout {
\newLayoutInstrument "Soprano" \VocalStaff \VocalVoice "Vocal" \ChoirStaff
\with
[bounty] context generating function - how to get context def from its name?
Hi all,
i got stuck when working on a function that creates custom context
definitions. The idea is to have a function \newInstrument that would
take a list of settings and create new customized xxxStaff and
xxxVoice contexts - something like this:
newInstrument =
#(define-scheme-function
(parser location instrName parentName settings)(string? ly:context-mod?)
;; ...
#{
\layout {
\context {
;; create "instrNameStaff" context, derived from "parentNameStaff",
;; with default child "instrNameVoice", and modifications specified
;; in "settings" argument
}
\context {
;; create "instrNameVoice" context, derived from "parentNameVoice",
}
}
#})
As you can see, i want to be able to specify the "parent" instrument
from which the new instrument will "inherit" settings. For example, i
want to define a "Vocals" instrument (=> VocalsStaff and VocalsVoice
contexts, derived from Staff and Voice, respectively) and a "Soprano"
instrument derived from "Vocals" (=> SopranoStaff and SopranoVoice
contexts, derived from VocalsStaff and VocalsVoice, respectively).
I managed to write a function that does something like this, but I
have two problems:
1) inside the function, i don't know how to get a context definition
from its name (i.e. from a string). Right now i have to pass parent
contexts' definitions as separate arguments, but this means that i
have three arguments instead of one.
2) i didn't manage to get midi stuff done inside the same function as
the layout stuff - but i think that i'll be able to solve that if i
have a solution to 1).
I offer €25 bounty for solving 1). I may also offer a bounty for 2)
if i won't manage to do it myself :)
See the attachment for the code that i already have.
best,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Appendix - Articulations and Ornamentation - part 2 (issue 114840043 by pkx1...@gmail.com)
Thanks Mark. Note I went with @code{} or @code{} and have had to include
a forced break for \stacatissimo as the automatic linebreak looked
awkward.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1513
Documentation/notation/notation-appendices.itely:1513: attached to notes
(eg. @samp{f\accent}). Each example shows the script
On 2014/07/24 20:22:38, Mark Polesky wrote:
(eg. @samp{f\accent} or @samp{f->}).
(see comments below)
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1558
Documentation/notation/notation-appendices.itely:1558: @code{\accent}
On 2014/07/24 20:22:38, Mark Polesky wrote:
It would make sense to also include the shortcuts here too. One of
these should
work, I think:
@item
@code{\accent}
@code{->}
@item @code{\accent}
@itemx @code{->}
@item
@code{\accent}@*@code{->}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1568
Documentation/notation/notation-appendices.itely:1568: @code{\marcato}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{-^}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1573
Documentation/notation/notation-appendices.itely:1573: @code{\portato}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{-_}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1579
Documentation/notation/notation-appendices.itely:1579:
@code{\staccatissimo}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{-!}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1584
Documentation/notation/notation-appendices.itely:1584: @code{\staccato}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{-.}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1589
Documentation/notation/notation-appendices.itely:1589: @code{\tenuto}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{--}
Done.
https://codereview.appspot.com/114840043/diff/80001/Documentation/notation/notation-appendices.itely#newcode1795
Documentation/notation/notation-appendices.itely:1795: @code{\stopped}
On 2014/07/24 20:22:38, Mark Polesky wrote:
@code{-+}
Done.
https://codereview.appspot.com/114840043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippet tags
On 25/07/14 15:44, David Kastrup wrote: Phil Holmes writes: Currently, the snippets in http://lilypond.org/doc/v2.19/Documentation/snippets/index include the current categories/tags: IIRC, the introductory text for the snippets states that this is just an excerpt of topics. But I don't think that we have a "full list" anywhere, so that's somewhat pointless. However, there are a _lot_ more tags in the snippet repository (see below). One upshot of this is that tagging a snippet with the "wrong" tags will prevent it appearing in the docs automatically. Should we update the list above to be the same as the one below? ancient-notation automatic-notation breaks chords connecting-notes contemporary-notation contexts-and-engravers devel editorial-annotations expressive-marks fretted-strings headword keyboards midi paper-and-layout percussion pitches preparing-parts really-cool really-simple real-music repeats rhythms scheme-language simultaneous-notes spacing specific-notation staff-notation stylesheet symbols-and-glyphs syntax-and-expressions template text titles tweaks-and-overrides unfretted-strings version-specific vocal-music winds workaround world-music I think that's excessive for the sort of unfolded table-of-contents structure that we have integrated that with. At the current point it is already hard to find anything in that mess. Blowing it up by a factor of 2 will not help. We probably need to find a somewhat more hierarchical structure for navigational purposes. I agree that is excessive. However, much like @cindex entries; you ask 3 people what a good entry would be and you'll get 4 different answers (it's an exercise in guessing someone else's thought process - you'll be on a hiding-to-nothing). Whatever 'one' does someone will complain or grumble :) Things like really-cool really-simple real-music are not that helpful. I don't have a real solution other than agreeing on what David said by making it Hierarchical, so you would have perhaps a minimum of three tags where thr first three are required. [type of music] / [type of notation] / [type of tweak] sort of thing (I am probably not articulating it that well, sorry). So Ancient-Music / noteheads / overrides Vocal-Music / lyrics / overrides / spacing Fretted-Music / markups / visibility Or something like that. Just my 1p's worth. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippet tags
Phil Holmes writes: > Currently, the snippets in > http://lilypond.org/doc/v2.19/Documentation/snippets/index include the > current categories/tags: IIRC, the introductory text for the snippets states that this is just an excerpt of topics. But I don't think that we have a "full list" anywhere, so that's somewhat pointless. > However, there are a _lot_ more tags in the snippet repository (see below). > One upshot of this is that tagging a snippet with the "wrong" tags will > prevent it appearing in the docs automatically. Should we update the list > above to be the same as the one below? > ancient-notation > automatic-notation > breaks > chords > connecting-notes > contemporary-notation > contexts-and-engravers > devel > editorial-annotations > expressive-marks > fretted-strings > headword > keyboards > midi > paper-and-layout > percussion > pitches > preparing-parts > really-cool > really-simple > real-music > repeats > rhythms > scheme-language > simultaneous-notes > spacing > specific-notation > staff-notation > stylesheet > symbols-and-glyphs > syntax-and-expressions > template > text > titles > tweaks-and-overrides > unfretted-strings > version-specific > vocal-music > winds > workaround > world-music I think that's excessive for the sort of unfolded table-of-contents structure that we have integrated that with. At the current point it is already hard to find anything in that mess. Blowing it up by a factor of 2 will not help. We probably need to find a somewhat more hierarchical structure for navigational purposes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Snippet tags
Currently, the snippets in http://lilypond.org/doc/v2.19/Documentation/snippets/index include the current categories/tags: ancient notation chords contexts and engravers editorial annotations expressive marks fretted strings keyboards midi paper and layout percussion pitches repeats rhythms simultaneous notes spacing staff notation template text titles tweaks and overrides unfretted strings vocal music winds world music However, there are a _lot_ more tags in the snippet repository (see below). One upshot of this is that tagging a snippet with the "wrong" tags will prevent it appearing in the docs automatically. Should we update the list above to be the same as the one below? ancient-notation automatic-notation breaks chords connecting-notes contemporary-notation contexts-and-engravers devel editorial-annotations expressive-marks fretted-strings headword keyboards midi paper-and-layout percussion pitches preparing-parts really-cool really-simple real-music repeats rhythms scheme-language simultaneous-notes spacing specific-notation staff-notation stylesheet symbols-and-glyphs syntax-and-expressions template text titles tweaks-and-overrides unfretted-strings version-specific vocal-music winds workaround world-music ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ambitus snippet
I think the snippet at: http://lilypond.org/doc/v2.19/Documentation/snippets/contexts-and-engravers#contexts-and-engravers-defining-an-engraver-in-scheme_003a-ambitus-engraver is rather complex to be included in the docs: I don't see why one would want to rewrite existing capability? Anyone object to its removal from the docs? (I'd create it on the LSR assuming it works there). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add an expert font tree interface (issue 108700043 by perpeduumimmob...@gmail.com)
On 07/25/2014 05:55 AM, markpole...@gmail.com wrote: https://codereview.appspot.com/108700043/diff/80001/input/regression/font-expert-selection.ly Mark, thanks for the comments. James, give this at least one more cycle, please. I'll incorporate the changes as soon as I can find the time, and want to double-check the entire patchset again - hopefully I'll have more time available next week. Best, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)
Thanks for checking.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode354
Documentation/contributor/administration.itexi:354: branches (prefrixed
with @code{test-}) with a third branch, called
On 2014/07/24 21:11:24, Mark Polesky wrote:
prefixed
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode591
Documentation/contributor/administration.itexi:591: The tracker issue's
lable is then changed automatically to
On 2014/07/24 19:32:50, Julien Rioux wrote:
label
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode606
Documentation/contributor/administration.itexi:606: lable is changed
automatically to @qq{Patch-Needs_work}.
On 2014/07/24 19:32:50, Julien Rioux wrote:
label
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode627
Documentation/contributor/administration.itexi:627: 02 0-23/2 * * *
/home/joe/lilypond-extra/patches/lilypond-patchy-staging.py
On 2014/07/24 19:32:50, Julien Rioux wrote:
joe -> patchy
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode694
Documentation/contributor/administration.itexi:694: This occurs when
Patchy detects that the commit ID is has not changed
On 2014/07/24 19:32:50, Julien Rioux wrote:
"is has" -> "has"
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode712
Documentation/contributor/administration.itexi:712: A previous test
attempt was unsuccesful for some reason and the scripts
On 2014/07/24 21:11:24, Mark Polesky wrote:
unsuccessful
Done.
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode783
Documentation/contributor/administration.itexi:783: merge from staging
On 2014/07/24 21:11:24, Mark Polesky wrote:
replace tabs with spaces
Done.
https://codereview.appspot.com/112280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
