Another change I was thinking about, is to redesign the API contracts
around interpret-markup-list.
Right now, we start from the list of markups, and for-each markup,
apply the markup function and destructively append! the resulting
stencil to the result list under construction.
The procedur
>> Of course, combine-score-stencils needs a real implementation, not just
>> (reverse stencils).
Ok, I created a patch:
http://codereview.appspot.com/207105
Boris Shingarov
Work on Lilypond under grant from Sonus Paradisi / Jiri Zurek (Prague),
Czech Science Foundation, Project No. 401/09/041
Le 12 févr. 2010 à 22:05, Neil Puttock a écrit :
> On 12 February 2010 04:50, Boris Shingarov wrote:
>
>> Of course, combine-score-stencils needs a real implementation, not just
>> (reverse stencils). But unfortunately, I do not understand what you mean by
>> space-lines. Could you explain in a
On 12 February 2010 21:14, Boris Shingarov wrote:
> Uh oh. Means I have to catch up with the latest master asap, otherwise I am
> producing obsolete, unmergeable code. Funny that I have not seen any
> discussion around this change, even though I am subscribed to -devel, -bug,
> and googlecode.
On Fri, Feb 12, 2010 at 04:14:55PM -0500, Boris Shingarov wrote:
> Uh oh. Means I have to catch up with the latest master asap, otherwise
> I am producing obsolete, unmergeable code. Funny that I have not seen any
> discussion around this change, even though I am subscribed to -devel,
> -bug,
Quoting Neil Puttock :
recent changes to the markup code (not least that there's no
define-builtin-markup-command any more).
Uh oh. Means I have to catch up with the latest master asap, otherwise
I am producing obsolete, unmergeable code.
Funny that I have not seen any discussion around th
On 12 February 2010 04:50, Boris Shingarov wrote:
> There are two problems.
> First, object life scope. The modification causes this:
>
> programming error: Parsed object should be dead: static scm_unused_struct*
> Grob::mark_smob(scm_unused_struct*)
> continuing, cross fingers
> programming erro
Quoting Nicolas Sceaux :
Why not defining e.g. a score-lines markup list command, which can be
used in situations where it is preferable to get one stencil per system.
Hmm, this is certainly an interesting idea; I am going to experiment
with it to see where it leads us.
My only possible obj
Le 12 févr. 2010 à 05:50, Boris Shingarov a écrit :
> Quoting Neil Puttock :
>
>> If you do this, you'll have to change the \score command to a
>> markup-list command, since a markup command can only return a single
>> stencil. This is problematic
>
> Here is some proof-of-concept code. I am s
Quoting Neil Puttock :
If you do this, you'll have to change the \score command to a
markup-list command, since a markup command can only return a single
stencil. This is problematic
Here is some proof-of-concept code. I am sure people will point out
how it is inconsistent with existing Lil
Quoting Neil Puttock :
If you do this, you'll have to change the \score command to a
markup-list command, since a markup command can only return a single
stencil
Well, you just described all the problems this leads to; so why not
relax the rule of markup command returning a single stencil?
On 10 February 2010 13:24, Boris Shingarov wrote:
> The fix, I believe, is to not perform the
> (stack-stencils Y DOWN baseline-skip ...) application; instead, leave just
> the (map paper-system-stencil ...) so each system becomes its own member of
> the markup list; then let the word wrapper p
Neil's recent modification to
(define-builtin-markup-command (score ...) ...), in
scm/define-markup-commands.scm, fixes the bug where only the first system was
printed, and now we can have multi-line embedded scores, by vertically stacking
the stencils instead of just selecting the first one.
13 matches
Mail list logo
