Re: Determining what parameters exist for an item

[David Nalesnik]

On Mon, Jan 25, 2016 at 1:47 PM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Harm,
>
> > if a property is settable, this does not mean your setting takes any
> effect.
> > I don't speak of user-errors in syntax, missing context, etc, but
> > sometimes an engraver does not listen to a certain property, maybe
> > because it's hard-coded or not really needed or for other good reasons.
>
> Excellent point. I’m sure it’s a pie-in-the-sky thought… but…
>
> Is there a way, in your [wonderful] list of _all_ properties, to have Lily
> automatically say which will have an effect?
> Or is that as simple as “adjusting a property will have an effect if and
> only if it’s listed on the grob’s ‘homepage’ in the IR”?
>

Just because a grob supports a certain interface doesn't guarantee that
there's code written to handle all of the interface's properties for that
particular grob.  Also, an overridable property doesn't necessarily have a
default value listed in the IR: 'color, for example.

DN
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-25 21:00 GMT+01:00 David Nalesnik :
>
>
> On Mon, Jan 25, 2016 at 1:47 PM, Kieren MacMillan
>  wrote:
>>
>> Hi Harm,
>>
>> > if a property is settable, this does not mean your setting takes any
>> > effect.
>> > I don't speak of user-errors in syntax, missing context, etc, but
>> > sometimes an engraver does not listen to a certain property, maybe
>> > because it's hard-coded or not really needed or for other good reasons.
>>
>> Excellent point. I’m sure it’s a pie-in-the-sky thought… but…
>>
>> Is there a way, in your [wonderful] list of _all_ properties, to have Lily
>> automatically say which will have an effect?

No.

To illustrate:
TextScript has 'font-name as a property, but setting it will not
always have an effect!!

'font-name in musicglyph-markup-command is hardcoded to #f, otherwise
LilyPond would try to take it from "TeX Gyre Chorus" in the example
below, with little chance for nice output, I'd say ...

{
  \override TextScript.font-name = "TeX Gyre Chorus"
  a'1-\markup { "This is a clef:  " \musicglyph #"clefs.G" }
}

This is only one single example (there are other markup-commands doing
similar) for one single grob...

>> Or is that as simple as “adjusting a property will have an effect if and
>> only if it’s listed on the grob’s ‘homepage’ in the IR”?

Again, no.
See, David's explanation, below.

>
>
> Just because a grob supports a certain interface doesn't guarantee that
> there's code written to handle all of the interface's properties for that
> particular grob.  Also, an overridable property doesn't necessarily have a
> default value listed in the IR: 'color, for example.
>
> DN

Sorry,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 25.01.2016 10:19, David Kastrup wrote:

e.g. ‘Offset KeyCancellation’s X-extent by #'(0 . 2) (so it will have
>two units whitespace at the right), regardless of how wide it would
>normally be’. That would be a very powerful use case for \offset, if
>also the technical limitations might be non-trivial.

Any reason you can't use extra-spacing-width here?


No. This wasn’t an actual use case, only a random example where one 
might think of using \offset.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Harm,

> if a property is settable, this does not mean your setting takes any effect.
> I don't speak of user-errors in syntax, missing context, etc, but
> sometimes an engraver does not listen to a certain property, maybe
> because it's hard-coded or not really needed or for other good reasons.

Excellent point. I’m sure it’s a pie-in-the-sky thought… but…

Is there a way, in your [wonderful] list of _all_ properties, to have Lily 
automatically say which will have an effect?
Or is that as simple as “adjusting a property will have an effect if and only 
if it’s listed on the grob’s ‘homepage’ in the IR”?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Sumbler]

On Mon, 2016-01-25 at 10:26 +0100, David Kastrup wrote:
> David Sumbler  writes:
> 
> >> From: David Nalesnik 
> >
> > 
> >> \offset only works on properties that have a default value listed in
> >> the grob pages in the IR (derived from the alist in
> >> scm/define-grobs.scm).  There is no default value listed for
> >> KeyCancellation.X-extent, hence the warning.
> > 
> >
> > This "\offset" sounds very interesting.  But I can find nothing about it
> > in the documentation.  It isn't indexed in any of the Lilypond
> > manuals.
> 
> Huh?
> 
> http://lilypond.org/doc/v2.19/Documentation/notation/available-music-functions#index-offset
> 
> Granted, the entry is lacklustre.

Ah - I hadn't thought of looking there, because most (all?) of the other
music functions are listed in NR Appendix D.  Should it not be added
there too?

My apologies for forgetting to change the subject line on my previous
e-mail to the list.

David S



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 25.01.2016 00:55, David Nalesnik wrote:


\offset only works on properties that have a default value listed in 
the grob pages in the IR (derived from the alist in 
scm/define-grobs.scm).  There is no default value listed for 
KeyCancellation.X-extent, hence the warning.


Well, the point was that exactly for this case it would be great to tell 
lily ‘Increase this property by two, no matter what it previously was’, 
e.g. ‘Offset KeyCancellation’s X-extent by #'(0 . 2) (so it will have 
two units whitespace at the right), regardless of how wide it would 
normally be’. That would be a very powerful use case for \offset, if 
also the technical limitations might be non-trivial.


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Kastrup]

Simon Albrecht  writes:

