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
[-- 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 --]
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
[-- 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 --]