Re: Opinions requested on deprecating "annotation" commands

[Urs Liska]

Am 01.07.2018 um 20:27 schrieb N. Andrew Walsh:

Hi Urs, List

On Sun, 1 Jul 2018, 00:08 Urs Liska > wrote:


Hi Simon and Craig,

I think it's a good point. And since maybe I'll have to suffer
more than anyone else ;-) I shouldn't wring my hands too much and
just go for that.

I'll consent to slogging through all our Kayser project to update the 
annotations if it means getting this very excellent feature implemented.


That can serve as a litmus test for a scripted conversion ;-) Maybe we 
can even provide a script that assists users to update their documents 
like convert-ly does for regular LilyPond files.
The issue I see here is that currently we have so many open working 
branches, which will complicate the situation significantly. Probably we 
should just do the change to the scholarly.annotate.legacy module until 
we have merged the branches ...


Best
Urs



Cheers,

A


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[N. Andrew Walsh]

Hi Urs, List

On Sun, 1 Jul 2018, 00:08 Urs Liska  wrote:

> Hi Simon and Craig,
>
> I think it's a good point. And since maybe I'll have to suffer more than
> anyone else ;-) I shouldn't wring my hands too much and just go for that.
>
I'll consent to slogging through all our Kayser project to update the
annotations if it means getting this very excellent feature implemented.

Cheers,

A
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[Urs Liska]

Am 01.07.2018 um 00:08 schrieb Urs Liska:


Hi Simon and Craig,

I think it's a good point. And since maybe I'll have to suffer more 
than anyone else ;-) I shouldn't wring my hands too much and just go 
for that.


There will be a Git tag referencing the latest state of the "old" 
interface, and it should be possible to use that for existing 
projects. Of course when someone wants to make use of the additional 
functionality they'd have to update their projects but for others this 
should at least work as long as LilyPond progress won't make things 
incompatible.




I've found a better solution: I've moved the code for the 
\criticalRemark functions and friends to a new module 
scholarly.annotate.legacy. So for existing documents just the 
\loadModule command has to be changed and the legacy commands can be 
used. The best part about this is that I didn't even have to duplicate 
any code, just redistribute it over two files and have one include the 
other ...


Best
Urs


Best
Urs


Am 01.07.2018 um 00:04 schrieb Craig Dabelstein:
I'm happy to go with the consensus. Breaking any of my old documents 
won't be an issue for me, and I'm happy to defer to your expertise.


Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht > wrote:


On 30.06.2018 14:14, Urs Liska wrote:
> # Encourage people to use the new system and "deprecate" the
old syntax
> (but leave it alone and working). The downside is that the
*names* of
> the old commands are very much what one would want, so I
wouldn't want
> to discard them completely.
> # Make the old names wrappers around the new technology, so one
can
> still say \criticalRemark.

I’d vote for the latter. Better to make a clean cut, and there’s
so much
potential in this, and the number of users seems to be limited
until now
in my perspective – I may be wrong.

Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-user



--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/




___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[Urs Liska]

Hi Simon and Craig,

I think it's a good point. And since maybe I'll have to suffer more than 
anyone else ;-) I shouldn't wring my hands too much and just go for that.


There will be a Git tag referencing the latest state of the "old" 
interface, and it should be possible to use that for existing projects. 
Of course when someone wants to make use of the additional functionality 
they'd have to update their projects but for others this should at least 
work as long as LilyPond progress won't make things incompatible.


Best
Urs


Am 01.07.2018 um 00:04 schrieb Craig Dabelstein:
I'm happy to go with the consensus. Breaking any of my old documents 
won't be an issue for me, and I'm happy to defer to your expertise.


Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht > wrote:


On 30.06.2018 14:14, Urs Liska wrote:
> # Encourage people to use the new system and "deprecate" the old
syntax
> (but leave it alone and working). The downside is that the
*names* of
> the old commands are very much what one would want, so I
wouldn't want
> to discard them completely.
> # Make the old names wrappers around the new technology, so one can
> still say \criticalRemark.

