Add an example implementation of cross-staff stems

Add an example implementation of cross-staff stems

[Pavel Roskin, 2012-03-23 13:04:19]

This is also the first use of a scheme engraver in input/regression.

[dak, 2012-03-23 13:12:56]

http://codereview.appspot.com/5882053/diff/2001/input/regression/stem-cross-s...
File input/regression/stem-cross-staff-engraver.ly (right):

http://codereview.appspot.com/5882053/diff/2001/input/regression/stem-cross-s...
input/regression/stem-cross-staff-engraver.ly:100: `((acknowledgers
Why don't you use make-engraver here?  Instead of the backquoted list, you write

(make-engraver
 (acknowledgers
  ((stem-interface trans grob source)
   (set! stems (cons grob stems))))	
 ((process-acknowledged trans)
  (make-stem-spans! ctx stems trans)
  (set! stems '())))

It is easier on the eyes.

[dak, 2012-03-23 13:16:01]

On 2012/03/23 13:04:19, Pavel Roskin wrote:
> This is also the first use of a scheme engraver in input/regression.

Apart from scheme-engraver.ly, scheme-engraver-instance.ly, and
scheme-text-spanner.ly.

[Pavel Roskin, 2012-03-23 21:46:41]

OK, I'll use make-engraver in the next revision.  I guess I'll need to strip all
Lilypond 2.14 compatibility stuff if this snippet is to be a part of the
Lilypond documentation.  I missed scheme engravers because I was looking for
"\consists #" on one line, my bad.

[dak, 2012-03-24 08:19:29]

On 2012/03/23 21:46:41, Pavel Roskin wrote:
> OK, I'll use make-engraver in the next revision.  I guess I'll need to strip
all
> Lilypond 2.14 compatibility stuff if this snippet is to be a part of the
> Lilypond documentation.

In LilyPond itself, it makes sense to document the latest version.  If people
read 2.16 documentation, they can't expect to see stuff that is guaranteed to
work under 2.14.

It is not uncommon for some new features to be only discernible from regtests. 
That is not really good.  This is the current state for Scheme engravers.  It
would be good to have some nice examples for Scheme engravers in the
documentation.

This particular case is, in my opinion, too complex for either documentation or
a targeted regtest.  It is LSR material, or should become part of LilyPond
proper if one can think of a good way.  Note that we have snippets in the
LilyPond documentation/repository as well: those can use the newest features. 
That would be the proper place, I think.

We still need to get Scheme engravers into the main documentation.

[Graham Percival, 2012-03-26 06:06:41]

The basic question is this: is this test helpful for programmers?  At first
glance I'd say that it is, provided that you update the syntax as David
suggested.

IMO it takes a pretty silly example for something to *not* be a helpful test
case.  Sure, having complicated scheme here might mean that future changes to
some scheme interfaces would need to update this file as well, but IMO that's a
perfectly legitimate function of a regtest!

Now, this test might be useful as a LSR snippet as well, so you may want to
consider sending it there (at least once LSR supports 2.16).  Until that
happens, it could got to Documentation/snippets/new, but I recommend asking
James or Phil to handle that part of it.

[Graham Percival, 2012-03-29 01:18:50]

LGTM; since it's just a snippet now, I support pushing it directly as long as it
compiles.