Re: Allow digits in identifiers (issue 6493072)

It's an undocumented feature: I'm using digits in lilypond since version 2.10.33, because I'm not using the ASCII digits! All superscript and subscript digits work, additionaly I use the superscript and subscript variants of '+' and '-', and the double underscore. This selection give me the most be

Re: exact placement rules for volta brackets?

Hello Marc, I think to base the volta brackets on the bar line horizontal origin (where differnt sized bar lines in different staves are aligned together) is the best solution. I expect, based on this a 'linear transformation' can do the rest of the job. I just started my trials with a callback t

Re: [GLISS] differentiating pre/post/neutral commands

> Rather than proposing something by way of example, I would like to > see all proposals in the form of a parser patch that does not > introduce extra shift/reduce or reduce/reduce conflicts, and > maintains general backward compatibility. If a proposer manages to > get that far, I promise I will

Re: preliminary GLISS discussions

Han-Wen Nienhuys writes: > On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen wrote: >> David Kastrup writes: >> Maybe the time has finally come to drop convert-ly and implement and fully supported conversions using LilyPond on music stream level. >>> >>> You still need a parser of the

Re: [GLISS] differentiating pre/post/neutral commands

On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup wrote: >> I predict that a lot of discussions will be had, and we will end up >> with virtually no changes. I guess that such is life. >> >>> Of course many of our ideas will not be good. That's fine! >>> That's how creative thinking works! >> >> No;

Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

On 2012/09/03 03:41:39, Patrick McCarty wrote: LGTM Let's not get this merged. ly_lily_module_constant ("module-variable") is available in _both_ Guile 1.8 as well as Guile 2.0. It may cause a slight cell count hit in Guile 1.8, but we don't want Guile 1 to stick around until the end of 2.17

Re: gerrit - does it allow writing commits using a web interface?

Janek Warchoł writes: > Hi John, > > i remember that you are investigating whether we could be using Gerrit > for Lily work. I may've asked this question already, but i don't > remember whether there was a definitive answer: does gerrit have a web > interface that allows to create new commits us

Re: preliminary GLISS discussions

On Sun, Sep 2, 2012 at 8:24 AM, Jan Nieuwenhuizen wrote: > David Kastrup writes: > >>> Maybe the time has finally come to drop convert-ly and implement and >>> fully supported conversions using LilyPond on music stream level. >> >> You still need a parser of the appropriate version at the front en

Re: [GLISS] differentiating pre/post/neutral commands

Han-Wen Nienhuys writes: > On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival > wrote: > >> The meta-target is "after spending 5 years very publicly telling >> people *not* to talk about changing the syntax because we would do so >> 'in a year or two', I think I should encourage such discussions.".

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

On 2012/09/02 20:38:28, Keith wrote: On 2012/09/02 06:25:58, MikeSol wrote: > It's not a copy of the original slur because it is using > pure heights and offsets. I saw you interrogating SlurStub regarding its purity, but did not notice that SlurStub took any different shape based on 'pur

Re: [GLISS] differentiating pre/post/neutral commands

On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival wrote: > The meta-target is "after spending 5 years very publicly telling > people *not* to talk about changing the syntax because we would do > so 'in a year or two', I think I should encourage such > discussions.". I mean, people trusted me when

Re: Removes echoed information from make doc (issue 6496074)

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

Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)

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

PATCH: Countdown to 20120904

For 20:00 MST Tuesday September 4 Critical: Issue 2783 : wrong placement of timesignature - R 6494071 Issue 1290 : Skyline compac

gerrit - does it allow writing commits using a web interface?

Hi John, i remember that you are investigating whether we could be using Gerrit for Lily work. I may've asked this question already, but i don't remember whether there was a definitive answer: does gerrit have a web interface that allows to create new commits using only a web browser? I've skimme

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

On 2012/09/02 06:25:58, MikeSol wrote: It's not a copy of the original slur because it is using pure heights and offsets. I saw you interrogating SlurStub regarding its purity, but did not notice that SlurStub took any different shape based on 'pure' estimates. The SlurStubs in the regtest we

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

More nit-picking: http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py File python/convertrules.py (right): http://codereview.appspot.com/6498052/diff/7003/python/convertrules.py#newcode3395 python/convertrules.py:3395: @rule ((2, 17, 2), r"New bar line interface") There's no

Re: [GLISS] verbifying music functions

