[EMAIL PROTECTED] writes:
> Currently, my greatest problem is to identify grobs so that I can
> modify their properties.
>
> I suggest a tool `grob' which accepts a LilyPond code fragment (either
> as an argument to the tool or read in interactively using
> e.g. readline), returning the context and grob.
>
> Example:
>
> grob a_"foo"
>
> should return something like this:
>
> `a': `Staff.NoteHead'
> `Staff.Stem'
> `"foo"': Staff.TextScript
>
> In case this isn't possible, I suggest to add a \what keyword to
> LilyPond which emits information on its argument to stdout (but having
> no other effect):
>
> \what a_"foo"
Try \apply #(lambda (x) (display x) x) ...
The problem has two components
* the mapping from syntax to parse trees is not entirely trivial. For
example
R1
is internall converted to
{ \spanrequest \start mmrest
s1
\spanrequest \start mmrest
}
what should \what return?
* There is no automated way to tell what will happen to a specific
music event. I'm planning to add this, but that will have to wait
until after 1.6. This means that information is added to the
engravers, so that you can click all the way from NoteHead to
Note_req (the input event). It will speed things up, and lily can
be made more transparent.
> The trial-and-error method which is necessary at the moment due to
> lacking documentation costs way too much time.
Can you be more specific about "lacking documentation"? I recently
added a section on adjusting output to the tutorial, which explains
how to go about tweaking.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen
_______________________________________________
Bug-lilypond mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-lilypond
