Re: Coding practices

Le 16 févr. 2013 à 15:15, m...@mikesolomon.org a écrit : > I've heard from friends that Google has codified standards for how code > should be written. What are these standards like? Style guides for Google-originated open-source projects ___

Re: Add alias in Spanish for espanol note names language (issue 6811060)

Le 4 nov. 2012 à 07:53, Joram Berger a écrit : > Am 04.11.2012 00:17, schrieb David Kastrup: >> Joram Berger writes: >>> Would it be an idea to add … "français" as aliases to "italiano"? >>> >>> According to my knowledge in French, the note names are the same and >>> bémol/dièse also fits with t

Re: Provide an \un function for turning overrides and sets into reverts and unsets (issue 6588067)

Le 6 oct. 2012 à 09:10, d...@gnu.org a écrit : > Reviewers: janek, > > Message: > On 2012/10/05 14:46:09, janek wrote: >> please provide usage example(s). I suppose i like this idea, but > without >> examples i don't know what exactly will be possible, and what won't be > possible. > > Is it en

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

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: > > \postfix: c2 d\p is unchanged > /prefix: for music functions like c2 /parenthesize d > .neutral: for c

Re: GOP2-3 - GLISS or not

Le 24 juil. 2012 à 11:09, Graham Percival a écrit : > ** Stability or not? > > Stabilizing a language is a tricky process. If you do it too > early, then you’re stuck with whatever mistakes or poor design > decisions. If you do it too late, then there’s a large body of > documents in the pre-stab

Re: Substitute for s1*0

Le 7 mai 2012 à 13:58, David Kastrup a écrit : > \relative c' { > e2\p\< d\> s1*0\! > } \addlyrics { Oh no } > > \relative c' { > e2\p\< d\> <>\! > } \addlyrics { Oh yes } I think that closes the s1*0 vs. <> debate. Because of its unexpected side effects, the s1*0 idiom must be banished. Now th

Re: Substitute for s1*0

Le 6 mai 2012 à 23:54, Trevor Daniels a écrit : >> I'm ok with using <> as a quick hack for things like convert-ly >> rules, so I'm not arguing against David's patch. But I wouldn't >> want to see <> becoming part of our basic vocabulary. I still >> think that a "n" or "z" or "\null" would be m

Re: Issue 1320: Rewriting bar-line::print

Le 20 mars 2012 à 09:39, Marc Hohl a écrit : > Hello list, > > I want to rewrite most if not all definitions currently settled in > lily/bar-line.cc in scheme. Please see the attached file for my > progress so far; I don't get any error messages, but no bar lines either :-( > > Is this a feasib

Re: Plans for changing chord repeat implementations

Le 26 janv. 2012 à 11:00, David Kastrup a écrit : > The bad news is that absolute pitch friends would have to call the \q > function (any better name for it?) explicitly. Since q is an input > convenience, and relative pitch is also an input convenience, I don't > think that there would be much o

Re: Overriding a pure print callback

Le 26 déc. 2011 à 10:18, m...@apollinemike.com a écrit : > > http://lilypond.org/doc/v2.15/Documentation/contributor/understanding-pure-properties Thanks for the pointer, Mike! It's in "contributing", but what I was doing is "extending". Something is missing e.g. in

Overriding a pure print callback

Hi, I have in my tool box some overriden stencil functions, in particular for bar lines (to define custom baroque repeat bars). Now, some things seem to have changed since 2.15.20, with respect to pure things, which show strange behavior when overriding the BarLine stencil callback, with a functi

Markup implementation

