Re: \with mods targeting parents
David Kastrup <[email protected]>
| Newsgroups | gmane.comp.gnu.lilypond.devel |
|---|---|
| Organization | Organization?!? |
| Message-ID | <[email protected]> |
Carl Sorensen <[email protected]> writes: > On Mon, Oct 27, 2025 at 1:14 PM David Kastrup <[email protected]> wrote: >> >> We actually went through all this once already including actual code, >> and the results were unhelpful. >> >> Please check >> >> <https://gitlab.com/lilypond/lilypond/-/issues/2982> >> > > Sorry about the noise. I agree with your conclusion. I did not actually remember that we already were there before, and I did not remember whether I merely had an internal discussion with myself on it. And looking at this thread right now, it looks an awful lot like I tried to strongarm myself through that discussion. I apologize for that. I agree that not all of the consequences of this design decision are likeable. But the problem is that something like mysettings = \with { ... } creates a context modification block that has no clue whatsoever to what kind of context it will be applied, and context modifications do not contain any context specifier. So with that kind of statement, we don't have what it would take to act context-specifically, and we don't retain enough information to act on it later on. Apart from that syntax, we have something like \new Staff \with ... and here at the time of parsing we only know about this being for "Staff" but not where Staff is actually sitting in the hierarchy: the context hierarchy is only established once music is iterated. So we cannot really decide whether we are upward or downward or off-side of Staff with any context specified in an override. And then we have \layout { \context { \Staff ... } } Again, this is before iteration happens, and where the respective overrides are sitting, it is not even clear whether the final \name of the context has been established (\Staff just copies the \name and other settings of "Staff", but it may well be renamed to something else afterwards in order to create a Staff-like context). Given all that, I actually wonder in what manner the discriminative conversion implemented before that change was actually able to work at all rather than "merely" in a surprising manner. Warnings, of course, have the advantage that they don't need be consistent. But I don't see how we could confine them to a subset of circumstances that were reasonably certain to be unintentional. So I don't really see us getting more helpful here. The logic and information does not seem to deliver. -- David Kastrup