Re: Shortcut for \repeat unfold

[David Kastrup]

Dan Eble  writes:

>> On Sep 24, 2021, at 19:32, Jean Abou Samra  wrote:
>> 
>> - "\rep n music", not as self-telling (and I think Lukas
>>   only calls his shortcut \rep because redefining \repeat
>>   is not syntactically valid);
>
> What about killing two birds with two stones?
>
> 1. convert-ly \times A/B into \tuplet B/A

We do that already in the 2.17.11 conversion rule.  It remains mainly
for backward compatibility.  I think I remember that some people liked
it for some purpose, however.  Uses the same convention as
\scaleDurations or so.

> 2. times = \repeat unfold \etc

When I was just occasionally using LilyPond, at some time when \tuplet
did not exist, I tended to be fuzzy about \time, \times, \tempo .  I am
familiar enough these days that this is a mere anecdotal data point: I
have no idea how it would affect newcomers.

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Dan Eble]

> On Sep 24, 2021, at 19:32, Jean Abou Samra  wrote:
> 
> - "\rep n music", not as self-telling (and I think Lukas
>   only calls his shortcut \rep because redefining \repeat
>   is not syntactically valid);

What about killing two birds with two stones?

1. convert-ly \times A/B into \tuplet B/A
2. times = \repeat unfold \etc

— 
Dan

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

28x { d a b fs | g d g a }

https://gitlab.com/lilypond/lilypond/-/merge_requests/937


That is a clever proposal. I am already fond of it.
Thank you.


This looks so "natural" (in the non-computer science-way of the meaning) 
one is surprised it works. :-)



What this means is that if you create a custom note
name language (with the undocumented not-yet-having-interface
#(set! language-pitch-names (acons 'mylang my-pitch-alist
language-pitch-names))), you won't be able to call a
note 'x', because

{ c4 x4 }

will be understood as

{ c 4x 4 }

I don't see that as a big deal. Using 'r' or 'R' or 'q'
as a note name is already not supported. To me, the
addition of this shorthand is worth a new element on
this list.


I agree with regard to pitch names; but what about Lyricmode (and also 
Figuremode etc.)?


Lukas

Re: Shortcut for \repeat unfold

[David Kastrup]

Jean Abou Samra  writes:


> It's not unconceivable to build whitespace into the
> lexer pattern and have { 5 x c'1 } work.

> What this means is that if you create a custom note
> name language (with the undocumented not-yet-having-interface
> #(set! language-pitch-names (acons 'mylang my-pitch-alist
> language-pitch-names))), you won't be able to call a
> note 'x', because
>
> { c4 x4 }
>
> will be understood as
>
> { c 4x 4 }

Unless you put a comment or a newline in the middle.

> I don't see that as a big deal. Using 'r' or 'R' or 'q'
> as a note name is already not supported.

They are perfectly fine as lyrics though.  Entering the alphabet song
with durations would become a nightmare

> To me, the addition of this shorthand is worth a new element on this
> list.

R and r do not intermingle with the lexical categories of numbers.

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Werner LEMBERG]

>> 28x { d a b fs | g d g a }
>>
>> https://gitlab.com/lilypond/lilypond/-/merge_requests/937
> 
> That is a clever proposal. I am already fond of it.  Thank you.

+1

>> I like that, thanks!  Carl's concerns w.r.t. whitespace are valid,
>> though.  Would it be possible to make the invalid syntax '28 x'
>> produce a nice error message like
>>
>>invalid ,  did you mean '28x'?
> 
> It's not unconceivable to build whitespace into the lexer pattern
> and have { 5 x c'1 } work.  [...]

Aah, nice :-)

> What this means is that if you create a custom note name language
> (with the undocumented not-yet-having-interface #(set!
> language-pitch-names (acons 'mylang my-pitch-alist
> language-pitch-names))), you won't be able to call a note 'x',
> because
> 
> { c4 x4 }
> 
> will be understood as
> 
> { c 4x 4 }
> 
> I don't see that as a big deal.  Using 'r' or 'R' or 'q' as a note
> name is already not supported.  To me, the addition of this
> shorthand is worth a new element on this list.

