28
$\begingroup$

Overview

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).

Installation

All the major browsers allow you to run GreaseMonkey scripts but some require add-ons to do this. These are listed below:

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:

Usage

Once installed, whenever you open a page with an editor in math.stackexchange.com or 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.

Collecting data

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 \label and \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.

$\endgroup$
9
  • $\begingroup$ Great! Does this supercede the earlier extension you suggested to test? $\endgroup$
    – Bill Dubuque
    Commented May 13, 2012 at 17:38
  • 1
    $\begingroup$ You should not use both at once. That one had a particular issue it was trying to target as the cause of your crashes (apparently that wasn't it, since leonbloy continues to have problems, though I'm reserving judgement until I get more information). This one is about improving speed and visual appearance during editing, and isn't targeted at the crash issue per se. My hope was that it might help, but if the crash is due to memory problems (as it seems it might be, since I can't think of anything directly tied to MathJax), then this won't help with the crashes. $\endgroup$
    – Davide Cervone
    Commented May 13, 2012 at 17:45
  • $\begingroup$ So which do your prefer to be tested? Is it ok to run the first extension in Chrome, and this one in IE/FF so to test both simultaneously? $\endgroup$
    – Bill Dubuque
    Commented May 13, 2012 at 17:54
  • $\begingroup$ Yes, that would be fine. $\endgroup$
    – Davide Cervone
    Commented May 13, 2012 at 18:01
  • $\begingroup$ It looks great so far, thanks! I am looking forward to trying it out for real in coming days. $\endgroup$
    – MJD
    Commented May 13, 2012 at 20:17
  • $\begingroup$ I have the plugin installed on my laptop but not on my desk machine, and when I use the desk machine, I actively miss the plugin. $\endgroup$
    – MJD
    Commented May 22, 2012 at 21:13
  • $\begingroup$ Davide: I did test this quite extensively with my old laptop, and it definitely helped. A drag was that (as you predicted) I occasionally had to hit FF's refresh button 3-5 times, before it worked as prescribed. I have since upgraded from a dual core Win XP laptop to a quad core Win 7 laptop, and I have not yet had the need to install that GreaseMonkey script. IOW the HW/OS upgrade seems to have made the problem go away. I still very much appreciate you tending to this matter. If the problem reappears, I will continue testing your script. For now I'm a happy camper. $\endgroup$
    – Jyrki Lahtonen
    Commented Feb 11, 2013 at 17:28
  • $\begingroup$ Is this being maintained? $\endgroup$
    – user142198
    Commented Sep 15, 2014 at 3:41
  • 1
    $\begingroup$ No. They've changed the timing of how the page loads its components, and I can't link into the sequence at the right time anymore. Sorry! $\endgroup$
    – Davide Cervone
    Commented Sep 15, 2014 at 10:25

3 Answers 3

Reset to default
2
$\begingroup$

I tried it on some of my longer posts and it worked almost perfectly well! I like the idea of highlighting the part being changed, although I think it would be better if it didn't stop being highlighted after a pause in typing. Now the text will change its color all the time during typing. (I pause often when I type.) I'm also not sure if the red font is the best way to highlight the text. Perhaps changing the background color a little bit would be better?

I also like the reduce flicker option. It gives a much more pleasant look to the preview.

One strange thing that happened can be seen on the screenshots below (one file, two screenshots):

enter image description here

As you can see the purple outline behaves differently in the two.

Another thing that happened, and I was too stupid to take a screenshot of, was that when I left the text of this very answer alone for a moment, with the cursor positioned right after "I tried" (the first words), the words got suddenly enclosed in a strange "box" and the font got strangely distorted within it. I'm sorry I can't explain it any better, but I stupidly pressed some button, and everything got back to normal.

I use Firefox 12.0.

EDIT I got the "box" to show up again, so I'm posting a screenshot. Nothing happened to the font inside this time.

enter image description here