Le 17 sept. 2011 à 17:41, m...@apollinemike.com a écrit : > > I've been toying with the idea for some time now of making markups at all > levels behave more like grobs. It would require a massive code rewrite, but > it'd allow a much more uniform approach to exactly this sort of thing > (marku

Make #{ #} accept everything an assignment accepts. (issue 4974046)

Hi David, This is so cool! and smart. http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm File scm/parser-ly-from-scheme.scm (right): http://codereview.appspot.com/4974046/diff/1/scm/parser-ly-from-scheme.scm#newcode36 scm/parser-ly-from-scheme.scm:36: (ly:parser-lookup

Re: [PATCH] Fix 750: No warning for non-found voice in lyrics combine when lyrics are empty

Le 9 juil. 2011 à 11:26, Reinhold Kainhofer a écrit : > Please review: > http://codereview.appspot.com/4641097 I have no remark, but thank you for doing this! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinf

Re: New alist to replace special characters. (issue4553056)

A replacement function for text is a very good idea, and would be very useful. General comments: A regtest for lyrics might be missing. The current implementation of replacement function, in the C++ part, need some rework. An alternate design might be: Define in the guile part the replacement f

Re: 'q' chord repetition shorthand. Bug?

Le 4 mai 2011 à 13:18, Francisco Vila a écrit : > Is this the intended output? Looks as if a C (incomplete) chord is > created where there is no previous chord. > > { c'8 q } What output can be intended when the input is wrong? `q' a chord repetition chord, so you should use it after chords. Ac

Re: PATCHES: 48-hour notice for fret diagrams and hamonics+chord glissando

Le 3 mars 2011 à 10:52, Graham Percival a écrit : > On Wed, Mar 02, 2011 at 11:28:16PM +0100, Nicolas Sceaux wrote: >> Le 2 mars 2011 à 08:08, Graham Percival a écrit : >> >>> Friday, 9am UK time. >>> >>> Fret diagram fixes >>> http://code

Re: PATCHES: 48-hour notice for fret diagrams and hamonics+chord glissando

Le 2 mars 2011 à 08:08, Graham Percival a écrit : > Friday, 9am UK time. > > > Fret diagram fixes > http://codereview.appspot.com/4176056/ I'm still taking care of this one... but my pace regarding LilyPond dev is just really slow. ___ lilypond-deve

Re: Fret diagram fixes (issue4176056)

Le 27 févr. 2011 à 15:17, carl.d.soren...@gmail.com a écrit : > P.S. Can you propose your patch to git-cl to the git-cl maintainers? I > think that your approach is the right one. But I don't want to have us > in the position of needing a custom git-cl. I thought git-cl was shipped in whatever

Re: Fret diagram fixes (issue4176056)

On 2011/02/17 18:39:21, Carl wrote: On 2011/02/17 16:17:29, nicolas.sceaux wrote: > There is also a modification of the first fret label position, but maybe this is > a mistake. Is the label supposed to be vertically centered with the fret line? > or the bottom of the label should be align

Fret diagram fixes (issue4176056)

Reviewers: carl.d.sorensen_gmail.com, Message: Hi, Here is a patch for fret diagrams, but as I have very little knowledge of them I may well be wrong on some points. First, it fixes sizing issues, when the size property is overridden: the xo signs became too big, and too far from the first fret

Re: Fix #1205. (issue2145047)

http://codereview.appspot.com/2145047/diff/6001/scm/define-music-display-methods.scm File scm/define-music-display-methods.scm (right): http://codereview.appspot.com/2145047/diff/6001/scm/define-music-display-methods.scm#newcode927 scm/define-music-display-methods.scm:927: (format #f "\\tempo ~{

Re: lilypond authors, release notes, announcements

Le 5 janv. 2011 à 11:37, Mats Bengtsson a écrit : > Since I haven't been very active on the LilyPond lists the last year, I think > it would be appropriate to remove my name from the "Current development team" > list. Mine too, please. I don't think I've done anything in this release. Nicolas

Re: Possible improvement to stringTunings architecture

Le 25 déc. 2010 à 01:42, Carl Sorensen a écrit : > I'd be happy if I could make something like > this work, as well: > > default-string-tunings = > #`((guitar-tuning . ,(lily->scheme )) > (bass-tuning . ,(lily->scheme )) > (mandolin-tuning . ,(lily->scheme ))) You may consider something like

Re: Help with mixing Scheme and Music

Le 23 déc. 2010 à 06:13, Carl Sorensen a écrit : > Hi, > > I'm trying to get an easier method of creating custom string tunings (see > http://article.gmane.org/gmane.comp.gnu.lilypond.general/60871) > > I'd like to do one of the following: > > \makeStringTuning #'violin-tuning If you want to

Re: Rewrite NR 3.2 Titles and headers. (issue3667041)

A short note about bookpart titles. http://codereview.appspot.com/3667041/diff/13001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/3667041/diff/13001/Documentation/notation/input.itely#newcode538 Documentation/notation/input.it

Re: lily gui in guile

2010/11/10 Jan Nieuwenhuizen : > I've created a GUB installer for linux-x86 > >    http://lilypond.org/schikkers-list/download/ Maybe LILYPOND_DATADIR environment variable should be set to ${INSTALLER_PREFIX}/share/lilypond/current by the main script, because otherwise, the lilypond serveur compl

Re: markup.scm: Remove unused and untested aliasing functionality from define-markup{, -list}-command (issue1995042)

Le 16 août 2010 à 01:33, carl.d.soren...@gmail.com a écrit : > LGTM. > > Further info: This code has been in the file since > 114c05e7b0e992de7dbdd0958d23eb8d2ab1eaae > > (the file name at that time was scm/new-markup.scm). > > I think that the alternate syntax has never been used in the main

Re: RemoveEmptyStaves and \with

Le 28 juil. 2010 à 01:50, Reinhold Kainhofer a écrit : > Am Dienstag, 27. Juli 2010, um 18:19:39 schrieb Neil Puttock: > [..] >> Why don't we move its definition to a separate file (e.g., >> `context-modifications-init.ly')? I'm sure there are other mods which >> could usefully be defined (e.g.,

Re: How to develop Emacs mode?

Le 19 juin 2010 à 16:15, David Kastrup a écrit : > Nicolas Sceaux writes: > >> Le 19 juin 2010 à 14:23, David Kastrup a écrit : >> >>> It would appear that you work on MacOSX or so. Can you check whether >>> some variation of the Midi test code using make-

Re: How to develop Emacs mode?

Le 19 juin 2010 à 14:23, David Kastrup a écrit : > It would appear pretty nonsensical for me to ignore your work on lyqi > (which, in turn, appears to be slated to replace most of the existing > lilypond-mode functionality). Indeed, I do not use LilyPond-mode anymore. > If it is compatible with

Re: How to develop Emacs mode?

Le 17 juin 2010 à 17:31, David Kastrup a écrit : > Carl Sorensen writes: > >> On 6/17/10 8:59 AM, "David Kastrup" wrote: >> >>> >>> >>> Hi, >>> >>> I have a question about developing Emacs input and major modes for >>> Lilypond. What would be the right way to go forward for me? >>> >>> I

Re: Presentation: "Publisher-grade LilyPond" in Ottawa

Le 13 juin 2010 à 15:22, David Kastrup a écrit : > If the worst Boris can come up with with regard to developer attitudes > are misconstrued postings of mine (heck, I'd think I can be enough of a > problem without reverting to such tactics) or replies to them, the > situation cannot be all that ba

Re: fix ly:parser-parse-file in an ly file (issue1345041)

Le 7 juin 2010 à 21:35, reinhold.kainho...@gmail.com a écrit : > On 2010/06/07 19:17:27, Neil Puttock wrote: >> On 2010/06/07 13:59:45, Reinhold wrote: >> > However, I fail to see where this is actually used... > >> It's called whenever Guile encounters the character sequence #{ for > parsing >>

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

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

Re: emacs lilypond-mode.el and lilypond-init.el patches to process .lytex files with "lilypond-book --pdf"/"pdflatex"

Le 8 mai 2010 à 17:37, James E. Bailey a écrit : > > > On Sat, 8 May 2010, josé henrique padovani wrote: > >> Hi, >> I have made some changes on my emacs lilypond-mode files to process lytex >> files as suggested here >> (http://lilypond.org/doc/v2.13/Documentation/usage-big-page#Invoking-li

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

Le 29 avr. 2010 à 20:27, David Kastrup a écrit : > What type signatures would be actually permissable under the assumption > that they are supported by lexer and parser? > > It is somewhat clear to me that we can't have markup-list followed by > markup in the arguments. Anything else? I'd say,

Re: PATCH: Doc: Reorganize music functions material.

Le 26 avr. 2010 à 19:46, Carl Sorensen a écrit : > The problem is that the #{ throws off the emacs Scheme editor (at least I > assume that's what happens). > > So there are two reasonably compliant choices for indentation. > > #(define-music-function (parser location args) >

Re: music-functions: #$var1 or just $var1 ?

Le 25 avr. 2010 à 08:13, Mark Polesky a écrit : > In both: > Notation 5.6.1 "Substitution function syntax", and > Extending 2.1.2 "Simple substitution functions", > > it says that variables inside the music block part of a > music-function definition should be referenced using the > hash-cash

Re: PATCH: accessors for note-column's dot-column, accidentals

Le 4 avr. 2010 à 20:20, Joe Neeman a écrit : > On Sun, 2010-04-04 at 11:46 +0200, Nicolas Sceaux wrote: >> +LY_DEFINE (ly_note_column__accidentals, >> "ly:note-column::accidentals", >> + 1, 0, 0, (SCM note_column), >> + "Return the f

Re: PATCH: accessors for note-column's dot-column, accidentals

Le 4 avr. 2010 à 13:06, Neil Puttock a écrit : > On 4 April 2010 10:46, Nicolas Sceaux wrote: >> Hi, >> >> While working on a scheme engraver for adding harpsichord ornementations >> to note heads, I'd like to be able to shift accidentals or dots attached >

PATCH: accessors for note-column's dot-column, accidentals

Hi, While working on a scheme engraver for adding harpsichord ornementations to note heads, I'd like to be able to shift accidentals or dots attached to notes. Is it OK to add this `lily/note-column-scheme.cc' file? note-column-scheme.patch Description: Binary data It makes it possible to ac

Re: Instanciable scheme engraver (issue216066)

Le 3 mars 2010 à 14:52, d...@gnu.org a écrit : > The use of modules oop and goops appears to me as part of a programming > practice at a different knowledge level than to be expected from the > audience of this example. > > If I rewrite the example to get along without those modules, are there >

Re: Enhancement: tabalture chord repetition (issue224082)

Le 1 mars 2010 à 20:24, Marc Hohl a écrit : > Nicolas Sceaux schrieb: >> >> Shouldn't there be a few words of explantion about using q and >> \tabChordRepetition somewhere in 2.4.1 "Common notation for fretted >> strings"? >>

Re: Enhancement: tabalture chord repetition (issue224082)

Le 1 mars 2010 à 10:00, Marc Hohl a écrit : > nicolas.sce...@gmail.com schrieb: >> >> http://codereview.appspot.com/224082/diff/1/3 >> File ly/chord-repetition-init.ly (right): >> >> http://codereview.appspot.com/224082/diff/1/3#newcode51 >> ly/chord-repetition-init.ly:51: #(define-public (tab-r

Re: Enhancement: tabalture chord repetition (issue224082)

On 2010/02/28 16:27:07, nicolas.sceaux wrote: http://codereview.appspot.com/224082/diff/1/3 File ly/chord-repetition-init.ly (right): http://codereview.appspot.com/224082/diff/1/3#newcode51 ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord previous-chord location duration art

Re: Instanciable scheme engraver (issue216066)

Le 28 févr. 2010 à 17:11, Han-Wen Nienhuys a écrit : > On Sun, Feb 28, 2010 at 12:48 PM, Nicolas Sceaux > wrote: > >>> On Sun, Feb 21, 2010 at 7:10 AM, wrote: >>>> This is a proof-of-concept for instanciable scheme engravers, with >>>> private inst

Enhancement: tabalture chord repetition (issue224082)

http://codereview.appspot.com/224082/diff/1/3 File ly/chord-repetition-init.ly (right): http://codereview.appspot.com/224082/diff/1/3#newcode51 ly/chord-repetition-init.ly:51: #(define-public (tab-repeat-chord previous-chord location duration articulations) It would be better to define a generi

Re: Instanciable scheme engraver (issue216066)

Le 21 févr. 2010 à 15:11, Han-Wen Nienhuys a écrit : > On Sun, Feb 21, 2010 at 7:10 AM, wrote: >> This is a proof-of-concept for instanciable scheme engravers, with >> private instance slots. > > Looks OK to me; maybe you'd want to pass in the context into the > function, so it can do addition

Re: CG chapter 3, second draft

Le 28 févr. 2010 à 12:35, Graham Percival a écrit : > On Sat, Feb 27, 2010 at 02:27:35PM -0800, Mark Polesky wrote: >> ...and hopefully the final draft. >> >> http://www.markpolesky.com/norobots/compiling_new.itexi >> http://www.markpolesky.com/norobots/compiling_new.itexi.html >> >> Please revi

Re: Problems with 'q' in tablature

Le 28 févr. 2010 à 10:18, Marc Hohl a écrit : > > This solution might be very useful for tablature users, so I propose to store > the > definition for tab-repeat-chord in scm/tablature.scm and provide a > user-friendly shortcut for switching to tab-repeat-chord, perhaps > \tabChordRepetition or s

Re: Problems with 'q' in tablature

Le 27 févr. 2010 à 11:07, Marc Hohl a écrit : > > the 'q' functionality has changed after 2.13.11 was released. Nicolas Sceaux > pushed a patch > to remove multiple fingerings etc., but the string information should be > copied, IMHO. Precisely for the reason fingeri

Instanciable scheme engraver (issue216066)

Reviewers: , Message: Hi, This is a proof-of-concept for instanciable scheme engravers, with private instance slots. There is at least one issue that I have to solve before this is commitable, as this shows the following warning: Warning : Attempting to remove nonexisting listener. Warning : A

Markup and markup-list protocol

Le 17 févr. 2010 à 07:27, Boris Shingarov a écrit : > Another change I was thinking about, is to redesign the API contracts > around interpret-markup-list. [...] Boris, The patch you submitted seems to me as a hack making the \score markup command behaving differently from other markup commands,

Re: Scheme engraver structure questions

Le 9 févr. 2010 à 21:32, David Kastrup a écrit : > If you really must, you should probably use make-procedure-with-setter > in order to be able to use > > (define (engraver-method engraver 'initialize) ... According to:

Re: Scheme engraver structure questions

Le 9 févr. 2010 à 14:42, David Kastrup a écrit : > I find that syntax tiresome to read. It requires evaluation and thus > does not have a close correspondence to print syntax. > > That's partly because of the way the Scheme engraver example has been > written. > > I'd much prefer it to use back

Re: changes to Clef

Le 31 janv. 2010 à 12:50, Reinhold Kainhofer a écrit : > Before ~1800, the G clef was mainly used for violins, while all choral voices > and > most other instruments used either a C-clef of the bass clef, thus in > German, it is now usually called the "Violin-Schlüssel". The English name > "tr

Re: #'header:title etc not defined outside \header and \paper blocks in \version 2.12.2

Le 6 janv. 2010 à 13:35, Reinhold Kainhofer a écrit : > >> If so it is a pity because it would be quite nice to be able >> to write things like: >> >> \tocItem \markup { \fromproperty #'header:title } > > I had the same problem a while ago, and there is a workaround to make header > fields avai

Re: [PATCH] Nested properties in the \paper block

Le 2 janv. 2010 à 11:57, Joe Neeman a écrit : > Any objections/comments? If not, I'll push in the next few days. Please do, it looks good and is indeed more convenient. > > Cheers, > Joe > > On Tue, 2009-12-22 at 21:52 -0800, Joe Neeman wrote: >> http://codereview.appspot.com/182042/show >> >

Re: Build failure on OS X: "error: template class without a name"

Le 15 déc. 2009 à 07:20, Patrick McCarty a écrit : > On 2009-12-14, Harmath Dénes wrote: >> On 2009.12.13., at 20:31, Patrick McCarty wrote: >> >>> 2009/12/12 Harmath Dénes : And yes, this solved the problem! You're right, flex is among the dependencies. Concluding it, I think two

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

On 2009/12/17 11:23:04, dak wrote: Well, patch set 7 does that, but after rethinking this, I suppose I'd call it a mistake. Even if the option gets implemented for other constructs than markup, the time and memory savings are likely negligible. Checking for the option is likely causing m

Re: Behaviour of chord repetition in \relative mode

Le 13 déc. 2009 à 11:05, David Kastrup a écrit : >> If in an existing score I later replace a q with an explicit chord all >> the following q, qq and qqq will need changing too. > > Yes. But q, qq, and qqq are not intended for use all across the score, > but rather in confined places. I am not

Re: Behaviour of chord repetition in \relative mode

Le 12 déc. 2009 à 14:01, David Kastrup a écrit : > > { G4 g D // | /// // / // | \time 3/4 G g / | D // // | /// // // | } Memorizing more than one chord/note (e.g. 3 chords/notes), and accessing them using q, qq, qqq, would do it? ___ lilypond-devel

Re: Behaviour of chord repetition in \relative mode

Le 12 déc. 2009 à 16:00, Reinhold Kainhofer a écrit : > Am Samstag, 12. Dezember 2009 13:29:57 schrieb Nicolas Sceaux: >> In particular, I've get rid off the user-settable >> memorization function: only chords (with angle brackets) are memorized. >> This should be the mo

Behaviour of chord repetition in \relative mode

Hi, I'm taking into account remarks from previous discussions regarding chord repetition. In particular, I've get rid off the user-settable memorization function: only chords (with angle brackets) are memorized. This should be the more useful to users, and at the same time easy enough for LilyPon

Re: Chord repetition: \relative mode (issue164096)

Le 6 déc. 2009 à 20:30, d...@gnu.org a écrit : > I think it is the wrong way to go if notes can only be guessed if you > know what user-settable memorization function is in effect. We should > not sacrifice readability for the sake of saving a few keystrokes. This is a valid objection, but which

Re: Chord repetition: \relative mode (issue164096)

Hi, I've uploaded a second patch set, which introduces a chord memorization function. When dealing with a simple_chord_element (simple notes, rests, etc) or a note_chord_element (chord with several notes), the parser updates the memorized chord by calling a user-settable memorization function (s

Re: severe chord repetition problem

Le 6 déc. 2009 à 13:09, Alexander Kobel a écrit : > I'm not sure, though, if such a policy-based version is possible via Scheme > (read: at runtime), since it seems to affect the parser. This is what I was beginning to think about. I will introduce a new customizable function for the memorizatio

Re: severe chord repetition problem

Le 6 déc. 2009 à 06:28, Werner LEMBERG a écrit : > > Please see #924. This one is fixed. Concerning chord repetition, the issues that have been raised are: - \relative mode A patch is available for review at If nobody objects I'll commit it within a few d

Re: Make define-builtin-markup{, -list}-command #:category #:properties keywords (issue160048)

Le 5 déc. 2009 à 09:48, d...@gnu.org a écrit : > Currently I don't see a better way forward than using a special command > line option, something like -dindex-markup on documentation runs. As > far as I can see, everything else would come too late in the load order. > Nicolas' proposal to only i

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

Hi, When defining a user markup command, it would be better not to modify at all the variables from the (lily) module, even if you took care of the memory leak. Also, there is one file to be deleted, and the associated \include to be removed from an init .ly file. Nicolas http://codereview.app

Re: Chord repetition: \relative mode (issue164096)

Le 3 déc. 2009 à 13:26, Valentin Villenave a écrit : > On Thu, Dec 3, 2009 at 11:56 AM, wrote: >> Here is a patch to make chord repetition work in \relative mode. > > You forgot the link: http://code.google.com/p/lilypond/issues/detail?id=164096 The link really is

Chord repetition: \relative mode (issue164096)

Reviewers: , Message: Hi, Here is a patch to make chord repetition work in \relative mode. As I'm not sure how exactly music translation works, might someone comment the RepeatedChord music type definition, and the relative callback? In particular, I don't know what the RepeatedChord types prope

Re: [GLISS] Syntax of \parallelMusic

Le 29 nov. 2009 à 16:15, Alexander Kobel a écrit : > I propose using a different separator for \parallelMusic than "|", and allow > to include bar checks in there. > > \parallelMusic as is is very fine and handy, but sometimes you want to enter > a whole phrase of two or three measures in a sin

Re: Make define-builtin-markup{,-list}-command #:category #:properties keywords (issue160048)

Hi, Maybe this patch, as a first step, should focus on the unification of the syntax of the two macros? (define-markup-command (command-name layout props . arguments) arguments-signature #:properties property-bindings #:allow-other-keys #:rest body) on the user side and: (define-builti

Re: Doc: improve doc on markup command writing (issue157133)

Le 24 nov. 2009 à 17:51, d...@gnu.org a écrit : > It would make sense to apply http://codereview.appspot.com/160048> > first and make this patch work on top of that. > > There may be cases where a separate property-bind like this is useful in > called routines, and the markup commands from the me

Re: What's the deal with the module system?

2009/11/24 David Kastrup > > > file3.ly: > > myInclude = > > #(define-music-function (parser location file) (string?) > > #{ \include $file #} > > (make-music 'void #t)) > > > > \myInclude "file2.ly" > > \markup \foo > Please ignore this case, it's broken. What I had in mind a

Re: What's the deal with the module system?

Le 23 nov. 2009 à 19:03, David Kastrup a écrit : > Han-Wen Nienhuys writes: > >> On Mon, Nov 23, 2009 at 1:21 PM, David Kastrup wrote: >> lilypond a.ly b.ly we want to reuse the built-in definitions, without changes effected in a.ly leaking into the processing of b.ly >>

Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords

Le 23 nov. 2009 à 22:05, David Kastrup a écrit : > > There is no clue just _how_ one should answer the questions or what they > mean. Oh please... If you had read the git-cl README, which gives the complete sequence, instead of writing (one more time) a lengthy useless mail, then the patch would

Re: [PATCH 3/4] Make define-builtin-markup{, -list}-command #:category #:properties keywords

Le 23 nov. 2009 à 01:03, David Kastrup a écrit : > The specification of category and properties makes the *-builtin-* > variants diverge syntactically from the user specified markup. Moving > those specifications into keyword arguments makes the builtin defining > macros upwards compatible with t

Re: Doc: improve doc on markup command writing (issue157133)

Le 23 nov. 2009 à 03:23, Carl Sorensen a écrit : > > I think that what Graham meant was you should use @var{props} instead of > `props'. Yes, I've finally understood what Graham meant, but after I've sent that stupid message :) ___ lilypond-devel ma

Re: Doc: improve doc on markup command writing (issue157133)

Le 22 nov. 2009 à 17:10, Graham Percival a écrit : > On Sun, Nov 22, 2009 at 3:37 PM, wrote: >> As I'm not (obviously) a native English speaker, comments on style are >> most welcome. > > Whenever I try to publish my comments, I get a 500 server error. :( > I'll summarize them below: > - use @

Re: Doc: improve doc on markup command writing (issue157133)

Thank you Ian for the careful review. Nicolas http://codereview.appspot.com/157133/diff/1/2 File Documentation/extending/programming-interface.itely (right): http://codereview.appspot.com/157133/diff/1/2#newcode1045 Documentation/extending/programming-interface.itely:1045: The @code{layout} a

Doc: improve doc on markup command writing (issue157133)

Reviewers: , Message: Hi, This patch improves (as I hope) the documentation on markup command definition, by using more complete examples. It also tries to address an issue that was raised on -devel, concerning the different syntax between built-in and user-defined markup command definition. A

Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups

Le 22 nov. 2009 à 00:00, David Kastrup a écrit : > >> I'd be insterested to see an implementation of a single >> `define-markup-command' for builtin and user defined markups, where >> user defined commands do not pollute the (lily) module, and still are >> available across file includes. > > Ther

Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups

Le 21 nov. 2009 à 17:32, David Kastrup a écrit : > Carl Sorensen writes: > >> I still don't like the divergence between define-markup-command and >> define-internal-markup-command. > > Agree. I think define-internal-markup-command makes for more readable > code. If we can consider define-inte

Re: [PATCH 1/2] scm/define-markup-commands.scm: remove some unnecessary lookups

Le 17 nov. 2009 à 19:00, Carl Sorensen a écrit : > David, > > I appreciate your work on this. > > However, I am *not* in favor of moving in this direction to solve the > problems you correctly identified. > > In my mind, the *last* thing we need is another opaque interface in > LilyPond, where

Re: A few questions regarding markup

Le 16 nov. 2009 à 20:32, David Kastrup a écrit : > With very few exceptions (about 2 or 3, one being the harp-pedal code), > all the commands appear to use the let-binding mechanism. Indeed, when I introduced the property binding thing I changed consistently all markup command definitions. But i

Re: A few questions regarding markup

Le 14 nov. 2009 à 09:29, David Kastrup a écrit : > Now the harp-pedal command defines the property signature > > ((size 1.0) > (harp-pedal-details) > (thickness 0.5)) > > So far, so fine. It > then calls make-harp-pedal without passing it those let-bound > variables. As far as I understan

Re: Issue #768: Chord repetition shortcut

On 2009/11/12 21:40:37, Carl wrote: http://codereview.appspot.com/154056/diff/1/10#newcode1 ly/chord-repetition-init.ly:1: \version "2.13.8" Just a question. Why do this in a .ly file instead of in a .scm file? This initializes the parser object, and thus shall be placed in a .ly file, where

Re: Issue #768: Chord repetition shortcut

On 2009/11/12 21:40:37, Carl wrote: Nicolas, It looks great! Thanks. I have just a couple of suggestions for changes to the documentation I've addressed your remarks concerning documentation in a new patch http://codereview.appspot.com/154056

Re: Code formatter

Le 13 nov. 2009 à 20:01, Werner LEMBERG a écrit : > >> The rules are already defined (albeit unsatisfactorily in my opinion): >> >> Do whatever emacs does. > > Then, for goodness' sake, why not write a small elisp program to use > Emacs in batch mode on the command line (yes, this is possible)

Re: Issue #768 - chord repetition shortcut: patch for review

Le 13 nov. 2009 à 13:25, David Kastrup a écrit : Kieren MacMillan writes: Since the patch (as I understand it) ensures that q does not duplicate anything except the notes, q allows for 8-. q-^ q-. q-^ etc., right? Obviously, this would *not* be possible with something like 4*8

Re: [PATCH] Strings as markup arguments in music functions

Le 12 nov. 2009 à 23:02, Neil Puttock a écrit : Hi all, Though strings are valid markup objects according to the type predicate `markup?', the parser only recognizes full_markup objects as valid for music functions, which means it's currently impossible to pass both strings and markups unless u

Issue #768 - chord repetition shortcut: patch for review

Hi, Here is patch implementing the chord repetition shortcut that has been discussed a few times, for review: I've chosed arbitrary defaults, which may be changed: - the shortcut is `q'; - the function copying the previous chord only copies the chord pit

Re: What is the deal with define-internal-markup-command?

Le 12 nov. 2009 à 20:45, David Kastrup a écrit : Why does define-internal-markup-command have more arguments than define-markup-command? I think you mean define-builtin-markup-command. One is the doc, but there also seem to be default properties. Why doesn't define-markup-command have prop

Re: line breaks and broken beams

Le 28 oct. 09 à 08:37, David Kastrup a écrit : Carl Sorensen writes: Isn't the problem that beams create melismata in vocal music, and you don't want to have a line break in the middle of a melisma? Baroque melisme can go on for lines. Do we have a way to discourage breaks but not complete

Re: Markuplines spacing broken: how to set a line padding?

Le 18 oct. 09 à 20:34, Joe Neeman a écrit : Does (or did) this really have the effect described in the comment? It seems to me that this would have used extent-based spacing, so the lines o y l would be unevenly spaced. This was solved by using an appropriate markup list command

Markuplines spacing broken: how to set a line padding?

Hi, What is the new way of setting the next padding and spacing of an individual line (a markup line in that case)? I am asking because there is a regression regarding markup lines: they used to be densely spaced, with no extra space between lines, but now they are stretched, which is no

Re: defining an \uppercase markup function

Le 9 sept. 09 à 15:58, Kieren MacMillan a écrit : The problem is, something like \markup \uppercase \fromproperty #'header:title fails. In general, I'd rather have the syntax be \markup \uppercase { "test } instead of \markup \uppercase #"test" There is currently no workaround to this

  1   2   3   4   5   6   >