Spellcheck intermittantly looses location in editor

[jrstrick]

When spell checking a document, spellcheck will append the changed spelling to the end of the text rather than overwriting the highlighted word. I have not yet determined what starts this.

[jrstrick]

Since my novel is in the final edit stage, I'm hitting this much more often, and I've isolated it a lot more.

What happens is this: When you open a large document (a novel, in my case), select a document, and right-click on a spelling mistake, or for any other reason, it works as you'd expect it. In the case of spell checking, it pops up the suggestions.

Any time you make a search, however, and open the document from the search list, right clicking sends you to the end of the document.

If you then select a document from the documents list as normal, right-click works normally again.

It looks very much as though search is leaving your span in the wrong state, if I understand how this actually works.

[TheJackiMonster]

It looks very much as though search is leaving your span in the wrong state, if I understand how this actually works.

Thanks for the detailed feedback. This might help to find the bug in the code and fixing it.

[TheJackiMonster]

I've commited a patch to the develop branch. You can test it by running Manuskript from source (explained in the wiki) or wait for the upcoming release which should include it.

Most of the time the issue should be gone. However it can still occur if you try to open a context menu via right-click on the exact portion of a word highlighted from the search. It is difficult problem because two different parts of the application fight around behavior what to highlight and what should be cleared. So I don't think there's an easy way to completely avoid this issue. But I think for most purposes the problem of a jumping cursor is gone now.

Hope this helps.

[jrstrick]

The spell check select problem seems to be resolved. I can replicate what you're talking about right-clicking on the exact portion of word highlighted from the search. Even after deselecting the search result, it still happens, and that word is subsequently 'poisoned' from ever being right clicked again. Clearing the search seems to make the word selectable again, although I'm not completely clear.

[TheJackiMonster]

Thanks for testing. I might look into it again but as I mentioned the problem is kind of complex due to multiple widgets overriding events there. The search tries to reset the cursor when it looses focus while the suggestion sets the cursor to the word (selecting it) and the click on the suggestion is what causes the focus-loss of the search widget.

The event management is not done globally though. So I can't properly clear it before or after handling the suggestion. But maybe I can create a global flag indicating that the cursor was touched/moved (even if it's technically the same position or word as the search selected). Then disable the clearing in this case.

I also have to double-check whether the clear-event-handlers get dropped after one usage. Because it didn't look like it was cleaning that up properly. ^^'

So I keep this issue open for now.

[TheJackiMonster]

I've pushed another patch upstream: 7293db7

The only solution I could find which would not cause any other kinds of problems is removing the clearing handler completely from use in case of text edits. Because the other idea I had was to remove it only in case the cursor in the text edit changed. However this still caused issues when right-clicking the selected part from the search, resetting the cursor somewhere while opening the context menu.

So now any selection the search does in a text edit will stay until you move the cursor anywhere else. Maybe we can refactor the search in a way to not select via the text cursor but using tags instead. However that needs a separate issue.

[jrstrick]

I think this behavior is pretty much exactly right. I think I've seen other apps where if you touch the results of a search, you have to redo the search to get the others, and I'm ok with that. I'm willing to mark this closed if you are.