Re: Can't have rehearsal mark and segno mark at same moment

[Jean Abou Samra]

Le 10/08/2022 à 20:48, Jean Abou Samra a écrit :
> Le 10/08/2022 à 20:35, Vincent Gay a écrit :
> > 10 août 2022 20:20:52 Jean Abou Samra <jean@abou-samra.fr>:
> >
> > > Another open question is how several marks, of any kind, should be
> > > positioned relative to each other when they are at the same place.
> > > In the example that started this thread, should the "A" mark be above
> > > the segno mark, or on its right, or on its left?
> > Please, let the one who writes the score decide for himself. \tweak 
> > is perfect for that.
>
>
> I completely agree that it should be user-settable, but
> we need to pick a default.
>
> Besides, I am not aware of a currently existing simple interface for
> stacking (say) a RehearsalMark and a MetronomeMark horizontally.
> If you \tweak X-offset, the value has to be manually adjusted.
> I actually wrote a snippet last year that automated horizontal
> stacking for RehearsalMark and MetronomeMark.
>
> https://lists.gnu.org/archive/html/lilypond-user/2021-09/msg00426.html
>
> So there is some work to be done to implement automatic horizontal 
> stacking
> in the first place.
>
> If it should be the default, it needs to be done first. If not,
> it can be done later.



I now have a patch locally that renames AdHocMarkEvent into 
LegacyAdHocMarkEvent
(also ad-hoc-mark-event into legacy-ad-hoc-mark-event), and reintroduces
an AdHocMarkEvent that creates AdHocMark grobs. The syntax is \adHocMark 
<markup> or
\adHocEndMark <markup>, any number of events is allowed in the same 
timestep.
The default for alignment is to stack AdHocMarks according to input order.
(It is the responsibility of the user to avoid dependency on event order 
with
<< >> constructs. I'm not sure if this concerning; this issue already exists
with text scripts and I don't recall problems, so I think it should be 
OK, but
feedback is welcome.)

The plan is to keep \mark <markup> for now, but recommend against it in the
documentation. Based on how we see usage evolve (from the mailing lists),
it could be reasonable to deprecate and actually remove this syntax at
some point, but this is a decision I prefer to leave for the future.

If anyone has objections, voicing them now would spare me some time writing
documentation and regtests.

Thanks,
Jean