$\endgroup$
4
  • $\begingroup$ Thanks for your report. I will look into the overlapping problem from your first image. I'm not sure what the font issue was that you saw. What browser/os are you using? About the highlighting, certainly the style can be set to do something like background rather than foreground color. It was originally just to help be debug what was being updated. Are you recommending that the color never be removed (during editing), or just advocating a longer delay? $\endgroup$
    – Davide Cervone
    Commented May 26, 2012 at 15:48
  • $\begingroup$ @DavideCervone I'm using Firefox 12.0 on Windows XP. I think it would be best if the part with the cursor in it were always highlighted (with some subtle but visible background color change). $\endgroup$
    – user23211
    Commented May 26, 2012 at 16:25
  • $\begingroup$ @DavideCervone I have added a screenshot with the box I was talking about earlier. $\endgroup$
    – user23211
    Commented Jun 19, 2012 at 22:15
  • 1
    $\begingroup$ Thanks, I see what it is now. It is the second output indicator that should be next to the [89] next to the Refresh Preview. But because the "Draft saved" message has shown up, it caused the second box to wrap, and you are seeing some of the border (the text of the answer is covering up the rest and the number that it contains). In any case, it is nothing to worry about, though a bit annoying. $\endgroup$
    – Davide Cervone
    Commented Jun 19, 2012 at 23:43
2
$\begingroup$

This seems to have stopped working a couple of weeks ago. When I have the extension enabled, my editing window looks like this:

screenshot

Notice the vestigial preview area.

Disabling the extension brings the situation back to normal; enabling the extension again causes the problem to recur.

My browser is:

Google Chrome   18.0.1025.142 (Official Build 129054)
OS  Linux
WebKit  535.19 (@111933)
JavaScript  V8 3.8.9.16
Flash   11.2 r202
User Agent  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19

I hope this helps you figure out the problem, because I liked using the extension.

$\endgroup$
3
  • 1
    $\begingroup$ I'll look into it as soon as I get the chance, but that may not be until next week. I did notice that they have recently changed to using a minimized version of the file that sets up the MathJax extensions to the editor. I suspect there is something minor that needs to be adjusted to coordinate with that. There were some delicate timing issues, and I hope that the change to minified version doesn't change the timing, or we might not be able to insert the patch at the right time. I'm hoping it is just that something that used to say "-new" no longer does, and that changing that will fix it. $\endgroup$
    – Davide Cervone
    Commented Oct 15, 2012 at 14:42
  • $\begingroup$ I am not in a hurry to have it fixed, so please deal with it at your convenience. Also thanks again for your brilliant work on Mathjax, which continues to amaze and delight me. $\endgroup$
    – MJD
    Commented Oct 15, 2012 at 15:04
  • $\begingroup$ It may be useful to know that quite a while ago it stopped working in Firefox (currently 16.0.2); when I enable the Greasemonkey script, it kills the editing tools that normally appear just above the preview window, but that’s all it does. This is apparently the same behavior that Chrome is now exhibiting. It was still working in Chrome when the Firefox bug appeared, but I don’t like Chrome and in any case can’t live with the crashes, so with regret I simply stopped using the incremental preview. $\endgroup$
    – Brian M. Scott
    Commented Nov 1, 2012 at 18:13
1
$\begingroup$

Here's one deficiency I've run into so far: In an enumerated list, say this one:

  1. Item 1.
  2. Item 2.
  3. Item 3.

the software re-renders the entire list (all three items) whenever I edit any one of them. I think it would make more sense to re-render just the single item I have edited.

It's not a serious problem, however.

$\endgroup$
3
  • 1
    $\begingroup$ The code as it currently stands always rerenders a top-level HTML element (usually a paragraph), but since the list items are contained in an <OL> element at the top level, that is what gets rerendered, so it is the entire list. The reason for that is that the code must keep track of a bunch of data about each element that it could rerender, and the bookkeeping gets pretty hairy if you can descend into the HTML tree. It might be possible to make an exception for lists, though. A suggestion worth thinking about. $\endgroup$
    – Davide Cervone
    Commented May 15, 2012 at 0:38
  • $\begingroup$ The matter came up in connection with this post, which is nothing but a giant list. $\endgroup$
    – MJD
    Commented May 15, 2012 at 0:40
  • 1
    $\begingroup$ Point taken. I'll give it some thought. It does complicate a number of routines within the code, however. It might be possible to descend into containers whose children are all containers themselves. That would cover your situation of lists of lists, and other nested blocks like quoted material or code blocks. $\endgroup$
    – Davide Cervone
    Commented May 15, 2012 at 0:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .