Limit the update rate when editing large files about ghosttext HOT 2 CLOSED

Can SublimeText know when the browser has finished receiving an update? Rather than using an arbitrary throttling duration, SublimeText could wait for the browser's response before sending a new update. Could that work?

from ghosttext.

Can SublimeText know when the browser has finished receiving an update? Rather than using an arbitrary throttling duration, SublimeText could wait for the browser's response before sending a new update. Could that work?

We could update the protocol sending an "update processed message" back to the server, but this solutions drawback would be heavy increased complexity.

Let's take the JS code editor with the Firefox add on as currently most complex solution of message passing, the pages JS scope has to inform the content script scope that the text change has been processed this message has to be passed to the main script which has to pass the message to the background script which finally sends the "update processed message" to the server.

The server code needs some more logic, too. Take a look at the current Atom prototype: https://github.com/Cacodaimon/GhostText-for-Atom/blob/master/lib/ghost-text.coffee less than 80 lines of code are enough for a minimalistic solution or this prototype of an gedit3 plug in: https://gist.github.com/Cacodaimon/eebeb67043b3acef3282 140 lines + the ST plugin's WebSocket and HTTP code are enough for this prototype to work.

I like your Idea because it is more deterministic, but I'm afraid that increasing the complexity could slow down the development.

We have no statistics about the used, but I believe the most texts edited with GT are smaller ones like this comment rather large CSS files which caused this issue: Connection errors #31 #29 . Which could means that this issue would increase the complexity for less than 20% of the use cases.

from ghosttext.