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

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

[Van Ly]

> > Why use the name shr for an HTML renderer?
>
> As the file's header says, "shr" stands for "Simple HTML Renderer".

Does Emacs do video streams?  Can it play well with VLC and multicast 
streams?  Is that the most useful potential feature which Emacs 
lacks?  From what people say on r/spacex, proprietary systems don't 
play well collectively as user-friendly 'eye witness' solution.

Remember-notes-mode could be used to annotate video streams for 
lawyering professional essential workers.  For example, to note when 
people slip on banana peel which must be picked up within a well 
defined time margin in public space maintained by robot cleaning 
machine.

 	VanL

--
... dragons do not see stones, fish do not see water.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Does Emacs do video streams?

What would Emacs do, with video streams?

				  Can it play well with VLC and multicast 
  > streams?

How would you like them to work together?

What free programs would people use to view multicast streams?
Firefox (or rather IceCat)?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Van Ly]

> What would Emacs do, with video streams?

If you look at history [1], the way creative spirit Jean Wright
appreciates Singer's line of sewing machine [2].  Advanced community
users/developers on Emacs at meta/interface of health/safety problem
solving would work video streams to inform decision making by
re-stitching and narrating them with automation intelligence for
director [3] before neuralink implant technology matures and arrives. 
:-)


> 				  Can it play well with VLC and multicast
>  > streams?
>
> How would you like them to work together?
>
> What free programs would people use to view multicast streams?
> Firefox (or rather IceCat)?
>

Anyway.  FSF associates have the benefit of videoconferencing.  After 
observing how people use "zoom" to videochat, can Emacs, VLC, 
multicast streams, Blender's kind of UI combine for more ways to 
work?  And, see how "1000 eyes" works, which Cisco is reported to 
have acquired.

Just sayin some ideas.

[1]
  . design principles behind smalltalk
  . https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html

[2]
  . Jean Wright
  . neaf talks
  . sew sisters to the stars
  . how sewing transformed the world of flight
  . https://tx0.org/33

[3]
  . Aviation Week's Check 6 Podcast
  . SpaceX COO on Prospects for Starship launcher

 	VanL

--
... dragons do not see stones, fish do not see water.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Anyway.  FSF associates have the benefit of videoconferencing.  After 
  > observing how people use "zoom" to videochat, can Emacs, VLC, 
  > multicast streams, Blender's kind of UI combine for more ways to 
  > work?

I don't have any idea what that could concretely mean.  I suppose
I have nothing against it, but it seems unimportant.  I hope this
won't draw effort and attention away from enabling Emacs to do
what we now use LibreOffice for.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Van Ly]

>  > Anyway.  FSF associates have the benefit of videoconferencing.  After
>  > observing how people use "zoom" to videochat, can Emacs, VLC,
>  > multicast streams, Blender's kind of UI combine for more ways to
>  > work?
>
> I don't have any idea what that could concretely mean.  I suppose
> I have nothing against it, but it seems unimportant.  I hope this
> won't draw effort and attention away from enabling Emacs to do
> what we now use LibreOffice for.

well it was an ambitious bluesky shot in the dark second guessing 
where the "puck" will be at, assuming people will work more and more 
with video streams and automation intelligence, and for Emacs to gain 
superpower capability, you hear people say the open plan office may 
not come back beyond this globally viral pandemic

for Emacs to catchup to some of LibreOffice's UI capabilities is
concretely well-defined for where the "puck" was

 	VanL

--
... dragons do not see stones, fish do not see water.

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

[excalamus--- via Emacs development discussions.]

May 31, 2020, 06:01 by van.ly+2@sdf.org:

>> > Anyway.  FSF associates have the benefit of videoconferencing.  After
>>  > observing how people use "zoom" to videochat, can Emacs, VLC,
>>  > multicast streams, Blender's kind of UI combine for more ways to
>>  > work?
>>
>
> well it was an ambitious bluesky shot in the dark second guessing where the "puck" will be at, assuming people will work more and more with video streams and automation intelligence, and for Emacs to gain superpower capability, you hear people say the open plan office may not come back beyond this globally viral pandemic
>  
>
What about collaborative editing?  That is, multiple people simultaneously editing a document over the internet.

Does anyone have experience with the projects mentioned on EmacsWiki for this topic? https://www.emacswiki.org/emacs/CollaborativeEditing 

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What about collaborative editing?  That is, multiple people
  > simultaneously editing a document over the internet.

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.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Yuri Khan]

On Mon, 1 Jun 2020 at 10:54, Richard Stallman <rms@gnu.org> wrote:
>   > What about collaborative editing?  That is, multiple people
>   > simultaneously editing a document over the internet.
>
> 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.

More importantly, a single Emacs will force identical configuration on
all collaborating users. And, instead of collaborating, they will
curse and bicker over every small convenience each of them has become
used to.

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

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.


Also, most collaboration editing tools in use today let users work on
a single document but not necessarily on multiple files in a project.
E.g. in a pair programming scenario, it would be nice if one could say
“now let’s go to that other file” and the other would automatically
follow. Preferably in a way that avoids the usual post-teleportation
feeling of disorientation.

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

[Bastien]

excalamus--- via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> What about collaborative editing?

FWIW, this is something Org users have been wanting for years.

Especially researchers using Org for publishing drafts for their
papers: they are used to be able to collaborate on LaTeX documents
and providing real-time collaboration over Org buffers would be a
huge plus.

-- 
 Bastien

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

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Date: Mon, 01 Jun 2020 11:11:41 +0200
> Cc: excalamus@tutanota.com, Van Ly <van.ly+2020@sdf.org>,
>  Richard Stallman <rms@gnu.org>
> 
> > What about collaborative editing?
> 
> FWIW, this is something Org users have been wanting for years.

