emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question collaborative editing - Wikipedia reference


From: Qiantan Hong
Subject: Re: Question collaborative editing - Wikipedia reference
Date: Sun, 11 Oct 2020 17:49:44 +0000

I’m now experimenting those in my local copy.
(2) I’m able to synchronize overlays between Emacsen now,
and as a result, e.g. org-cycle now get synced between Emacsen.
There’s a few choice to make though:
- what’s a reasonable way to decide what overlays to sync?
   I’m currently deciding it based on the command that create the overlay
  (only overlay created during executing a customizable set of commands 
  are tracked). Is there better way?
- similar question to text property.

Also about (1), what do you think a a good format? I have
two design in mind:
a) share a full directory, probably making use of projectile (however
projectile is not in Emacs itself but I’d wish crdt.el get included in
the future)
b) share a “workspace” with flat namespace. Server can decide
which buffer to add to it. (And if they're UNIX fan they’ll write a function
to add a directory). I like flat namespace, but to make it useful
it’d better has some tagging mechanism, and I feel like there’s
too many wheels to reinvent. Another problem is how to allow
clients creating new file (maybe don’t?)

> On Oct 9, 2020, at 9:33 AM, Joe Corneli <holtzermann17@gmail.com> wrote:
> 
> Hi Qiantan and all,
> 
> As a basic solution for pairing — before your nice software appeared recently 
> — we were using lockstep.el.
> 
> One cool feature of lockstep is that you share the whole Emacs session.  This 
> is useful for workflows that involve
> lots of files and buffers (e.g., consider using it alongside Projectile, or 
> Org Roam).  Access to the shell or Helm is
> transparent, for example.
> 
> One downside I noticed recently is that having multiple emacsclients working 
> on the same set of files seems to
> interfere with Org Roam, with regard to syncing the database (... still 
> investigating that). This is a problem that
> would not come up with crdt.el b/c it manages syncing at the buffer level, 
> not the file level!
> 
> All this leads to some possible feature requests for crdt.
> 
> (1) Would it make sense for a future version of crdt.el to also manage a list 
> of files (like Projectile or Gobby?).  
> (2) Would it make sense for a future version of crdt.el to sync not just 
> buffers... but also commands and windows (like lockstep?)
> 
> I realise it's still early days, so I don't want to distract w/ these 
> questions.
> 
> Joe

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]