Re: Shortcut for \repeat unfold
Hi,
In short, I propose to make the first argument to
\repeat optional, making \repeat n music equivalent to
\repeat unfold n music.
Thanks for working on that!
The issue I have with your idea is that to me, \repeat unfold and
\repeta volta/tremolo have slightly different semantics:
\repeat volta and \repeat tremolo create "time-honored" visual
indicators for repeated music, so they are commands that correspond to
special music layouts.
\repeat unfold saves typing while inputting music.
Of course, the distinction is not very strict, in particular since
there's \unfoldRepeats. But still I'm not sure it's ideal syntax-wise if
users have to use the same command for "saving typing" and for "creating
musical repeat signs / tremolo notation". And this, I think, is
exacerbated with your suggestion, because if \repeat alone is the
keystroke-saving command, then \repeat volta and \repeat tremolo look
like variants of that: Adding a qualifier turns the command into
something completely different.
My experience is that every time I want to repeat a note
four times, I have a half-a-second wonder about whether
typing "\repeat unfold" will be shorter than cut-and-paste.
Absolutely. Of course it depends on which type of music you engrave, but
in my "common practice"-heavy everyday work, \repeat unfold 16 d8 comes
up _very_ often.
Other possibilities:
- "\rep n music", not as self-telling (and I think Lukas
only calls his shortcut \rep because redefining \repeat
is not syntactically valid);
... 'n 'cause it's even shrtr. :-)
- "music * n", attractive but the difference between c1*5
and { c1 } * 5 would be confusing; also, for longer passages
one would rather state the number of repetitions from the
start than having to remember to put it at the end;
Yes, that is confusing to a degree I'm very skeptical if it's possible
at all. You've already given the main example.
- "\* n music", very short but doesn't read as nicely I think,
and I don't view repeats as special enough to warrant
this kind of syntax with many special characters.
I think I disagree. After David suggested it in the gitlab thread, I
used it in some scores and found it to be very convenient. (Maybe I'm
biased because on german keybaord layout, \* can be entered in a single
movement with a quite enjoyable thumb-midde-finger-pinkie-ring-finger
flourish :-).) Also, brevity is key for keystroke-saving commands.
But your special-character argument made me think: Maybe it would be
possible to get rid of the * sign? Maybe I'm missing something, but
isn't \{unsigned int} still "available" so one could do \16 d8 instead
of \*16 d8 ? Of course, probably only David K. can say for sure what
implications that would have for parasing/lexing.
Aaron:
If the asterisk feels overloaded, you could use the multiplication sign:
\version "2.22.0"
× = % U+00D7
I'd advise against introducing non-ASCII commands. Users won't be happy
if they can't find on their keyboards what the documentation instructs
them to type.
Lukas
Re: Shortcut for \repeat unfold
On 25/09/2021 08:46, Lukas-Fabian Moser wrote: Absolutely. Of course it depends on which type of music you engrave, but in my "common practice"-heavy everyday work, \repeat unfold 16 d8 comes up _very_ often. Just as a counter-point, while I'm a light user / copyist, I don't think I've EVER used repeat unfold, while repeat percent happens a lot. I actually quite like the "\x16 d8" idea as a shortcut, but what I'm saying is don't think it's a good idea, just because YOU do it a lot. Other people may have completely different work patterns ... Cheers, Wol
Re: Shortcut for \repeat unfold
What about using '**' to indicate repetition? Other programming
languages use '**' to indicate exponentiation, thus the analogy to
repetition wouldn't be too far-fetched.
c'*2*0.5 ** 5
{ c'2 d } ** 4
No idea whether this is easily doable in LilyPond's grammar.
Werner
Re: Shortcut for \repeat unfold
Just as a counter-point, while I'm a light user / copyist, I don't think I've EVER used repeat unfold, while repeat percent happens a lot. I actually quite like the "\x16 d8" idea as a shortcut, but what I'm saying is don't think it's a good idea, just because YOU do it a lot. Other people may have completely different work patterns ... Yes of course, and LilyPond is a great tool for all different kinds of work patterns. But it's not a question of making one job easier for the price of making others harder, in which case your argument would be more relevant. To give an example: The fact that I never (so far) needed/used guitar tabulature isn't an argument against improving work experience for people who do. As long as no-one proposes syntax changes that make guitar tabulature easier and figured bass harder, I'm very happy if the support for guitar tabulature improves. Lukas
Re: Shortcut for \repeat unfold
Lukas-Fabian Moser writes:
> But your special-character argument made me think: Maybe it would be
> possible to get rid of the * sign? Maybe I'm missing something, but
> isn't \{unsigned int} still "available" so one could do \16 d8 instead
> of \*16 d8 ? Of course, probably only David K. can say for sure what
> implications that would have for parasing/lexing.
Guitarists (among other string instrument players) would likely object
to losing string number specifications.
--
David Kastrup
Re: Shortcut for \repeat unfold
But your special-character argument made me think: Maybe it would be
possible to get rid of the * sign? Maybe I'm missing something, but
isn't \{unsigned int} still "available" so one could do \16 d8 instead
of \*16 d8 ? Of course, probably only David K. can say for sure what
implications that would have for parasing/lexing.
Guitarists (among other string instrument players) would likely object
to losing string number specifications.
I _knew_ I was missing something. Thanks.
(I stupidly only tried { \4 c' }. Even { \4 c' \4 d' } would have been
enough to remind me of string numbers.)
Lukas
Re: Shortcut for \repeat unfold
IS unfold the best candidate? Just because the OP makes extensive use
of it, doesn't mean everyone else does. I'd rather it was percent, but
I suspect I genuinely am a minority.
One of the reasons I argue against making \repeat $n \music equivalent
to some \repeat X $n \music.
An implementation that doesn't require changes in the lexer/parser would
have the advantage of allowing you to re-define it according to your
needs. LilyPond is so great it even allows you to do:
\version "2.22"
repeat-shorthand = unfold
"\*" =
#(define-music-function (n mus) (index? ly:music?)
#{ \repeat $repeat-shorthand $n { #mus } #})
{
\*8 c'4
#(set! repeat-shorthand "percent")
\*8 d'4
#(set! repeat-shorthand "tremolo")
\*8 e'16
e'2
#(set! repeat-shorthand "volta")
\*2 { f'4 e' d' c' }
}
But I expect also Jean's way of re-defining \repeat would allow for such
a configurable option.
But what if more people would benefit if that tweak were applied to
figured bass, rather than tablature?
Then we should find a way to make both happen (or let the user select
according to their needs). :-)
Lukas
Re: Shortcut for \repeat unfold
On 2021-09-25 12:46 am, Lukas-Fabian Moser wrote: Aaron: If the asterisk feels overloaded, you could use the multiplication sign: \version "2.22.0" × = % U+00D7 I'd advise against introducing non-ASCII commands. Users won't be happy if they can't find on their keyboards what the documentation instructs them to type. I guess my sarcasm indicator got lost in shipment. What one should have taken away from my post was that \x was the viable alternative to \*, not the multiplication sign (which is ASCII, by the by; just not commonly found on keyboard layouts). -- Aaron Hill
Re: Shortcut for \repeat unfold
Aaron Hill writes: > On 2021-09-25 12:46 am, Lukas-Fabian Moser wrote: >> Aaron: >> >>> If the asterisk feels overloaded, you could use the multiplication >>> sign: >>> >>> \version "2.22.0" >>> × = % U+00D7 >> I'd advise against introducing non-ASCII commands. Users won't be >> happy if they can't find on their keyboards what the documentation >> instructs them to type. > > I guess my sarcasm indicator got lost in shipment. What one should > have taken away from my post was that \x was the viable alternative to > \*, not the multiplication sign (which is ASCII, by the by; just not > commonly found on keyboard layouts). ASCII is a 7-bit encoding; U+00D7 is certainly not within its range. -- David Kastrup
Re: Shortcut for \repeat unfold
On 2021-09-25 5:11 am, David Kastrup wrote: Aaron Hill writes: On 2021-09-25 12:46 am, Lukas-Fabian Moser wrote: Aaron: If the asterisk feels overloaded, you could use the multiplication sign: \version "2.22.0" × = % U+00D7 I'd advise against introducing non-ASCII commands. Users won't be happy if they can't find on their keyboards what the documentation instructs them to type. I guess my sarcasm indicator got lost in shipment. What one should have taken away from my post was that \x was the viable alternative to \*, not the multiplication sign (which is ASCII, by the by; just not commonly found on keyboard layouts). ASCII is a 7-bit encoding; U+00D7 is certainly not within its range. *was*. ASCII has been 8-bit for quite some time. Still, be pedantic and miss the forest for the trees, my point was that \x is a good option if \* was going to be problematic. -- Aaron Hill
Re: Shortcut for \repeat unfold
Aaron Hill writes: > On 2021-09-25 5:11 am, David Kastrup wrote: >> Aaron Hill writes: >> >>> On 2021-09-25 12:46 am, Lukas-Fabian Moser wrote: Aaron: > If the asterisk feels overloaded, you could use the multiplication > sign: > > \version "2.22.0" > × = % U+00D7 I'd advise against introducing non-ASCII commands. Users won't be happy if they can't find on their keyboards what the documentation instructs them to type. >>> I guess my sarcasm indicator got lost in shipment. What one should >>> have taken away from my post was that \x was the viable alternative to >>> \*, not the multiplication sign (which is ASCII, by the by; just not >>> commonly found on keyboard layouts). >> ASCII is a 7-bit encoding; U+00D7 is certainly not within its range. > > *was*. ASCII has been 8-bit for quite some time. https://en.wikipedia.org/wiki/ASCII > Still, be pedantic and miss the forest for the trees, my point was > that \x is a good option if \* was going to be problematic. Sure, but the problem with \× is exactly that × is not part of ASCII and thus does not uniformly work on extended ASCII encodings (of which the non-8-bit UTF-8 encoding that LilyPond uses for representing code points in the Latin-1 specific subrange of Unicode is only one). -- David Kastrup
Re: Shortcut for \repeat unfold
Le 25/09/2021 à 14:44, David Kastrup a écrit : Aaron Hill writes: Still, be pedantic and miss the forest for the trees, my point was that \x is a good option if \* was going to be problematic. Sure, but the problem with \× is exactly that × is not part of ASCII and thus does not uniformly work on extended ASCII encodings (of which the non-8-bit UTF-8 encoding that LilyPond uses for representing code points in the Latin-1 specific subrange of Unicode is only one). You did realize that Aaron talked about the good option being \x and not \×?
Re: Shortcut for \repeat unfold
On 25/09/2021 10:19, Lukas-Fabian Moser wrote: Just as a counter-point, while I'm a light user / copyist, I don't think I've EVER used repeat unfold, while repeat percent happens a lot. I actually quite like the "\x16 d8" idea as a shortcut, but what I'm saying is don't think it's a good idea, just because YOU do it a lot. Other people may have completely different work patterns ... Yes of course, and LilyPond is a great tool for all different kinds of work patterns. But it's not a question of making one job easier for the price of making others harder, in which case your argument would be more relevant. But is it a case of making a niche case easier, when the same trick could be used instead (mutually exclusive) to make the common case easier? IS unfold the best candidate? Just because the OP makes extensive use of it, doesn't mean everyone else does. I'd rather it was percent, but I suspect I genuinely am a minority. To give an example: The fact that I never (so far) needed/used guitar tabulature isn't an argument against improving work experience for people who do. As long as no-one proposes syntax changes that make guitar tabulature easier and figured bass harder, I'm very happy if the support for guitar tabulature improves. But what if more people would benefit if that tweak were applied to figured bass, rather than tablature? Cheers, Wol
Re: Shortcut for \repeat unfold
Jean Abou Samra writes: > Le 25/09/2021 à 14:44, David Kastrup a écrit : >> Aaron Hill writes: >>> Still, be pedantic and miss the forest for the trees, my point was >>> that \x is a good option if \* was going to be problematic. >> Sure, but the problem with \× is exactly that × is not part of ASCII and >> thus does not uniformly work on extended ASCII encodings (of which the >> non-8-bit UTF-8 encoding that LilyPond uses for representing code points >> in the Latin-1 specific subrange of Unicode is only one). > > You did realize that Aaron talked about the good option being \x and not \×? You did realize that Aaron previously to \x declared \× to be an option, stating that code point D7 was part of ASCII, then insisted that the ASCII standard magically switched to becoming 8 bit at some point of time? -- David Kastrup
Re: Shortcut for \repeat unfold
Le 25/09/2021 à 09:46, Lukas-Fabian Moser a écrit :
Hi,
In short, I propose to make the first argument to
\repeat optional, making \repeat n music equivalent to
\repeat unfold n music.
Thanks for working on that!
The issue I have with your idea is that to me, \repeat unfold and
\repeta volta/tremolo have slightly different semantics:
\repeat volta and \repeat tremolo create "time-honored" visual
indicators for repeated music, so they are commands that correspond to
special music layouts.
\repeat unfold saves typing while inputting music.
Of course, the distinction is not very strict, in particular since
there's \unfoldRepeats. But still I'm not sure it's ideal syntax-wise
if users have to use the same command for "saving typing" and for
"creating musical repeat signs / tremolo notation". And this, I think,
is exacerbated with your suggestion, because if \repeat alone is the
keystroke-saving command, then \repeat volta and \repeat tremolo look
like variants of that: Adding a qualifier turns the command into
something completely different.
The musical validity of this approach might
be questionable, but LilyPond thinks of these
types of repeats in similar ways. \repeat unfold
does not copy the music n times, it just wraps it
in UnfoldedRepeatedMusic.
It would make reasonable sense to write a function
changing unfold to another repeat type, like
\version "2.23.4"
unfoldToPercent =
#(define-music-function (music) (ly:music?)
(music-map
(lambda (m)
(if (music-is-of-type? m 'unfolded-repeated-music)
(make-music 'PercentRepeatedMusic m)
m))
music))
var = \repeat unfold 4 \relative { c'8 g' c g }
{ \var }
\unfoldToPercent \var
So I do view these kinds of repeats similar enough
to warrant similar syntax.
I think it's a trap to see \repeat unfold as syntactic
sugar for repeating a sequence of characters n times
in the input. For instance,
\relative { \repeat unfold 4 c'1 }
is not the same as
\relative { c'1 c'1 c'1 c'1 }
My experience is that every time I want to repeat a note
four times, I have a half-a-second wonder about whether
typing "\repeat unfold" will be shorter than cut-and-paste.
Absolutely. Of course it depends on which type of music you engrave,
but in my "common practice"-heavy everyday work, \repeat unfold 16 d8
comes up _very_ often.
Other possibilities:
- "\rep n music", not as self-telling (and I think Lukas
only calls his shortcut \rep because redefining \repeat
is not syntactically valid);
... 'n 'cause it's even shrtr. :-)
- "music * n", attractive but the difference between c1*5
and { c1 } * 5 would be confusing; also, for longer passages
one would rather state the number of repetitions from the
start than having to remember to put it at the end;
Yes, that is confusing to a degree I'm very skeptical if it's possible
at all. You've already given the main example.
- "\* n music", very short but doesn't read as nicely I think,
and I don't view repeats as special enough to warrant
this kind of syntax with many special characters.
I think I disagree. After David suggested it in the gitlab thread, I
used it in some scores and found it to be very convenient. (Maybe I'm
biased because on german keybaord layout, \* can be entered in a
single movement with a quite enjoyable
thumb-midde-finger-pinkie-ring-finger flourish :-).) Also, brevity is
key for keystroke-saving commands.
Keyboards may be an important factor. Part of my
dislike for \* comes from the fact that on French
keyboards, the backslash is farther to the left,
on the same key as 8, making it less convenient
than what you describe.
They are not the only factor though. Let's see how
it looks visually:
{ c'1 \repeat 5 dis'8-_ c'1 }
{ c'1 \x 5 dis'8-_ c'1 }
{ c'1 \* 8 dis'8-_ c'1 }
{ c'1 dis'8-_**8 c'1 }
With \x or \*, I find it harder to discern the structure.
They are so small that they seem sprinkled over the input
without grouping other elements -- the third one in
particular looks like \* is some shortcut and 8 is
a duration repeating the previous pitch as in { c'1 8 }.
I said \repeat unfold was overly long, but that is not
to say that we should try to squeeze the command in as
few characters as possible ;-) Syntax readability matters
a lot to me, for editing scores after writing, for
communication on mailing lists, and just to navigate
in the input.
I like Werner's suggestion with ** better already.
What worries me a bit is the difference with the
existing use of *, which might be confusing. R1*5
will be (most of the time) equivalent to R1**5,
whereas c'1*5 will not be the same as c'1**5.
Something like c'1\p**5 will be valid, contrary to
c'1\p*5; c'1*4/5 will work but not c'1**4/5; …
I have to think about it a bit more.
Just as a counter-point, while I'm a light user / copyist, I don't
think I've EVER used repeat unfold, while repeat percent happens a lot.
I actually quite like the "\x16 d8" idea as a shortcut, but wha
Re: Shortcut for \repeat unfold
Jean Abou Samra writes: > Le 25/09/2021 à 09:46, Lukas-Fabian Moser a écrit : >> Hi, >> >>> In short, I propose to make the first argument to >>> \repeat optional, making \repeat n music equivalent to >>> \repeat unfold n music. >> >> Thanks for working on that! >> >> The issue I have with your idea is that to me, \repeat unfold and >> \repeta volta/tremolo have slightly different semantics: >> >> \repeat volta and \repeat tremolo create "time-honored" visual >> indicators for repeated music, so they are commands that correspond >> to special music layouts. >> \repeat unfold saves typing while inputting music. >> >> Of course, the distinction is not very strict, in particular since >> there's \unfoldRepeats. But still I'm not sure it's ideal >> syntax-wise if users have to use the same command for "saving >> typing" and for "creating musical repeat signs / tremolo >> notation". And this, I think, is exacerbated with your suggestion, >> because if \repeat alone is the keystroke-saving command, then >> \repeat volta and \repeat tremolo look like variants of that: Adding >> a qualifier turns the command into something completely different. > > The musical validity of this approach might > be questionable, but LilyPond thinks of these > types of repeats in similar ways. \repeat unfold > does not copy the music n times, it just wraps it > in UnfoldedRepeatedMusic. It's worth remembering that \repeat unfold , like all \repeat variants, accepts an \alternative clause. And will probably be able to heed it. I am not sure whether \repeat percent does so, but actually interspersing material like <>\< <>\p or so would be perfectly legitimate uses. Whether they make for great syntax is a different question... -- David Kastrup
Re: Shortcut for \repeat unfold
"\*" =
#(define-music-function (n mus) (index? ly:music?)
#{ \repeat $repeat-shorthand $n { #mus } #})
Instead of debating a default repeat type and function, why not provide access
to repetition as a music function with a clear name like
\repeatFunction type n music
And let the user decide how to abbreviate it?
x = \repeatFunction unfold \etc
Maybe it helps to give some context: The discussion started with the
problem of skipping notes in lyrics (using \addlyrics {} / \lyricsto {})
in the documentation. In order to skip multiple notes, the documentation
currently suggests ugly things like
\repeat unfold 2 { \skip 1 }
that
a) are very cumbersome,
b) contain a mandatory-yet-unused duration argument.
I think b) can be remedied by using "" instead of the skip (I'm not sure
yet if it's really equivalent), which leads to
\repeat unfold 2 ""
And I think it would be nice to have an even more natural variant for
that; I think it's reasonable to provide & show/recommend convenient
solutions for standard tasks (rather than say "you can define your own
abbreviation here if you know how to do so") - for example,
\*2 "" or \x2 ""
which would be my favourite.
Lukas
Re: Shortcut for \repeat unfold
Hi Jean,
I think it's a trap to see \repeat unfold as syntactic
sugar for repeating a sequence of characters n times
in the input. For instance,
\relative { \repeat unfold 4 c'1 }
is not the same as
\relative { c'1 c'1 c'1 c'1 }
Yes, of course. But I'd be very surprised if a large percentage of
relative mode users would really expect "f4., g8 an then four times c,8"
really to produce \relative { c, c, c, c, }. (Maybe those with a
background in computer science would :-).)
So, when I talked about "syntactic sugar" I didn't mean the literal
character-copy-and-paste sense.
Keyboards may be an important factor. Part of my
dislike for \* comes from the fact that on French
keyboards, the backslash is farther to the left,
on the same key as 8, making it less convenient
than what you describe.
They are not the only factor though. Let's see how
it looks visually:
{ c'1 \repeat 5 dis'8-_ c'1 }
{ c'1 \x 5 dis'8-_ c'1 }
{ c'1 \* 8 dis'8-_ c'1 }
{ c'1 dis'8-_**8 c'1 }
With \x or \*, I find it harder to discern the structure.
They are so small that they seem sprinkled over the input
without grouping other elements -- the third one in
particular looks like \* is some shortcut and 8 is
a duration repeating the previous pitch as in { c'1 8 }.
I think you're making it harder to read than necessary: Why the space
after \* / \x ?
I like Werner's suggestion with ** better already.
What worries me a bit is the difference with the
existing use of *, which might be confusing. R1*5
will be (most of the time) equivalent to R1**5,
whereas c'1*5 will not be the same as c'1**5.
Something like c'1\p**5 will be valid, contrary to
c'1\p*5; c'1*4/5 will work but not c'1**4/5; …
I have to think about it a bit more.
My gut feeling is that postfix ** might be dangerous/difficult to
implement robustly. But feel free to ignore this uneducated guess. :-)
I wouldn't push it so far -- it's easy enough to write
a music function for the repeat style you use most
often, just like you can shorten a lot of things
with variables and music functions, even more
conveniently now that we have \etc (let's hope the
latter would start working with \repeat someday).
By now, I know a handful of "normal" musicians among my friends who use
LilyPond for their occasional engraving tasks. From what they show me
when they have questions, I think there is still a significant number of
users that stay in the mode of "never defining anything new except music
variables" (and are still able to produce impressive scores). Of course,
the advent of \etc has made it extremely easy to create simple music
functions without even realising it; but I still think a sentence like
"it's easy enough to write a music function" makes a possible feature
practically invisible/unattainable for a large percentage of users: The
idea of defining parameterised short-hands is not familiar to many
people without a maths/computer science background.
Lukas
Re: Shortcut for \repeat unfold
> On 25 Sep 2021, at 17:47, Lukas-Fabian Moser wrote: > > And I think it would be nice to have an even more natural variant for that; I > think it's reasonable to provide & show/recommend convenient solutions for > standard tasks (rather than say "you can define your own abbreviation here if > you know how to do so") - for example, > > \*2 ""or\x2 "" > > which would be my favourite. Perhaps the LilyPond syntax might be tweaked so that identifiers starting with a UTF-8 multi-byte (high bit set) character do not need the backslash. Then simply ×2 would look good. As for typing such characters, I found text substitutions efficient, which is supported by some editors and OS text services. So in my system, if I type ".x" it translates into ×.
Re: Shortcut for \repeat unfold
On Sep 25, 2021, at 06:32, Lukas-Fabian Moser wrote:
>
>
> "\*" =
> #(define-music-function (n mus) (index? ly:music?)
>#{ \repeat $repeat-shorthand $n { #mus } #})
>
Instead of debating a default repeat type and function, why not provide access
to repetition as a music function with a clear name like
\repeatFunction type n music
And let the user decide how to abbreviate it?
x = \repeatFunction unfold \etc
—
Dan
Re: Shortcut for \repeat unfold
>> And I think it would be nice to have an even more natural variant >> for that; I think it's reasonable to provide & show/recommend >> convenient solutions for standard tasks (rather than say "you can >> define your own abbreviation here if you know how to do so") - for >> example, >> >> \*2 ""or\x2 "" >> >> which would be my favourite. > > Perhaps the LilyPond syntax might be tweaked so that identifiers > starting with a UTF-8 multi-byte (high bit set) character do not > need the backslash. Then simply ×2 would look good. This reminds me of TeX's 'active characters'. I think we shouldn't go this route. IMHO, a command should always be introduced with a backslash. Werner
Re: Shortcut for \repeat unfold
> On 25 Sep 2021, at 18:37, Werner LEMBERG wrote: > >>> And I think it would be nice to have an even more natural variant >>> for that; I think it's reasonable to provide & show/recommend >>> convenient solutions for standard tasks (rather than say "you can >>> define your own abbreviation here if you know how to do so") - for >>> example, >>> >>> \*2 ""or\x2 "" >>> >>> which would be my favourite. >> >> Perhaps the LilyPond syntax might be tweaked so that identifiers >> starting with a UTF-8 multi-byte (high bit set) character do not >> need the backslash. Then simply ×2 would look good. > > This reminds me of TeX's 'active characters'. I think we shouldn't go > this route. IMHO, a command should always be introduced with a > backslash. The idea here is different, it is for identifiers, and in the input syntax only, does not change the internal semantics at all. It is good not having to type backslash when a command is used.
Re: Shortcut for \repeat unfold
>>> Perhaps the LilyPond syntax might be tweaked so that identifiers >>> starting with a UTF-8 multi-byte (high bit set) character do not >>> need the backslash. Then simply ×2 would look good. >> >> This reminds me of TeX's 'active characters'. I think we shouldn't >> go this route. IMHO, a command should always be introduced with a >> backslash. > > The idea here is different, it is for identifiers, and in the input > syntax only, does not change the internal semantics at all. It is > good not having to type backslash when a command is used. Really? I highly doubt that. In particular, what about lyrics mode? Werner
Re: Shortcut for \repeat unfold
> On 25 Sep 2021, at 19:25, Werner LEMBERG wrote:
>
Perhaps the LilyPond syntax might be tweaked so that identifiers
starting with a UTF-8 multi-byte (high bit set) character do not
need the backslash. Then simply ×2 would look good.
>>>
>>> This reminds me of TeX's 'active characters'. I think we shouldn't
>>> go this route. IMHO, a command should always be introduced with a
>>> backslash.
>>
>> The idea here is different, it is for identifiers, and in the input
>> syntax only, does not change the internal semantics at all. It is
>> good not having to type backslash when a command is used.
>
> Really? I highly doubt that. In particular, what about lyrics mode?
The idea would be to change the file lexer.ll by adding U and UCOMMAND:
A [a-zA-Z\200-\377]
U [\200-\377]
AA {A}|_
N [0-9]
ANY_CHAR(.|\n)
SYMBOL {A}([-_]{A}|{A})*
COMMAND \\{SYMBOL}
UCOMMAND{U}{SYMBOL}
Then in select places, that is context switches, add {UCOMMAND}:
{COMMAND} {
return scan_escaped_word (YYText_utf8 () + 1);
}
{UCOMMAND} {
return scan_escaped_word (YYText_utf8 ());
}
Re: Shortcut for \repeat unfold
Dan Eble writes:
> On Sep 25, 2021, at 06:32, Lukas-Fabian Moser wrote:
>>
>>
>> "\*" =
>> #(define-music-function (n mus) (index? ly:music?)
>>#{ \repeat $repeat-shorthand $n { #mus } #})
>>
>
> Instead of debating a default repeat type and function, why not
> provide access to repetition as a music function with a clear name
> like
>
> \repeatFunction type n music
>
> And let the user decide how to abbreviate it?
>
> x = \repeatFunction unfold \etc
How about we change \repeat ... \alternative in its structure to be
\repeat ... { \alternative ... }, namely introduce a separate music
expression for \alternative? That way neither \repeat nor \alternative
need to be special.
Either \alternative could send some events caught by \repeat (with
\alternative being right behind \repeat being the last opportunity to
catch them, with \repeat \repeat ... \alternative possibly being tricky)
or a scorification hook does the final assembly.
Then we'd not need a special syntax (and the lookahead needed by
\alternative is a real nuisance) and could relitigate the meaning of
\repeat 4 .
--
David Kastrup
Re: Shortcut for \repeat unfold
On Sep 25, 2021, at 14:27, David Kastrup wrote:
>
> Dan Eble writes:
>
> How about we change \repeat ... \alternative in its structure to be
> \repeat ... { \alternative ... }, namely introduce a separate music
> expression for \alternative? That way neither \repeat nor \alternative
> need to be special.
Alternatives inside the repeat block are already partially supported. They
just don't work as desired in the most interesting case: at the tail.
I'm optimistic about implementing full support, but it's tangled up in work on
\repeat segno and there's something making it hard for me to work much on
LilyPond recently.
—
Dan
Re: Shortcut for \repeat unfold
Dan Eble writes:
> On Sep 25, 2021, at 14:27, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>> How about we change \repeat ... \alternative in its structure to be
>> \repeat ... { \alternative ... }, namely introduce a separate music
>> expression for \alternative? That way neither \repeat nor \alternative
>> need to be special.
>
> Alternatives inside the repeat block are already partially supported.
> They just don't work as desired in the most interesting case: at the
> tail.
>
> I'm optimistic about implementing full support, but it's tangled up in
> work on \repeat segno and there's something making it hard for me to
> work much on LilyPond recently.
Would the following stopgap measure make any sense for decoupling the
needs expressed in this thread and your time planning?
>From 27e1064d6dfc8a4748b0a62efa2c979339099f9a Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Sun, 26 Sep 2021 00:48:48 +0200
Subject: [PATCH] Allow partial \repeat commands without \alternative
This allows using
\repeat \etc
and
\repeat \etc
to act like partial music functions in order to make it easy to define
abbreviations. However, those partial music functions don't support
appending `\alternative` phrases like repeats usually do.
---
lily/include/lily-imports.hh | 1 +
lily/lily-imports.cc | 1 +
lily/parser.yy | 20 ++--
scm/ly-syntax-constructors.scm | 8 +++-
4 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/lily/include/lily-imports.hh b/lily/include/lily-imports.hh
index 88fa4b2478..3b35e5131b 100644
--- a/lily/include/lily-imports.hh
+++ b/lily/include/lily-imports.hh
@@ -166,6 +166,7 @@ extern Variable property_revert;
extern Variable property_set;
extern Variable property_unset;
extern Variable repeat;
+extern Variable repeat_alt;
extern Variable repetition_chord;
extern Variable sequential_alternative_music;
extern Variable sequential_music;
diff --git a/lily/lily-imports.cc b/lily/lily-imports.cc
index 6c4e4496ab..ea6ff46032 100644
--- a/lily/lily-imports.cc
+++ b/lily/lily-imports.cc
@@ -153,6 +153,7 @@ Variable property_revert ("property-revert");
Variable property_set ("property-set");
Variable property_unset ("property-unset");
Variable repeat ("repeat");
+Variable repeat_alt ("repeat-alt");
Variable repetition_chord ("repetition-chord");
Variable sequential_alternative_music ("sequential-alternative-music");
Variable sequential_music ("sequential-music");
diff --git a/lily/parser.yy b/lily/parser.yy
index 01f9f0a2a5..8a737ac8ef 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -849,6 +849,22 @@ partial_function:
scm_cadr ($2), scm_car ($2)),
$4);
}
+ | REPEAT simple_string unsigned_number
+ {
+ $$ = scm_cons (scm_list_3 (Syntax::repeat, $3, $2), SCM_EOL);
+ }
+ | REPEAT simple_string unsigned_number partial_function
+ {
+ $$ = scm_cons (scm_list_3 (Syntax::repeat, $3, $2), $4);
+ }
+ | REPEAT simple_string
+ {
+ $$ = scm_cons (scm_list_2 (Syntax::repeat, $2), SCM_EOL);
+ }
+ | REPEAT simple_string partial_function
+ {
+ $$ = scm_cons (scm_list_2 (Syntax::repeat, $2), $3);
+ }
// Stupid duplication because we already expect ETC here. It will follow anyway.
| script_dir markup_mode markup_partial_function
{
@@ -1487,11 +1503,11 @@ music_assign:
repeated_music:
REPEAT simple_string unsigned_number music
{
- $$ = MAKE_SYNTAX (repeat, @$, $2, $3, $4, SCM_EOL);
+ $$ = MAKE_SYNTAX (repeat, @$, $2, $3, $4);
}
| REPEAT simple_string unsigned_number music sequential_alternative_music
{
- $$ = MAKE_SYNTAX (repeat, @$, $2, $3, $4, $5);
+ $$ = MAKE_SYNTAX (repeat_alt, @$, $2, $3, $4, $5);
}
;
diff --git a/scm/ly-syntax-constructors.scm b/scm/ly-syntax-constructors.scm
index 7f9fe275e9..3ef6b01611 100644
--- a/scm/ly-syntax-constructors.scm
+++ b/scm/ly-syntax-constructors.scm
@@ -190,7 +190,13 @@
(make-sequential-music (list tempo-change tempo-set))
tempo-change)))
-(define-public (repeat type num body alts)
+(define-public repeat
+ (define-syntax-function ly:music?
+(type num body)
+(string? index? ly:music?)
+(ly:set-origin! (make-repeat type num body '()
+
+(define-public (repeat-alt type num body alts)
(ly:set-origin! (make-repeat type num body alts)))
(define (script-to-mmrest-text music)
--
2.32.0
--
David Kastrup
Re: Shortcut for \repeat unfold
On Sep 25, 2021, at 18:55, David Kastrup wrote: > > Subject: [PATCH] Allow partial \repeat commands without \alternative > > This allows using > >\repeat \etc > > and > >\repeat \etc > > to act like partial music functions in order to make it easy to define > abbreviations. However, those partial music functions don't support > appending `\alternative` phrases like repeats usually do. I haven't reviewed the patch itself, but I consider this a good idea. — Dan
Re: Shortcut for \repeat unfold
Dan Eble writes: > On Sep 25, 2021, at 18:55, David Kastrup wrote: >> >> Subject: [PATCH] Allow partial \repeat commands without \alternative >> >> This allows using >> >>\repeat \etc >> >> and >> >>\repeat \etc >> >> to act like partial music functions in order to make it easy to define >> abbreviations. However, those partial music functions don't support >> appending `\alternative` phrases like repeats usually do. > > I haven't reviewed the patch itself, but I consider this a good idea. Well, on the one hand \etc is really a bottomless pit. On the other hand, filling parts of it is comparatively easy as this patch shows, and in this case the intent is to require this just "temporarily" until \repeat can be replaced by a music function anyway. -- David Kastrup
Re: Shortcut for \repeat unfold
>>> The idea here is different, it is for identifiers, and in the
>>> input syntax only, does not change the internal semantics at all.
>>> It is good not having to type backslash when a command is used.
>>
>> Really? I highly doubt that. In particular, what about lyrics
>> mode?
>
> The idea would be to change the file lexer.ll by adding U and
> UCOMMAND:
>
> A [a-zA-Z\200-\377]
> U [\200-\377]
> AA{A}|_
> N [0-9]
> ANY_CHAR (.|\n)
> SYMBOL{A}([-_]{A}|{A})*
> COMMAND \\{SYMBOL}
> UCOMMAND {U}{SYMBOL}
>
> Then in select places, that is context switches, add {UCOMMAND}:
> {COMMAND} {
> return scan_escaped_word (YYText_utf8 () + 1);
> }
> {UCOMMAND} {
> return scan_escaped_word (YYText_utf8 ());
> }
You might provide a MR, maybe it gets accepted. I still doubt that it
would be a good idea.
Werner