What is missing in Emacs to make this possible?

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

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Bastien <bzg@gnu.org>
>> Date: Mon, 01 Jun 2020 11:11:41 +0200
>> Cc: excalamus@tutanota.com, Van Ly <van.ly+2020@sdf.org>,
>>  Richard Stallman <rms@gnu.org>
>> 
>> > What about collaborative editing?
>> 
>> FWIW, this is something Org users have been wanting for years.
>
> What is missing in Emacs to make this possible?

I don't know for sure.

In the past, I was able to collaborate with a friend using an Emacs
extension called "Rudel", which lets two distant buffers communicate
with each other over the Gobby protocol.

https://www.emacswiki.org/emacs/Rudel indicates that the reference
implementation for the Gobby protocol is broken.  I have not tried.

So perhaps the required work is not on the Emacs side, but on that 
of the protocol and its implementation.

-- 
 Bastien

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

[Jean-Christophe Helary]

> On Jun 2, 2020, at 8:32, Bastien <bzg@gnu.org> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Bastien <bzg@gnu.org>
>>> Date: Mon, 01 Jun 2020 11:11:41 +0200
>>> Cc: excalamus@tutanota.com, Van Ly <van.ly+2020@sdf.org>,
>>> Richard Stallman <rms@gnu.org>
>>> 
>>>> What about collaborative editing?
>>> 
>>> FWIW, this is something Org users have been wanting for years.
>> 
>> What is missing in Emacs to make this possible?
> 
> I don't know for sure.
> 
> In the past, I was able to collaborate with a friend using an Emacs
> extension called "Rudel", which lets two distant buffers communicate
> with each other over the Gobby protocol.
> 
> https://www.emacswiki.org/emacs/Rudel indicates that the reference
> implementation for the Gobby protocol is broken.  I have not tried.
> 
> So perhaps the required work is not on the Emacs side, but on that 
> of the protocol and its implementation.

It looks like SubEthaEdit, the text editor that first provided solid collaborative editing features on macos is now released under the MIT license and its communication protocol is documented on emacswiki:

https://www.emacswiki.org/emacs/SubEthaEditProtocol



-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > More importantly, a single Emacs will force identical configuration on
  > all collaborating users. And, instead of collaborating, they will
  > curse and bicker over every small convenience each of them has become
  > used to.

If they use one single Emacs, that will happen.

  > > Or perhaps one Emacs could be the "server", and the others act as clients,
  > > maintaining mirrors of the document.

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

If each has per own Emacs, that will happen.

To avoid both of those problems, we need some other way,
but what could it be?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Karl Fogel]

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

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
>

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

[Stefan Monnier]

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

It's the only option, as far as I'm concerned.  Sharing an Emacs process
with some other user simply doesn't work at all (as anyone who has tried
it will know, 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.

Back when I tried it, those issues didn't even have time to show up.
Instead we quickly bumped into issues with the "single keyboard mode",
and other similar "modal" problems.  Or the unexpected sharing of the
kill-ring, ...
It's just hopeless.

> Furthermore, there are privacy concerns with sharing an Emacs process.

Indeed, the first thing I did when someone tried `make-frame-on-display`
to display their Emacs session on my display (back when we tried out
this new feature), was `M-x shell`.


        Stefan

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

[Eli Zaretskii]

> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> Date: Tue, 2 Jun 2020 08:50:33 +0900
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  excalamus@tutanota.com,
>  van.ly+2020@sdf.org,
>  Richard Stallman <rms@gnu.org>,
>  emacs-devel@gnu.org
> 
> >> What is missing in Emacs to make this possible?
> > 
> > I don't know for sure.
> > 
> > In the past, I was able to collaborate with a friend using an Emacs
> > extension called "Rudel", which lets two distant buffers communicate
> > with each other over the Gobby protocol.
> > 
> > https://www.emacswiki.org/emacs/Rudel indicates that the reference
> > implementation for the Gobby protocol is broken.  I have not tried.
> > 
> > So perhaps the required work is not on the Emacs side, but on that 
> > of the protocol and its implementation.
> 
> It looks like SubEthaEdit, the text editor that first provided solid collaborative editing features on macos is now released under the MIT license and its communication protocol is documented on emacswiki:
> 
> https://www.emacswiki.org/emacs/SubEthaEditProtocol

What I think is missing is not the description of a specific protocol,
but a higher-level spec of basic capabilities needed for the
collaborative editing support in Emacs.  Is this available anywhere?
If not, could someone please write it up?

For example, one thing that strikes me is why "collaboration" via a
dVCS is not a good solution, or at least the basis of a solution?  Am
I missing something?

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Sat, Jun 06, 2020 at 12:42:07PM +0300, Eli Zaretskii wrote:

[...]

> What I think is missing is not the description of a specific protocol,
> but a higher-level spec of basic capabilities needed for the
> collaborative editing support in Emacs.  Is this available anywhere?
> If not, could someone please write it up?

That would indeed be a Good Thing.

> For example, one thing that strikes me is why "collaboration" via a
> dVCS is not a good solution, or at least the basis of a solution?  Am
> I missing something?

DISCLAIMER: I haven't much experience with collaborative editing.

That said, as far as I understand the collaborative editing folks,
the difference to a dVCS (which I read as "distributed version
control system" à la git) is the "live" experience: you see other
people's cursors (points?) running over the text making changes,
while you change the text, too. Ideally supported by a side channel,
e.g. audio.

Think several people doodling simultaneously over a shared blackboard.

There was a thread a while ago in -help or -devel explaining why
several emacs clients connected to a common server didn't quite
fill that bill: I could only partially understand what the limitations
were. I think I'll have to try it in practice to get a grip on
that.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Thibaut Verron]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

