search

minad / jinx

🪄 Enchanted Spell Checker
GNU General Public License v3.0
432 stars 21 forks source link

Eagerness of misspelling overlay while typing #38

Closed gusbrs closed 1 year ago

gusbrs commented 1 year ago

I've been defaulting to jinx-mode here to try things out and overall I'm very happy with it. Thank you!

One thing that currently feels a little intrusive is that the misspelling overlay is too eager for when one is typing. The overlay kicks in mid-word, when the word is obviously misspelled since it isn't finished. This is distractive and, imho, would best be avoided if possible.

Would there be a way for the overlay to kick in only after hitting SPC? (or some non-word character, e.g. punctuation). I think that's how flyspell works. I don't recall being bothered by this with flyspell, but it may be the fact that jinx is faster, I'm not sure. That given, an obvious mitigation would be to increase jinx-delay, but I'd still go for the "space trigger" if the situation can be distinguished. WDYT?

I don't know how to identify the situation formally. Naturally only "point at the right edge of the word" is not sufficient, since if one navigates there some other how we don't want the overlay to disappear. Perhaps "point at the right edge of the word" + "last-command = self-insert"?

minad commented 1 year ago

Thanks. Yes, I've noticed this one too from time to time, but it doesn't bother me too much. This doesn't happen often since I usually type fast enough. You can use a larger value for jinx-delay. Longer delays are better anyway for performance. I had also experimented with two different delays, one for post command hooks (slow for typing) and one for scrolling (fast).

minad commented 1 year ago

Perhaps "point at the right edge of the word" + "last-command = self-insert"?

This could be a good heuristic, however it is not completely trivial to add this to the current infrastructure. One would have to defer the checking of the word somehow or temporarily hide the overlay and then unhide it afterwards. If there is interest in this, I'd welcome a patch.

gusbrs commented 1 year ago

This could be a good heuristic, however it is not completely trivial to add this to the current infrastructure.

Wouldn't a predicate work for this?

If there is interest in this, I'd welcome a patch.

I don't know of others but, even if I get it working, I can't offer one. No papers. I'm only allowed reports, suggestions, ideas, etc.

minad commented 1 year ago

Wouldn't a predicate work for this?

No, since then the word may not get highlighted at all.

gusbrs commented 1 year ago

No, since then the word may not get highlighted at all.

Mhm, pity, that was my first thought.

Btw, I did test flyspell and my memory did not fail me: the overlay does not kick in until you hit space even if you let it linger there for several seconds. So, as far as I can tell, it is not "delay" difference, it is a difference of behavior. (I have no idea how flyspell does it, though).

minad commented 1 year ago

Thinking about this again - a predicate with a side effect may work. The predicate could check for self-insert and the word boundary. Then it could reschedule a refontification of the current line. Another small complication here is that the point information is lost while scanning over the words, so overall it may not be simpler than https://github.com/minad/jinx/issues/38#issuecomment-1505309763.

Btw, I did test flyspell and my memory did not fail me: the overlay does not kick in until you hit space even if you let it linger there for several seconds.

Yes, Flyspell works in a different way. Nothing wrong with sticking to it if you like it. It doesn't Fly for me, that's why I have Jinx.

gusbrs commented 1 year ago

Thinking about this again - a predicate with a side effect may work.

:+1:

Yes, Flyspell works in a different way. Nothing wrong with sticking to it if you like it. It doesn't Fly for me, that's why I have Jinx.

That was not my point, and you know it...

minad commented 1 year ago

I think I found a reasonably simple solution for the problem. It should at least catch the most common case during typing and completion. But as soon as one starts to move around, Jinx will start to get annoying again.

gusbrs commented 1 year ago

I think I found a reasonably simple solution for the problem. It should at least catch the most common case during typing and completion. But as soon as one starts to move around, Jinx will start to get annoying again.

Thank you! I'll test when it gets here.

But, a comment, I've seen you used (eq last-input-event ?\s). Wouldn't it be better to test whether the character is not word syntax?

minad commented 1 year ago

But, a comment, I've seen you used (eq last-input-event ?\s). Wouldn't it be better to test whether the character is not word syntax?

Right. It gets slightly more ugly, but we can do that. https://github.com/minad/jinx/commit/6c13df5966b59f69d0694638c86c3b94750c9f58

gusbrs commented 1 year ago

Right. It gets slightly more ugly, but we can do that. 6c13df5

If it does the right thing it looks pretty to me. ;-) Thank you!

gusbrs commented 1 year ago

I was still thinking about this one and I just saw you went from "disabling the timer while typing" to "skipping the current word". Looks good! Thank you very much once again!