StackExchange's live-preview-with-$\rm\LaTeX$-support gives you the ability to see your mathematics properly typeset as you compose your post, but it has some drawbacks (as everyone who has edited anything substantial on the site knows). In particular, the fact that the entire question or answer is rerendered for each keypress can make for a slow experience when the post includes a lot of mathematics. Additionally, the preview "flickers" a lot since it is replaced and reprocessed for each new character.
I have spent the last week working on an incremental preview, meaning that only part of the preview is replaced and retypeset as the post is edited. This should improve both of these issues: since only a single paragraph (in general) will be typeset, the speed should be improved and only a small part of the post will flicker. It is even possible to prevent that flicker, at the cost of some responsiveness in typing (see below).
I have put together a GreaseMonkey userscript that can be used to test out the prototype for this incremental preview feature. This works in all the major browsers, though some need add-ons to allow userscripts to run (see below). If you want to try it, follow the instructions below and let me know what you think.
Warning: this is beta-test software, and it is pretty complicated, so it may have bugs. Beware that by installing it, you may be taking a risk of losing some of your work (though I suspect that even in the worst case, you could copy the text of your answer, reload the page, and paste it in again to clear any problems).
All the major browsers allow you to run GreaseMonkey scripts but some require add-ons to do this. These are listed below:
- Firefox: GreaseMonkey
- Safari: GreaseKit (also requires SIMBL)
- Chrome: built-in
- Opera: built-in (instructions)
- Internet Explorer: IE7Pro
Note that IE7Pro does work with IE8 and IE9, though its icon may not show up (press the ALT key to get the menu bar and use Tools -> IE7Pro Preferences to access it).
For all browsers other than Opera, simply opening a userscript file will cause it to be installed (or open a dialog asking if it should be installed). Once you have any needed plug-ins and have restarted your browser, click on one of the links below to try out the incremental preview prototype:
Once installed, whenever you open a page with an editor in
meta.math.stackexchange.com, the userscript will try to replace the MathJax preview code with a new version that does the incremental MathJax updates. You can tell that it is working when you see a purple outline to the preview rather than the usual grey one.
The timing for when that can be done is delicate, and if the GreaseMonkey script runs too late, the editor will already be set up and the script will not be able to replace the non-incremental preview code. My experiments suggest that in most browsers there is some variability in when the userscript runs, and it doesn't always run in time to do its job, so you may find some situations where the preview doesn't have the purple outline. In that case, reloading the page often helps. Opera in particular seems to miss the window of opportunity when the page is initially loaded, but usually gets it on a refresh. In IE, clicking in the URL location and pressing return works better than using the refresh key or button. Note that this is an issue with how the GreaseMonkey script interacts with the page — if SE were to make this code official, this would not be a problem.
Once you see the purple border, you know the incremental preview is being used. You should be able to type and edit as normal, but only the paragraph where your changes are being made will be updated, in general. You will see how much of the answer is being updated because it will be displayed in red briefly as it is being updated. This can help you see where you are working visually (but was mainly a debugging tool for me so that I could see whether the correct pieces were being updated).
The Preview Controls
For testing purposes, there are several controls and indicators inserted between the editing box and the preview. These will not be part of the final version, but are there to provide some options to see what people prefer, and to give me some information in case there are bugs that need to be reported. They include the following
A Highlight changed sections checkbox. This controls whether the updates are highlighted in red or not. If you find that distracting, you can turn that off, but you might be interested in seeing how much of the preview is being updated as you type.
A Reduce flicker checkbox. This switches between two different approaches to how the update should be performed. When unchecked (the default), updates will be applied to the screen as quickly as possible, and the mathematics may be visible as raw $\rm\TeX$ code as you type, depending on how quickly you type and how fast the typesetting occurs. As you continue to type, you interrupt MathJax's typesetting, and the screen is updated again leading to the familiar "flicker" that happens as MathJax transforms the $\rm\TeX$ into typeset mathematics.
When checked, MathJax will be allowed to complete the typesetting before the preview is altered again (though keystrokes will be buffered in the meantime). This means that you should only see fully typeset previews, and the result should be more visually pleasing.
The trade-off is that the reduction in flicker comes at a cost in update speed. When this box is unchecked, the characters you type will appear on screen as fast as possible, so the responsiveness of the preview should be high (but you will get the flicker since you are not allowing MathJax to complete its typesetting before updating the preview again). When checked, the preview should always look good, but your typing may appear in the preview in chunks, and so the preview will be somewhat less responsive to your typing and may seem a bit jerky.
A Refresh Preview button. This is for in case the preview gets out-of-phase in some way and you want to have the entire preview refreshed. I have not had to use this myself, but wanted to give you a fail-safe button in case something went wrong. (Alternatively, selecting your entire input, cutting it, then pasting it back in should also refresh the display.)
In addition to these, there are two output areas with numeric readouts. The first is the current "key rate" that represents the average time (in milliseconds) between the last 10 or so keypresses (excluding long pauses). This is used internally to decide on the timing of updates to try to match your typing speed dynamically. The second is the time (in milliseconds) that it took for MathJax to typeset whatever needed updating, which is also used in the timing computations. If you report any bugs, please include these two numbers as part of your report.
If you try out this userscript, please let me know what you think via an answer here, and in particular, your preferences for the two checkboxes that control the preview.
For most typing, it should be sufficient to update a single paragraph, but there are situations where that is not the case. For example, if you are editing a macro definition, that could require reprocessing the rest of the post (to reflect the changed definition), or if you are using
\ref, a changed
\label could require updating elsewhere in the post, since a
\ref could be anywhere. This code should handle those situations properly, but it is a very complicated situation, especially when typesetting can be interrupted by additional typing, so it may be that I have overlooked something. I am particularly interested to hear the experiences of people editing posts with macro definitions or labels and references.
If you have problems with the script, please report these as clearly as you can, and be as precise about what you were doing before the problem, as well as the visual state of the preview that indicates the problem. Please include the two output numbers from the boxes to the right of the "Refresh Preview" button. If you are able to reproduce the problem, please give instructions for what you have to do, so that I can work out the issues.
Note: I am not part of the SE development team, and they have no idea I've been working on this. It may never be included in the SE code base, but your input here can help determine if this approach is feasible or not, and what the implications of switching to it might be. Thanks for your help.