Re: stackexchange question: sync html source and rendered buffers

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2018-01-10 12:43, Vladimir Sedach wrote:
>
> > I considered trying to provide a feature for this, but it seemed like a
> > lot of work, and I don't have that availability now.
>
> That does sound like a lot of work (a big feature request posed as a
> question...) and also sounds like a very useful feature.

Quite. It nudges emacs-w3m towards beginning to provide something like
the "developer tools" of firefox etal.

> There is an Emacs package, impatient-mode, that does automatic buffer
> refreshing in JavaScript-capable browsers:
>
> https://github.com/netguy204/imp.el

Very cool!

> Do you have ideas for how to implement this without modifying w3m?

Initial ideas, yes, but nothing that I've researched for viability.

My initial idea was to model the feature on ediff which also presents
two related buffers side-by-side and maintains point synchronization
between them. A name for the feature could be something like w3m-dev,
evoking the "developer tools" in browsers such as firefox. It would
spawn a process to monitor action in either buffer and perform the sync.
An example of a current emacs feature that spawns a background process
to monitor buffers is ispell. There would be no need for this w3m-dev
process to have its own buffer visible as a third window in the frame,
but ediff also allows one to toggle visibility of its buffer.

I would also look at package 'mulitple cursors' for inspiration.

My research would start with looking at the Tex/PDF feature that user
mentioned in his question.

> The most reliable method I can think to implement this is to modify
> the HTML parser to annotate the parse tree so that every character in
> text that will be rendered is mapped to a file position. Then make the
> HTML renderer produce two files: the rendered HTML, and a map from
> rendered HTML file position to HTML source file position.

If that means that whenever one inserts / deletes  a single character
at the beginning of the document, all characters need to be remapped,
that strikes me as an undesirable cpu load.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0