Crash in STLineNumberRulerView.invalidateLineNumbers() when deleting content

[iliasaz]

Hi Marcin,

I've been testing your sample app with the line number ruler and have come across a use case that results in a crash consistently. Here are the steps to reproduce:

1. Start the sample app (TextEdit or TextEdit.SwiftUI with added line numbers).
2. Put a cursor a couple paragraphs down.
3. Select all text to the end (Cmd+Shift+End)
4. Press Delete

Then you get this:

STTextView/STLineNumberRulerView.swift:190: Fatal error: Unexpectedly found nil while unwrapping an Optional value

It works fine when selecting and deleting all text (Cmd+A, Del)

Also, something weird is happening when I select all text, delete, and then revert back by Cmd-Z. Only the first line appears back until I click anywhere or press any key.

Thanks!

[krzyzanowskim]

thank you! I'm able to reproduce. I fixed the crash already, but there's still a display update issue after delete that I'll tackle at some point

[iliasaz]

Thanks a lot for fixing the crash!

I noticed a couple more issues today. Let me put them here so that I don't spam your Discussions section ;-)

(1) Sometimes, the Find command doesn't scroll to the line/position where the word is to be found. It does scroll somewhere, but not to the right location. Try searching for "more" in your text and then hit "next" several times and watch where the highlighting goes. The yellow highlighting works only on the first match, and that's no big deal because other matches are still highlighted with white. But sometimes, when hitting next you just see the gray background and no white or yellow highlighted words. That can be very confusing.

(2) Find&Replace mode adds a substantial lag when scrolling and resizing. Duplicate your text 4-5 times, then search for "more", then try to scroll.

(3) Trying to Select All (Cmd+A) on a large text (copy/paste your text 4-5 times) hangs the view for about 20 seconds and doubles the memory utilization.

Thanks again for doing the great work. Your implementation of a text view is the best I could find by far.

[krzyzanowskim]

thank you!

(3) Trying to Select All (Cmd+A) on a large text (copy/paste your text 4-5 times) hangs the view for about 20 seconds and doubles the memory utilization.

It turns out NSTextLayoutManager.enumerateTextSegmentsInRange is annoyingly slow. Gotta find workaround for that

[krzyzanowskim]

that is improved in main branch

[krzyzanowskim]

I noticed a couple more issues today.

I think I managed to fix it. Fixes are on branch main. Please play with it in case I missed something

[iliasaz]

Wow, great progress - thank you!

• The crash is definitely fixed.
• Cmd+A, Del, Cmd+Z is fixed.
• Cmd+A slowness is fixed.
• Scrolling while in find mode has definitely improved by a lot. It still lags in the area with right-to-left languages, though.

Now, the Find mode has improved, but it's not fixed yet. There seems to be more than one issue at play, and it's a bit beyond my comprehension of your code :-) So I put my QA hat on and tested this case more thoroughly. Let me give you more detailed steps to reproduce.

I copied your text 5 times in STTextView and in Sublime.
Then I searched for the word "infamous". Both STTextView and Sublime find 5 occurrences, which is correct.
STTextView correctly highlights the first match on line 13.

Then I click "next" button in the Find toolbar. The view should've scrolled to line 543. But I got this instead:

As you can see, it underscrolls.

I click "next" button again. The next match should have been on line 1073. Instead, I got this:

This was an overscroll. It actually scrolled passed the 4th occurrence.

Now, if I manually scroll back up to the 4th occurrence in line 1603, it is not highlighting the match.

So I put the cursor on line just above 1603 and clicked next again. It now highlights the word, but now the line numbers have gone missing in the ruler view.

And I click "next" again. Now the line numbers are back, and 1603 line match is highlighted correctly. Though I'd expect it to go to the line 2133 now, that's a minor thing.

Now, the worst thing is that if I simply go back to the top of the document and search again, I get different results. But if I kill the app and start over from scratch, then I can reproduce it exactly as I described above.

Not sure whether it is helpful or not, I did my best :-)

[iliasaz]

Hi Marcin,

I see you've made quite a few changes recently so I retested the above scenario on the new build, and it still reproducible. I figured the issue is in textSegmentFrame method of NSTextLayoutManager extension. enumerateTextSegments seems to resolve the rectangle at random sometimes, especially on large texts. I also tried passing different options in addition to upstreamAffinity, but it doesn't seem to help.

enumerateTextSegments(in: textRange, type: type, options: [.upstreamAffinity]) { _, textSegmentFrame, _, _ -> Bool in
            if result == nil {
                result = textSegmentFrame
            } else {
                result = result!.union(textSegmentFrame)
            }
            print("fragment: \(textSegmentFrame), result: \(result), for textRange: \(textRange)")
            return true
        }

fragment: (5.0, 0.0, 0.0, 19.2), result: Optional((5.0, 0.0, 0.0, 19.2)), for textRange: 0...0
fragment: (205.9033203125, 230.39999999999995, 40.1806640625, 19.2), result: Optional((205.9033203125, 230.39999999999995, 40.1806640625, 19.2)), for textRange: 354...359
fragment: (205.9033203125, 3559.7278836162095, 40.1806640625, 19.2), result: Optional((205.9033203125, 3559.7278836162095, 40.1806640625, 19.2)), for textRange: 24577...24582
fragment: (205.9033203125, 19767.669841269824, 40.1806640625, 19.2), result: Optional((205.9033203125, 19767.669841269824, 40.1806640625, 19.2)), for textRange: 48800...48805
fragment: (205.9033203125, 12326.400000000101, 40.1806640625, 19.2), result: Optional((205.9033203125, 12326.400000000101, 40.1806640625, 19.2)), for textRange: 73023...73028
fragment: (205.9033203125, 16358.400000000252, 40.1806640625, 19.2), result: Optional((205.9033203125, 16358.400000000252, 40.1806640625, 19.2)), for textRange: 97246...97251
fragment: (205.9033203125, 20258.937931034867, 40.1806640625, 19.2), result: Optional((205.9033203125, 20258.937931034867, 40.1806640625, 19.2)), for textRange: 121469...121474

[krzyzanowskim]

In the meantime, I refactored that part of code significanly and STLineNumberRuleView is completely gone. That should fix that issue.

I'm closing this one, feel free to open new discussion if there's something different to discuss.