[Top][All Lists]

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

Re: LSR update?

From: Jean Abou Samra
Subject: Re: LSR update?
Date: Tue, 27 Dec 2022 15:24:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0

Le 27/12/2022 à 15:06, Thomas Morley a écrit :
Well, I started to update the snippets to 2.24.0 locally.

Thank you for doing this.

Do you intend to do them all, or do you need help?

Some observations:

I'm stuck with three snippets:
a) It's tagged "doc"
I've no clue how we get it into Snippets, though the image there is
wrong (compared with lsr).
For me it looks like the emitted .eps-files are replaced by .pdf-files
and then the snippet crashes.
How to fix?
Needs a complete rewrite!?

`barAlways' is gone, but the proposed replacement
`forbidBreakBetweenBarLines' does not what the snippet deserves.

I propose to just delete this snippet, and maybe replace
it with a snippet showing how to use forbidBreakBetweenBarLines.

I don't see what the use case for barAlways and defaultBarType != ""
could be (although it would still be possible with a Scheme engraver).

convert-ly emits a plethora of "not smart enough" messages for
\consists Mark_engraver
But why?
It's not outdated code!!
It's going on my nerves. I don't think we should use convert-ly to
educate our users to use the new possibilties, that's the duty of the
And there are still cases where \remove/consists Mark_engraver is what
the user wants, but these messages will persists forever.
I vote for simply deleting that convert-rule.

Disagreed. \consists Mark_engraver needs conversion in *some* cases.
The convert-ly rule is not advertising new possibilities, it's warning
about a potential needed update to get the same output as before.

The messages will not "persist forever" since convert-ly will
update the \version statement and the rule will not run afterwards.
(OK, LSR snippets don't have a \version line, but you'd run
convert-ly from the latest stable.)

It's not possible to do
lilypond *.ly
on all snippets.
Somewhere there's a bleed over, causing multiple
warnings/errors/crashes on otherwise clean compilimg snippets, when
compiled separately.
Worth researching I'd say, too tired right now though.

I think this is a lost cause. There is a lot of hacky Scheme code
in snippets and I think quite a few are not protected against

Here a list what I did else:

  [fixed manually]
  REMARK: Above is *not* obsolet

In the snippet file, you write:

"I don't think the snippet is obsolet, because we don't have a snippet explaining
how to print above *and* below"

Isn't it obvious once you know how to add a text mark above
and how to add a text mark below?

The latter (\tweak direction #DOWN) is shown in the official docs, maybe
we can add a snippet just for it.
  REMARK: Above will be replaced by the one from
/Doceumentation/snippets/new anyway
  REMARK: Above will be replaced by the one from
/Doceumentation/snippets/new anyway

  [fixed manually inside LSR]
  TODO Above lsr-image is wrong

  [won't fix]

  TODO guile message about `string-delete'

Can be fixed by just inverting the arguments to string-delete.

  TODO correct??

What do you mean by "TODO correct??" ?

  TODO needs fix at all?

Some snippets needs to get the description updated, mostly those about
multiple RehearsalMarks.
In many cases TextMark is used now...

I attach a tarball with the updated snippets from LSR's `all'
subfolder, though without the snippets from (1)


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

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