I am editing a large (25K lines) HTML document -- it will become an online etext of a book -- inspecting it and making numerous detail changes in format and layout. It is most convenient to use the built-in Preview, but even on a fast machine, re-rendering the page after any edit takes almost a second -- during which I can't type or scroll.
I am sure that BBEngineers have gotten a lot of heartburn trying to figure out the exact delay time to wait, after a keystroke, before initiating a redraw of the preview. Right now, it's a little fast for me. For example: say I want to change an <h3> into an <h4>. If I make the change of "3" to "4", well before I can get the cursor to the matching "3" at the end of the line and change the </h3> to </h4>, BBEdit has initiated a redraw -- in which much of the document is rendered as <h4> because there's no closing tag, yet. Actually with practice I have got this particular issue contained: I carefully hilight the opening "3" and then poise the cursor over the closing "3". Type 4 and INSTANTLY drag over the other 3 and type another 4. Whew, made it. What I'm getting at is a feature request for one of two things (or both!) 1) Make the redraw delay a preference setting (lots of room in the HTML Preview pane), user selects number of milliseconds to delay before redraw. 2) And/Or: make redraw a keystroke command -- remember the old spreadsheets, where you hit command-equals to cause a "recalc"? Like that: give me an option to make redraw user-triggered. Then I could make several related edits, with the preview for reference, and see the effect of all at once. Yes, I am quite well aware of the alternatives, I've been doing this awhile. I could open the document in another browser. But then, to see a change, I have to cmd-s, click in the other window, click the reload button. Or, I could close the BBEdit preview window and set a keystroke to re-open it. Either method is slower and has more mouse moves than just using the built-in preview... which is great, it's just a little annoying and could easily be fixed. Thanks for listening, Dave Cortesi
