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 <lfm@gmx.de> 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 people without a maths/computer 
> science background. 


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.

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

Best,
Jean