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?

[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?

[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?

[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?

[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?

[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?

[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

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]

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

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

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?

[Evgeny Zajcev]

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

Subwindow glyph functionality would be exceptionally useful in Emacs, see
https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg01188.html

Currently, we do many hacks to bring video/animations into Emacs, thanks to
:base_uri svg functionality to make it more or less acceptable

-- 
lg

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

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

[ndame]

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

> Would you interest in EAF?

If you mean if the community would be interested in sponsoring it then you should create a poll and post it to Emacs.Reddit, for example.

There are 40k emacs users there, so from the responses you can get a picture if it's worthwile to start a crowfunding for EAF.

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

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

[Zhu Zihao]

Would you interest in EAF?

github.com/manateelazycat/emacs-application-framework
(please add https header manually because if I don't remove it my mail server
will reject my mail for unknown reason)

It use platform specific API to paint QT windows on Emacs, so you can develop
wonderful applications in PyQT.

What is the most useful potential feature which Emacs lacks?

[ndame]

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

There is a discussion on Reddit about sponsoring development of multithreading in Emacs, and people there say it's too hard, takes a lot of time and it doesn't even bring that much benefit to the user.

If this is the case (is it?) then what are those other features which could bring much more tangible benefits for the user and assuming somebody works on them full time sponsored by the community they can be implemented in, say,  a few months?

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

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

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

> There is a discussion on Reddit about sponsoring development of multithreading in Emacs, and people there say it's too hard, takes a lot of time and it doesn't even
> bring that much benefit to the user.
>
> If this is the case (is it?) then what are those other features which could bring much more tangible benefits for the user and assuming somebody works on them full time
> sponsored by the community they can be implemented in, say,  a few months?
Maybe a better support for graphics? Let people draw in Emacs window (on
GUi clients). It could benefit some org mode features, some poeple who
does uml via ditaa or similar, powerline users etc. Emacs could be used
in a similar fashion like Conky (system monitoring tool), for those that
use Emacs as a daemon, and could even make Emacs more of a office style
application for some people.

Could also benefit some UI stuff, for example drawing on screen could
benefit more mouse/touch interface so one day Emacs could get a "tablet
ui" or something.

Could be done by exposing underlaying OS/Widget Kit drawing (Cairo, X11,
Gdk, whatever Macs have) to draw directly on Emacs frame/either window
or buffer based. Could also be done by drawing to an "image" (in memory)
via say Cairo surface, XPixmap etc, and then displaying that image in
overlays as Emacs already do.

Could be nice with some task-based parallelism too, like Intel's TBB
does. TBB has Apache license, I am not so legal so I don't know if it is
compatible with GPL, so no idea if it is just opensource or free ...

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

[ndame]

>
> Maybe a better support for graphics? Let people draw in Emacs window (on
> GUi clients).

Yes, it could be useful. One should come up with a concrete specification like what exactly should be implemented and an estimation of how much time it takes.

Somebody on Reddit mentioned that Clojure has a setup where the community sponsors the implementation of features. Emacs could also have something similar:

   In the Clojure community, there is something called ClojuristsTogether, where they
   fund several opensource projects for 3 months, compensated for $3k a month.

https://old.reddit.com/r/emacs/comments/ghq1yx/lets_get_real_multithreading_into_emacs_by_hiring/fqavqiy/

https://www.clojuriststogether.org/

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

[Stefan Kangas]

ndame <ndame@protonmail.com> writes:

> Somebody on Reddit mentioned that Clojure has a setup where the
> community sponsors the implementation of features. Emacs could also
> have something similar:
>
>    In the Clojure community, there is something called ClojuristsTogether, where they
>    fund several opensource projects for 3 months, compensated for $3k a month.
>
> https://old.reddit.com/r/emacs/comments/ghq1yx/lets_get_real_multithreading_into_emacs_by_hiring/fqavqiy/
>
> https://www.clojuriststogether.org/

If we asked our users, I think we would find that many people would be
willing to contribute financially.

Is there anything stopping us from doing something like this?

Best regards,
Stefan Kangas

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

[ndame]

>
> If we asked our users, I think we would find that many people would be
> willing to contribute financially.
>

People are more likely to contribute if they get something sooner than otherwise.

So the questions is: is there someone who would'd love to work on his pet emacs feature full time instead of in his free time? Because if so and it's a popular feature (e.g. graphics canvas for emacs, vscode-like instant support for languages which sets up the lsp server, lsp client and completion automatically, etc.) then it's very likely the community would support that developer via crowdfunding for several months of full time emacs work in return of getting those features quickly in a few months.

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

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>>
>> If we asked our users, I think we would find that many people would be
>> willing to contribute financially.
>>
>
> People are more likely to contribute if they get something sooner than
> otherwise.

> So the questions is: is there someone who would'd love to work on his pet emacs
> feature full time instead of in his free time? Because if so and it's a popular
> feature (e.g. graphics canvas for emacs, vscode-like instant support for
> languages which sets up the lsp server, lsp client and completion automatically,
> etc.) then it's very likely the community would support that developer via
> crowdfunding for several months of full time emacs work in return of getting
> those features quickly in a few months.

Indeed. If you just ask people what they want for certain amount of $$$
you might end up building a death star :-)

https://www.bbc.com/news/world-us-canada-20997144

I can't find the link on U.S. goverment site any more.

It is probably, more constructive to offer a project, or two, to
contribute and help to.

Or maybe you could lift up and help some popular projects to integrate
themselves better into Emacs and develop maybe some more functionality
they might be missing, something like org, magit, projectile, etc.

Maybe you could offer a coaching/mentoring to someone who has a vision
to develop some new functionality that might benefit wider audience of
users?

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

[HaiJun Zhang]

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

I want to manage and process my pictures in emacs, like cropping.

I want to play video in emacs and control the playing with emacs style.

在 2020年5月12日 +0800 PM2:57，Arthur Miller <arthur.miller@live.com>，写道：
> ndame <ndame@protonmail.com> writes:
>
> > There is a discussion on Reddit about sponsoring development of multithreading in Emacs, and people there say it's too hard, takes a lot of time and it doesn't even
> > bring that much benefit to the user.
> >
> > If this is the case (is it?) then what are those other features which could bring much more tangible benefits for the user and assuming somebody works on them full time
> > sponsored by the community they can be implemented in, say, a few months?
> Maybe a better support for graphics? Let people draw in Emacs window (on
> GUi clients). It could benefit some org mode features, some poeple who
> does uml via ditaa or similar, powerline users etc. Emacs could be used
> in a similar fashion like Conky (system monitoring tool), for those that
> use Emacs as a daemon, and could even make Emacs more of a office style
> application for some people.
>
> Could also benefit some UI stuff, for example drawing on screen could
> benefit more mouse/touch interface so one day Emacs could get a "tablet
> ui" or something.
>
> Could be done by exposing underlaying OS/Widget Kit drawing (Cairo, X11,
> Gdk, whatever Macs have) to draw directly on Emacs frame/either window
> or buffer based. Could also be done by drawing to an "image" (in memory)
> via say Cairo surface, XPixmap etc, and then displaying that image in
> overlays as Emacs already do.
>
> Could be nice with some task-based parallelism too, like Intel's TBB
> does. TBB has Apache license, I am not so legal so I don't know if it is
> compatible with GPL, so no idea if it is just opensource or free ...
>

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

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

[Eduardo Ochs]

Hi HaiJun,

several years ago - in 2012, I think - I tried the existing ways of
playing audio from Emacs and I found them hard to use and unreliable,
and I decided to implement a minimalistic way to play audios and
videos from Emacs by calling external programs (sort of) directly...
and I've been incredibly happy with it since then. It's very different
from what you're asking for, but it's very easy to set up and to hack.
If you want to take a look at it, it's here:

  http://angg.twu.net/eev-intros/find-audiovideo-intro.html
  http://angg.twu.net/eev-intros/find-audiovideo-intro.html#4

The link with the "#4" points to a demo. There's a good introduction
to eev here,

  http://angg.twu.net/emacsconf2019.html

and you can install it from ELPA.

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/#eev


On Tue, 12 May 2020 at 21:56, HaiJun Zhang <netjune@outlook.com> wrote:
>
> I want to manage and process my pictures in emacs, like cropping.
>
> I want to play video in emacs and control the playing with emacs style.

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

[Eduardo Ochs]

Oops, sorry, "#4" -> "#4.3"... the right link to the demo is:

  http://angg.twu.net/eev-intros/find-audiovideo-intro.html#4.3

On Tue, 12 May 2020 at 22:34, Eduardo Ochs <eduardoochs@gmail.com> wrote:
>
> Hi HaiJun,
>
> several years ago - in 2012, I think - I tried the existing ways of
> playing audio from Emacs and I found them hard to use and unreliable,
> and I decided to implement a minimalistic way to play audios and
> videos from Emacs by calling external programs (sort of) directly...
> and I've been incredibly happy with it since then. It's very different
> from what you're asking for, but it's very easy to set up and to hack.
> If you want to take a look at it, it's here:
>
>   http://angg.twu.net/eev-intros/find-audiovideo-intro.html
>   http://angg.twu.net/eev-intros/find-audiovideo-intro.html#4
>
> The link with the "#4" points to a demo. There's a good introduction
> to eev here,
>
>   http://angg.twu.net/emacsconf2019.html
>
> and you can install it from ELPA.
>
>   Cheers,
>     Eduardo Ochs
>     http://angg.twu.net/#eev
>
>
> On Tue, 12 May 2020 at 21:56, HaiJun Zhang <netjune@outlook.com> wrote:
> >
> > I want to manage and process my pictures in emacs, like cropping.
> >
> > I want to play video in emacs and control the playing with emacs style.

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

[H. Dieter Wilhelm]

Some too personal ideas?

What I'm missing from stock Emacs:

- Synchronisation of BBDB and Calendar (or other Emacs' PIMs) with
  Nextcloud (or similar.  I read that Tramp connects now to Nextcloud
  :-).

- A tree view in dired (like ztree, for example).

- Starting executables from Dired under Windows (for example with S-RET,
  OK, there's this package dired-launch).

Where I often have to leave Emacs (mainly under Windows @work):

- Capturing screenshots and drawing stuff over them.  This is just an
  observation, I'm not asking to convert Emacs to the Gimp!

What I'm dreaming off:

- Operating a Tor browser (or others) as a true Emacs-Browser (I'm using
  EWW as often as possible, but when a web browser is already open, then
  it is hard to go back).

- Some Dictionary access, in the vain of ispell, when reading, writing
  and browsing.

- And maybe visual word and spelling suggestions like these Android
  keyboards (but I think some of you are working on such things...)

  Dieter


ndame <ndame@protonmail.com> writes:

> There is a discussion on Reddit about sponsoring development of
> multithreading in Emacs, and people there say it's too hard, takes a
> lot of time and it doesn't even bring that much benefit to the user.
>
> If this is the case (is it?) then what are those other features which
> could bring much more tangible benefits for the user and assuming
> somebody works on them full time sponsored by the community they can
> be implemented in, say, a few months?
>

-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

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

[Michael Albinus]

dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) writes:

Hi Dieter,

> - Synchronisation of BBDB and Calendar (or other Emacs' PIMs) with
>   Nextcloud (or similar.  I read that Tramp connects now to Nextcloud
>   :-).

That is just for files. I don't know, whether such a synchronisation can
be implemented based on file copying.

And it needs GOA (Gnome Online Accounts).

>   Dieter

Best regards, Michael.

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

Connecting to Nextcloud is useful, but if you want your data to be
secure you shouldn't send it unencrypted to a company's server.
Does Tramp have the ability to encrypt the data before sending it to Nextcloud,
and decrypt it after fetching it from Nextcloud?

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

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

> Connecting to Nextcloud is useful, but if you want your data to be
> secure you shouldn't send it unencrypted to a company's server.
> Does Tramp have the ability to encrypt the data before sending it to Nextcloud,
> and decrypt it after fetching it from Nextcloud?

Tramp uses GVFS (Gnome Virtual FileSystem) as implementation. Under the
hood, the nextcloud server is connected via davs, that is the dav
protocol, ssl encrypted. Well, these days it is rather tls.

So yes, data are encrypted when Tramp accesses a nextcloud server.

Best regards, Michael.

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

  > So yes, data are encrypted when Tramp accesses a nextcloud server.

SSL encrypts the data for transport between Tramp and the nextcloud
server.  Whan I am talking about is to store the data in encrypted
form _in_ the nextcloud server, and not decrypt them until you fetch
them back again.


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

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

>   > So yes, data are encrypted when Tramp accesses a nextcloud server.
>
> SSL encrypts the data for transport between Tramp and the nextcloud
> server.  Whan I am talking about is to store the data in encrypted
> form _in_ the nextcloud server, and not decrypt them until you fetch
> them back again.

Tramp cannot run processes on a remote nextcloud server. Fortunately,
this isn't needed.

When you visit an encrypted file from the nextcloud server, let's call
it foo.gpg, Tramp creates a local copy of that file with the same
extension, like tmp.gpg. That file is visited then in the buffer, and
Emacs' mechanisms recognize it as encrypted, and ask you for the
passphrase to decrypt.

The reverse scenario works similar: If you want to save a buffer bound
to a file on the remote nextcloud server, let's call it foo.gpg again,
Tramp saves the buffer into a local tempoprary file with the same
extension, like tmp.gpg. This triggers encryption of the local
file. Afterwards, Tramp moves the local file to the nextcloud server
with the proper name.

For you (the user) everything looks like handling a local file.

Best regards, Michael.

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

  > > SSL encrypts the data for transport between Tramp and the nextcloud
  > > server.  Whan I am talking about is to store the data in encrypted
  > > form _in_ the nextcloud server, and not decrypt them until you fetch
  > > them back again.

  > Tramp cannot run processes on a remote nextcloud server. Fortunately,
  > this isn't needed.

We may be miscommunicating.

You should _only_ do encryption and decryption on your own machine,
using free software that you installed in the usual way.  You cannot
trust a server to do those operations for you.

So the way I have in mind is that Tramp would automatically encrypt
any file before sending it to Nextcloud, and decrypt after fetching
it.  So you would not have to choose your file names to specify "this
is encrypted data."  Tramp, when uploading, would put in something to
indicate that Tramp had encrypted the data, and that would tell Tramp
to decrypt it when fetching it back.

The file name you started with should be encrypted too, so that the 
nextcloud instance cannot see what it was.



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

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

> So the way I have in mind is that Tramp would automatically encrypt
> any file before sending it to Nextcloud, and decrypt after fetching
> it.  So you would not have to choose your file names to specify "this
> is encrypted data."  Tramp, when uploading, would put in something to
> indicate that Tramp had encrypted the data, and that would tell Tramp
> to decrypt it when fetching it back.
>
> The file name you started with should be encrypted too, so that the
> nextcloud instance cannot see what it was.

Such functionality does not exist in Tramp.

Remember, Tramp is just a stupid library, which offers alternative
implementations for primitives like write-region, copy-file, or
insert-file-contents. Before Tramp could implement automagic
encoding/decoding, we would need a design in Emacs how it shall look
like. Not only for Tramp, other file name handlers could profit from
this as well. And even files on mounted directories come to mind.

Best regards, Michael.

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

  > Before Tramp could implement automagic
  > encoding/decoding, we would need a design in Emacs how it shall look
  > like.

I would suggest that this be part of accessing files on cloudy services.
Anything going up gets encrypted first; anything coming down gets decrypted
on arrival.

However: when people use nextcloud, are they normally using their
own server instances?  Or normally using a server run by someone else?

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

[H. Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > Before Tramp could implement automagic
>   > encoding/decoding, we would need a design in Emacs how it shall look
>   > like.
>
> I would suggest that this be part of accessing files on cloudy services.
> Anything going up gets encrypted first; anything coming down gets decrypted
> on arrival.
>
> However: when people use nextcloud, are they normally using their
> own server instances?  Or normally using a server run by someone else?

Sorry, I can't tell what the norm is.  Personally, I'm using a webhoster
for my Nextcloud instance.  And I've got a colleague which is running it
on his Raspberry Pi from home.  Of course: Both is possible.

   Dieter
-- 
Best wishes
H. Dieter Wilhelm
Zwingenberg, Germany

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

  > Sorry, I can't tell what the norm is.  Personally, I'm using a webhoster
  > for my Nextcloud instance.  And I've got a colleague which is running it
  > on his Raspberry Pi from home.  Of course: Both is possible.

Since we can't determine whether any given user will want the
auto-encrypt-decrypt, we should let users specify yes or no.
Eventually we might develop ideas for defaults more sophisticated
than just "yes" and "no".

The goal here is to be able to save and retrieve files on any server,
such that the server operator can't determine their contents or their
names.  Tramp would generate the remote file name to use, encrypt the
file contents, then write that into the generated remote file name on
the remote machine.

Tramp would have to maintain a local table mapping specified (local) names to
generated (remote) names.

The data that gets encrypted could contain first the specified file
name, then a delimiter, then the contents of the file.  That way, if
you lose the local table or it is lacking some files, but you have the
encryption key, you can decrypt each saved remote file and find out
what its original specified file name was.

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

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

Hi Richard,

>   > Before Tramp could implement automagic
>   > encoding/decoding, we would need a design in Emacs how it shall look
>   > like.
>
> I would suggest that this be part of accessing files on cloudy services.
> Anything going up gets encrypted first; anything coming down gets decrypted
> on arrival.

We cannot enable this by default. There are good reasons that people
bring their files on a "cloudy" server unencrypted, for example because
they want to share those files with other people, or they want to access
these files with other tools but Emacs. So it could be an option only,
like a new Tramp method "nextcloud-crypt" or whatever.

And it doesn't affect file copying only. You want to hide the file
names, which has effect for most of the file name operations Tramp
provides an own implementation.

> However: when people use nextcloud, are they normally using their
> own server instances?  Or normally using a server run by someone else?

Like Dieter said, both is happening. I, for example, use two local
nextcloud servers on my NAS devices in the basement, and I use also
public nextcloud servers somewhere else.

Best regards, Michael.

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

[Eric S Fraga]

On Tuesday, 12 May 2020 at 12:00, H. Dieter Wilhelm wrote:
> I read that Tramp connects now to Nextcloud

Any tutorials on this?  I have tried, based on the small snippet in the
tramp info manual, and all I get is "There is no online account
...".  It would make some of the discussed features available easily
(relatively).

Thank you.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.6 on Debian bullseye/sid

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

[Michael Albinus]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

Hi Eric,

>> I read that Tramp connects now to Nextcloud
>
> Any tutorials on this?  I have tried, based on the small snippet in the
> tramp info manual, and all I get is "There is no online account
> ...".  It would make some of the discussed features available easily
> (relatively).

"... your credentials must be populated in your ‘Online Accounts’
application outside Emacs."

From the Tramp manual, speaking about the nextcloud method.

> Thank you.

Best regards, Michael.

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

[Eric S Fraga]

On Tuesday, 12 May 2020 at 17:34, Michael Albinus wrote:
> "... your credentials must be populated in your ‘Online Accounts’
> application outside Emacs."
>
> From the Tramp manual, speaking about the nextcloud method.

Thanks for this.  And, boy, did this ever send me down a rabbit
hole... anyway, finally managed to get GNOME running and created an
"online" account.  Now, back with my usual DE/WM and running Emacs
again, I get an error like this:

tramp-signal-hook-function:
   Host name ‘MY.NEXTCLOUD.SITE’ does not match
   ‘\`\(127\.0\.0\.1\|::1\|localhost6?\|t3610\)\'’

and I don't see why it should as that is the regexp for identifying a
local host, which is most definitely what I do not want given that I am
trying to connect to a nextcloud server...  hey hum.  Tramp info manual
not helpful in this regard unfortunately.

Anyway, apologies for hijacking the thread although, in my defence, the
desirable potential feature of being able to transparently access
resources on the web is what started me off...

Thanks again Michael.

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.3.6 on Debian bullseye/sid

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

[Arthur Miller]

dieter@duenenhof-wilhelm.de (H. Dieter Wilhelm) writes:

> Some too personal ideas?
>
> What I'm missing from stock Emacs:
>
> - Synchronisation of BBDB and Calendar (or other Emacs' PIMs) with
>   Nextcloud (or similar.  I read that Tramp connects now to Nextcloud
>   :-).
>
> - A tree view in dired (like ztree, for example).
You can already have this with some third party pacakges

Checkout dired-hacks and dired-ranger. I think there were some other
packages offereing a tree view of directories, but I don't remember any
more I don't use dired that way myself.

> - Starting executables from Dired under Windows (for example with S-RET,
>   OK, there's this package dired-launch).
You can do this too, shouldn't be a problem with few shortcuts, or
dired-launch or open-with.
> Where I often have to leave Emacs (mainly under Windows @work):
>
> - Capturing screenshots and drawing stuff over them.  This is just an
>   observation, I'm not asking to convert Emacs to the Gimp!
Have you tried "ScreenShot":https://www.emacswiki.org/emacs/ScreenShot

I don't take many screenshots myself, so I didn't try it myself, just
remember it was there.

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

[Drew Adams]

> - Starting executables from Dired under Windows (for example with S-
>   RET, OK, there's this package dired-launch).

Just use `!'.
Customize option `dired-guess-shell-alist-user' so
it associates the executable you want with the file
extension you want.  When you hit `!' on a file with
that extension you get the program you want as the
default - just hit `RET'.

You need (standard) library `dired-x.el' for this.

> - Some Dictionary access, in the vain of ispell, when reading, writing
>   and browsing.

This wiki page has lots of such (search for "dict"):

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

And this wiki page has thesauri (synonyms) libraries:

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

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

[Helmut Eller]

On Mon, May 11 2020, ndame wrote:

> There is a discussion on Reddit about sponsoring development of
> multithreading in Emacs, and people there say it's too hard, takes a
> lot of time and it doesn't even bring that much benefit to the user.
>
> If this is the case (is it?) then what are those other features which
> could bring much more tangible benefits for the user and assuming
> somebody works on them full time sponsored by the community they can
> be implemented in, say,  a few months?

1. Improving display of long lines.  Emacs gets very unresponsive when a
buffer contains long lines.  This is something I run into rather
frequently and it's very irritating.  Apparently this is a difficult
problem to fix because to the display code needs to "measure" how long
the line is in pixels and there is no other way to that than to iterate
over each character in a line.  But it may be possible reduce the number
of how often this measuring needs to done.  It seems to me that
web-browsers also need a long time to display long lines, but once the
line is drawn, scrolling works as quick as for short lines.

2. Being able to display HTML/CSS/SVG the way mainstream web-browsers
display would be nice.  But probably too big a project.  And in the long
run, probably a reason for Emacs to go extinct.

Helmut

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

[Jose A. Ortega Ruiz]

On Tue, May 12 2020, Helmut Eller wrote:

[...]

> 1. Improving display of long lines.  Emacs gets very unresponsive when a
> buffer contains long lines.  This is something I run into rather
> frequently and it's very irritating.  Apparently this is a difficult
> problem to fix because to the display code needs to "measure" how long
> the line is in pixels and there is no other way to that than to iterate
> over each character in a line.  But it may be possible reduce the number
> of how often this measuring needs to done.  It seems to me that
> web-browsers also need a long time to display long lines, but once the
> line is drawn, scrolling works as quick as for short lines.
>
> 2. Being able to display HTML/CSS/SVG the way mainstream web-browsers
> display would be nice.  But probably too big a project.  And in the long
> run, probably a reason for Emacs to go extinct.

Just wanted to say, as someone who uses Emacs for literally everthing
except visiting a few web pages, that these two projects are exactly the
ones i'd need more.  In case someone's counting :)

Cheers,
jao, who wishes he had time to hack on this.
-- 
Experience is not what happens to you; it is what you do with what
happens to you.
 - Aldous Huxley

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

[Stefan Monnier]

> Just wanted to say, as someone who uses Emacs for literally everthing
> except visiting a few web pages, that these two projects are exactly the
> ones i'd need more.  In case someone's counting :)

For the "browser" part, have you tried the `xwidget` approach to the problem?
How 'bout EAF (emacs-application-framework)?


        Stefan

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

[jao]

On Tue, May 12 2020, Stefan Monnier wrote:

>> Just wanted to say, as someone who uses Emacs for literally everthing
>> except visiting a few web pages, that these two projects are exactly the
>> ones i'd need more.  In case someone's counting :)
>
> For the "browser" part, have you tried the `xwidget` approach to the
> problem?

A few years ago: it was then in a very early stage and tended to kill
emacs.  And after a while i got the impression that it got out of steam
and further development stopped: but maybe that's not so?

> How 'bout EAF (emacs-application-framework)?

I haven't used it (yet), but its problem (IIUC) in my case is that it
wants to be my window manager (i'm a very happy user of exwm), pdf
viewer (ditto with pdf-tools), and so on, so it feels a bit too invasive
(i guess i also don't like the looks of qt apps, but that's just
prejudice).  Again, i might be wrong and the EAF be modular enough for
using only its browser.

I guess what i'd really like about a fully integrated browser would be
its being leaner than the webkit or quantum behemoths and fully
scriptable in elisp: if all we have is a widget which essentially embeds
one of those browsers and i have to access it using python, well,
there's not much difference with having a firefox process running in an
exwm workspace, as i do now, together with something like trydactil.

Something a bit better with graphical layout than emacs-w3m, which i
quite like already, would be almost enough for me, really.  But this is
most probably not a very reasonable expectation: people will want all
the HTML5 bells and wishes, i suppose...

Cheers,
jao
-- 
Omnia disce, videbus postea nihil esse superfluum - Hugh of St Victor

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

[João Távora]

On Tue, May 12, 2020 at 1:30 PM Helmut Eller <eller.helmut@gmail.com> wrote:
> 2. Being able to display HTML/CSS/SVG the way mainstream web-browsers
> display would be nice.  But probably too big a project.  And in the long
> run, probably a reason for Emacs to go extinct.

That translates to "either Emacs becomes a Elisp-programmable
web-browser or goes extinct".  Indeed hard, but not impossible .

And Elisp can teach JS a thing or two. And what if Emacs could run JS?

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

[Stefan Kangas]

João Távora <joaotavora@gmail.com> writes:

> That translates to "either Emacs becomes a Elisp-programmable
> web-browser or goes extinct".  Indeed hard, but not impossible .

HTML rendering was mentioned in this talk at Emacsconf 2019 by
Perry E. Metzger:

   https://media.emacsconf.org/2019/26.html

   (Discussion on HTML starts around 00:30:00.)

He thinks it would have to be based on an external web rendering
toolkit (like WebKit).

Best regards,
Stefan Kangas

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

[Helmut Eller]

On Wed, May 13 2020, Stefan Kangas wrote:

> João Távora <joaotavora@gmail.com> writes:
>
>> That translates to "either Emacs becomes a Elisp-programmable
>> web-browser or goes extinct".  Indeed hard, but not impossible .
>
> HTML rendering was mentioned in this talk at Emacsconf 2019 by
> Perry E. Metzger:
>
>    https://media.emacsconf.org/2019/26.html
>
>    (Discussion on HTML starts around 00:30:00.)
>
> He thinks it would have to be based on an external web rendering
> toolkit (like WebKit).

Or maybe Emacs could run inside a browser via WebAssembly or something
like that.

Helmut

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

[tomas]

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

On Thu, May 14, 2020 at 12:08:46PM +0200, Helmut Eller wrote:

[...]

> Or maybe Emacs could run inside a browser via WebAssembly or something
> like that.

I guess you're saying it tongue-in-cheek. But still I shudder at this
dystopia.

Cheers
-- t

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

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

[Robert Pluim]

>>>>> On Thu, 14 May 2020 12:17:41 +0200, <tomas@tuxteam.de> said:

    nil> On Thu, May 14, 2020 at 12:08:46PM +0200, Helmut Eller wrote:
    nil> [...]

    >> Or maybe Emacs could run inside a browser via WebAssembly or something
    >> like that.

    nil> I guess you're saying it tongue-in-cheek. But still I shudder at this
    nil> dystopia.

Youʼre aware of <https://repl.it>, right?

Robert

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

[tomas]

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

On Thu, May 14, 2020 at 12:34:50PM +0200, Robert Pluim wrote:
> >>>>> On Thu, 14 May 2020 12:17:41 +0200, <tomas@tuxteam.de> said:
> 
>     nil> On Thu, May 14, 2020 at 12:08:46PM +0200, Helmut Eller wrote:
>     nil> [...]
> 
>     >> Or maybe Emacs could run inside a browser via WebAssembly or something
>     >> like that.
> 
>     nil> I guess you're saying it tongue-in-cheek. But still I shudder at this
>     nil> dystopia.
> 
> Youʼre aware of <https://repl.it>, right?

I'm not. I don't even want to follow that link -- I know it'll make me sad.
Don't get me wrong. I'm well aware of what WebAssembly /technically/ is, and
what's possible with it (including Spectre exploits).

It's rather watching the browser (the one piece of software in my environment
I most detest and mistrust) evolve into the indispensable operating system.

It's watching how a piece of formally free software becomes unfree because
of crushing complexity and decommoditiation of protocols

For one time I'm glad to be rather old and soon out of this game.

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?

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

We have a program, LibreJS, which blocks all webassebly code
as well as nonfree Javascript code.  We should try to teach people
NOT to run any webassebly.

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

[Dmitry Gutov]

On 15.05.2020 06:25, Richard Stallman wrote:
> We have a program, LibreJS, which blocks all webassebly code
> as well as nonfree Javascript code.  We should try to teach people
> NOT to run any webassebly.

You're aware that webassembly doesn't always mean "proprietary", right?

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

We have a program, LibreJS, which blocks all webassebly code
as well sa nonfree Javascript code.  We should try to teach people
NOT to run any webassebly.

I suspect that repl.it would be blocked by LibreJS.
Would someone like to tell me a 10-line summary of what it does?

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

[Dmitry Gutov]

On 15.05.2020 06:25, Richard Stallman wrote:
> I suspect that repl.it would be blocked by LibreJS.

Maybe, maybe not. The landing page is mostly static HTML, with some 
embedded pictures and videos.

> Would someone like to tell me a 10-line summary of what it does?

A couple of marketing blurbs:

   Repl.it is a simple yet powerful online IDE, Editor, Compiler, 
Interpreter, and REPL. Code, compile, run, and host in 50+ programming 
languages...

   Code together, right from your browser. With Multiplayer, you can 
write, review and debug together, in real time. Share your entire Repl 
projects, or live Repl Embeds with the community.

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

  >    Code together, right from your browser. With Multiplayer, you can 
  > write, review and debug together, in real time. Share your entire Repl 
  > projects, or live Repl Embeds with the community.

Does this manner of operation involve using a server?  If so, whose server?

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

[Dmitry Gutov]

On 16.05.2020 07:18, Richard Stallman wrote:
>    >    Code together, right from your browser. With Multiplayer, you can
>    > write, review and debug together, in real time. Share your entire Repl
>    > projects, or live Repl Embeds with the community.
> 
> Does this manner of operation involve using a server?  If so, whose server?

Quoting their docs again:

   Q. How does repl.it work?

   For most languages, code is sent to our servers where it will be
   executed in a secure sandbox. The result is then sent back and
   rendered on the website. However, some of our interpreters can run
   directly in your browser without going to the server.

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

     > Q. How does repl.it work?

     > For most languages, code is sent to our servers where it will be
     > executed in a secure sandbox. The result is then sent back and
     > rendered on the website. However, some of our interpreters can run
     > directly in your browser without going to the server.

Thanks.  Now I see that repl.it operates in two ways, both of which
people ought to avoid on general principles.

So Emacs should not talk about repl.it.

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

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

  > > That translates to "either Emacs becomes a Elisp-programmable
  > > web-browser or goes extinct".

HTML is a peripheral application area for Emacs.  We should not exaggerate
its importance.

When I want to look at HTML in an email, I use an external renderer:
lynx.

The built-in Emacs renderer gives ok results when the links don't matter.
For links, the way it tries to follow them is useless since it doesn't
go through Tor.  Anyway, I'd rather send an email to fetch the page contents.
The lynx output makes that easy to do.

The built-in Emacs renderer often takes a painfully long time.  I wish
I could easily tell it to give up without trying if the text is above
a certain size or complexity.

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 14 May 2020 23:17:08 -0400
> Cc: eller.helmut@gmail.com, joaotavora@gmail.com, emacs-devel@gnu.org
> 
> The built-in Emacs renderer often takes a painfully long time.

Please try customizing shr-use-fonts to nil, and see if this makes
things less painful for you.

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

  > Please try customizing shr-use-fonts to nil, and see if this makes
  > things less painful for you.

Thanks.

I never invoke the HTML renderer explicitly.  It gets done automatically
by MIME display.  As a result, I don't know what it is called, so I don't
know where to look for customizations.

Would it be possible to change MIME display to show users, somehow,
what package it is using to render HTML?

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: stefankangas@gmail.com, eller.helmut@gmail.com,
> 	joaotavora@gmail.com, emacs-devel@gnu.org
> Date: Sat, 16 May 2020 00:18:43 -0400
> 
>   > Please try customizing shr-use-fonts to nil, and see if this makes
>   > things less painful for you.
> 
> Thanks.
> 
> I never invoke the HTML renderer explicitly.  It gets done automatically
> by MIME display.  As a result, I don't know what it is called, so I don't
> know where to look for customizations.

Emacs has only one built-in HTML renderer, it is called shr.el.

> Would it be possible to change MIME display to show users, somehow,
> what package it is using to render HTML?

Ideas for how to do this are welcome.  Do we have any machinery in
Emacs to show similar information in other similar conditions?  For
example, visiting a file of some type automatically shows that file in
some format.  The way we should this is via the major mode name in the
mode line.  So perhaps we should mentions shr in the mode line as well
in these cases, as minor mode or somesuch?

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

[Stefan Monnier]

> mode line.  So perhaps we should mentions shr in the mode line as well
> in these cases, as minor mode or somesuch?

I'm not sure this info is important enough to warrant displaying it in
the mode-line, but `describe-mode` would be a "natural" place, indeed.


        Stefan

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

  > Emacs has only one built-in HTML renderer, it is called shr.el.

What is the relation of eww to shr?

  > Ideas for how to do this are welcome.  Do we have any machinery in
  > Emacs to show similar information in other similar conditions? 

Perhaps display a header line saying

  Rendered by shr mode

and if you click on that you get the mode help for shr mode

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

[Andreas Schwab]

On Mai 16 2020, Richard Stallman wrote:

> What is the relation of eww to shr?

eww is a front end for shr, other users are rmail and gnus.  shr only
handles the rendering.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

Why use the name shr for an HTML renderer?  I'd never guess that name,
and from the name I would never guess what it does.

How about renaming it to HTML Render?

A rendered HTML segment in a message can't really have its own major mode,
but if it sets up a text property keymap to get the commands of that mode,
it would be useful to offer a way to display the doc string of that mode.



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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> cc: emacs-devel@gnu.org
> Date: Sun, 17 May 2020 23:42:32 -0400
> 
> Why use the name shr for an HTML renderer?

As the file's header says, "shr" stands for "Simple HTML Renderer".

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

[Filipp Gunbin]

On 16/05/2020 00:18 -0400, Richard Stallman wrote:

> Would it be possible to change MIME display to show users, somehow,
> what package it is using to render HTML?

Gnus uses the variable "mm-text-html-renderer" (also shr by default) to
select HTML renderer.  Maybe this variable can be reused in other
places.

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

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,
>   eller.helmut@gmail.com,  stefankangas@gmail.com,  joaotavora@gmail.com
> Date: Mon, 18 May 2020 18:20:18 +0300
> 
> Gnus uses the variable "mm-text-html-renderer" (also shr by default) to
> select HTML renderer.  Maybe this variable can be reused in other
> places.

Not surprisingly, Rmail has rmail-mime-render-html-function for the
same purpose.

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

[Robert Pluim]

>>>>> On Thu, 14 May 2020 23:17:08 -0400, Richard Stallman <rms@gnu.org> said:

    Richard> The built-in Emacs renderer gives ok results when the links don't matter.
    Richard> For links, the way it tries to follow them is useless since it doesn't
    Richard> go through Tor.
   
The url library used by eww/shr supports SOCKS, and Tor can be run as
a SOCKS proxy.

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 15 May 2020 11:10:22 +0200
> Cc: emacs-devel@gnu.org, eller.helmut@gmail.com,
>  Stefan Kangas <stefankangas@gmail.com>, joaotavora@gmail.com
> 
>     Richard> The built-in Emacs renderer gives ok results when the links don't matter.
>     Richard> For links, the way it tries to follow them is useless since it doesn't
>     Richard> go through Tor.
>    
> The url library used by eww/shr supports SOCKS, and Tor can be run as
> a SOCKS proxy.

It's a matter of some coding, I guess.  Richard added a defcustom to
use Tor in VC (it's already in Emacs 27), and I guess something
similar can be done for URL.

Any volunteers?

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

[Robert Pluim]

>>>>> On Fri, 15 May 2020 13:21:06 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 15 May 2020 11:10:22 +0200
    >> Cc: emacs-devel@gnu.org, eller.helmut@gmail.com,
    >> Stefan Kangas <stefankangas@gmail.com>, joaotavora@gmail.com
    >> 
    Richard> The built-in Emacs renderer gives ok results when the links don't matter.
    Richard> For links, the way it tries to follow them is useless since it doesn't
    Richard> go through Tor.
    >> 
    >> The url library used by eww/shr supports SOCKS, and Tor can be run as
    >> a SOCKS proxy.

    Eli> It's a matter of some coding, I guess.  Richard added a defcustom to
    Eli> use Tor in VC (it's already in Emacs 27), and I guess something
    Eli> similar can be done for URL.

I donʼt think any coding is required:

You can point the url library at localhost:9050 (or whatever the Tor
default SOCKS port is) using:
    
    socks-server is a variable defined in `socks.el'.
    Its value is ("Default server" "socks" 1080 5)

and tell url to use SOCKS with:

    url-gateway-method is a variable defined in `url-vars.el'.
    Its value is `native'

      You can customize this variable.

    Documentation:
    The type of gateway support to use.
    Should be a symbol specifying how to get a connection from the local machine.

    Currently supported methods:
    `telnet': Run telnet in a subprocess to connect;
    `rlogin': Rlogin to another machine to connect;
    `socks': Connect through a socks server;
    `tls': Connect with TLS;
    `ssl': Connect with SSL (deprecated, use `tls' instead);
    `native': Connect directly.

unless youʼre talking about getting url to use 'torsocks' as a gateway
method, which would require some coding.

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: rms@gnu.org,  emacs-devel@gnu.org,  eller.helmut@gmail.com,
>   stefankangas@gmail.com,  joaotavora@gmail.com
> Date: Fri, 15 May 2020 13:07:08 +0200
> 
> unless youʼre talking about getting url to use 'torsocks' as a gateway
> method, which would require some coding.

I think I did mean 'torsocks', but I'm way out of my depth here, so
feel free to ignore me.

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

[Robert Pluim]

>>>>> On Fri, 15 May 2020 14:28:50 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: rms@gnu.org,  emacs-devel@gnu.org,  eller.helmut@gmail.com,
    >> stefankangas@gmail.com,  joaotavora@gmail.com
    >> Date: Fri, 15 May 2020 13:07:08 +0200
    >> 
    >> unless youʼre talking about getting url to use 'torsocks' as a gateway
    >> method, which would require some coding.

    Eli> I think I did mean 'torsocks', but I'm way out of my depth here, so
    Eli> feel free to ignore me.

'torsocks' just does what I described up-thread: send network traffic
to the tor instance running on localhost:9050, which can already be
done using the emacs variables.

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Fri, 15 May 2020 13:49:23 +0200
> Cc: emacs-devel@gnu.org, eller.helmut@gmail.com, stefankangas@gmail.com,
>  rms@gnu.org, joaotavora@gmail.com
> 
>     Eli> I think I did mean 'torsocks', but I'm way out of my depth here, so
>     Eli> feel free to ignore me.
> 
> 'torsocks' just does what I described up-thread: send network traffic
> to the tor instance running on localhost:9050, which can already be
> done using the emacs variables.

Is that easy enough for users?  Maybe we should have a defcustom that
would set that up?

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

[Robert Pluim]

>>>>> On Fri, 15 May 2020 14:58:43 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Fri, 15 May 2020 13:49:23 +0200
    >> Cc: emacs-devel@gnu.org, eller.helmut@gmail.com, stefankangas@gmail.com,
    >> rms@gnu.org, joaotavora@gmail.com
    >> 
    Eli> I think I did mean 'torsocks', but I'm way out of my depth here, so
    Eli> feel free to ignore me.
    >> 
    >> 'torsocks' just does what I described up-thread: send network traffic
    >> to the tor instance running on localhost:9050, which can already be
    >> done using the emacs variables.

    Eli> Is that easy enough for users?  Maybe we should have a defcustom that
    Eli> would set that up?

To replace the two that we have already? People who want to do this
tend to be very technically capable, I donʼt see the need.

Robert

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

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org,  eller.helmut@gmail.com,  stefankangas@gmail.com,
>   rms@gnu.org,  joaotavora@gmail.com
> Date: Fri, 15 May 2020 14:14:02 +0200
> 
>     Eli> Is that easy enough for users?  Maybe we should have a defcustom that
>     Eli> would set that up?
> 
> To replace the two that we have already?

No, to arrange those two to be set to those particular values.

> People who want to do this tend to be very technically capable, I
> donʼt see the need.

Let's see what Richard has to say about this, he is the user who'd
need to make these customizations for his use case.

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

[Stefan Monnier]

> To replace the two that we have already? People who want to do this
> tend to be very technically capable, I donʼt see the need.

There's an argument to be made that "we" should encourage the use of Tor
(tho this "we" isn't specifically "we, the Free Software community" but it's
a community with a non-negligible overlap).


        Stefan

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

[Robert Pluim]

>>>>> On Fri, 15 May 2020 11:22:23 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> To replace the two that we have already? People who want to do this
    >> tend to be very technically capable, I donʼt see the need.

    Stefan> There's an argument to be made that "we" should encourage the use of Tor
    Stefan> (tho this "we" isn't specifically "we, the Free Software community" but it's
    Stefan> a community with a non-negligible overlap).

Thatʼs a separate argument, but it pleads more for us to document how
to do this than to write code.

Robert

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

  > unless youʼre talking about getting url to use 'torsocks' as a gateway
  > method, which would require some coding.

If it supports 'socks' as a gateway method, supporting 'tor' as a
gateway method should be easy -- just translate it into 'socks' with the
suitable socks port.
-- 
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?

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

  >     Richard> The built-in Emacs renderer gives ok results when the links don't matter.
  >     Richard> For links, the way it tries to follow them is useless since it doesn't
  >     Richard> go through Tor.
   
  > The url library used by eww/shr supports SOCKS, and Tor can be run as
  > a SOCKS proxy.

The issue is even more complex.  There are TWO ways I visit web pages
from Emacs, neither of which is eww.  I want to be able to choose
which way to use each time.

Doing that manually is easy enough -- if I can SEE the URL in the
buffer.  So I use lynx -dump to render the HTML, and it shows the URLs
of the links at the end.  Then I can do what I want to do.

The built-in Emacs renderer (is that eww?) doesn't show me the URLs,
which means I have no way to follow those links in either of the ways
I want to use.  Therefore, I need to hide the eww rendering and render
with lynx.

I would appreciate being able to specify "use lynx -dump to render HTML
from my incoming emails."  lynx -dump instead of eww that is.

Also helpful would be a way to customize how to follow a link in eww
rendering, which would let me write Lisp code to do one or the other
of the things I want to do.  Then maybe I would like eww as much as
lynx -dump.

But I would also want to be able to grab the URL into the kill buffer.
Could eww include those URLs in the rendered text?

I would guess lynx -dump is faster too, but I don't know for
certain.

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

[Andreas Schwab]

On Mai 16 2020, Richard Stallman wrote:

> The built-in Emacs renderer (is that eww?) doesn't show me the URLs,

Yes, it does.  If you tab to an anchor, the URL is shown in the echo
area.  You can even edit the URL before following.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Yuri Khan]

On Sat, 16 May 2020 at 13:51, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > The built-in Emacs renderer (is that eww?) doesn't show me the URLs,
>
> Yes, it does.  If you tab to an anchor, the URL is shown in the echo
> area.  You can even edit the URL before following.

Moreover, when point is on a link, pressing ‘u’ or ‘w’ in eww
(shr-maybe-probe-and-copy-url) will copy the URL to the kill ring.
Also, if you know that URL to be a redirect, pressing ‘u’ or ‘w’ again
will resolve it and copy the resolved destination URL.

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

  > Yes, it does.  If you tab to an anchor, the URL is shown in the echo
  > area.  You can even edit the URL before following.

I never had any idea of that.  Perhaps I never tried using TAB in those
buffers.  Thanks.

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

[Dmitry Gutov]

On 12.05.2020 15:30, Helmut Eller wrote:
> 2. Being able to display HTML/CSS/SVG the way mainstream web-browsers
> display would be nice.  But probably too big a project.  And in the long
> run, probably a reason for Emacs to go extinct.

Extinct, or just "not fully suitable as an OS replacement"? :)

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

[Christopher Lemmer Webber]

ndame writes:

> There is a discussion on Reddit about sponsoring development of
> multithreading in Emacs, and people there say it's too hard, takes a
> lot of time and it doesn't even bring that much benefit to the user.
>
> If this is the case (is it?) then what are those other features which
> could bring much more tangible benefits for the user and assuming
> somebody works on them full time sponsored by the community they can
> be implemented in, say, a few months?

I guess there are really two potential directions to think about it:

 - What is the most potentially useful direction for newcomers who are
   familiar with other mainstream UI patterns?
 - What is the most potentially useful project for existing everyday
   emacs users?

I think these are two separate things to solve.  IMO the former is more
important than the latter right now because Emacs has a way of making
users capable of extending it... it is one of the most beautiful things
about the choice of lisp as its configuration system.

So the real question to me would be: how do we lower the barrier to
entry?  There's been a lot of discussion on this, and I think the
most promising direction to me so far has been seeing the wild success
of Spacemacs as a "starter pack" that comes preconfigured in a way that
it feels familiar to Vim users.

These days most programmers start off in neither Vi(m) nor Emacs, they
start out with UI patterns that solidified after those programs were
made.  My suspicion is that a Spacemacs-like "starter pack" would solve
a lot of this, but it's work that's hard to motivate... once most
developers are far enough down the Emacs rabbit hole, doing this work
really doesn't do much to scratch their own itch.

Thus if there's a space for paid work, I think it would be to do this
work which might not be as directly useful to the developer, but would
be directly useful to other newcomers.  It would be useful and important
IMO to directly test against newcomers' experiences and collect feedback.

(The more difficult question to me would be: do the training wheels ever
come off the bike?  Or is it just a "different UI pattern" at that point
that one comes to accept and use emacs in that way?)

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

[Karl Fogel]

On 12 May 2020, Christopher Lemmer Webber wrote:
>ndame writes:
>
>> There is a discussion on Reddit about sponsoring development of
>> multithreading in Emacs, and people there say it's too hard, takes a
>> lot of time and it doesn't even bring that much benefit to the user.
>>
>> If this is the case (is it?) then what are those other features which
>> could bring much more tangible benefits for the user and assuming
>> somebody works on them full time sponsored by the community they can
>> be implemented in, say, a few months?
>
>I guess there are really two potential directions to think about it:
>
> - What is the most potentially useful direction for newcomers who are
>   familiar with other mainstream UI patterns?
> - What is the most potentially useful project for existing everyday
>   emacs users?
>
>I think these are two separate things to solve.  IMO the former is more
>important than the latter right now because Emacs has a way of making
>users capable of extending it... it is one of the most beautiful things
>about the choice of lisp as its configuration system.
>
>So the real question to me would be: how do we lower the barrier to
>entry?  [...]
>
>Thus if there's a space for paid work, I think it would be to do this
>work which might not be as directly useful to the developer, but would
>be directly useful to other newcomers.  It would be useful and important
>IMO to directly test against newcomers' experiences and collect feedback.

FWIW -- and perhaps to your surprise -- I would argue that this is *not* the important question for Emacs.

I've explained why in another thread:

  https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01855.html

  From: Karl Fogel <kfogel@red-bean.com>
  To: Emacs Devel
  Subject: Re: GNU Emacs raison d'etre
  Date: Wed, 13 May 2020 11:18:50 -0500
  Message-ID: <871rnnvmdx.fsf@red-bean.com>

Best regards,
-Karl

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

[Christopher Lemmer Webber]

Karl Fogel writes:

> On 12 May 2020, Christopher Lemmer Webber wrote:
>
>>Thus if there's a space for paid work, I think it would be to do this
>>work which might not be as directly useful to the developer, but would
>>be directly useful to other newcomers.  It would be useful and important
>>IMO to directly test against newcomers' experiences and collect feedback.
>
> FWIW -- and perhaps to your surprise -- I would argue that this is *not* the important question for Emacs.
>
> I've explained why in another thread:
>
>   https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01855.html

Hi Karl, nice to hear you reply to me :)

I agree with a lot of your assessments, that the highest value in Emacs
is the willingness to invest in it.  A well customized emacs conforms to
the shape of one's body and mind.  And I agree then that this is a
selling point to advertise.

I still don't think that's in contradiction to the "conventional editor
starter pack" goal though.  I know people who are tantalized by the
*idea* of learning Emacs, but get an enormous amount of imposter
syndrome and feeling of being overwhelmed when dipping their toes in the
water... some have tried dipping their toes in the water a few times.

Me personally, once I decided to learn emacs I just jumped straight into
the deep end.  But that's not for everyone.  Sometimes it can be nice to
have a wading area in the swimming pool for some folks.

That's my feeling, anyway.
 - Chris

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

[Karl Fogel]

On 13 May 2020, Christopher Lemmer Webber wrote:
>Hi Karl, nice to hear you reply to me :)

I don't (can't) read every post to this list, but I always read yours :-).

>I agree with a lot of your assessments, that the highest value in Emacs
>is the willingness to invest in it.  A well customized emacs conforms to
>the shape of one's body and mind.  And I agree then that this is a
>selling point to advertise.
>
>I still don't think that's in contradiction to the "conventional editor
>starter pack" goal though.  I know people who are tantalized by the
>*idea* of learning Emacs, but get an enormous amount of imposter
>syndrome and feeling of being overwhelmed when dipping their toes in the
>water... some have tried dipping their toes in the water a few times.
>
>Me personally, once I decided to learn emacs I just jumped straight into
>the deep end.  But that's not for everyone.  Sometimes it can be nice to
>have a wading area in the swimming pool for some folks.

I believe those goals *are* somewhat in tension, though.  I've taught Emacs to a fair number of people, sometimes successfully and sometimes not.  One thing that I recall every newcomer experiencing is, at least initially, the feeling that Emacs was constantly biting them -- constantly surprising them with unexpected and confusing behaviors that jump out from accidental keystrokes.  Two of the first things I always have to teach newcomers are `C-g' and `C-h l' :-).

Here's a concrete example I've seen over and over:

User does `C-x C-f' to find a file, but they hit Return at the wrong moment while typing the file path, causing a Dired buffer comes up visiting the file's directory.  The user is, of course, totally baffled by this result.  And yet it's obvious why this is a good default behavior for `find-file' -- for people who understand what's going on.

If the proposed starter pack is going to mitigate effects like that for newcomers, it can only do so by making the keybound functionality space sparser -- which of course then lowers the reward-for-investment rate as the user gains expertise.  How do you propose solving that?  Do we make an explicit "I'm ready to leave newcomer mode now" command?  But that requires the user to make a guess about the moment of their graduation from newcomer to non-newcomer -- and this moment is mythical, since the learning is a continuous process with no discrete boundary.

Changes that make Emacs better for newcomers *without* reducing the reward-for-investment rate are great, and I'm in favor of them like everyone else is.  No one would object to them; therefore they are not the subject of any disagreement.  I do think those changes are harder to find than you think they are.

Really I'm just suggesting a general framework for thinking about what Emacs's goals should be.  If we just say "Emacs should be easier for newcomers to learn", that's not a useful rallying cry IMHO.  If we say instead "Emacs should try to attract newcomers who have a higher-than-average probability of becoming high-investment users, and should explain early on to those newcomers what the road ahead looks like", *then* we have a high-level guiding principle we can actually use.

Best regards,
-Karl

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

[Robert Pluim]

>>>>> On Wed, 13 May 2020 23:08:04 -0500, Karl Fogel <kfogel@red-bean.com> said:
    Karl> Here's a concrete example I've seen over and over:

    Karl> User does `C-x C-f' to find a file, but they hit Return at the wrong
    Karl> moment while typing the file path, causing a Dired buffer comes up
    Karl> visiting the file's directory.  The user is, of course, totally
    Karl> baffled by this result.  And yet it's obvious why this is a good
    Karl> default behavior for `find-file' -- for people who understand what's
    Karl> going on.

Are you proposing "you appear to be visiting a directory, would you
like to enable dired? [yes/no/once]"? That would be massively
annoying, but only once per feature, so I could live with it. Or we
could add an 'emacs-expert-user' variable (or should that be
'expert-emacs-user'? :-) ).

    Karl> If the proposed starter pack is going to mitigate effects like that
    Karl> for newcomers, it can only do so by making the keybound functionality
    Karl> space sparser -- which of course then lowers the reward-for-investment
    Karl> rate as the user gains expertise.  How do you propose solving that?
    Karl> Do we make an explicit "I'm ready to leave newcomer mode now" command?
    Karl> But that requires the user to make a guess about the moment of their
    Karl> graduation from newcomer to non-newcomer -- and this moment is
    Karl> mythical, since the learning is a continuous process with no discrete
    Karl> boundary.

disabled commands already offer this, no?

Robert

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

[Christopher Lemmer Webber]

Karl Fogel writes:

> If the proposed starter pack is going to mitigate effects like that
> for newcomers, it can only do so by making the keybound functionality
> space sparser -- which of course then lowers the reward-for-investment
> rate as the user gains expertise.  How do you propose solving that?
> Do we make an explicit "I'm ready to leave newcomer mode now" command?
> But that requires the user to make a guess about the moment of their
> graduation from newcomer to non-newcomer -- and this moment is
> mythical, since the learning is a continuous process with no discrete
> boundary.

I've talked about this with a friend who is a prominent Blender user;
the program Blender has a similar issue where it has a perceived amount
of UI complexity; a lot of it also because things were foreign.  (It
also has not quite as much but a similar-ish level of extensibility.)

Users for years complained that the program is inaccessible.  Apparently
they did go through many UI improvements and eventually the UI did get
much easier to use (last time I opened it up though, since my experience
was from much older versions, *I* was confused... eg they switched the
order of right and left mouse buttons to be what other programs do).

For years, many of the suggestions for improving it though were around
changing or removing features.  It seems that recently they have made
many changes and managed to not remove features... I wonder how they did
it?  New users seem to be increasingly happy with the changes.  But of
course, some still complain that it's "too complicated", but a certain
amount of this is a domain problem: Blender chooses to be a powerful 3d
tool, and to a certain degree there will always be a certain amount of
overwhelmingness to it that's unavoidable.  Notably, this is also true
with the command line, which is also something that many have to become
convinced to become unafraid of.

Here are two lessons that I've thought about since those Blender
conversations though:

 - One thought is: you can change the defaults to be not what the
   current group is familiar with, but what matches the
   mainstream... and do compatibility in the *opposite* direction.  What
   if instead of turning on cua-mode, you turn on legacy-mode?

   I know this won't be a popular choice here, but it's worth proposing.
   When I opened Blender again, I reversed the mouse buttons because it
   was more "what I was used to from the old days" since Blender (like
   Emacs) made some convention decisions before there was a "mainstream
   choice".  But I could set it back.

   Notably this happened in a small way in emacs already: the scrollbars
   moved from the left to the right by default.  Well!  I rebound them
   back.  But I'm glad they're in the right by default now: that's the
   right decision.

   Still, this is maybe a harder sell for eg many of Emacs' keybindings,
   and the history list is very long on things like "kill"... I suspect
   the current community would be up in arms too much to accept such
   change.  But it's worth proposing the complete alternative.

   Let's not forget: some ideas in emacs are the way they are because
   they're more powerful.  Some of them are the way they are because
   Emacs predates modern UIs.  Maybe the result for what we choose to
   (not) do is the same.  But we shouldn't forget that these are
   (sometimes, not always) two different things.

 - An alternate line of thinking mentioned by my friend, frustrated by
   the calls to "streamline Blender", was to bring up a talk or paper or
   something they heard about Super Mario Bros being an excellent first
   UI: the game has a significant amount of complexity, but that
   complexity is *gradually introduced to the player*, and in an
   intuitive way.

   I don't know what talk or paper or article they were talking about,
   but this article has some degree of summary:

     https://medium.com/swlh/the-perfect-game-tutorial-analyzing-super-marios-level-design-92f08c28bdf7

   You enter the world, you find out you can move to the right.  But you
   keep moving to the right, you run into your first enemy and die.

   You discover jump.  You try to jump, you accidentally hit this block
   above you, it does something interesting.

   You get far enough along in the level, you've absorbed those patterns
   already... so now you get to encounter new challenges.

   Eventually new game elements being introduced becomes more rare, and
   instead you reach the level of combinatorial introduction of elements
   together.

What I like about the latter approach is it doesn't suggest needing to
switch between a binary transition point of "beginner mode" and "expert
mode".  Instead, you have a gradual "just in time" introduction of
complexity.

Now, how to map that to Emacs?  I'm not sure yet... but maybe it's a
perspective worth starting from that allows for easing in newcomers
without throwing out expressive power.

Or maybe I just play too many video games, and that's why I appreciate
the analogy. :)

 - Chris

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

[Dmitry Gutov]

On 14.05.2020 19:35, Christopher Lemmer Webber wrote:
>   - An alternate line of thinking mentioned by my friend, frustrated by
>     the calls to "streamline Blender", was to bring up a talk or paper or
>     something they heard about Super Mario Bros being an excellent first
>     UI: the game has a significant amount of complexity, but that
>     complexity is*gradually introduced to the player*, and in an
>     intuitive way.

I don't know if we can honestly say that Super Mario Bros is a complex 
game, but the principle can probably be applied everywhere to some degree.

For Emacs, it could probably be used to create some tutorial with 
gradually ramping up the complexity of tasks.

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

  > For Emacs, it could probably be used to create some tutorial with 
  > gradually ramping up the complexity of tasks.

If someone gets an inspiration for this, please give it a try.

Perhaps a game in which you try to correct a text
faster than a robotic ooponent can mess it up?
-- 
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?

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

  > User does `C-x C-f' to find a file, but they hit Return at the
  > wrong moment while typing the file path, causing a Dired buffer
  > comes up visiting the file's directory.  The user is, of course,
  > totally baffled by this result.  And yet it's obvious why this is
  > a good default behavior for `find-file' -- for people who
  > understand what's going on.

This is a useful observation.  How can we arrange to inform users
about this at the right time?

One idea: the first time a user tries to specify a directory in find-file,
display a help screen to explain what that means, and describe a few
usual ways out.

Do you think this would ameliorate the problem?

Any other ideas?

    > If we just say "Emacs should be easier for newcomers to learn",
    > that's not a useful rallying cry IMHO.

I think it can have a practical benefit -- if it motivates people to
observe beginners' stumbling blocks as you have done, and then to study
how to help beginners cope with them.

What other frequent points of confusion have you observed?

It could be useful to make a list of those, and we could
try to work on each of them over time.

  > If we say instead "Emacs should try to attract newcomers who have
  > a higher-than-average probability of becoming high-investment
  > users, and should explain early on to those newcomers what the
  > road ahead looks like"

We should do that, but not by exaggerating.

-- 
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 14 May 2020, Richard Stallman wrote:
>  > User does `C-x C-f' to find a file, but they hit Return at the
>  > wrong moment while typing the file path, causing a Dired buffer
>  > comes up visiting the file's directory.  The user is, of course,
>  > totally baffled by this result.  And yet it's obvious why this is
>  > a good default behavior for `find-file' -- for people who
>  > understand what's going on.
>
>This is a useful observation.  How can we arrange to inform users
>about this at the right time?
>
>One idea: the first time a user tries to specify a directory in find-file,
>display a help screen to explain what that means, and describe a few
>usual ways out.
>
>Do you think this would ameliorate the problem?

My guess is it would ameliorate the problem for some users, and scare off other ones (ones who are less patient, or, put another way, who are less willing to invest time in reading an explanatory screen like that to figure out what just happened).

>    > If we just say "Emacs should be easier for newcomers to learn",
>    > that's not a useful rallying cry IMHO.
>
>I think it can have a practical benefit -- if it motivates people to
>observe beginners' stumbling blocks as you have done, and then to study
>how to help beginners cope with them.

The danger I am worried about is a change that simultaneously makes Emacs *more* approachable for the type of newcomer who isn't inclined toward investment but *less* rewarding to the type of user who is.  When we face that tradeoff, let's optimize for the second kind of user.

Obviously, changes that give the former benefit while not incurring the latter cost are non-controversial and we should all be in favor of them.  (How hard they may be to implement is a separate question.)

>What other frequent points of confusion have you observed?

Well, there are a bunch; the next time I'm helping a newbie I'll try to watch and keep a list.  I think I've posted the main ones that I can easily recall.

None of this is a criticism of Emacs, by the way.  The Atom editor, for example, seems to be a lot friendlier for newcomers, at least when I watch them use Atom.  On the other hand, I have yet to see anyone -- newcomer or experienced user -- using Atom to do text manipulation anywhere near as fast and fluently as an experienced Emacs user does.

One major source of these observations for me has been the regular Tuesday night in-person gatherings in Chicago at https://chihacknight.org/.  Unfortunately, those are not happening in person right now, of course, and no one knows when they will resume.  For the same reason, it will probably be a long time before I have a chance again to observe newcomers editing (in any editor) in person.

>It could be useful to make a list of those, and we could
>try to work on each of them over time.

Making such a list is not easy, but if I get a chance to do it I will.

>  > If we say instead "Emacs should try to attract newcomers who have
>  > a higher-than-average probability of becoming high-investment
>  > users, and should explain early on to those newcomers what the
>  > road ahead looks like"
>
>We should do that, but not by exaggerating.

As I reiterated in some other posts: I wasn't exaggerating.  Emacs is more daunting for newcomers than other editors, and its dauntingness is connected inextricably to its power -- to the path by which it rewards investment.

I believe that for most users, Emacs really only starts to pay off after more than a year of regular use.  By "pay off", I mean something quite specific: I mean reaching the point where one can, on average, accomplish one's tasks noticeably faster in Emacs than one could have in some other editor had one spent that year learning that other editor instead.  

This was my own experience, and it's what I've seen happen with others.  Now, I'm sure there are exceptions: if someone spends a few months *intensely* learning Emacs, especially with in-person help, they'll surely learn as much as some other person might have learned in a year or even more.  If I were to quit my job and practice piano all day long, I could get pretty good pretty fast too :-).  But I'm talking about the common case: of users who today are fluent Emacs users, I think (though based on anecdata) that most of them took more than a year to get to the point described above.

(I'm assuming vim is not the "other editor" in the above scenario, since vim too is extensible and very much oriented toward rewarding sustained investment -- and, no coincidence, fluent vim users do things at least as quickly as fluent Emacs users do, as far as I can tell.  I've sometimes heard that Microsoft Visual Studio Code can be the same way, but I've rarely had chances to observe experienced people using it, so I can't say.)

Best regards,
-Karl

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

[Stefan Monnier]

>>One idea: the first time a user tries to specify a directory in find-file,
>>display a help screen to explain what that means, and describe a few
>>usual ways out.
>>Do you think this would ameliorate the problem?
> My guess is it would ameliorate the problem for some users, and scare off
> other ones (ones who are less patient, or, put another way, who are less
> willing to invest time in reading an explanatory screen like that to figure
> out what just happened).

Maybe we could simply use the "confirm" mechanism.  I.e. don't put any
explanatory text, but just emit "[confirm]" and wait for a second RET,
just like we do when `C-x C-f` specifies a non-existing file.


        Stefan

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

[Karl Fogel]

On 28 May 2020, Stefan Monnier wrote:
>>>One idea: the first time a user tries to specify a directory in find-file,
>>>display a help screen to explain what that means, and describe a few
>>>usual ways out.
>>>Do you think this would ameliorate the problem?
>> My guess is it would ameliorate the problem for some users, and scare off
>> other ones (ones who are less patient, or, put another way, who are less
>> willing to invest time in reading an explanatory screen like that to figure
>> out what just happened).
>
>Maybe we could simply use the "confirm" mechanism.  I.e. don't put any
>explanatory text, but just emit "[confirm]" and wait for a second RET,
>just like we do when `C-x C-f` specifies a non-existing file.

It would only do this the first time a user does `find-file' on a directory?  Or would it be every time?

If it's every time, that punishes experienced users, who do `find-file' on directories deliberately and don't want an extra keystroke to get in the way.

If it's only the first time, then I think it has other disadvantages:

- It doesn't really help the new user know what's going on or what's about to happen.

- It mis-trains them to think that when they do `find-file' on a directory they'll be asked for confirmation, when actually that's only going to happen this one time.  (Or maybe they have to set some variable to get what we currently consider the "normal" behavior?  But that's adding even complexity.)

I admit that I'm basically using this as Yet Another Example of how newcomer-friendliness is inherently in tension with rewards-investors :-).  It's hard to make find-file-on-a-directory less surprising for newcomers without either reducing the feature's investability (that is, without reducing a persistent new user's ability to learn about it by digesting a surprise and comprehending it) or reducing the feature's utility to the experienced users who are already familiar with it.

So, IMHO, we should change nothing about Emacs's behavior here: I think `find-file' does the best thing it can do right now.

(However, maybe it would be good to cover this behavior, or at least warn about it, in the tutorial or in other new-user help documentation -- I haven't looked at that documentation in a long time, so I can't say for sure.)

Best regards,
-Karl

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

[Drew Adams]

> If it's every time, that punishes experienced users, who do `find-file'
> on directories deliberately and don't want an extra keystroke to get in
> the way.
> 
> If it's only the first time, then I think it has other disadvantages:
> 
> - It doesn't really help the new user know what's going on or what's
> about to happen.
> 
> - It mis-trains them to think that when they do `find-file' on a
> directory they'll be asked for confirmation, when actually that's only
> going to happen this one time.  (Or maybe they have to set some
> variable to get what we currently consider the "normal" behavior?  But
> that's adding even complexity.)
> 
> I admit that I'm basically using this as Yet Another Example of how
> newcomer-friendliness is inherently in tension with rewards-investors
> :-).  It's hard to make find-file-on-a-directory less surprising for
> newcomers without either reducing the feature's investability (that is,
> without reducing a persistent new user's ability to learn about it by
> digesting a surprise and comprehending it) or reducing the feature's
> utility to the experienced users who are already familiar with it.
> 
> So, IMHO, we should change nothing about Emacs's behavior here: I think
> `find-file' does the best thing it can do right now.
> 
> (However, maybe it would be good to cover this behavior, or at least
> warn about it, in the tutorial or in other new-user help documentation
> -- I haven't looked at that documentation in a long time, so I can't
> say for sure.)

+1, for everything.

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

[Dmitry Gutov]

On 28.05.2020 20:19, Karl Fogel wrote:
> It would only do this the first time a user does `find-file' on a directory?  Or would it be every time?

Someday, we could also turn on fido-mode by default. There, RET means 
enter a directory. And/or pick the first suggestion.

It's a decent behavior for long-times users as well, since C-j provides 
an override.

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

[Alan Third]

On Thu, May 28, 2020 at 09:45:28PM +0300, Dmitry Gutov wrote:
> On 28.05.2020 20:19, Karl Fogel wrote:
> > It would only do this the first time a user does `find-file' on a directory?  Or would it be every time?
> 
> Someday, we could also turn on fido-mode by default. There, RET means enter
> a directory. And/or pick the first suggestion.
> 
> It's a decent behavior for long-times users as well, since C-j provides an
> override.

This seems like a reasonable solution to me. Alternatively perhaps we
just need to sell C-x C-f as "open a file or directory" rather than
"find a file"?
-- 
Alan Third

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

[Stefan Monnier]

> This seems like a reasonable solution to me. Alternatively perhaps we
> just need to sell C-x C-f as "open a file or directory" rather than
> "find a file"?

A directory *is* a file.


        Stefan

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

[Alan Third]

On Thu, May 28, 2020 at 05:02:33PM -0400, Stefan Monnier wrote:
> > This seems like a reasonable solution to me. Alternatively perhaps we
> > just need to sell C-x C-f as "open a file or directory" rather than
> > "find a file"?
> 
> A directory *is* a file.

Well why are these damn newbies getting confused when they open a
directory? ;)
-- 
Alan Third

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