>
> What I think is missing is not the description of a specific protocol,
> but a higher-level spec of basic capabilities needed for the
> collaborative editing support in Emacs.  Is this available anywhere?
> If not, could someone please write it up?
>
> For example, one thing that strikes me is why "collaboration" via a
> dVCS is not a good solution, or at least the basis of a solution?  Am
> I missing something?
>

Collaborative editors usually show modifications done by other users in
real time. I don't know how major conflicts are resolved.

How would you emulate this with a VCS? Commit-push-pull with various
--force flags, on a timer run every second?

Thibaut

[-- Attachment #2: Type: text/html, Size: 974 bytes --]

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

[Eli Zaretskii]

> Date: Sat, 6 Jun 2020 11:58:51 +0200
> From: <tomas@tuxteam.de>
> 
> That said, as far as I understand the collaborative editing folks,
> the difference to a dVCS (which I read as "distributed version
> control system" à la git) is the "live" experience: you see other
> people's cursors (points?) running over the text making changes,
> while you change the text, too. Ideally supported by a side channel,
> e.g. audio.
> 
> Think several people doodling simultaneously over a shared blackboard.

Someone will have to explain why this is useful.  Sitting and looking
at other people's typing something, then erasing and retyping, one
character at a time, sounds like a huge waste of time to me.  I could
use that same time to modify a different section of the same document,
or suggest a solution for a problem in parallel to several others
suggesting their solutions for the same problem (which would need some
processing on top of VC conflict resolution).  I'm probably missing
something.

> There was a thread a while ago in -help or -devel explaining why
> several emacs clients connected to a common server didn't quite
> fill that bill: I could only partially understand what the limitations
> were. I think I'll have to try it in practice to get a grip on
> that.

I don't think using emacsclient in its current implementation and the
infrastructure it uses will help us make any progress in this area.
The current keyboard "multiplexing" in Emacs doesn't really support
any concurrent input in any useful sense of that word.

That's why I think we need to start from the basics, and define the
features we'd need.  In general, since we are talking about several
different individuals, the concept of having a single Emacs "server"
sounds a non-starter to me.  We should talk about several separate
Emacs sessions communicating between them in some way.

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

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Sat, 6 Jun 2020 11:59:47 +0200
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>, bzg@gnu.org, 
> 	excalamus@tutanota.com, van.ly+2020@sdf.org, Richard Stallman <rms@gnu.org>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> Collaborative editors usually show modifications done by other users in real time. I don't know how major
> conflicts are resolved.
> 
> How would you emulate this with a VCS? Commit-push-pull with various --force flags, on a timer run every
> second? 

That could be a start, yes.

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]

On Sat, Jun 06, 2020 at 11:59:47AM +0200, Thibaut Verron wrote:
> >
> > What I think is missing is not the description of a specific protocol,
> > but a higher-level spec of basic capabilities needed for the
> > collaborative editing support in Emacs.  Is this available anywhere?
> > If not, could someone please write it up?
> >
> > For example, one thing that strikes me is why "collaboration" via a
> > dVCS is not a good solution, or at least the basis of a solution?  Am
> > I missing something?
> >
> 
> Collaborative editors usually show modifications done by other users in
> real time. I don't know how major conflicts are resolved.

My hunch is that conflicts aren't as heavy "in real time", because users
can react to them in a more fine-grained fashion. But there's a whole
body of theory dedicated to that. I'd start here [1].

Actually the problems are akin to (but possibly not as hard as)
networked gaming, where you have several clients sharing a common
model: you'll have to cheat a bit if you don't want to wait until
you know the exact model's state, because that'd mean a full network
round trip. Sometimes you can afford that, sometimes not. Balancing
out that and fixing things to hide your cheating after the fact
in a way that the user can cope with the fallout is, I think, the
"interesting" part.

> How would you emulate this with a VCS? Commit-push-pull with various
> --force flags, on a timer run every second?

I think network latency would kill you (or rather, your users might ;-)

Cheers

[1] https://en.wikipedia.org/wiki/Collaborative_real-time_editor#Technical_challenges
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

On Sat, Jun 06, 2020 at 01:11:36PM +0300, Eli Zaretskii wrote:

Hi,

Sorry, just a short answer now -- pressed at the moment. Will come
back today later.

> > Date: Sat, 6 Jun 2020 11:58:51 +0200
> > From: <tomas@tuxteam.de>
> > 
> > That said, as far as I understand the collaborative editing folks,
[...]
> > Think several people doodling simultaneously over a shared blackboard.
> 
> Someone will have to explain why this is useful.

Yup, that's the problem.

This isn't the way I enjoy doing things either (so I'm not the
most qualified to answer that question, but I feel your pain),
but people *love* pushing around an Etherpad [1] URL and just
collaboratively hack away at something.

Perhaps because it doesn't force them to change the way they
interact too much. It's a bit like sitting around a sand pit
and putting sticks and stones and drawing doodles around them.

You don't take turns at this either, and if you step onto some
other's doodle, a side channel (she pushes you out of the sand
pit or yells at you ;-) is used.

Luckily Etherpad is free software

Cheers

[1] https://en.wikipedia.org/wiki/Etherpad
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jean-Christophe Helary]