I agree.


Werner

Re: Shortcut for \repeat unfold

[Jean Abou Samra]

Le 29/09/2021 à 01:50, Dan Eble a écrit :

On Sep 24, 2021, at 19:32, Jean Abou Samra  wrote:

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);
- "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;
- "\* 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.
Thoughts?

28x { d a b fs | g d g a }

https://gitlab.com/lilypond/lilypond/-/merge_requests/937


That is a clever proposal. I am already fond of it.
Thank you.



I like that, thanks!  Carl's concerns w.r.t. whitespace are valid,
though.  Would it be possible to make the invalid syntax '28 x'
produce a nice error message like

   invalid ,  did you mean '28x'?



It's not unconceivable to build whitespace into the
lexer pattern and have { 5 x c'1 } work.

diff --git a/lily/lexer.ll b/lily/lexer.ll
index a1556480d3..f13211cde1 100644
--- a/lily/lexer.ll
+++ b/lily/lexer.ll
@@ -178,7 +178,7 @@ COMMAND \\{SYMBOL}
 SPECIAL    [-+*/=<>{}!?_^'',.:]
 SHORTHAND  (.|\\.)
 UNSIGNED   {N}+
-REPEAT_COUNT    {UNSIGNED}x
+REPEAT_COUNT    {UNSIGNED}{WHITE}*x
 E_UNSIGNED \\{N}+
 FRACTION   {N}+\/{N}+
 INT    -?{UNSIGNED}
@@ -582,7 +582,7 @@ FIG_ALT_EXPR 
{WHITE}*{FIG_ALT_SYMB}({FIG_ALT_SYMB}|{WHITE})*

    return UNSIGNED;
    }
    {REPEAT_COUNT}  {
-   yylval = scm_c_read_string (YYText ());
+   yylval = scan_repeat_count (YYText ());
    return REPEAT_COUNT;
    }
    \\\"    {
@@ -642,7 +642,7 @@ FIG_ALT_EXPR 
{WHITE}*{FIG_ALT_SYMB}({FIG_ALT_SYMB}|{WHITE})*

    return UNSIGNED;
    }
    {REPEAT_COUNT}  {
-   yylval = scm_c_read_string (YYText ());
+   yylval = scan_repeat_count (YYText ());
    return REPEAT_COUNT;
    }
    -  {
@@ -818,7 +818,7 @@ FIG_ALT_EXPR 
{WHITE}*{FIG_ALT_SYMB}({FIG_ALT_SYMB}|{WHITE})*

 }

 {REPEAT_COUNT} {
-   yylval = scm_c_read_string (YYText ());
+   yylval = scan_repeat_count (YYText ());
    return REPEAT_COUNT;
 }

@@ -1398,7 +1398,8 @@ scan_fraction (string frac)
 SCM
 scan_repeat_count (string s)
 {
-   s.pop_back (); // remove the 'x'
+   while (!isdigit (s.back ()))
+   s.pop_back (); // remove the 'x' and whitespace
    return scm_c_read_string (s.c_str ());
 }


What this means is that if you create a custom note
name language (with the undocumented not-yet-having-interface
#(set! language-pitch-names (acons 'mylang my-pitch-alist
language-pitch-names))), you won't be able to call a
note 'x', because

{ c4 x4 }

will be understood as

{ c 4x 4 }

I don't see that as a big deal. Using 'r' or 'R' or 'q'
as a note name is already not supported. To me, the
addition of this shorthand is worth a new element on
this list.

Thanks,
Jean

Re: Shortcut for \repeat unfold

[Werner LEMBERG]

> 28x { d a b fs | g d g a }

I like that, thanks!  Carl's concerns w.r.t. whitespace are valid,
though.  Would it be possible to make the invalid syntax '28 x'
produce a nice error message like

  invalid ,  did you mean '28x'?


Werner

Re: Shortcut for \repeat unfold

[Carl Sorensen]

On 9/28/21, 6:16 PM, "Dan Eble"  wrote:

