Re: Rietveld review

>> This is a serious question I'd like to ask you. If you were the >> king of LilyPond, what would you establish as the workflow? I'd >> really like to hear your opinion. > > I'd not prohibit any work flow that can be maintained with > single-line git commands. That includes posting patch seri

Re: Rietveld review

Carl Sorensen writes: > On 5/3/10 1:02 AM, "David Kastrup" wrote: > >> >> I don't see that you stand a chance with the standard processes here. >> You don't have commit access. The gold standard here (to the >> exclusion of all other workflows) is a patch review on Rietveld. >> That basically

Re: nasty header positioning issues

> Try this one instead: > > > http://codereview.appspot.com/1089041 Thanks. Is this change sufficient? Or does the presence of this token (I mean the \vspace itself, regardless of its dimensions) trigger an insertion of a space between this and the next element of the argument list of fill-lin

Re: nasty header positioning issues

On 5/3/10 11:23 PM, "Werner LEMBERG" wrote: > > >>> It looks like \vspace has horizontal extent, which is skewing the >>> text string. >> >> Thomas morgan fixed the analogous problem with hspace earlier. >> Patch posted on Rietveld: >> >> http://codereview.appspot.com/40122 > > Are you sure

Re: nasty header positioning issues

>> It looks like \vspace has horizontal extent, which is skewing the >> text string. > > Thomas morgan fixed the analogous problem with hspace earlier. > Patch posted on Rietveld: > > http://codereview.appspot.com/40122 Are you sure this is a link to the right patch set? I see nothing related

Re: Doc: LM: Reformat ly code. (issue1056041)

http://codereview.appspot.com/1056041/show ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Doc: LM: Reformat ly code. (issue1056041)

http://codereview.appspot.com/1056041/diff/1/2 File Documentation/learning/common-notation.itely (right): http://codereview.appspot.com/1056041/diff/1/2#newcode101 Documentation/learning/common-notation.itely:101: aeses1 On 2010/05/03 14:19:08, Graham Percival wrote: On 2010/05/03 13:48:52, Car

Re: [PATCH] Doc: LM: Reformat ly code.

Trevor Daniels wrote: >> I think we should always use bar-checks when the piece >> is more than one bar long. That's a good habit to get >> into; we ought to start it right from the first. > > I would agree with this. In fact I put bar checks into > quite a few of the examples in the LM originall

Re: nasty header positioning issues

Neil Puttock gmail.com> writes: > > It looks like \vspace has horizontal extent, which is skewing the text string. > Thomas morgan fixed the analogous problem with hspace earlier. Patch posted on Rietveld: http://codereview.appspot.com/40122 Thanks, Carl __

Rietveld review (was: markup-command and markup-command-list signatures)

On 5/3/10 1:02 AM, "David Kastrup" wrote: > > I don't see that you stand a chance with the standard processes here. > You don't have commit access. The gold standard here (to the exclusion > of all other workflows) is a patch review on Rietveld. That basically > limits feedback to persons with

Re: [PATCH] Re: syntax change for \cresc

Dear Xavier, Am Montag, 3. Mai 2010 22:40:01 schrieb Xavier Scheuer: > 2010/5/3 Reinhold Kainhofer : > > Yes, this is the way around the "issue". > > > > BTW, I pushed that patch a minute ago. > > Seen it. > > BTW sorry for having "polluted" this thread with my selfish > considerations about "c

Re: [PATCH] Re: syntax change for \cresc

2010/5/3 Reinhold Kainhofer : > Yes, this is the way around the "issue". > > BTW, I pushed that patch a minute ago. Seen it. BTW sorry for having "polluted" this thread with my selfish considerations about "custom dynamics" or "text aligned on dynamics". This (and my syntax suggestions) should h

Re: Re: %module-public-interface

On Mon, May 3, 2010 at 3:50 PM, Ian Hulin wrote: > > I believe you originally put together the Lily/Guile module code.  There's an > upcoming change such that Guile want to deprecate yep. > > %module-public-interface .  The Guile developers have come up with the > proposed fix below, which req