> On Jun 6, 2020, at 18:42, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
>> Date: Tue, 2 Jun 2020 08:50:33 +0900
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> excalamus@tutanota.com,
>> van.ly+2020@sdf.org,
>> Richard Stallman <rms@gnu.org>,
>> emacs-devel@gnu.org
>> 
>>>> What is missing in Emacs to make this possible?
>>> 
>>> I don't know for sure.
>>> 
>>> In the past, I was able to collaborate with a friend using an Emacs
>>> extension called "Rudel", which lets two distant buffers communicate
>>> with each other over the Gobby protocol.
>>> 
>>> https://www.emacswiki.org/emacs/Rudel indicates that the reference
>>> implementation for the Gobby protocol is broken.  I have not tried.
>>> 
>>> So perhaps the required work is not on the Emacs side, but on that 
>>> of the protocol and its implementation.
>> 
>> It looks like SubEthaEdit, the text editor that first provided solid collaborative editing features on macos is now released under the MIT license and its communication protocol is documented on emacswiki:
>> 
>> https://www.emacswiki.org/emacs/SubEthaEditProtocol
> 
> What I think is missing is not the description of a specific protocol,
> but a higher-level spec of basic capabilities needed for the
> collaborative editing support in Emacs.  Is this available anywhere?
> If not, could someone please write it up?
> 
> For example, one thing that strikes me is why "collaboration" via a
> dVCS is not a good solution, or at least the basis of a solution?  Am
> I missing something?

I am totally unable to talk about the technical aspect, but in fact, the software that I mention in the emacs for translators thread on help-gnu-emacs (OmegaT) actually uses Git or svn as the "engine" for collaboration.

The files that are shared on the git server are manipulated by all the collaborators who regularly commit their modifications and when there is a conflict, the collaborators are asked to resolve it. One collaborator commits are regularly reflected to the other collaborators so that the work proceeds with only a small lag between updates.

But I think what collaborative editing users have in mind is closer to an etherpad than to what OmegaT does.


-- 
Jean-Christophe Helary @brandelune
http://mac4translators.blogspot.com

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

[Stefan Monnier]

> Someone will have to explain why this is useful.

Or maybe you can just accept it as something other people might enjoy
even tho you don't ;-)

> Sitting and looking at other people's typing something, then erasing
> and retyping, one character at a time, sounds like a huge waste of
> time to me.

Yet, as a teacher, I very often am exactly in that situation, where
either the student or I write slowly on the board to try and express
visually what we want to say.  Now, "plain text" like we have in Emacs
buffers isn't quite the same, but now that I have to teach via
video-conferences, I regularly share my Emacs frame over Jitsi and they
watch me slowly type code (and erase and retype) while explaining out
loud what it is I'm doing.

It may sound slow and painful, but the low speed is actually useful to
give them time to understand, and the fact that it's done "live" makes
the feedback loop much more effective when it takes several back&forth
between the students and I before we come to an understanding.

And of course, all that applies as well sometimes when discussing
research ideas among peers.

> I could use that same time to modify a different section of the same
> document, or suggest a solution for a problem in parallel to several
> others suggesting their solutions for the same problem (which would
> need some processing on top of VC conflict resolution).  I'm probably
> missing something.

Yes, we *also* do that (using Git, typically to share a TeX document or
source code) and that's where the meat of work takes place, but at times
the fast back&forth of "live editing" (or just talking) is very helpful.


        Stefan

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

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Someone will have to explain why this is useful.
>
> Or maybe you can just accept it as something other people might enjoy
> even tho you don't ;-)
>
>> Sitting and looking at other people's typing something, then erasing
>> and retyping, one character at a time, sounds like a huge waste of
>> time to me.
>
> Yet, as a teacher, I very often am exactly in that situation, where
> either the student or I write slowly on the board to try and express
> visually what we want to say.  Now, "plain text" like we have in Emacs
> buffers isn't quite the same, but now that I have to teach via
> video-conferences, I regularly share my Emacs frame over Jitsi and they
> watch me slowly type code (and erase and retype) while explaining out
> loud what it is I'm doing.
>
> It may sound slow and painful, but the low speed is actually useful to
> give them time to understand, and the fact that it's done "live" makes
> the feedback loop much more effective when it takes several back&forth
> between the students and I before we come to an understanding.
>
> And of course, all that applies as well sometimes when discussing
> research ideas among peers.
>
>> I could use that same time to modify a different section of the same
>> document, or suggest a solution for a problem in parallel to several
>> others suggesting their solutions for the same problem (which would
>> need some processing on top of VC conflict resolution).  I'm probably
>> missing something.
>
> Yes, we *also* do that (using Git, typically to share a TeX document or
> source code) and that's where the meat of work takes place, but at times
> the fast back&forth of "live editing" (or just talking) is very helpful.
>
>
>         Stefan

Can this give some inspiration to you guys?

http://impromptu.moso.com.au/

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

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

On Sat, Jun 06, 2020 at 01:11:36PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 6 Jun 2020 11:58:51 +0200
> > From: <tomas@tuxteam.de>

[...]

> > Think several people doodling simultaneously over a shared blackboard.
> 
> Someone will have to explain why this is useful [...]

I think Stefan offered a better explanation than I did.
My attempt had the flaw (not the only one, mind you) that
I mixed in personal preferences, so it possibly turned
out more sarcastic than intended.

> > There was a thread a while ago in -help or -devel explaining why
> > several emacs clients connected to a common server didn't quite
> > fill that bill [...]

> I don't think using emacsclient in its current implementation and the
> infrastructure it uses will help us make any progress in this area.
> The current keyboard "multiplexing" in Emacs doesn't really support
> any concurrent input in any useful sense of that word.

