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 only to talk about my friends being normal, not myself. :-)
> > 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.
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"

than to come up with a shorthand using \etc themselves. That's the 
problem with general constructions: You have to 
see/understand/discover/be shown to what they can specialise. But of 
course there's the drawback of having too many specialised syntax 
constructions: If there's a command for everything, no one can remember 
the right tool for anything.

So I agree that this just boils down to a matter of documentation and of 
making \etc and its possible applications appear prominently in the 
learning manual as well as the notation reference. I'll try to make 
myself useful there.

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

Lukas