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
## Details
When computing widths for concealed text in highlights we were correctly
using the display width of the associated node's text. However, when
accounting for conceal `extmark`s added by this plugin we simply used
the difference between start & end column, which is the size in bytes.
This meant that if something concealed by this plugin contained glyphs
which are displayed shorter than the number of bytes (common in many
languages) we would incorrectly calculate offsets.
Fixing this is a little involved since we need access to the actual text
that is being concealed, however when adding the mark all we have is the
range. We can get around this since we do have access to the text and
start / end columns when we are computing the widths. So we no longer
store the width information directly, instead we store the concealed
ranges along with some additional metadata, find the overlap of these
ranges with the text, then calculate the width of the text associated
with any overlaps.
To make this all work we needed to be much better about how ranges were
stored and added. We do a coalesce operation (similar to view ranges)
each time a new one is added at the row level, when we combine a range
with another we include the combined conceal characters and the number
of individual blocks that made the combination. This information is
needed to correctly handle different conceal level behaviors.
The `interval` module `overlaps` method has been replaced with an
`overlap` method which returns the region associated with an overlap
rather than just a `boolean`. This was needed for the new functionality,
existing usage was replaced since checking if `overlap` is non-nil does
the same thing.
Minor quality of life improvement for unit testing, the `expected` marks
are now sorted using the same logic as the `actual` marks before being
compared. This means the order information is added does not matter for
correctness allowing us to share common marks as needed. For instance
for many of the `table` related tests the offsets and such are different
but the pipe related marks all occur at the same absolute locations, so
we can create a method to compute those and include them where needed.
0 commit comments