I wasn't seriously proposing to use that as a replacement for
collab editing: my aim was rather to understand the issues and
perhaps learn a bit more about collaborative editing itself.

> That's why I think we need to start from the basics, and define the
> features we'd need [...]

Actually, having had the time to do some homework, I found:

  - Rudel: a collaborative editing environment for Emacs.
    It's even on Elpa and has a page on Emacswiki [1]
    It seems to be based on the Gobby protocol

  - there's someone (github [2], alas) implementing the Etherpad
    protocol for Emacs

Embarrasment of riches, it seems ;-)

Cheers

[1] https://www.emacswiki.org/emacs/Rudel
[2] https://github.com/holtzermann17/linepad

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Stefan Monnier]

>   - Rudel: a collaborative editing environment for Emacs.
>     It's even on Elpa and has a page on Emacswiki [1]
>     It seems to be based on the Gobby protocol

Yes, it's in GNU ELPA, but it's been on life-support for several years.
It would benefit quite significantly from someone digging into it and
making it use libgnutls rather than gnutls-cli.

Streamlining the setup would also be quite useful.


        Stefan

collaborative editing

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The Subject used to be

   What is the most useful potential feature which Emacs lacks?

I've changed it to try to separate this question from others.


I have not done shared editing over the network, but lots of people do
it -- in Etherpad and in Google Docs -- and it is clear that they
find it useful.  How about if we take for granted it is useful
and skip the debate about that point?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: collaborative editing

[tomas]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Sat, Jun 06, 2020 at 11:36:35PM -0400, Richard Stallman wrote:

[...]

> I've changed it to try to separate this question from others.

Good idea, thanks!

> I have not done shared editing over the network, but lots of people do
> it -- in Etherpad and in Google Docs -- and it is clear that they
> find it useful.  How about if we take for granted it is useful
> and skip the debate about that point?

I didn't take the debate as being about /whether/ it is useful, but
rather about /in which way/ it may be useful: from that angle, I think
the debate itself is useful, as it may help to guide us shaping this
feature.

Myself, I'll give Rudel a try and look into the TLS point Stefan made,
as a result of this debate.

Cheers
-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Collaborative editing.

[Perry E. Metzger]

Howdy!

For years now, pair programming has been of interest to loads of 
programmers, and I've done quite a bit of it myself. For a long time, 
I'd do this with Emacs by running Screen on a machine and having myself 
and whoever I was pairing with both connect up to the same Emacs 
(running in a terminal) that way.

However, it's increasingly difficult to get the full benefits of Emacs 
in ordinary terminals; there are too many things a gui can do that a 
terminal can't.

I've also discovered that many other editors (such as VSCode and Atom) 
seem to now have dedicated modes for doing collaborative editing, and 
apparently do it quite well. Indeed, many people I asked directed me to 
VSCode for this when I asked around about methods to do it for Emacs. 
(SubEthaEdit, which is now free software, also allows such things, but 
it is a much more limited editor.)

Especially with more and more working programmers doing their jobs from 
home but wanting to work with colleagues far away, it would seem like 
having truly good support for collaborative editing baked in to Emacs by 
some means would be a good idea.

I know there have been some experiments with collaborative editing modes 
in the past that were written purely in Elisp but none seem to be 
currently maintained and I'm not sure if any were actually very good to 
begin with.

Anyone have thoughts on how one could get Emacs to be a really top 
flight collaborative editing environment, especially for programmers? 
Just to be clear, one would want both programmers to be in distant 
locations, but to get essentially the same view of the file being 
edited, the same view of any UI elements like popups, and to be able to 
control the keyboard and mouse more or less simultaneously. Presumably 
one of the two Emacsen would be the primary one and the other one just a 
remote display, though other architectures are possible.

Obvious design alternatives are dealing with some sort of quite literal 
display sharing mechanism in which a VNC-like protocol is used, a 
slightly more "semantically" based display sharing protocol in which a 
remote display is sent a series of high level commands about updates, 
some sort of more literal collaborative editing in which diffs to text 
get sent back and forth (but this would not make it easy for both 
programmers to see the same view of the text, including popups etc.), 
and there are probably other places in the design space.

Perry

Re: Collaborative editing.

[Tim Cross]

"Perry E. Metzger" <perry@piermont.com> writes:

> Howdy!
>
> For years now, pair programming has been of interest to loads of programmers,
> and I've done quite a bit of it myself. For a long time, I'd do this with Emacs
> by running Screen on a machine and having myself and whoever I was pairing with
> both connect up to the same Emacs (running in a terminal) that way.
>
> However, it's increasingly difficult to get the full benefits of Emacs in
> ordinary terminals; there are too many things a gui can do that a terminal
> can't.
>
> I've also discovered that many other editors (such as VSCode and Atom) seem to
> now have dedicated modes for doing collaborative editing, and apparently do it
> quite well. Indeed, many people I asked directed me to VSCode for this when I
> asked around about methods to do it for Emacs. (SubEthaEdit, which is now free
> software, also allows such things, but it is a much more limited editor.)
>
> Especially with more and more working programmers doing their jobs from home but
> wanting to work with colleagues far away, it would seem like having truly good
> support for collaborative editing baked in to Emacs by some means would be a
> good idea.
>
> I know there have been some experiments with collaborative editing modes in the
> past that were written purely in Elisp but none seem to be currently maintained
> and I'm not sure if any were actually very good to begin with.
>
> Anyone have thoughts on how one could get Emacs to be a really top flight
> collaborative editing environment, especially for programmers? Just to be clear,
> one would want both programmers to be in distant locations, but to get
> essentially the same view of the file being edited, the same view of any UI
> elements like popups, and to be able to control the keyboard and mouse more or
> less simultaneously. Presumably one of the two Emacsen would be the primary one
> and the other one just a remote display, though other architectures are
> possible.
>
> Obvious design alternatives are dealing with some sort of quite literal display
> sharing mechanism in which a VNC-like protocol is used, a slightly more
> "semantically" based display sharing protocol in which a remote display is sent
> a series of high level commands about updates, some sort of more literal
> collaborative editing in which diffs to text get sent back and forth (but this
> would not make it easy for both programmers to see the same view of the text,
> including popups etc.), and there are probably other places in the design space.
>

