emacs-devel
[Top][All Lists]
Advanced

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

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


From: Karl Fogel
Subject: Re: What is the most useful potential feature which Emacs lacks?
Date: Mon, 01 Jun 2020 22:57:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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



reply via email to

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