David, I appreciate your work on this.
However, I am *not* in favor of moving in this direction to solve the problems you correctly identified. In my mind, the *last* thing we need is another opaque interface in LilyPond, where in the markup command we don't know whether a certain property is to be looked up in props or to be assigned a value in a let-binding from the define-internal-markup-command macro. I think it's *much* better to pass default values as appended values to the tail of props. Then we can go ahead and use a props lookup in the code. Thanks, Carl On 11/17/09 9:27 AM, "David Kastrup" <d...@gnu.org> wrote: > --- > scm/define-markup-commands.scm | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/scm/define-markup-commands.scm b/scm/define-markup-commands.scm > index 08c24bb..fec895d 100644 > --- a/scm/define-markup-commands.scm > +++ b/scm/define-markup-commands.scm > @@ -732,7 +732,6 @@ If there are no arguments, return an empty stencil. > stencils)) > (text-width (apply + text-widths)) > (word-count (length stencils)) > - (prop-line-width (chain-assoc-get 'line-width props #f)) > (line-width (or line-width (ly:output-def-lookup layout > 'line-width))) > (fill-space > (cond > @@ -3198,7 +3197,7 @@ where @var{X} is the number of staff spaces." > ((baseline-skip)) > "Like @code{\\column}, but return a list of lines instead of a single > markup. > @code{baseline-skip} determines the space between each markup in @var{args}." > - (space-lines (chain-assoc-get 'baseline-skip props) > + (space-lines baseline-skip > (interpret-markup-list layout props args))) > > (define-builtin-markup-list-command (override-lines layout props new-prop > args) > -- > 1.6.5.3.153.g0670 > > > > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel