Sorry that I took so long to answer. I was very busy. Am 07.07.2016 um 18:37 schrieb Richard Shann: > On Tue, 2016-07-05 at 21:19 +0200, Andreas Schneider wrote: >> Am 05.07.2016 um 10:41 schrieb Richard Shann: >>> On Sun, 2016-07-03 at 20:14 +0200, Andreas Schneider wrote: >>>> Thank you for creating an advanced version of the command. In most cases >>>> it works really well. >>>> >>>> There are a few small things I noticed: >>>> * If you put the end at the same movement as the beginning it does not >>>> work. (A chapter with only one movement may sometimes be needed.) >>> >>> If I understand correctly there is no need for this, you just leave that >>> movement alone, giving it a title. It makes the single-movement book a >>> bit irregular but was easier to deal with. >> >> For me, chapters group movements of a special type. Sometimes there may >> be only one movement of a certain type. > > Yes, that is the logical way to have things. Does the attached file give > the desired output though? It has three chapters the middle one being of > only one movement. Just done with Book Chapter, (and Score->Simple > Titles->Title for the singleton chapter).
No, this is not my desired output because normally each movement has a title. At the start of a chapter there is first the chapter title (preferably in a larger font) and then the movement title. >> For the first movement in a >> chapter there is first the heading of the chapter and then the heading >> of the movement, regardless if the given chapter contains one or more >> movement(s). >> I am thinking about how one can overcome the restriction that a chapter >> cannot end at the same movement where it starts. >> First of all, your >> solution is clever because it does not need a reference (e.g. to the >> movement number where the end is) that may void if movements are >> inserted or deleted, and because it automatically prevents starting a >> chapter where a chapter end is already present. At the moment you cannot >> begin and end a chapter at the same movement because you use the same >> tag for both begin and end. > > Well, no actually you *can* have begin and end on the same movement - > you could have a single Denemo Directive with the tag SimpleChapter but > with both prefix and postfix fields filled in for the end and start of > chapter respectively. You could test for this case (you get #f for a > field that isn't filled in) and write the script to handle that. Your idea is more elegant than mine. So this should be the way to go. >> When using a different tag, that restriction >> would not be present any longer. Is there a directive to get the number >> of movements in a score? > I don't think so - it is (d-PushPosition)(while (d-NextMovement))(set! > number-of-movements (d-GetMovement))(d-PopPosition). >> Maybe I can come up with some code. Or do you >> think that approach is not wise? > > The advantage of using a single tag is that it can be (and is in this > case) the name of the command, and so the user can re-run the command in > the Movement Properties Editor. Directives that have a tag that isn't a > command name are more difficult for the user to work with - Denemo > doesn't know what command created them and can't give any guidance about > them. There *is* a mechanism to mitigate this - you can write an > "editscript" named after the tag and put that in the actions/editscripts > directory, but I think that is over elaborate. I see, I did not think of that. >>>> * If you give an end movement number that is larger than the number of >>>> movements and thus does not exist, the script does an infinite loop. In >>>> that case the end movement should be set to the last present movement >>>> and a warning be given. >>> >>> I've fixed this. >>> >>>> * If you give an end movement that is before the start movement, the >>>> lilypond code is erroneous. That should be checked and an error message >>>> given. For example before line 32: (if (< end (d-GetMovement)) >>>> (d-InfoDialog "Chapter end cannot be before chapter start!") (begin ... )) >>> >>> that fix also prevents bad code generation in this case >> >> I suggest to give a message to the user in this case, e.g. by inserting >> (d-WarningDialog (string-append (_ "Invalid movement number: ") end )) >> as else branch of the (if ...) starting in line 28. >> >>>> * The end movement cannot be changed. (This becomes important if one >>>> insert a movement at the end of a chapter.) If you click on EndChapter, >>>> you just get an information dialog. It would be more convenient be told >>>> the movement number where the corresponding start is and given the >>>> option to move the EndChapter to another movement. Workaround is to >>>> delete and re-insert. >>> >>> Hmm, it seems you have to delete the start as well as the end and the >>> re-instate. > > actually, there should be a cleverer way - you make a button that will > create a clone of the End Chapter, then delete that End Chapter, move to > the movement where you want the end to go and use the button to > reinstate the End Chapter in the new position. That sounds like a good possibility. However, it also sounds like a lot of work for which I don't have the time right now. Andreas _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
