Consider different fading systems

This commit is contained in:
nik gaffney 2020-12-19 15:58:06 +01:00
parent bfb8b4bfac
commit 36956db9fa

View file

@ -3,7 +3,7 @@
** Etherpad & collaborative editing
[[https://melpa.org/#/etherpad][file:https://melpa.org/packages/etherpad-badge.svg]]
“Etherpad is a highly customizable Open Source online editor providing collaborative editing in really real-time. Etherpad allows you to edit documents collaboratively in real-time, much like a live multi-player editor that runs in your browser. Write articles, press releases, to-do lists, etc. together with your friends, fellow students or colleagues, all working on the same document at the same time.” https://etherpad.org/
The Etherpad API provides a way to add, delete and edit pads. It also enables access to changesets and author information required for displaying changes between revisions but doesnt appear to provide a way to send changesets (c.f. using the API call [[https://etherpad.org/doc/v1.8.5/#index_getrevisionchangeset_padid_rev][getRevisionChangeset]] and the [[https://etherpad.org/doc/v1.8.5/#index_changeset_library][changeset]] format)
@ -14,7 +14,11 @@ The Etherpad API provides a way to add, delete and edit pads. It also enables ac
This package enables read-write access to pads with emacs, but is not (yet) suitable for general use as an Etherpad client (compare [[https://github.com/JohnMcLear/etherpad-cli-client][etherpad-cli-client]])
It provides a quick&dirty way to edit pads on an Etherpad server from emacs as if they were filelike (It uses the Etherpad API rather than the socket.io interface). It doesnt (yet) provide a real-time interface for collaborative editing and will overwrite author information. It tries to warn you if the pad on the server has been changed if editing asynchronously (c.f file changed on disk) There is a simplistic autosync mode where every change to the local buffer is written to the server, which is slow (there is a complete pad update for every character) inefficient, and collision prone (since it relies on revision numbers to sync). There is no diff interface or way to resolve divergent changes.
It provides a quick&dirty way to edit pads on an Etherpad server from emacs as if they were filelike (It uses the Etherpad API rather than the socket.io interface). It doesnt provide an efficient real-time interface for collaborative editing and will overwrite author information. It tries to warn you if the pad on the server has been changed if editing asynchronously (c.f file changed on disk) There is a simplistic autosync mode where every change to the local buffer is written to the server, which is slow (there is a complete pad update for every character) inefficient, and collision prone (since it relies on revision numbers to sync). There is no diff interface or way to resolve divergent changes.
** realtime collaborative editing
There is an experimental branch =ethersync= which enables realtime editing using the socket.io interface to an etherpad server. Its currently unstable and incomplete, but works as a proof-of-concept and basis for further development.
** install & configure
@ -38,11 +42,7 @@ To update a pad with changes from the current buffer use ~etherpad-save~ (which
Automatic sync between an emacs buffer and the etherpad server can be enabled by setting ~etherpad-autosync~ or interactively with ~etherpad-autosync-enable~ or ~etherpad-autosync-disable~ (and/or toggled with ~etherpad-autosync-toggle~)
** Further
** Further
- [[https://etherpad.org/doc/v1.8.4/#index_api_methods][Etherpad HTTP API reference]]
- [[https://raw.githubusercontent.com/ether/etherpad-lite/master/doc/easysync/easysync-full-description.pdf][Etherpad and EasySync Technical Manual]] (pdf)
- [[https://lists.gnu.org/archive/html/emacs-devel/2020-10/msg00238.html][Re: Question collaborative editing]] (CRDT based collaborative editing in emacs)