Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.

Mark Polesky wrote Wednesday, July 22, 2009 8:32 AM In NR 2.2.1 Changing staff automatically, it says this: Chords will not be split across the staves; they will be assigned to a staff based on the first note named in the chord construct. http://kainhofer.com/~lilypond/Documentation/user/lily

Re: pushing to git question

Mark Polesky wrote Friday, July 24, 2009 3:16 AM One wrinkle is that compiling and testing things with "make doc" is (at the moment) out of the question on the computer that I currently have access to. Which means that I can't definitively prove that my patches don't break anything, even though

Re: ppppp but no fffff

Mark Polesky wrote Saturday, July 25, 2009 4:29 AM We all okay with this patch? LGTM Of course it's a new command and a syntax change; I don't know if that means some special process has to be taken; updating the parser, etc. I have no idea, actually. Let me know. Nothing else is needed,

Re: RFC: new vertical layout engine

Kieren MacMillan wrote Saturday, July 25, 2009 6:30 PM Thanks for the reference — for subsequent thread-followers, I also recommend Indeed, I just see that @frenchspacing is only used for French and Japanese (the latter only partially).

Re: docs

Werner wrote Monday, July 27, 2009 12:07 PM For better searching-results, sometimes add different words, e.g. cuenotes beside cue notes beside cue-notes, No, this is silly. It is a recipe for deliberately writing incorrect English grammar and inconsistent spelling. invisible beside hidden

RE: rearrange manual

