Re: difference betwwen \pad-around and \pad-markup?
On 8/15/09 12:49 AM, "Reinhold Kainhofer" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Samstag, 15. August 2009 05:09:40 schrieb Carl Sorensen: >> On 8/14/09 6:14 PM, "Reinhold Kainhofer" wrote: >>> Anyway, you don't mind about any subdir, right? In that case, I would >>> simply use >>> ls input/regression/*.ly | xargs ... >>> instead. >> >> Well, I think that at least we need to be able to handle the xml regtests >> as well, so we *do* need some subdirectories, I think. > > The musicxml regtests are *.xml files, so searching for *.ly in that directory > won't help anyway. The .ly files are all auto-created in out-www, running > converty-ly on them can only give you an indication where musicxml2ly needs to > be updated to a new version... OK. That makes it easier. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 15. August 2009 05:09:40 schrieb Carl Sorensen: > On 8/14/09 6:14 PM, "Reinhold Kainhofer" wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Am Samstag, 15. August 2009 01:54:17 schrieb Carl Sorensen: > >> A related problem is that when I run convert-ly as > >> > >> find input/regression *.ly | xargs convert-ly -e --from "2.13.3" > >> > >> it does a convert-ly on all the files in input/regression/out/* and > >> input/regression/out-www/*. I don't want to mess with those files; > >> they're created by the build system. > > > > Hmm, the find call above is wrong, I suppose it should be > > find input/regression/ -name '*.ly' > > Yes, that's right. I typed it from memory, rather than pasting it from my > terminal. > > > Anyway, you don't mind about any subdir, right? In that case, I would > > simply use > > ls input/regression/*.ly | xargs ... > > instead. > > Well, I think that at least we need to be able to handle the xml regtests > as well, so we *do* need some subdirectories, I think. The musicxml regtests are *.xml files, so searching for *.ly in that directory won't help anyway. The .ly files are all auto-created in out-www, running converty-ly on them can only give you an indication where musicxml2ly needs to be updated to a new version... 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) iD8DBQFKhlpkTqjEwhXvPN0RAnfAAJ9qVBfFHkb/GlS8P3KkUI9byztMBgCfQjg2 pKPiXqzUDeDH76mhVh4yAPU= =L7dR -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/14/09 6:14 PM, "Reinhold Kainhofer" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Samstag, 15. August 2009 01:54:17 schrieb Carl Sorensen: >> A related problem is that when I run convert-ly as >> >> find input/regression *.ly | xargs convert-ly -e --from "2.13.3" >> >> it does a convert-ly on all the files in input/regression/out/* and >> input/regression/out-www/*. I don't want to mess with those files; they're >> created by the build system. > > Hmm, the find call above is wrong, I suppose it should be > find input/regression/ -name '*.ly' Yes, that's right. I typed it from memory, rather than pasting it from my terminal. > Anyway, you don't mind about any subdir, right? In that case, I would simply > use > ls input/regression/*.ly | xargs ... > instead. Well, I think that at least we need to be able to handle the xml regtests as well, so we *do* need some subdirectories, I think. > >> I've been trying to figure out how to get find to ignore any subdirectories >> called out/ or out-*/, but haven't been able to figure it out yet. Any >> help would be appreciated. > > I don't think there is a way to do it directly. You might filter the results > through grep, though: > > find input/regression *.ly | grep -v out- |grep -v /out/ |xargs convert-ly -e > \ > - --from "2.13.3" > Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Fri, Aug 14, 2009 at 05:54:17PM -0600, Carl Sorensen wrote: > > On 8/12/09 5:54 PM, "Graham Percival" wrote: > > > Yes. Now, we could just *hope* that there's only one convert-ly > > update for each version, but that would be silly. What about > > adding: > >convert-ly --from "2.13.3" ... > > It appears that when I run convert-ly on the regtests, it updates the > version number on *every* regtest, not just those whose syntax has changed. I was unclear. If there is a convert-ly rule for x.y.z, then it updates the version to x.y.z. If there is no convert-ly rule for x.y.z, then it leaves the number unchanged. > So I have hundreds of files in my commit. That's ok. > That's why I wanted to have part of the job of releasing a development > version be to > A) bump VERSION > B) run convert-ly on the Docs, the snippets, and the regtests. Won't do anything, since there won't be any convert-ly rules affecting last_released_version+1. > A related problem is that when I run convert-ly as > > find input/regression *.ly | xargs convert-ly -e --from "2.13.3" > > it does a convert-ly on all the files in input/regression/out/* and > input/regression/out-www/*. I don't want to mess with those files; they're > created by the build system. > > I've been trying to figure out how to get find to ignore any subdirectories > called out/ or out-*/, but haven't been able to figure it out yet. Any help > would be appreciated. find input/regression/ -name "*.ly" | grep -v "/out" | xargs convert-ly -e --from "2.13.3" Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Samstag, 15. August 2009 01:54:17 schrieb Carl Sorensen: > A related problem is that when I run convert-ly as > > find input/regression *.ly | xargs convert-ly -e --from "2.13.3" > > it does a convert-ly on all the files in input/regression/out/* and > input/regression/out-www/*. I don't want to mess with those files; they're > created by the build system. Hmm, the find call above is wrong, I suppose it should be find input/regression/ -name '*.ly' Anyway, you don't mind about any subdir, right? In that case, I would simply use ls input/regression/*.ly | xargs ... instead. > I've been trying to figure out how to get find to ignore any subdirectories > called out/ or out-*/, but haven't been able to figure it out yet. Any > help would be appreciated. I don't think there is a way to do it directly. You might filter the results through grep, though: find input/regression *.ly | grep -v out- |grep -v /out/ |xargs convert-ly -e \ - --from "2.13.3" 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) iD8DBQFKhf3sTqjEwhXvPN0RAr23AJ445S1Pp8aumZMZYifQfaVdTU9FqQCdGS3s LQJj/bP9s0q1yKOUwp06czQ= =ms6c -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 5:54 PM, "Graham Percival" wrote: > On Wed, Aug 12, 2009 at 05:43:39PM -0600, Carl Sorensen wrote: >> >> Also, we need to recognize that the first commit after running convert-ly on >> the docs and the snippets will result in changes to every version statement. > > Yes. Now, we could just *hope* that there's only one convert-ly > update for each version, but that would be silly. What about > adding: >convert-ly --from "2.13.3" ... > (where 2.13.3 is the previous downloadable version) > > to the above commands? > It appears that when I run convert-ly on the regtests, it updates the version number on *every* regtest, not just those whose syntax has changed. So I have hundreds of files in my commit. That's why I wanted to have part of the job of releasing a development version be to A) bump VERSION B) run convert-ly on the Docs, the snippets, and the regtests. Once we have all of the versions up to the current devel version, changes will be made only when the syntax changes in the file. A related problem is that when I run convert-ly as find input/regression *.ly | xargs convert-ly -e --from "2.13.3" it does a convert-ly on all the files in input/regression/out/* and input/regression/out-www/*. I don't want to mess with those files; they're created by the build system. I've been trying to figure out how to get find to ignore any subdirectories called out/ or out-*/, but haven't been able to figure it out yet. Any help would be appreciated. Thanks, Carl >> Maybe we need to make sure that part of the release of a new development >> version is to: >> >> A. Bump VERSION >> B. Run convert-ly (there won't be any rules, but it will change all the >> version statements, so once convert-ly is run on a new snippet and changes >> it, the proper changes will be tracked in git. > > convert-ly only changes version statements if there's a syntax > change, so this would do nothing. > > >> Back to update procedure: >> >> 3) If convert rule *is* NOT_SMART, >> A) Manually copy all snippets resulting in NOT_SMART conversion to >> B) Manually update all of these snippets: >> C) Run scripts/auxiliar/makelsr.py > > Yes, as far as it goes -- I didn't keep track of the numerous > discussions about translated docs. What happens to those? > > > Cheers, > - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/14 Neil Puttock : > 2009/8/12 Carl Sorensen : > >> Redundant is OK by me. >> >> If I think of having a checklist for a developer to submit a change, it >> would include the following: >> >> 1) New or revised code. >> 2) convert-ly rule for revisions (new functions don't need convert-ly rule) >> 2) Regression tests that demonstrate the code, including revision of old >> regression tests and creation of new regression tests as necessary. >> 3) All Documentation/snippets files that use the revised code are converted >> and copied to Documentation/snippets/new. >> >> I think we should not have makelsr.py run except at release time. Here's >> why. >> >> Currently, devel release is 2.13.3. The current working git release is >> 2.13.4, but it's never been released. If I run makelsr.py, then all the >> snippets in Documentation/snippets will be updated by the current convert-ly >> rules to 2.13.4. >> >> Next week, Marc makes a change and adds a new convert-ly rule. >> >> But, since all of the snippets are now listed as 2.13.4, there is nothing to >> be done. > > This only applies to snippets in snippets/new, since the remaining > items will be converted from the LSR tarball (which defaults to the > stable version). > > TBH, I can't say I'm particularly concerned by this issue since the > onus would be on the person adding the new convert-ly rule to ensure > any snippet compilation problems are corrected (even if this has to be > done manually). If this turns out not to be the case, any breakages > should be caught by whoever's running makelsr.py on the LSR tarball. > >> >> So it seems to me that any changed snippets should be placed in >> Documentation/snippets/new and left there until a release is made, at which >> time all the conversion takes place to get them into the proper release >> shape, and applies all the rules necessary to convert from 2.13.3 to 2.13.4. >> >> Does this make any sense, or am I all wet? >> >> Thanks, >> >> Carl >> > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/13/09 5:02 PM, "Graham Percival" wrote: > On Thu, Aug 13, 2009 at 10:01:31PM +0200, Werner LEMBERG wrote: >> >> [about Makefiles] >> >>> Don't waste your time understanding them, as their timelife is now >>> known to be very limited. >> >> Are you sure that SCons is the right choice? What about cmake? > > I used cmake for a project approximately half the size of > lilypond, and I don't recommend it. > > The main reason is that there's virtually no documentation -- they > really push the "free program, sell support" model. Which is a > completely fair business model... but it got really annoying to > continually read "buy our manual for $XY" when I was trying to set > up the system. I actually got most of my "how to use cmake" info > from reading blog posts about the system by random bloggers. :( > > Their invented macro language isn't _bad_, but it's not very > flexible. That's particularly a concern for our build system, > which involves a huge number of weirdnesses concerning the > internals reference and the translations. > > If we just had the English texinfo manuals, I might cautiously > recommend cmake (I got cmake to work with texinfo for Marsyas), > but as it is, I definitely think cmake would be wrong. > > > That said, I'm not certain that SCons is the right choice. waf > looks quite interesting, especially since it's 80kb and requires > no installation. It's also written in python, so we'd still have > that flexbility. However, I'm not certain how mature waf is -- > SCons is definitely used by some big projects. (so is cmake, I > must admit) > > Ultimately though, I'm fine with whatever John wants to use. > > ... hey, SCons seems to have a "no installation required" version: > scons-local. Ok, that eliminates the main point in favor of waf! :) Waf appears to be significantly faster than Scons in some benchmarks[1]. Speed of Scons appears to be the major drawback I've found on the web. I have no real experience with any of these build systems, however. I did look at the Scons tutorial a couple of months ago and thought it looked very interesting. Carl 1. http://tinyurl.com/9chgax > > Cheers, > - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Thu, Aug 13, 2009 at 10:01:31PM +0200, Werner LEMBERG wrote: > > [about Makefiles] > > > Don't waste your time understanding them, as their timelife is now > > known to be very limited. > > Are you sure that SCons is the right choice? What about cmake? I used cmake for a project approximately half the size of lilypond, and I don't recommend it. The main reason is that there's virtually no documentation -- they really push the "free program, sell support" model. Which is a completely fair business model... but it got really annoying to continually read "buy our manual for $XY" when I was trying to set up the system. I actually got most of my "how to use cmake" info from reading blog posts about the system by random bloggers. :( Their invented macro language isn't _bad_, but it's not very flexible. That's particularly a concern for our build system, which involves a huge number of weirdnesses concerning the internals reference and the translations. If we just had the English texinfo manuals, I might cautiously recommend cmake (I got cmake to work with texinfo for Marsyas), but as it is, I definitely think cmake would be wrong. That said, I'm not certain that SCons is the right choice. waf looks quite interesting, especially since it's 80kb and requires no installation. It's also written in python, so we'd still have that flexbility. However, I'm not certain how mature waf is -- SCons is definitely used by some big projects. (so is cmake, I must admit) Ultimately though, I'm fine with whatever John wants to use. ... hey, SCons seems to have a "no installation required" version: scons-local. Ok, that eliminates the main point in favor of waf! :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
[about Makefiles] > Don't waste your time understanding them, as their timelife is now > known to be very limited. Are you sure that SCons is the right choice? What about cmake? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/13/09 11:07 AM, "John Mandereau" wrote: > Le jeudi 13 août 2009 à 10:52 -0600, Carl Sorensen a écrit : >> I try not to look at any of the make files; it's hopeless for me to >> understand them. > > I can understand, I used to be hopeless too. Don't waste your time > understanding them, as their timelife is now known to be very limited. > > >> Is this the right understanding? > > It is. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le jeudi 13 août 2009 à 09:56 -0700, Mark Polesky a écrit : > c) change the English version and expect them to see the change >on their own, or If the changes are not spread across different files, translators will notice them; this is the preferred option for changes in text in English outside @lilypond blocks, which is not the point of current discussion. > d) change all versions and expect them to not be bothered that >I'm altering their work. Let's tick d). I plan that check-translation tool can be used to mark a translation as up to date again in case it was up to date before changes made in both this language and English. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le jeudi 13 août 2009 à 10:52 -0600, Carl Sorensen a écrit : > I try not to look at any of the make files; it's hopeless for me to > understand them. I can understand, I used to be hopeless too. Don't waste your time understanding them, as their timelife is now known to be very limited. > Is this the right understanding? It is. Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
John Mandereau wrote: > A general rule for handling translations could be, if there are changes > that can be done in all languages -- moving sections, updating @lilypond > snippets -- then mao do it for all languages. I know this is much of a > burden for the guy who does it, so drop a note on -devel or privately to > me so we increase overall productivity while spreading the work load. Actually, I don't think it's so much a burden, at least in small cases. I don't need to read German or Spanish to change "\pad-markup" to "\pad-around" in those docs. In a certain sense, leaving them unchanged is more of a burden... I can ponder how long it will take my modification to get translated, especially if it's in a node that's already "finished". And then I think, why not just do it myself? I think the core question I was trying to get at (I apologize if I wasn't able to see this earlier) is this: Is there a protocol for notifying the translators of these types of changes? Do I... a) change the English version and notify the translators b) change all versions and notify the translators c) change the English version and expect them to see the change on their own, or d) change all versions and expect them to not be bothered that I'm altering their work. I know that correcting a command-name is hardly altering one's work, but I could imagine some situations where the surrounding text is relevant to the change. Perhaps the surrounding text explains the meaning of the words that make up the command, I don't know. I'm just wary of screwing something up accidentally. If I've learned anything since I started applying patches, it's that there are unintended consequences. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/13/09 10:42 AM, "John Mandereau" wrote: > Le mardi 11 août 2009 à 21:19 -0600, Carl Sorensen a écrit : >> And if makelsr.py hasn't been done, LilyPond will get the snippet from >> Documentation/snippets/new instead of Documentation/snippets. > > This is wrong -- Thank you for the clarification. > see LILYPOND_BOOK_INCLUDES in make/lilypond-vars.make I try not to look at any of the make files; it's hopeless for me to understand them. I'm glad you do, though. > -- and not needed anyway: anyone can run makelsr.py without argument > from top of the source tree to get changes from input/new and > Documentation//texidocs into Documentation/snippets. Yes, this is what the CG recommends now. I misunderstood what input/new did. My current understanding is that it's not a place for the documentation to get snippets. It's rather a place for makelsr.py to get source material for snippets in Documentation/snippets, and a place to store snippets that will need to be manually changed when the LSR is updated. Is this the right understanding? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le mardi 11 août 2009 à 21:19 -0600, Carl Sorensen a écrit : > And if makelsr.py hasn't been done, LilyPond will get the snippet from > Documentation/snippets/new instead of Documentation/snippets. This is wrong -- see LILYPOND_BOOK_INCLUDES in make/lilypond-vars.make -- and not needed anyway: anyone can run makelsr.py without argument from top of the source tree to get changes from input/new and Documentation//texidocs into Documentation/snippets. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le mercredi 12 août 2009 à 17:27 -0700, Graham Percival a écrit : > I was talking about @lilypond stuff, not snippets. i.e. if > Documentation/fr/notation/rhythms.itely > contains some old autobeaming stuff requring a NOT_SMART rule, > what happens? We can't leave it alone, since that would break > compiling. A general rule for handling translations could be, if there are changes that can be done in all languages -- moving sections, updating @lilypond snippets -- then mao do it for all languages. I know this is much of a burden for the guy who does it, so drop a note on -devel or privately to me so we increase overall productivity while spreading the work load. This may sound cumbersome to do this way at first sight, but when you have moved one file and done all necessary updates in other source files, it's faster and easier to do it again yourself than expecting somebody else to do it fo the first time. For the particular case of @lilypond snippets, there is "make snippet-update", which is in the best case half-broken. Cheers, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: command_replace function (was: Re: difference betwwen \pad-around and \pad-markup?)
On 8/12/09 12:31 PM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>> Even better would be to define a function:
>> def command_replace(old_command, new_command, str)
>> that could then be used in a convert-ly rule
>> str = command_replace ("pad-markup", "pad-around", str)
>>
>> so that in the future you'd never have to worry about dealing
>> with word boundaries, etc. This was something Graham asked for
>> a couple of months ago, but it never got added. If you wanted
>> to do this as part of your project, it would be great.
>
> Yes, the idea was that the python function would add "\\" and "\b"
> appropriately, but at least one gotcha has been mentioned (by
> Neil):
>
> For each builtin markup-command, the define-builtin-markup-command
> macro (line 48 of markup.scm) generates a "make-COMMAND-markup",
> which wouldn't be converted if the rule mandates "\\".
>
> I presume that this wouldn't be a big deal to accommodate, but I
> have no idea how many other gotchas there are. This one is markup-
> specific, but I imagine there are plenty of other similar traps.
>
> Anyone have an idea how to find the other "traps"? Could there be
> a systematic approach?
I think the best way to do this is to do the following:
0) Ask for any other ideas as to where the regexp wouldn't work.
1) Write the function, and take care of the make-COMMAND-markup rule.
2) Use the new function to write convert-ly rules
3) Look for any errors caused by the use of the convert-ly rules being
applied
4) When the errors show up, do what is necessary to fix them.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Wed, Aug 12, 2009 at 06:06:01PM -0600, Carl Sorensen wrote: > > On 8/12/09 5:54 PM, "Graham Percival" wrote: > > >convert-ly --from "2.13.3" ... > > (where 2.13.3 is the previous downloadable version) > > > > to the above commands? > > That's what the "-f current-devel-release" part of the commands was; I used > -f instead of --from. Oh, I didn't realize there was a shortcut. Ok then. > > Yes, as far as it goes -- I didn't keep track of the numerous > > discussions about translated docs. What happens to those? > > The snippets in Documentation/snippets/new take precedence over the snippets > in Documentation/snippets. So the translated documents get the new > snippets. I was talking about @lilypond stuff, not snippets. i.e. if Documentation/fr/notation/rhythms.itely contains some old autobeaming stuff requring a NOT_SMART rule, what happens? We can't leave it alone, since that would break compiling. Yes, we try to keep tweaks in the snippets, for almost precisely this reason, but -- so far, at least -- we still have some such material in the main docs. (I'm vaguely considering if changing this should be a goal of GLISS and GDP2, but on second thought I think it would introduce too many headaches when dealing with NR3+ material) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 5:54 PM, "Graham Percival" wrote:
> On Wed, Aug 12, 2009 at 05:43:39PM -0600, Carl Sorensen wrote:
>>
>> Also, we need to recognize that the first commit after running convert-ly on
>> the docs and the snippets will result in changes to every version statement.
>
> Yes. Now, we could just *hope* that there's only one convert-ly
> update for each version, but that would be silly. What about
> adding:
>convert-ly --from "2.13.3" ...
> (where 2.13.3 is the previous downloadable version)
>
> to the above commands?
That's what the "-f current-devel-release" part of the commands was; I used
-f instead of --from.
>
>> Maybe we need to make sure that part of the release of a new development
>> version is to:
>>
>> A. Bump VERSION
>> B. Run convert-ly (there won't be any rules, but it will change all the
>> version statements, so once convert-ly is run on a new snippet and changes
>> it, the proper changes will be tracked in git.
>
> convert-ly only changes version statements if there's a syntax
> change, so this would do nothing.
OK -- no problem them.
>
>
>> Back to update procedure:
>>
>> 3) If convert rule *is* NOT_SMART,
>> A) Manually copy all snippets resulting in NOT_SMART conversion to
>> B) Manually update all of these snippets:
>> C) Run scripts/auxiliar/makelsr.py
>
> Yes, as far as it goes -- I didn't keep track of the numerous
> discussions about translated docs. What happens to those?
The snippets in Documentation/snippets/new take precedence over the snippets
in Documentation/snippets. So the translated documents get the new
snippets.
And when translations are updated, the new translation strings will be added
to the new snippets. So the translated docs are taken care of by this
procedure.
If a snippet is to be removed from the body of the docs (selected snippets),
it should be removed from all languages.
If a snippet is to be removed from inclusion as a "docs" snippet in the LSR,
it should be copied to Documentation/snippets/new and modified (as above) so
that the content reads
\markup {" This snippet is deprecated from Release X.Y.Z. and will be
removed from the documentation."}
There should probably also be a request to the LSR editor (currently Neil or
Valentin, IIRC) to remove the docs tag from that snippet.
I think that has everything accounted for.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Wed, Aug 12, 2009 at 05:43:39PM -0600, Carl Sorensen wrote: > > Also, we need to recognize that the first commit after running convert-ly on > the docs and the snippets will result in changes to every version statement. Yes. Now, we could just *hope* that there's only one convert-ly update for each version, but that would be silly. What about adding: convert-ly --from "2.13.3" ... (where 2.13.3 is the previous downloadable version) to the above commands? > Maybe we need to make sure that part of the release of a new development > version is to: > > A. Bump VERSION > B. Run convert-ly (there won't be any rules, but it will change all the > version statements, so once convert-ly is run on a new snippet and changes > it, the proper changes will be tracked in git. convert-ly only changes version statements if there's a syntax change, so this would do nothing. > Back to update procedure: > > 3) If convert rule *is* NOT_SMART, > A) Manually copy all snippets resulting in NOT_SMART conversion to > B) Manually update all of these snippets: > C) Run scripts/auxiliar/makelsr.py Yes, as far as it goes -- I didn't keep track of the numerous discussions about translated docs. What happens to those? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 4:26 PM, "Graham Percival" wrote: > On Wed, Aug 12, 2009 at 11:31:48AM -0600, Carl Sorensen wrote: >> >> Does it cause problems to edit the snippet and move it to >> Documentation/snippets/new? > > Yes, in that it forces somebody to look at it manually, when no > manual attention is needed. > >> I think it would be best to have one procedure that is always followed; if >> somebody wants to follow the exception, they can. > > The procedure is: > 1) write convert-ly rule. > 2) run convert-ly on the docs (inculding snippets) and regtests. Docs: cd Documentation find . -name '*.itely' | xargs convert-ly -e -f current-devel-release Snippets: cd Documentation/snippets find . -name '*.ly' | xargs convert-ly -e -f current-devel-release Regtests cd input/regression find . -name '*.ly' | xargs convert-ly -e -f current-devel-release I think the -f argument is necessary so that we don't fail to do the conversion if somebody has previously run convert-ly. Also, we need to recognize that the first commit after running convert-ly on the docs and the snippets will result in changes to every version statement. Maybe we need to make sure that part of the release of a new development version is to: A. Bump VERSION B. Run convert-ly (there won't be any rules, but it will change all the version statements, so once convert-ly is run on a new snippet and changes it, the proper changes will be tracked in git. Back to update procedure: 3) If convert rule *is* NOT_SMART, A) Manually copy all snippets resulting in NOT_SMART conversion to Documentation/snippets/new B) Manually update all of these snippets: i) Remove "autogenerated" comments ii) Remove translated info strings iii) Remove "% begin verbatim" comment iv) Make syntax conform with new version v) Verify that all snippets work properly C) Run scripts/auxiliar/makelsr.py > 4) make all; make doc 5) Make test-check 6) If everything is working at this point, push changes Do you agree, or does this need more changes? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Wed, Aug 12, 2009 at 11:31:48AM -0600, Carl Sorensen wrote: > > Does it cause problems to edit the snippet and move it to > Documentation/snippets/new? Yes, in that it forces somebody to look at it manually, when no manual attention is needed. > I think it would be best to have one procedure that is always followed; if > somebody wants to follow the exception, they can. The procedure is: 1) write convert-ly rule. 2) run convert-ly on the docs (inculding snippets) and regtests. 4) make all; make doc Everything should be working at this point. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Wed, Aug 12, 2009 at 09:36:57AM -0700, Mark Polesky wrote: > Carl Sorensen wrote: > > > > When doing a convert-ly rule, do I update snippets/regression tests? > > > > The correct question is: When changing syntax, what do I do besides writing > > a convert-ly rule? > > Okay, that covers the snippet, but what about the regression test? > Do I just update it manually? > Or do I just leave it alone, the idea being that convert-ly is > run on the regression tests anyway? convert-ly is not run automatically on the regtests. After writing the convert-ly rule, run convert-ly on the regtests. This is also a good way to test that your rule works. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Neil Puttock wrote: > LSR turns backslashes in titles into hyphens; perhaps it would be > better if it silently ignored them (which would simplify the migration > of new snippets to LSR when there's a version bump). Yes, that would be better in my opinion. Is that something that Seba would have to change ? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/12 Carl Sorensen : > Does it cause problems to edit the snippet and move it to > Documentation/snippets/new? Not really, but it's redundant. This is precisely why makelsr.py performs a convert-ly run on all the LSR snippets. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/12 Carl Sorensen : > Not as long as you changed every occurrence in the docs and did a git-rename > to the snippet. You'd also need to rename the texidoc translations and remove the `docs' tag from LSR (otherwise we'd end up with two almost identical snippets in the docs). LSR turns backslashes in titles into hyphens; perhaps it would be better if it silently ignored them (which would simplify the migration of new snippets to LSR when there's a version bump). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
command_replace function (was: Re: difference betwwen \pad-around and \pad-markup?)
Carl Sorensen wrote:
> Even better would be to define a function:
> def command_replace(old_command, new_command, str)
> that could then be used in a convert-ly rule
> str = command_replace ("pad-markup", "pad-around", str)
>
> so that in the future you'd never have to worry about dealing
> with word boundaries, etc. This was something Graham asked for
> a couple of months ago, but it never got added. If you wanted
> to do this as part of your project, it would be great.
Yes, the idea was that the python function would add "\\" and "\b"
appropriately, but at least one gotcha has been mentioned (by
Neil):
For each builtin markup-command, the define-builtin-markup-command
macro (line 48 of markup.scm) generates a "make-COMMAND-markup",
which wouldn't be converted if the rule mandates "\\".
I presume that this wouldn't be a big deal to accommodate, but I
have no idea how many other gotchas there are. This one is markup-
specific, but I imagine there are plenty of other similar traps.
Anyone have an idea how to find the other "traps"? Could there be
a systematic approach?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 10:56 AM, "Mark Polesky" wrote: > Also, the snippet filename is > blanking-staff-lines-using-the--whiteout-command.ly > > Would anything break if I fix the double-hyphen? > blanking-staff-lines-using-the-whiteout-command.ly > Not as long as you changed every occurrence in the docs and did a git-rename to the snippet. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
str.replace is probably preferred for this particular example. str.*
functions use less overhead. But really, at the level we're using it in
convert-ly, it doesn't matter.
But you should probably really use something like
str = re.sub (r'\b\\pad-markup\b', r'\\pad-around', str)
Note- I haven't tested this expression, so it may not be right.
The object is to make sure you start the match and end the match on a word
boundary, and to make sure you include the \.
You don't want to change somebody's function call \special-lilypad-markup to
\special-lilypad-around.
Even better would be to define a function:
def command_replace(old_command, new_command, str)
that could then be used in a convert-ly rule
str = command_replace ("pad-markup", "pad-around", str)
so that in the future you'd never have to worry about dealing with word
boundaries, etc. This was something Graham asked for a couple of months
ago, but it never got added. If you wanted to do this as part of your
project, it would be great.
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 10:58 AM, "Neil Puttock" wrote: > 2009/8/12 Carl Sorensen : > >> You copy the snippet from Documentation/snippets to >> Documentation/snippets/new. > > Only if the syntax change can't be handled by convert-ly. > > Since the only change to > `blanking-staff-lines-using-the--whiteout-command.ly' is a simple > renaming, this represents an exception to the usual rule that > autogenerated LSR snippets shouldn't be amended. Assuming Mark's > convert rule works properly, there should be no docs breakage even if > the snippet in LSR isn't changed, since makelsr.py will perform the > conversion itself. Does it cause problems to edit the snippet and move it to Documentation/snippets/new? I think it would be best to have one procedure that is always followed; if somebody wants to follow the exception, they can. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/12/09 10:36 AM, "Mark Polesky" wrote: > Carl Sorensen wrote: > >>> When doing a convert-ly rule, do I update snippets/regression tests? >> >> The correct question is: When changing syntax, what do I do besides writing >> a convert-ly rule? > > Okay, that covers the snippet, but what about the regression test? > Do I just update it manually? In my case, the one involved is > input/regression/whiteout.ly. Do I do: > > \version "2.12.0" -> \version "2.13.4" > "\pad-markup" -> "\pad-around" > > Or do I just leave it alone, the idea being that convert-ly is > run on the regression tests anyway? I think you *need* to update the regression test to make sure that your patch has worked. You should never push a patch without verifying that the regression tests work. > > Sorry if I'm being dense. No, you're being careful. I appreciate it. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Neil Puttock wrote: > > You copy the snippet from Documentation/snippets to > > Documentation/snippets/new. > > Only if the syntax change can't be handled by convert-ly. Okay, so I simply leave it alone? What about the regression test? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/12 Carl Sorensen : > You copy the snippet from Documentation/snippets to > Documentation/snippets/new. Only if the syntax change can't be handled by convert-ly. Since the only change to `blanking-staff-lines-using-the--whiteout-command.ly' is a simple renaming, this represents an exception to the usual rule that autogenerated LSR snippets shouldn't be amended. Assuming Mark's convert rule works properly, there should be no docs breakage even if the snippet in LSR isn't changed, since makelsr.py will perform the conversion itself. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Also, the snippet filename is blanking-staff-lines-using-the--whiteout-command.ly Would anything break if I fix the double-hyphen? blanking-staff-lines-using-the-whiteout-command.ly - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Carl Sorensen wrote: > > When doing a convert-ly rule, do I update snippets/regression tests? > > The correct question is: When changing syntax, what do I do besides writing > a convert-ly rule? Okay, that covers the snippet, but what about the regression test? Do I just update it manually? In my case, the one involved is input/regression/whiteout.ly. Do I do: \version "2.12.0" -> \version "2.13.4" "\pad-markup" -> "\pad-around" Or do I just leave it alone, the idea being that convert-ly is run on the regression tests anyway? Sorry if I'm being dense. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Which one of these is preferred?
str = str.replace ("pad-markup", "pad-around")
str = re.sub ('pad-markup', 'pad-around', str)
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
John Mandereau wrote: > If you think about it more than a second, you can hardly cause trouble > by modifying a few lines of ly snippets in translated documentation > files. Well, I could imagine causing trouble by omitting some step that I don't know about... like when I didn't know about adding a @funindex entry when I added the \f command. Oh right - I still need to do that. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Carl Sorensen wrote: > This should be in the CG but isn't. Graham summarized this earlier, but I > couldn't find the message. > > You copy the snippet from Documentation/snippets to > Documentation/snippets/new. > > > You eliminate the comment at the top that says "This snippet was > automatically generated" > > You eliminate the foreign language translations of the texidoc. > > You eliminate the comment that says % begin verbatim. > > Then you run convert-ly on that snippet, to verify the convert-ly rule > works. > > Now, the next time somebody does makelsr.py, it will be copied back to > Documentation/snippets from Documentation/snippets/new, with all of the > other stuff automagically generated. > > And if makelsr.py hasn't been done, LilyPond will get the snippet from > Documentation/snippets/new instead of Documentation/snippets. I guess this is kind of stated in CG 8.7, but your explanation is a lot clearer. Would you be interested in adding to or rewording CG 8.7? Thanks for you help. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On 8/11/09 8:30 PM, "Mark Polesky" wrote: > > > When doing a convert-ly rule, do I update snippets/regression tests? The correct question is: When changing syntax, what do I do besides writing a convert-ly rule? The proper answer is: You apply it to the snippets to make sure it works. This should be in the CG but isn't. Graham summarized this earlier, but I couldn't find the message. You copy the snippet from Documentation/snippets to Documentation/snippets/new. You eliminate the comment at the top that says "This snippet was automatically generated" You eliminate the foreign language translations of the texidoc. You eliminate the comment that says % begin verbatim. Then you run convert-ly on that snippet, to verify the convert-ly rule works. Now, the next time somebody does makelsr.py, it will be copied back to Documentation/snippets from Documentation/snippets/new, with all of the other stuff automagically generated. And if makelsr.py hasn't been done, LilyPond will get the snippet from Documentation/snippets/new instead of Documentation/snippets. HTH, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
When doing a convert-ly rule, do I update snippets/regression tests? These two pop up with "grep pad-markup": Documentation/snippets/blanking-staff-lines-using-the--whiteout-command.ly input/regression/whiteout.ly What should I do with these? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le mardi 11 août 2009 à 21:01 +0100, Neil Puttock a écrit : > 2009/8/11 John Mandereau : > > > Why don't you just convert-ly docs after having written the convert-ly > > rule and compiled convert-ly? > > Is this possible on Windows? (I've never tried it myself). It should be doable in theory, as convert-ly only needs Python. However, our current build system based on autoconf and make doesn't make it easy... yet another reason to switch to SCons. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/11 John Mandereau : > Why don't you just convert-ly docs after having written the convert-ly > rule and compiled convert-ly? Is this possible on Windows? (I've never tried it myself). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Le mardi 11 août 2009 à 10:45 -0700, Mark Polesky a écrit : > When grepping for pad-markup, two hits are from translated docs. > Do I just silently modify them, or do I need to notify the > translators? Why don't you just convert-ly docs after having written the convert-ly rule and compiled convert-ly? > Skimming through CG 3.7.4, it mentions running "make > check-translation"... can I do that on Windows? If git binary is in your PATH, it may work. > And do I need to > update documentation PO for such a small change? No, I usually take care of doing this. Nowadays doc PO generation is no longer valid, so the next update will have to wait a bit. > Sorry if these are annoying questions. If the answers are simple, > maybe a short node could be added to CG 3.4 "Documentation > policy". Something like "Updating translations". I don't want to > accidentally cause trouble, I guess. If you think about it more than a second, you can hardly cause trouble by modifying a few lines of ly snippets in translated documentation files. I'll add some blurb about translation management by non-translators in the CG, as they frequently ask about these, and are not aware that it's rather too few porting of changes in English docs into translations that is annoying for translators, e.g. when .itely files are moved from one manual to another. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/11 Mark Polesky : > When grepping for pad-markup, two hits are from translated docs. > Do I just silently modify them, or do I need to notify the > translators? Modifying them is OK, as long as you don't change any non-snippet documentation (see CG 8.7.3, `Write documentation') You could run update-snippets.py after amending the corresponding snippet in the english docs, but it's probably simpler just to edit the files manually (you'll have to change the index entries anyway). > Skimming through CG 3.7.4, it mentions running "make > check-translation"... can I do that on Windows? And do I need to > update documentation PO for such a small change? None of this is necessary (or desirable). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Now that I'm a pusher again, I'm trying to return to unfinished projects. I'm looking again at the pad-markup->pad-around conversion and I have a question. I remember discussing this before, but I couldn't find it in the archives. When grepping for pad-markup, two hits are from translated docs. Do I just silently modify them, or do I need to notify the translators? Skimming through CG 3.7.4, it mentions running "make check-translation"... can I do that on Windows? And do I need to update documentation PO for such a small change? Sorry if these are annoying questions. If the answers are simple, maybe a short node could be added to CG 3.4 "Documentation policy". Something like "Updating translations". I don't want to accidentally cause trouble, I guess. Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
On Sat, Aug 01, 2009 at 09:27:54AM -0700, Mark Polesky wrote: > > Mark Polesky wrote: > > > These are things I've not done before, but perhaps I'll give it a > > try! > > Okay, looking at earlier rules for guidance, I'm surprised to see so > many different formats for this. Here are some examples that I see > that I thought might > be similar to the convert-rule in question: Like many issues, it's already been discussed: http://code.google.com/p/lilypond/issues/detail?id=788&q=label%3AMaintainability We *really* need a contributor who knows a little python, or one who's willing to learn a little python. Honestly, this stuff is *not* hard. Python is one of the easiest languages to learn, and text editing is one of its main strengths. As temporary measure, I recommend doing "\\oldCommand\b" -> "\\newComand" Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/1 Valentin Villenave : > I'd use the last one. The first one is probably deprecated now. Neil, > thoughts? I think it's OK in this case; if we use the last rule, we'll have to add another for `make-pad-markup-markup'. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/1 Mark Polesky :
>
> Mark Polesky wrote:
>
>> > Mark, do you want to take care of removing the \pad-markup command?
>> > Please remember to add a convert-ly rule, and a NEWS item.
>>
>> These are things I've not done before, but perhaps I'll give it a
>> try!
>
> Okay, looking at earlier rules for guidance, I'm surprised to see so
> many different formats for this. Here are some examples that I see
> that I thought might
> be similar to the convert-rule in question:
>
> str = str.replace ("setHairpinDim", "dimHairpin")
If the conversion is likely to be unambiguous, this is the simplest
method: it's highly unlikely this rule will generate a false match.
> str = re.sub (r"([\\:]+)center-align", r"\1center-column", str)
There are several places in the docs where `center-align' shouldn't be
converted to `center-column' (e.g., comments in snippets); this rule
ensures only markup commands are picked up (backslashed or #:).
> str = re.sub (r"hcenter(\s+)", r"center-align\1", str)
This rule expects a space after `hcenter' to prevent \hcenter-in from
being converted (though it doesn't account for make-hcenter-markup).
> str = str.replace ("pad-markup", "pad-around")
I think this will be fine, since `pad-markup' is unlikely to be found
outside its present usage; it also picks up #:pad-markup and
`make-pad-markup-markup'. :)
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/8/1 Mark Polesky :
>> These are things I've not done before, but perhaps I'll give it a
>> try!
Precisely, it's a good opportunity for you to learn :-) Feel free to
send me a link to your committish if you want me to review your work.
> Okay, looking at earlier rules for guidance, I'm surprised to see so
> many different formats for this. Here are some examples that I see
> that I thought might
> be similar to the convert-rule in question:
>
> str = str.replace ("setHairpinDim", "dimHairpin")
> str = re.sub (r"([\\:]+)center-align", r"\1center-column", str)
> str = re.sub (r"hcenter(\s+)", r"center-align\1", str)
> str = re.sub (r"([\\:])bigger", r"\1larger", str)
>
> Are some of these better than others? Should some of these be changed?
> I can guess what they all mean, but I don't know python, so I'll ask
> someone to recommend one of the following (preferably with a little
> explanation for future reference).
>
> str = str.replace ("pad-markup", "pad-around")
> str = re.sub (r"pad-markup(\s+)", r"pad-around\1", str)
> str = re.sub (r"([\\:])pad-markup", r"\1pad-around", str)
> str = re.sub (r"([\\:]+)pad-markup", r"\1pad-around", str)
I'd use the last one. The first one is probably deprecated now. Neil, thoughts?
Mark, don't forget to search through the source code for any file that
use the \pad-markup command:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git&a=search&h=HEAD&st=grep&s=pad-markup
And please add a NEWS item so we we can go "RTF-NEWS-page" if any user
complaints about the command having been removed :-)
Regards,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Mark Polesky wrote:
> > Mark, do you want to take care of removing the \pad-markup command?
> > Please remember to add a convert-ly rule, and a NEWS item.
>
> These are things I've not done before, but perhaps I'll give it a
> try!
Okay, looking at earlier rules for guidance, I'm surprised to see so
many different formats for this. Here are some examples that I see
that I thought might
be similar to the convert-rule in question:
str = str.replace ("setHairpinDim", "dimHairpin")
str = re.sub (r"([\\:]+)center-align", r"\1center-column", str)
str = re.sub (r"hcenter(\s+)", r"center-align\1", str)
str = re.sub (r"([\\:])bigger", r"\1larger", str)
Are some of these better than others? Should some of these be changed?
I can guess what they all mean, but I don't know python, so I'll ask
someone to recommend one of the following (preferably with a little
explanation for future reference).
str = str.replace ("pad-markup", "pad-around")
str = re.sub (r"pad-markup(\s+)", r"pad-around\1", str)
str = re.sub (r"([\\:])pad-markup", r"\1pad-around", str)
str = re.sub (r"([\\:]+)pad-markup", r"\1pad-around", str)
Thanks.
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Valentin Villenave wrote: > Mark, do you want to take care of removing the \pad-markup command? > Please remember to add a convert-ly rule, and a NEWS item. These are things I've not done before, but perhaps I'll give it a try! - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
2009/7/30 Mark Polesky : > Nice catch. The scheme code for both is functionally identical. > There is no difference. One should be deprecated. I prefer to > keep pad-around since it is more descriptive. Using "markup" in > a markup command name is redundant anyway. Are there any other > markup command names that contain the word "markup"? Not that I can see. Mark, do you want to take care of removing the \pad-markup command? Please remember to add a convert-ly rule, and a NEWS item. Regards, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
> I prefer to keep pad-around since it is more descriptive. OK. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: difference betwwen \pad-around and \pad-markup?
Werner LEMBERG wrote: > Is there a difference between \pad-around and \pad-markup? Reading > the documentation and looking at the examples, I can't see any. In > case there are differences, this should be documented. Otherwise I > suggest to mark one of the two commands as deprecated. Nice catch. The scheme code for both is functionally identical. There is no difference. One should be deprecated. I prefer to keep pad-around since it is more descriptive. Using "markup" in a markup command name is redundant anyway. Are there any other markup command names that contain the word "markup"? - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