> On 25.01.2016 00:55, David Nalesnik wrote:
>>
>> \offset only works on properties that have a default value listed in
>> the grob pages in the IR (derived from the alist in
>> scm/define-grobs.scm).  There is no default value listed for
>> KeyCancellation.X-extent, hence the warning.
>
> Well, the point was that exactly for this case it would be great to
> tell lily ‘Increase this property by two, no matter what it previously
> was’,

Does anything even look at the grob property here?

> e.g. ‘Offset KeyCancellation’s X-extent by #'(0 . 2) (so it will have
> two units whitespace at the right), regardless of how wide it would
> normally be’. That would be a very powerful use case for \offset, if
> also the technical limitations might be non-trivial.

Any reason you can't use extra-spacing-width here?

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi Carl,
>
>> 4) Going to one of these interfaces […]
>> provides a list of user-settable properties for that interface
>
> Yes, but unless I’m missing something, you can’t find the default
> value(s) there, right?

Interfaces don't have default values.  Grobs have.

> I personally would love to be able to get, for any grob, a list of
> every settable value (“native” or “interfaced”) *including the default
> value for each setting*.

You mean, something like


3.1.24 ChordName


ChordName objects are created by: *note Chord_name_engraver::.

   Standard settings:

 ‘after-line-breaking’ (boolean):
  ‘ly:chord-name::after-line-breaking’

  Dummy property, used to trigger callback for
  ‘after-line-breaking’.

 ‘extra-spacing-height’ (pair of numbers):
  '(0.2 . -0.2)

  In the horizontal spacing problem, we increase the height of
  each item by this amount (by adding the ‘car’ to the bottom of
  the item and adding the ‘cdr’ to the top of the item).  In
  order to make a grob infinitely high (to prevent the
  horizontal spacing problem from placing any other grobs above
  or below this grob), set this to ‘(-inf.0 . +inf.0)’.

 ‘extra-spacing-width’ (pair of numbers):
  '(-0.5 . 0.5)

  In the horizontal spacing problem, we pad each item by this
  amount (by adding the ‘car’ on the left side of the item and
  adding the ‘cdr’ on the right side of the item).  In order to
  make a grob take up no horizontal space at all, set this to
  ‘(+inf.0 . -inf.0)’.

 ‘font-family’ (symbol):
  ‘'sans’

  The font family is the broadest category for selecting text
  fonts.  Options include: ‘sans’, ‘roman’.

 ‘font-size’ (number):
  ‘1.5’

  The font size, compared to the ‘normal’ size.  ‘0’ is
  style-sheet’s normal size, ‘-1’ is smaller, ‘+1’ is bigger.
  Each step of 1 is approximately 12% larger; 6 steps are
  exactly a factor 2 larger.  If the context property ‘fontSize’
  is set, its value is added to this before the glyph is
  printed.  Fractional values are allowed.

 ‘stencil’ (stencil):
  ‘ly:text-interface::print’

  The symbol to print.

 ‘word-space’ (dimension, in staff space):
  ‘0.0’

  Space to insert between words in texts.

 ‘Y-extent’ (pair of numbers):
  ‘# >’

  Extent (size) in the Y direction, measured in staff-space
  units, relative to object’s reference point.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> Interfaces don't have default values.  Grobs have.

That’s my point.

> You mean, something like
> 3.1.24 ChordName

Well, that’s *those* values…
Those are the ones Charles and I (and, I assume, others) know how to find 
easily.

What, though, is the default value for ChordName.baseline-skip [via 
text-interface]? And all the other values for settings available via 
chord-name-interface, font-interface, grob-interface, item-interface, 
outside-staff-interface, rhythmic-grob-interface and text-interface?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> Interfaces don't have default values.  Grobs have.
>
> That’s my point.
>
>> You mean, something like
>> 3.1.24 ChordName
>
> Well, that’s *those* values…
> Those are the ones Charles and I (and, I assume, others) know how to
> find easily.
>
> What, though, is the default value for ChordName.baseline-skip [via
> text-interface]?

Uh, unset?  It's not listed.  Cf

\new ChordNames
\chordmode
{
  \applyOutput ChordNames.ChordName #(lambda (g c p) (display (ly:grob-property 
g 'baseline-skip)))
  c1
}

which outputs () as expected.

> And all the other values for settings available via
> chord-name-interface, font-interface, grob-interface, item-interface,
> outside-staff-interface, rhythmic-grob-interface and text-interface?

