[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shortcut for \repeat unfold

From: David Kastrup
Subject: Re: Shortcut for \repeat unfold
Date: Tue, 28 Sep 2021 15:27:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

> 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

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]