is a bad idea.
In general #*unspecified inside of a music expression is elided.
(make-music 'Music) isn't. It prints under \displayMusic, it takes
articulations. It has non-trivial side effects and should not be
silently inserted for what may likely be lackadaisical coding without a
clear idea of what is happening.
--
David Kastrup
o provide a framework for such work but
it hasn't gained critical mass and it is not as integrated into the
LilyPond engine as LaTeX is with the TeX engine.
AI and LSR both don't provide guarantees and may be hit and miss, to
various degrees. But abandoning LSR does not seem like a step forward
without anything slated to succeed it.
--
David Kastrup
er, because language grammar for
lilypond is unavailable (version-mismatch): 15
⛔ Warning (treesit): Cannot activate tree-sitter, because language grammar for
lilypond is unavailable (version-mismatch): 15
⛔ Warning (treesit): Cannot activate tree-sitter, because language grammar for
lilypond is
David Kastrup writes:
> Saul Tobin writes:
>
>> Uh oh. Thanks for the report. It would be helpful if you could let me know:
>>
>>1. Did the LilyPond Tree-sitter grammar get installed at all?
>>`(treesit-ready-p 'lilypond)`
>
> ⛔ Warning (trees
variable
'treesit-font-lock-feature-list) lilypond-ts--font-lock-features) (set
(make-local-variable 'treesit-font-lock-level) 3) (set (make-local-variable
'treesit-simple-indent-rules) lilypond-ts-indent-rules) (set
(make-local-variable 'treesit-simple-imenu-settings) lilypond-ts-imenu-rules)
(add-hook 'lilypond-ts-post-eval-hook #'lilypond-ts--require-list-refresh)
(treesit-major-mode-setup) (set (make-local-variable 'lisp-indent-function)
#'scheme-indent-function) (set (make-local-variable
'syntax-propertize-function) #'lilypond-ts--propertize-syntax)
(lilypond-ts-autodoc-mode 1) (lilypond-ts-capf-mode 1)
(lilypond-ts-navigation-mode 1)
lilypond-ts-mode()
funcall-interactively(lilypond-ts-mode)
call-interactively(lilypond-ts-mode record nil)
command-execute(lilypond-ts-mode record)
execute-extended-command(nil "lilypond-ts-mode" "lilypond-ts-mo")
funcall-interactively(execute-extended-command nil "lilypond-ts-mode"
"lilypond-ts-mo")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
--
David Kastrup
sion-mismatch): 15
⛔ Warning (treesit): The installed language grammar for lilypond cannot be
located or has problems (version-mismatch): 15
--
David Kastrup
t; indentation, and as you say many of the features are unmaintained.
>
> My one concern is that lilypond-ts-mode seems to be targeted at Emacs
> 30+. Does it work on earlier Emacs?
In what respect would that be a concern?
--
David Kastrup
mode
> in favor of lilypond-ts-mode.
>
> I believe that quite a few LilyPond devs are Emacs users. If you haven't
> yet, I highly encourage you to give lilypond-ts-mode a try. I think you'll
> be pleased — or if not, please let me know why!
git shortlog -s --after="10
:19:1:
error: unknown command: `\testMarkupI'
out/lybook-testdb/12/lily-b0020de6.log:include-path-modification-i.ly:25:1:
error: syntax error, unexpected end of input, expecting '.' or '='
are ignored as well?
Or is the latter because I am doing in-tree testing?
--
David Kastrup
't
relevant. The work of creating your reply to the salient points and
remove the others starts at the top.
--
David Kastrup
ing sent back
> and forth.
Where things get really ugly is when someone quotes the weekly digest at
the bottom of their mail. And this quote makes it into the next weekly
digest.
--
David Kastrup
in and again.
--
David Kastrup
nesting in order to process input that does not actually correspond to
what it is supposed to express...
Nope. We don't want that kind of obfuscation in order to accidentally
end up with the thing naïvely intended by the user but not reflected
properly in the input.
--
David Kastrup
Saul Tobin writes:
>> On Tue, Jan 28, 2025 at 6:18 PM David Kastrup wrote:
>>
>>> Saul Tobin writes:
>>>
>>> > I think merging \compoundMeter into \time as a single command would be
>>> > great. IMO an even bigger improvement would be to
symbol lists. How feasible
> would it be to support arguments to \time (or to music functions generally)
> of the form 3/8+2/4 or 2+3/8?
Nightmarish?
Don't really see anything that would generalize sensibly.
In particular since you likely want the above to be (3/8)+(2/4) vs (2+3)/8.
--
David Kastrup
I've just did a switch to German, and "Notenwert" would be pretty much
the duration. I cannot rule out that for native English speakers, "note
value" has the right connotations. However, for "computer English"
speakers, "value" may have more of a specific meaning/connotation,
making the term more problematic for an international audience than a
native English one that is used to, well, compounding compound words.
--
David Kastrup
eturn values, expected values, call-with-values,
value->lily-string and so on.
Even with the prefix "note", this is going to end in a situation that is
not really making for good convert-ly foo and readable code.
--
David Kastrup
a lot of (if (null? ...)) and (if (not (null? ...)) ...) code in
LilyPond that just feels wrong because the property checked with null?
has nothing whatsoever to do with being a list.
--
David Kastrup
;()
which is not really pretty but possibly a hangover from the LISP mindset
where (not 1) and '() are the same, namely NIL.
But I don't think *unspecified* was ever really used in LilyPond.
--
David Kastrup
. But now it is
> certain that he will not return and resume his work on OpenLilyLib and
> its subprojects. I sincerely hope that the legacy he leaves behind in
> this project will not be forgotten.
That is very sad news indeed.
--
David Kastrup
Trevor Bača writes:
> On Fri, Dec 13, 2024 at 1:02 PM David Kastrup wrote:
>
>> Trevor Bača writes:
>>
>> > I am concerned by what seems to be an unwillingness to use the term
>> > "duration" to label things in the system that are clearly duration
Carl Sorensen writes:
> On Fri, Dec 13, 2024 at 2:03 PM David Kastrup wrote:
>
>> Trevor Bača writes:
>>
>> > I am concerned by what seems to be an unwillingness to use the term
>> > "duration" to label things in the system that are clea
erminology while expecting
consistent results.
--
David Kastrup
ot;duration". But with regard
to established jargon, I think of "timespan" as something measured in
seconds while I think of "length" as something measured in beats. We
don't really use "length" for properties measured in centimeters,
inches, staff spaces and the like, do we? We use "width" and "height"
here. At least that would be one way to avoid ambiguity.
--
David Kastrup
displaying Right-Hand Fingerings"?
--
David Kastrup
t typesetting tasks, but
someone™ has to do the work for any of them. That is not the choice of
a central project managing authority but of someone invested enough in a
specific task that they will gear up to doing the involved work.
--
David Kastrup
weekly digest of the mailing list, and finding the
content in such a digest when the starting posting is quoted and
requoted dozens of times is close to impossible.
Thanks for your consideration.
--
David Kastrup
How can we better spread best programming practises and showcase the
tools that are available for them?
--
David Kastrup
How can we better spread best programming practices and showcase the
tools that are available for them?
--
David Kastrup
ssed at rare times on the
developer list where probably also the current semantics have been
finetunes in discussions. But we don't have an obvious place in our
docs for it.
--
David Kastrup
Carl Sorensen writes:
> On Wed, Nov 6, 2024 at 6:30 AM David Kastrup wrote:
>
> Which people know the best programming practices?
> You, Harm, Werner? I'm certainly not part of that group.
For the kind of user interface programming that provides reasonably
simple access t
Dan Eble writes:
> On 2024-10-04 17:58, David Kastrup wrote:
>> Dan Eble writes:
>>
>>> Taking all the feedback into account, I plan to prepare a patch
>>> renaming baseMoment to beatBase.
>> How about doing both rename and retyping to rational and kee
I don't think so.
Werner LEMBERG writes:
> Just curious: Is the 'top-posting' restriction on the LilyPond mailing
> lists still active? If yes, where and how is this enforced?
>
>
> Werner
>
>
--
David Kastrup
Dan Eble writes:
> On 2024-10-04 19:30, David Kastrup wrote:
>> I'd probably bring them into existence with something like
>> (define-compatibility-property 'baseMoment 'beatBase
>>ly:moment? ly:moment-main ly:make-moment)
>
> My battle with conve
Dan Eble writes:
> On 2024-10-04 17:58, David Kastrup wrote:
>> Dan Eble writes:
>>
>>> Taking all the feedback into account, I plan to prepare a patch
>>> renaming baseMoment to beatBase.
>> How about doing both rename and retyping to rational and kee
ack into account, I plan to prepare a patch
> renaming baseMoment to beatBase.
How about doing both rename and retyping to rational and keeping the old
property as a Moment-typed compatibility read/write accessor?
That would be less of a compatibility nightmare.
--
David Kastrup
Dan Eble writes:
> On 2024-10-04 03:59, David Kastrup wrote:
>
>> This isn't one. What is more of an issue that a lot of properties
>> taking a ly:moment? should rather be taking an exact rational
>> (because they will never have grace parts), and the reason tha
have exact rationals.
That is also the reason for the existence of functions like
ly:moment-mul and ly:moment-div which make no sense whatsoever in terms
of their argument and result types.
--
David Kastrup
lution guaranteed to work. Human relations are
both more flexible and more elusive. There is no guarantee anything
will work or fail other than trying and doing one's best in recovering
gracefully from failure.
--
David Kastrup
to the future of hel-arabic.ly.
--
David Kastrup
er off removing
that contribution than allowing it to contribute to a toxic work
environment driving more contributors away than it will draw in new
users.
Please try to do your part in keeping LilyPond pleasant to work with and
to work on.
Thank you
--
David Kastrup
question hadn't had
this impeccable timing, I'd not have mentioned it.
Talk about waxing nostalgic!
--
David Kastrup
s the surprise come from?
>
> Well, both `#+3` and `#-3` work, so it might be tempting to assume
> that `+3` and `-3` also work (outside of `\markup`).
So does ##e+3.0 and so does #3/1 so should we be supporting those as well?
--
David Kastrup
t. Yet.
`-` can become a part of numerical tokens in certain syntax modes, so it
isn't just the parser that is involved here but also the lexer.
> Can you imagine any other use for `+` right before numbers? Otherwise
> I suggest to make it work, to provide the least surprise for users.
Do we say anywhere that `+` is a sign in LilyPond syntax? Where does
the surprise come from?
--
David Kastrup
elling argument for wasting syntactic elements on doing nothing?
--
David Kastrup
Thomas Morley writes:
> Am Mo., 25. Dez. 2023 um 20:55 Uhr schrieb David Kastrup :
>>
>> Probably. Articulation events with a listener are removed (and
>> separately broadcast) from the articulations on a non-chord NoteEvent
>> before it is passed to its own engrav
Jean Abou Samra writes:
> Probably related to the code and comment in lily/rhythmic-music-iterator.cc.
Probably. Articulation events with a listener are removed (and
separately broadcast) from the articulations on a non-chord NoteEvent
before it is passed to its own engravers.
--
Da
an interest in that mess will be tasked with
the consequences, for better or worse.
--
David Kastrup
David Kastrup writes:
> Werner LEMBERG writes:
>
>>> Inspired by
>>> <https://music.stackexchange.com/questions/132340/lilypond-different-clefs-for-each-voice-on-one-staff>
>>>
>>> Should we be offering something like that?
>>
>> What
a
differently-weighted solution. I think that one would be more special,
though.
--
David Kastrup
\oneVoice
\change Staff = "lower" % change back to standard staff
}
>>
}
}
}
--
David Kastrup
y like it and I don't think it is our job to promote a
different style.
--
David Kastrup
LilyPond 10 years ago.
Feels like Carl Benz complaining about stick shift: just makes you
question your customer model.
--
David Kastrup
ublic all-translation-properties
> (append all-user-translation-properties
> all-internal-translation-properties))
> ```
>
> completely construct `all-translation-properties`. Why the additional
> `set!`?
Looks like an oversight in commit 7b22eeeee2505be517e58c3f922ddc53f1b7b0bd
--
David Kastrup
ection timed out
Uh-oh. It's been now several years since git-cl has no place whatsoever
in our workflow. I cannot find any reference to git-cl in our current
documentation, so can you figure out where you got a reference to it?
Thanks
--
David Kastrup
ge.html,web-big-page.it.html,web-big-page.ja.html,web-big-page.zh.html}
>
>
> Is that expected?
It looks to me like the "not accessible" file names are without any file
extension. That would make it unlikely that their size can be
determined. Something appears rotten.
--
David Kastrup
Jean Abou Samra writes:
> Le dimanche 09 juillet 2023 à 12:39 +0200, David Kastrup a écrit :
>> The build isn't broken unless you use bytecode compilation. Do we do
>> this in general?
>
>
> Depends on who is "we". I for one always build with bytecode beca
n. Do we do
this in general? Do we have a way of installing bytecode?
--
David Kastrup
Jean Abou Samra writes:
> Le vendredi 07 juillet 2023 à 14:43 +0200, Jean Abou Samra a écrit :
>> Le vendredi 07 juillet 2023 à 14:15 +0200, David Kastrup a écrit :
>> > Yikes. Looks like the bytecode compiler/optimizer/whatever converts (- )
>> > or
>&
- ) or something like it into (- 0 )
Without checking, this looks like a Guile problem, but that's not going
to help us. Huh. So this needs either a workaround or a revert of the
operator patch or some partial undo. I'll try to figure out more. I
haven't yet worked with bytecode.
--
David Kastrup
David Kastrup writes:
> Dan Eble writes:
>
>> On Jun 16, 2023, at 19:13, Jason Yip wrote:
>>>
>>> minSubdivideInterval and maxSubdivideInterval. They are both
>>> Rationals. Their numerator and denominator must be a power of 2. For
>>> each powe
That sounds like it would make more sense to specify those values in the
form of a "duration log", like the first argument to a ly:make-duration
call.
--
David Kastrup
work passing into general project reponsibility",
maintaining it under accounts with a possibly diverging interest (where
deletion is an extreme form of a diverging interest) does not appear
like the best policy to me.
--
David Kastrup
st, we filed some bug reports, IIRC).
>
> Thanks, that helps. However, I still don't understand what impact on
> size this makes. Do the two result in different PDF primitives?
I seem to remember that the second variant allowed Ghostscript to merge
subsetted fonts from included separate files.
--
David Kastrup
tream event (grobs reaching
the originating event only via another grob need a directed tweak
explicitly stating their grob name).
--
David Kastrup
rather seldom used, I reckon) and
> `convert-ly` emit a warning.
A default conversion of \text to \roman would likely match more than 90%
of the current uses.
--
David Kastrup
n music engravers have taken
> inspiration from the LilyPond attitude to engraving. The Dorico blog
> posts have been quite explicit about it, and maybe we could ask the
> MuseScore folks for comments too.
For better or worse, I think the main selling point of LilyPond these
days is not as much quality as workflow.
--
David Kastrup
John Wheeler writes:
> On 3/19/23 11:51, David Kastrup wrote:
>> So how to better involve others?
>
> Maybe a good place to start is by asking a few questions.
>
> What you would like these others to do?
Well, we are talking about core maintenance and rearchitecting here.
John Wheeler writes:
> On 3/19/23 11:51, David Kastrup wrote:
>
> When I was becoming familiar with the LilyPond manuals, it seemed to
> me one manual that was missing was a concise specification of the
> LilyPond language, something paralleling the R5RS for the Scheme
> langua
Jean Abou Samra writes:
> Le lundi 20 mars 2023 à 00:15 +0100, David Kastrup a écrit :
>
>> The MYBACKUP and MYPARSE stuff messes with the input in order to trigger
>> syntactic decisions based on expression values. That's a bit more than
>> usually expected
Jean Abou Samra writes:
> Le dimanche 19 mars 2023 à 17:51 +0100, David Kastrup a écrit :
>>
>> So how to better involve others? The parser may be one of those
>> areas with an awful amount of shoestring and glue, namely fiddling
>> around until things happen
David Zelinsky writes:
> David Kastrup writes:
>
>> But while my desire for work on user-pointing and internal design and
>> architecture at that time sort of unfolded mostly in a vacuum, the years
>> since then have not seen a lot of uptake.
> [...]
>> The
areas
with an awful amount of shoestring and glue, namely fiddling around
until things happen to work. All that fiddling happens in private
before commits end up in master, meaning that it has no opportunity to
end up contagious the way it happens now.
That's not really fabulous regarding the "bus factor" in that area.
--
David Kastrup
under the terms of the GNU General Public License as published by
> ```
>
> Thoughts?
"Mainly authored" relies on which metric? How are mechanical
reformattings not generally affecting the copyright situation catered
for? How is a generational update expounding on the original idea but
not leaving original code in place catered for?
--
David Kastrup
by complying with the GPL, you are complying with all
> the other relevant licences.
>
> So the effect of the GPL is that we can safely behave as if lilypond
> is completely GPL, while the legal reality is completely different.
"legal reality". Sigh. And of course you know much better about the
legal reality than the law professors consulted by the FSF.
--
David Kastrup
Wol writes:
> On 15/02/2023 17:08, David Kastrup wrote:
>> Wols Lists writes:
>>
>>> On 15/02/2023 02:01, David Kastrup wrote:
>>>>> Personally, I'd be happiest if everybody who updated a file was
>>>>> responsible for mak
Jean Abou Samra writes:
> Le mercredi 15 février 2023 à 18:05 +0100, David Kastrup a écrit :
>
>> No GNU program requiring a copyright assignment for working on it has
>> ceased doing so as far as I know,
>
> [Off-topic]
>
> Actually, both GCC and Guile h
Wols Lists writes:
> On 15/02/2023 02:01, David Kastrup wrote:
>>> Personally, I'd be happiest if everybody who updated a file was
>>> responsible for making sure the copyright date was updated
>>> appropriately,
>
>> That is going to work fantasticall
he fact).
> But if they DON'T require copyright assignment, and they DON'T own the
> copyright, then changing the copyright notice smacks of fraud.
The FSF does not change copyright notices of projects it is not in
charge of and I already explained why this statement is both wrong and
unnecessarily inflammatory.
> Simple as. BUT DOES ANYBODY REALLY CARE? Only the armchair lawyers, I
> guess :-)
I am not sure who you try to denigrate here and for what purpose.
--
David Kastrup
work is provided.
> Personally, I'd be happiest if everybody who updated a file was
> responsible for making sure the copyright date was updated
> appropriately,
That is going to work fantastically well, right? Distribute
responsibility until nobody feels responsible for anything and enjoy the
chaos.
--
David Kastrup
ed actually pressing the licensing
conditions (cf Harald Welte regarding the Linux kernel). That is the
same with LilyPond.
Mouthing off that the practices vetted extensively by the FSF lawyers
are fraudulent is really pointless.
--
David Kastrup
tracks local changes. If you are looking for the source of
some change, the grand replace has no impact on it.
I can understand this discussion about whitespace/formatting changes
(`git blame -w` helps and can be set as the default behavior). For the
grand replace, it seems like a nothingburger to me.
--
David Kastrup
--- End Message ---
--
David Kastrup
e must not introduce any workaround for
> such outdated systems.
Did you intent to write "need not" instead of "must not"? In German,
the negations of the corresponding words have other meanings than in
English.
--
David Kastrup
doing this for
> someone roughly my age),
On the Internet, nobody can measure the length of your beard.
--
David Kastrup
David Kastrup writes:
> Jean Abou Samra writes:
>
>> Le 14/01/2023 à 22:10, David Kastrup a écrit :
>>> What should it be?
>>
>>
>> I have no idea. My own gut feeling is that output defs need a redesign
>> and reimplementation from scratch anyway. In
Dan Eble writes:
> On Jan 26, 2023, at 12:22, David Kastrup wrote:
>>
>>c'' x2
>>
>
> That looks a lot like "twice" to me.
Ugh. Well, it would be a rare syntax discussion that had everybody on
the same page...
--
David Kastrup
Aaron Hill writes:
> On 2023-01-26 9:57 am, David Kastrup wrote:
>> Luca Fascione writes:
>>> I'd think that if 'x' meant "last pitch" and 'X' meant "last
>>> chord", things
>>> would be real peachy.
>>
n of using case distinction here (doesn't help that the German
accordion accompaniment notation uses c for a c major chord and C for a
single c root note).
Maybe xx for chords... Should be fast enough to type and is somewhat
mnemonic. At least more so than y .
--
David Kastrup
Aaron Hill writes:
> On 2023-01-23 3:35 pm, David Kastrup wrote:
>> p would require that there actually is a next pitch (or drum type,
>> assuming that p gets specialcased like r and R).
>
> I feel like I am missing context from the original query. '0' seems
>
Dan Eble writes:
> On Jan 23, 2023, at 18:05, David Kastrup wrote:
>>
>> Dan Eble writes:
>>
>>> On Jan 23, 2023, at 10:11, David Kastrup wrote:
>>>>
>>>> I am not saying that 0 is the best choice here. It merely appears to be
>>
iginal post. I had
> intended to fully call out that ** is exponentiation in some language,
> thus might not be the best symbol.
Well, mathematically c**4 in some sense is the same as c c c c . Not
saying that I find that compelling but it is some kind of argument.
--
David Kastrup
Jean Abou Samra writes:
> On 24/01/2023 00:41, David Kastrup wrote:
>> At any rate, postfix expressions require lookahead, and ** requires more
>> than one token of lookahead. What constructs would you see as
>> candidates before ** ?
>
>
> Without agreeing or
Aaron Hill writes:
> On 2023-01-23 3:35 pm, David Kastrup wrote:
>> p would require that there actually is a next pitch (or drum type,
>> assuming that p gets specialcased like r and R).
>
> I feel like I am missing context from the original query. '0' seems
>
nt mus)
> (number? ly:music?)
> #{
> \repeat unfold $count $mus
> #})
>
> {\time 7/8 \dup #3 a8 \dup #4 b16 c4}
> %
>
> If you don't like the name dup, you could use ru (short for repeat
> unfold)
"\\*" works as well, giving
{\time 7/8 \*3 a8 \*4 b16 c4}
--
David Kastrup
ns require lookahead, and ** requires more
than one token of lookahead. What constructs would you see as
candidates before ** ?
--
David Kastrup
o require a bit of
attention. The positive thing is that there already is a Scheme
representation, and there might be _some_ motivation to remove redundant
durations in \displayLilyMusic again when one can output
{ c'4 c' p2 } instead of the faulty { c'4 c' 2 } . But I am not sure
that removing redundancy would actually be a good thing.
--
David Kastrup
Dan Eble writes:
> On Jan 23, 2023, at 10:11, David Kastrup wrote:
>>
>> I am not saying that 0 is the best choice here. It merely appears to be
>> rather cheap. I thought of * and / but the first renders sequences like
>> c4*2 ambiguous and the second would at l
Benkő Pál writes:
> Jean Abou Samra ezt írta (időpont: 2023. jan.
> 22., V, 23:45):
>>
>> On 22/01/2023 23:38, David Kastrup wrote:
>> >
>> > There are situations where sticking with the default duration may make
>> > sense when something loo
y different look from the
usual c4 syntax for notes.
--
David Kastrup
1 - 100 of 1867 matches
Mail list logo