Unset?  I don't really know what you are talking about.  Layout
properties rather than grob properties?  Those are, unless overriden by
a grob, global.  But their values may well depend on stuff like the
current staff size and your preferred style sheets so there is not
really a lot that could actually be listed with some confidence.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> \new ChordNames
> \chordmode
> {
>  \applyOutput ChordNames.ChordName #(lambda (g c p) (display 
> (ly:grob-property g 'baseline-skip)))
>  c1
> }

That’s a helpful funcion — thanks!

> Those are, unless overriden by a grob, global.

Exactly. As far as the user cares, the setting has a value, even if it’s global.

If I don’t override ChordName.baseline-skip, and my ChordName has a column, the 
baseline still skips a certain/exact/known distance. By trial-and-error, I can 
find that the default is likely 3:

%%%  SNIPPET BEGINS
\version "2.19.35"

testing = \chordmode {
  \override ChordName.stencil = #ly:text-interface::print
  \override ChordName.text = \markup \column { first second }
  c1
  \override ChordName.baseline-skip = #5
  c1
  \override ChordName.baseline-skip = #3
  c1
}

\score {
  \new ChordNames \testing
}
%%%  SNIPPET ENDS

> But their values may well depend on stuff like the
> current staff size and your preferred style sheets so there is not
> really a lot that could actually be listed with some confidence.

At that point, I say, "Let the user beware.”

My question is: Is there a way to iterate your property display function (or 
similar) through all available properties of a grob, and output as a single 
list (alphabetically, if possible) the current/default value [e.g., 
ChordName.baseline-skip appears to be 3 by default, or in any case was at the 
time my snippet began compiling]?

Thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi David,

> it would be easier if you did not do creative editing in order to
> let everything disappear not meeting your preconceptions.

It’s not clear what you’re talking about… but anyway…

It’s still perfectly clear to me — and, it seems, Charles and others — that 
Lilypond has grobs, and those grobs have properties, and those properties have 
values, and the default values of some of those properties are not easily 
determinable by the [beginning?] user.

Three examples which I just pulled at total random are
Beam.beam-thickness (via beam-interface)
NoteHead.break-visibility (via item-interface)
KeyCancellation.font-size (via font-interface)

I don’t see anywhere in the documentation where I can find what those default 
values are.

Regards,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 18:22, Kieren MacMillan wrote:

Lilypond has grobs, and those grobs have properties, and those properties have 
values,


I think the point is that some properties either do not have values at 
all, or those values are determined during compilation, depending on 
other circumstances.



  and the default values of some of those properties are not easily 
determinable by the [beginning?] user.

Three examples which I just pulled at total random are
 Beam.beam-thickness (via beam-interface)


Beam thickness is certainly a multiple of staff line thickness, so its 
value can’t be told in general.



 NoteHead.break-visibility (via item-interface)


This is clearly a property which is unset, and remains unset, and for 
good reasons: Why would the visibility of a NoteHead depend on line 
breaks? In fact, tests show that a NoteHead is always considered to be 
‘unbroken’ (= mid-line), so \override NoteHead.break-visibility = ##(#t 
#f #t) will make all NoteHeads invisible, and the first and third values 
in the vector don’t matter at all.



 KeyCancellation.font-size (via font-interface)


It turns out that this can’t be overridden at all.

I hope this helps enlighten matters.

Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> At that point, I say, "Let the user beware.”
>
> My question is: Is there a way to iterate your property display
> function (or similar) through all available properties of a grob, and
> output as a single list (alphabetically, if possible) the
> current/default value [e.g., ChordName.baseline-skip appears to be 3
> by default, or in any case was at the time my snippet began
> compiling]?

Look, it would be easier if you did not do creative editing in order to
let everything disappear not meeting your preconceptions.  You are not
talking about grob properties but markup properties, in this case
inherited from the paper block.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> it would be easier if you did not do creative editing in order to
>> let everything disappear not meeting your preconceptions.
>
> It’s not clear what you’re talking about… but anyway…
>
> It’s still perfectly clear to me — and, it seems, Charles and others —
> that Lilypond has grobs, and those grobs have properties, and those
> properties have values, and the default values of some of those
> properties are not easily determinable by the [beginning?] user.
>
> Three examples which I just pulled at total random are
> Beam.beam-thickness (via beam-interface)

LilyPond internals:

3.1.19 Beam
---

Beam objects are created by: *note Auto_beam_engraver::, *note
Beam_engraver::, *note Chord_tremolo_engraver::, *note
Grace_auto_beam_engraver:: and *note Grace_beam_engraver::.

   Standard settings:

 ‘auto-knee-gap’ (dimension, in staff space):
  ‘5.5’

  If a gap is found between note heads where a horizontal beam
  fits that is larger than this number, make a kneed beam.

 ‘beam-thickness’ (dimension, in staff space):
  ‘0.48’

  Beam thickness, measured in ‘staff-space’ units.

[...]

What do you think that 0.48 is supposed to be?

In the Internals Reference.

> NoteHead.break-visibility (via item-interface)

Unset, so default behavior.  Namely everything's visible.  Not a really
surprising default.

> KeyCancellation.font-size (via font-interface)

Unset, so default behavior.  font-size is documented (in the Internals
Reference) as following a context property fontSize when present.

> I don’t see anywhere in the documentation where I can find what those
> default values are.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi again,

Here’s a perfect example of what I’m talking about…

For KeyCancellation, the output of Harm’s function includes

 GROB-INTERFACE
X-extent:
(0.0 . 5.82)

But if I look on 
http://www.lilypond.org/doc/v2.19/Documentation/internals/keycancellation, 
there is no entry for the X-extent setting. And if I follow the interface link 
to grob-interface, all it says is

X-extent (pair of numbers)
Extent (size) in the X direction, measured in staff-space units, relative 
to object’s reference point.

with [obviously] no specific setting for KeyCancellation.

Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
default is (0.0 . 5.82)*** gives me critical information that I can 
actually use as a reference point; without that information, the 
trial-and-error factor increases dramatically.

Thanks again, Harm. This is *extremely* helpful, and exactly solves this 
problem which I’ve asked about on the list several times over the past few 
years.

Best regards,
Kieren.

*** I’m not sure if that strange-looking value 5.82 is the result of some 
calculation that is getting evaluated/resolved in order to be visible in the 
output… but that’s of secondary concern to me as a user/tweaker.



Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 20:03 GMT+01:00 Kieren MacMillan :
> Hi Harm,
>
>> If you really want to see all of the default properties and their
>> values for a certain grob, try the code below.
>
> Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also 
> wanted.
> Thank you.
>
>> 1. I think you'll agree that we don't want to put it in the docs,
>> repeating it for every single grob …
>
> No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
> want to see all properties…”, etc. — would be a wonderful idea.

Maybe LSR, I'll have to test with 2.18.2.

>> 2. It doesn't work for NoteHead.
>
> Do you have any reason to believe it wouldn’t work with any other grob(s)?


Well, it's a brute-force attack on our code.
The functions in output-lib.scm making a problem are
`select-head-glyph' and `note-head::calc-glyph-name'.
Though, while normal compilation style '()/default is handled in
note-head.cc. Only with my coding and others of this kind the error
appears. No idea, if this will happen for other grobs at other places
as well.


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

Hi Kieren,

2016-01-24 18:22 GMT+01:00 Kieren MacMillan :
> Hi David,
>
>> it would be easier if you did not do creative editing in order to
>> let everything disappear not meeting your preconceptions.
>
> It’s not clear what you’re talking about… but anyway…
>
> It’s still perfectly clear to me — and, it seems, Charles and others — that 
> Lilypond has grobs, and those grobs have properties, and those properties 
> have values, and the default values of some of those properties are not 
> easily determinable by the [beginning?] user.
>
> Three examples which I just pulled at total random are
> Beam.beam-thickness (via beam-interface)

Beam.beam-thickness is in the IR ;)