On Sep 28, 2021, at 20:12, Carl Sorensen  wrote:
> 
> Would 
>28 x { d a b fs | g d g a }
> 
> Work with the current MR?

No, the x is a suffix.  28 would be parsed as a duration (an invalid one) 
and x as a note name (an invalid one).

Thanks, that's what I thought.

I'm not sure how I feel about this.  I love the brevity of it.  I'm not sure I 
love the suffix.

Thanks,

Carl
 

Re: Shortcut for \repeat unfold

[Dan Eble]

On Sep 28, 2021, at 20:12, Carl Sorensen  wrote:
> 
> Would 
>28 x { d a b fs | g d g a }
> 
> Work with the current MR?

No, the x is a suffix.  28 would be parsed as a duration (an invalid one) and x 
as a note name (an invalid one).
— 
Dan

Re: Shortcut for \repeat unfold

[Carl Sorensen]

On 9/28/21, 5:51 PM, "lilypond-devel on behalf of Dan Eble" 
 wrote:


> On Sep 24, 2021, at 19:32, Jean Abou Samra  wrote:
> 
> 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);
> - "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;
> - "\* 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.

> Thoughts?

28x { d a b fs | g d g a }

Looking at the code, I'm not sure about the implications, and I haven't built 
it to test.

Would 
28 x { d a b fs | g d g a }

Work with the current MR?  I would much prefer if we could allow white space 
between the repeat count and the x, because white space is very seldom crucial 
in lilypond syntax.

Thanks,

Carl

 

Re: Shortcut for \repeat unfold

[Dan Eble]

> On Sep 24, 2021, at 19:32, Jean Abou Samra  wrote:
> 
> 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);
> - "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;
> - "\* 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.

> Thoughts?

28x { d a b fs | g d g a }

https://gitlab.com/lilypond/lilypond/-/merge_requests/937
— 
Dan

Re: Shortcut for \repeat unfold

[David Kastrup]

Lukas-Fabian Moser  writes:

>>> I answer somewhat orthogonally to your question: I think that for many
>>> people it's a lot easier to digest the information
>>>
>>> "\* creates unfolded repeats; this behaviour may be changed using
>>> \defaultRepeatType percent"
>> That is one step forward, one step back: one advantage of a fixed
>> shorthand is that documents written in colloboration can depend on it.
>> "this behavior may be changed" negates that again.
>
> Yes, undoubtedly (although it's not uncommon to have default behaviour
> that may be customized, and every collaborative effort is going to
> need some conventions regarding coding style etc. anyway).

The point is that _only_ \repeat unfold makes some sense as an _input_
shorthand.  The other repeats have visible representations.  There may
be some cuteness incentive to do

"\\%" = \repeat percent \etc
"\\|" = \repeat volta \etc
"\\/" = \repeat tremolo \etc

but the only thing with some input convenience relevance may be \repeat
tremolo which already has a shorthand for the most relevant single note
tremolos.

> But in the context you quoted, I was not advocating a concrete
> solution involving some fixed-but-configurable shorthand, but instead
> trying to weigh "didactical" aspects. In short: I agree with Jean
> that, since it's not useful to have an abundance of dedicated
> solutions, it might be better to think about documentation (good
> exposition and enlightening examples) that enable as many people as
> possible to put universal tools to good concrete use.

Not least of all since it lowers the threshold towards writing "proper"
music functions.

>>> Absolutely. It's an incredibly elegant tool.
>> 
>
> I'm not sure what your point is (but that thread's an enlightening
> read, anyway). It seems to show that - considering the importance of
> suggestive names - Dan deserves a fair share of credit for the
> ingenuity of \etc as well.

The originally proposed \incomplete is technical, and the overall
proposal of mine was under the general feeling "feels like it could save
some typing but it doesn't really seem to provide anything to the user
they don't have already".  "\etc" tells the reader "it's not necessary
to think more about this" while "\incomplete" tells the reader "it would
be necessary to think more about this".

Effective programming demagoguery.  Who would have thought this to be a
thing?

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

