Tighten mark addition logic against zero-length marks. #3005
Conversation
themithy
force-pushed
the
michal/tighten-zero-length-marks
branch
from
f3806a7 to
1309536
Compare
themithy
force-pushed
the
michal/tighten-zero-length-marks
branch
from
1309536 to
f3444af
Compare
| if (key === end.key) length = end.offset | ||
| if (key === start.key && key === end.key) | ||
| length = end.offset - start.offset | ||
|
|
There was a problem hiding this comment.
is this change significant for the fix or is this just trying to tighten up logic?
There was a problem hiding this comment.
This logic is slightly different now specifically in the case where (key === start.key && key !== end.key)
Before:
length = node.text.length
Now:
length = node.text.length - start.offset
There was a problem hiding this comment.
Sure this is needed, if you move the offset you need to truncate the length accordingly - in both cases when key === and !== end.key
|
Hey @themithy this looks good to me. Can you add a test to ensure this logic? Might be hard with normalization, not sure. |
|
I believe that this may be fixed by #3093, which has changed a lot of the logic in Slate and |
Hi,
When adding marks to multi-line range it might happen that a mark is added to zero-length text node. Although such situation is corrected then by normalization, extra operations are generated unnecessarily.
This fix tightens the logic.
Thanks.