> NoteHead.break-visibility (via item-interface)
> KeyCancellation.font-size (via font-interface)

These are _not_set!


If you really want to see all of the default properties and their
values for a certain grob, try the code below.
1. I think you'll agree that we don't want to put it in the docs,
repeating it for every single grob ...
2. It doesn't work for NoteHead.
Reason: in output-lib.scm are some procedures doing
(symbol->string style)
without testing whether style may be '()
(Already fixed locally, I'll provide a patch)


\version "2.19.35"

#(define (supported-properties iface)
  (let ((iface-info (hashq-get-handle (ly:all-grob-interfaces) iface)))
(last iface-info)))

#(define (print-all-grob-properties-key-values grob)
  (let ((ifaces (assoc-get 'interfaces (ly:grob-property grob 'meta
(for-each
  (lambda (iface)
(format #t "\n~a\n" (string-upcase (symbol->string iface)))
  (for-each
(lambda (p)
(ly:grob-property grob p)
  (format #t "\n\t~a:\n\t~a" p (ly:grob-property grob p))
  )
(supported-properties iface)))
  ifaces)))
%%{
\new ChordNames
\chordmode
{
  \applyOutput ChordNames.ChordName
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))
  c1
}
%}
%%{
\new Staff
{
  \key cis \major
  c1
  \applyOutput Staff.KeyCancellation
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))

  \key ces \major
  c1
}
%}
%{
\new Staff
{
  \applyOutput Score.NoteHead
#(lambda (grob ctx p)
  (format #t "\n~a in context: ~a:\n" grob ctx)
  (print-all-grob-properties-key-values grob))
  c1
}
%}


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Harm,

> If you really want to see all of the default properties and their
> values for a certain grob, try the code below.

Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also wanted.
Thank you.

> 1. I think you'll agree that we don't want to put it in the docs,
> repeating it for every single grob …

No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
want to see all properties…”, etc. — would be a wonderful idea.

> 2. It doesn't work for NoteHead.

Do you have any reason to believe it wouldn’t work with any other grob(s)?

Many thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 22:22 GMT+01:00 Thomas Morley :

> Btw, I tested it with 2.18.2, doesn't work with \applyOutput, but with
> \override Grob.after-line-breaking

http://lsr.di.unimi.it/LSR/Item?u=1=1017

Best,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 21:28, Simon Albrecht wrote:

On 24.01.2016 21:15, Thomas Morley wrote:
Now, if I want to reduce or enlarge KeyCancellation.X-extent, 
knowing that default is (0.0 . 5.82)*** gives me critical 
information that I can actually use as a reference point; without 
that information, the trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though


Oh, it would be great if we could use \offset for such cases. 
Unfortunately it doesn’t work here…
David, is this the case you described in 
, with 
mutable properties?


Test case:

%%%
\version "2.19.35"
{
  \key fis \major
  1
  \once\override Staff.KeyCancellation.X-extent = #'(0 . 5)
  \key b \minor
  1
  \once\offset X-extent #'(0 . 5) Staff.KeyCancellation
  \key g \major
  1
}
%%

– throwing twice ‘warning: the property 'X-extent of #KeyCancellation > cannot be offset’ and printing the KeyCancellation 
_without_ any X-extent.


Yours, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 21:32 GMT+01:00 Simon Albrecht :
> On 24.01.2016 21:28, Simon Albrecht wrote:
>>
>> On 24.01.2016 21:15, Thomas Morley wrote:

 Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing
 that default is (0.0 . 5.82)*** gives me critical information that I 
 can
 actually use as a reference point; without that information, the
 trial-and-error factor increases dramatically.
