emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: "François Pinard" <pinard@iro.umontreal.ca>
To: emacs-orgmode@gnu.org
Subject: colorg: A few more thoughts
Date: Mon, 14 Jan 2013 02:09:34 -0500	[thread overview]
Message-ID: <86bocsp7f5.fsf@iro.umontreal.ca> (raw)

Hi, Orgers!

Here are some development news about ColOrg, which is a tool meant for
real-time collaborative edition for Org files.  I pushed a bit on the
project this weekend, but now, job duties might force me to delay
further work until next weekend.

I'm not done yet with the initial writing, it is all very broken, many
things need to be completed before usability.  Yet, a bit everything
starts to move, I even got the encouraging proof that some communication
occurs between Emacs and the ColOrg server. :-)

The tool is likely to be surprisingly small, both on the client side (in
Emacs Lisp) and the server side (in Python).  Usage is going to be
simple and crude at start.  We minimally do not need much: a toggle
command to put any Emacs buffer under ColOrg, and a few initial
questions (most of them may be spared), and that's it.  A newly created
resource gets transparently uploaded to the server for sharing, an
existing resource is downloaded when associated with an empty buffer.

Separate buffers may be associated to separate (or even the same)
resource, ColOrg is designed to multiplex and manage them.  Responsivity
(typing speed) might be reasonable enough.  I stuffed a few stub
routines with delays, to get an idea of how it would go.

I've given some good thought to the rewriting of the operational
transforms, this is the main missing part on the Python side.  I think I
have a dependable but inefficient solution in head, that would admit
hairy optimization.  The ColOrg Wiki would be a nice place to receive a
description of the problem and chosen solutions.  To be done later.

Many details remain to be addressed.  For example: how to interface with
Undo within Emacs?  It has incidence on the design of the protocol.  My
current choice is either to postpone and let every change be separate,
or collapse outside changes from many users, arriving at once, into a
single Undo step.

Have fun!  For now, sleep time!

François

                 reply	other threads:[~2013-01-14  7:12 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86bocsp7f5.fsf@iro.umontreal.ca \
    --to=pinard@iro.umontreal.ca \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).