[andres.ramirez]

Hi.

>>>>> "Alan" == Alan Third <alan@idiocy.org> writes:

    Alan> On Thu, May 28, 2020 at 05:02:33PM -0400, Stefan Monnier
    Alan> wrote:
    >> > This seems like a reasonable solution to me. Alternatively
    >> perhaps we > just need to sell C-x C-f as "open a file or
    >> directory" rather than > "find a file"?
    >> 
    >> A directory *is* a file.

    Alan> Well why are these damn newbies getting confused when they
    Alan> open a directory? ;) -- Alan Third

Because on mainstream products (There is a distinction about file and
folder. But on Unix everything is a file).

Best Regards

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

[Stefan Monnier]

>> A directory *is* a file.
> Well why are these damn newbies getting confused when they open a
> directory? ;)

;-)


        Stefan

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

[Arthur Miller]

Alan Third <alan@idiocy.org> writes:

> On Thu, May 28, 2020 at 05:02:33PM -0400, Stefan Monnier wrote:
>> > This seems like a reasonable solution to me. Alternatively perhaps we
>> > just need to sell C-x C-f as "open a file or directory" rather than
>> > "find a file"?
>> 
>> A directory *is* a file.
>
> Well why are these damn newbies getting confused when they open a
> directory? ;)
n00bs! :-)

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