>>>
>>> Well, we have the \offset-function ...
>>> No clue about possible limitations, though
>>
>>
>> Oh, it would be great if we could use \offset for such cases.
>> Unfortunately it doesn’t work here…
>> David, is this the case you described in
>> , with mutable
>> properties?
>
>
> Test case:
>
> %%%
> \version "2.19.35"
> {
>   \key fis \major
>   1
>   \once\override Staff.KeyCancellation.X-extent = #'(0 . 5)
>   \key b \minor
>   1
>   \once\offset X-extent #'(0 . 5) Staff.KeyCancellation
>   \key g \major
>   1
> }
> %%
>
> – throwing twice ‘warning: the property 'X-extent of #> cannot be offset’ and printing the KeyCancellation _without_ any X-extent.
>
> Yours, Simon


Ok, \offset has limitations.
Though, I usually read directly the relevant grob-property and reset
it to my needs:

{
  \key cis \major
  c1
  \once\override Staff.KeyCancellation.after-line-breaking =
#(lambda (grob)
  (write-me "\nX-extent: " (ly:grob-property grob 'X-extent))
  )
  \key ces \major
  c1
}


Prints to terminal:
X-extent: (0.0 . 5.82)

Now I have the actual value and can do what ever I want with it ;)


Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Harm,

> Well, it is the _actual_ default. KeyCancellation _can't_ have
> a general default of X-extent for all possible KeyCancellations…

Obviously.  =)

But the benefits of the function are both general (“Get a list of every 
settable property for this grob.”) and specific (“Get the property values for a 
particular instance of this grob.”) I suppose we could spoonfeed the user more 
by somehow highlighting/mentioning in the output which are general/fixed values 
and which are specific/instance/relative values… but having this function 
already puts us well ahead of where we were a few hours ago.

> Well, we have the \offset-function ...
> No clue about possible limitations, though

The \offset function behaves in a “user-inconsistent” manner — by which I mean, 
there is undoubtedly a perfectly logical/technical reason why it works in 
certain cases and throws errors in others, but users don’t (or at least 
shouldn’t) care why they see “inconsistent” [sic] behaviour.

Simon says:
> Oh, it would be great if we could use \offset for such cases.


+1
But I know it may not be possible.

One case where a lack of \offset-ability drives me crazy is explicit 
system/staff positioning: as far as I know (and queries to the list have 
confirmed), there is no way to “nudge” a system (e.g.) up 1 staff space. So 
there’s a lot of trial-and-error in those situations.

Best,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 20:15 GMT+01:00 Kieren MacMillan :
> Hi again,
>
> Here’s a perfect example of what I’m talking about…
>
> For KeyCancellation, the output of Harm’s function includes
>
>  GROB-INTERFACE
> X-extent:
> (0.0 . 5.82)
>
> But if I look on 
> http://www.lilypond.org/doc/v2.19/Documentation/internals/keycancellation, 
> there is no entry for the X-extent setting. And if I follow the interface 
> link to grob-interface, all it says is
>
> X-extent (pair of numbers)
> Extent (size) in the X direction, measured in staff-space units, relative 
> to object’s reference point.
>
> with [obviously] no specific setting for KeyCancellation.

Well, it is the _actual_ default.
KeyCancellation _can't_ have a general default of X-extent for all
possible KeyCancellations...

> Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
> default is (0.0 . 5.82)*** gives me critical information that I can 
> actually use as a reference point; without that information, the 
> trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though

> Thanks again, Harm. This is *extremely* helpful, and exactly solves this 
> problem which I’ve asked about on the list several times over the past few 
> years.
>
> Best regards,
> Kieren.
>
> *** I’m not sure if that strange-looking value 5.82 is the result of some 
> calculation that is getting evaluated/resolved in order to be visible in the 
> output… but that’s of secondary concern to me as a user/tweaker.

Cheers,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Simon Albrecht]

On 24.01.2016 21:15, Thomas Morley wrote:

Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing that 
default is (0.0 . 5.82)*** gives me critical information that I can 
actually use as a reference point; without that information, the 
trial-and-error factor increases dramatically.

Well, we have the \offset-function ...
No clue about possible limitations, though


Oh, it would be great if we could use \offset for such cases. 
Unfortunately it doesn’t work here…
David, is this the case you described in 
, with 
mutable properties?


Best, Simon

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Determining what parameters exist for an item

[Charles O. Lawrence]

Gentlemen,

Thanks for all your replies.  I had no idea such a simple request would stir up 
such a hornet's nest.  I have some good ideas to follow up on now.

Charles


-Original Message-
From: Kieren MacMillan [mailto:kieren_macmil...@sympatico.ca] 
Sent: Sunday, January 24, 2016 2:04 PM
To: Thomas Morley <thomasmorle...@gmail.com>
Cc: David Kastrup <d...@gnu.org>; Charles O. Lawrence 
<charlesolawre...@bellsouth.net>; Lilypond-User Mailing List 
<lilypond-user@gnu.org>; Carl Sorensen <c_soren...@byu.edu>
Subject: Re: Determining what parameters exist for an item

Hi Harm,

> If you really want to see all of the default properties and their 
> values for a certain grob, try the code below.

Now THIS… this is EXACTLY what I wanted; and, I infer, what Charles also wanted.
Thank you.

> 1. I think you'll agree that we don't want to put it in the docs, 
> repeating it for every single grob …

No, but I offer that putting this FUNCTION in the docs (snippets?) — “If you 
want to see all properties…”, etc. — would be a wonderful idea.

