Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(5037)

Issue 6768064: Allow \tweak to act as a stand-in for \once\override (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
11 years, 6 months ago by dak
Modified:
11 years, 6 months ago
Reviewers:
CC:
lilypond-devel_gnu.org
Base URL:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git/trunk/
Visibility:
Public.

Description

Allow \tweak to act as a stand-in for \once\override This is actually again a three-commit series, but the changes should be reviewable together fine as well. The first commit implements check-grob-path and is confined entirely to scm/music-functions.scm. The real commit is in ly/music-functions-init.ly in the definition of \tweak, bringing its behavior in line with that of tweak-like commands. This necessitates a regtest change in input/regression/lyric-tweak.ly. The last commit are resulting simplifications elsewhere in ly/music-functions-init.ly. Here is the list of commit messages in reverse order: Let \footnote and \shape rely on \tweak for overrides Allow \tweak to act as a stand-in for \once\override Making tweak optionally accept a grob specification instead of music to tweak makes it compatible with the behavior of functions such as \footnote and \shape, and actually serves to simplify their implementation. One slight complication occurs in lyrics mode, as demonstrated by the change necessary to input/regression/lyric-tweak.ly: with \tweak #'color #red reddish fish, LilyPond tries an override for a grob named "reddish" and fails. Tweaks in lyrics mode are highly unusual, have not been supported for long, and their effect can usually better be accomplished in markup mode instead. The fix here is to write \tweak #'color #red \markup reddish fish, since LilyPond does not consider explicit markup a candidate for conversion into symbols. The same problem is inherent with other commands using the same kind of symbol-list-or-music? interface, like \footnote, \hide, \omit. Implement function check-grob-path for checking/extending grob path specs From the function documentation string: Check a grob path specification @var{path}, a symbol list (or a single symbol), for validity and possibly complete it. Returns the completed specification, or @code{#f} if invalid. If optional @var{parser} is given, a syntax error is raised in that case, optionally using @var{location}. If an optional keyword argument @code{#:start @var{start}} is given, the parsing starts at the given index in the sequence @samp{Context.Grob.property.sub-property...}, with the default of @samp{0} implying the full path. If there is no valid first element of @var{path} fitting at the given path location, an optionally given @code{#:default @var{default}} is used as the respective element instead without checking it for validity at this position. The resulting path after possibly prepending @var{default} can be constrained in length by optional arguments @code{#:min @var{min}} and @code{#:max @var{max}}, defaulting to @samp{1} and unlimited, respectively.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+118 lines, -29 lines) Patch
M input/regression/lyric-tweak.ly View 2 chunks +6 lines, -4 lines 0 comments Download
M ly/music-functions-init.ly View 3 chunks +36 lines, -25 lines 0 comments Download
M scm/music-functions.scm View 1 chunk +76 lines, -0 lines 0 comments Download

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b