Keith OHara writes: > Graham Percival percival-music.ca> writes: > >> Let's have a look at verbifying music functions. >> [and special-cases that look just like music functions to the user] > > Most pre-fix functions do seem to be verbs expressing what we want LilyPond > to do to the following m

Re: [GLISS] verbifying music functions

Graham Percival percival-music.ca> writes: > Let's have a look at verbifying music functions. > [and special-cases that look just like music functions to the user] Most pre-fix functions do seem to be verbs expressing what we want LilyPond to do to the following music. The exceptions > appogg

Re: preliminary GLISS discussions

Keith OHara writes: > Janek Warchoł gmail.com> writes: > >> On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup gnu.org> wrote: >> > Graham Percival percival-music.ca> writes: >> >> So far I don't feel that the discussion has been very fruitful. >> > >> > And it will not be fruitful in the near futu

Re: preliminary GLISS discussions

Janek Warchoł gmail.com> writes: > On Sat, Sep 1, 2012 at 5:41 PM, David Kastrup gnu.org> wrote: > > Graham Percival percival-music.ca> writes: > >> So far I don't feel that the discussion has been very fruitful. > > > > And it will not be fruitful in the near future. One reason is that I am >

Re: Allow digits in identifiers (issue 6493072)

All in all, this creates so many loose ends and problems of the kind I have been working to get tied up that I can basically start from scratch with lexer/parser work. I am very strongly opposed to this, and it is easy to come up with examples that fail for inexplicable reasons because of the int

Re: Removes echoed information from make doc (issue 6496074)

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

Re: Allow digits in identifiers (issue 6493072)

On 2012/09/02 11:52:46, dak wrote: It looks like some _severe_ doctoring around with regard to notenames was done to make regtests pass without an actual understanding of the failure modes, introducing some half-baked in-between modes that don't have a purpose apart from papering over the

Re: Allow digits in identifiers (issue 6493072)

Reviewers: dak, http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independent.ly File input/regression/page-spacing-nonstaff-lines-independent.ly (left): http://codereview.appspot.com/6493072/diff/14/input/regression/page-spacing-nonstaff-lines-independe

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc File lily/phrasing-slur-engraver.cc (right): http://codereview.appspot.com/6498077/diff/21/lily/phrasing-slur-engraver.cc#newcode119 lily/phrasing-slur-engraver.cc:119: if (slur_stubs_.find (slurs_[j]) == slur_stubs_.en

Re: Dynamics do not unnecessarily horizontal shift for stems. (issue 6493073)

Reviewers: dak, Message: Thanks for the review! http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc File lily/self-alignment-interface.cc (right): http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213 lily/self-alignment-interface.cc

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

Thanks for the review! http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc File lily/axis-group-interface.cc (right): http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode419 lily/axis-group-interface.cc:419: */ On 2012/09/02 15:59:00, dak wro

Re: preliminary GLISS discussions

On Sun, Sep 02, 2012 at 12:58:47AM +0200, Janek Warchoł wrote: > For what it's worth, i'm ok with this discussion (and similar ones) > happening on devel, as long as we won't loose track of concrete > proposals (when they will appear, ofc.). I think the direction we're moving in is to have unstruc

[GLISS] verbifying music functions

On Sat, Sep 01, 2012 at 10:58:31PM +0200, Nicolas Sceaux wrote: > Le 1 sept. 2012 à 18:25, Graham Percival a écrit : > > > Continuing to brainstorm on the problem of it not being obvious to > > which note a particular \command refers to, what if we used: > > If a prefix music function is consiste

Dynamics do not unnecessarily horizontal shift for stems. (issue 6493073)

http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc File lily/self-alignment-interface.cc (right): http://codereview.appspot.com/6493073/diff/1/lily/self-alignment-interface.cc#newcode213 lily/self-alignment-interface.cc:213: vector_sort (vais, less ()); Seriously? If

Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)

http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc File lily/axis-group-interface.cc (right): http://codereview.appspot.com/6498077/diff/21/lily/axis-group-interface.cc#newcode390 lily/axis-group-interface.cc:390: /* Where is the point in putting a whole callback inside o

Re: wrong beam positions in LilyPond

On Sun, Sep 2, 2012 at 5:04 AM, Jan Nieuwenhuizen wrote: > Janek Warchoł writes: > >> thanks! Is there any explanation to these numbers other than digging >> it myself from beam-quanting.cc? I've skimmed over it, but didn't >> find it immediately helpful. > > I've compiled with -DDEBUG_BEAM_SCOR

Re: Trying to work out at what point patchy fails during make test

