On non-consecutive ranges, we were drawing the starting line on top of the separator, which lead to some visual glitches in some viewers (e.g. Chrome).
On non-consecutive ranges, we were drawing the starting line _on top_ of the separator, which lead to some visual glitches in some viewers (e.g. Chrome).


Not really useful since we're only checking if an index is in the list later on (line 431/434)
Also, dedup doesn't modify the array in place so the result should be reassigned to the variable
range-boundaries=range-boundaries.dedup()
Not really useful since we're only checking if an index is in the list later on (line 431/434)
Also, `dedup` doesn't modify the array in place so the result should be reassigned to the variable
```typst
range-boundaries = range-boundaries.dedup()
```
It seems like removing duplicates is not really necessary because the only time we read from the list is to check whether it contains particular indices. I'd suggest not calling dedup at all
It seems like removing duplicates is not really necessary because the only time we read from the list is to check whether it contains particular indices. I'd suggest not calling `dedup` at all
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On non-consecutive ranges, we were drawing the starting line on top of the separator, which lead to some visual glitches in some viewers (e.g. Chrome).
@@ -392,1 +392,4 @@range-boundaries.push(start-i)range-boundaries.push(end-i)}range-boundaries.dedup()Not really useful since we're only checking if an index is in the list later on (line 431/434)
Also,
dedupdoesn't modify the array in place so the result should be reassigned to the variableWhat do you suggest we do instead?
It seems like removing duplicates is not really necessary because the only time we read from the list is to check whether it contains particular indices. I'd suggest not calling
dedupat allOk, done.
3a0331f33btob6f2fd99b8