Re: [PATCH] Re: syntax change for \cresc

Am Dienstag, 27. April 2010 19:26:01 schrieb Xavier Scheuer: > By the way I found a solution using another variable that would have > this '-' within its definition. > > mycresc = #(define-music-function (parser location mymarkup) (string?) >(make-music 'CrescendoEvent 'span-direction START >

Re: [PATCH] Re: syntax change for \cresc

Am Montag, 26. April 2010 22:29:21 schrieb Carl Sorensen: > On 4/26/10 2:24 PM, "Reinhold Kainhofer" wrote: > > Am Sonntag, 25. April 2010 14:10:40 schrieben Sie: > >> Should I say that it would be useful for many people to see this in the > >> LSR and in the doc? > > > > Yes, I totally understan

Re: Ousting bad people

Werner LEMBERG writes: > On the other hand, you obviously have too much time, David, to write > such long replies I wish I did. So you suggest I'd rather _not_ make point-to-point replies to negative reviews and hope that eventually somebody else figures out that the points are not valid with r

our development mess

On Mon, May 03, 2010 at 05:16:09PM +0200, Werner LEMBERG wrote: > > Please, PLEASE! All parties, calm down! Meanwhile the list members > should know how to tackle David; basically, I don't see hostility in > his replies but rather the wish to improve lilypond. Agreed on both points. Look, lilyp

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On 5/3/10 5:01 AM, "Han-Wen Nienhuys" wrote: > > Just for the record: I am ok with the current form of the patch. > Would anybody else care to review this before it gets pushed? http://codereview.appspot.com/969046/show Thanks, Carl ___ lilypon

Re: Page breaking fails for multiline embedded scorelocalhost/

Boris wrote: > Right now, we start from the list of markups, and for-each markup, > apply the markup function and destructively append! the resulting > stencil to the result list under construction. > > The procedural nature of this design, is somewhat limiting in terms of > expressive power. For

Re: Ousting bad people

Kieren MacMillan writes: [...] >> Having my chains yanked is not something I deal with gracefully. > > Funny... I'm still waiting to see one thing that you *do* deal with > gracefully. > >> There is no shortage of them: they are easier to recruit than coders. > > I'd rather have a civil communit

Re: Ousting bad people

>> There are undoubtedly others that feel the same way. > > There is no shortage of them: they are easier to recruit than > coders. Please, PLEASE! All parties, calm down! Meanwhile the list members should know how to tackle David; basically, I don't see hostility in his replies but rather the

Multiline score patch

On 5/3/10 8:40 AM, "Neil Puttock" wrote: > On 3 May 2010 15:04, Carl Sorensen wrote: > >> I've reviewed the patch; the only problems I see are minor indentation and >> formatting issues.  I'm surprised, because the patch set says it's 2 months >> old, but I can't find any reference to issue

Re: Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))

Hi David, >> For the record, I am appalled at David's etiquette -- which is to say, >> complete lack thereof > > Thanks for that important observation. > It is likely to improve the quality of contributions. Choose your own response here: #1 if [by some fluke of mao] you're not being your usual

Boris' formatting rules patches (was: markup-command and markup-command-list signatures)

Carl Sorensen writes: > On 5/2/10 8:38 PM, "Boris Shingarov" wrote: > >> I am working on a system of markups which allows to specify more >> flexible formatting rules. > > I've reviewed the patch; the only problems I see are minor indentation and > formatting issues. I'm surprised, because the

Re: make Completion_heads_engraver respect tuplets and scaling

On 1 May 2010 23:58, PálBenkő wrote: > hi all, > > patch and an example below. > > this may look academical, but I need this feature when > transcribing renaissance music - for real life examples see > http://wiki.lilynet.net/index.php/Benkop_projects > the Ockeghem and la Rue examples. This look

