Re: respec question: not losing place during reload

Hi Sandro,

On May 9, 2012, at 17:21 , Sandro Hawke wrote:
> It's a little annoying use respec that when I edit in emacs, save, and
> reload in firefox, I then have to scroll all the way through the
> document to where I was to see the change.  If I'm not using respec,
> then reload in firefox keeps me where I am, and I can see the change
> right away.  Does anyone know a way to avoid or workaround this problem?

Yes, it's a known problem, I will file a bug about it, and I think I can fix it. What's happening is that you're using auto-generated IDs for sections (which some people consider bad practice, but RS lets you choose) and the browser tries to find the anchor before the ID has been generated. The fix is to detect that at the end of processing, and scroll the page to that ID. I'll file a bug for it after I'm off the plane and hope to add a fix soon. I have a bunch of fixes to work on and ought to get around to several hopefully next week.

In the meantime, the dirty workaround that works for me is to hit reload, and once it's done hit Cmd-L (or whatever focuses the address bar) and enter. At least in Firefox that does not cause the document to load again but rather it looks for the anchor anew and finds it. Not ideal, but better than scrolling down.

> Also, while I'm thinking about it, has anyone figured out how to run
> respec in a batch/command-line mode?    (I could actually use that as a
> workaround, since firefox wouldn't be dealing with respec in that mode.)

I have an absolutely horrendous PhantomJS script that I use to do that in order to generate the static W3C course that I wrote. It only works with RSv2 (though I suspect it could be adapted to v1) and it essentially detects when a specific debugging console message is sent in order to get the generated content. It randomly fails on what looks like a PhantomJS race condition and it features comments like "I have no idea why, but this is required for things to work". I have to further warn you that code written for PhantomJS is overall strange. The callback to page.evaluate() looks like it's in the same context as the rest of the JS but it actually gets run in the page, variables being only shared in some ways, and the returned data structure being very limited (for your purposes you'll need to get the generated HTML from inside evaluate() and return it to write it to disk).

Anyway, you have been warned. I'm attaching said script, but if you use/adapt it you agree to forfeit all rights to complain about it and are solely responsible if it happens to eat your homework, or your dog, or reopen httpRange-14, as well as for sundry near-apocalyptic and extinction-level events that may follow.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon