Fletcher on 06 May, 2018 02:46 AM
It looks like the jump happens after you type a space and then t (thereby disabling the "don't update preview when typing a space" function), but the preview update must have already been triggered because it doesn't include the t in the preview, meaning the last character it saw was the space.
When I compare the latest release to the latest beta, the beta seems more responsive (the preview updates more frequently).
In fact, when typing gibberish, which results in a lot of misspellings to be flagged, it is much faster. Which must be because I was able to revert to the default spell checking behavior with some recent changes.
I'll have to see what I can do about this. Updating the preview has to be asynchronous (because it can be much slower than a keypress and would slow things down). But it does run the risk of refreshing in between keystrokes like that.
Interestingly, there is a "sweet spot", or perhaps I should say "sour spot" in typing speed vs refresh speed. If I type much faster than the preview, then it will be rare that the preview updates before a space, and immediately after the space (which is when Apple's "space bug" occurs). If the preview is much slower than my typing speed, then there will be enough of a delay that the preview waits for me to type something else after typing a space.
I'm looking into an efficient way to avoid this....
Fletcher on 06 May, 2018 02:32 PM
Just pushed 4.4 b5. I adjusted the preview refresh delay to improve performance as well as reduce the jumpiness.
(Below technical comments are for interested readers and to remind myself in the future...)
That said -- I don't know that there is a way to 100% prevent the "space bug" from occurring:
(For those who are unfamiliar, there seems to be a long-standing bug in Apple's WebView whereby changing this to this<space> causes the preview to jump vertically. This has been a persistent problem since the first versions of Composer, and others have documented it as well.)
Option A is synchronous refreshing of the preview, which would destroy performance with longer documents with every keystroke where a refresh occurred.
Option B is asynchronous refreshing (like now). I've adjusted the timing and delay settings to minimize this, but it is still theoretically possible to type at a certain speed relative to refresh timing and trigger the bug. Basically I am trying to play with statistics to make the bug rare, but can't make it impossible. Advantage -- adjusting this is really easy, though it can be trial and error to find good settings. Disadvantage -- it's not perfect, and ideal settings will vary based on user and machine variables outside of my control (typing speed and characteristics, CPU speed, number of CPU processors, other programs running at same time, etc.)
Option C would be to jump through some hoops to try to synchronously and atomically grab the contents of the textview and the last character typed, and then perform the updates in the background. This would still hurt performance due to having to copy the entire contents of the text view for every keystroke, but not as badly as option A since the rest would be in the background. I would prefer to avoid this approach, but can consider it if necessary.
Option D -- use asynchronous refreshing, but on every refresh compare the existing HTML with the replacement HTML to verify that a space is not the only difference between the two. This will hurt preview performance, but should not affect typing responsiveness. It would increase overall CPU usage and therefore decrease battery life (by some as yet unknown amount.) This might be better than option C, but still seems like overkill.
For now I will try to tweak the timing settings to minimize the bug.