Deprecate \fermataMarkup for full-bar rests.

Deprecate \fermataMarkup for full-bar rests.

[Neil Puttock, 2011-08-07 15:24:42]

Hi,

I've always been a bit annoyed by this, so I though it would be a nice
enhancement to allow scripts to work on full-bar rests just like ordinary
markup.

The syntax constructor already makes a half-hearted attempt to add scripts, but
fails in trying to set the 'text property, since it doesn't extract the useful
information from an ArticulationEvent.  By accessing all-script-definitions, it
now caters for all types of fermata without having to define them manually:

{
  R1\fermata
  R1\longfermata
}

As an added bonus, \displayLilyMusic works properly with the above, whereas the
original \fermataMarkup caused it to crash.

Cheers,
Neil

[Trevor Daniels, 2011-08-07 16:01:48]

Nice!  LGTM.
Will need some doc changes too.
Should we deprecate \fermataMarkup?

http://codereview.appspot.com/4672059/diff/1/scm/ly-syntax-constructors.scm
File scm/ly-syntax-constructors.scm (right):

http://codereview.appspot.com/4672059/diff/1/scm/ly-syntax-constructors.scm#n...
scm/ly-syntax-constructors.scm:157: 'tweaks tweaks
tabs

http://codereview.appspot.com/4672059/diff/1/scm/ly-syntax-constructors.scm#n...
scm/ly-syntax-constructors.scm:158: 'text text)))
tabs

[Neil Puttock, 2011-08-07 16:13:50]

On 7 August 2011 17:01,  <tdanielsmusic@googlemail.com> wrote:
> Nice!  LGTM.

Thank you.

> Will need some doc changes too.

Indeed.  I'll sort that out later (+ a regression test to exercise the
code properly).

> Should we deprecate \fermataMarkup?

I think so.  A convert rule would be reliable since it's just a substitution.

Cheers,
Neil

[x.scheuer_gmail.com, 2011-08-07 16:31:10]

On 7 August 2011 17:24,  <n.puttock@gmail.com> wrote:
>
> Reviewers: ,
>
> Message:
> Hi,
>
> I've always been a bit annoyed by this, so I though it would be a nice
> enhancement to allow scripts to work on full-bar rests just like
> ordinary markup.
>
> The syntax constructor already makes a half-hearted attempt to add
> scripts, but fails in trying to set the 'text property, since it doesn't
> extract the useful information from an ArticulationEvent.  By accessing
> all-script-definitions, it now caters for all types of fermata without
> having to define them manually:
>
> {
>  R1\fermata
>  R1\longfermata
> }
>
> As an added bonus, \displayLilyMusic works properly with the above,
> whereas the original \fermataMarkup caused it to crash.

That would be a nice improvement in syntax simplification and better
accessibility to users (i.e. less problems and questioning messages).

Cheers,
Xavier

-- 
Xavier Scheuer <x.scheuer@gmail.com>

[Reinhold, 2011-08-07 19:21:32]

LGTM. I have always wondered why \fermataMarkup was necessary.

http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly
File ly/property-init.ly (right):

http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly#newcode189
ly/property-init.ly:189: fermataMarkup = \fermata
How about a wrapper to mark definitions/functions as deprecated, so they print
out a warning, but still work?
I usually prefer deprecating functions (plus a convert-ly rule) to completely
removing a definition.

We can also move such definitions to e.g. deprecated.ly, so we can in future
versions easily remove them, once the users had enough time to update their
scores.

[Neil Puttock, 2011-08-07 19:41:43]

On 7 August 2011 20:21,  <reinhold.kainhofer@gmail.com> wrote:

> http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly
> File ly/property-init.ly (right):
>
> http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly#newcode189
> ly/property-init.ly:189: fermataMarkup = \fermata
> How about a wrapper to mark definitions/functions as deprecated, so they
> print out a warning, but still work?

That sounds great, though I'd be concerned about the overhead: surely
every lookup via Lily_lexer::lookup_identifier () would need a
deprecation check (probably using an object property).

Cheers,
Neil

[reinhold_kainhofer.com, 2011-08-07 19:48:58]

Am Sunday, 7. August 2011, 21:41:42 schrieb Neil Puttock:
> On 7 August 2011 20:21,  <reinhold.kainhofer@gmail.com> wrote:
> > http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly
> > File ly/property-init.ly (right):
> > 
> > http://codereview.appspot.com/4672059/diff/1/ly/property-init.ly#newcode1
> > 89 ly/property-init.ly:189: fermataMarkup = \fermata
> > How about a wrapper to mark definitions/functions as deprecated, so they
> > print out a warning, but still work?
> 
> That sounds great, though I'd be concerned about the overhead: surely
> every lookup via Lily_lexer::lookup_identifier () would need a
> deprecation check (probably using an object property).

I wouldn't go that lowlevel. I rather thought about a scheme function that 
prints a ly:warning and then returns the new definition (or calls the new 
function).

Cheers,
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, reinhold@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

[Neil Puttock, 2011-08-07 20:55:31]

On 7 August 2011 20:48, Reinhold Kainhofer <reinhold@kainhofer.com> wrote:

> I wouldn't go that lowlevel. I rather thought about a scheme function that
> prints a ly:warning and then returns the new definition (or calls the new
> function).

How would you prevent the deprecation warning from being issued when
the identifier is created?

Cheers,
Neil

[janek, 2011-08-23 22:36:30]

This one is very nice!
I vote for deleting \fermataMarkup altogether.
Will it be also possible to deprecate MultiMeasureRestText?  It's confusing too.

Added a tracker issue: http://code.google.com/p/lilypond/issues/detail?id=1833

thanks, Neil!
Janek

[pkx166h, 2011-08-24 21:13:08]

passes make and reg tests

[Neil Puttock, 2011-09-05 15:48:53]

On 2011/08/07 19:48:58, reinhold_kainhofer.com wrote:

> I wouldn't go that lowlevel. I rather thought about a scheme function that 
> prints a ly:warning and then returns the new definition (or calls the new 
> function).

Well, it turns out my idea for object properties wouldn't work anyway since the
identifier is contained in an anonymous variable object which can't access an
object property.

One other possibility would be to create a promise and force it when looking up
the identifier.

Cheers,
Neil
> 
> Cheers,
> Reinhold
> -- 
> ------------------------------------------------------------------
> Reinhold Kainhofer, mailto:reinhold@kainhofer.com,
http://reinhold.kainhofer.com/
>  * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
>  * http://www.fam.tuwien.ac.at/, DVR: 0005886
>  * LilyPond, Music typesetting, http://www.lilypond.org