- Original Message - From: "James" To: "John Mandereau" Cc: "Devel" Sent: Sunday, September 02, 2012 3:31 PM Subject: Trying to work out at what point patchy fails during make test John, I'm still finding my way round the new layout/organization of where Patchy puts the output and

Trying to work out at what point patchy fails during make test

John, I'm still finding my way round the new layout/organization of where Patchy puts the output and test results, however it is not clear sometimes what is failing, while I can just run reject patchy and say 'where' in the cycle it fails (make, make test etc.). It does help the devs if I can be a

Removes echoed information from make doc (issue 6496074)

Reviewers: John Mandereau, Message: Please check. Description: I've tested this with a full make, make doc, make test and diffed the files created with make doc - all is exactly the same. Think this should be good to go, but just want confirmation. Please review this at http://codereview.appsp

Re: preliminary GLISS discussions

Jan Nieuwenhuizen writes: > David Kastrup writes: > >> What issues were raised? > > Janek and Graham raised the `what is a music function / let's make > everything postfix' issue. That's rather vague as an issue description. Sort of the "What is a preposition / let's make everything a case" iss

Re: preliminary GLISS discussions

Jan Nieuwenhuizen writes: > David Kastrup writes: > >>> Maybe the time has finally come to drop convert-ly and implement and >>> fully supported conversions using LilyPond on music stream level. >> >> You still need a parser of the appropriate version at the front end. > > We have perfectly fine

Allow digits in identifiers (issue 6493072)

All in all, a large step backwards for making the lexer behave predictably across modes regarding word and command syntax, connected with several timing problems when parsing. It looks like some _severe_ doctoring around with regard to notenames was done to make regtests pass without an actual un

Re: preliminary GLISS discussions

David Kastrup writes: >> Maybe the time has finally come to drop convert-ly and implement and >> fully supported conversions using LilyPond on music stream level. > > You still need a parser of the appropriate version at the front end. We have perfectly fine ly parsers of each available version a

Re: preliminary GLISS discussions

David Kastrup writes: > What issues were raised? Janek and Graham raised the `what is a music function / let's make everything postfix' issue. Han-Wen raised the issue of [nameless] optional arguments. >> instead of >> >> \relative { a \parenthesize b c } >> >> we could have something* like

Re: preliminary GLISS discussions

Jan Nieuwenhuizen writes: > David Kastrup writes: > >> Using LilyPond for reading LilyPond files (as opposed to parsers written >> in Python) has the advantage of being rather thorough, and the >> disadvantage to be tied into a single version (not all that helpful if >> you want to write somethin

Re: preliminary GLISS discussions

Jan Nieuwenhuizen writes: > Han-Wen Nienhuys writes: > >> I have become convinced that optional, unnamed arguments are not a >> happy design decision, in any language. In Lily it's particularly >> problematic, since we don't group function parameters. > > If we start doing this, that would solve

Hard-coded version numbers updated (issue 6492072)

Reviewers: Graham Percival, Description: I've checked Google and it is now indexing the 2.17 pages and returning hundreds of results - so we should update the search boxes. There's no issue tracker for this because my finger slipped when entering my google credentials. Please review this at htt

Re: slides-in-tablature.ly snippets: string numbers of hided notes arevisible

Il 02/09/2012 12:13, Phil Holmes ha scritto: Well - I've done that, but it appears that the snippet actually only works properly on 2.16. Using the LSR and on my own machine with 2.14 I get no numerals over the normal staff, and little zeros on the tabstaff. If you know how to fix that, please

Re: slides-in-tablature.ly snippets: string numbers of hided notes arevisible

- Original Message - From: "Federico Bruni" To: "Lily-Devel List" Sent: Saturday, September 01, 2012 4:40 PM Subject: slides-in-tablature.ly snippets: string numbers of hided notes arevisible I've just realized that in this snippet the hidden notes, used to make the grace slides, h

Re: preliminary GLISS discussions

Han-Wen Nienhuys writes: > I have become convinced that optional, unnamed arguments are not a > happy design decision, in any language. In Lily it's particularly > problematic, since we don't group function parameters. If we start doing this, that would solve the several of the issues raised. It

Re: preliminary GLISS discussions

David Kastrup writes: > Using LilyPond for reading LilyPond files (as opposed to parsers written > in Python) has the advantage of being rather thorough, and the > disadvantage to be tied into a single version (not all that helpful if > you want to write something like convert-ly). Maybe the time