[Joost Kremers]

On Thu, May 28 2020, Stefan Monnier wrote:
>> This seems like a reasonable solution to me. Alternatively 
>> perhaps we
>> just need to sell C-x C-f as "open a file or directory" rather 
>> than
>> "find a file"?
>
> A directory *is* a file.

And a smart phone is a computer, but that's not how most people 
think about it. :-)

-- 
Joost Kremers
Life has its moments

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

[Arthur Miller]

Joost Kremers <joostkremers@fastmail.fm> writes:

> On Thu, May 28 2020, Stefan Monnier wrote:
>>> This seems like a reasonable solution to me. Alternatively perhaps we
>>> just need to sell C-x C-f as "open a file or directory" rather than
>>> "find a file"?
>>
>> A directory *is* a file.
>
> And a smart phone is a computer, but that's not how most people think about it.
> :-)

And Dired is "directory editor", wich suggest a directory is a  file,
but even I use to speak of dired (and emacs) as a file manager, and
other file managers are not called directory editors, despite of file
managing being directories editing. Just another example of how we
humnas build abstractions on top of each other to simplify our
reasoning. Those abstractions then get their own life.

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

[Karl Fogel]

On 28 May 2020, Stefan Monnier wrote:
>> This seems like a reasonable solution to me. Alternatively perhaps we
>> just need to sell C-x C-f as "open a file or directory" rather than
>> "find a file"?
>
>A directory *is* a file.

