Re: Patch: Delete intermediate ps files
On Tue, Jul 14, 2009 at 09:34:34PM +0100, Neil Puttock wrote: 2009/7/13 Maximilian Albert maximilian.alb...@googlemail.com: Thanks a lot! So does this close issue 685? Yes. Not until somebody changes the status! Remember, whenever you push a fix to master, alter the status on the tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax changes in translated documentation
On Tue, Jul 14, 2009 at 04:23:52PM +0200, Jean-Charles Malahieude wrote: I'm going back to updating the web branch. I'm never certain how much translators know about the other development stuff... just checking, you *do* know that the entire web branch might be obsolete in 1 month? Ok, I said might; it's more likely to be 2 or 3 months now... but the point remains that any work you put into web now is unlikely to be visible for a long time. I mean, if you want to just fix a few obvious mistakes or untranslated areas, by all means do so. But I wouldn't want you to spend a lot of time on this if you didn't realize that it'll all be changing soon... Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for user view of docs
On Sat, Jul 11, 2009 at 03:13:53AM -0700, Graham Percival wrote: Here's my proposal for the user's view of the documentation. - the website is available in HTML, info, and pdf. If you type info lilypond, you get the website. Package managers might create a lilypond-doc package consisting of the pdfs, or a local copy of the HTML, or whatever. - when the user clicks (or info-browses to) on Manuals, he sees pretty much the current Manuals page: http://percival-music.ca/blogfiles/out/lilypond-general_15.html - when the user clicks on Learning Manual, he gets the first page of the LM, namely: http://lilypond.org/doc/v2.13/Documentation/user/lilypond-learning/index That sounds great to me. There are a few modifications: - the top menu from the website might still present (I'm not certain if this would be a good idea or not) - the Back to the Documentation Index link in the top-left corner takes the user back to the Manuals page. (actually, if we keep the top website menu, we can remove that Back to the Documentation Index link) I don't know if we could manage this, i.e. keeping the top website menu for the docs. The navbar for the main website uses an absolute positioned div#tocframe, and the TOC for the docs uses the same technique. They currently have the same id, but that's not a problem. I am just worried about the CSS positioning problems this would pose. The docs layout was more difficult to code than the new website layout. ...and unfortunately, the docs layout is currently broken in IE8. I need to take a look at that. :-) The current Documentation/index.html.in is completely removed. Sounds reasonable. - the same applies to all the other manuals; all 9 entries on the new website Manuals page. Yes. - there is no other user documentation. Things on the old index.html.in: Examples is dead (merged into the new Introductions-Examples), Translation Status is merged into the CG, Developer Resources is found under Community-development, Thankyous+Dedication are found under Community-Authors. That leaves License, which could go... hmm, Download? Introduction-Freedom? I think the License would be more appropriate in Download. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for doc rearrangement
On Tue, Jul 14, 2009 at 04:40:30PM +0100, Trevor Daniels wrote: Graham Percival wrote Tuesday, July 14, 2009 10:46 AM Do we want anyone to use LilyPad? If we still ship it, then we should describe it. For Windows and OSX; the linux version just has the command-line. Seems at the moment we don't ;) But you're right. We need to describe it, and its limitations. I'll take a look at the Windows LilyPad situation. I imagine it is probably something simple that was overlooked. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for user view of docs
On Tue, Jul 14, 2009 at 11:29:42PM -0700, Patrick McCarty wrote: On Sat, Jul 11, 2009 at 03:13:53AM -0700, Graham Percival wrote: There are a few modifications: - the top menu from the website might still present (I'm not certain if this would be a good idea or not) - the Back to the Documentation Index link in the top-left corner takes the user back to the Manuals page. (actually, if we keep the top website menu, we can remove that Back to the Documentation Index link) I don't know if we could manage this, i.e. keeping the top website menu for the docs. -snip- Good reasons. Quite apart from the positioning, there's the question of whether (that instance of) texi2html knows all the node names. The 1990s solution would be to put the manuals inside a frame, but that's an awfully netscape navigator 4-type solution. So, in other words, not a solution at all. :) Let's keep the top-left Back to Documentation link, then. - there is no other user documentation. Things on the old index.html.in: Examples is dead (merged into the new Introductions-Examples), Translation Status is merged into the CG, Developer Resources is found under Community-development, Thankyous+Dedication are found under Community-Authors. That leaves License, which could go... hmm, Download? Introduction-Freedom? I think the License would be more appropriate in Download. I'll do that, and leave a link to it from Introduction-Freedom. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for user view of docs
Le samedi 11 juillet 2009 à 03:13 -0700, Graham Percival a écrit : - the website is available in HTML, info, and pdf. If you type info lilypond, you get the website. Package managers might create a lilypond-doc package consisting of the pdfs, or a local copy of the HTML, or whatever. Using might is a little too light here, even if Lily doc packaging has not been so succesful; if we scrap the HTML documentation index, we should replace it with something that *will mostly* build out of the box. Apart from this nitpick, it's an excellent idea. There are a few modifications: - the top menu from the website might still present (I'm not certain if this would be a good idea or not) I second this, as this would make the link between documentation Why not just naming this page Documentation (or even Documentation Central à la Python) instead of Manuals? I can see no risk of confusion between this and documentation for developers and contributors (which can be found under Community). - the Back to the Documentation Index link in the top-left corner takes the user back to the Manuals page. (actually, if we keep the top website menu, we can remove that Back to the Documentation Index link) I don't see the point of distracting the reader with the top website menu while she is reading the documentation. - there is no other user documentation. Things on the old index.html.in: Examples is dead (merged into the new Introductions-Examples), Translation Status is merged into the CG, Translation status is not only information for translators, but for any non-English-speaking user too, so it should appear in Manuals, maybe in small letters, and in the footer of translated pages. It certainly has not its place in the CG. I'm fine with the other choices you made. Best, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax changes in translated documentation
Le mardi 14 juillet 2009 à 23:27 -0700, Graham Percival a écrit : On Tue, Jul 14, 2009 at 04:23:52PM +0200, Jean-Charles Malahieude wrote: I'm going back to updating the web branch. I'm never certain how much translators know about the other development stuff... just checking, you *do* know that the entire web branch might be obsolete in 1 month? When I was only a translator, I always tried to read all of lilypond-devel traffic, skipping only paragraphs I didn't understand, but never ignoring entire threads. I expect all translators to do so, including chiming in whenever they feel it necessary. Translators, please be patient for a few days so I can catch up with every emails since June. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translation review requests -- texi2html's handling of @ignore blocks
Le lundi 13 juillet 2009 à 10:57 +0200, Jan Nieuwenhuizen a écrit : I realised it would be nice if texi2html would copy any @ignore @end ignore blocks to html comments !-- GIT committish: !-- so that you can easily check if the website is up to date. It would be even simpler if texi2html could even copy every comment into HTML output, just like Makeinfo. I added this on my check/to-do list. Thanks, John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: translation review requests -- texi2html's handling of @ignore blocks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 13. Juli 2009 10:57:23 schrieb Jan Nieuwenhuizen: Just talking to xorius on #lilypond about where the latest french translations live for review... I realised it would be nice if texi2html would copy any @ignore @end ignore blocks to html comments !-- GIT committish: !-- so that you can easily check if the website is up to date. Actually, @ignore blocks are not supposed to be processed at all, that's why they are called ignore. However, @c comments would make sense to include as comments in the html code. You might ask Patrice (on the texi2html mailing list) about this feature. He has always been very forthcoming and usually implemented things within hours. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKXdaRTqjEwhXvPN0RAsxcAJ9fDlI18YRX42DQp5XppOSa5qmecwCg0BY+ QwrZqwZUkAxYah5bI+ooBcQ= =DAxk -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[ANNOUNCE] Git User's Survey 2009 (fwd)
Hi, as every year, there is a user's survey about Git; Hopefully as every year, useful and fascinating ideas will crop up! Ciao, Johannes -- Forwarded message -- Date: Wed, 15 Jul 2009 09:22:32 +0200 From: Jakub Narebski jna...@gmail.com To: g...@vger.kernel.org Subject: [ANNOUNCE] Git User's Survey 2009 Hi all, We would like to ask you a few questions about your use of the Git version control system. This survey is mainly to understand who is using Git, how and why. The results will be published to the Git wiki and discussed on the git mailing list. The survey would be open from 15 July till 15 September 2009. Please devote a few minutes of your time to fill this simple questionnaire, it will help a lot the git community to understand your needs, what you like of Git, and of course what you don't like of it. The survey can be found here: http://tinyurl.com/GitSurvey2009 http://www.survs.com/survey?id=2PIMZGU0channel=Q0EKJ3NF54 -- Git Development Community -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Obsolete snippets
Le lundi 13 juillet 2009 à 06:07 -0600, Carl Sorensen a écrit : So, in order to not have broken documentation, I need to eliminate old file referenes, and old in-line snippets as well. I guess I should just edit all of the Documentation/*/user/rhythms.itely and delete the parts that have been deleted in the english version, and insert the parts (in english) that have been added to the english version, thus leaving a mixed-language file. Is this correct? Yes, it is. If a majority of translators prefer that the outdated part of the translation is just deleted and not replaced by anything, we might adopt a simpler policy. I don't care as long as this does not put too much burden on doc contributors and developers. Fortunately changes that are not convert-lyable are not so frequent. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
Le mercredi 15 juillet 2009 à 07:43 -0600, Carl Sorensen a écrit :
On 7/14/09 3:57 PM, n.putt...@gmail.com n.putt...@gmail.com wrote:
http://codereview.appspot.com/88155/diff/95/1147#newcode69
Line 69: section 1.2.4 Beams, for more information.
Is it possible to use @ruser{} here?
I'm not sure. I thought NEWS was supposed to be a standalone document.
Graham, you're the source of all truth about documents; what do you think?
There is no @ruser defined in NEWS. However, see top of NEWS.tely: a
macro named @usermanref is defined, but it's currently unused in both
2.12 and 2.13, so please check whether it works before pushing.
Fortunately, Graham's proposal of reorganization will lead to clean up
and unify our Texinfo xref cooking.
Best,
John
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using LyricHyphens in the docs
Trevor == Trevor Daniels t.dani...@treda.co.uk writes: Trevor Mark Polesky wrote Tuesday, July 14, 2009 7:38 AM I think the Salve, Regína example in NR 2.8 Ancient Notation would be improved by using LyricHyphens. For example, instead of Sal- ve, Re- gí- na, use Sal -- ve, Re -- gí -- na,. Unless there's some ancient hyphen typesetting convention that I don't know about. The file involved is input/manual/ancient-headword.ly. There may be others, but I just noticed it there. Anyone care to comment on that? Trevor I know essentially nothing about ancient music, Trevor but as these examples were set by experts I assume Trevor they know what should be done. I doubt that Trevor ancient music was ever typeset using modern Trevor lyric spacing hyphens, not least because the Trevor ligatures are conventionally grouped closely Trevor together, and the syllable (with the hyphen) Trevor almost always sits neatly under them. I don't know that much about the chant publications, but the 16th and early 17th century facsimiles I transcribe from don't use hyphens to separate syllables at all. Underlay was a performers' job, not a music publishers'. I agree with Marc that the LyricHyphen's look better than having the hyphen be part of the word, and I suspect the experts were introducing hyphens and just weren't expert enough in lilypond to know the best way of doing that. Of course, I may be wrong and chant publishers may have felt differently about underlay than madrigal publishers. -- Laura (mailto:lcon...@laymusic.org) (617) 661-8097 233 Broadway, Cambridge, MA 02139 http://www.laymusic.org/ http://www.serpentpublications.org I thought hell is bound to be a livelier place, as he joins forever those whom he served in life, applauding their prejudices and fanning their hatred. Gore Vidal, when asked how he felt on hearing that William F. Buckley had died. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: using LyricHyphens in the docs
Laura Conrad wrote: Trevor I know essentially nothing about ancient music, Trevor but as these examples were set by experts I assume Trevor they know what should be done. I doubt that Trevor ancient music was ever typeset using modern Trevor lyric spacing hyphens, not least because the Trevor ligatures are conventionally grouped closely Trevor together, and the syllable (with the hyphen) Trevor almost always sits neatly under them. I don't know that much about the chant publications, but the 16th and early 17th century facsimiles I transcribe from don't use hyphens to separate syllables at all. Underlay was a performers' job, not a music publishers'. I eventually found a source copy online: http://interletras.com/canticum/salve_regina.html Clearly we should leave the hyphens in that example as they are. However, there are other examples in the docs that I think would benefit from LyricHyphens (NR 2.1.2, NR 2.1.3, and NR 2.1.5). If I have time later, perhaps I can get around to it, but if nothing else, I've made a note of it here with this post. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
On 7/15/09 9:30 AM, John Mandereau john.mander...@gmail.com wrote:
Le mercredi 15 juillet 2009 à 07:43 -0600, Carl Sorensen a écrit :
On 7/14/09 3:57 PM, n.putt...@gmail.com n.putt...@gmail.com wrote:
http://codereview.appspot.com/88155/diff/95/1147#newcode69
Line 69: section 1.2.4 Beams, for more information.
Is it possible to use @ruser{} here?
I'm not sure. I thought NEWS was supposed to be a standalone document.
Graham, you're the source of all truth about documents; what do you think?
There is no @ruser defined in NEWS. However, see top of NEWS.tely: a
macro named @usermanref is defined, but it's currently unused in both
2.12 and 2.13, so please check whether it works before pushing.
I tried, and it didn't work (but it didn't appear to break compilation,
either). So for right now, I think I'll leave the reference out.
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
Carl Sorensen wrote:
What if a property like tweak-callback were added, whose job is
just to trigger the grob callback necessary for what you want to
do?
Then you could have
\relative {
c! \tweak #'tweak-callback #color-accidental e! g!
}
I think you could have multiple calls to #'tweak-callback,
because all of the tweaks are stored in a list, and would all be
executed.
\displayMusic
\relative {
c
\tweak #'color #red
\tweak #'color #yellow
d
}
Unfortunately this doesn't seem to work. See attached PNG and
console output below. When using this indirect tweaking method,
only the *last* tweak affects the typeset output. The desired
output in the example below is to have both E-naturals colored red
and reduced in size. The first one is reduced but not colored; the
second one is colored, but not reduced.
It seems to me that a satisfactory resolution of this issue will
have significant implications for my LilyPond projects, so
hopefully someone can help me find the answer!
Thanks so much.
- Mark
\version 2.13.2
#(define (color-accidental note-grob color)
;; notehead before-line-breaking callback
(let ((accidental (ly:grob-object note-grob 'accidental-grob)))
(if (not (null? accidental))
(ly:grob-set-property! accidental 'color color
#(define (resize-accidental note-grob fontsize)
;; notehead before-line-breaking callback
(let ((accidental (ly:grob-object note-grob 'accidental-grob)))
(if (not (null? accidental))
(ly:grob-set-property! accidental 'font-size fontsize
\relative {
c!
\tweak #'before-line-breaking
#(lambda (grob) (color-accidental grob red))
\tweak #'before-line-breaking
#(lambda (grob) (resize-accidental grob -3)) e!
\displayMusic
c!
\tweak #'before-line-breaking
#(lambda (grob) (resize-accidental grob -3))
\tweak #'before-line-breaking
#(lambda (grob) (color-accidental grob red)) e!
}
(make-music
'EventChord
'elements
(list (make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'force-accidental
#t
'pitch
(ly:make-pitch -1 0 0))
(make-music
'NoteEvent
'duration
(ly:make-duration 2 0 1 1)
'tweaks
(list (cons 'before-line-breaking
#procedure #f (grob))
(cons 'before-line-breaking
#procedure #f (grob)))
'force-accidental
#t
'pitch
(ly:make-pitch -1 2 0
attachment: accidental-tweaks.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @subsection foo should get name=foo
Graham Percival wrote:
Yes. You can add a menu to the Feta font
section and introduce each subsection with
@node
@subsection ...
As we're in an appendix maybe this should be
@node ...
@appendixsubsec ... ?
I believe it should be
@node
@unnumberedsubsec
You can use them inside an @appendicsec, and since the html pages
are split based on numbers, we want an @unnumbered... there.
Just want to make sure I have this right. Is this outline correct?
Thanks.
- Mark
@node The Feta font
@appendixsec The Feta font
@cindex Feta font
@cindex Font, Feta
The following symbols are available in the Emmentaler font and may be
accessed directly using text markup such as @code{g^\markup @{
\musicglyph #scripts.segno @}}, see @ref{Formatting text}.
@menu
* Clefs::
* Time Signatures::
etc...
@end menu
@node Clefs
@unnumberedsubsec Clefs
@lilypond[quote]
\include font-table.ly
\markuplines \override-lines #'(word-space . 4)
\doc-chars #clefs
@end lilypond
@node Time Signatures
@unnumberedsubsec Time Signatures
@lilypond[quote]
\include font-table.ly
\markuplines \override-lines #'(word-space . 4)
\doc-chars #timesig
@end lilypond
etc...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
musicxml2ly bug?
Dear list, while trying to import some scores into lilypond i was given as xml export from a finale using collegue, i stumbled across some problems... by far the most common one i tried to reduce into the attached files. while the xml (correctly) contains a Vivace mark in the first bar, the .ly file resulting from musicxml2ly conversion shifts it incorrectly into the third bar, where it finds the first pitch... unfortunately i do not feel able to provide a patch for that myself... yours, arno http://www.nabble.com/file/p24505418/pause-und-vortragsbez.png pause-und-vortragsbez.png http://www.nabble.com/file/p24505418/pause-und-vortragsbez.ly pause-und-vortragsbez.ly http://www.nabble.com/file/p24505418/pause-und-vortragsbez.xml pause-und-vortragsbez.xml -- View this message in context: http://www.nabble.com/musicxml2ly-bug--tp24505418p24505418.html Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centering of instrument names
2009/5/30 Joe Neeman joenee...@gmail.com: The sanest behaviour IMO is the behaviour of your current patch, but with a different meaning for 'padding. I can see two ways to do this: the quickdirty way to get this is to replace instrument-name::calc-combined-delimiters-offset with instrument-name::calc-min-distance-to-support, which goes through all the instrument names and finds the minimum distance necessary between any instrument name and any grob in its support. The nicer way to get the same effect would be to create an InstrumentNameColumn grob that is the X-parent of all the InstrumentNames and do the instrument name positioning in ly:instrument-name-column::calc-positioning-done. I had a stab at creating an InstrumentNameColumn, which acknowledges InstrumentNames, but it doesn't work properly because InstrumentName grobs appear to be static unless there's a name change, meaning they only get acknowledged once. I placed the new engraver in the Score context, but it missed all but the first system's InstrumentNames; setting a new shortInstrumentName before the next system resulted in only that grob being acknowledged. Following your comments about keeping the positioning out of the stencil code, I've reworked my original patch completely in Scheme, removing the X- and Y-positioning to X-offset/Y-offset callbacks. I've posted the new patch set to Rietveld here: http://codereview.appspot.com/91119/show Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
2009/7/15 Carl Sorensen c_soren...@byu.edu: I'm not sure I understand why you think it should it be in input/new instead of just being in the docs. It doesn't use \set or \override. It explains the use of a LilyPond command. That's why I thought it should be an inline snippet. It's positioned in the middle of a @snippet block, so it looks like a snippet waiting to be moved to LSR. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accessing accidentals with \tweak
Mark Polesky wrote:
Mark Polesky wrote:
Okay, I figured out a way around this -- by passing an property-alist to
the 'before-line-breaking tweak, I was able to get all the accidental
modifications done in one tweak (see modify-accidental below).
I just came up with something similar. It still requires a lot of typing
though, but maybe it'll help you anyway.
#(define-macro when
(lambda (test . branch)
(list 'if test
(cons 'begin branch
#(define (change-accidental note-grob fontsize color)
;; notehead before-line-breaking callback
(let ((accidental (ly:grob-object note-grob 'accidental-grob)))
(when (not (null? accidental))
(if (integer? fontsize)
(ly:grob-set-property! accidental 'font-size fontsize))
(if (and (list? color) (= (length color) 3))
(ly:grob-set-property! accidental 'color color)
\relative {
c!
\tweak #'before-line-breaking
#(lambda (grob) (change-accidental grob -3 #f)) e!
c!
\tweak #'before-line-breaking
#(lambda (grob) (change-accidental grob #f red)) e!
c!
\tweak #'before-line-breaking
#(lambda (grob) (change-accidental grob -3 red)) e!
} http://www.nabble.com/file/p24507733/test.png test.png
--
View this message in context:
http://www.nabble.com/accessing-accidentals-with-%5Ctweak-tp24487012p24507733.html
Sent from the Gnu - Lilypond - Dev mailing list archive at Nabble.com.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New format for autobeaming rules
On 7/15/09 3:45 PM, n.putt...@gmail.com n.putt...@gmail.com wrote: http://codereview.appspot.com/88155/diff/2005/3086 File scm/music-functions.scm (right): http://codereview.appspot.com/88155/diff/2005/3086#newcode519 Line 519: (make-simultaneous-music output) This breaks all the Festival regression tests which use \time (song-associated-voice.ly, song-basic.ly, song-breathe.ly, song-melisma.ly, song-stanzas.ly song-tempo.ly): /usr/local/share/lilypond/2.13.4/scm/song.scm:707:52: In procedure last in expression (last lst-1): /usr/local/share/lilypond/2.13.4/scm/song.scm:707:52: Wrong type argument in position 1 (expecting pair): () http://codereview.appspot.com/88155 Aargh -- I thought I had run the regtests after that change, but apparently not. I've got that fixed now, and the regtests run without error. Thanks for saving my bacon, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Obsolete snippets
2009/7/15 John Mandereau john.mander...@gmail.com: Le lundi 13 juillet 2009 à 06:07 -0600, Carl Sorensen a écrit : So, in order to not have broken documentation, I need to eliminate old file referenes, and old in-line snippets as well. I guess I should just edit all of the Documentation/*/user/rhythms.itely and delete the parts that have been deleted in the english version, and insert the parts (in english) that have been added to the english version, thus leaving a mixed-language file. Is this correct? Yes, it is. If a majority of translators prefer that the outdated part of the translation is just deleted and not replaced by anything, we might adopt a simpler policy. Yes. I prefer you not to insert anything in English in my translated docs (IIRC this has never been done before) if this is not costly for others. Anything you change in the original English docs will be noticed thanks to the check-translation infrastructure scripts. -- Francisco Vila. Badajoz (Spain) www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Obsolete snippets
On 7/15/09 6:30 PM, Francisco Vila paconet@gmail.com wrote: 2009/7/15 John Mandereau john.mander...@gmail.com: Le lundi 13 juillet 2009 à 06:07 -0600, Carl Sorensen a écrit : So, in order to not have broken documentation, I need to eliminate old file referenes, and old in-line snippets as well. I guess I should just edit all of the Documentation/*/user/rhythms.itely and delete the parts that have been deleted in the english version, and insert the parts (in english) that have been added to the english version, thus leaving a mixed-language file. Is this correct? Yes, it is. If a majority of translators prefer that the outdated part of the translation is just deleted and not replaced by anything, we might adopt a simpler policy. Yes. I prefer you not to insert anything in English in my translated docs (IIRC this has never been done before) if this is not costly for others. Anything you change in the original English docs will be noticed thanks to the check-translation infrastructure scripts. OK, I'll delete all the English and just leave the corrected snippets in the Spanish docs. How about french and german? What would you prefer? Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: proposal for user view of docs
On Wed, Jul 15, 2009 at 01:42:33PM +0200, John Mandereau wrote: Le samedi 11 juillet 2009 à 03:13 -0700, Graham Percival a écrit : There are a few modifications: - the top menu from the website might still present (I'm not certain if this would be a good idea or not) I second this, as this would make the link between documentation Why not just naming this page Documentation (or even Documentation Central à la Python) instead of Manuals? I can see no risk of confusion between this and documentation for developers and contributors (which can be found under Community). A few weeks ago in one of the website draft threads, somebody proposed Manuals instead of Documentation. Jan approved of the idea. At first I was a bit iffy, but now I like it better than Documentation. That said, I'm not absolutely wedded to the word change. I mostly like it because it's shorter (so more space between top-menu entries) and has a different letter than downloads (so the mind can more easily recognize that it's different from downloads, especially when they're next to each other). - there is no other user documentation. Things on the old index.html.in: Examples is dead (merged into the new Introductions-Examples), Translation Status is merged into the CG, Translation status is not only information for translators, but for any non-English-speaking user too, so it should appear in Manuals, maybe in small letters, and in the footer of translated pages. It certainly has not its place in the CG. Really? Ick, we already have so many sections in Manuals... but I already added a fourth section divisor to this chapter, so there's a natural place to put this. Ok, done. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: @subsection foo should get name=foo
On Wed, Jul 15, 2009 at 01:44:03PM -0700, Mark Polesky wrote: Graham Percival wrote: I believe it should be @node @unnumberedsubsec You can use them inside an @appendicsec, and since the html pages are split based on numbers, we want an @unnumbered... there. Just want to make sure I have this right. Is this outline correct? Yep, looks good. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New markup commands: \left-brace \right-brace.
http://codereview.appspot.com/8874/diff/2201/3202 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/8874/diff/2201/3202#newcode2625 Line 2625: (find-brace (binary-search 0 575 get-y-from-brace scaled-size)) Would Open_type_font::count () return the value 575 you need here? I'm not sure, because this function is not used anywhere, and I don't understand the Freetype code. If it does return 575, I would recommend writing and using a callback to retrieve this value, named something like ly:otf-glyph-count. http://codereview.appspot.com/8874 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New markup commands: \left-brace \right-brace.
On Wed, Jul 15, 2009 at 8:40 PM, pnor...@gmail.com wrote: http://codereview.appspot.com/8874/diff/2201/3202 File scm/define-markup-commands.scm (right): http://codereview.appspot.com/8874/diff/2201/3202#newcode2625 Line 2625: (find-brace (binary-search 0 575 get-y-from-brace scaled-size)) Would Open_type_font::count () return the value 575 you need here? I'm not sure, because this function is not used anywhere, and I don't understand the Freetype code. If it does return 575, I would recommend writing and using a callback to retrieve this value, named something like ly:otf-glyph-count. http://codereview.appspot.com/8874 I need to learn to check these things with GDB before I post. :-P Open_type_font::count () is called in System_start_delimiter::staff_brace (), and it does indeed return the value 575. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH v3] Fix crash when a stencil routine is missing
On Tue, Jul 7, 2009 at 2:44 PM, Patrick McCartypnor...@gmail.com wrote: Hello, The third revision of my patch set (Patch Set 5) is on Rietveld: http://codereview.appspot.com/83046/show The change from Patch Set 4 is the generalization of -dwarning-as-error. Note that this is a series of 8 commits that contain more in-depth commit summaries. They can be found here: http://repo.or.cz/w/lilypond/patrick.git?a=shortlog;h=refs/heads/stencil-update Does anyone have comments for these changes? Really, there are four separate changes: 1) Removing obsolete code from lily.scm and output-ps.scm. 2) Enabling warnings for missing stencil expressions. Currently, Guile crashes in these cases. 3) Revision of define-stencil-commands.scm so that it makes more sense. 4) Adding a new option, -dwarning-as-error, that turns all warnings into errors if enabled. IMO, 1) and 3) are completely harmless. I'm not entirely sure if I used the best approach for 2) or 4). Thanks in advance for your feedback. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix crash when a stencil routine is missing
lgtm http://codereview.appspot.com/83046 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New instrument name positioning in Scheme.
Just one corner case, otherwise lgtm http://codereview.appspot.com/91119/diff/1/10 File scm/output-lib.scm (right): http://codereview.appspot.com/91119/diff/1/10#newcode833 Line 833: (interval-center extent If (not (pair? live-elts)) then (interval-center extent) will be NaN, instead of 0 which would be more sensible. http://codereview.appspot.com/91119 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: centering of instrument names
On Wed, 2009-07-15 at 22:07 +0100, Neil Puttock wrote: 2009/5/30 Joe Neeman joenee...@gmail.com: The sanest behaviour IMO is the behaviour of your current patch, but with a different meaning for 'padding. I can see two ways to do this: the quickdirty way to get this is to replace instrument-name::calc-combined-delimiters-offset with instrument-name::calc-min-distance-to-support, which goes through all the instrument names and finds the minimum distance necessary between any instrument name and any grob in its support. The nicer way to get the same effect would be to create an InstrumentNameColumn grob that is the X-parent of all the InstrumentNames and do the instrument name positioning in ly:instrument-name-column::calc-positioning-done. I had a stab at creating an InstrumentNameColumn, which acknowledges InstrumentNames, but it doesn't work properly because InstrumentName grobs appear to be static unless there's a name change, meaning they only get acknowledged once. I placed the new engraver in the Score context, but it missed all but the first system's InstrumentNames; setting a new shortInstrumentName before the next system resulted in only that grob being acknowledged. Right, because there's only one InstrumentName. But if your InstrumentNameColumn is a spanner and it spans the whole staff, it will get broken up into lots of little InstrumentNameColumns, one for each system. And each of those InstrumentNameColumns will contain the broken piece of the InstrumentName that corresponds to the same system. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
