doc reorg (especially Usage) possibly finished
What do people think about the doc reorg shown in: http://kainhofer.com/~lilypond/Documentation/general/Manuals.html (and the actual manual pages, of course) I think I have the balance between Learning and Usage good now. The only remaining issues are: 1) Learning B. Scheme tutorial -- do we want to keep this here, or integrate into Learning 4? Or _possibly_ make a Learning 5 Programming inside LilyPond? 2) Was there some reason why all the indices are called "LilyPond index"? I have a vaugue recollection that it worked better in the info format or something like that...? If somebody could search the archives to look for any such reason, that would be nice. If there's no such reason, then I'd rather rename them in some way. 3) I'm not convinced about the order of material inside each chapter of Usage yet -- at the moment, I just want people to consider the division of stuff into chapters, not within each chapter. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
+1. (I've always felt this way, too.) Trevor (B). On Thu, Sep 24, 2009 at 5:44 PM, Werner LEMBERG wrote: > > What's the reason that line breaks are by default forbidden if there > is a broken beam crossing the bar line, and that you have to set the > `breakable' flag manually to override it? > > BTW, it is very unpleasant that lilypond doesn't emit any kind of > warning if it produces an overlong staff caused by that issue. It > silently accumulates unbreakable bars and happily walks out of the > right margin. I would consider this behaviour a bug. > > >Werner > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
>> What's the reason that line breaks are by default forbidden if >> there is a broken beam crossing the bar line, and that you have to >> set the `breakable' flag manually to override it? >> >> BTW, it is very unpleasant that lilypond doesn't emit any kind of >> warning if it produces an overlong staff caused by that issue. It >> silently accumulates unbreakable bars and happily walks out of the >> right margin. I would consider this behaviour a bug. > > +1. > > (I've always felt this way, too.) Then let's drop the IMHO unfounded limitation of not breaking at beams crossing a barline. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line breaks and broken beams
Werner LEMBERG writes: >>> What's the reason that line breaks are by default forbidden if >>> there is a broken beam crossing the bar line, and that you have to >>> set the `breakable' flag manually to override it? >>> >>> BTW, it is very unpleasant that lilypond doesn't emit any kind of >>> warning if it produces an overlong staff caused by that issue. It >>> silently accumulates unbreakable bars and happily walks out of the >>> right margin. I would consider this behaviour a bug. >> >> +1. >> >> (I've always felt this way, too.) > > Then let's drop the IMHO unfounded limitation of not breaking at beams > crossing a barline. Is there a way to slightly penalize it rather than prohibiting it completely or being completely unconcerned? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
On 9/27/09 6:57 AM, "Graham Percival" wrote: > What do people think about the doc reorg shown in: > http://kainhofer.com/~lilypond/Documentation/general/Manuals.html > (and the actual manual pages, of course) > > > I think I have the balance between Learning and Usage good now. > The only remaining issues are: > > 1) Learning B. Scheme tutorial -- do we want to keep this here, or > integrate into Learning 4? Or _possibly_ make a Learning 5 > Programming inside LilyPond? I don't think we want to put this in the main body of the Learning Manual, since we ask readers to read the LM cover to cover. I think that having it as an appendix is the right thing to do. But I like the name Programming inside LilyPond much better than Scheme tutorial. > > 2) Was there some reason why all the indices are called "LilyPond > index"? I have a vaugue recollection that it worked better in the > info format or something like that...? index.html is the default page for a website. Hence, we wanted LilyPond index. > If somebody could search the archives to look for any such reason, > that would be nice. If there's no such reason, then I'd rather > rename them in some way. > > 3) I'm not convinced about the order of material inside each > chapter of Usage yet -- at the moment, I just want people to > consider the division of stuff into chapters, not within each > chapter. I like the division of stuff into chapters. Looks good! I think there should be at least a pointer to OooLilyPond in Usage 3.2., I do have a minor nit to pick: on the Manuals page, the regular use section is ordered Notation, Snippets, Usage, but the menu bar is ordered Notation, Snippets, Usage. All the rest are in order. Thanks for your great work! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
On Sun, Sep 27, 2009 at 10:15:30AM -0600, Carl Sorensen wrote: > > On 9/27/09 6:57 AM, "Graham Percival" wrote: > > > 1) Learning B. Scheme tutorial -- do we want to keep this here, or > > integrate into Learning 4? Or _possibly_ make a Learning 5 > > Programming inside LilyPond? > > I don't think we want to put this in the main body of the Learning Manual, > since we ask readers to read the LM cover to cover. I think that having it > as an appendix is the right thing to do. But I like the name Programming > inside LilyPond much better than Scheme tutorial. How much of scheme do we get into, though? I mean, what about moving it back into Notation? As far as I'm concerned, as long as newbies know that it's *possible* to do all sorts of funky stuff with this magical scheme stuff, that's all they need to know. I mean, nobody can seriously complain that we're newbie-unfriendly by not explaining how to make noteheads automatically change size based on their staff position! > > 2) Was there some reason why all the indices are called "LilyPond > > index"? I have a vaugue recollection that it worked better in the > > info format or something like that...? > > index.html is the default page for a website. Hence, we wanted LilyPond > index. Was that seriously the reason? I don't follow... I mean, the html filename is "LilyPond-index.html". > > 3) I'm not convinced about the order of material inside each > > chapter of Usage yet -- at the moment, I just want people to > > consider the division of stuff into chapters, not within each > > chapter. > > I think there should be at least a pointer to OooLilyPond in Usage 3.2., It's in Usage 3.6. IMO, Usage 3 is the worst chapter in our existing documentation, but I'm not getting into that until other projects are finished up. > I do have a minor nit to pick: on the Manuals page, the regular use section > is ordered > Notation, Snippets, Usage, > but the menu bar is ordered > Notation, Snippets, Usage. I see there was a similar thinko when you wrote that! The meaning got through, though; thanks, fixed. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit : > How much of scheme do we get into, though? I mean, what about > moving it back into Notation? This would be wrong: even if we expanded it up to make a big chapter, it would not become reference documentation (we alreadhy have Notation Ref. 6 "Interfaces for programmers" and the Internals Reference for this), it would remain learning material. > As far as I'm concerned, as long as newbies know that it's > *possible* to do all sorts of funky stuff with this magical scheme > stuff, that's all they need to know. I mean, nobody can seriously > complain that we're newbie-unfriendly by not explaining how to > make noteheads automatically change size based on their staff > position! Certainly. However, when we decide time has come to significantly expand this appendix and it gets too big to remain an appendix, we'll have to reword the reading guidelines so the reader doesn't feel he should even read this chapter, e.g. by recommending that "all this manual should be read from cover to cover, except the last chapter "Scheme tutorial", that can be read later to make better use of Chapters 5 and 6 of the Notation Reference, for example." > > index.html is the default page for a website. Hence, we wanted LilyPond > > index. > > Was that seriously the reason? I don't follow... I mean, the html > filename is "LilyPond-index.html". So, why do you criticize the name "LilyPond index"? The constraint is that we must have a node name other than "Index", otherwise the splitted HTML page name would clash with Top node HTML page index.html (not on Unix systems, but on Windows). Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
On Sun, Sep 27, 2009 at 07:55:32PM +0200, John Mandereau wrote: > Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit : > > As far as I'm concerned, as long as newbies know that it's > > *possible* to do all sorts of funky stuff with this magical scheme > > stuff, that's all they need to know. > Certainly. However, when we decide time has come to significantly > expand this appendix and it gets too big to remain an appendix, we'll > have to reword the reading guidelines so the reader doesn't feel he > should even read this chapter, I guess. We'd also need to reword the intro to Notation, since that "assumes the reader has read and understood the Learning manual". > > Was that seriously the reason? I don't follow... I mean, the html > > filename is "LilyPond-index.html". > > So, why do you criticize the name "LilyPond index"? The constraint is > that we must have a node name other than "Index", otherwise the splitted > HTML page name would clash with Top node HTML page index.html (not on > Unix systems, but on Windows). I'm wondering if we can call them "Function index" and "Concept index". Or something like that. It just seems weird to have a "LilyPond index" for every manual. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
Le dimanche 27 septembre 2009 à 13:57 +0100, Graham Percival a écrit : > What do people think about the doc reorg shown in: > http://kainhofer.com/~lilypond/Documentation/general/Manuals.html > (and the actual manual pages, of course) I think the frame "Read it now" is superfluous, a simple link "Read it now" at the beginning of the frame "MANUAL NAME" or assiging "MANUAL NAME" the URL of the manual should be enough (I prefer the former to make sure that the reader immediately sees it). A few files have been moved in English docs, could somebody do the same for translated docs? I'm asking just in case somebody may volunteer, otherwise I'll do this after October 5th and not before I get an Internet connection at home. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
Le dimanche 27 septembre 2009 à 19:08 +0100, Graham Percival a écrit : > I'm wondering if we can call them "Function index" and "Concept > index". Or something like that. It just seems weird to have a > "LilyPond index" for every manual. Maybe "Function and concept index", as this index actually merges concept index and function index? I'm not sure this is better than "LilyPond index". Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Why are book blocks objects but not contexts in Lilypond?
Hi, I'm looking at this in terms of design inconsistencies rather than documentation issues. I've been looking around at the code and documentation regarding contexts and noted these statements: LM 3.3.2 says "Note that there is no |\new Score| command; *the single top-level |Score| context is introduced with |\score|*." (My bolding) LM 3.1.1 says "*Every |\book| block creates a separate output file (e.g., a PDF file). If you haven’t explicitly added one, LilyPond wraps your entire input code in a |\book| block implicitly.* Every |\score| block is a separate chunk of music within a |\book| block. Every |\layout| block affects the |\score| or |\book| block in which it appears – i.e., a |\layout| block inside a |\score| block affects only that |\score| block, but a |\layout| block outside of a |\score| block (and thus in a |\book| block, either explicitly or implicitly) will affect every |\score| in that |\book|." (My bolding) So, is the top-level block in a lilypond input file implicitly a book or a score? Which is right, and do all places in the code make the correct assumption consistently? There are a couple of parser variables relevant to \book output-count and output-prefix (only output-prefix is still used as of 2.13.4). I reckon output-prefix and possibly then the filename part of the output filespec would be valid properties for \book. I also think Book would be a valid context for these to live in. However, at the moment contexts are designed to be part of the process of translating music source code into final format of some sort (e.g. .png, .pdf), and are associated with engravers and suchlike. The Book context would be concerned with whereabouts that output was headed. I had been thinking of adding all the parser variables as properties, but have since had a look at the original list Marl Polesky generated and have come to the conclusion parser variables seem to be a very mixed bag: for things which are supposed to be user-settable this seems to be because maybe the developer couldn't think of a place that fitted for them: afterGraceFraction should have been an optional parameter to the afterGrace function, and output-count and output-prefix should have had some way of being attached to the \book in the lilypond language; showFirstLength and showLastLength are associated with the skipTypeSetting property which LR 3.4.2 lists as a score property so show*Length should be in define-context-properties.scm where skipTypesetting is defined. The rest of the parser variables look like they are genuine internal things for use in Scheme code. So, if \book is really the top of the tree, and a lilypond file is either: * a series of \book blocks * a single \book block * an implicit \book block And each book block of whatever sort contains either: * a series of \score blocks * a single \score block * an undeclared, implicit \score block Places in the code assuming "a single top-level score context" will need fixing. I would like lilypond to have a Book context sitting above Score in the context hierarchy. How could I add Book as a valid context? I already understand how to add new properties to the lists in define-context-properties.scm. I haven't yet found out how \set, \unset, \override or \revert code decides which of the property lists like all-music-properties, all-translation-properties or all-backend-properties to search for a valid property definition. Thanks in advance for any help, tips, pointers or comments. Cheers, Ian Hulin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
context.hh and context-property.cc
Some, but not all of the functions declared in context-property.cc are declared as methods of the Context class in context.hh. Is this by design or is it an oversight? Declared in both are: apply_property_operations execute_revert_property execute_pushpop_property sloppy_general_pushpop_property updated_grob_properties Declared in context_property.cc only are: general_pushpop_property (which calls sloppy_general_pushpop_property) execute_override_property Should execute_override_property be a method, too? Cheers, Ian Hulin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: doc reorg (especially Usage) possibly finished
On 9/27/09 11:55 AM, "John Mandereau" wrote: > Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit : >> How much of scheme do we get into, though? I mean, what about >> moving it back into Notation? > > This would be wrong: even if we expanded it up to make a big chapter, it > would not become reference documentation (we alreadhy have Notation Ref. > 6 "Interfaces for programmers" and the Internals Reference for this), it > would remain learning material. > > >> As far as I'm concerned, as long as newbies know that it's >> *possible* to do all sorts of funky stuff with this magical scheme >> stuff, that's all they need to know. I mean, nobody can seriously >> complain that we're newbie-unfriendly by not explaining how to >> make noteheads automatically change size based on their staff >> position! > > Certainly. However, when we decide time has come to significantly > expand this appendix and it gets too big to remain an appendix, we'll > have to reword the reading guidelines so the reader doesn't feel he > should even read this chapter, e.g. by recommending that "all this > manual should be read from cover to cover, except the last chapter > "Scheme tutorial", that can be read later to make better use of Chapters > 5 and 6 of the Notation Reference, for example." I think that my preference would actually to create a LilyPond Programming manual, with the Scheme Tutorial and a rewritten NR6. I don't think that NR6 is actually Notation Reference. That particular chapter has seemed to me to be out of place anyway. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
