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

[Ihor Radchenko]

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

As a bonus, it might be used as a basis for true concurrency.

Best,
Ihor


Karl Fogel <kfogel@red-bean.com> writes:

> 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* .emacs 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
>