I feel the vocal music bits are a little buried in the Text section. Perhaps if this section were renamed "Text and Lyrics" it would improve matters. Trevor > -Original Message- > From: [EMAIL PROTECTED] > [mailto:lilypond-user-bounces+t.daniels=treda.co.u > [EMAIL PROTECTED] Behalf Of

RE: fourth rearrangement

Hi Graham > > Based on the feedback, it seems that most users > would vastly prefer > something like this? > http://lilypondwiki.tuxfamily.org/index.php?title=Doc > I like this layout; the criterion being whether I would look in the right section for the answers to questions. I especially like

GDP - Learning Manuall Songs section

As one of the GDP helpers I'm having a first look at the Songs section which is to go into the new Learning Manual. It will be based on the Tutorial Songs section (section 2.4) in the present User Manual. This is rather short at present, and I would like to extend it. The question is, by how mu

RE: Pitches rewrite draft

Graham wrote: > Ok, let's start the other half of real GDP work > SEEKING COMMENTS / OFFERS OF HELP Some comments on Pitches > - move Cautionary accidentals into Accidentals. Yes > - move Micro tones into Accidentals. No, too specialist. Should it be moved into Specialist notation? Wherever

RE: Pitches rewrite draft

Graham replied: > Trevor Daniels wrote: > > Graham wrote: > >> - move Micro tones into Accidentals. > > > > No, too specialist. Should it be moved into Specialist > > notation? Wherever it is it needs a link to > Other languages. > > I disagree with

RE: new display for warnings

Graham wrote: > > What do you think of the new warnings in the > manual? In the Learning > Manual, see > 2.1.1 Compiling a file > 2.3.1 Music expressions explained > > As always, look at the new docs on > http://opihi.cs.uvic.ca/~gperciva/ > I quite like them, although perhaps we should reserve t

Markup with multi-measure rests

In the following example of writing a typical part containing multi-measure rests, the annotation of the rests in 2.11.34 collides if more notes are added to fill the line (to simulate this, I've added ragged-right = ##t). This seems to be a bug. The collisions can be avoided in 2.11 by attachin

Description of feathered beams

I'm attempting to improve the very brief description of feathered beams in the GDP Notation Reference. Could those of you more knowledgeable than I am please check the following draft and either correct or confirm it. Thanks. Trevor D "Feathered beams are used to indicate that a small group of

Tuplet line-breaking

I've been unable to discover how to permit line-breaking when there is a long sequence of tuplets which cross barlines. Beams and Glissandos subscribe to the unbreakable-spanner-interface, so line-breaking when these cross barlines may be permitted by setting #'breakable = ##t. But TupletBracket

Acciaccaturas with beams have no slash

Developers This topic has appeared on the users' list several times over the years, but acciaccatura with two beamed notes still look identical to appoggiatura with two beamed notes in release 2.11. This behaviour may be as intended. Certainly some music publishers slash the stems of single acc

RE: Acciaccaturas with beams have no slash

ation reference as is, but it would be a good candidate for an LSR example which could be referenced. Trevor D > From: Maximilian Albert [mailto:[EMAIL PROTECTED] > Sent: 29 October 2007 14:20 > > Trevor Daniels wrote: > > >> In either case, is there an accepted 'best&

Why no \new Score?

I am writing part of the GDP Learning Manual and having some trouble explaining why score and book blocks are introduced with \score and \book commands rather than \new Score and \new Book commands. Since it is possible to have several score and book blocks in a single input file, the user might

GDP: Colors in RGB?

I'm helping to write the GDP manuals, and am puzzled by an omission in the description of setting the color property of grobs. The Internals Reference (grob-interface) says the color should be a list, and supplying a list of RGB values like \once \override Voice.Slur #'color = #'(1.0 0.0 0.0

RE: GDP: spaces around \override Context . PropertyName

Graham Percival wrote on 03 December 2007 05:01 > > Valentin Villenave wrote: > > P.S. isn't there really any possibility to make > the foo.Bar syntax > > work in lyricmode? that would solve the problem > for good, wouldn't it? Absolutely! > > But I guess there isn't... > > We want to displa

RE: Help on changing staff sizes

As I said yesterday, I've already added this to the learning manual. Maybe it needs to go somewhere in the Notation Reference too? Trevor D > -Original Message- > From: [EMAIL PROTECTED] > [mailto:lilypond-user-bounces+t.daniels=treda.co.u > [EMAIL PROTECTED] Behalf Of > Till Rettig > S

left and right padding

The Internals Reference says that the left-padding and right-padding properties of the accidental-placement-interface, which are used (only) by the AccidentalPlacement object are user-settable, but I can't see any effect resulting from setting them. Should there be? Or is the IR misleading on thi

RE: left and right padding

relative { > > \override Staff.AccidentalPlacement #'right-padding = #10 > > } > >/Mats > > Trevor Daniels wrote: > > The Internals Reference says that the left-padding and > > right-padding properties of the > > accidental-placement-interface,

RE: msysgit, was Request for comments: prettify snippets page

Valentin Villenave 28 December 2007 21:57 > > 2007/12/28, Graham Percival <[EMAIL PROTECTED]>: > > > > > 1) Could you write up detailed > explanations of this msysgit > > > > thing? Trevor might be interested. > > > Yes, I am. I installed WinGit, but it conked out tried to load up the docume

RE: Leaving

Graham I'm sure everyone on this list will wish to express their appreciation for everything you have done for the LilyPond project and the many users of LilyPond. To say we shall miss you is the biggest understatement of the year! If every user was willing to contribute just 1% of the effort y

RE: \times -> \tuplet (was Re: Issue 566 in lilypond: showStaffSwitch -> \staffSwitchOn)

Bryan Stanbridge wote on 27 January 2008 21:38 > > John Mandereau wrote: > > There has already been a *huge* thread on the > -user list about this, and > > the conclusion was that the only realistic > change we could do was > > renaming \times to \tuplet, and nothing else; > the point of my re

Beam thickness

Mats Bengtsson wrote on 01 February 2008 16:07 (to -user) > > Trevor Daniels wrote: > > > > By default the beam thickness is set to 0.48 of a > > staff-space (Note the IR is wrong is this respect; > > it says in units of line-thickness, which is normally > > ri

RE: GDP: NR 1.1 Piano Templates

> David Fedoruk wrote 02 February 2008 05:30 (to -user) > The "Piano Centered Dynamics" template in > particular is overwhelming. > Perhaps separating the pedal performer out from > the rest would make > this template less overwhelming. > Piano-centered dynamics are very commonly required wh

Re: NR 2.2.1 keyboards, staff changes

Keith E OHara wrote Monday, September 20, 2010 12:38 AM I am suggesting a new @knownissues for the Notation Reference 2.2.1. The corresponding bug tracker issues are 1043, 439, and 36. If issue 1043 is solved, the second paragraph of my suggestion will become obsolete. I wrote the text

Re: targeting specific context ID's from within \layout?

Mark Polesky wrote Tuesday, September 21, 2010 6:35 AM % Is there a way to target a specific context (eg. one of % several Staff contexts) from within the \layout block? I don't believe so. Modifying a single named context is the only reason for the continued existence of the ungainly \wit

Re: Doc: NR 1.5.2: Clarify voice order; \shiftOn etc. (issue2226045)

markpolesky wrote Thursday, September 23, 2010 3:51 PM On 2010/09/22 14:53:15, Graham Percival wrote: Documentation/notation/simultaneous.itely:392: @example Can't this @example be removed, now that there's the @lilypond just below it? as I think more about visual-impairment accessibility,

Re: Help with trying to alter an @lilypond example in the NR for Tracker item 1033

James Lowe wrote Wednesday, September 29, 2010 10:57 PM The current example I am having problems with is in 5.1.4 Modifying context plug-ins. The example in the current document is: --- @lilypond[quote,relative=1,ragged-right,verbatim,fragment] This should be @lilypond[quote,verbatim]

Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)

markpolesky wrote Saturday, October 02, 2010 5:09 PM Okay, here we go... Hooke's law: F=-kx "x" is the displacement of the end of the spring from its equilibrium position (in SI units: "m"); "F" is the restoring force exerted by the material (in SI units: N or kg·m/s^2); and "k

Re: What am I doing wrong here?

David Kastrup wrote Sunday, October 03, 2010 3:22 PM push = -\tweak #'side-axis #X ^\markup { \musicglyph #"accordion.push" } pull = -\tweak #'side-axis #X ^\markup { \musicglyph #"accordion.pull" } \score { \repeat unfold 8 { c'-1\push c'-1\pull } } Why does this work nice with \push, and

Re: names of vertical spacing dimensions

Mark Polesky wrote Monday, October 04, 2010 11:14 PM Usually when I propose things like this, they're shot down pretty fast, but here goes anyway. It took me a while to mentally connect the names of the vertical spacing variables with their specific domains. For example, I think it's counter

Re: docs addition, beaming cadenzas

Keith E OHara wrote Tuesday, October 05, 2010 7:18 AM In the existing @knownissues for cadenzaOn, I suggest adding one sentence (in context below) encouraging manual beams. Users might *think* autobeaming works through cadenzas, and it does for a while, but it will not through longer cadenz

Re: attachment points for vertical spacing dimensions

Mark Polesky wrote Tuesday, October 05, 2010 7:09 PM http://lists.gnu.org/archive/html/lilypond-devel/2010-10/msg00070.html Let me know what you guys think; it would be nice to achieve consensus on this one. I'm with Carl on this. I agree with all his comments. Further to my suggestion to

Re: Staff sizes...

Arno Waschk wrote Wednesday, October 06, 2010 1:27 PM why does the following: [snip> give a small piano part (which i expected) but a normal sized bassPart Staff? It does give a small bassPart here (2.13.34). What do you have in bassPart? Trevor __

Re: names of vertical spacing dimensions

Mark Polesky wrote Wednesday, October 06, 2010 4:46 PM I also think the name 'space is misleading; I propose 'default-distance. Opinions? I'd be happy with that change too. Mark Trevor ___ lilypond-devel mailing list lilypond-devel

NR 2.1 Vocal music

Graham I've just pushed a patch to NR 2.1 Vocal music which provides a first draft for the last of the blank sections marked TBC ("To Be Completed"). I believe it's now in a much better shape than it was, even though much of the chapter is in "first draft" state. Next up are the 19 TODOs, a

Re: names of vertical spacing dimensions

Mark Polesky wrote Saturday, October 09, 2010 4:46 PM It's not that I want to split hairs; I want to get the new variable names right the first time. My apologies to any of you who are getting tired with this process. :) Yes, thanks! I'm afraid I'm no longer following this discussion suff

Re: names of vertical spacing dimensions

James wrote Tuesday, October 12, 2010 1:27 PM On 12/10/2010 12:54, David Kastrup wrote: James writes: Hello, On 12/10/2010 10:13, Alexander Kobel wrote: On 2010-10-09 17:46, Mark Polesky wrote: CURRENT NAME PROPOSED NAME - top-system top-system top-title top-mar

Re: names of vertical spacing dimensions

Graham Percival Yes, but I see some weaknesses in our docs. - Glossary: staff should link to system - Glossary: both staff and system could benefit from images - Learning: add some link(s) to Glossary: system. Currently we have none! gperc...@futoi:~/src/lilypond/Documentation/learning$ git

Re: NR 2.1 Vocal music

Valentin Villenave wrote Wednesday, October 13, 2010 4:03 PM Hi Trevor, here's a minor patch for Vocal music. Nothing too extraordinary so far, I quite like what you've done! I've done about a third of the file, I plan to work on the rest later (though it may have to wait for a while :) G

Re: names of vertical spacing dimensions

David Kastrup wrote Thursday, October 14, 2010 8:42 AM Carl Sorensen writes: On 10/13/10 2:40 PM, "David Kastrup" wrote: The point is that we want a sane way of specifying document layout parameters. The current naming scheme resembles that desire. The current code not. Adapting the n

Re: names of vertical spacing dimensions

David Kastrup wrote Thursday, October 14, 2010 10:05 AM "Trevor Daniels" writes: Although this is a good point, the problem is not as stark as this might suggest. There are many situations when writing LilyPond code when score-wide settings are inappropriate. This is ju

Re: Problem with 2.13.30?

Valentin Villenave wrote Sunday, October 17, 2010 4:57 PM On Tue, Sep 7, 2010 at 1:01 AM, Trevor Daniels wrote: Looks good to me. I'll confirm when the GUB 2.13.33 for Windows is available. sorry for bumping this discussion, but: where are we wrt this problem? Whoops, sorry, I f

TODO in vocal

Valentin There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff << Voice \lyricsto >> bug If it really is a bug then we shouldn't be documenting it anyway, but I'd like to know what it means first. Do you know which bug it is referring to? Trevor __

Re: TODO in vocal

Valentin Villenave wrote Monday, October 18, 2010 1:47 PM On Mon, Oct 18, 2010 at 12:03 PM, Trevor Daniels wrote: There's a TODO in vocal.itely that I don't understand: 902 @c TODO: document \new Staff << Voice \lyricsto >> bug If it really is a bug then we shoul

Re: anybody understand the instrumentCueName docs?

Keith E OHara wrote Monday, October 18, 2010 11:40 PM I suggest (diff attached) removing the part about instrumentCueName in favor of a fuller example for \killCues. The manual teaches markup elsewhere; the challenge with cue-note labels is to let the label appear with the cue notes in parts

Re: anybody understand the instrumentCueName docs?

Keith E OHara wrote Tuesday, October 19, 2010 12:21 AM One thing worth discussing is that I use the verb "to cue" differently from the original author. I believe that to cue is to *give* a signal for someone else to begin action. So the instrument playing just before the singer begins is t

Re: anybody understand the instrumentCueName docs?

Trevor Daniels wrote Tuesday, October 19, 2010 9:35 PM Keith E OHara wrote Tuesday, October 19, 2010 12:21 AM Suggestions attached as a diff, I'm happy to push this as is. Many thanks Keith. Pushed to git pretty well as you suggested, Keith, and snippet updated in git. Ch

Re: anybody understand the instrumentCueName docs?

Keith E OHara wrote Tuesday, October 19, 2010 10:34 PM On Tue, 19 Oct 2010 13:34:05 -0700, Trevor Daniels wrote: If no one objects soon I shall push it. James Lowe made comments that you might not have seen yet. I see where he is coming from, but I hope my answer explained the purpose of

Re: NR 2.1 suggestions

ead and comment down to 2.1.7. Trevor - Original Message - From: "James Bailey" To: ; "Trevor Daniels" Sent: Wednesday, October 20, 2010 5:55 PM Subject: NR 2.1 suggestions These are just some things that I noticed. 2.1.1 Entering Lyrics. Lyrics are entered in

Re: NR 2.1 suggestions

Valentin Villenave wrote Wednesday, October 20, 2010 7:48 PM On Wed, Oct 20, 2010 at 7:20 PM, Trevor Daniels wrote: Many thanks for your comments. At first glance they all seem pertinent. I'll have a look at fixing them up tomorrow. I've taken the liberty to apply James&#x

Re: Query about sentence in Notation Reference

James Lowe wrote Saturday, October 23, 2010 8:00 PM While scanning through NR 1.2.2 the last section I came across the line When a multi-measure rest immediately follows a @code{\partial} setting, resulting bar-check warnings may not be displayed. Does anyone therefore know when I wouldn'

Re: [Patch] Fix #903: Add shortcuts for note names languages.(issue2606042)

Valentin Villenave wrote Saturday, October 23, 2010 9:54 PM On Thu, Oct 21, 2010 at 4:53 AM, wrote: I like this idea as a way to get the functionality you want in the short term. But I don't like it for the long term. I think the long-term syntax needs to be \language "foobar" So I th

Re: 2.14 release, or GOP now?

Graham Percival wrote Sunday, October 24, 2010 4:22 AM We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards

Re: renaming "vertical spacing inside systems" props

Mark Polesky wrote Friday, October 29, 2010 11:27 PM Here are my proposals for renaming the properties related to "Vertical spacing inside systems". * * * * * * * * * * * * * * * I've thought about it, and I think I slightly favor the term "loose line" over "non-staff line"; the word "loose"

Re: renaming "vertical spacing inside systems" props

Mark Polesky wrote Tuesday, November 02, 2010 8:56 PM Renaming proposals, round 2: CURRENT NAME PROPOSED NAME - next-staff staff-staff default-next-staff default-staff-staff inter-staffnonstaff-staff I'd go with Carl's suggestion of nonst

Re: renaming "vertical spacing inside systems" props

Carl Sorensen wrote Wednesday, November 03, 2010 11:00 PM On 11/3/10 2:49 PM, "Mark Polesky" wrote: Trevor wrote: I wonder if affinity/nonaffinity are optimal. Are they better than relatedstaff/unrelatedstaff? Or target/opposite, reference/opposite, refstaff/oppstaff? Actually, now I r

Re: renaming "vertical spacing inside systems" props

Valentin Villenave wrote Thursday, November 04, 2010 12:10 AM > On Thu, Nov 4, 2010 at 12:58 AM, Trevor Daniels wrote: >>> Renaming proposals, round 3: >>> >>> CURRENT NAME PROPOSED NAMETD's PREFERENCE >>> -

Re: solved: reference points for non-staff lines

Good work, Mark. I'd prefer to see your image in the docs rather than text. Trevor - Original Message - From: "Mark Polesky" To: "lilypond-devel" Sent: Friday, November 05, 2010 11:17 PM Subject: solved: reference points for non-staff lines In case anyone cares, I finally was abl

Re: solved: reference points for non-staff lines

Valentin Villenave wrote Saturday, November 06, 2010 12:00 AM On Sat, Nov 6, 2010 at 12:44 AM, David Kastrup wrote: "Trevor Daniels" writes: I'd prefer to see your image in the docs rather than text. Just be sure you look your best. ROTFL! Me too! Nice one, Da

Re: Renaming the 'space alist-key

Mark Polesky wrote Saturday, November 06, 2010 5:32 PM 7 proposals for renaming the 'space alist-key have been discussed, but a decision has not yet been made. And I just added an 8th proposal (initial-distance). To recap, I think the arguments *for* each of these are mostly self-evident, so

Re: renaming "vertical spacing inside systems" props

Keith E OHara wrote Sunday, November 07, 2010 2:54 AM On Sat, 06 Nov 2010 18:20:08 -0700, wrote: [...] And lastly, I still think reference/opposite is better than related/unrelated: nonstaff-referencestaff nonstaff-oppositestaff But I won't protest. Any last thoughts/votes, or should I go

Re: Renaming the 'space alist-key

Mark Polesky wrote Sunday, November 07, 2010 12:46 AM Carl Sorensen wrote: 9) initial-separation * longer but describes the meaning more accurately now we have an item-item-spacing format I vote for 8 or 9. 9. Does this entail changing 'minimum-distance to 'minimum-separation? I

Re: non-technical help for spacing issues

Keith E OHara wrote Sunday, November 07, 2010 1:19 AM On Wed, 27 Oct 2010 00:24:33 -0700, Graham Percival wrote: >On Tue, 26 Oct 2010 00:47:01 -0700, Graham wrote: >This is directed at people saying "I can't do anything to >help..." > I need a committing, not necessarily committed, par

Re: Renaming the 'space alist-key

it should remain open and transparent to the end. Trevor - Original Message - From: "Mark Polesky" To: "lilypond-devel" ; "Carl Sorensen" ; "Trevor Daniels" Cc: "Joe Neeman" Sent: Sunday, November 07, 2010 8:59 AM Subject: Re: Renaming th

Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup

Valentin Villenave wrote Sunday, November 07, 2010 10:35 AM Greetings everybody, here's a patch that (hopefully) addresses the low-priority issue 1365. I'm not sure if we've ever used convert-ly to insert comments in .ly files, but I do think we should in this specific case: the piano-cente

Re: renaming "vertical spacing inside systems" props

Mark Polesky wrote Sunday, November 07, 2010 4:40 PM Mark Polesky wrote: Okay, I think enough votes are in to finalize the most recent proposal: http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00137.html I almost forgot... Can we have one last vote among these two choices? 1) w

Re: Renaming the 'space alist-key

Mark Polesky wrote Sunday, November 07, 2010 3:30 PM All right, hopefully everyone here won't mind one last vote, so please state your preference among the following: SPACE MINIMUM-DISTANCE -- -- 1) basic-distanceminimum-distance 2) ini

Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup

Graham Percival wrote Sunday, November 07, 2010 12:50 PM On Sun, Nov 07, 2010 at 12:26:59PM -, Trevor Daniels wrote: Valentin Villenave wrote Sunday, November 07, 2010 10:35 AM >I'm not sure if we've ever used convert-ly to insert comments in >.ly >files, but I do

Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamics performergroup

Graham Percival wrote Sunday, November 07, 2010 1:07 PM On Sun, Nov 07, 2010 at 12:50:20PM +, Graham Percival wrote: The normal method would be for convert-ly to print a warning message to the console. Why is this Dynamics thing so different from previous changes? Another option is to

Re: renaming "vertical spacing inside systems" props

Mark Polesky wrote Monday, November 08, 2010 1:24 AM Instead of these two: withingroup-staff-staff-spacing staffgroup-staff-spacing Let's stay with these. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mail

Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamicsperformergroup

Reinhold Kainhofer wrote Monday, November 08, 2010 12:09 AM Am Sonntag, 7. November 2010, um 20:46:54 schrieb Trevor Daniels: I think this would be an improvement, but I don't think it's essential. The file will be left in an erroneous state so the user will be forced in

Re: [Patch] Fix #1365: convert-ly shouldn't remove Dynamicsperformergroup

Valentin Villenave wrote Monday, November 08, 2010 11:16 AM On Mon, Nov 8, 2010 at 11:13 AM, Trevor Daniels wrote: There might even be an argument for adding something which made compilation fail - in a way that clearly indicated the problem, of course. Bold idea... or insane, I can&#

Re: renaming "vertical spacing inside systems" props

Mark Polesky wrote Monday, November 08, 2010 7:14 PM Keith E OHara wrote: We will use this in context that makes that first qualifier almost redundant : \override Context.StaffGrouper #'withingroup-staff-staff-spacing This is an excellent point, and in response I'd like to propose one more

Re: anybody understand the instrumentCueName docs?

Trevor Daniels wrote Tuesday, October 19, 2010 8:34 PM Keith E OHara wrote Monday, October 18, 2010 11:40 PM I suggest (diff attached) removing the part about instrumentCueName in favor of a fuller example for \killCues. The manual teaches markup elsewhere; the challenge with cue-note

Re: vert. spacing: Rename properties (lily, scm). (issue3031041)

markpole...@gmail.com wrote Friday, November 12, 2010 10:48 PM On 2010/11/12 21:53:41, Mark Polesky wrote: I might like to keep staff-staff-spacing for the StaffGrouper prop. I'm thinking it over, and I'll get back to you. Guys, I'd rather not change StaffGrouper's 'staff-staff-spacing to '

Re: vert. spacing: Rename properties (lily, scm). (issue3031041)

Mark, you wrote Saturday, November 13, 2010 12:50 AM I think I made every suggestion except one. I didn't change "grob" to "layout object", just because "grob" appears as a word so often in define-grob-properties.scm, and "layout" doesn't appear once: That may be so, but it's a standard ter

Re: oddHeaderMarkup and its kin are \paper variables?

Mark Polesky wrote Monday, November 15, 2010 5:18 AM These are essentially \paper variables, right? oddHeaderMarkup evenHeaderMarkup oddFooterMarkup evenFooterMarkup You have to set them in the \paper block, it seems, so I would like to categorize them alongside things like system-separat

Fw: music function

This is the second time this has come up recently. Sounds like a good candidate for an enhancement request. Trevor - Original Message - From: "jakob lund" To: Sent: Wednesday, November 17, 2010 9:22 AM Subject: music function Hi I have two questions that I hope someone here can a

Re: Fw: music function

Valentin Villenave wrote Wednesday, November 17, 2010 10:47 AM On Wed, Nov 17, 2010 at 10:41 AM, Trevor Daniels wrote: Sounds like a good candidate for an enhancement request. my brain seems to be in low-power mode today, could you help me rephrase this request so I can add it to the

Re: questioning doc policy for @item

Graham Percival Saturday, November 20, 2010 12:44 AM On Fri, Nov 19, 2010 at 08:55:26AM -0800, Mark Polesky wrote: CG 4.3.6 says: "Always put �...@item’ on its own line, and separate consecutive items with a blank line." In fact, we literally have thousands of cases: $ git grep -c "^...@ite

Re: questioning doc policy for @item

Trevor Daniels wrote Saturday, November 20, 2010 8:29 AM Graham Percival Saturday, November 20, 2010 12:44 AM On Fri, Nov 19, 2010 at 08:55:26AM -0800, Mark Polesky wrote: CG 4.3.6 says: "Always put �...@item’ on its own line, and separate consecutive items with a blank line." I

Re: questioning doc policy for @item

Graham Percival wrote Saturday, November 20, 2010 8:40 PM On Sat, Nov 20, 2010 at 08:29:35AM -, Trevor Daniels wrote: Graham Percival Saturday, November 20, 2010 12:44 AM >@itemize >@item >foo far This is best, but I'd prefer a blank line before and after every @item

Re: questioning doc policy for @item

Graham Percival wrote Saturday, November 20, 2010 8:40 PM Who wants to edit the CG for this? James is away for a few days, so there's no point leaving it as a "learn how to use git" exercise. Somebody please edit the CG and push (no reitveld necessary). Done Graham: please check the commit

Re: questioning doc policy for @item

Graham Percival wrote Sunday, November 21, 2010 11:18 PM On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote: Graham Percival wrote Saturday, November 20, 2010 8:40 PM >Who wants to edit the CG for this? James is away for a few >days, >so there's no point l

Re: questioning doc policy for @item

Trevor Daniels wrote Sunday, November 21, 2010 11:58 PM Graham Percival wrote Sunday, November 21, 2010 11:18 PM On Sun, Nov 21, 2010 at 09:38:42AM -, Trevor Daniels wrote: Graham Percival wrote Saturday, November 20, 2010 8:40 PM >Who wants to edit the CG for this? James is a

Re: cueDuring and its various settings

Reinhold Kainhofer wrote Monday, November 22, 2010 4:35 PM I'm currently trying to make cue notes much better supported in LilyPond. In particular, it's not as simple as quoting the notes in a CueVoice. In real scores, there are several different options to take into account: -) Transpose th

Re: cueDuring and its various settings

Carl Sorensen wrote Monday, November 22, 2010 4:54 PM On 11/22/10 9:35 AM, "Reinhold Kainhofer" wrote: Do you have any idea how to properly add options for the cueDuring command in LilyPond??? I think you define cue-during-details as a music property, and then do \cueDuring \withMusic

Re: cueDuring and its various settings

Reinhold Kainhofer wrote Monday, November 22, 2010 7:56 PM Am Montag, 22. November 2010, um 18:57:01 schrieben Sie: Would it not be better to define these properties using \addInstrumentDefinition #"flute" ... and then simply refer to "flute" in \cueDuring, as \instrumentSwitch does? Actu

Re: Line breaks in @file{} entries?

Valentin Villenave wrote Friday, November 26, 2010 1:40 AM On Fri, Nov 26, 2010 at 1:11 AM, Graham Percival I don't think that @/ is appropriate. Certainly not for a short @file{filename.ext}. I'm willing to entertain the notion of using them inside a @file{long/directory/location/with/filena

Re: Line breaks in @file{} entries?

Valentin Villenave wrote Friday, November 26, 2010 3:00 PM Here's what I'm thinking (I'll update the doc guidelines if you guys agree): @file{} entries should not contain a @/ escape sequence, unless these are long enough to justify a possible line break. Tick, as a policy statement. Lo

Re: Line breaks in @file{} entries?

Valentin Villenave wrote Friday, November 26, 2010 5:51 PM On Fri, Nov 26, 2010 at 4:47 PM, Trevor Daniels wrote: Long entries are those who contain either more than one dash or more that :) than one slash (not counting "../"). Er, are you suggesting that @file{this/is/a/very

Re: Line breaks in @file{} entries?

Carl Sorensen wrote Friday, November 26, 2010 6:43 PM On 11/26/10 10:51 AM, "Valentin Villenave" wrote: Please have a look at the attached patch: http://dl.free.fr/pMyOkyICo I like the new patch, I think. I believe that it would be preferable to do this instead of reverting the previou

Re: Line breaks in @file{} entries?

Valentin Villenave wrote Friday, November 26, 2010 10:31 PM Thanks! I've pushed this patch, and merged translation onto master Great! Appreciated! On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels wrote: Ideally, yes. But who is going to look manually through all the docs?

Re: Line breaks in @file{} entries?

Carl Sorensen wrote Saturday, November 27, 2010 12:03 AM On 11/26/10 4:26 PM, "Valentin Villenave" wrote: I've fixed all @file refs that were more than 50-chars long (there were only a dozen or so, so this really was no big deal). Most of these file references aren't actually more than 5

Re: Modify fret calculation algorithm (issue3320041)

Carl Sorensen wrote Saturday, November 27, 2010 4:10 AM Neil found a bug in the code. What happens when someone requests an open string that isn't present in the tuning? I've got the code fixed to issue a warning. After issuing the warning, we have two choices: 1 -- leave the improper

Re: Line breaks in @file{} entries?

Graham Percival wrote Saturday, November 27, 2010 12:59 AM On Fri, Nov 26, 2010 at 11:31:06PM +0100, Valentin Villenave wrote: On Fri, Nov 26, 2010 at 10:41 PM, Trevor Daniels wrote: > OK; I agree. Patch looks good. Thanks! I've pushed this patch, and merged translation onto

<    6   7   8   9   10   11   12   13   14   >