Re: parser variables persist beyond { } scope
Werner LEMBERG wrote: It's only for some exotic tweaks that you might want to change the fraction to something else than the default 15/16... Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the default value for \afterGrace. A documentation bug? Nope. Honest mistake. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.13.4 release soon?
Graham wrote Thursday, August 06, 2009 11:53 PM Sorry, not this time. The purpose of the unstable releases is to aid the development effort; it doesn't make sense to hold Trevor and Mark back just because the doc build is in flux. The MinGW build that Neil made is fine, Graham, so there's no need to rush on our behalf, but thanks anyway. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Freitag, 7. August 2009 07:52:53 schrieb Werner LEMBERG: It's only for some exotic tweaks that you might want to change the fraction to something else than the default 15/16... Hmm. Section 1.2.6 in notation.pdf says that 3/4 is the default value for \afterGrace. A documentation bug? No, a bug in my brain... The default is 6/8, but out examples in this thread were always talking about 15/6, so I mixed them up (but as I said, I never had any need to tweak this. Cheers, Reinhold - -- - -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKe+MSTqjEwhXvPN0RAhrqAJ0fCg4ZwOhrfykB8tVQhL1twbBG0QCfXijD Xq25q/iIQvRxgVEHmMzQ2kE= =q9hx -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On 8/5/09 7:19 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. In the meantime, we can move forward on tablature. As I see it, the current decision causes problems only if we were to change to xHead in the future and eliminate deadNote. And I see no plans in the future to eliminate deadNote. Does this make sense to you? Thanks Carl and Marc for the explanations. I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads, but I accept that no great harm has been done by this parochial approach, as long as future developers don't forget this can be easily changed. Now it's documented here there is less chance of that, but it would be even better if you could do it while it's fresh in your mind :) The generic approach has now been pushed to git 247f0b6d46fd8f3253a99f95a70ce14345daa5f9 There's a generic styledNoteHeads music function that applies a note style to music whether or not it's in a chord construct. deadNotes and palmMute have been redefined to use the generic functions instead of a specific function. I'd be happy to document it, add aliases, and flesh out NR 2 wherever crossheads are used. Please feel free to add aliases and flesh out NR 2 wherever special music heads are used (crosses is one example; harmonics might be another). But we're hoping to get one of the members of the tablature user community to develop the tablature documentation once 2.13.4 is released. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
Carl Sorensen wrote Friday, August 07, 2009 2:49 PM On 8/5/09 7:19 AM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl Sorensen wrote Wednesday, August 05, 2009 1:42 PM If we decide to use this same function for the general case of switching to a cross-shaped notehead, then we will redefine it to either crossHead or xHead, but we will still keep deadNote (the semantically correct term for guitar tablature) as an alias for xHead. I think it was a pity that the groundwork for a more generic approach was not laid down right away, so we could have easily added the aliases for all the other uses of crossheads The generic approach has now been pushed to git 247f0b6d46fd8f3253a99f95a70ce14345daa5f9 There's a generic styledNoteHeads music function that applies a note style to music whether or not it's in a chord construct. deadNotes and palmMute have been redefined to use the generic functions instead of a specific function. Carl, that's great! Thanks! It would have taken me a month to work out how to do that. I'd be happy to document it, add aliases, and flesh out NR 2 wherever crossheads are used. Please feel free to add aliases and flesh out NR 2 wherever special music heads are used (crosses is one example; harmonics might be another). Fine. The changes are all in Scheme so I can easily update my copy of Lily without waiting for a GUB release. I've got family commitments over the weekend, but I'll get to this next week. But we're hoping to get one of the members of the tablature user community to develop the tablature documentation once 2.13.4 is released. OK - I'll leave tabs alone. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: conditionally eliminating lyric extender
Hi Kieren, I'm not sure I understand the need for this. I would not normally use a lyric extender unless the syllable had an extended duration over several notes or was sung to a long note. This occurs far less frequently than a 2-note melisma. Do you attach lyric extenders unconditionally to every syllable sung to a melisma? Yes: 1. According to the engraving histories/guides I've read, there should be an extender after *every* [final] melisma syllable Aah - final syllable - yes! And it's needed whether it's a melisma or not if the final note is long, as it often is. regardless of how short (including negative) that extender line would end up being. 2. One can't possibly know in advance how wide the final engraved note spacing will be relative to the length of the lyric syllable — hence one should *always* include extenders so that Lilypond can DTRT depending on the spacing requirements [of different editions, alternative system breaks, etc.]. OK, I agree your automatic length calculation would be a nice feature, with negative lengths resulting in no extender being printed. this seems to be the standard practice in the vocal scores I'm familiar with. Recently, I've seen a lot of scores that don't use extenders *ever*... but I think this is a horrible practice which makes sight- singing more difficult. Agreed. They are definitely helpful when the duration of the note(s) in the score is significantly longer than the associated printed syllable. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the separate, but integrated website proposal
Hello Graham and John Graham Percival schrieb: On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: Le mardi 04 août 2009 à 05:20 -0700, Graham Percival a écrit : Eh? Why on earth would the Examples change for different languages? IIRC, we currently have French lyrics, Italian musical terms, German titles, Italian lyrics, an English instrument name, Italian instrument names, a Hungarian (?) title, Italian titles, some English lyrics and directions... if there was ever part of the docs that we could say yeah, we really don't need any translations here, it would be the pngs on Introduction-Examples. I was thinking on annotated SVG examples, which should be created for the essay BTW -- I believed Till had taken this over a while ago, but I never got news about this. Do you mean the annotated SVGs in web-Introduction-Text input? I read this only today, the volume on -devel ist just a bit too strong for my present pace. I had had a look at this svg generation a long time ago and was able to understand how svgs work as well as change a string inside of a file manually but I have no idea about the building scripts and so I didn't go further here. So far the web/switch/howto.html has svgs that ge translated in all languages. I thought it would be nice to have also other annotated examples especially in the essay to be translated according to language (e.g the notation examples that show how the software improved). But as said I gave up long ago neither have the time for it at the present moment. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the separate, but integrated website proposal
Francisco Vila schrieb: 2009/8/4 Graham Percival gra...@percival-music.ca: On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: I was thinking on annotated SVG examples, which should be created for the essay BTW -- I believed Till had taken this over a while ago, but I never got news about this. Do you mean the annotated SVGs in web-Introduction-Text input? Daniel Tonda was who started translating the web page, he succeeded at using Inkscape to build the translated http://lilypond.org/web/switch/howto (the crash course) pages. http://lilypond.org/web/graphics/annotate-example-1.es.png etc. Oh great, is he on the list anymore? Actually are these examples going to be integrated into the new web page? Till ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] SVG backend: Output a single SVG file for each page
On Thu, Aug 06, 2009 at 09:09:35AM -0700, Patrick McCarty wrote: On Thu, Aug 06, 2009 at 11:44:17AM +0200, Valentin Villenave wrote: 2009/8/6 Patrick McCarty pnor...@gmail.com: Any comments or suggestions are welcome. This patch is one of the final steps towards producing SVG output that is both valid and compatible across all user agents I have tested (Inkscape, Firefox, etc.) Though single-page SVG output is a sensible default, perhaps we could keep the multi-page SVG output as a -d option just in case some users might indeed want to have one single output file? Just to clarify... I think it's okay to provide a -d option for a single-file output, instead of one-file-per-page output. Sorry to bug you again, Valentin. :-) I'm starting to dislike this idea after all... At least for now. SVG is a vector graphics format, so there should only be *one* page of output per file. If we want to provide an option to generate only one SVG file, this option should apply to the PS, EPS, and PNG output as well. So this would be a different feature request, IMO. For example, if you have a multiple-page score, and use the PS backend to generate PNG output, you would get the following output if the file is named `test.ly': test-page1.png test-page2.png test-page3.png etc... Does anyone else have any thoughts about this, or the patch itself? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH v2] SVG backend: Output a single SVG file for each page
Hello, I have updated my patchset on Rietveld: http://codereview.appspot.com/105045/show The only changes from the previous patchset are updates for the documentation and source code comments. My plan is to eventually reinstate pageSet and page when they are supported by Inkscape, etc. But until then, I think this rewrite of the SVG framework offers a more reasonable solution. Please review and comment. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
\context for named Staff
I've always wondered about this. Is there a way? http://lists.gnu.org/archive/html/lilypond-user/2009-08/msg00173.html - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
magnification-font-size not documented
If anyone has time, I think the magnification-font-size procedure (last lines of font.scm) should be documented, probably here: NR 1.7.1 Selecting notation font size NR 5.4.4 Distances and measurements - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unable to use git
Huh. I had 3 open sessions visible when I logged in to savannah: https://savannah.gnu.org/my/admin/sessions.php The last 2 had a trash can icon, I clicked there and deleted them. But the first says Current session. I can't delete it from savannah. I assume these were sessions that terminated improperly, but how can I close the session that savannah thinks I'm still using? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
HTML formatting for *all* LSR snippets descriptions?
Greetings everybody,
Currently, the LSR offers three options for snippets descriptions formatting:
- Pure Unicode text
- Full HTML
- HTML fragment
`Full HTML' is not used in any snippet.
`HTML fragment' is used in most of the snippets; when generating the
doc-snippets, tags are automatically converted into texinfo:
code/code becomes @code{}, q/q becomes @qq{} (Seba has just
implemented this one, and I've rewritten all snippets accordingly, as
Werner asked).
`Pure Unicode' is sometimes used, but I think we shouldn't recommend
it any longer, since such (lack of) formatting doesn't meet our
documentation-writing guidelines. Besides, any user who want to write
plain text can do so in HTML too.
So, I'm thinking that we'd better junk these pseudo-options, and ask
Seba to make HTML formatting allowed in all snippet descriptions.
Thoughts?
Regards,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: HTML formatting for *all* LSR snippets descriptions?
Valentin Villenave wrote Friday, August 07, 2009 9:45 PM
So, I'm thinking that we'd better junk these pseudo-options, and
ask
Seba to make HTML formatting allowed in all snippet descriptions.
Thoughts?
Sounds reasonable. Do we make it clear anywhere what html
markup is permitted in snippets destined for the docs (defined
by tags that are doc-related)? Just so people don't use markup
that isn't going to be translated to texinfo.
Should any other markup be translated?
e.g
b/b to @strong{}
i/i to @emph{}
etc
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
SVG backend: Output a single SVG file for each page
lgtm. You can ignore my nitpicking if you disagree. http://codereview.appspot.com/105045/diff/5/1005 File scm/framework-svg.scm (right): http://codereview.appspot.com/105045/diff/5/1005#newcode60 Line 60: (dump (ec 'svg)) Just a very very minor thing: IWBN to have eo and ec closer together. For example, if svg-header just returned the alist of attributes then you could write (dump (eo (cons 'svg (svg-header paper))) ... (dump (ec 'svg)) and it would be totally obvious that they match. http://codereview.appspot.com/105045 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH v2] SVG backend: Output a single SVG file for each page
On Fri, Aug 07, 2009 at 01:16:43PM -0700, Patrick McCarty wrote: My plan is to eventually reinstate pageSet and page when they are supported by Inkscape, etc. But until then, I think this rewrite of the SVG framework offers a more reasonable solution. That sounds quite sensible. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unable to use git
On Fri, Aug 07, 2009 at 01:44:42PM -0700, Mark Polesky wrote: The last 2 had a trash can icon, I clicked there and deleted them. But the first says Current session. I can't delete it from savannah. I assume these were sessions that terminated improperly, but how can I close the session that savannah thinks I'm still using? I don't think it's possible to delete the current session -- you need a session (i.e. to be logged in) to be viewing your account! There's an option somewhere that says keep session active or keep me logged in or something like that... you could try changing that. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: HTML formatting for *all* LSR snippets descriptions?
On Fri, Aug 07, 2009 at 10:45:59PM +0200, Valentin Villenave wrote:
So, I'm thinking that we'd better junk these pseudo-options, and ask
Seba to make HTML formatting allowed in all snippet descriptions.
That makes sense.
code/code becomes @code{}, q/q becomes @qq{} (Seba has just
implemented this one, and I've rewritten all snippets accordingly, as
Werner asked).
I was going to complain that q wasn't real html, but apparently
it is! So why the mao do people use those silly ngr; (or
whatever) codes?!
... oh, I see. It's not supported in IE. Oh well. :)
One small concern: q produces double-quotes, whereas our texinfo
@q{} produces single quotes. I don't think it's a big deal, but
it might confuse somebody down the road.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: SVG backend: Output a single SVG file for each page
On Fri, Aug 7, 2009 at 4:56 PM, joenee...@gmail.com wrote: lgtm. You can ignore my nitpicking if you disagree. http://codereview.appspot.com/105045/diff/5/1005 File scm/framework-svg.scm (right): http://codereview.appspot.com/105045/diff/5/1005#newcode60 Line 60: (dump (ec 'svg)) Just a very very minor thing: IWBN to have eo and ec closer together. For example, if svg-header just returned the alist of attributes then you could write (dump (eo (cons 'svg (svg-header paper))) ... (dump (ec 'svg)) and it would be totally obvious that they match. Thanks, Joe. I'll implement your suggestion and then push. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
the r in git pull -r
Regarding CG 1.2.2: http://kainhofer.com/~lilypond/Documentation/contributor/Update-command.html What does -r do in git pull -r? I don't see -r listed as an option here: http://www.kernel.org/pub/software/scm/git/docs/git-pull.html - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
On Fri, Aug 07, 2009 at 07:34:01PM -0700, Mark Polesky wrote: Regarding CG 1.2.2: http://kainhofer.com/~lilypond/Documentation/contributor/Update-command.html What does -r do in git pull -r? I don't see -r listed as an option here: http://www.kernel.org/pub/software/scm/git/docs/git-pull.html It's undocumented, unfortunately. :-) The equivalent long option (that *is* documented) is git pull --rebase I think it would be nice to have an entire CG section devoted to explaining what rebasing means, but the git rebase man page provides a reasonably good explanation in the meantime. http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html HTH, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
On Mon, Aug 03, 2009 at 06:45:38PM -0700, Graham Percival wrote: On Mon, Aug 03, 2009 at 06:18:20PM -0700, Mark Polesky wrote: Graham Percival wrote: If you do restart, try the git clone --depth 1 git://URL method. (the CG will probably be updated to use this method in a week or so) it seems that this method is not suitable for developers with push access. You can't push from it -- see below. I've done it. --depth depth Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches. I read that before, but I tried it anyway. git push was just fine. I was using git 1.5.6.5. I'll double-check in a few days, before changing the CG. I've just tested git's shallow cloning feature. It's pretty neat. :-) From what I can see, shallow clones would be okay for *casual* contributors that are only sending patches based on the tip of master. However, since git history is limited to the depth of the clone, then shallow clones would not permit a developer to revert a commit from, say, three weeks ago. In other words, I think both the git clone and git clone --depth methods should be included in the CG. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
Patrick McCarty wrote: I've just tested git's shallow cloning feature. It's pretty neat. :-) From what I can see, shallow clones would be okay for *casual* contributors that are only sending patches based on the tip of master. However, since git history is limited to the depth of the clone, then shallow clones would not permit a developer to revert a commit from, say, three weeks ago. In other words, I think both the git clone and git clone --depth methods should be included in the CG. To me, it seems that a developer should be able to just stick to shallow clones for everyday use. I assume that one could simply increase the depth of the clone when needed. Is that true? I've never needed to revert a three-week old commit, but if I needed to, I figure I would just do another clone with a greater depth. Does it work that way? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git hang-ups
On Fri, Aug 07, 2009 at 08:39:16PM -0700, Mark Polesky wrote: Patrick McCarty wrote: I've just tested git's shallow cloning feature. It's pretty neat. :-) From what I can see, shallow clones would be okay for *casual* contributors that are only sending patches based on the tip of master. However, since git history is limited to the depth of the clone, then shallow clones would not permit a developer to revert a commit from, say, three weeks ago. In other words, I think both the git clone and git clone --depth methods should be included in the CG. To me, it seems that a developer should be able to just stick to shallow clones for everyday use. I assume that one could simply increase the depth of the clone when needed. Is that true? I've never needed to revert a three-week old commit, but if I needed to, I figure I would just do another clone with a greater depth. Does it work that way? I suppose that sounds reasonable, but if you reclone a repository two or three times, each time with greater depth, then you'll probably be using more bandwidth than if you had just downloaded the entire repo initially (with git clone). Really, it all depends on how developers use git history. Personally, I browse git history on the command line quite often when working with LilyPond. A while back, I needed to find a change made to a certain file several years ago (I don't remember which file). To exacerbate the problem, the file had been renamed once or twice. But git makes this easy: $ git log -p --follow file.scm Then I found the commit I was looking for very quickly. But maybe others don't use git history quite as extensively. I don't know. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the r in git pull -r
On Fri, Aug 7, 2009 at 8:45 PM, Patrick McCartypnor...@gmail.com wrote: On Fri, Aug 07, 2009 at 07:34:01PM -0700, Mark Polesky wrote: Regarding CG 1.2.2: http://kainhofer.com/~lilypond/Documentation/contributor/Update-command.html What does -r do in git pull -r? I don't see -r listed as an option here: http://www.kernel.org/pub/software/scm/git/docs/git-pull.html It's undocumented, unfortunately. :-) The equivalent long option (that *is* documented) is git pull --rebase I think it would be nice to have an entire CG section devoted to explaining what rebasing means, but the git rebase man page provides a reasonably good explanation in the meantime. http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html I'm currently reading 'Pro Git' by Scott Chacon (http://progit.org/book/) and it's a very nice introduction to using git for version control. It might make a nice link from the CG. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the separate, but integrated website proposal
On Fri, Aug 7, 2009 at 12:40 PM, Till Paalatill.ret...@gmx.de wrote: Hello Graham and John Graham Percival schrieb: On Tue, Aug 04, 2009 at 02:53:51PM +0200, John Mandereau wrote: Le mardi 04 août 2009 à 05:20 -0700, Graham Percival a écrit : Eh? Why on earth would the Examples change for different languages? IIRC, we currently have French lyrics, Italian musical terms, German titles, Italian lyrics, an English instrument name, Italian instrument names, a Hungarian (?) title, Italian titles, some English lyrics and directions... if there was ever part of the docs that we could say yeah, we really don't need any translations here, it would be the pngs on Introduction-Examples. I was thinking on annotated SVG examples, which should be created for the essay BTW -- I believed Till had taken this over a while ago, but I never got news about this. Do you mean the annotated SVGs in web-Introduction-Text input? I read this only today, the volume on -devel ist just a bit too strong for my present pace. I had had a look at this svg generation a long time ago and was able to understand how svgs work as well as change a string inside of a file manually but I have no idea about the building scripts and so I didn't go further here. So far the web/switch/howto.html has svgs that ge translated in all languages. I thought it would be nice to have also other annotated examples especially in the essay to be translated according to language (e.g the notation examples that show how the software improved). But as said I gave up long ago neither have the time for it at the present moment. I can't speak for the future content of http://lilypond.org/~graham/Text-input.html, but I will be working on the next version of the essay (once the directory structure for images in Documentation/ stabilizes), and it should not require any bit-mapped text. Even in cases such as http://lilypond.org/web/images/lily14-sarabande-correct.png, the corrections could be highlighted visually without requiring that descriptions occur in the image. Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: HTML formatting for *all* LSR snippets descriptions?
q/q becomes @qq{}
One small concern: q produces double-quotes, whereas our texinfo
@q{} produces single quotes. I don't think it's a big deal, but
it might confuse somebody down the road.
Read it again, Graham :-)
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