> 2. It doesn't work for NoteHead.

Do you have any reason to believe it wouldn’t work with any other grob(s)?

Many thanks,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

2016-01-24 22:03 GMT+01:00 Kieren MacMillan :
> Hi Harm,
>
>> Well, it is the _actual_ default. KeyCancellation _can't_ have
>> a general default of X-extent for all possible KeyCancellations…
>
> Obviously.  =)
>
> But the benefits of the function are both general (“Get a list of every 
> settable property for this grob.”)

But please understand: if a property is settable, this does not mean
your setting takes any effect.
I don't speak of user-errors in syntax, missing context, etc, but
sometimes an engraver does not listen to a certain property, maybe
because it's hard-coded or not really needed or for other good
reasons.

Btw, I tested it with 2.18.2, doesn't work with \applyOutput, but with
\override Grob.after-line-breaking

Cheers,
  Harm

> and specific (“Get the property values for a particular instance of this 
> grob.”) I suppose we could spoonfeed the user more by somehow 
> highlighting/mentioning in the output which are general/fixed values and 
> which are specific/instance/relative values… but having this function already 
> puts us well ahead of where we were a few hours ago.
>
>> Well, we have the \offset-function ...
>> No clue about possible limitations, though
>
> The \offset function behaves in a “user-inconsistent” manner — by which I 
> mean, there is undoubtedly a perfectly logical/technical reason why it works 
> in certain cases and throws errors in others, but users don’t (or at least 
> shouldn’t) care why they see “inconsistent” [sic] behaviour.
>
> Simon says:
>> Oh, it would be great if we could use \offset for such cases.
>
>
> +1
> But I know it may not be possible.
>
> One case where a lack of \offset-ability drives me crazy is explicit 
> system/staff positioning: as far as I know (and queries to the list have 
> confirmed), there is no way to “nudge” a system (e.g.) up 1 staff space. So 
> there’s a lot of trial-and-error in those situations.
>
> Best,
> Kieren.
> 
>
> Kieren MacMillan, composer
> ‣ website: www.kierenmacmillan.info
> ‣ email: i...@kierenmacmillan.info
>

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Nalesnik]

On Sun, Jan 24, 2016 at 2:32 PM, Simon Albrecht 
wrote:

> On 24.01.2016 21:28, Simon Albrecht wrote:
>
>> On 24.01.2016 21:15, Thomas Morley wrote:
>>
>>> Now, if I want to reduce or enlarge KeyCancellation.X-extent, knowing
 that default is (0.0 . 5.82)*** gives me critical information that I
 can actually use as a reference point; without that information, the
 trial-and-error factor increases dramatically.

>>> Well, we have the \offset-function ...
>>> No clue about possible limitations, though
>>>
>>
>> Oh, it would be great if we could use \offset for such cases.
>> Unfortunately it doesn’t work here…
>>
>>
\offset only works on properties that have a default value listed in the
grob pages in the IR (derived from the alist in scm/define-grobs.scm).
There is no default value listed for KeyCancellation.X-extent, hence the
warning.

DN
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kevin Barry]

On 23 January 2016 at 18:01, Charles O. Lawrence <
charlesolawre...@bellsouth.net> wrote:

> For example, what are all the parameters for a TextSpanner?


Do you mean this?
http://lilypond.org/doc/v2.18/Documentation/internals/textspanner
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Carl Sorensen]

Charles O. Lawrence wrote:


> Gentlemen,
 
> How can I determine what parameters exist for an item?  For example,
>what are all the parameters for a
>  TextSpanner?  If my terminology is not correct, please correct me.
 


Charles,

Here is the way I do it, without programming.  You may find this less
confusing.

1) Look up the object in the Internals Reference, Section 3.1 All layout
objects.  For TextSpanner, you can use this link for version 2.18:

http://www.lilypond.org/doc/v2.18/Documentation/internals/textspanner


2)  The standard settings on this page tell you the default settings for
this object.  These are the most commonly used, but they are not all.

3) At the bottom of the page, the interfaces the object supports are
listed.  In the case of the TextSpanner,
these are font-interface, grog-interface, line-interface,
line-spanner-interface, side-position-interface, and spanner-interface.
Each of these interfaces has a list of properties found in the Internals
Reference section 3.2.  And the property lists are linked from the
TextSpanner page.

4) Going to one of these interfaces, e.g. the font-interface found in the
Internals Reference, section 3.2.36,

http://www.lilypond.org/doc/v2.18/Documentation/internals/font_002dinterfac
e


provides a list of user-settable properties for that interface, which will
affect any output item having that interface.

All of this is explained in section 5.2 of the Notation Reference.
Please read it for more information.

HTH,

Carl Sorensen






___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Nalesnik]

Harm,

On Sat, Jan 23, 2016 at 3:29 PM, Thomas Morley 
wrote:

>
> display-scheme-music is defined in our source and is the
> scheme-version of (LilyPond-syntax) `displayMusic', which is explained
> in the docs.
> I sort of abuse it quite often, because it internally uses
> `pretty-print'. (In .ly file I would always need to include the
> relevant module from guile for pretty-print, which is tedious).
> pretty-print puts out nicely formatted lists.
> guile and LilyPond provide a plethora of different displaying procedures
> ...
>

Actually, you can use pretty-print directly, as of 2.19.18.  See
https://sourceforge.net/p/testlilyissues/issues/4331/

