Re: Does \hspace need a vertical extent?
Neil Puttock gmail.com> writes: > > 2009/8/10 Thomas Morgan ziiuu.com>: > > > I'm not aware of this (though I don't doubt that you're right). > > Could you give me an example? > > See the attached image, which shows the change in output for the > regression test `chord-names-languages.ly'. > > It's not a particularly serious issue, but there are likely to be > other cases (uncovered by the regression tests) where the current > behaviour of \hspace is taken into consideration. > This patch has languished for a while because we thought it might mess up the current code. It looks to me like the only issue is that the vertical extent of the hspace pushed the staff down to avoid a non-existent collision. I think we should go ahead and push this patch (but if we need to wait for the new chord name code, I guess we can do so) Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-git: amending patches
On 12/31/09 8:27 PM, "Graham Percival" wrote: > On Thu, Dec 31, 2009 at 3:27 PM, Carl Sorensen wrote: >> >> I took an intermediate approach. The extra button isn't "un-commit", it's >> "wrap the current changes into the previous commit". There isn't as much >> flexibility as the "un-commit" button, but it should handle the hypothetical >> situation quite well. > > Ok. I'm happy with the described functionality (sorry, ran out time > to test it), but not the UI -- we don't want users to do 1. 2. 3. 4. > under the current UI. > > I toyed with having 1. 2a 2b 3. but it wasn't working for me. I also > briefly tried having a frame around 2a 2b, but couldn't figure out the > tcl/tk commands in the time I allotted myself. I pushed a version that stacks 2a and 2b vertically, so we go 2a 1 3 Abort 2b I think I like it better. It would be easy to stretch 1 3 and Abort vertically so they all took the same space if that were preferred. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-git: amending patches
On Thu, Dec 31, 2009 at 3:27 PM, Carl Sorensen wrote: > > I took an intermediate approach. The extra button isn't "un-commit", it's > "wrap the current changes into the previous commit". There isn't as much > flexibility as the "un-commit" button, but it should handle the hypothetical > situation quite well. Ok. I'm happy with the described functionality (sorry, ran out time to test it), but not the UI -- we don't want users to do 1. 2. 3. 4. under the current UI. I toyed with having 1. 2a 2b 3. but it wasn't working for me. I also briefly tried having a frame around 2a 2b, but couldn't figure out the tcl/tk commands in the time I allotted myself. Another possibility is to have the "amend" button on the right (although not red). That way, it's clear that it's a special button that you should only use with your mentor's supervision, but it's not hard to find. I ended up pushing this version, but I'm open to other suggestions or more UI tweaks. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH]: Parenthesize markup
Thomas Morgan submitted this patch last July as part of his chord-name work. http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/22784 It got the provisional OK but never got resubmitted as a single patch, instead of a series of patches. We're trying to get the chord-name code finished off. Please review this patch on Rietveld: http://codereview.appspot.com/183101 Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.10 pre-release testing
On Thu, Dec 31, 2009 at 6:18 PM, Graham Percival wrote: > The recent problem with end-of-line in mingw is (believed to be) > fixed; please test the new version here: > http://lilypond.org/~graham/ > > Also, I'm still waiting to hear if it still works on darwin (any > architecture, any OS version; just make sure you can still generate > any output). The line-ending issue is fixed here on Wine, and everything else seems normal. I can't test the darwin versions until (at least) Saturday, so hopefully someone else can. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.10 pre-release testing
The recent problem with end-of-line in mingw is (believed to be) fixed; please test the new version here: http://lilypond.org/~graham/ Also, I'm still waiting to hear if it still works on darwin (any architecture, any OS version; just make sure you can still generate any output). Cheers, - Graham On Thu, Dec 31, 2009 at 10:29 AM, Trevor Daniels wrote: > Hi Graham > > With Vista Home Premium and 2.13.10-1.mingw.exe: > > Downloaded - OK > Installed - OK > Lilypad - 2 issues > I don't run with administrator privileges > so can't save to /Public/Desktop. Saved in > my 'home' folder. Then OK, except that pdf > does not display the url (Never looked for > this before, so may be an old issue.) > convert-ly - OK, except > Happened to try a file with \version "2.10" > This causes a python index error. > lilypond-book - OK > (on notation/pitches.itely) > LilyPond itself - OK > (on all snippets in notation/pitches.itely) > > Trevor > > - Original Message - From: "Graham Percival" > > To: "Lily devel" > Sent: Thursday, December 31, 2009 8:15 AM > Subject: 2.13.10 pre-release testing > > >> Yet more architectural changes to GUB, so I thought it'd be worth >> hearing if it works. lilypad should be included automatically now. >> >> http://lilypond.org/~graham/ >> >> Cheers, >> - Graham >> >> >> ___ >> lilypond-devel mailing list >> lilypond-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/lilypond-devel >> >> > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with tablature angle brackets
On Thu, Dec 31, 2009 at 7:35 AM, Werner LEMBERG wrote: > >> Would it be a good idea to *draw* these angle brackets instead of >> using glyphs from a font? > > Yes. The angle brackets in TeX Gyre Schola (which will eventually > become part of the LilyPond distribution and replace the New Century > Schoolbook fonts) are not too nice IMHO. I agree. Also, TeX Gyre Schola does not have U+27E8 or U+27E9, which are the non-deprecated Unicode angle brackets. I will look into reworking the stencils for the tablature angle brackets. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: StaffGrouper vs. VerticalAxisGroup: syntax inconsistencies
>> why can I say
>>
>> \new PianoStaff \with {
>> \override StaffGrouper
>> #'between-staff-spacing #'minimum-distance = #20
>> } ...
>>
>> but not
>>
>> \new Staff \with {
>> \override VerticalAxisGroup
>> #'next-staff-spacing #'minimum-distance = #20
>> } ...
>
> Because next-staff-spacing defaults to a callback rather than to an
> alist. IWBN if one could use the nested property syntax for
> overriding callbacks but it isn't quite trivial to implement, as far
> as I can see.
OK. A comment in the docs would be quite helpful then.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with tablature angle brackets
> Would it be a good idea to *draw* these angle brackets instead of > using glyphs from a font? Yes. The angle brackets in TeX Gyre Schola (which will eventually become part of the LilyPond distribution and replace the New Century Schoolbook fonts) are not too nice IMHO. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problems with tablature angle brackets
>> Would it be a good idea to *draw* these angle brackets instead of >> using glyphs from a font? I'm thinking that there would be fewer >> problems that way. > > Or maybe we could add a set of angle brackets to the Emmentaler > font, and use those instead? I can imagine that we want to have angle brackets which differ in hight but still have the same width... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/31/09 12:44 PM, "Han-Wen Nienhuys" wrote: > On Thu, Dec 31, 2009 at 2:33 PM, Carl Sorensen wrote: That's actually what the current mechanism is. It uses a special music function, and I can work within the current limitations. However, David was objecting to the special case that timeSignatureSettings would have as a revertable context property. So I was trying to come up with a method that would not use it as a special case. >>> >>> Right - but it is worth noting that we removed the revertable property >>> for the autobeam settings, exactly to not have the hack of doind >>> \revert/\override on something that is not a grob. >> >> I'm not sure exactly what you mean by this. > > if you do > > \override Stem #'direction = #1 > > we actually check the type associated with #'direction for grobs, so > we can warn when people do > > \override Stem #'direction = #'blah > > or > > \override Stem #21 = #1 > > the code has (or had) some contortions to switch this off for the auto > beam property case. Oh, yes. There may still be a comment about it, but the hack has been removed. Instead, we're using special beam-setting code, and we don't do \revert and \override. We use a music function (as you suggested we should). And since it's part of a special case anyway, then using special beam-setting code doesn't seem to me to be a problem. > > >>> \set timeSigFraction = .. >>> \set measureGrouping = .. >>> #(set-auto-beaming .. ) >> >> Hmm -- I plan to do that. But I need to have per-Voice beaming rules, so I >> think the rules need to be a context property. > > The argument could be a symbol though, > > #(set-auto-beaming 'timesig-3-4) > > so the beaming can still be set per voice. Hmm... not sure. > >> And IIUC, the time signature properties are part of the Timing context, not >> a Voice context. > > yes, I left out the context out of laziness. > >>> then you can be as flexible as you want. Are these settings >>> intrinsically part of the music or part of the translation process? >> >> The time signature is part of the music. The autobeaming is part of the >> translation process, I think. >> >> Do you think it's wrong to have the autobeam settings stored per context and >> indexed by the time signature? If that's a bad decision, I'd like to get >> that straightened out before I finish implementing the code. > > No that sounds fine, but the time signature settings themselves (ie. > whether 6/8 = 3+3 or 2+2+2) should not be part of the context > properties. But each staff can have a separate time signature by moving the Timing_egraver to the staff context, and we show examples of that, so to make that work, the time signature settings need to be part of a context propery, I think. Is there something wrong with having them do that? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On Thu, Dec 31, 2009 at 2:33 PM, Carl Sorensen wrote: >>> That's actually what the current mechanism is. It uses a special music >>> function, and I can work within the current limitations. >>> >>> However, David was objecting to the special case that timeSignatureSettings >>> would have as a revertable context property. So I was trying to come up >>> with a method that would not use it as a special case. >> >> Right - but it is worth noting that we removed the revertable property >> for the autobeam settings, exactly to not have the hack of doind >> \revert/\override on something that is not a grob. > > I'm not sure exactly what you mean by this. if you do \override Stem #'direction = #1 we actually check the type associated with #'direction for grobs, so we can warn when people do \override Stem #'direction = #'blah or \override Stem #21 = #1 the code has (or had) some contortions to switch this off for the auto beam property case. >> \set timeSigFraction = .. >> \set measureGrouping = .. >> #(set-auto-beaming .. ) > > Hmm -- I plan to do that. But I need to have per-Voice beaming rules, so I > think the rules need to be a context property. The argument could be a symbol though, #(set-auto-beaming 'timesig-3-4) so the beaming can still be set per voice. Hmm... not sure. > And IIUC, the time signature properties are part of the Timing context, not > a Voice context. yes, I left out the context out of laziness. >> then you can be as flexible as you want. Are these settings >> intrinsically part of the music or part of the translation process? > > The time signature is part of the music. The autobeaming is part of the > translation process, I think. > > Do you think it's wrong to have the autobeam settings stored per context and > indexed by the time signature? If that's a bad decision, I'd like to get > that straightened out before I finish implementing the code. No that sounds fine, but the time signature settings themselves (ie. whether 6/8 = 3+3 or 2+2+2) should not be part of the context properties. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Han-Wen Nienhuys writes: > On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman wrote: > >>> > If you were to use a context property, why would you need the >>> > special command \overrideTimeSignatureSettings to change it? That >>> > is, why couldn't people just use \set? If it helps, we could >>> > extend \set to allow nested properties (the same thing that >>> > http://codereview.appspot.com/182042/show does for paper-block >>> > variables). >>> >>> Because I want to be able to \revert, not just \unset. I want to be >>> able to change to some custom behavior, then go back to the default >>> behavior without having to know what the default behavior is in >>> detail. >>> >>> IIUC, \override is roughly equivalent to \set value (cons new-value >>> old-value). I want to have that functionality, so that old-value is >>> still available for a \revert. >>> >>> But certainly nested properties would help in making this change. >>> >>> Why have we decided that context properties can only be \set, and >>> grob properties can only be \overridden? In version 2.0 we had two >>> kinds of properties, layout properties and translation >>> properties. I think that translation properties in those days are >>> what we now call context properties, and that what were then called >>> layout properties are now called grob properties. Also, in version >>> 2.0 we could either \set (destructively assign a value) or \override >>> (push a value on the stack). In fact, according to the >>> documentation, \override and \revert were the equivalent of push and >>> pop. > > This is a misconception, and the change in syntax was made to stop > this misconception from breeding. It didn't succeed. I think that in this case it would make more sense to better match the behavior to the misconception than the other way round. Because understanding the misconception requires technical expertise on the level required for _changing_ the behavior, and that is a scarce resource. If yielding to this misconception needs two different _implementations_ of the setting commands depending on whether they are used in contexts or grobs that is a smaller price to pay than requiring two different user level _explanations_. If you can save yourself the trouble of making your _users_ smarter by instead making the _code_ smarter, that is well-invested time. Because user stupidity is diversified and unreliable, whereas code needs to be fixed just once. > Of course, the \set \unset model falls apart for autoBeaming > properties, which is exactly why have (had; do we still have it?) the > hack that messes around with layout properties of a non-existent grob > to store auto-beaming properties. I don't think having nice syntax > for auto-beam settings is worth the effort and confusion of an > implementation of stack-like behavior for normal properties. But the confusion _is_ there. The documentation cannot really hope to clear it up because there is no reason accessible from user-level for it. > We used to have a single namespace for properties, eg. > > \property stemVerticalDirection = #UP > > beyond hard to maintain the zillion properties, each override would be > stored individually in every grob, taking an acons (16 bytes) per > grob, per formatting property, which made Peter's machine start > trashing > > git diff release/1.3.80..release/1.3.81 So now instead of Peter's _machine_ thrashing while typesetting music, we have Paul, George and Mary (and likely Peter as well) thrashing while trying to understand the documentation. That's not a good deal. Especially because implementing grob and context properties differently does not necessitate giving them a different user interface. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/31/09 8:56 AM, "Han-Wen Nienhuys" wrote: > On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen wrote: > > Why have we decided that context properties can only be \set, and grob > properties can only be \overridden? In version 2.0 we had two kinds of > properties, layout properties and translation properties. I think that > translation properties in those days are what we now call context > properties, and that what were then called layout properties are now > called > grob properties. Also, in version 2.0 we could either \set (destructively > assign a value) or \override (push a value on the stack). In fact, > according to the documentation, \override and \revert were the equivalent > of > push and pop. >>> >>> This is a misconception, and the change in syntax was made to stop >>> this misconception from breeding. There never was a stack-like >>> behavior for context/translation properties. The suggested mechanism >>> for this instead was to have the default be at a higher level context >>> (eg. Score), and doing \unset at a lower level (eg. Staff) to restore >>> the default. >> >> OK. When I was using 2.0 I didn't understand the internals well enough to >> appreciate these nuances. But when I read the docs yesterday, they implied >> that /override and /revert applied to translation properties. > > Well, the nuance is that \override do not strictly manipulate grob > properties (ie. per grob settings), but the alist containing the > defaults, and the alist is stored in a context property, so in a way > it applies to a context property. > > > \unset is actually important for internally-used context properties. So we would have to _add_ a revert function instead of just changing the behaviour of \unset. >>> >>> I think you are going at the problem from the wrong angle. Are there >>> other cases that need this new behavior? (I suspect not). If not, >>> you should not implement something generic, but work on a more >>> palatable syntax for what we currently have through music functions or >>> some other existing extension mechanism. >>> >> >> That's actually what the current mechanism is. It uses a special music >> function, and I can work within the current limitations. >> >> However, David was objecting to the special case that timeSignatureSettings >> would have as a revertable context property. So I was trying to come up >> with a method that would not use it as a special case. > > Right - but it is worth noting that we removed the revertable property > for the autobeam settings, exactly to not have the hack of doind > \revert/\override on something that is not a grob. I'm not sure exactly what you mean by this. > > BTW, IIRC, we still have some special-case code for the hack to switch > off type-checking on the nested properties for the beam settings. > >> Your feedback (which I'm happy to accept) is to go ahead and use it as a >> special case. So I will. And if we need to use it for another property in >> the future, then I guess we can turn the special case into a general case. >> >> Thanks for your feedback. I'll proceed with the special case, and put some >> comments in the code indicating why we do it. > > Looking back through the thread, I am wondering why you do not expand > these settings at the parsing stage, ie. have \time 2/4 expand to > > \set timeSigFraction = .. > \set measureGrouping = .. > #(set-auto-beaming .. ) Hmm -- I plan to do that. But I need to have per-Voice beaming rules, so I think the rules need to be a context property. And IIUC, the time signature properties are part of the Timing context, not a Voice context. > > then you can be as flexible as you want. Are these settings > intrinsically part of the music or part of the translation process? The time signature is part of the music. The autobeaming is part of the translation process, I think. Do you think it's wrong to have the autobeam settings stored per context and indexed by the time signature? If that's a bad decision, I'd like to get that straightened out before I finish implementing the code. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On Thu, Dec 31, 2009 at 1:43 PM, Carl Sorensen wrote: Why have we decided that context properties can only be \set, and grob properties can only be \overridden? In version 2.0 we had two kinds of properties, layout properties and translation properties. I think that translation properties in those days are what we now call context properties, and that what were then called layout properties are now called grob properties. Also, in version 2.0 we could either \set (destructively assign a value) or \override (push a value on the stack). In fact, according to the documentation, \override and \revert were the equivalent of push and pop. >> >> This is a misconception, and the change in syntax was made to stop >> this misconception from breeding. There never was a stack-like >> behavior for context/translation properties. The suggested mechanism >> for this instead was to have the default be at a higher level context >> (eg. Score), and doing \unset at a lower level (eg. Staff) to restore >> the default. > > OK. When I was using 2.0 I didn't understand the internals well enough to > appreciate these nuances. But when I read the docs yesterday, they implied > that /override and /revert applied to translation properties. Well, the nuance is that \override do not strictly manipulate grob properties (ie. per grob settings), but the alist containing the defaults, and the alist is stored in a context property, so in a way it applies to a context property. >>> \unset is actually important for internally-used context properties. So >>> we would have to _add_ a revert function instead of just changing the >>> behaviour of \unset. >> >> I think you are going at the problem from the wrong angle. Are there >> other cases that need this new behavior? (I suspect not). If not, >> you should not implement something generic, but work on a more >> palatable syntax for what we currently have through music functions or >> some other existing extension mechanism. >> > > That's actually what the current mechanism is. It uses a special music > function, and I can work within the current limitations. > > However, David was objecting to the special case that timeSignatureSettings > would have as a revertable context property. So I was trying to come up > with a method that would not use it as a special case. Right - but it is worth noting that we removed the revertable property for the autobeam settings, exactly to not have the hack of doind \revert/\override on something that is not a grob. BTW, IIRC, we still have some special-case code for the hack to switch off type-checking on the nested properties for the beam settings. > Your feedback (which I'm happy to accept) is to go ahead and use it as a > special case. So I will. And if we need to use it for another property in > the future, then I guess we can turn the special case into a general case. > > Thanks for your feedback. I'll proceed with the special case, and put some > comments in the code indicating why we do it. Looking back through the thread, I am wondering why you do not expand these settings at the parsing stage, ie. have \time 2/4 expand to \set timeSigFraction = .. \set measureGrouping = .. #(set-auto-beaming .. ) then you can be as flexible as you want. Are these settings intrinsically part of the music or part of the translation process? -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/31/09 8:27 AM, "Han-Wen Nienhuys" wrote: > On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman wrote: > If you were to use a context property, why would you need the special command \overrideTimeSignatureSettings to change it? That is, why couldn't people just use \set? If it helps, we could extend \set to allow nested properties (the same thing that http://codereview.appspot.com/182042/show does for paper-block variables). >>> >>> Because I want to be able to \revert, not just \unset. I want to be able to >>> change to some custom behavior, then go back to the default behavior without >>> having to know what the default behavior is in detail. >>> >>> IIUC, \override is roughly equivalent to \set value (cons new-value >>> old-value). I want to have that functionality, so that old-value is still >>> available for a \revert. >>> >>> But certainly nested properties would help in making this change. >>> >>> Why have we decided that context properties can only be \set, and grob >>> properties can only be \overridden? In version 2.0 we had two kinds of >>> properties, layout properties and translation properties. I think that >>> translation properties in those days are what we now call context >>> properties, and that what were then called layout properties are now called >>> grob properties. Also, in version 2.0 we could either \set (destructively >>> assign a value) or \override (push a value on the stack). In fact, >>> according to the documentation, \override and \revert were the equivalent of >>> push and pop. > > This is a misconception, and the change in syntax was made to stop > this misconception from breeding. There never was a stack-like > behavior for context/translation properties. The suggested mechanism > for this instead was to have the default be at a higher level context > (eg. Score), and doing \unset at a lower level (eg. Staff) to restore > the default. OK. When I was using 2.0 I didn't understand the internals well enough to appreciate these nuances. But when I read the docs yesterday, they implied that /override and /revert applied to translation properties. > > Of course, the \set \unset model falls apart for autoBeaming > properties, which is exactly why have (had; do we still have it?) the > hack that messes around with layout properties of a non-existent grob > to store auto-beaming properties. I don't think having nice syntax > for auto-beam settings is worth the effort and confusion of an > implementation of stack-like behavior for normal properties. No, we don't have that hack. That hack was eliminated in favor of a music function to reset things. > > As a historical note: the stack model for grob properties started as a > hack to make LilyPond usable on a poor musician's (no money to buy > RAM) machine - > > http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03897.html > http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03854.html > http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03937.html > > We used to have a single namespace for properties, eg. > > \property stemVerticalDirection = #UP > > beyond hard to maintain the zillion properties, each override would be > stored individually in every grob, taking an acons (16 bytes) per > grob, per formatting property, which made Peter's machine start > trashing > > git diff release/1.3.80..release/1.3.81 > > shows the feature in all its endearing simplicity and naivity. > >> \unset is actually important for internally-used context properties. So >> we would have to _add_ a revert function instead of just changing the >> behaviour of \unset. > > I think you are going at the problem from the wrong angle. Are there > other cases that need this new behavior? (I suspect not). If not, > you should not implement something generic, but work on a more > palatable syntax for what we currently have through music functions or > some other existing extension mechanism. > That's actually what the current mechanism is. It uses a special music function, and I can work within the current limitations. However, David was objecting to the special case that timeSignatureSettings would have as a revertable context property. So I was trying to come up with a method that would not use it as a special case. Your feedback (which I'm happy to accept) is to go ahead and use it as a special case. So I will. And if we need to use it for another property in the future, then I guess we can turn the special case into a general case. Thanks for your feedback. I'll proceed with the special case, and put some comments in the code indicating why we do it. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lily-git: amending patches
On 12/31/09 12:46 AM, "Graham Percival" wrote: > We either need one more button for lily-git, or one less. > > Taking a completely hypthetical example, suppose a new doc > contributors writes a nice addition for the docs, but only uses one > space after a period (the heretic!). I ask for an updated patch. Our > fearless contributor edits the file accordingly, then presses "2. > local commit" and "3. generate patches" (or whatever the buttons > are). I previously had an "Amend previous commit" button, but took it out because it called the editor (and we don't want that happening). I now found the proper git command to use to make the Amend button work, so I've added it. > > He now has two patches; one of which is just fixing the mistakes in > the previous one. > > > I see two possibilities: > - "one less button": eliminate the "2. local commit"; just make button > 3 produce a patch including _any_ difference between the source tree > and origin. I don't like this idea; I think that creating a patch should be a separate step. > - "one more button": add a button for "un-commit", which takes the > patch out of the git history, but leaves the files modified. The > contributor can then edit the file and do a "local commit" like > normal. > This would require a prompt for which local commit to un-commit. I > think we can assume that contributors can recognize the correct patch > to un-commit; they'll generally only have one or two. And if they > *do* get confused, it'll be a good lesson to write better changelog > message. :) I took an intermediate approach. The extra button isn't "un-commit", it's "wrap the current changes into the previous commit". There isn't as much flexibility as the "un-commit" button, but it should handle the hypothetical situation quite well. User sends a patch. You send back "Make a couple of changes." User makes the changes, then clicks "Amend previous commit", followed by "Make patch". And now there is just one patch to be applied. I think this works. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman wrote: >> > If you were to use a context property, why would you need the special >> > command \overrideTimeSignatureSettings to change it? That is, why >> > couldn't people just use \set? If it helps, we could extend \set to >> > allow nested properties (the same thing that >> > http://codereview.appspot.com/182042/show does for paper-block >> > variables). >> >> Because I want to be able to \revert, not just \unset. I want to be able to >> change to some custom behavior, then go back to the default behavior without >> having to know what the default behavior is in detail. >> >> IIUC, \override is roughly equivalent to \set value (cons new-value >> old-value). I want to have that functionality, so that old-value is still >> available for a \revert. >> >> But certainly nested properties would help in making this change. >> >> Why have we decided that context properties can only be \set, and grob >> properties can only be \overridden? In version 2.0 we had two kinds of >> properties, layout properties and translation properties. I think that >> translation properties in those days are what we now call context >> properties, and that what were then called layout properties are now called >> grob properties. Also, in version 2.0 we could either \set (destructively >> assign a value) or \override (push a value on the stack). In fact, >> according to the documentation, \override and \revert were the equivalent of >> push and pop. This is a misconception, and the change in syntax was made to stop this misconception from breeding. There never was a stack-like behavior for context/translation properties. The suggested mechanism for this instead was to have the default be at a higher level context (eg. Score), and doing \unset at a lower level (eg. Staff) to restore the default. Of course, the \set \unset model falls apart for autoBeaming properties, which is exactly why have (had; do we still have it?) the hack that messes around with layout properties of a non-existent grob to store auto-beaming properties. I don't think having nice syntax for auto-beam settings is worth the effort and confusion of an implementation of stack-like behavior for normal properties. As a historical note: the stack model for grob properties started as a hack to make LilyPond usable on a poor musician's (no money to buy RAM) machine - http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03897.html http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03854.html http://www.mail-archive.com/gnu-music-disc...@gnu.org/msg03937.html We used to have a single namespace for properties, eg. \property stemVerticalDirection = #UP beyond hard to maintain the zillion properties, each override would be stored individually in every grob, taking an acons (16 bytes) per grob, per formatting property, which made Peter's machine start trashing git diff release/1.3.80..release/1.3.81 shows the feature in all its endearing simplicity and naivity. > \unset is actually important for internally-used context properties. So > we would have to _add_ a revert function instead of just changing the > behaviour of \unset. I think you are going at the problem from the wrong angle. Are there other cases that need this new behavior? (I suspect not). If not, you should not implement something generic, but work on a more palatable syntax for what we currently have through music functions or some other existing extension mechanism. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
On 12/31/09 7:45 AM, "Marc Hohl" wrote: > Carl Sorensen schrieb: >> >> On 12/31/09 6:37 AM, "Marc Hohl" wrote: >> >> >>> Carl Sorensen schrieb: >>> On 12/30/09 7:42 AM, "Marc Hohl" wrote: > Carl Sorensen schrieb: > > OK, I've attached a 300 dpi png and with the clef rotated from 0 to 4 degrees. >>> Thanks for your work, Carl. >>> An Inkscape svg is available at http://www.et.byu.edu/~sorensen/cleftest.svg >>> OT: This is strange; in the browser, it looks ok, but with inkscape, the >>> staff lines are missing. >>> >> >> What version of inkscape are you using? Older versions didn't handle >> default colors according to the specification. I opened the file in my >> browser, and saved it, then opened it in inkscape, and everything was fine. >> > inkscape V 0.46. I did it via saving directly from your link, > and via saving through the browser, with identical results. I'm using 0.46-devel. >> >> Your opinions exactly match mine -- 1.5 or 2.0 with a slight shift of the >> bulb. But I think I prefer 1.5. >> > Ok, so I'll go for this. It isn't as easy as I thought, because I cannot > just rotate the whole picture, because the path is too complex for metafont. > So I'll have to transform every point and draw thereafter. It seems to > work, but > I have to change some explicit drawing angles accordingly and bring it into > a less hackish form - but I think this will come next year ;-) Well, I'm putting most of my work off to next year, too. > > Best wishes! > And to you! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
Carl Sorensen schrieb: On 12/31/09 6:37 AM, "Marc Hohl" wrote: Carl Sorensen schrieb: On 12/30/09 7:42 AM, "Marc Hohl" wrote: Carl Sorensen schrieb: OK, I've attached a 300 dpi png and with the clef rotated from 0 to 4 degrees. Thanks for your work, Carl. An Inkscape svg is available at http://www.et.byu.edu/~sorensen/cleftest.svg OT: This is strange; in the browser, it looks ok, but with inkscape, the staff lines are missing. What version of inkscape are you using? Older versions didn't handle default colors according to the specification. I opened the file in my browser, and saved it, then opened it in inkscape, and everything was fine. inkscape V 0.46. I did it via saving directly from your link, and via saving through the browser, with identical results. But that's not important, because: A 600-dpi png is available at http://www.et.byu.edu/~sorensen/cleftest.png I printed this and stared at the clefs for quite a long time. I am not sure to use the 1.5 version as it is, or the 2.0 version with a tiny shift of the bulb to the right. But I tend to claim 1.5 being the best. Your opinions exactly match mine -- 1.5 or 2.0 with a slight shift of the bulb. But I think I prefer 1.5. Ok, so I'll go for this. It isn't as easy as I thought, because I cannot just rotate the whole picture, because the path is too complex for metafont. So I'll have to transform every point and draw thereafter. It seems to work, but I have to change some explicit drawing angles accordingly and bring it into a less hackish form - but I think this will come next year ;-) Best wishes! Marc Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
Carl Sorensen writes: > On 12/31/09 5:18 AM, "Joe Neeman" wrote: > >> I don't know the reason; I don't think I was even using LilyPond back >> in the 2.0 days. But it does sound perfectly reasonable to have >> context (or translation, if you prefer) properties that can be >> overridden and reverted. I can have a look at adding this (if you >> wouldn't rather have a go yourself). > > I'd love for you to have a look at it. But be sure to get Han-Wen's > approval. AFAICS, it was Han-Wen's decision to make the change, for > the two reasons I listed earlier. And this would be undoing part of > the change. Yes it would. We have had some previous discussion here, and the current interface decision has not been explained satisfactorily in my opinion. We have for properties: context: \set, \unset grob: \override, \revert There is nothing about the verbs "set" and "unset" which connects them semantically with "context", and nothing about "override" and "revert" which semantically connects them with "grob". _If_ the distinction were important and inherently connected with contexts and/or grobs, we should need context: \contextset, \contextunset grob: \grobset, \grobunset This would make more sense to the user. But \override and \revert also have useful (and different) semantics and had them even before the context/grob split was introduced. So having \contextoverride and the like would be nice. I think it is reasonable (and Scheme-like) _not_ to have different namespaces for contexts and grob, so that just \set, \unset, \revert, \override do the trick for all. But at least in _most_ cases context and grob should be distinguishable by name, and even if we permit overloading, one could have accessors called \set.context \set.grob and so on for that purpose. The current distinction may or may not be done because of technical details, but those details are not accessable to the average Lilypond user. I mean, I tried milking Han-Wen for the underlying reason and, while getting a lot of information and causing a lot of aggravation and work for him, I did not get anything out which would have made good sense to me. I may just be too stupid, but I doubt that the majority of Lilypond users is much smarter in this particular aspect, and so it might be an easier course to _abolish_ this difference again rather than _document_ it well enough so that even I and my ilk get it and feel confident navigating Lilypond files based on that distinction. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On 12/31/09 5:18 AM, "Joe Neeman" wrote: > On Tue, 2009-12-29 at 15:48 -0700, Carl Sorensen wrote: >> On 12/29/09 2:14 PM, "Joe Neeman" wrote: >>> I much prefer leaving it as a context property. Grob properties of the >>> TimeSignature grob should be things that affect the appearance of the >>> TimeSignature grob, not the creation of beams. >>> >>> If you were to use a context property, why would you need the special >>> command \overrideTimeSignatureSettings to change it? That is, why >>> couldn't people just use \set? If it helps, we could extend \set to >>> allow nested properties (the same thing that >>> http://codereview.appspot.com/182042/show does for paper-block >>> variables). >> >> Because I want to be able to \revert, not just \unset. I want to be able to >> change to some custom behavior, then go back to the default behavior without >> having to know what the default behavior is in detail. >> >> IIUC, \override is roughly equivalent to \set value (cons new-value >> old-value). I want to have that functionality, so that old-value is still >> available for a \revert. >> >> But certainly nested properties would help in making this change. >> >> Why have we decided that context properties can only be \set, and grob >> properties can only be \overridden? In version 2.0 we had two kinds of >> properties, layout properties and translation properties. I think that >> translation properties in those days are what we now call context >> properties, and that what were then called layout properties are now called >> grob properties. Also, in version 2.0 we could either \set (destructively >> assign a value) or \override (push a value on the stack). In fact, >> according to the documentation, \override and \revert were the equivalent of >> push and pop. > > I don't know the reason; I don't think I was even using LilyPond back in > the 2.0 days. But it does sound perfectly reasonable to have context > (or translation, if you prefer) properties that can be overridden and > reverted. I can have a look at adding this (if you wouldn't rather have > a go yourself). I'd love for you to have a look at it. But be sure to get Han-Wen's approval. AFAICS, it was Han-Wen's decision to make the change, for the two reasons I listed earlier. And this would be undoing part of the change. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
On 12/31/09 6:37 AM, "Marc Hohl" wrote: > Carl Sorensen schrieb: >> >> On 12/30/09 7:42 AM, "Marc Hohl" wrote: >> >> >>> Carl Sorensen schrieb: >>> >> >> OK, I've attached a 300 dpi png and with the clef rotated from 0 to 4 >> degrees. >> > Thanks for your work, Carl. >> An Inkscape svg is available at >> >> http://www.et.byu.edu/~sorensen/cleftest.svg >> > OT: This is strange; in the browser, it looks ok, but with inkscape, the > staff lines are missing. What version of inkscape are you using? Older versions didn't handle default colors according to the specification. I opened the file in my browser, and saved it, then opened it in inkscape, and everything was fine. > But that's not important, because: >> A 600-dpi png is available at >> >> http://www.et.byu.edu/~sorensen/cleftest.png >> > I printed this and stared at the clefs for quite a long time. I am not > sure to use the > 1.5 version as it is, or the 2.0 version with a tiny shift of the bulb > to the right. > But I tend to claim 1.5 being the best. Your opinions exactly match mine -- 1.5 or 2.0 with a slight shift of the bulb. But I think I prefer 1.5. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: G clef changes [was: Re: Alternative music font]
Carl Sorensen schrieb: On 12/30/09 7:42 AM, "Marc Hohl" wrote: Carl Sorensen schrieb: On 12/30/09 6:06 AM, "Marc Hohl" wrote: @Carl: I am not at all familiar with SVG. Could you please produce a file similar to the one you sent already with different rotating angles? I can only produce a file like that with the clefs you have designed if you generate svg output instead of (or in addition to) the pdf output. Use lilypond -fsvg myfile.ly in order to generate svg output (see Command line options for lilypond in section 1.2 of Usage). Oh, sorry, I wasn't clear enough. I meant you to create this file with the original liypond clef. Then we can find the ideal rotating angle, and I'll implement that in metafont. OK, I've attached a 300 dpi png and with the clef rotated from 0 to 4 degrees. Thanks for your work, Carl. An Inkscape svg is available at http://www.et.byu.edu/~sorensen/cleftest.svg OT: This is strange; in the browser, it looks ok, but with inkscape, the staff lines are missing. But that's not important, because: A 600-dpi png is available at http://www.et.byu.edu/~sorensen/cleftest.png I printed this and stared at the clefs for quite a long time. I am not sure to use the 1.5 version as it is, or the 2.0 version with a tiny shift of the bulb to the right. But I tend to claim 1.5 being the best. I'll dive into the metafont sources to rotate the clef. Marc In reviewing these, I think a rotation of the whole clef by 1.5 degrees would look just about perfect. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Autobeaming
On Tue, 2009-12-29 at 15:48 -0700, Carl Sorensen wrote: > On 12/29/09 2:14 PM, "Joe Neeman" wrote: > > I much prefer leaving it as a context property. Grob properties of the > > TimeSignature grob should be things that affect the appearance of the > > TimeSignature grob, not the creation of beams. > > > > If you were to use a context property, why would you need the special > > command \overrideTimeSignatureSettings to change it? That is, why > > couldn't people just use \set? If it helps, we could extend \set to > > allow nested properties (the same thing that > > http://codereview.appspot.com/182042/show does for paper-block > > variables). > > Because I want to be able to \revert, not just \unset. I want to be able to > change to some custom behavior, then go back to the default behavior without > having to know what the default behavior is in detail. > > IIUC, \override is roughly equivalent to \set value (cons new-value > old-value). I want to have that functionality, so that old-value is still > available for a \revert. > > But certainly nested properties would help in making this change. > > Why have we decided that context properties can only be \set, and grob > properties can only be \overridden? In version 2.0 we had two kinds of > properties, layout properties and translation properties. I think that > translation properties in those days are what we now call context > properties, and that what were then called layout properties are now called > grob properties. Also, in version 2.0 we could either \set (destructively > assign a value) or \override (push a value on the stack). In fact, > according to the documentation, \override and \revert were the equivalent of > push and pop. I don't know the reason; I don't think I was even using LilyPond back in the 2.0 days. But it does sound perfectly reasonable to have context (or translation, if you prefer) properties that can be overridden and reverted. I can have a look at adding this (if you wouldn't rather have a go yourself). > If we could allow nested context properties, and get \set to do the > equivalent of \override, and \unset do the equivalent of \revert, then I'd > be all set to do TimeSignatureDefinitions as a context property. \unset is actually important for internally-used context properties. So we would have to _add_ a revert function instead of just changing the behaviour of \unset. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Re: 2.13.10 pre-release testing
Reinhold Kainhofer wrote Thursday, December 31, 2009 11:26 AM Am Donnerstag, 31. Dezember 2009 11:29:14 schrieb Trevor Daniels: convert-ly - OK, except Happened to try a file with \version "2.10" This causes a python index error. Ouch, convert-ly assumed that all version strings always consist of three entries... I've created a patch to really check for this and normalize the version to a three-entry tuple if the version has more/fewer levels: http://codereview.appspot.com/183097 Okay to apply? LGTM Checked and fixes issue here. Many thanks! Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.10 pre-release testing
Graham, you wrote Thursday, December 31, 2009 10:44 AM I'm not asking for a pile of release-related bugs here; I just want to know if the release process has any regressions against previous versions. I just checked all these issues against 2.13.9. All were faults in 2.13.9 too except for the missing url in the pdf from test.ly. That was displayed correctly in 2.13.9, but is missing in the pdf generated by 2.13.10. It seems to be due to a change in the way subtitle handles a newline in its string. An easy fix is to put the string in test.ly all on one line. This is probably adequate to get 2.13.10 out. I'll investigate further and file a bug report. Trevor On Thu, Dec 31, 2009 at 10:29 AM, Trevor Daniels wrote: Hi Graham With Vista Home Premium and 2.13.10-1.mingw.exe: Downloaded - OK Installed - OK Lilypad - 2 issues I don't run with administrator privileges so can't save to /Public/Desktop. Saved in my 'home' folder. Then OK, except that pdf does not display the url (Never looked for this before, so may be an old issue.) convert-ly - OK, except Happened to try a file with \version "2.10" This causes a python index error. lilypond-book - OK (on notation/pitches.itely) LilyPond itself - OK (on all snippets in notation/pitches.itely) Trevor - Original Message - From: "Graham Percival" To: "Lily devel" Sent: Thursday, December 31, 2009 8:15 AM Subject: 2.13.10 pre-release testing Yet more architectural changes to GUB, so I thought it'd be worth hearing if it works. lilypad should be included automatically now. http://lilypond.org/~graham/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Re: 2.13.10 pre-release testing
Am Donnerstag, 31. Dezember 2009 11:29:14 schrieb Trevor Daniels: > convert-ly - OK, except > Happened to try a file with \version "2.10" > This causes a python index error. Ouch, convert-ly assumed that all version strings always consist of three entries... I've created a patch to really check for this and normalize the version to a three-entry tuple if the version has more/fewer levels: http://codereview.appspot.com/183097 Okay to apply? 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.10 pre-release testing
Sorry, I'm a bit woozy from being up past my bedtime. Does the below translate to "no (definitely) new problems" ? I'm not asking for a pile of release-related bugs here; I just want to know if the release process has any regressions against previous versions. I'd kind-of like to get 2.13.10 out there, so that we have a definite "ok, clean out your builddir and rebuild from scratch" point, because otherwise things like "make check" won't be useful. (I think. if "make check" looks at regtests) Cheers, - Graham On Thu, Dec 31, 2009 at 10:29 AM, Trevor Daniels wrote: > Hi Graham > > With Vista Home Premium and 2.13.10-1.mingw.exe: > > Downloaded - OK > Installed - OK > Lilypad - 2 issues > I don't run with administrator privileges > so can't save to /Public/Desktop. Saved in > my 'home' folder. Then OK, except that pdf > does not display the url (Never looked for > this before, so may be an old issue.) > convert-ly - OK, except > Happened to try a file with \version "2.10" > This causes a python index error. > lilypond-book - OK > (on notation/pitches.itely) > LilyPond itself - OK > (on all snippets in notation/pitches.itely) > > Trevor > > - Original Message - From: "Graham Percival" > > To: "Lily devel" > Sent: Thursday, December 31, 2009 8:15 AM > Subject: 2.13.10 pre-release testing > > >> Yet more architectural changes to GUB, so I thought it'd be worth >> hearing if it works. lilypad should be included automatically now. >> >> http://lilypond.org/~graham/ >> >> Cheers, >> - Graham >> >> >> ___ >> lilypond-devel mailing list >> lilypond-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/lilypond-devel >> >> > > > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.10 pre-release testing
Hi Graham With Vista Home Premium and 2.13.10-1.mingw.exe: Downloaded - OK Installed - OK Lilypad - 2 issues I don't run with administrator privileges so can't save to /Public/Desktop. Saved in my 'home' folder. Then OK, except that pdf does not display the url (Never looked for this before, so may be an old issue.) convert-ly - OK, except Happened to try a file with \version "2.10" This causes a python index error. lilypond-book - OK (on notation/pitches.itely) LilyPond itself - OK (on all snippets in notation/pitches.itely) Trevor - Original Message - From: "Graham Percival" To: "Lily devel" Sent: Thursday, December 31, 2009 8:15 AM Subject: 2.13.10 pre-release testing Yet more architectural changes to GUB, so I thought it'd be worth hearing if it works. lilypad should be included automatically now. http://lilypond.org/~graham/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.13.10 pre-release testing
Yet more architectural changes to GUB, so I thought it'd be worth hearing if it works. lilypad should be included automatically now. http://lilypond.org/~graham/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
