* match the whole URL (sans trailing RET) * rename the get buffer function There are still a few warts to fix for save-progress to work properly. Namely at the moment after each C-x C-s this will cause additional re-sends of the data back. It still works, it's just ugly.
This should mean we re-use the existing buffer. It's not working for me at the moment and I'm not sure why.
This is part one of incremental save support. When we run C-x C-s (edit-server-save) we add headers to the response. The browser interprets those as an in-progress save and sends a fresh edit request back. At the moment this will create a brand new buffer. However once the edit-server is aware of the x-file parameter we should be able to just bring back the buffer we were editing.
…st plain bugs
Variable `edit-server-client' is not used as buffer local variable; move it's definition and don't set the `permanent-local' property.
Because defvar does not do anything when the variable is already initialized this allow users to provide their own keymap definition before loading the library. This way they don't have to undo any of the bindings they don't want and can concentrate on what they want.
As discussed in #37 a change in major mode after setting up can loose critical information. The normal major mode selection tries to mitigate against this by making sure those mode changes happen early on. If you change major-mode you'll still need to re-enable the edit-server-edit-mode to re-enable the key map that allows you to save your progress. Written-by: frobtech
Following a suggested patch from tarsius on github I've changed the behaviour of C-x C-s to save the current buffer into the kill-ring. This stops the C-x C-s operation from potentially loosing data in the client has disappeared on it.
(featurep 'aquamacs) was false for me on the experimental Emacs Mac port, causing edit-server to fail since make-frame-on-display seems to only work when you're under X11. I presume--but have not tested--that it would also fail for the official Emacs NS port. This new test on window-system should cover Aquamacs (tested), Emacs NS port (untested), and the Emacs Mac port (tested).
…attern -> major mode mappings
Makes it possible to change major mode using `edit-server-start-hook'.
Also clean up indentation which was horribly broken.
Raw tabs, displayed with indent 2. Added a section to the README explaining this, and added emacs & vim modelines to adhere to these settings.
This is accomplished by extending the communication protocol between the extension and the edit server. The edit server watches for changes to the temp file it creates. When a change is discovered, the edit server responds as normal, except that it adds two new headers, 'x-file' and 'x-open'. The value for 'x-file' is the name of the temporary file. The value for 'x-open' is set to 'true'. When the extension receives a response with 'x-open' set to 'true', it immediately makes another request to the edit server, adding a header, 'x-file', whose value is the same as the value in the preceding response. If the edit server gets a request with a valid 'x-file' header, it does not create a new temp file and spawn a new text editor instance. Instead, it watches the given file for changes. The process of the text editor is also monitored for termination. A terminated editor instance also triggers a response by the edit server. The Python edit server was the only one modified to handle the changes. It shouldn't be too difficult to update the Emacs-based edit server in the future.
Here is a small patch that I have found convenient - it allows the edit buffer to run in multibyte mode, so that it displays Unicode characters correctly in Emacs 23. (I often edit wiki pages in which others have inserted Unicode ellipses ... or left/right double quotes or em dash. With emacs multibyte enabled, this characters display correctly instead of as binary bytes.