On Mon, Sep 14, 2015 at 05:17:32PM -0400, Karl Dahlke wrote:
> So many things are changing, I mean it's a complete redesign,
> and I'm trying to keep the ship sailing in the meantime.
> If I step back and think about it globally my head spins,
> so I keep head down, stay focused, and make one incremental change at a time.
> 
> As we move forward, more things don't work in the old system,
> and I can't maintain it forever.
> With the latest push, edbrowse runs on the new system by default.
> If you really need javascript, and I have badly broken it,
> export oldsystem=1
> to bring back the old system; but I can't guarantee how long
> it will keep working.

Yeah, I think we probably need to introduce a deadline on that as otherwise
there'll always be a reason to keep the code in the codebase.

> The new system has a new 2 letter command, rr, for rerender.
> It's a little bit meaningless now, but will make sense when
> (someday) we have asynchronous javascript running.

Yeah, that's on my todo list. Do we think that should be before or after the
duktape investigations?
> Perhaps stock prices on the page have changed, which a sighted person
> would just look at the screen and see the change; we would type rr for rerender.
> When you do this now it just says "no change".
> This has no meaning in the old system, or when not in browse mode,
> or when js is inactive.

Sounds good.

> The point here is that rerender is called internally
> after each javascript action.
> Perhaps you clicked on a button, or changed a field
> that has onchange code associated with it, or whatever.
> The objects change, the screen is rerendered, and compared
> against the old.
> Like if you change the state in jsrt to Utah, which changes the color menu.
> 
> This is really really preliminary.
> The comparison is done by strcmp.
> If the screen is unchanged, and it almost always is,
> that's the high runner case, I don't do anything and don't print anything.
> Just move on.
> If a single byte of the screen changes, I delete the old contents,
> put in the new, and tell you that something has changed.
> That's it, for now.
> You get to figure out what has changed.
> Of course I'll put in some more smarts over the next few days,
> some kind of diff algorithm to tell you
> "line 12 has been updated", and perhaps just changing that line
> so I can retain your dot location and any labels you might have set.
> That's coming but for now it's clunky,
> just to prove the concept.

Can't we do something fancy with our line mappings to do this?
It won't be particularly performant but we should be able to isolate the change to a line?

> Yes, we can rerender the tree of nodes again and again,
> and reflect any changes that have been made through javascript.

Excellent. I guess, once all this is finished,
the next step is to get the js to DOM link a bit more automatic such that any
attributes set on a tag's js object are reflected in the edbrowse
representation. Last time I checked this didn't happen but I've not checked the new code.
The same applies for js objects which represent nodes being automagically
incerted into the DOM. Again not checked the new code for this.

Cheers,
Adam.