Fix the most urgent bugs#81
Open
grothesque wants to merge 6 commits into
Open
Conversation
This commit introduces handling for fragmented websocket frames in the atomic-chrome Emacs extension. A new hash table, `atomic-chrome-frame-socket-incomplete-buffers-hash`, maps websocket sockets to buffers that accumulate payload fragments from incomplete websocket frames. This allows for efficient handling and concatenation of large and/or fragented messages. The `atomic-chrome-on-message` function has been updated to accumulate payload fragments in a dedicated buffer when frames are marked as incomplete or a previous incomplete frame exists for the socket. Upon receiving the final fragment, the full payload is reconstructed, decoded, and processed as a JSON object to either create or update associated Emacs buffers for editing. Additionally, the `atomic-chrome-on-close` function now removes the associated buffer from the hash table when a websocket socket is closed.
- Remove unrelated lexical-binding change - Avoid two-argument generate-new-buffer for older Emacs compatibility - Clean up incomplete WebSocket fragments on close - Add copyright notices
Remove an unused HTTP request binding so byte-compilation stays clean with lexical binding enabled.
Improves alpha22jp#34 and addresses alpha22jp#75.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In 6 commits, this PR resolves the following problems
Fragmented WebSocket messages are accepted for long text inputs (this addresses github.com/Need to handle long text inputs #77 and builds upon fix: support fragmented websocket frames, resolves #77 #79 by @KarimAziev by taking over one of his commits, and adding a second one on top with polish and cleanups)
HTTP handshake response is made RFC compliant, so that it works with strict HTTP parsers as well (this hasn’t been reported yet, but it’s a problem I stumbled upon myself while working on a GhostText client)
Edit buffers are no longer deleted after browser disconnects (this addresses Allow recovering from when remote editing session closed unexpectedly (e.g. by backups or saving a history) #75 and other related issues)
Orphaned edit buffers are re-used after browser reconnects automatically if they match perfectly. This further improves usability for Allow recovering from when remote editing session closed unexpectedly (e.g. by backups or saving a history) #75
@alpha22jp, feel free to take over the whole branch or cherry pick commits at will.
My intention is to continue cleaning up / fixing aspects of this extension, while keeping it simple and compliant with the GhostText protocol. (@KarimAziev’s vision for their fork seems to differ.)
I have a working prototype for syncing of point/region between Emacs and a browser.
But before adding this, I would like to fix another problem first: The current approach of sending the whole buffer (UTF-16 encoded) after each command is not workable for longer buffers, but it is also not necessary. I think that a better approach is to only send the buffer after a short moment of idleness (like 0.3 s).
@alpha22jp, are you interested in evolving this project in such a direction?
By the way, is the Atomic Chrome protocol still relevant? The GhostText “ecosystem” seems much bigger, covering many browsers and editors. If this is indeed the case, perhaps removing support for the Atomic Chrome protocol is a good idea? Since the original Chrome extensions is no longer around, there’s no way to verify that it still works anyway.
@fregante, what do you think?