colorg: Some news!

colorg: Some news!

[François Pinard]

Hi to all my Org friends.

ColOrg is a project about real-time collaborative editing of Org files.
Here are some news about its progress, after a second push this
weekend.  It is not usable yet, but a few more steps have been taken.  A
few more ropes are needed to tie it up all together, but not much.

Some details follow.

The ColOrg client (on the Emacs side) acquired code for processing all
commands coming from a ColOrg server.  This includes per-collaborator
colorization of recently inserted text, and notification windows for
transient diagnostics.  To be usable, the client still misses the
association between local buffers and remote resource numbers, so
modifications go where they were meant.  The client should also ask the
server to build completions for existing users or resources.

The ColOrg server (on the Python side) requires more work.  The protocol
has been solidified a bit, but needs some love in the area of returned
values.  The problem of proper command rewriting is now better analyzed,
it looks simpler, but still has to be programmed.  I decided for a naive
approach, and by postponed optimization issues, all dark corners have
been lit, none remain so far that I know.

The Wiki also got some more text.  See https://github.com/pinard/ColOrg.

François

Re: colorg: Some news!

[Daimrod]

[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]

François Pinard <pinard@iro.umontreal.ca> writes:

> Hi to all my Org friends.

Hi,

> ColOrg is a project about real-time collaborative editing of Org files.
> Here are some news about its progress, after a second push this
> weekend.  It is not usable yet, but a few more steps have been taken.  A
> few more ropes are needed to tie it up all together, but not much.
>
> Some details follow.
>
> The ColOrg client (on the Emacs side) acquired code for processing all
> commands coming from a ColOrg server.  This includes per-collaborator
> colorization of recently inserted text, and notification windows for
> transient diagnostics.  To be usable, the client still misses the
> association between local buffers and remote resource numbers, so
> modifications go where they were meant.  The client should also ask the
> server to build completions for existing users or resources.
>
> The ColOrg server (on the Python side) requires more work.  The protocol
> has been solidified a bit, but needs some love in the area of returned
> values.  The problem of proper command rewriting is now better analyzed,
> it looks simpler, but still has to be programmed.  I decided for a naive
> approach, and by postponed optimization issues, all dark corners have
> been lit, none remain so far that I know.
>
> The Wiki also got some more text.  See https://github.com/pinard/ColOrg.

That's a really cool project! Do you plan to keep the server in Python?
Or do you think it would be possible to make this in Emacs Lisp only
with Elnode[1] for the server-side?

> François

[1] http://elnode.org/
-- 
Daimrod/Greg

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: colorg: Some news!

[François Pinard]

Daimrod <daimrod@gmail.com> writes:

> François Pinard <pinard@iro.umontreal.ca> writes:

>> ColOrg is a project about real-time collaborative editing of Org files.

> That's a really cool project!

Thanks.

> Do you plan to keep the server in Python?  Or do you think it would be
> possible to make this in Emacs Lisp only with Elnode[1] for the
> server-side?

Once we get a working solution, the protocol remains the contact point.
The server could be replaced using other languages, and new clients may
be written for other editors (given they are extensible enough).  My
goal is quickly getting something usable, so I selected the means that
looked fastest to me, and that's how Python got in the picture.

Is there any incentive for rewriting the server in Emacs Lisp?  For one,
even if rather bearable, Emacs Lisp is not my preferred programming
language.  Moreover, I consider a bit wrong having to rely on an editor
for tasks wholly unrelated to editing.  Other people are free to have
differing opinions, and do that rewrite, however. 

If I really had more time and less pressure, I would likely have
selected Node (JavaScript) to write the server instead of Python.  The
choice of JSON within the ColOrg communication protocol is a way, for
me, to leave that door opened.  One not so hidden dream is to bring Org
mode a bit closer to Web browsers, if there are ways to do so.

François

Re: colorg: Some news!

[Daimrod]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

François Pinard <pinard@iro.umontreal.ca> writes:

> Once we get a working solution, the protocol remains the contact point.
> The server could be replaced using other languages, and new clients may
> be written for other editors (given they are extensible enough).  My
> goal is quickly getting something usable, so I selected the means that
> looked fastest to me, and that's how Python got in the picture.
>
> Is there any incentive for rewriting the server in Emacs Lisp?  For one,
> even if rather bearable, Emacs Lisp is not my preferred programming
> language.  Moreover, I consider a bit wrong having to rely on an editor
> for tasks wholly unrelated to editing.  Other people are free to have
> differing opinions, and do that rewrite, however.

It's not unlreated to editing, it's for collaborative editing! :)
Anyway, I understand and respect your point of view.

Moreover, it's nice of you to report on the mailing list, it helps to
keep on eye.

> If I really had more time and less pressure, I would likely have
> selected Node (JavaScript) to write the server instead of Python.  The
> choice of JSON within the ColOrg communication protocol is a way, for
> me, to leave that door opened.  One not so hidden dream is to bring Org
> mode a bit closer to Web browsers, if there are ways to do so.

-- 
Daimrod/Greg

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]