Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)
L pretty GTM. It would look even better with a little manual adjustment first. http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm File scm/music-functions.scm (right): http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm#newcode673 scm/music-functions.scm:673: (make-music 'RestEvent 'duration (ly:music-property mus 'duration)) remove the double space, I think http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm#newcode973 scm/music-functions.scm:973: ))) Is it out of the question to move orphaned brackets to the previous line? http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm#newcode1470 scm/music-functions.scm:1470: (lambda (m) (eq? 'NoteEvent (ly:music-property m 'name))) Same question for bare (if and (list I'd be happy with 1 space in this case and 2 spaces when the function is not bare [as indent seems to do for all bare (function calls]. Don't know what emacs does though. http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a glyph for tied lyrics. (issue 4808074)
use separate binding for (/ word-space 2) Done. http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Comand token too long?
Reinhold Kainhofer: Am Sunday, 14. August 2011, 03:36:05 schrieb Karl Hammar: Works here: Doesn't work here on a German Kubuntu system: ... $ echo $LANG C $ echo $LANG de_AT.UTF-8 $ LANG=de_AT.UTF-8 $ echo 'z:/' | egrep '^(/|[A-z]:/)' egrep: Das Ende des angegebenen Intervalls ist nicht gültig $ echo 'z:/' | egrep '^(/|[A-Za-z]:/)' z:/ $ export LC_ALL=C $ echo 'z:/' | egrep '^(/|[A-z]:/)' z:/ $ So that means that this bug is due to collation order, and as you wrote yesterday the interval should be changed to A-Za-z. The egrep thing is there to detect if a filename is absolute, i.e. starting with / as in /usr/bin/true (unix style), or C:/ (or another device letter) as in C:/WINDOWS/SYSTEM32/FILE.DLL (Dos/Windows style). As written in man grep: To obtain the traditional interpretation of bracket expressions, you can use the C locale by setting the LC_ALL environment variable to the value C. we can go around this bug by setting LC_ALL to C. This bug is fixed in [1]: - echo $command_line_filename | $EGREP '^(/|[A-z]:/)' 6 \ + echo $command_line_filename | LC_ALL=C $EGREP '^(/|[A-Za-z]:/)' 6 \ We might go around the bug with the attaced patch (texi2dvi is called from texi2pdf), but I have not had time to test it. Regards, /Karl Hammar [1] http://ftp.gnu.org/gnu/texinfo/texi2dvi --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 diff --git a/make/doc-i18n-root-rules.make b/make/doc-i18n-root-rules.make index f510ded..83f2ee6 100644 --- a/make/doc-i18n-root-rules.make +++ b/make/doc-i18n-root-rules.make @@ -18,7 +18,7 @@ $(top-build-dir)/Documentation/$(outdir)/%.$(ISOLANG).html: $(outdir)/%.texi $(X $(top-build-dir)/Documentation/$(outdir)/%.$(ISOLANG).pdf: $(outdir)/%.texi cd $(outdir) \ - texi2pdf $(TEXI2PDF_FLAGS) $(TEXINFO_PAPERSIZE_OPTION) $*.texi \ + LC_ALL=C texi2pdf $(TEXI2PDF_FLAGS) $(TEXINFO_PAPERSIZE_OPTION) $*.texi \ mkdir -p $(dir $@) mv $*.pdf $@ $(outdir)/version.%: $(top-src-dir)/VERSION___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilydev remix iso - where
Hi Jonathan, you wrote Sunday, August 14, 2011 1:50 AM On Sat, Aug 13, 2011 at 5:53 PM, Trevor Daniels t.dani...@treda.co.uk wrote: The lilynet website still seems to be under construction. In particular the lilydev remix iso is not available from the link in the CG. (I guess this should be a critical bug under the proposed new classification scheme.) I'd actually like to obtain it, as I need to reinstall my ubuntu system and want to upgrade to it. Is it available anywhere else? I have it but it's 827MB. Do you have a server where I could upload it for you? Thanks. I have access to a server which should do the job. I'll email the access codes privately. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3833 - Release Date: 08/14/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds a glyph for tied lyrics. (issue 4808074)
Pushed as 8d148ea05fa4b34f8cc3407e112363d715b27ad8 Bertrand http://codereview.appspot.com/4808074/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: chaotic stems when querying direction property
On 14 August 2011 01:03, Ricardo Wurmus ricardo.wur...@gmail.com wrote: So ly:glob-property has side effects because of the stem callback? How can I make sure to get the final stem direction after all dependent properties were calculated? I want to replace a note head with a triangle, but there is a gap between note head a stem when the stem points upward. To correct this, I modify the stem-attachment property of the note head. This correction offset must be different when the stem points down. I'd override the default callback for stem-attachment. It should be safe to get the stem direction at this point since it's already been calculated and cached. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Texi2HTML: don't wrap p around the contents of table cells. (issue 4891044)
LGTM. http://codereview.appspot.com/4891044/diff/1/Documentation/lilypond-texi2html.init File Documentation/lilypond-texi2html.init (right): http://codereview.appspot.com/4891044/diff/1/Documentation/lilypond-texi2html.init#newcode2076 Documentation/lilypond-texi2html.init:2076: if (defined ($command_stack_at_begin-[0]) and $command_stack_at_begin-[0] eq 'multitable') whitespace http://codereview.appspot.com/4891044/diff/1/Documentation/lilypond-texi2html.init#newcode2080 Documentation/lilypond-texi2html.init:2080: whitespace http://codereview.appspot.com/4891044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
David Kastrup d...@gnu.org writes: I don't think that anything close to a sensible implementation can be significantly simpler or significantly more efficient. There are some things that may be nicer to do in C, and some shortcuts that may be taken. But as a functional sketch, this should more or less be what it takes. I don't think we can get this much cheaper. ;; Structure of source: a list exactly as long as the list reaching ;; from cache inclusively to tail exclusively, and associated 1:1 with ;; the respective list elements. Each element of source has the ;; following parts: ;; car - records whether this property was entered with \once or ;; not. ;; cdr - length of nested property path. After this many cdar ;; calls on the property alist, you reach the set value of ;; the nested property. All other content of the property ;; alist entry is taken from other alist entries. Well David, I should not want to let you implement this in the current form without any feedback from the developer list. When you try converting your approach into C code, you'll likely notice a few problems where performance might be suboptimal. The one thing to note is that fold-right is an inefficient function to use, and because of the guile implementation, greatly more so if you use it with more than a single list. It is still O(n), but with a factor of ugliness that warrants some polishing up, the simplest polish-up possibly just consisting in hard-coding the case for 2 lists instead of using general code. But that still results in complex code and a recursion filling up the stack before actually starting any work working the stack down to empty again. So let us see what you are using fold-right for. Its main purpose appears to be for updating a context's personal part of the property list in reverse, back to front. And it is only in this context that you are actually using source. So basically, there seems to be little incentive not to keep source in reversed form in the first place. The second point of interest is seeing what you are using source for. One thing source is used for is keeping score of once. We need that in order to clear all \once\override commands at the end of a time step. And we need it in order to check whether a [\once]\revert applies to some property or not. But if you make this list sparse (as in storing only the elements with once being #t), it should work just fine. How to find out you are processing a given list element of the alist? Well, we are consing the top level alist entries ourselves, so their identity is established by eq if we don't change the entries. You need to check, however, whether keeping the eq-identity of an entry is feasible when it partly consists of copied sibling properties from somewhere else, and those need to be adapted because of new override/reverts. The other thing source keeps track of is the depth of nesting of each override. Making this sparse might not help all that much with regard to efficiency: when we need to consult it, we already are in the process of consing up a new spine, so we are already O(n). The question is how to keep a balance between making the code reasonably efficient as well as understandable, and thus, maintainable. While probably not all too many people are comfortable with that code area in the current state, dealing with nested properties is going to make the situation worse, and that should be kept in check as well as possible. Perhaps you'd want some more opinions. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: chaotic stems when querying direction property
So ly:glob-property has side effects because of the stem callback? How can I make sure to get the final stem direction after all dependent properties were calculated? I want to replace a note head with a triangle, but there is a gap between note head a stem when the stem points upward. To correct this, I modify the stem-attachment property of the note head. This correction offset must be different when the stem points down. I'd override the default callback for stem-attachment. It should be safe to get the stem direction at this point since it's already been calculated and cached. Cheers, Neil Thanks, Neil. That helped. I will read a little more about callbacks. A number of ugly parts of my code could be solved a lot more elegantly through callbacks. Best, Rekado ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
Well David, I should not want to let you implement this in the current form without any feedback from the developer list. [...] :-) Unfortunately, I have nothing useful to say. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
Werner LEMBERG w...@gnu.org writes: Well David, I should not want to let you implement this in the current form without any feedback from the developer list. [...] :-) Unfortunately, I have nothing useful to say. Well, there is the code (obviously bound to be streamlined before implementation) and there are the proposed semantics. At least for the latter, I would want to get some sort of feedback. The semantics can be summarized as follows: a) a revert will only cancel the last _matching_ override, and the match includes the complete specified property path, _and_ the prospective use of \once. \revert will not cancel \once\override and vice versa. b) At the end of a timestep, all \once\override are reverted. All non-\once overrides remain in effect and on the stack as if none of the \once\override had ever happened. I have no clear view about \set yet. It would seem to me that \unset should be equivalent to \revert, and \set should be equivalent to \revert+\override. I am pretty sure that any less strict 1:1 matching of reverts and overrides will cause surprises to users that are really hard to track down and explain. This is a change of existing semantics and will likely require changes to some Lilypond scores. I should be quite surprised if such changes would not make the intent of the writer easier to follow and maintain, but they would be changes nevertheless. Once I rewrite the property code in C, getting negative feedback about the semantics afterwards will be a major pain. So I made a toy implementation (it is already suffering from too much premature optimization for a toy, but is still more or less readable) in Scheme. The version in C will be less readable, but deliver the same results. The Scheme version was likely overkill to do, but whether or not somebody actually looks at it, it helped for focussing on the needed data structures. So from those not interested in the code (long as it works(TM)), I'd be at least interested in hearing whether they would be ok with _what_ I propose it should be doing, never mind _how_ it does it. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote: Werner LEMBERG w...@gnu.org writes: Unfortunately, I have nothing useful to say. Well, there is the code (obviously bound to be streamlined before implementation) and there are the proposed semantics. At least for the latter, I would want to get some sort of feedback. I agree. :( The semantics can be summarized as follows: Those look fine to me. Once I rewrite the property code in C, getting negative feedback about the semantics afterwards will be a major pain. So I made a toy implementation (it is already suffering from too much premature optimization for a toy, but is still more or less readable) in Scheme. If you really want to poke the hornet's nest, and if the scheme implementation can be used for any arbitrary lilypond file (i.e. just by adding an \include new-overrides.ly to the top), then we could ask on the lilypond-user mailing list. Since we'll be having a release candidate as soon as Mike fixes his python 2.4 problem in output-distance.py, I'd ask you to wait until 2.16 is out before pushing this change. That's the only real feedback I can give, sorry. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Prevents nested tuplets from colliding. (issue4808082)
On Aug 11, 2011, at 11:40 PM, n.putt...@gmail.com wrote: Hi Mike, Have you tested this with broken tuplets? I've tried adding breaks at random in tuplet-nest.ly and get collisions in some cases. Cheers, Neil Thanks Neil! New patchset uploaded that fixes the line breaking problem. I haven't gotten around to making the other changes you pointed out yet, but I will either tonight or tomorrow. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixes heights and pure heights of stems. (issue 4898044)
Reviewers: , Message: Hey all, This patch fixes a bug in LilyPond that has nagged me for some time: incorrect heights and pure heights for stems. THE GOOD: With this patch, heights for stems are correct (they weren't before) and pure heights are better approximations. There is one new regtest that shows it in action, and the code works favorably in several other regtests. To wit: beam-collision-beamcount.ly : leads to the lesser of two evils in a beam collision spacing-correction-accidentals.ly: actually works now (before the spacing was off) tablature-tremolo.ly: the heights between systems corresponds to the actual system skyline (lengths of stems in this context used to be set to zero) Also, the Stem grob's property list is cleaned up. It looses three confusing properties: length, stem-begin-position, and stem-end-position. It also leads to cleaner overrides: if the user wants to do some work with stem ends but does not want to trigger beam calculations, she can work with the pure callback. Idem for stem beginnings. To see this patch do its thing, add: \override Stem #'stencil = #(lambda (grob) (let ((y-ext (ly:stem::pure-height grob 0 1000)) (stem (ly:stem::print grob))) (if (null? stem) (ly:make-stencil '() '(0 . 0) '(0 . 0)) (ly:stencil-add stem (stencil-with-color (ly:stencil-translate-axis (ly:stencil-translate-axis (make-line-stencil 0.2 0 (car y-ext) 0 (cdr y-ext)) 0 Y) -0.3 X) red) or \override Stem #'stencil = #(lambda (grob) (let ((y-ext (ly:stem::height grob)) (stem (ly:stem::print grob))) (if (null? stem) (ly:make-stencil '() '(0 . 0) '(0 . 0)) (ly:stencil-add stem (stencil-with-color (ly:stencil-translate-axis (ly:stencil-translate-axis (make-line-stencil 0.2 0 (car y-ext) 0 (cdr y-ext)) 0 Y) -0.3 X) red) depending on if you want to see the height or pure height. You'll see that the results of this patch compared to current master are much better. THE BAD: The pure height calculation for beamed stems is more computationally intensive, which increases compile time for pieces with lots of beams, especially if those beams hold lots of stems. A separate patch to cache pure heights would speed this (and many other things) up a great deal. At a certain point, beam-slope-stemlet.ly gave me periodic errors of infinite stencil offset for the tuplet bracket. It no longer does this, but I'm not sure if this is because I actually fixed it or because I'm lucky. The problem originally came from the change in tuplet-brackets.cc. THE UGLY: Because this patch effects stem extents across the board, the regtest comparisons are nightmarish to check. The layout probably does not change at all in most regtests (at least not to the naked eye), but because of the change in Y-extent, almost every regtest with stems comes back as having changed. So, spotting regressions is very difficult. The files I list above are the only ones where I see a noteworthy change, and I believe all of these are for the better. PARTING SHOT: This is a labor of love that will pave the way for non-buggy glissando stems in LilyPond as well as (probably) no more stem-accidental collisions in extreme beaming situations. It may also fix other collision-related issues in the tracker (I'll have to do some snooping). The existing code logic does not change at all save the stem pure_height function. stem.cc is, however, significantly rearranged in order to consolidate properties and standardize height/pure-height approximations. Thanks for your time looking at this, and I'm looking forward to any and all comments! Cheers, MS Description: Fixes heights and pure heights of stems. Please review this at http://codereview.appspot.com/4898044/ Affected files: M input/regression/stem-length-estimation.ly A input/regression/stem-pure-height-beamed.ly M lily/beam.cc M lily/dot-column.cc M lily/include/stem.hh M lily/note-spacing.cc M lily/staff-spacing.cc M lily/stem-tremolo.cc M lily/stem.cc M lily/tie-formatting-problem.cc M lily/tuplet-bracket.cc M ly/engraver-init.ly M scm/define-grob-properties.scm M scm/define-grobs.scm M scm/flag-styles.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
Graham Percival gra...@percival-music.ca writes: On Sun, Aug 14, 2011 at 05:31:11PM +0200, David Kastrup wrote: Werner LEMBERG w...@gnu.org writes: Unfortunately, I have nothing useful to say. Well, there is the code (obviously bound to be streamlined before implementation) and there are the proposed semantics. At least for the latter, I would want to get some sort of feedback. I agree. :( The semantics can be summarized as follows: Those look fine to me. There are likely two contentious changes. The first is related to nested properties: namely that the pairing of override/revert of a property x should be independent from override/revert of a nested property x.y. However, if overrides and reverts of x and x.y are not acting as if they were issued independently, and if overrides and reverts of x and x.z are not acting as if issued independently, then it gets quite hard to let overrides and reverts of x.y and x.z act as if they were issued independently. And that would make working with nested properties less straightforward in my opinion. The second is that \once\override will not mix with \override\revert. Currently \once\override ... \override will have the second \override active just for the current timestep, and revert to the previous value afterwards. \override ... \once \override ... \revert \revert will at first revert both overrides, but reinstate the state after the first override at the end of the timestep. If I understand the code correctly. I prefer to have behavior corresponding to simple well-defined rules rather than implementation artifacts. Even if it means that the implementation is harder to write. Once I rewrite the property code in C, getting negative feedback about the semantics afterwards will be a major pain. So I made a toy implementation (it is already suffering from too much premature optimization for a toy, but is still more or less readable) in Scheme. If you really want to poke the hornet's nest, and if the scheme implementation can be used for any arbitrary lilypond file (i.e. just by adding an \include new-overrides.ly to the top), then we could ask on the lilypond-user mailing list. Since a number of other Context internals in addition to the grob property list manipulators themselves are written in C++, such a replacement is unfortunately not feasible to do without recompilation as far as I can see. Since we'll be having a release candidate as soon as Mike fixes his python 2.4 problem in output-distance.py, I'd ask you to wait until 2.16 is out before pushing this change. That's the only real feedback I can give, sorry. I'll not likely be that fast, anyway. On the other hand, once the stuff works for me, it seems reasonable to get it out for massive testing. So it seems a bit awkward that we don't have a release branch separate from master. Since the change of semantics would not be limited to nested properties, it does not make sense to rush this in under the pretense of it being a mere bug fix, however. It is more like fixing a design flaw. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
Trevor Daniels t.dani...@treda.co.uk writes: David I think we need to clarify a few things first. You wrote The semantics can be summarized as follows: a) a revert will only cancel the last _matching_ override, and the match includes the complete specified property path, _and_ the prospective use of \once. \revert will not cancel \once\override and vice versa. b) At the end of a timestep, all \once\override are reverted. All non-\once overrides remain in effect and on the stack as if none of the \once\override had ever happened. Will the order of \override and \once \overide within the same timestep for the same property matter, or does the \once \override always take precedence within its timestep? The order matters with regard to which override determines the active state of a property (always the last override). It does not matter for matching reverts to overrides. I'm not clear about stacking. Will \override be equivalent to push and \revert to pop, with the top value left on the stack being effective? Or is there no stack? There is a stack, and the last active override determines the value. If an override is just for a subproperty, it determines the value just for that subproperty (and its respective subsubproperties). The exact matching is done for matching reverts (which may for that reason happen below the stack top) to overrides, not for reading out properties. I have no clear view about \set yet. It would seem to me that \unset should be equivalent to \revert, and \set should be equivalent to \revert+\override. As we are contemplating a major change anyway, I'd prefer an equivalence in operation of \override, \once \override and \revert with \set, \once \set and \unset. Or is this infeasible? A sequence of \set \set \set would lead to stack buildup. That seems contrary to the spirit of the command name. On the other hand, a sequence of \set \unset will, under my proposal which is pretty much the current semantics, cancel a previous override, while a sequence \override \set \set \set \revert will be neutral, all-in-all. I don't particularly like all the semantics, but they are reasonably comprehensible and useful. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes heights and pure heights of stems. (issue 4898044)
Benchmark done on a book with many beams: without the patch: 51.8s and 80 pages with the patch: 52.2s and 83 pages I also noticed some ugliness's between beams and figured bass. The figures stay exactly where they were, but the stems are longer and collide a bit with them. Bertrand http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes heights and pure heights of stems. (issue 4898044)
Same remark for fingerings. See input/regression/fingering-cross-staff.ly Consecutive ties look better in input/regression/tie-single.ly http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes heights and pure heights of stems. (issue 4898044)
Wow, this is a major rewrite! I can't comment on the logic, and at present I can't test it, so I've just made a few nit-picking comments on style. Trevor http://codereview.appspot.com/4898044/diff/1/input/regression/stem-length-estimation.ly File input/regression/stem-length-estimation.ly (right): http://codereview.appspot.com/4898044/diff/1/input/regression/stem-length-estimation.ly#newcode4 input/regression/stem-length-estimation.ly:4: texidoc = Stems with overridden 'stem-end-position should 'Y-extent http://codereview.appspot.com/4898044/diff/1/lily/include/stem.hh File lily/include/stem.hh (right): http://codereview.appspot.com/4898044/diff/1/lily/include/stem.hh#newcode55 lily/include/stem.hh:55: static Grob* get_reference_head (Grob *); Grob *get_reference_head http://codereview.appspot.com/4898044/diff/1/lily/stem-tremolo.cc File lily/stem-tremolo.cc (right): http://codereview.appspot.com/4898044/diff/1/lily/stem-tremolo.cc#newcode219 lily/stem-tremolo.cc:219: Real ss = Staff_symbol_referencer::staff_space (me); delete http://codereview.appspot.com/4898044/diff/1/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4898044/diff/1/lily/stem.cc#newcode34 lily/stem.cc:34: The only exception to this is ::pure_height, whcih calls internal_pure_height which http://codereview.appspot.com/4898044/diff/1/lily/stem.cc#newcode141 lily/stem.cc:141: if (stemlet !lh beam) All three conditions include !lh; better test !lh outside http://codereview.appspot.com/4898044/diff/1/lily/stem.cc#newcode149 lily/stem.cc:149: + beam_translation * max (0, (beam_count - 1)) indent http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for Issue 620. (issue 4814041)
On 2011/08/05 00:21:45, MikeSol wrote: Neil - whenever you get the chance, I'd like to hear more of what you have to say about it. If you think that custom engravers would be a better idea here (or even non-custom engravers), I'd like to fully discuss it on the list. I think an engraver approach would be too complicated for this. Ideally, I'd like a solution which doesn't require a new property, but that's probably not feasible. Cheers, Neil http://codereview.appspot.com/4814041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for Issue 620. (issue 4814041)
http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc File lily/axis-group-interface.cc (right): http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc#newcode82 lily/axis-group-interface.cc:82: Axis_group_interface::relative_maybe_bound_group_extent (vectorGrob* const elts, vectorGrob * http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc#newcode109 lily/axis-group-interface.cc:109: vectorGrob* new_elts; vectorGrob * http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc#newcode118 lily/axis-group-interface.cc:118: if (new_elts.size () == 0) !new_elts.size () http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc#newcode846 lily/axis-group-interface.cc:846: bound-alignment-interfaces tab http://codereview.appspot.com/4814041/diff/24001/lily/axis-group-interface.cc#newcode847 lily/axis-group-interface.cc:847: default-staff-staff-spacing tab http://codereview.appspot.com/4814041/diff/24001/lily/hairpin.cc File lily/hairpin.cc (right): http://codereview.appspot.com/4814041/diff/24001/lily/hairpin.cc#newcode144 lily/hairpin.cc:144: Interval e = (Axis_group_interface::has_interface (b) tab http://codereview.appspot.com/4814041/diff/24001/lily/include/axis-group-interface.hh File lily/include/axis-group-interface.hh (right): http://codereview.appspot.com/4814041/diff/24001/lily/include/axis-group-interface.hh#newcode50 lily/include/axis-group-interface.hh:50: static Interval relative_maybe_bound_group_extent (vectorGrob* const list, vectorGrob * http://codereview.appspot.com/4814041/diff/24001/lily/include/axis-group-interface.hh#newcode51 lily/include/axis-group-interface.hh:51: Grob *common, Axis, bool); indent http://codereview.appspot.com/4814041/diff/24001/lily/line-spanner.cc File lily/line-spanner.cc (right): http://codereview.appspot.com/4814041/diff/24001/lily/line-spanner.cc#newcode112 lily/line-spanner.cc:112: Interval extent = (Paper_column::has_interface (bound_grob) if you change this to Axis_group_interface::has_interface () you should be able to remove the special case in separation-item.cc for arpeggios (and restore the old code which was replaced for issue 591 in rhythmic-column-engraver.cc) http://codereview.appspot.com/4814041/diff/24001/lily/line-spanner.cc#newcode118 lily/line-spanner.cc:118: details); tabs http://codereview.appspot.com/4814041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)
New comments, and the results of fixing some non-indent spacing issues in the source file. http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm File scm/music-functions.scm (right): http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm#newcode752 scm/music-functions.scm:752: (set! new-settings (delete x new-settings))) On 2011/08/14 03:15:34, Carl wrote: This is too much indentation. I'll need to figure out why. It worked well at line 157. I think it's the missing space between lambda and (x). When I added it, the indentation worked properly. http://codereview.appspot.com/4896043/diff/1/scm/music-functions.scm#newcode973 scm/music-functions.scm:973: ))) On 2011/08/14 07:48:48, Trevor Daniels wrote: Is it out of the question to move orphaned brackets to the previous line? I think we don't want to do that in general. The only time we want to have orphaned brackets (parentheses in the US) is if there is a list that may be added to. In that case, the orphaned brackets should be all the brackets that are not part of a list entry. In this case, I think the first bracket on this line should be attached to the end of the line before (to close off the labmda form). Then the final orphaned brackets would line up properly with the list of lambda forms. http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Nested context properties -- an implementation sketch
David Kastrup wrote Sunday, August 14, 2011 8:11 PM Trevor Daniels t.dani...@treda.co.uk writes: I think we need to clarify a few things first. You wrote I have no clear view about \set yet. It would seem to me that \unset should be equivalent to \revert, and \set should be equivalent to \revert+\override. As we are contemplating a major change anyway, I'd prefer an equivalence in operation of \override, \once \override and \revert with \set, \once \set and \unset. Or is this infeasible? A sequence of \set \set \set would lead to stack buildup. That seems contrary to the spirit of the command name. On the other hand, a sequence of \set \unset will, under my proposal which is pretty much the current semantics, cancel a previous override, while a sequence \override \set \set \set \revert will be neutral, all-in-all. Now I am confused. Are you saying that \set will operate on grob properties rather than or in addition to operating on context properties? That would be a major change! Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3833 - Release Date: 08/14/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make accidental styles available as context mods. (issue 4819064)
http://codereview.appspot.com/4819064/diff/1/scm/music-functions.scm File scm/music-functions.scm (right): http://codereview.appspot.com/4819064/diff/1/scm/music-functions.scm#newcode1267 scm/music-functions.scm:1267: Staff ,(make-accidental-rule 'same-octave 0) As Carl's pointed out here, http://codereview.appspot.com/4896043/, the current indentation cannot be maintained. I agree that the data structure should be revised instead. http://codereview.appspot.com/4819064/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add scripts/auxiliar/guileindent.scm (issue 4896043)
Hi Carl, This latest patch looks great. I'm not sold on the change to `else', but that's mainly due to being used to how Emacs does it. I'll do a bit more testing on other files and report back. Cheers, Neil http://codereview.appspot.com/4896043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes heights and pure heights of stems. (issue 4898044)
Hi Mike, This looks like a work in progress. What's going on with the begin/end position methods? You've removed the grob properties, but kept the exported callbacks plus an entry in pure-conversions-alist which does nothing. Cheers, Neil http://codereview.appspot.com/4898044/diff/1/scm/flag-styles.scm File scm/flag-styles.scm (right): http://codereview.appspot.com/4898044/diff/1/scm/flag-styles.scm#newcode188 scm/flag-styles.scm:188: ((if (eqv? d DOWN) index-cell http://codereview.appspot.com/4898044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1349 - Fix load order for running with Guile V2 (issue 4849054)
Reinhold's recent commit for log-levels will require a git re-base and probably a merge for scm/lily.scm. Will do this, re-test and upload new patch-set. Ian http://codereview.appspot.com/4849054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: cartouche collides with heading
A fix from Karl. Please test and report back. Werner ---BeginMessage--- the first cartouche collides with the heading. Does this patch (not yet committed) solve the problem in your real file? (It fixes the test file, thanks much for the reduction.) k --- texinfo.tex.~1.347.~2011-07-08 08:58:52.0 -0700 +++ texinfo.tex 2011-08-14 17:23:58.0 -0700 @@ -6275,2 +6274,8 @@ end \let\nonarrowing = t% + % + % If this cartouche directly follows a sectioning command, we need the + % \parskip glue (backspaced over by default) or the cartouche can + % collide with the section heading. + \ifnum\lastpenalty1 \vskip\parskip \fi + % \vbox\bgroup ---End Message--- ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