Just as another data point, I've done this similar to your screen
example (except we used tmux). We also used spacemacs, which has it's
'hybrid' mode, which supports both traditional Emacs key bindings and
Evil, which was handy because the other user was not an Emacs user, but
they were familiar with VI. It worked OK, but was definitely not as
'polished' as VSCode's remote collaboration/editing mode. The VSCode
model does work very nicely.

A remote/pair programming mode for Emacs would be nice. What would be
very nice is if it was possible for Emacs to leverage off the same
protocol as VSCode. It would be very nice if you could pair program with
someone who is using VSCode while you are using Emacs (and vice versa).
One of the limitations with the screen/tmux model is the expectation
both parties are Emacs users. It is rare I find many other Emacs users
on teams I've worked with. In the last few years, VSCode and Atom seem
to be far more common. 

Re: Collaborative editing.

[Eli Zaretskii]

> Date: Thu, 12 Aug 2021 19:43:25 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> 
> Anyone have thoughts on how one could get Emacs to be a really top 
> flight collaborative editing environment, especially for programmers? 

I suggest to search the archives of this list for "collaborative",
there were a few large discussions last year.  One of the latest
attempts to add these capabilities to Emacs is here:

  https://code.librehq.com/qhong/crdt.el/

Re: Collaborative editing.

[Jean Louis]

* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
> I know there have been some experiments with collaborative editing modes in
> the past that were written purely in Elisp but none seem to be currently
> maintained and I'm not sure if any were actually very good to begin with.

CRDT works just fine and is well maintained, you can contact author
Qiantan Hong <qhong@mit.edu> at any time you wish.

Do:

$ git clone https://code.librehq.com/qhong/crdt.el.git

Let me know if you need any help or assistance to start with
collaborative editing.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Collaborative editing.

[Ergus]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?

On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>> I know there have been some experiments with collaborative editing modes in
>> the past that were written purely in Elisp but none seem to be currently
>> maintained and I'm not sure if any were actually very good to begin with.
>
>CRDT works just fine and is well maintained, you can contact author
>Qiantan Hong <qhong@mit.edu> at any time you wish.
>
>Do:
>
>$ git clone https://code.librehq.com/qhong/crdt.el.git
>
>Let me know if you need any help or assistance to start with
>collaborative editing.
>
>
>-- 
>Jean
>
>Take action in Free Software Foundation campaigns:
>https://www.fsf.org/campaigns
>
>In support of Richard M. Stallman
>https://stallmansupport.org/
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1689 bytes --]

Re: Collaborative editing.

[Philip Kaludercic]

Ergus <spacibba@aol.com> writes:

> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?

The package still seems to be on version 0.0.0, and the HACKING[0] file
indicates that a few intended items are not implemented yet. It might
make sense to push for a preliminary version to be published as to
provide a basic collaborative environment available on ELPA (or NonGNU
ELPA if necessary), and then later work on full-compatibility.

