Re: Overrides and nesting: intentional?
2011/8/6 David Kastrup :
>> Going back to your colorful examples, here's what effects i'd expect:
>>
>> \relative c' {
>> c4
>> \once\override Stem #'color = #red
>> \override Stem #'color = #blue
>> c4 c
>> \revert Stem #'color
>> c4
>> }
>>
>> black blue blue black
>
> That's a reasonable expectation, but it requires that \once\override
> keeps track of just what it is supposed to revert at the end of the time
> step. Popping the top of the stack would not work, leaving us with
> black, blue, red, black. One possibility would be to store the
> \once\override info in a separate location (or with a special mark)
> where it does not mix with the \override info.
>
>> \relative c' {
>> c4
>> \override Stem #'color = #blue
>> \once\override Stem #'color = #red
>> \revert Stem #'color
>> c4 c
>> c4
>> }
>>
>> black black black black.
>
> Actually, I think I'd prefer black, red, black, black. I feel a revert
> should not cancel more than one \override, so something should happen at
> the second time step. The pure stack approach would leave us with
> black, blue, black, black, arguably weird. But pretty easy to explain.
>
> If we aim for black, red, black, black, this would more or less imply
> (if things should obey simple rules) that you can _never_ use \revert to
> cancel \once\override. However, the syntax already permits
> \once\revert, so maintaining what amounts to a separate stack for \once
> could work reasonably well and be nice enough to document.
I'm not sure if i prefer black, red, black, black over 4 x black, but
it's not that important. Overall, your suggestion seems good to me.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
- Original Message - From: "Jan Warchoł" Going back to your colorful examples, here's what effects i'd expect: +1 on all of those. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
Jan Warchoł writes:
> 2011/8/5 David Kastrup :
>
> I'm not sure if i understand it (is "a" a property or a value?),
Property. I am not yet concerned about values... Anyway, I am not sure
I understand what I write either.
> but it seems to me that \override should indeed not begin with a
> revert.
My current comprehension is that this is likely the intent of the code.
Doesn't work yet, but I'll try figuring out why, and then likely what
change caused this for what reason.
> However, we may need additional command like
> \revertTillDefaultIsReached or sth like that.
>
> Going back to your colorful examples, here's what effects i'd expect:
>
> \relative c' {
> c4
> \once\override Stem #'color = #red
> \override Stem #'color = #blue
> c4 c
> \revert Stem #'color
> c4
> }
>
> black blue blue black
That's a reasonable expectation, but it requires that \once\override
keeps track of just what it is supposed to revert at the end of the time
step. Popping the top of the stack would not work, leaving us with
black, blue, red, black. One possibility would be to store the
\once\override info in a separate location (or with a special mark)
where it does not mix with the \override info.
> \relative c' {
> c4
> \override Stem #'color = #blue
> \once\override Stem #'color = #red
> c4 c
> \revert Stem #'color
> c4
> }
>
> black red blue black
Yup.
> \relative c' {
> c4
> \override Stem #'color = #blue
> \once\override Stem #'color = #red
> \revert Stem #'color
> c4 c
> c4
> }
>
> black black black black.
Actually, I think I'd prefer black, red, black, black. I feel a revert
should not cancel more than one \override, so something should happen at
the second time step. The pure stack approach would leave us with
black, blue, black, black, arguably weird. But pretty easy to explain.
If we aim for black, red, black, black, this would more or less imply
(if things should obey simple rules) that you can _never_ use \revert to
cancel \once\override. However, the syntax already permits
\once\revert, so maintaining what amounts to a separate stack for \once
could work reasonably well and be nice enough to document.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
2011/8/5 David Kastrup :
>
> On the hopefully correct assumption that this was intended to go to the
> list and just mistakenly sent in private
Yes, i occasionally misclick the button. Thanks!
> I think that originally \override was a push, \revert was a pop, and
> \once\override was a push/pop pair (that's more or less what is in the
> user docs as well).
>
> Then somebody probably thought that \override\override\revert should be
> a nop since \override has to be used instead of \set anyway (which would
> not push), and turned \override into a pop-push pair (pop never goes
> beyond the current context, so "little harm done"). That explains why
> the first example pairs the pop from the \once\override with the push
> from \override. In the first example, the \override should, when
> cancelling the push from \once\override, not leave the corresponding pop
> lying around to be executed later.
>
> Now take that incoherent mess, and add nested properties into it.
> Apparently the current code has no qualms to start an \override with a
> pop that will cancel an entirely unrelated operation.
>
> Now if we do something like (never mind the value and the syntax)
> \override a.b.c \override a
> should the second \override be able to cancel the first one with its
> implied \revert at its front? How about if we do
> \override a \override a.b.c
> instead? Should the second override be able to cancel the first one?
> Only partially? What if we now do
> \override a \override a.b.c \override a
> How many \revert a should we need to have the stack empty again? If we
> do
> \override a \override a.b.c \revert a.b.c
> what should the state of a.whatever be? Changed against before or not?
> What should the state of a.b.c be? Changed against before (to the value
> set by \override a) or not?
I'm not sure if i understand it (is "a" a property or a value?), but
it seems to me that \override should indeed not begin with a revert.
However, we may need additional command like
\revertTillDefaultIsReached or sth like that.
Going back to your colorful examples, here's what effects i'd expect:
\relative c' {
c4
\once\override Stem #'color = #red
\override Stem #'color = #blue
c4 c
\revert Stem #'color
c4
}
black blue blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
c4 c
\revert Stem #'color
c4
}
black red blue black
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
\revert Stem #'color
c4 c
c4
}
black black black black.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
David Kastrup writes: > Reinhold Kainhofer writes: > >> Am Freitag, 5. August 2011, 19:08:43 schrieb David Kastrup: >>> Proposal 1: \override should not start with an internal \revert but >>> rather do just what the user documentation says: push its own version in >>> front of the existing alist of properties, without deleting existing >>> overrides. >> >> That's what I would expect, too. >> Of course, then the list of overrides will grow with every override and >> might >> be quite large for a very long score... > > Hm? Either you want to override once, then the net result on the stack > is none anyway, or you want to override permanently, then their is no > growth, or you switch back and forth, then you'll need to revert in > between. But as things are currently, it is impossible to use \override > for establishing a basic setting in the context: with the first > \override/\revert pair, the basic setting is _gone_. And you can't use > \set for grob properties, either. Anyway, I think that my given example was flawed in that it likely relied on unintentionally broken behavior. I probably was mistaken about the intended behavior (override likely is intended to do a push without a previous pop), but then given the quality of the user documentation, I have to rely on a combination of actual behavior and my interpretation of the code. It does not exactly help that I currently get throws in critical sections galore, maybe a problem with gcc/binutil/whatever. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
Reinhold Kainhofer writes:
> Am Freitag, 5. August 2011, 19:08:43 schrieb David Kastrup:
>> Proposal 1: \override should not start with an internal \revert but
>> rather do just what the user documentation says: push its own version in
>> front of the existing alist of properties, without deleting existing
>> overrides.
>
> That's what I would expect, too.
> Of course, then the list of overrides will grow with every override and might
> be quite large for a very long score...
Hm? Either you want to override once, then the net result on the stack
is none anyway, or you want to override permanently, then their is no
growth, or you switch back and forth, then you'll need to revert in
between. But as things are currently, it is impossible to use \override
for establishing a basic setting in the context: with the first
\override/\revert pair, the basic setting is _gone_. And you can't use
\set for grob properties, either.
>> Obviously, something considered bad will happen, or the code would
>> not go to the pains to do what it does now. What is the bad thing
>> that will happen?
>
> I think that only Han-Wen can answer that question. That behavior
> (revert if the music property pop-first ist set) was introduced in
> between versions 1.3.109 and 1.3.111 (commit
> f085824b2182c1f0fa2c5118884770ac7ff775c7 ) in November 2000.
cda8fc1780778b760905c8832f7e984161218f20 I see.
Author: Han-Wen Nienhuys > Sun Nov 26 20:06:46 2000
Committer: Han-Wen Nienhuys > Sun Nov 26 20:06:46 2000
release: 1.3.111
[...]
* Changed syntax \push -> \override, \pop -> \revert. Add:
\property Context.Element \set #'foo = #bar
which does a \revert followed by a \override.
[...]
But if you take a look to see where it is set, namely in parser.yy,
you'll see that it just pertains to \set here:
| PROPERTY STRING '.' STRING SET embedded_scm '=' embedded_scm {
Music *t = new Music;
t->set_mus_property ("iterator-ctor",
Push_property_iterator::constructor_cxx_function);
t->set_mus_property ("symbols", scm_string_to_symbol ($4));
t->set_mus_property ("pop-first", SCM_BOOL_T);
t->set_mus_property ("grob-property", $6);
t->set_mus_property ("grob-value", $8);
Context_specced_music *csm = new Context_specced_music (t);
$$ = csm;
$$->set_spot (THIS->here_input ());
csm-> set_mus_property ("context-type", $2);
}
So no, this is not the answer. At this point of time, \set was
available, and only \set does a pop before push.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
Am Freitag, 5. August 2011, 19:08:43 schrieb David Kastrup: > Proposal 1: \override should not start with an internal \revert but > rather do just what the user documentation says: push its own version in > front of the existing alist of properties, without deleting existing > overrides. That's what I would expect, too. Of course, then the list of overrides will grow with every override and might be quite large for a very long score... > Obviously, something considered bad will happen, or the code would not > go to the pains to do what it does now. What is the bad thing that will > happen? I think that only Han-Wen can answer that question. That behavior (revert if the music property pop-first ist set) was introduced in between versions 1.3.109 and 1.3.111 (commit f085824b2182c1f0fa2c5118884770ac7ff775c7 ) in November 2000. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
James Lowe writes: [...] > )Now take that incoherent mess, and add nested properties into it. > )Apparently the current code has no qualms to start an \override with a > )pop that will cancel an entirely unrelated operation. > ) > )Now if we do something like (never mind the value and the syntax) > )\override a.b.c \override a should the second \override be able to cancel > )the first one with its implied \revert at its front? How about if we do > )\override a \override a.b.c instead? Should the second override be able > )to cancel the first one? > )Only partially? What if we now do > )\override a \override a.b.c \override a > )How many \revert a should we need to have the stack empty again? If > )we do \override a \override a.b.c \revert a.b.c what should the state of > )a.whatever be? Changed against before or not? > )What should the state of a.b.c be? Changed against before (to the value > )set by \override a) or not? > ) > > What do you think? I started working on the nested property stuff by reverting a patch that complicated the situation and introduced new illogical behavior while making some test cases produce the expected results. I have the impression that this is not dissimilar for straightforward properties. The "try to revert before override" behavior appears to me like somebody considered it a good idea because it made something work more similarly to what he/she expected, but resulting in behavior and code that is harder to predict overall. So I would like to hear _what_ the "revert before override" behavior was supposed to be fixing. Designing a useful behavior for working with nested overrides is doomed to failure if I don't have a design of useful behavior available for straightforward properties. So I'd appreciate a case table of sequences of \once\override, \override, \revert and their friends (\once\revert anybody?) together with the _wanted_ outcomes and possible _acceptable_ outcomes. > Seriously, that is not (meant to be) an impertinent question. You've > obviously done a lot of thinking about this so why not lay your cards > on the table and go from there. Take the lead. Up to now I have just done code analysis, reading the behavior that is currently there. The user level documentation is partly in conflict with what I read in the code. Somebody obviously put that code there for a _reason_. It is more complex than the user level documentation. There is no rationale to be found in the code. So I'd like to hear it. There is no point if I slash through the code, restore the simpler behavior that likely was there at one time, and get the whole marked up as a regression that gets re"fixed" in the same or analog manner. I don't like the semantics of the current implementation. I would tend to tie overrides and reverts together on a lexical base (meaning you can't revert things coming from a different music list or even the same input source). It seems particularly pointless to let \once\override revert anything at the end of the time step that is unrelated to its own override. > I know the discussion is nice and all but it can all get a bit too > philosophical - paralysis from analysis and all that, too much theory > not enough practical. I don't _have_ practical experience to offer. I want to _fix_ stuff that is being used, and that has obviously been complicated (and not with uniquely positive results) by trying to accommodate practical reasons. This is why I am calling out here. I can't accommodate the same reasons if I don't get to know about them. > If we're serious about changing/tidying this then why not make a > proposal? Then a real discussion can commence. Fine. Proposal 1: \override should not start with an internal \revert but rather do just what the user documentation says: push its own version in front of the existing alist of properties, without deleting existing overrides. Obviously, something considered bad will happen, or the code would not go to the pains to do what it does now. What is the bad thing that will happen? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Overrides and nesting: intentional?
David, )-Original Message- )From: lilypond-devel-bounces+james.lowe=datacore@gnu.org )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On )Behalf Of David Kastrup )Sent: 05 August 2011 17:14 )To: Jan Warchoł )Cc: lilypond-devel@gnu.org )Subject: Re: Overrides and nesting: intentional? ) ) )Now take that incoherent mess, and add nested properties into it. )Apparently the current code has no qualms to start an \override with a )pop that will cancel an entirely unrelated operation. ) )Now if we do something like (never mind the value and the syntax) )\override a.b.c \override a should the second \override be able to cancel )the first one with its implied \revert at its front? How about if we do )\override a \override a.b.c instead? Should the second override be able )to cancel the first one? )Only partially? What if we now do )\override a \override a.b.c \override a )How many \revert a should we need to have the stack empty again? If )we do \override a \override a.b.c \revert a.b.c what should the state of )a.whatever be? Changed against before or not? )What should the state of a.b.c be? Changed against before (to the value )set by \override a) or not? ) What do you think? Seriously, that is not (meant to be) an impertinent question. You've obviously done a lot of thinking about this so why not lay your cards on the table and go from there. Take the lead. I know the discussion is nice and all but it can all get a bit too philosophical - paralysis from analysis and all that, too much theory not enough practical. If we're serious about changing/tidying this then why not make a proposal? Then a real discussion can commence. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Overrides and nesting: intentional?
On the hopefully correct assumption that this was intended to go to the
list and just mistakenly sent in private (I don't think there is content
that would benefit from a private discussion):
Jan Warchoł writes:
> 2011/8/5 David Kastrup :
>>
>> If I take the following code:
>>
>> \relative c' {
>> c4
>> \once\override Stem #'color = #red
>> \override Stem #'color = #blue
>> c4 c
>> \revert Stem #'color
>> c4
>> }
>>
>> the result is that the second stem is blue, and the third is already
>> black again. That surprised me. If I take
>>
>> \relative c' {
>> c4
>> \override Stem #'color = #blue
>> \once\override Stem #'color = #red
>> c4 c
>> \revert Stem #'color
>> c4
>> }
>>
>> then the second stem is red and the third is blue which looks like less
>> of a surprise. If we take the following:
>>
>> \relative c' {
>> c4
>> \override Stem #'color = #blue
>> \once\override Stem #'color = #red
>> \revert Stem #'color
>> c4 c
>> c4
>> }
>>
>> then just the second stem is blue.
>
> Very interesting! I'd expect something slightly different.
I think that originally \override was a push, \revert was a pop, and
\once\override was a push/pop pair (that's more or less what is in the
user docs as well).
Then somebody probably thought that \override\override\revert should be
a nop since \override has to be used instead of \set anyway (which would
not push), and turned \override into a pop-push pair (pop never goes
beyond the current context, so "little harm done"). That explains why
the first example pairs the pop from the \once\override with the push
from \override. In the first example, the \override should, when
cancelling the push from \once\override, not leave the corresponding pop
lying around to be executed later.
Now take that incoherent mess, and add nested properties into it.
Apparently the current code has no qualms to start an \override with a
pop that will cancel an entirely unrelated operation.
Now if we do something like (never mind the value and the syntax)
\override a.b.c \override a
should the second \override be able to cancel the first one with its
implied \revert at its front? How about if we do
\override a \override a.b.c
instead? Should the second override be able to cancel the first one?
Only partially? What if we now do
\override a \override a.b.c \override a
How many \revert a should we need to have the stack empty again? If we
do
\override a \override a.b.c \revert a.b.c
what should the state of a.whatever be? Changed against before or not?
What should the state of a.b.c be? Changed against before (to the value
set by \override a) or not?
The effects of override/revert on a straightforward simple property are
currently an unholy mess you can't figure out from the documentation.
And now I am trying to implement sane semantics for nested properties.
How should I try matching mixed-level nested overrides/reverts when the
current implementation does not even sensibly match straightforward
overrides/reverts?
Maybe reverts (in particular from \once\override) should try keeping
some sort of lexical information about what override they are supposed
to cancel, and only apply to that override (in case it is still in
effect) instead of just reverting whatever happens to be at the top of
the override stack when they get their action.
Anyway, I've boiled the additional info for correctly dealing with
nested overrides (once we figured out how to deal with non-nested
overrides sanely) to one value per nested override: the alist entry of
the nested override itself. Everything behind that is not synchronized
to parenting context changes. Everything else in the override is a copy
from parenting contexts (or an override lower in this stack, something
that will need consideration if stacks are not reverted strictly in
order) and needs updating when things underneath change.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Overrides and nesting: intentional?
If I take the following code:
\relative c' {
c4
\once\override Stem #'color = #red
\override Stem #'color = #blue
c4 c
\revert Stem #'color
c4
}
the result is that the second stem is blue, and the third is already
black again. That surprised me. If I take
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
c4 c
\revert Stem #'color
c4
}
then the second stem is red and the third is blue which looks like less
of a surprise. If we take the following:
\relative c' {
c4
\override Stem #'color = #blue
\once\override Stem #'color = #red
\revert Stem #'color
c4 c
c4
}
then just the second stem is blue.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