Not in a sense that's meaningful to most non-programmers.  Even many programmers don't naturally conceptualize directories as files -- especially those who have learned programming in the WWW era, since they haven't had to do much programming in which file<->directory unity matters.

If explanations of Emacs features start to depend on people having filesystem programming experience, that will narrow Emacs' audience quite a bit more than necessary :-).

Best regards,
-Karl

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

[Drew Adams]

> >A directory *is* a file.
> 
> Not in a sense that's meaningful to most non-programmers.  Even many
> programmers don't naturally conceptualize directories as files --
> especially those who have learned programming in the WWW era, since
> they haven't had to do much programming in which file<->directory unity
> matters.

Yes.

A directory is often _implemented_ using a file,
and files and dirs can be manipulated in many of
the same ways.

But it helps to let a user know when some operation
works for either one, as opposed to just one or the
other.  Creating a new directory isn't the same
thing as creating a new file.

And Emacs reflects this in its prompts and doc
strings.  Dired is just one example ("visit this
file or directory in another window").

And for users who are used to thinking in terms of
files and "folders" there's no conception at all
of a folder being a file, regardless of the
underlying implementation.

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

  > This seems like a reasonable solution to me. Alternatively perhaps we
  > just need to sell C-x C-f as "open a file or directory" rather than
  > "find a file"?

That would make our initial explanations more complex, and that might
lead to more confusion than clarity.

I think it is better to explain this wrinkle when the user encounters it,
not before.

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

[Drew Adams]

>> This seems like a reasonable solution to me. Alternatively perhaps
>> we just need to sell C-x C-f as "open a file or directory" rather
>> than "find a file"?
> 
> That would make our initial explanations more complex, and that might
> lead to more confusion than clarity.

I disagree.  It's clearer to state, when it's the case,
that a given operation acts on a file or a dir, or on
files and dirs.

We do that pretty consistently in Dired and some other
areas of Emacs.  We should do it wherever it makes
sense, and it makes sense wherever someone might not
understand that the operation applies to either/both.

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

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > This seems like a reasonable solution to me. Alternatively perhaps we
>   > just need to sell C-x C-f as "open a file or directory" rather than
>   > "find a file"?
>
> That would make our initial explanations more complex, and that might
> lead to more confusion than clarity.
>
> I think it is better to explain this wrinkle when the user encounters it,
> not before.

Aren't users encountering that wrinkle first time they open a file?

Observe there are even more wrinkles there to explain: if file does not
exist Emacs creates a new buffer, and if user ment a directory, the
buffer will still be just a plain file not a dir. And what about if
there are some non-existent directories on the way? Emacs asks if  user
wants them to be created ... so there are quite a few wrinkles in that
one, not the simplest behaviour to explain anyway :-).