I answer somewhat orthogonally to your question: I think that for many
people it's a lot easier to digest the information

"\* creates unfolded repeats; this behaviour may be changed using
\defaultRepeatType percent"

That is one step forward, one step back: one advantage of a fixed
shorthand is that documents written in colloboration can depend on it.
"this behavior may be changed" negates that again.


Yes, undoubtedly (although it's not uncommon to have default behaviour 
that may be customized, and every collaborative effort is going to need 
some conventions regarding coding style etc. anyway).


But in the context you quoted, I was not advocating a concrete solution 
involving some fixed-but-configurable shorthand, but instead trying to 
weigh "didactical" aspects. In short: I agree with Jean that, since it's 
not useful to have an abundance of dedicated solutions, it might be 
better to think about documentation (good exposition and enlightening 
examples) that enable as many people as possible to put universal tools 
to good concrete use.



  One reason \etc is so great is that you
can use it in many different cases without thinking too much
or writing a single line in an esoteric, err, not very
commonly spoken programming language.

Absolutely. It's an incredibly elegant tool.




I'm not sure what your point is (but that thread's an enlightening read, 
anyway). It seems to show that - considering the importance of 
suggestive names - Dan deserves a fair share of credit for the ingenuity 
of \etc as well.


Lukas

Re: Shortcut for \repeat unfold

[David Kastrup]

Lukas-Fabian Moser  writes:

> I answer somewhat orthogonally to your question: I think that for many
> people it's a lot easier to digest the information
>
> "\* creates unfolded repeats; this behaviour may be changed using
> \defaultRepeatType percent"

That is one step forward, one step back: one advantage of a fixed
shorthand is that documents written in colloboration can depend on it.
"this behavior may be changed" negates that again.

>>  One reason \etc is so great is that you
>> can use it in many different cases without thinking too much
>> or writing a single line in an esoteric, err, not very
>> commonly spoken programming language.
>
> Absolutely. It's an incredibly elegant tool.



-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Lukas-Fabian Moser]

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.


Well, \repeat unfold has become sort of an independent
issue from my point of view since what I would rather
see in lyrics is some way to make explicit durations
override the synchronization between lyrics and melody,
either as

\lyricmode {
  lyrics following notes
  lyrics8 with4. \skip 1 own2. rhythm1*3/4
  follow notes again
}

or (if the compatibility breakage were too high)

\lyricmode {
  lyrics following notes
  \noSync { lyrics8 with4. \skip 1 own2. rhythm1*3/4 }
  follow notes again
}


I'm still not sure if it's possible to give this a well-defined meaning 
at the boundaries between sync'ed and non-sync'ed lyrics.


Anyway: As I now know, "" is not a suitable replacement for a lyric skip 
(it stops lyric extenders). So, regarding my initial merge request: I 
still think that "\skip 1" in lyrics (the necessary-but-discarded 
duration argument) is sufficiently ugly to warrant hiding it behind 
special syntax, e.g. \lyricSkip as I proposed (or \skipNote). I agree 
that the multi-notes variant in that said merge request might be 
overkill, and I'd be absolutely fine with trashing that.



\*… well I can't say I'm a huge fan of it, but it looks reasonable enough.


[...]


We have a lot of syntax to remember already. While I advocate
an addition here for something that I consider sufficiently
generally useful (notably for presentation contexts where custom
shorthands are not wanted), I think we should be parcimonious
when adding new syntax, because more of it also means looking
up the documentation more frequently when you are not
an intensive user.
(Please forgive me for re-arranging your mail, I hope I didn't distort 
your intended meaning.)


Yes, absolutely. I think for \repeat unfold ... it might be warranted, 
though: That is sufficiently clumsy (if used for repeating single notes, 
for example) and at the same time ubiquitous that a shorthand might be a 
worthwhile addition. Of course it's true that everybody may define 
shorthands for whatever constructions they use the most, but if an 
addition makes it possible to give examples in the NR in a way that is 
succinct and easy to write and read, that might be a good idea. After 
all, the NR should show how elegant and convenient entering music in 
LilyPond can be - not demonstrate a cumbersome way of expressing things 
that "insiders" might know how to simplify.

