Re: GUB commands not running

On Mon, Sep 24, 2012 at 10:43:25AM +0100, Phil Holmes wrote: > - Original Message - From: "Graham Percival" > > >Either lilypond.make has changed (only one change in the past two > >years: > >https://github.com/gperciva/gub/commit/dd2f4077f5f818a6f689b0f4a795bacb92dcb8ae > >which doesn't s

Regularize lyrics lexer mode (issue 6594047)

LGTM. http://codereview.appspot.com/6594047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

>> I prefer \single to \next. >> >> \justOne \onlyOne ? > > It is, in a way, a complement to \once, so I would want to avoid > multiple-word approaches leading to CamelCase. Had someone already suggested \here? Werner ___ lilypond-devel mailing l

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

Now looking at the log files, I do get "undead" errors for our regression test 'bar-line-define-bar-glyph.ly' but not from any other files that I tried. (I don't know why the scripts from `make check` did not flag it.) There are four messages, but the particular undead objects vary from run to r

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

On 2012/09/29 09:14:08, marc wrote: Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net: > In one pdf previewer (evince) at low resolution, the span bars look a > little thicker than the regular bar lines. Disregard. The slight mis-rendering on screen was there before your patch as well. http

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

"Trevor Daniels" writes: > David Kastrup wrote Saturday, September 29, 2012 4:47 PM > >> Since by far the easiest time to press a change is before a first >> version is installed, people should speak up now if they feel that >> is significantly better than >> for changing just the head on e', o

Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)

David Kastrup wrote Saturday, September 29, 2012 4:47 PM > Marc Hohl writes: > >> Am 29.09.2012 11:01, schrieb David Kastrup: >>> Marc Hohl writes: >>> Am 28.09.2012 17:40, schrieb d...@gnu.org: >> hmm... not quite perfect. >> No other idea, though... > \here misses the relat

Re: Syntactical question [was: Re: Call for help with bar lines]

Am 29.09.2012 19:05, schrieb Laura Conrad: "Marc" == Marc Hohl writes: >> I hope that the new interface both makes more sense than the old one, >> and still allows me to set barless music without ugly gaps where the bar >> lines aren't. Marc> Hmmm - with the new interface, n

Re: Project - Eliminating grob parents and outside-staff-priority

On 29 sept. 2012, at 19:53, "Keith OHara" wrote: > On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org > wrote: > >> >> The way you're using "tentative" is almost exactly how pure properties are >> used in LilyPond. > > Specifically, 'pure-height being the estimated vertical extent be

Re: Project - Eliminating grob parents and outside-staff-priority

On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org wrote: The way you're using "tentative" is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking

Re: Adds tick mark to scripts (issue 6568055)

- Original Message - From: "Janek Warchoł" To: "Phil Holmes" Cc: "James" ; ; ; ; ; Sent: Saturday, September 29, 2012 6:25 PM Subject: Re: Adds tick mark to scripts (issue 6568055) Hmm. My answer to "how would we place the glyph at the correct vertical position, above the barline

Re: Project - Eliminating grob parents and outside-staff-priority

On 29 sept. 2012, at 18:34, Keith OHara wrote: > Han-Wen Nienhuys gmail.com> writes: > >> I think it is a much clearer abstraction to decide that each property >> can only be evaluated once, and that everything should be driven by >> callbacks. In fact, one thing I would suggest looking at is

Re: Adds tick mark to scripts (issue 6568055)

Hmm. My answer to "how would we place the glyph at the correct vertical position, above the barline?" is: i suppose that we're going to create a \tickBreathe command; if so, i guess that defining it in this manner tickBreathe = { \override BreathingSign #'outside-staff-priority = something \ove

Re: Syntactical question [was: Re: Call for help with bar lines]

> "Marc" == Marc Hohl writes: >> I hope that the new interface both makes more sense than the old one, >> and still allows me to set barless music without ugly gaps where the bar >> lines aren't. Marc> Hmmm - with the new interface, nonexistent bar lines are not Marc> supp

Re: [GLISS] facilitate changes of the (default-) drumStyleTable

Am 27.09.2012 00:32, schrieb Thomas Morley: 2012/9/26 Marc Hohl : I like the idea of giving the user the ability to change only parts of the list without having to rewrite the full list; I think that this concept could be of use in other parts of lilypond as well, Hi Marc, further testing sho

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

Am 29.09.2012 18:54, schrieb Colin Campbell: On 12-09-29 09:47 AM, David Kastrup wrote: I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick wi

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

On 12-09-29 09:47 AM, David Kastrup wrote: I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick with \single. Since by far the easiest time to

Re: Syntactical question [was: Re: Call for help with bar lines]

Am 29.09.2012 18:39, schrieb Laura Conrad: "David" == David Kastrup writes: >> \bar "" inserts an empty stencil, so the padding around the >> (invisible) bar line is preserved. David> Yes, I understood that. But what do we need that for? For the Renaissance music I transcribe,

Re: Provide \hide and \no functions for transparent and void glyphs (issue 6575048)

Too bad that \delete is taken... Maybe using \no is the right choice, although i'd prefer to make this decision after GLISS decides that we don't need \no for something else. As for \single vs. \next, i don't have a strong opinion. Janek http://codereview.appspot.com/6575048/

Re: Syntactical question [was: Re: Call for help with bar lines]

> "David" == David Kastrup writes: >> \bar "" inserts an empty stencil, so the padding around the >> (invisible) bar line is preserved. David> Yes, I understood that. But what do we need that for? For the Renaissance music I transcribe, the composers weren't thinking in bar lin

Re: Project - Eliminating grob parents and outside-staff-priority

Han-Wen Nienhuys gmail.com> writes: > I think it is a much clearer abstraction to decide that each property > can only be evaluated once, and that everything should be driven by > callbacks. In fact, one thing I would suggest looking at is removing > {before,after}_line_breaking which breaks this

Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)

