'Preview in BBEdit' Bug

Too bad it's nearly useless.

You see, every time the preview is re-rendered, its scroll position is reset.

This makes live preview while editing longer documents practically impossible. Picture it: you scroll the preview to the end of your document. You start adding text to the source window. Bango, the preview is refreshed and you're staring at its top again. You scroll the preview back to the bottom. Add more text. Auto refresh fires again, and you're staring at the top of the preview again. Rinse, lather, repeat. Pen frustrated weblog entry.

It's a real shame. Bare Bones comes so very close. Otherwise, the feature has their characteristic polish. Unlike SubEthaEdit, which first offered realtime HTML preview, BBEdit doesn't update its preview with each keystroke. That slows down the typing, and I find the extra window updating distracting. Instead, BBEdit waits for one second of idle time before re-rendering. Very nice -- effective real-time updating sans impeded typing and distracting updates.

I hope it's something that's easy to fix, and not something indicative of say, using the WebKit's Carbon API (versus the Cocoa API). Because that would, well, Suck®.

Update: Commenting on Eric Albert's response to this posting, Dominik Wagner of SubEthaEdit fame spells out how to fix WebKit's behavior. I now realize I failed to mention SubEthaEdit gets this behavior right. Nice work, and thanks for sharing how you pulled it off!

Update: This bug is fixed in BBEdit 7.1.1. Thanks, guys!

Update: I upgraded the BBEdit links to point to permanent pages. Thanks to John Gruber for poking Bare Bones to offer permalinks and cluing me in about them.

Tuesday, November 18, 2003
12:00 AM