Ousting bad people (was: Don't hardcode a limited set of markup signatures. (issue969046))

Kieren MacMillan writes: > Hi Han-Wen, > >> I take issue with the way you interact with me on the mailing-list, >> and I have had enough of it. > > For the record, I am appalled at David's etiquette -- which is to say, > complete lack thereof Thanks for that important observation. It is likely

Re: markup-command and markup-command-list signatures

On 3 May 2010 15:04, Carl Sorensen wrote: > I've reviewed the patch; the only problems I see are minor indentation and > formatting issues.  I'm surprised, because the patch set says it's 2 months > old, but I can't find any reference to issue 207105 in the -devel or the > -user archives.  So thi

Re: markup-command and markup-command-list signatures

"Boris Shingarov" writes: > On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: > "Boris Shingarov" writes: >> > Markup functions being able to return a list of stencils. > > > > Markup lists don't do the trick here? >   > No; if you look at patch 207105, you'll see what I mean.   >> I

Re: markup-command and markup-command-list signatures

On 5/2/10 8:38 PM, "Boris Shingarov" wrote: > I am working on a system of markups which allows to specify more > flexible formatting rules.  WE are using it for things like multi-line > embedded scores, mixing them with markup lines, rules about what things > / combinations of things should not s

Re: markup-command and markup-command-list signatures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 3. Mai 2010 15:12:56 schrieb Boris Shingarov: > The real problem here is not of process, but of fundamental > interests. I am scratching *my* itch, which is, make > top-publication-grade work possible with Lilypond. Lilypond did not > reac

Re: Doc: LM: Reformat ly code. (issue1056041)

I'm out of time to finish this review today, so I thought it would be best to publish what I have. My overall thought is that in the Learning Manual, we shouldn't enforce yet-to-be-explained coding standards. Instead, we ought to format the examples to do the best job possible of explaining the

Re: please add patches to the tracker if they're getting lost

Hi Graham, I would like to ask for some advices concerning tracking of patches: 1. Is there an easy way to find out if some patch was pushed? 2. I guess there are some developers who's patches I don't need to follow, because they can push patches themselves. Is there a list of them? 3. should I tra

Re: markup-command and markup-command-list signatures

On Mon, 03 May 2010 09:02:55 0200, David Kastrup wrote: "Boris Shingarov" writes: > Markup functions being able to return a list of stencils. > > Markup lists don't do the trick here?   No; if you look at patch 207105, you'll see what I mean.   I don't see that you stand a chance with the

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Hi Han-Wen, > I take issue with the way you interact with me on the mailing-list, > and I have had enough of it. For the record, I am appalled at David's etiquette -- which is to say, complete lack thereof -- and understand your reaction completely. While I appreciate and (at a basic level) val

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On Mon, May 3, 2010 at 4:22 AM, David Kastrup wrote: For one reason or another, whenever I review code from you it degrades into a fight. I am not quite sure why this always happens. >>> >>> Because you don't bother taking the contributions of other people >>> seriously.  You don't read

Re: Don't hardcode a limited set of markup signatures. (issue969046)

On 2010/05/02 16:34:12, hanwenn wrote: On Sun, May 2, 2010 at 8:04 AM, wrote: > > http://codereview.appspot.com/969046/diff/7001/8002 > File lily/lexer.ll (right): > > http://codereview.appspot.com/969046/diff/7001/8002#newcode545 > lily/lexer.ll:545: // loop will be EXPECT

Re: Don't hardcode a limited set of markup signatures. (issue969046)

Han-Wen Nienhuys writes: > On Sun, May 2, 2010 at 6:19 PM, David Kastrup wrote: > >>> For one reason or another, whenever I review code from you it degrades >>> into a fight. I am not quite sure why this always happens. >> >> Because you don't bother taking the contributions of other people >> s

Re: markup-command and markup-command-list signatures

"Boris Shingarov" writes: > I am working on a system of markups which allows to specify more > flexible formatting rules.  WE are using it for things like multi-line > embedded scores, mixing them with markup lines, rules about what > things / combinations of things should not start / end a line,