I don't know how you reasoned back in days when find file was
introduced/created, but I guess, it was more Unixy, a dir is just a file
(everything in Unix is file), so it was assumed that dirs are just
files? I don't think millenials see dirs as just files, but I don't
know, I might be a bit prejudiced (right word?) here.

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

[Thibaut Verron]

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

Le ven. 29 mai 2020 à 15:20, Arthur Miller <arthur.miller@live.com> a
écrit :

> Richard Stallman <rms@gnu.org> writes:
>
> > [[[ 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. ]]]
> >
> >   > This seems like a reasonable solution to me. Alternatively perhaps we
> >   > just need to sell C-x C-f as "open a file or directory" rather than
> >   > "find a file"?
> >
> > That would make our initial explanations more complex, and that might
> > lead to more confusion than clarity.
> >
> > I think it is better to explain this wrinkle when the user encounters it,
> > not before.
>
> Aren't users encountering that wrinkle first time they open a file?
>
> Observe there are even more wrinkles there to explain: if file does not
> exist Emacs creates a new buffer, and if user ment a directory, the
> buffer will still be just a plain file not a dir. And what about if
> there are some non-existent directories on the way? Emacs asks if  user
> wants them to be created ... so there are quite a few wrinkles in that
> one, not the simplest behaviour to explain anyway :-).
>

