Re: vertical shift of trill

[Jean Abou Samra]

Le 06/08/2022 à 16:45, Werner LEMBERG a écrit :
> > That said, there's a much simpler way.  [...]
> Your solution is ingenious.  However, how on earth are we mere mortals
> able to find that?


Read the source, Luke :-)

Seriously, there is no way around that in this case -- as in many cases
when it comes to Scheme coding, because the task is essentially to meddle
with LilyPond internals.

Obviously, I don't claim that this is something every user is supposed to
be able to do.


> Both `note-columns` and `side-support-elements`
> are tagged as internal properties, which essentially means "don't
> touch".


_All_ "object" properties* are documented as internal, so as soon
as you're writing an engraver that sets up a grob that interacts
with other grobs, you start touching those.

In my book, a property being tagged as "internal" means "this is an
advanced parameter, be aware that touching it might be more difficult
than using \override and you likely need to know a bit about internals
if you want to tinker with it", but doesn't advise against using it
in Scheme when you know what you're doing. (If setting internal properties
in Scheme were forbidden, the range of things you could do with Scheme
in LilyPond would be much more limited.)


> Additionally, the documentation is ... scarce, to be polite
>
> I wonder whether it makes sense to encapsulate this functionality into
> a LilyPond macro, to be provided by default.  Or maybe even better:
> Could this functionality be activated automatically as soon as there
> is `\override TrillSpanner.outside-staff-priority = ##f`?


Well, it wouldn't hurt to have it by default even with
outside-staff-priority. I'm currently preparing other things
though, maybe later, or maybe you'll beat me at it :-)
It's not more difficult than defining the callback in output-lib.scm,
using it in define-grobs.scm, and adding a regtest too.
I've actually long been wanting to refactor outside-staff placement
so this sort of issue would not appear in the first place
(see also 
https://lists.gnu.org/archive/html/lilypond-user/2022-06/msg00232.html)
but it's pretty complicated ...

Best,
Jean



* I mean the grobs & grob arrays, accessed with ly:grob-object, and
  subject to break substitution. I never know how to call them,
  "object properties" sounds similar to "[regular] properties of
  [graphical] objects" which is not the same, and Guile also has
  "object properties" that are a different thing entirely ...