Do note, however, that:

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:


is not entirely true: once a function is defined, it can be
relied on internally. Imagine my embarrassment when I had to
explain on -user-fr the cause of the error occurring with
the code (minimized here):

cons = \markup \tiny "conséquent"

{
  \stemDown
  c'2^\cons
  \undo \stemDown
  c'2
}
Agreed: The possibility to redefine things ends where redefinitions 
render the whole system unusable. But I'm really glad that your example 
does not crash anymore, as that shows that it's become quite less easy 
to disrupt LilyPond in such a way.

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.


If ** could be make to work, it might be a good idea to demonstrate its 
use in the manuals only with spaces. Of course they don't 
(shouldn't/mustn't) make a difference to LilyPond, but to the human 
reader, "c4 ** 5" is much less likely to be mistaken for "c4*5" than 
"c4**5". There's a reason we write


\relative {
  c'4 d8 e f4 d
  e4 d c2
}

and not

\relative { c' 4d 8e f 4d e 4d c 2 }


By now, I know a handful of "normal" musicians among my friends

Oh, my notion of my own normality totters somewhat… ;-)

I took care o

Re: Shortcut for \repeat unfold

[David Kastrup]

Jean Abou Samra  writes:

> This seems a likely cause for current success:
>
>
> commit b0c6d48388c66aa12a472a6069f5b2ec07c579b2
> Author: Han-Wen Nienhuys 
> Date:   Sun Feb 14 11:15:17 2021 +0100
>
>     Initialize session from a dedicated parser
>
>     The session mechanism reads the initialization .ly files, to setup
>     variable assignments to replay for later files.  This mechanism
>     inherently retains the module associated with the parser for
>     initializing the session.
>
>     Before, if the first .ly file assigned something to an identifier,
> the value
>     would be retained, leading to "parsed-object is dead" warnings.
>
>     By executing the initialization in a separate parser, we avoid the
>     warnings. It also ensures that the first file is processed in the same
>     way as later files.

Oh, ok.  It would have been my expectation though possibly to be
adjusted for macro usage because macro replacements are not module
specific.  Good thing then Han-Wen made that change.

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Jean Abou Samra]

Le 27/09/2021 à 23:52, David Kastrup a écrit :

Jean Abou Samra  writes:


is not entirely true: once a function is defined, it can be
relied on internally. Imagine my embarrassment when I had to
explain on -user-fr the cause of the error occurring with
the code (minimized here):

cons = \markup \tiny "conséquent"

{
   \stemDown
   c'2^\cons
   \undo \stemDown
   c'2
}

That code works fine here and produces the expected result:



Didn't check development versions. With 2.22.1, you get

