Re: Shortcut for \repeat unfold

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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

2021-09-25 Thread 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