David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Kieren MacMillan]

Hi Carl,

> 4) Going to one of these interfaces […]
> provides a list of user-settable properties for that interface

Yes, but unless I’m missing something, you can’t find the default value(s) 
there, right?

I personally would love to be able to get, for any grob, a list of every 
settable value (“native” or “interfaced”) *including the default value for each 
setting*.

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Charles O. Lawrence]

Hello Thomas,

I thought I was replying to the list, but I see now that I sent you a
personal email.  I was inside the archives and clicked on the reply button.
Sorry.  I'm not exactly sure how to respond and keep the post's hierarchy
going.  I hope I got it right this time.  All I did was reply to the digest
email, strip out what I didn't need, and replace the default subject.

Thanks for the info.  I had not looked at the "Extending"  manual yet.  I
had gone through first two chapters of the "Learning" manual already.  I had
already "googled" and downloaded a Scheme and Guile manual.  I also had
discovered the "Scores of Beauty" blog, but had not gone through all the
Scheme tutorials yet.  I have a lot of reading studying to do.  Your reply
has been very helpful.

Thanks,
Charles




Hi Charles,

please keep the discussion on the list, apart from real private stuff.

2016-01-23 20:33 GMT+01:00 Charles O. Lawrence
:
> Thank you for your replies.
>
> This is an example of you giving me a code sample that will display the
properties, and I thank you for it, but to a newbie to lilypond such as I
am, I have no clue what or why is in the procedure.  A little elaboration
would be nice.  For example, what is the lambda?  I can guess what the
string-upcase, display and display-scheme-music are, but where did you find
out about their existence and how to call them?   Is there a document or
book that explains all this stuff, more than the reference material, which
is more than overwhelming?  I realize you are an advanced user.  [...] I
never had the need or opportunity to study Lisp or Scheme, or whatever
lilypond input syntax is.  Any guidance is greatly appreciated.
>
> Charles

LilyPond uses an input language, which you will need to learn. Best start
reading the "Learning Manual".
Scheme/guile is used as an extension-language in LilyPond. A good starting
point for getting deeper into it is the "Extending Manual".
And ofcourse the guile-manual itself, please note we use guile-1.8 Apart
from the guile-manual, there are a lot of tutorials out there.

Details:
display, string-upcase and lambda are native guile
-> see guile-manual
Maybe look at this one, too:
http://lilypondblog.org/category/using-lilypond/advanced/scheme-tutorials/

display-scheme-music is defined in our source and is the scheme-version of
(LilyPond-syntax) `displayMusic', which is explained in the docs.
I sort of abuse it quite often, because it internally uses `pretty-print'.
(In .ly file I would always need to include the relevant module from guile
for pretty-print, which is tedious).
pretty-print puts out nicely formatted lists.
guile and LilyPond provide a plethora of different displaying procedures ...

ly:grob-properties and ly:grob-basic-properties are defined in C++ for use
in guile.
--> see Internals Reference
Same for 'after-line-breaking, which is a dummy-property called at a certain
point during compilation. Nice to put in all sort of stuff or for displaying
this and that, as done here.