On Sat, Sep 29, 2012 at 4:30 PM, wrote: > Actually, it is not really "simplifying" the grammar. At the current > point of time, the lexer has to make decisions about the type of > identifiers (and functions) at a point of time where those decisions are > actually premature. As a result of those

Re: [Lilypond-auto] Issue 2868 in lilypond: Patch: Various clean-ups in stems and beams.

Am 29.09.2012 17:01, schrieb lilyp...@googlecode.com: Comment #1 on issue 2868 by mts...@gmail.com: Patch: Various clean-ups in stems and beams. http://code.google.com/p/lilypond/issues/detail?id=2868#c1 Various clean-ups in stems and beams. *) Eliminates code dups for Kievan work. *) Transf

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

Marc Hohl writes: > Am 29.09.2012 11:01, schrieb David Kastrup: >> Marc Hohl writes: >> >>> Am 28.09.2012 17:40, schrieb d...@gnu.org: > hmm... not quite perfect. > No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly

Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)

On 2012/09/29 13:37:28, janek wrote: On Sat, Sep 29, 2012 at 3:10 PM, wrote: > Embarrassingly, not really. The point of this change is to move forward > in removing the special-casing of various *_IDENTIFIER token types. The > target is to arrive at only a single SCM_I

Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)

On Sat, Sep 29, 2012 at 3:10 PM, wrote: > Embarrassingly, not really. The point of this change is to move forward > in removing the special-casing of various *_IDENTIFIER token types. The > target is to arrive at only a single SCM_IDENTIFIER type. Once that is > achieved, it is no longer neces

Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)

Reviewers: janek, Message: On 2012/09/28 06:22:40, janek wrote: The description looks really nice, but unfortunately i think i don't grasp the consequences of this change. Could you give some before/after input examples? Embarrassingly, not really. The point of this change is to move forwa

Re: Project - Eliminating grob parents and outside-staff-priority

On Sat, Sep 29, 2012 at 11:35 AM, m...@mikesolomon.org wrote: > > On 29 sept. 2012, at 10:59, Han-Wen Nienhuys wrote: > >> On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote: >>> Han-Wen Nienhuys writes: >>> In order to do cache invalidation, you will have to construct the reverse

Re: Project - Eliminating grob parents and outside-staff-priority

On 29 sept. 2012, at 10:59, Han-Wen Nienhuys wrote: > On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote: >> Han-Wen Nienhuys writes: >> >>> In order to do cache invalidation, you will have to construct the >>> reverse graph. If A.x depends on B.y, now A points to B. For proper >>> cache i

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

Am 29.09.2012 11:01, schrieb David Kastrup: Marc Hohl writes: Am 28.09.2012 17:40, schrieb d...@gnu.org: hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly

Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)

Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net: Looks good so far. In one pdf previewer (evince) at low resolution, the span bars look a little thicker than the regular bar lines. Maybe a rounding fault of the viewer, but it would be better if you know how to avoid it. If you zoom it, this wil

Re: Error tracking through the log files [was: Re: Compilation errorwith page-breaking-page-count3.ly]

Am 28.09.2012 12:24, schrieb Phil Holmes: - Original Message - From: "Marc Hohl" To: Sent: Friday, September 28, 2012 11:00 AM Subject: Re: Error tracking through the log files [was: Re: Compilation errorwith page-breaking-page-count3.ly] [...] A brute force method is to find th

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

Marc Hohl writes: > Am 28.09.2012 17:40, schrieb d...@gnu.org: >> >>> hmm... not quite perfect. >>> No other idea, though... >> >> \here misses the relation to the next item (not that \single is much >> better). \directly was nicer in that regard. \next would possibly also >> work. > Having to

Re: Project - Eliminating grob parents and outside-staff-priority

On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup wrote: > Han-Wen Nienhuys writes: > >> In order to do cache invalidation, you will have to construct the >> reverse graph. If A.x depends on B.y, now A points to B. For proper >> cache invalidation, if B.y changes, then A.x becomes invalid. This >>

Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)

Am 28.09.2012 17:40, schrieb d...@gnu.org: On 2012/09/28 15:06:38, janek wrote: On Fri, Sep 28, 2012 at 9:30 AM, wrote: > I must be in a controversial mood today since I feel like upholding the > idea. I had been thinking about it while fetching breakfast and eating >