I’d vote for the latter. Better to make a clean cut, and there’s
so much
potential in this, and the number of users seems to be limited
until now
in my perspective – I may be wrong.

Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org 
https://lists.gnu.org/mailman/listinfo/lilypond-user



--
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com 
/http://maximesmusic.com/


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[Craig Dabelstein]

I'm happy to go with the consensus. Breaking any of my old documents won't
be an issue for me, and I'm happy to defer to your expertise.

Craig

On Sat, 30 Jun 2018 at 23:13, Simon Albrecht  wrote:

> On 30.06.2018 14:14, Urs Liska wrote:
> > # Encourage people to use the new system and "deprecate" the old syntax
> > (but leave it alone and working). The downside is that the *names* of
> > the old commands are very much what one would want, so I wouldn't want
> > to discard them completely.
> > # Make the old names wrappers around the new technology, so one can
> > still say \criticalRemark.
>
> I’d vote for the latter. Better to make a clean cut, and there’s so much
> potential in this, and the number of users seems to be limited until now
> in my perspective – I may be wrong.
>
> Best, Simon
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>


-- 
*Craig Dabelstein*
Maxime's Music
craig.dabelst...@gmail.com
*http://maximesmusic.com *
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Opinions requested on deprecating "annotation" commands

[Simon Albrecht]

On 30.06.2018 14:14, Urs Liska wrote:
# Encourage people to use the new system and "deprecate" the old syntax 
(but leave it alone and working). The downside is that the *names* of 
the old commands are very much what one would want, so I wouldn't want 
to discard them completely.
# Make the old names wrappers around the new technology, so one can 
still say \criticalRemark.


I’d vote for the latter. Better to make a clean cut, and there’s so much 
potential in this, and the number of users seems to be limited until now 
in my perspective – I may be wrong.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Opinions requested on deprecating "annotation" commands

[Urs Liska]

Hi,

as you know I'm working on a number of features around the scholarLY 
package, and now I'm facing the need to deal with the existing interface.


The openLilyLIb module scholarly.annotate provides commands like 
\criticalRemark, \musicalIssue and a few more that attach an annotation 
to a score element.


Now, while implementing the commands \tagSpan and \editorialMarkup that 
"tag" some music as a finding or editorial decision I gave them the 
capability to also create and attach annotations. And since the function 
interface to \criticalRemark and friends is somewhat clumsy and limited 
in its capability to addressing the annotated music I would like to make 
the \tagSpan approach the new standard.


I see two options, both with disadvantages:

 * Encourage people to use the new system and "deprecate" the old
   syntax (but leave it alone and working). The downside is that the
   *names* of the old commands are very much what one would want, so I
   wouldn't want to discard them completely.
 * Make the old names wrappers around the new technology, so one can
   still say \criticalRemark.

The second solution would definitely be what I want the package to 
behave like. Basically the following two statements would then be 
equivalent:


 * \editorialMarkup annotation \with { ann-type = critical-remark
   message = "My comment" } { c' d' e' }
 * \criticalRemark \with { message = "My comment" } { c' d' e'}

The problem with this is that it would of course break existing 
documents. Of course package development is still in a version 0.X 
state, so breaking changes are definitely not "illegal", but I would 
actually prefer to get some feedback before going into that direction.


I think for most of the cases it would be possible to create a scripted 
solution to update instances (like convert-ly), but I'm reluctant to 
make any promises about that:


\criticalRemark \with {
  message = "Hey"
} NoteHead c'

=>

\critical
Remark \with {
  message = "Hey"
} c'

\musicalIssue \with {
  message = "Hey"
} Accidental cis'

=>
\musicalIssue \with {
  message = "Hey"
  item = Accidental
} cis'

but I'm not sure about the other valid syntax options, and not about all 
the things that could go wrong when comments in the \with block might 
confuse the parser.


Any opinions?

Best
Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user