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
