Decoration equality bug?


#1

During some debugging to figure out what was wrong with something in our code, I discovered that the prematch equality checking was returning true when it should be false. For example, if you’re doing a find and replace tool and you have multiple results on a line and it starts at pos 0 for the locals in the decoration set, it matches the first result, then it proceeds to compare that first result to subsequent ones, and instead of matching position or by reference, it just matches by markup and deep compare attrs/spec. As a result it thinks everything is equal and it proceeds but never adds the supposedly equal text nodeview, which i imagine in the minds of most people would be wrong.

This equality behavior can be defeated by adding any field to an inline decoration that is unequal the the other inline decoration. It then fails to pass the equality check. Maybe I missed it, but, I feel like the API and docs do not explain this nuanced behavior.


#2

Decorations are intended to be compared by value, not by identity. Can you set up an example that shows the problem?


#3

Yes, I can try. Might take a few days to get some time for it.


#4

I was not able to replicate this in a simple context. Though I’m not surprised. Since theres a lot of stuff going on there that is based on 2 year old code.