But those are consistent with how other software behaves. The user won't
think of a buffer as much as of a not-yet-saved file, but that's also
consistent with what emacs does.

Other software would force the directory to be created before opening the
file, but that's minor I believe.

Being able to open a directory just like a file, on the other hand, is not
usual. Web browsers can do it, but that's because their "files" are almost
like directories.

I personally like the ido approach of having different keys for accessing
files and directories. Simple operations like listing files or creating a
new one are done directly in the ido buffer, no need for dired.

Thibaut

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

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

[Arthur Miller]

Alan Third <alan@idiocy.org> writes:

> On Thu, May 28, 2020 at 09:45:28PM +0300, Dmitry Gutov wrote:
>> On 28.05.2020 20:19, Karl Fogel wrote:
>> > It would only do this the first time a user does `find-file' on a directory?  Or would it be every time?
>> 
>> Someday, we could also turn on fido-mode by default. There, RET means enter
>> a directory. And/or pick the first suggestion.
>> 
>> It's a decent behavior for long-times users as well, since C-j provides an
>> override.
>
> This seems like a reasonable solution to me. Alternatively perhaps we
> just need to sell C-x C-f as "open a file or directory" rather than
> "find a file"?
I think you are spot on there. I don't think many people today think of
directories as just "files", so directory part of "find file" gets lost
for some. BTW, how about selling it as "Find file or directory"?

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

[ndame]

> what are those other features which could bring much more tangible benefits for the user

BTW, somebody on Reddit said "I would easily pay $10 a year to have someone dedicated to work on Emacs. Many of us have employers that I guess would be willing to pay a dime as well." and others agreed.

Emacs Reddit has 40k members and it may be goal with which many of its members can sympahtize.

Do you think it could help Emacs if it had someone working on it full time, checking bug reports, taking care of all the usual things, fixing bugs, etc. thereby lightening the load on maintainers and core developers, so they have more time for developing features?

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

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>> what are those other features which could bring much more tangible benefits for the user
>
> BTW, somebody on Reddit said "I would easily pay $10 a year to have someone
> dedicated to work on Emacs. Many of us have employers that I guess would be
> willing to pay a dime as well." and others agreed.
>
> Emacs Reddit has 40k members and it may be goal with which many of its members can sympahtize.
>
> Do you think it could help Emacs if it had someone working on it full time,
> checking bug reports, taking care of all the usual things, fixing bugs, etc.
> thereby lightening the load on maintainers and core developers, so they have
> more time for developing features?
I can't even imagine how much Emacs would evolve if Eli got full-time
payed jobb on Emacs .... 

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

[ndame]

>
> I can't even imagine how much Emacs would evolve if Eli got full-time
> payed jobb on Emacs ....

Well, let's ask him if he's interested. Eli?

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

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>>
>> I can't even imagine how much Emacs would evolve if Eli got full-time
>> payed jobb on Emacs ....
>
> Well, let's ask him if he's interested. Eli?
I would definitely pay $10 a year or halv if Eli would go full time on
Emacs :-).

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

[Eli Zaretskii]

> Date: Thu, 14 May 2020 04:10:50 +0000
> From: ndame <ndame@protonmail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> >
> > I can't even imagine how much Emacs would evolve if Eli got full-time
> > payed jobb on Emacs ....
> 
> Well, let's ask him if he's interested. Eli?

It is not a question of interest, not at my age and point in life.

Anyway, the above is unlikely to happen.

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

[ndame]

>
> It is not a question of interest, not at my age and point in life.
>
> Anyway, the above is unlikely to happen.

If by chance you know somebody who is qualified and could be interested in the job then please let him or her know about this possibility. Provided you think a full time developer could help Emacs development.  The core developers are in a better position to judge this.

Emacs development has an untapped potential in users who don't have the time or inclination to work on Emacs code, but they use Emacs a lot, so they are willing to donate for Emacs development. Most likely the vast majority of Emacs users are in this position, so the untapped potential is huge.

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

[Stefan Kangas]

ndame <ndame@protonmail.com> writes:

> If by chance you know somebody who is qualified and could be
> interested in the job then please let him or her know about this
> possibility. Provided you think a full time developer could help Emacs
> development.  The core developers are in a better position to judge
> this.

Maybe this is starting in the wrong end.

There is some serious work required to even get something like this
going.  Perhaps one should look for a candidate to do that work first.

Not that I have any clout to say much about anything, but here's what I
think:

Whoever is prepared to organize this will work on a volunteer basis.
This would be a task of great responsibility, so it has to be a
trustworthy person, possibly already on emacs-devel or prepared to
establish and maintain that communication.

Such a volunteer would start with writing up a serious proposal for how
to organize it.  This should involve some specifics about financing (at
least: how to collect donations), recruitment of candidates,
advertising, deliverables, time-frame, etc.  Probably many other things.

Next, you would need to be able to work patiently in discussion to
convince emacs-devel, Eli, RMS and others that this is a good idea.
Part of that work is convincing people that you are the candidate to see
this through.  Maybe the FSF needs to be discussed with and convinced
too.

And, finally, the correct candidate for that work would be prepared to
accept that, even having invested the above time, maybe it's not
feasible to get all the moving parts working together to realize this.

If someone is interested in doing that work, maybe this has a chance.
I don't see that it's a hard task, just one that would take some time,
dedication and organizing.

Just my two cents.

Best regards,
Stefan Kangas

PS. BTW, is there any reason Emacs is not already part of GSOC?

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

[Arthur Miller]

Stefan Kangas <stefankangas@gmail.com> writes:

> ndame <ndame@protonmail.com> writes:
>
>> If by chance you know somebody who is qualified and could be
>> interested in the job then please let him or her know about this
>> possibility. Provided you think a full time developer could help Emacs
>> development.  The core developers are in a better position to judge
>> this.
>
> Maybe this is starting in the wrong end.
>
> There is some serious work required to even get something like this
> going.  Perhaps one should look for a candidate to do that work first.
>
> Not that I have any clout to say much about anything, but here's what I
> think:
>
> Whoever is prepared to organize this will work on a volunteer basis.
> This would be a task of great responsibility, so it has to be a
> trustworthy person, possibly already on emacs-devel or prepared to
> establish and maintain that communication.
>
> Such a volunteer would start with writing up a serious proposal for how
> to organize it.  This should involve some specifics about financing (at
> least: how to collect donations), recruitment of candidates,
> advertising, deliverables, time-frame, etc.  Probably many other things.
>
> Next, you would need to be able to work patiently in discussion to
> convince emacs-devel, Eli, RMS and others that this is a good idea.
> Part of that work is convincing people that you are the candidate to see
> this through.  Maybe the FSF needs to be discussed with and convinced
> too.
>
> And, finally, the correct candidate for that work would be prepared to
> accept that, even having invested the above time, maybe it's not
> feasible to get all the moving parts working together to realize this.
>
> If someone is interested in doing that work, maybe this has a chance.
> I don't see that it's a hard task, just one that would take some time,
> dedication and organizing.
>
> Just my two cents.
>
> Best regards,
> Stefan Kangas
>
> PS. BTW, is there any reason Emacs is not already part of GSOC?

Could FSF control a crowd-sourcing fond that goes to development?

They could have something like a list of bugs/features, maybe have a
poll where public can vote for priority on that list, and announce a
prize money to those who turn in accepted patch. Does not even need to
be an Emacs specific fond, could be a list of bugs/features/improvements
in all GNU software. It could be open to anyone who is willing to send
in technically and legaly (FSF paperwork, licence and so on) acceptable
patch.

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

The FSF could set up a special fund for Emacs development.
It does that for other programs.

However, experience with other packages says that it probably
won't bring in enough money to pay a developer.  The other programs
use their funds for other, smaller expenses.

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

[chad]

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

On Sun, May 17, 2020 at 5:43 AM Stefan Kangas <stefankangas@gmail.com>
wrote:

> PS. BTW, is there any reason Emacs is not already part of GSOC?
>

GSOC projects to improve Emacs have happened in the past. IIUC, the main
hurdles are finding interesting projects that fit in the short timeline,
and finding mentors for such projects. For example, several years back
there were a couple GSOC projects to push guile&emacs integration:
https://www.gnu.org/software/guile/news/gsoc-guile-emacs-and-emacsy.html

Hope that helps,
~Chad

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

What is the most useful potential feature which Emacs lacks?

[Vasilij Schneidermann]

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

Namespaces for me.  The kind where I can write a new package without worrying
about prefixing anything, declare a public interface and later import the
package with an appropriate namespace prefix.  No more unnecessary namespace
pollution or pondering about the tradeoff between ergonomics and potential
namespace clashes.  Experimentation gets easier, say you'd want to have list
processing functions à la <insert favorite Lisp>.  You can now design such a
thing without forcing a clunky or misleading namespace prefix on everyone.  Or
imagine you'd want to replace or prototype a built-in facility.  Or you'd like
to use just one thing from a package.  All these things are now possible, at
the cost of `grep` becoming a less powerful tool.

Vasilij

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Björn Lindqvist]

I've long wanted GMail integration in Gnus. The IMAP interface just
doesn't work very well. I know it will never happen in a million years
because GMail is non-free software but one can wish. :)

Den mån 11 maj 2020 kl 22:10 skrev ndame <ndame@protonmail.com>:
>
> There is a discussion on Reddit about sponsoring development of multithreading in Emacs, and people there say it's too hard, takes a lot of time and it doesn't even bring that much benefit to the user.
>
> If this is the case (is it?) then what are those other features which could bring much more tangible benefits for the user and assuming somebody works on them full time sponsored by the community they can be implemented in, say,  a few months?



-- 
mvh/best regards Björn Lindqvist