Searches take you to the wrong place after the file is edited

[ByteOfBrie]

When you search, the results are stored with offsets. When you edit a file that you've searched in (specifically the text before it), the offsets become wrong, and it takes you to the wrong spot in the file.

I see a few possible approaches for this:

1. Live search, basically re-searching every time an edit is made (or on save/when search is interacted with, but ideally done in a way that wouldn't break everything when you tried to go to the next search after an edit was made. This is probably workable, and my guess as to what most other applications actually do.
2. Keeping track of the offsets that are in the file being edited, and then updating the position if an edit is made earlier in the file. This might be difficult to implement (especially with pasting and formatting), and you need to keep track of all the files in the search but it should work reasonably well.
3. Using the surrounding text to try to keep track of which search is which. This probably isn't worth implementing, since it will only work some of the time and would lead to users being confused about that.

Personally, I'd probably try to implement live search. It seems like it would be the most useful, and shouldn't be too difficult to do, and would work in the way that people expect.

I don't think performance issues are a big concern here, although depending on the exact implementation, there could be some impact. It's at least worth thinking about, and if we did some sort of live search, we'd probably only want to do so in that particular file.

[obw]

As I mention in #1318 when we could make Manuskript concurrent, a lot of performance problems, should be gone! But also I knew, multithreaded programming, has its own fair share of Problems.
If we could split some actions, like word count and spellchecker (which are both reasons for the lag), to own threads, Manuskript would run much smoother, also a research, after each edit will not create a not bearable lag!

[TheJackiMonster]

As I mention in #1318 when we could make Manuskript concurrent, a lot of performance problems, should be gone! But also I knew, multithreaded programming, has its own fair share of Problems. If we could split some actions, like word count and spellchecker (which are both reasons for the lag), to own threads, Manuskript would run much smoother, also a research, after each edit will not create a not bearable lag!

I don't think concurrency is the right way to solve the problem, honestly. It brings way too many problems with it that most people can't fix and it can make software extremely unreliable.

I would think it makes much more sense to use asynchronous calls of heavy functions. So they don't stall any user input while running.