Axis_group_engraver + Scheme engraver for staff combining
It provides an intuitive user interface
to control whether shared or separate
staves are printed, and should work
for combinations of 4 or more parts.
Currently, Axis_group_engraver reads
keepAliveInterfaces into an internal
variable during process-music, then
uses the stored value during
acknowledge-grob.
In this patched it waits to read
keepAliveInterfaces during
acknowledge-grob.

On 2019/03/17 01:45:49, saul.james.tobin wrote:
> Re cdr is not a predicate — the list being processed here is composed of
> pairs, the cdr of which is ##t or ##f.
The description is still confusing. Do you mean something like below?
#(define (divide-true-cdr ls)
"Split @var{ls} into those elements which do and don't have a tail of value
@code{#t}"
(call-with-values
(lambda () (partition (lambda (x) (eq? #t (cdr x))) ls))
(lambda (a b) (list a b))))
#(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
=> (((2 . #t)) ((1 . #f) (3 . #f)))
>
> One question — is there a preferred way to get child contexts in Scheme?
> Can't seem to find such a thing in the documentation but maybe I'm missing
> something.
We have AnnounceNewContext which may help.
For an usage-example see:
https://lists.gnu.org/archive/html/bug-lilypond/2019-03/msg00011.html

thomasmorley65@gmail.com writes:
> On 2019/03/18 22:26:15, dak wrote:
>
>> The silence of the lambdas (almost):
>
>> #(define (divide-true-cdr ls)
>> "Split @var{ls} into those elements which don't and do have a tail of
>> value @code{#f}"
>> (call-with-values (lambda () (partition cdr ls)) list))
>
>> #(display (divide-true-cdr '((1 . #f) (2 . #t) (3 . #f))))
>> => (((2 . #t)) ((1 . #f) (3 . #f)))
>
>> --
>> David Kastrup
>
>
> Aargh, replacing `(lambda (a b) (list a b))´ with `list´ is ofcourse far
> better.
> I considered to use simple `cdr´ instead of `(lambda (x) (eq? #t (cdr
> x)))´, though one would need to ensure the `cdr´ is always a boolean,
> otherwise our procedures would return differently sometimes. Saul said
> so, though I thought better be paranoid than sorry ...
I have problems understanding how comparing with #t rather than #f is in
any sense better for a value presumed to be boolean. Why do you think
it is a good idea to consider 3.14 (say) equivalent to #f rather than #t
? I mean, nothing wrong with paranoia but to me this looks like bolting
the lampshade rather than some window.
> https://codereview.appspot.com/576540043/
--
David Kastrup