You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tricky one, since the original reasoning for applying active
styles first is still correct, but an edge case disrupts it.
When parsing an nested expression, when the start of an annotation is
green it becomes active, and when it is closed it becomes pending.
Take the following string for example:
{red:hello {green:there {blue:you} and} good} day
The list of active (and pending) styles would look like so:
- red
- red, green
- red, green, blue
- red, green (blue pending)
- red (green pending)
- (red pending)
As such, the pending styles are the most recently applied, and so should
be applied last to have a higher priority, as is appropriate.
However, this situation becomes complicated when interpolation occurs,
as when an expression is interpolated we need to jump out of the usual
processing, and active styles can be more specific than pending.
Consider this example
{red:hello} {green:there$(interpolation)}
Now the active/pending styles are:
- red,
- (red pending)
- green (red pending)
- interpolation happens!
In this situation, note that the pending style should be applied first.
If this was the only code responsible for annotation ordering was in
addpart!, we'd be in a bit of a conundrum, because fixing the second
example would break the first. However, thanks to other recent efforts
to handle nested annotations better (e.g. dfef96d) we can adjust
the code in addpart! to handle the linear/interpolated case correctly,
and the nested behaviour isn't broken.
To be completely frank, I'm not entirely sure that this is exactly and
everything going on. This is arguably the most complicated part of the
code base, and (re)building a mental model of the entire parser
intricate enough for me to be able to declare this with confidence would
be the work of a morning/afternoon, at least.
However, it is well-tested, and with this change none of the tests
break (and one is fixed). As such, I feel there's sufficient
justification to run with the theory I outlined above until such a time
that further complications pop up (if they ever do). We should add some
more tests around annotation order, but for now we seem better off with
this change than without it.
Hopefully in the future, further tests will be written for this part of
the codebase, and the behaviour entirely ironed down. Writing
intelligent tests does take some effort though, so for now I'll take
better observed behaviour and potential future bug-fixes. Ideally some
other contributors will be attracted to this project and somebody other
than me will write these tests :)
0 commit comments