[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org

> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>> I know there have been some experiments with collaborative editing modes in
>>> the past that were written purely in Elisp but none seem to be currently
>>> maintained and I'm not sure if any were actually very good to begin with.
>>
>>CRDT works just fine and is well maintained, you can contact author
>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>
>>Do:
>>
>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>
>>Let me know if you need any help or assistance to start with
>>collaborative editing.
>>
>>
>>-- 
>>Jean
>>
>>Take action in Free Software Foundation campaigns:
>>https://www.fsf.org/campaigns
>>
>>In support of Richard M. Stallman
>>https://stallmansupport.org/
>>

-- 
	Philip Kaludercic

Re: Collaborative editing.

[Philip Kaludercic]

Ergus <spacibba@aol.com> writes:

> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?

The package still seems to be on version 0.0.0, and the HACKING[0] file
indicates that a few intended items are not implemented yet. It might
make sense to push for a preliminary version to be published as to
provide a basic collaborative environment available on ELPA (or NonGNU
ELPA if necessary), and then later work on full-compatibility.

[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org

> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>> I know there have been some experiments with collaborative editing modes in
>>> the past that were written purely in Elisp but none seem to be currently
>>> maintained and I'm not sure if any were actually very good to begin with.
>>
>>CRDT works just fine and is well maintained, you can contact author
>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>
>>Do:
>>
>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>
>>Let me know if you need any help or assistance to start with
>>collaborative editing.
>>
>>
>>-- 
>>Jean
>>
>>Take action in Free Software Foundation campaigns:
>>https://www.fsf.org/campaigns
>>
>>In support of Richard M. Stallman
>>https://stallmansupport.org/
>>

-- 
	Philip Kaludercic

Re: Collaborative editing.

[Ergus]

On Thu, Aug 19, 2021 at 09:33:28AM +0000, Philip Kaludercic wrote:
>Ergus <spacibba@aol.com> writes:
>
>> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
>
>The package still seems to be on version 0.0.0, and the HACKING[0] file
>indicates that a few intended items are not implemented yet. It might

>make sense to push for a preliminary version to be published as to
>provide a basic collaborative environment available on ELPA (or NonGNU
>ELPA if necessary), and then later work on full-compatibility.

This is the point. When some users know about the package searching in
the packages-list; maybe they will want to collaborate or report issues,
so it won't becomes a single man effort. IMHO a package doesn't really
exist until it is in Elpa or at least Melpa.

Otherwise in a couple of years there will be someone starting again
another similar effort from scratch.
>
>[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org
>
>> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>>> I know there have been some experiments with collaborative editing modes in
>>>> the past that were written purely in Elisp but none seem to be currently
>>>> maintained and I'm not sure if any were actually very good to begin with.
>>>
>>>CRDT works just fine and is well maintained, you can contact author
>>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>>
>>>Do:
>>>
>>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>>
>>>Let me know if you need any help or assistance to start with
>>>collaborative editing.
>>>
>>>
>>>--
>>>Jean
>>>
>>>Take action in Free Software Foundation campaigns:
>>>https://www.fsf.org/campaigns
>>>
>>>In support of Richard M. Stallman
>>>https://stallmansupport.org/
>>>
>
>-- 
>	Philip Kaludercic

Re: Collaborative editing.

[dick]

E> Otherwise in a couple of years there will be someone starting again another
E> similar effort from scratch.

I wouldn't worry about that.  Google remains the finder of lost children *par
excellence*.  If a project attained any kind of critical mass (such as
crdt.el), Google will find it, not the nugatory search capabilities of the ELPAs.

Re: Collaborative editing.

[Perry E. Metzger]

On 8/19/21 10:18, Ergus wrote:
>
> This is the point. When some users know about the package searching in
> the packages-list; maybe they will want to collaborate or report issues,
> so it won't becomes a single man effort. IMHO a package doesn't really
> exist until it is in Elpa or at least Melpa.
>
> Otherwise in a couple of years there will be someone starting again
> another similar effort from scratch.
>
I'd go further and say that like tramp, gnus, or org mode, or other 
really critical features, collaborative editing probably should be part 
of the base distribution.

Perry

Re: Collaborative editing.

[Philip Kaludercic]

Ergus <spacibba@aol.com> writes:

> On Thu, Aug 19, 2021 at 09:33:28AM +0000, Philip Kaludercic wrote:
>>Ergus <spacibba@aol.com> writes:
>>
>>> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
>>
>>The package still seems to be on version 0.0.0, and the HACKING[0] file
>>indicates that a few intended items are not implemented yet. It might
>
>>make sense to push for a preliminary version to be published as to
>>provide a basic collaborative environment available on ELPA (or NonGNU
>>ELPA if necessary), and then later work on full-compatibility.
>
> This is the point. When some users know about the package searching in
> the packages-list; maybe they will want to collaborate or report issues,
> so it won't becomes a single man effort. IMHO a package doesn't really
> exist until it is in Elpa or at least Melpa.

I agree, though in this case there is also the issue of having a package
that is hard to debug and test on your own, because the real bugs will
probably only pop up in hard to replicate configurations
(transcontinental-collaboration, obscure network configurations, etc.)

> Otherwise in a couple of years there will be someone starting again
> another similar effort from scratch.

I'd be intersted to see what Qiantan has to say about all of this. It
seems like he changed his email address according to the last commit in
the repository, so I update the CC'ed address in this thread too in case
he is missing out on the conversation.

>>
>>[0] https://code.librehq.com/qhong/crdt.el/-/raw/master/HACKING.org
>>
>>> On August 15, 2021 7:46:43 AM GMT+02:00, Jean Louis <bugs@gnu.support> wrote:
>>>>* Perry E. Metzger <perry@piermont.com> [2021-08-13 02:44]:
>>>>> I know there have been some experiments with collaborative editing modes in
>>>>> the past that were written purely in Elisp but none seem to be currently
>>>>> maintained and I'm not sure if any were actually very good to begin with.
>>>>
>>>>CRDT works just fine and is well maintained, you can contact author
>>>>Qiantan Hong <qhong@mit.edu> at any time you wish.
>>>>
>>>>Do:
>>>>
>>>>$ git clone https://code.librehq.com/qhong/crdt.el.git
>>>>
>>>>Let me know if you need any help or assistance to start with
>>>>collaborative editing.
>>>>
>>>>
>>>>--
>>>>Jean
>>>>
>>>>Take action in Free Software Foundation campaigns:
>>>>https://www.fsf.org/campaigns
>>>>
>>>>In support of Richard M. Stallman
>>>>https://stallmansupport.org/
>>>>
>>
>> -- 	Philip Kaludercic
>

-- 
	Philip Kaludercic

Re: Collaborative editing.

[Eli Zaretskii]

> Date: Thu, 19 Aug 2021 11:19:54 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> 
> I'd go further and say that like tramp, gnus, or org mode, or other 
> really critical features, collaborative editing probably should be part 
> of the base distribution.

I agree, provided that we can find a package which implements that in
a clean enough manner, and the author agrees to contribute it.

Re: Collaborative editing.

[Qiantan Hong]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]


Hi guys!

Sorry I've been busy lately and haven't seen this till now.

>>> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
I've already done the paperwork! Our school's office was quite slow but it's done now.

>>
>>The package still seems to be on version 0.0.0, and the HACKING[0] file
>>indicates that a few intended items are not implemented yet. It might
>
>>make sense to push for a preliminary version to be published as to
>>provide a basic collaborative environment available on ELPA (or NonGNU
>>ELPA if necessary), and then later work on full-compatibility.
Those few intended items was in fact rather very ambitious plan,
and not necessarily needed for "usual" collaboration experience.
They're suppose to enable support for, say, sharing a XScheme.el
buffer with an active running process so people can share a Lisp image
through Emacs.

Basically all functionalities for "usual" collaboration editing are all already implemented.

I'm happy to release crdt.el into either ELPA, or into mainstream Emacs
(maybe after it's battle tested on ELPA first)!

There are indeed issue about the difficulty in debugging, there is an open issue
on librehq that I still haven't reproduced yet.
It may help if we have a larger testing base.
I think it will also be very helpful if some other hackers get to understand
the internal of crdt.el and could hack when they happen to trigger some bugs,
as debugging another user's Emacs via carbon-based bio-SSH is hard.

Best,
Qiantan



[-- Attachment #2: Type: text/html, Size: 8592 bytes --]

Re: Collaborative editing.

[Qiantan Hong]

Hi guys!

Sorry I've been busy lately and haven't seen this till now.

>>> Could we try to add crdt to Elpa? Is the author somehow opposed to do the paperwork or so?
I've already done the paperwork! Our school's office was quite slow but it's done now.

>>
>>The package still seems to be on version 0.0.0, and the HACKING[0] file
>>indicates that a few intended items are not implemented yet. It might
>
>>make sense to push for a preliminary version to be published as to
>>provide a basic collaborative environment available on ELPA (or NonGNU
>>ELPA if necessary), and then later work on full-compatibility.
Those few intended items was in fact rather very ambitious plan,
and not necessarily needed for "usual" collaboration experience.
They're suppose to enable support for, say, sharing a XScheme.el
buffer with an active running process so people can share a Lisp image
through Emacs.

Basically all functionalities for "usual" collaboration editing are all already implemented.

I'm happy to release crdt.el into either ELPA, or into mainstream Emacs
(maybe after it's battle tested on ELPA first)!

There are indeed issue about the difficulty in debugging, there is an open issue
on librehq that I still haven't reproduced yet.
It may help if we have a larger testing base.
I think it will also be very helpful if some other hackers get to understand
the internal of crdt.el and could hack when they happen to trigger some bugs,
as debugging another user's Emacs via carbon-based bio-SSH is hard.

Best,
Qiantan

Re: Collaborative editing.

[Philip Kaludercic]

Qiantan Hong <qhong@alum.mit.edu> writes:

> I'm happy to release crdt.el into either ELPA, or into mainstream Emacs
> (maybe after it's battle tested on ELPA first)!

I think adding it to ELPA first would be preferable. Just note that you
would have to update the copyright notice before it could be added, and
I think incrementing the version from 0.0.0 would be nice too.

-- 
	Philip Kaludercic

Re: Collaborative editing.

[Qiantan Hong]

Sounds good, I’ve updated the copyright notice and assigned version number 0.1.0

> On Aug 28, 2021, at 4:40 AM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> Qiantan Hong <qhong@alum.mit.edu> writes:
> 
>> I'm happy to release crdt.el into either ELPA, or into mainstream Emacs
>> (maybe after it's battle tested on ELPA first)!
> 
> I think adding it to ELPA first would be preferable. Just note that you
> would have to update the copyright notice before it could be added, and
> I think incrementing the version from 0.0.0 would be nice too.
> 
> -- 
> 	Philip Kaludercic

Re: Collaborative editing.

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

Qiantan Hong <qhong@mit.edu> writes:

> Sounds good, I’ve updated the copyright notice and assigned version number 0.1.0

Yep, I managed to build the package now, using the following package
specification:


[-- Attachment #2: Type: text/plain, Size: 551 bytes --]

diff --git a/elpa-packages b/elpa-packages
index 8eab656624..576c96e704 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -105,6 +105,7 @@
  ("counsel"		:url "https://github.com/abo-abo/swiper")
  ("cpio-mode"		:url "https://github.com/dlewan/cpio-mode")
  ("crisp"		:url nil)
+ ("crdt"		:url "https://code.librehq.com/qhong/crdt.el")
  ;; ("crossword"		:url "https://github.com/Boruch-Baum/emacs-crossword")
  ;; ("csharp-mode"		:url "https://github.com/emacs-csharp/csharp-mode")
  ("csharp-mode"		:url "https://github.com/emacs-csharp/csharp-mode"

[-- Attachment #3: Type: text/plain, Size: 24 bytes --]


-- 
	Philip Kaludercic

Re: Collaborative editing.

[Ag Ibragimov]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 12 Aug 2021 19:43:25 -0400
>> From: "Perry E. Metzger" <perry@piermont.com>
>> 
>> Anyone have thoughts on how one could get Emacs to be a really top 
>> flight collaborative editing environment, especially for programmers? 
>
> I suggest to search the archives of this list for "collaborative",
> there were a few large discussions last year.  One of the latest
> attempts to add these capabilities to Emacs is here:
>
>   https://code.librehq.com/qhong/crdt.el/

Sorry for so nonchalantly changing the subject, but speaking of
searching the archives. Since not too long ago I've been having trouble
searching using "field-specified searching", i.e., using the +subject, or
+from, and most importantly - using +message-id operator.

I have a function that allows me to find the current email thread in the archives
using email's message-id; basically, it calls
(notmuch-show-get-message-id); then launches https://lists.gnu.org
and tries to search with a search string like this:

  +message-id:<YRiqQ7auhgw8LW0z@protected.localdomain>

And it used to work, but at some point, it stopped working, and that's
annoying. I've been helplessly shaking my fist whenever I try to find a thread
in the archives, but other than that, I have no idea how to cope with
this.

Does anyone know what's changed, why the search doesn't work as before anymore?