Parsing.../home/jean/lilypond2.22.1/lilypond/usr/share/lilypond/current/ly/music-functions-init.ly:1962:18: 
In expression (cons (make-music # # ...) overrides):


/home/jean/lilypond2.22.1/lilypond/usr/share/lilypond/current/ly/music-functions-init.ly:1962:18: 
Wrong type to apply: (# 
"conséquent")



This seems a likely cause for current success:


commit b0c6d48388c66aa12a472a6069f5b2ec07c579b2
Author: Han-Wen Nienhuys 
Date:   Sun Feb 14 11:15:17 2021 +0100

    Initialize session from a dedicated parser

    The session mechanism reads the initialization .ly files, to setup
    variable assignments to replay for later files.  This mechanism
    inherently retains the module associated with the parser for
    initializing the session.

    Before, if the first .ly file assigned something to an identifier, 
the value

    would be retained, leading to "parsed-object is dead" warnings.

    By executing the initialization in a separate parser, we avoid the
    warnings. It also ensures that the first file is processed in the same
    way as later files.

Re: Shortcut for \repeat unfold

[David Kastrup]

Carl Sorensen  writes:

> On 9/27/21, 3:52 PM, "lilypond-devel on behalf of David Kastrup"
>  behalf of d...@gnu.org> wrote:
>
> Jean Abou Samra  writes:
> 
> > is not entirely true: once a function is defined, it can be
> > relied on internally. Imagine my embarrassment when I had to
> > explain on -user-fr the cause of the error occurring with
> > the code (minimized here):
> >
> > cons = \markup \tiny "conséquent"
> But doesn't this redefine the scheme symbol 'cons ?
>
> Carl

Only in the current parser module.  You'll have lots of fun using "cons"
in code defined _afterwards_.  But the references of preexisting code
remain to the Guile primitive.

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[David Kastrup]

Jean Abou Samra  writes:

> I *think* it means a token of lookahead is required
> after most curly braces, which *may* have consequences
> on synchronization between lexer and parser around mode
> boundaries — at any rate, parser.yy contains the comment
>
> // We must not have lookahead tokens parsed in lyric mode.
>
> Perhaps David can tell more?

There is not much more to tell.  Once a token has been lexed in some
mode, it's fixed.  So you don't want to require a lookahead token for
deciding whether to switch to a different lexing mode.

Tokens that are the same in different modes are not an issue, but lyric
mode lexes a whole lot of stuff into quite different tokens than other
modes do.

> I know, but is it significantly easier to write
>
> \defaultRepeatType percent
>
> compared to
>
> per = \repeat percent \etc
>
> ? The latter is allowed with David's patch, which
> has now become https://gitlab.com/lilypond/lilypond/-/merge_requests/932
> ­— thank you David!
>
> If it's a matter of discoverability, then it's the job
> of the documentation to advertise the possibility of
> defining these shortcuts, possibly mentioning it around
> repeats and possibly presenting \etc prominently in the
> learning manual next to variables.

I am somewhat loth to overstress \repeat ... \etc right now when \repeat
is hopefully slated to eventually become an ordinary music function
rather than an exception (it would be a real nuisance to explain why
\alternative does not work with \etc forms in the current version).
Once \repeat is a proper music functions, it may be a prime example for
\etc usage.

-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Carl Sorensen]

On 9/27/21, 3:52 PM, "lilypond-devel on behalf of David Kastrup" 
 wrote:

Jean Abou Samra  writes:

> is not entirely true: once a function is defined, it can be
> relied on internally. Imagine my embarrassment when I had to
> explain on -user-fr the cause of the error occurring with
> the code (minimized here):
>
> cons = \markup \tiny "conséquent"
But doesn't this redefine the scheme symbol 'cons ?

Carl

>
> {
>   \stemDown
>   c'2^\cons
>   \undo \stemDown
>   c'2
> }

That code works fine here and produces the expected result:

Re: Shortcut for \repeat unfold

[David Kastrup]

Jean Abou Samra  writes:

> is not entirely true: once a function is defined, it can be
> relied on internally. Imagine my embarrassment when I had to
> explain on -user-fr the cause of the error occurring with
> the code (minimized here):
>
> cons = \markup \tiny "conséquent"
>
> {
>   \stemDown
>   c'2^\cons
>   \undo \stemDown
>   c'2
> }

That code works fine here and produces the expected result:


-- 
David Kastrup

Re: Shortcut for \repeat unfold

[Jean Abou Samra]

Le 25/09/2021 à 17:25, Dan Eble a écrit :

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


It is very desirable to have \etc work with \repeat,
but to me partly orthogonal to providing a built-in
shortcut, particularly when considering LSR and documentation
snippets as well as minimal examples, where defining shortcuts
is not appropriate.


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.



Well, \repeat unfold has become sort of an independent
issue from my point of view since what I would rather
see in lyrics is some way to make explicit durations
override the synchronization between lyrics and melody,
either as

\lyricmode {
  lyrics following notes
  lyrics8 with4. \skip 1 own2. rhythm1*3/4
  follow notes again
}

or (if the compatibility breakage were too high)

\lyricmode {
  lyrics following notes
  \noSync { lyrics8 with4. \skip 1 own2. rhythm1*3/4 }
  follow notes again
}


So, when I talked about "syntactic sugar" I didn't mean the literal 
character-copy-and-paste sense.


Ok.

I think you're making it harder to read than necessary: Why the space 
after \* / \x ?


I have to admit I assumed too fast it wouldn't make a
readability difference.

{ c'1 \repeat 8 dis'8-_ c'1 }

{ c'1 \x 8 dis'8-_ c'1 }

{ c'1 \* 8 dis'8-_ c'1 }

{ c'1 \x8 dis'8-_ c'1 }

{ c'1 \*8 dis'8-_ c'1 }

{ c'1 dis'8-_**8 c'1 }

I would definitely object to \x because x is a very common
variable name. \*… well I can't say I'm a huge fan of it, but
it looks reasonable enough. (Readers should note that \* occupies
the name "\*", not "*", without confusion with the Scheme procedure
"*".)

Do note, however, that:

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:


is not entirely true: once a function is defined, it can be
relied on internally. Imagine my embarrassment when I had to
explain on -user-fr the cause of the error occurring with
the code (minimized here):

cons = \markup \tiny "conséquent"

{
  \stemDown
  c'2^\cons
  \undo \stemDown
  c'2
}



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 *think* it means a token of lookahead is required
after most curly braces, which *may* have consequences
on synchronization between lexer and parser around mode
boundaries — at any rate, parser.yy contains the comment

// We must not have lookahead tokens parsed in lyric mode.

Perhaps David can tell more?



By now, I know a handful of "normal" musicians among my friends



Oh, my notion of my own normality totters somewhat… ;-)


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

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 26 Sep 2021, at 10:16, Jean Abou Samra  wrote:
> 
> Le 26/09/2021 à 09:57, Hans Åberg a écrit :
>>> On 26 Sep 2021, at 06:49, Werner LEMBERG  wrote:
>>> 
>>> You might provide a MR, maybe it gets accepted.  I still doubt that it
>>> would be a good idea.
>> There is a conflict in some contexts between {SYMBOL} and {COMMAND}, so may 
>> not work. To get a regular COMMAND syntax, they should start with something 
>> that SYMBOL does not.
>> 
>> Otherwise you might replace the function YYText_utf8 with proper UTF-8 
>> patterns, a variation of:
>> 
>> /* UTF-8 character with valid Unicode code point. */
>> utf8char
>> [\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF]([\x80-\xBF]{2})|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|[\xF1-\xF3]([\x80-\xBF]{3})|\xF4[\x80-\x8F]([\x80-\xBF]{2})
> 
> I concur with Werner.I don't think special characters like ×
> are easier to type than a backslash, and they are an annoyance if
> you don't have keyboard shortcuts at hand (like on a computer that
> is not your primary work device). They require more effort
> for beginners and memory of keyboard input methods for everyone.
> Plus, it's not clear how to make them work in lyrics mode and
> markup given that something like \lyricmode { ×8 } is already
> valid syntax and has legitimate uses.

I use text substitutions, which I have found to be fastest both to create and 
use. For example, I have set ".x" to translate to "×".

Re: Shortcut for \repeat unfold

[Jean Abou Samra]

Le 26/09/2021 à 09:57, Hans Åberg a écrit :

On 26 Sep 2021, at 06:49, Werner LEMBERG  wrote:


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.

There is a conflict in some contexts between {SYMBOL} and {COMMAND}, so may not 
work. To get a regular COMMAND syntax, they should start with something that 
SYMBOL does not.

Otherwise you might replace the function YYText_utf8 with proper UTF-8 
patterns, a variation of:

/* UTF-8 character with valid Unicode code point. */
utf8char
[\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF]([\x80-\xBF]{2})|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|[\xF1-\xF3]([\x80-\xBF]{3})|\xF4[\x80-\x8F]([\x80-\xBF]{2})


I concur with Werner.I don't think special characters like ×
are easier to type than a backslash, and they are an annoyance if
you don't have keyboard shortcuts at hand (like on a computer that
is not your primary work device). They require more effort
for beginners and memory of keyboard input methods for everyone.
Plus, it's not clear how to make them work in lyrics mode and
markup given that something like \lyricmode { ×8 } is already
valid syntax and has legitimate uses.

Regards,
Jean

Re: Shortcut for \repeat unfold

[Hans Åberg]

> On 26 Sep 2021, at 06:49, Werner LEMBERG  wrote:
> 
 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.

There is a conflict in some contexts between {SYMBOL} and {COMMAND}, so may not 
work. To get a regular COMMAND syntax, they should start with something that 
SYMBOL does not.

Otherwise you might replace the function YYText_utf8 with proper UTF-8 
patterns, a variation of:

/* UTF-8 character with valid Unicode code point. */
utf8char
[\x09\x0A\x0D\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF]([\x80-\xBF]{2})|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x\90-\xBF]([\x80-\xBF]{2})|[\xF1-\xF3]([\x80-\xBF]{3})|\xF4[\x80-\x8F]([\x80-\xBF]{2})

Re: Shortcut for \repeat unfold

[Werner LEMBERG]

>>> 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

Re: Shortcut for \repeat unfold

[David Kastrup]

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

[Dan Eble]

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

[David Kastrup]

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

[Dan Eble]

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

[David Kastrup]

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

[Hans Åberg]

> 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

[Werner LEMBERG]

>>> 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

[Hans Åberg]

> 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

[Werner LEMBERG]

>> 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

[Dan Eble]

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

[Hans Åberg]

> 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

[Lukas-Fabian Moser]

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

[Lukas-Fabian Moser]

"\*" =
#(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

[David Kastrup]

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

[Jean Abou Samra]

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

[David Kastrup]

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

[anthony]

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]

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

[David Kastrup]

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

[Aaron Hill]

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

[David Kastrup]

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

[Aaron Hill]

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

[Lukas-Fabian Moser]

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

[Lukas-Fabian Moser]

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

[David Kastrup]

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

[Lukas-Fabian Moser]

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

[Werner LEMBERG]

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

[antlists]

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

[Lukas-Fabian Moser]

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

[Aaron Hill]

On 2021-09-24 4:32 pm, Jean Abou Samra wrote:

- "\* 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 would disagree.  Such an abbreviation is sensible when repeating 
singleton notes.  For smaller values of n, the proposed "\repeat n" 
could still be longer than just manually repeating a duration value:


  { \repeat 4 b'4 } vs { b'4 4 4 4 }

If the asterisk feels overloaded, you could use the multiplication sign:


\version "2.22.0"

× = % U+00D7
#(define-music-function
 (count music) (number? ly:music?)
 #{ \repeat unfold #count $music #})

{ \×4 b'4 | \tuplet 3/2 \×3 { a'8 g' } fis'2 }


Granted, many fonts make that look so much like "\x" that you probably 
would just use the letter 'x' instead if one does not mind giving up a 
single-letter command for the cause.



-- Aaron Hill

Shortcut for \repeat unfold

[Jean Abou Samra]

Hi,

This continues a discussion sparked at
https://gitlab.com/lilypond/lilypond/-/merge_requests/921

In short, I propose to make the first argument to
\repeat optional, making \repeat n music equivalent to
\repeat unfold n music.

The principal motivation is sparing typing. \repeat unfold
is commonly used as a time-saving shortcut, not only in
real-world usage, but also while constructing minimal
working examples involving filler music. It is personally
one of the commands I use the most frequently, and I am
apparently not alone in that case
(https://gitlab.com/lilypond/lilypond/-/merge_requests/921#note_682103342).
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.

Now, if we want to shorten \repeat unfold, what's the best
syntax? I favor \repeat as it matches usage patterns of
functions with optional arguments (like \time). Even though
\repeat is not currently a music function, I think having it
mimic that syntax helps mnemonics. \repeat n music is also
very readable.

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);
- "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;
- "\* 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.

With this change, documentation can be updated to use
the short syntax (let's leave Documentation/snippets as-is
though, to avoid piling work that will have to be paid
at the next LSR upgrade, whenever that happens).

Thoughts?

Regards,
Jean

PS: Apart from regression tests and documentation,
I have a draft implementation locally.