Re: What is the most useful potential feature which Emacs lacks?

[Karl Fogel <kfogel@red-bean.com>]

On 31 May 2020, Richard Stallman wrote:
>It would be good to do that in a truly usable way.
>
>Emacs has had the feature of running multiple terminals at once for
>over 20 years, but there are bad problems in it.  To do it right, to
>has to have a thread for each terminal, and they have to be able to
>get in and out of the minibuffer separately.
>
>The other way to do this is to have separate Emacs processes that
>communicate with each other.  We would need to use modification hooks
>to take note of changes and transmit them to the other Emacses.
>
>Or perhaps one Emacs could be the "server", and the others act as clients,
>maintaining mirrors of the document.

Having separate Emacs processes that communicate with each other is best, I think.  

As Yuri Khan pointed out, experienced users have customized their Emacsen in distinctive ways, such that having to edit inside someone else's Emacs setup would be annoying.

Furthermore, there are privacy concerns with sharing an Emacs process.  I might want to collaborate with people on one buffer while having private things in other buffers.  It would be harder to reliably lock out access to those other buffers if the collaboration were happening in the same Emacs process.

Meanwhile, this concern...

>However, it then follows that each instance is going to have its own
>supporting tools. So, a power user who has an elaborate setup with LSP,
>flycheck, whatever, will not be able to share the advantages of his
>setup with a newbie.

...is not a big deal IMHO.  The primary goal of collaborative editing is the editing.  Anyway, if the expert can see the newbie editing in real time, the expert can suggest usage or configuration improvements, which the newbie can install or learn to do in her own Emacs.  That's how teaching normally happens anyway.  It's not important for the newbie to have access to the expert's personal customizations, because it's rare that the most useful lesson for a newbie involves duplicating some expert's idiosyncratic personal configuraton rather than learning some built-in thing already available in Emacs.  I mean, the newbie might be urged to set a few variables in her .emacs, or turn on some auto-mode associations or something, but that's normal customization (and the expert can share *her* .e
 macs via the same collaborative editing method, if she wants to do so).

I wish I had time to work on any of the leads at https://www.emacswiki.org/emacs/CollaborativeEditing.  That page lists a number of protocols and third-party free software libraries that could be used to make Emacs do inter-process collaborative editing.  The client side of Floobits plugin listed there is free software and seems promising (it is apparently working -- I have no direct experience of this, as I haven't used it because the server-side is proprietary.  I emailed them in early May to ask how much it would cost to get them to liberate the server side, and never received a response).  'git clone https://github.com/Floobits/floobits-emacs.git' will get you the client-side code, anyway.

Best regards,
-Karl