@terdon, I think you might have read a cached copy of the question since his revision did fix the typo. Regardless, I just edited the title to be a bit more clear and phrased as a question to get rid of any confusion. I like the idea of this feature, but is there any way you can disable the highlighting for a particular code block? (e.g. for terminal outputs or log files which shouldn't be highlighted)

Related: Editing others' questions: etiquette issue with partially off-topic questions?. In general, I'd say the same etiquette applies here as if you were to edit any other user's question/answer. That being said, in this very specific case, I doubt you can shine any additional light on the user's question without any additional input from him/her.

I think this is possibly a bug, albeit a minor one (as even clicking links generated by the share button, like this one, end up being expanded to a "normal" looking one as the first link in the OP (I'd assume it simply rewrites the URL once the question ID is deemed valid). Even if this is not by design, I'd argue that it's (fortunately) just a cosmetic bug and minor annoyance.

And two more (from my answer on What should be featured in our list of off-topic close reasons?): AHK script to toggle hidden folders in Windows 8? and script to scroll page by cursor movement - add the option to pause and change speed with keystrokes

You can always offer a bounty on the question when you get enough reputation, or add a note to the question (NOT including any answers...).

I've been hit by this one a few times, so I never usually click the Close button when I'm unsure without first opening the question in a different browser tab (where you could then hit the Close button and see who voted for what without affecting the review queue). While I agree that you shouldn't immediately fail for clicking the Close button, I think it would be difficult to add back in "fake" votes for a particular reason. I think a better idea might be to allow users to dispute/flag a particular test they felt was invalid, because the tests don't really matter unless there's a problem.

By this logic one should close every question, once it gets a single accepted answer is a gross oversimplification of what I said. I was just pointing out the relatively obscurity of this feature (at least relative to the desktop market, as if that wasn't the case you'd have no reason to ask this in the first place), and that it's unlikely you'll find any answers outside of modifying a PDF viewer or the PDF's themselves. Search as I might, I can only find references to this "feature" in Android software - thus my comments...

Originally this question did appear to be a software recommendation to me; however, even in it's current form, you're unlikely to get any constructive answers (the answer depends on a particular program supporting this to begin with). I think the single answer you have now is as good as it's going to get. Why can't you just manually zoom in and lock/prevent horizontal scrolling? Most PDF viewers should restore your position/zoom for a document when re-opening the file, so this should only have to be done once per PDF...