`all-grob-descriptions' is an alist defined in define-grobs.scm.
Although it's public you'll find no documentation about it. Reason:
you shouldn't mess around with internals unless you really know what you're
doing ;)

So far the details for the little coding, but I'm afraid my explanations
will more obfuscate then enlightning...

My recommendation would be:
- try to read and understand the codings provided here on the list.
- Read the manuals: LilyPond, guile, guile-tutorials, etc

I'm not a programmer, though as a LilyPond-starter I had found that not all
was as I wanted it to be. So I started to learn guile to say her what to do
how. I did a lot of exercises: defining substitution-functions and
markup-commands, etc And ofcourse it's very good practise to read/understand
code from others and/or try helping other user.
The LSR is quite nice as well
http://lsr.di.unimi.it/LSR/


Hope it helps a bit,
  Harm



--



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Determining what parameters exist for an item

[Charles O. Lawrence]

Thanks Carl,

I will see where I get using your method.  As you pointed out, I had noticed
earlier that the property lists in the manuals are not all inclusive in one
place.

Charles


-Original Message-
From: Carl Sorensen [mailto:c_soren...@byu.edu] 
Sent: Saturday, January 23, 2016 8:07 PM
To: Charles O. Lawrence <charlesolawre...@bellsouth.net>;
lilypond-user@gnu.org
Subject: Re: Determining what parameters exist for an item

Charles O. Lawrence wrote:


> Gentlemen,
 
> How can I determine what parameters exist for an item?  For example, 
>what are all the parameters for a
>  TextSpanner?  If my terminology is not correct, please correct me.
 


Charles,

Here is the way I do it, without programming.  You may find this less
confusing.

1) Look up the object in the Internals Reference, Section 3.1 All layout
objects.  For TextSpanner, you can use this link for version 2.18:

http://www.lilypond.org/doc/v2.18/Documentation/internals/textspanner


2)  The standard settings on this page tell you the default settings for
this object.  These are the most commonly used, but they are not all.

3) At the bottom of the page, the interfaces the object supports are listed.
In the case of the TextSpanner, these are font-interface, grog-interface,
line-interface, line-spanner-interface, side-position-interface, and
spanner-interface.
Each of these interfaces has a list of properties found in the Internals
Reference section 3.2.  And the property lists are linked from the
TextSpanner page.

4) Going to one of these interfaces, e.g. the font-interface found in the
Internals Reference, section 3.2.36,

http://www.lilypond.org/doc/v2.18/Documentation/internals/font_002dinterfac
e


provides a list of user-settable properties for that interface, which will
affect any output item having that interface.

All of this is explained in section 5.2 of the Notation Reference.
Please read it for more information.

HTH,

Carl Sorensen






___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[David Nalesnik]

On Sat, Jan 23, 2016 at 3:58 PM, David Nalesnik 
wrote:

> Harm,
>
> On Sat, Jan 23, 2016 at 3:29 PM, Thomas Morley 
> wrote:
>
>>
>> display-scheme-music is defined in our source and is the
>> scheme-version of (LilyPond-syntax) `displayMusic', which is explained
>> in the docs.
>> I sort of abuse it quite often, because it internally uses
>> `pretty-print'. (In .ly file I would always need to include the
>> relevant module from guile for pretty-print, which is tedious).
>> pretty-print puts out nicely formatted lists.
>> guile and LilyPond provide a plethora of different displaying procedures
>> ...
>>
>
> Actually, you can use pretty-print directly, as of 2.19.18.  See
> https://sourceforge.net/p/testlilyissues/issues/4331/
>
>
Hmm.  Though objections were voiced after this was pushed.  (See
https://codereview.appspot.com/222810043.  I'll offer again there to remove
the enhancement.)

--David
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

RE: Determining what parameters exist for an item

[Charles O. Lawrence]

Thanks for your reply Kieren.

I'm glad to see that I am not the only one who would like a list of all the 
properties of an "object" and their default values.

Charles

-Original Message-
From: Kieren MacMillan [mailto:kieren_macmil...@sympatico.ca] 
Sent: Saturday, January 23, 2016 8:21 PM
To: Carl Sorensen <c_soren...@byu.edu>
Cc: Charles O. Lawrence <charlesolawre...@bellsouth.net>; Lilypond-User Mailing 
List <lilypond-user@gnu.org>
Subject: Re: Determining what parameters exist for an item

Hi Carl,

> 4) Going to one of these interfaces […] provides a list of 
> user-settable properties for that interface

Yes, but unless I’m missing something, you can’t find the default value(s) 
there, right?

I personally would love to be able to get, for any grob, a list of every 
settable value (“native” or “interfaced”) *including the default value for each 
setting*.

Cheers,
Kieren.


Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Determining what parameters exist for an item

[Thomas Morley]

Hi Charles,

please keep the discussion on the list, apart from real private stuff.

2016-01-23 20:33 GMT+01:00 Charles O. Lawrence :
> Thank you for your replies.
>
> This is an example of you giving me a code sample that will display the 
> properties, and I thank you for it, but to a newbie to lilypond such as I am, 
> I have no clue what or why is in the procedure.  A little elaboration would 
> be nice.  For example, what is the lambda?  I can guess what the 
> string-upcase, display and display-scheme-music are, but where did you find 
> out about their existence and how to call them?   Is there a document or book 
> that explains all this stuff, more than the reference material, which is more 
> than overwhelming?  I realize you are an advanced user.  [...] I never had 
> the need or opportunity to study Lisp or Scheme, or whatever lilypond input 
> syntax is.  Any guidance is greatly appreciated.
>
> Charles

LilyPond uses an input language, which you will need to learn. Best
start reading the "Learning Manual".
Scheme/guile is used as an extension-language in LilyPond. A good
starting point for getting deeper into it is the "Extending Manual".
And ofcourse the guile-manual itself, please note we use guile-1.8
Apart from the guile-manual, there are a lot of tutorials out there.

Details:
display, string-upcase and lambda are native guile
-> see guile-manual
Maybe look at this one, too:
http://lilypondblog.org/category/using-lilypond/advanced/scheme-tutorials/

display-scheme-music is defined in our source and is the
scheme-version of (LilyPond-syntax) `displayMusic', which is explained
in the docs.
I sort of abuse it quite often, because it internally uses
`pretty-print'. (In .ly file I would always need to include the
relevant module from guile for pretty-print, which is tedious).
pretty-print puts out nicely formatted lists.
guile and LilyPond provide a plethora of different displaying procedures ...

ly:grob-properties and ly:grob-basic-properties are defined in C++ for
use in guile.
--> see Internals Reference
Same for 'after-line-breaking, which is a dummy-property called at a
certain point during compilation. Nice to put in all sort of stuff or
for displaying this and that, as done here.

`all-grob-descriptions' is an alist defined in define-grobs.scm.
Although it's public you'll find no documentation about it. Reason:
you shouldn't mess around with internals unless you really know what
you're doing ;)

So far the details for the little coding, but I'm afraid my
explanations will more obfuscate then enlightning...

My recommendation would be:
- try to read and understand the codings provided here on the list.
- Read the manuals: LilyPond, guile, guile-tutorials, etc

I'm not a programmer, though as a LilyPond-starter I had found that
not all was as I wanted it to be. So I started to learn guile to say
her what to do how. I did a lot of exercises: defining
substitution-functions and markup-commands, etc
And ofcourse it's very good practise to read/understand code from
others and/or try helping other user.
The LSR is quite nice as well
http://lsr.di.unimi.it/LSR/


Hope it helps a bit,
  Harm

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user