Re: Making Emacs more friendly to newcomers

Re: Making Emacs more friendly to newcomers

[ndame]

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

> It is not that they are lazy, just like people who use a machine to do their
> laundry instead of doing it by hand, they use tools that have been developed
> without the historical constraints of Emacs.

The majority of developers don't like to mold their editor so much, like
hardcore emacs users mold emacs.

They may change the colors, the fonts, maybe some keybindings, but
that's it. They want an editor which looks pleasant and does most
things out of the box without additional tinkering.

VSCode does this well. It provides a great out of box experience, most
things work out of the box, or just a plugin install away. In case of
LSP it may also download and install an LSP server, not just a client.

Most developers want an experience like this where everything works
with minimal tinkering.

I don't think it's realistic for Emacs to compete with that. There are
the legal issues, for example, which I assume prevent installing
Non-GNU binaries from the net and not all LSP servers have GNU license
AFAIK.

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

Re: Making Emacs more friendly to newcomers

[Po Lu]

ndame <ndame@protonmail.com> writes:

> VSCode does this well. It provides a great out of box experience, most
> things work out of the box, or just a plugin install away. In case of
> LSP it may also download and install an LSP server, not just a client.

IIRC, lsp-mode has good support for automagically downloading popular
LSP servers.  Perhaps that could be added to eglot?

> I don't think it's realistic for Emacs to compete with that. There are
> the legal issues, for example, which I assume prevent installing
> Non-GNU binaries from the net and not all LSP servers have GNU license
> AFAIK.

There are legal issues with shipping code /with/ Emacs that has not been
copyright assigned to the FSF.  I don't think anyone would mind if a
package shipped with Emacs automatically downloaded and installed a
free language server. (and I haven't actually seen any non-free language
servers.)

If memory serves, someone proposed finding promising new packages and
asking the authors about including it inside Emacs (or ELPA).  I find
that would also be a nice idea.

Re: Making Emacs more friendly to newcomers

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

  >   I don't think anyone would mind if a
  > package shipped with Emacs automatically downloaded and installed a
  > free language server. (and I haven't actually seen any non-free language
  > servers.)

That approach to problem can have disadvantages.
In general, for the kind of packages that we would
like to include in Emacs, we should push for that kind of solution.

We should not treat "autoloaded from elsewhere" as equivalent to
"included".  Where something is distributed DOES make a difference.



-- 
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: Making Emacs more friendly to newcomers

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> That approach to problem can have disadvantages.
> In general, for the kind of packages that we would
> like to include in Emacs, we should push for that kind of solution.

Language servers are external programs, not "packages" that can be
bundled inside Emacs.  I personally don't find anything wrong if the
language server isn't non-free.

> We should not treat "autoloaded from elsewhere" as equivalent to
> "included".  Where something is distributed DOES make a difference.

I'm not disputing that, I'm just saying that I'm not sure we can include
every popular language server with Emacs.  A lot of competing editors
however have a nice interface for installing language servers from a
central source, and having that in Emacs would indeed be nice.

Re: Making Emacs more friendly to newcomers

[Theodor Thornhill]

"Po Lu" <luangruo@yahoo.com> writes:

> IIRC, lsp-mode has good support for automagically downloading popular
> LSP servers.  Perhaps that could be added to eglot?
>

I know that fsharp-mode already offers this integration with eglot. So
it is absolutely possible. However, there are some small things I see
which could be needed for this easier adoption for newcomers. I see some
of this has been disussed earlier, but anyhow:

1: VsCode offers on the home screen an option to click on what languages
you want to install support for. This offers a nice one-click shop for
language packs. This, I guess is the same behaviour that Doom/Spacemacs
offers with their layers etc. In Emacs we often have to install
lsp-client, lsp-server, language mode, company, adjust company backends.
It would be nice to have emacs install all of the above automatically
when clicking on Python, JS and such.

2: One bigger problem here is that VsCode attracts JS/TS-devs, and
tssnerver is really not lsp-compliant, or even an lsp-server at all. So
to get that behaviour you need you have to install
javascript-typescript-server OR typescript-language-server. The latter
seems to be the best, but it is now unmaintained. Also, support for JSX,
while improved a ton lately, is not there for TSX yet. To get proper
support for TSX you must use web-mode, but this in turn does not offer
keyword syntax highlighting for typescript. Also, "tide" is a separate
lsp implementation dealing only with js/typescript

3: Eglot has some shortcomings compared to lsp-mode. In example multi
server support, which is discussed here:
https://github.com/joaotavora/eglot/issues/423

This is needed yet again for better support of js/ts.

4: Eglot chooses to "take over" emacs' default behaviour, and I believe
this could be extended further to alleviate at least point number
one. If eglot were capable of installing company, lsp-servers and
file-extension-based language modes we are already there as for
one-click functionality. It even has an eglot-stay-out-of option for
configuration if more granular control is wanted.

              
The JS/TS story however is not solvable quickly it seems:
https://github.com/emacs-typescript/typescript.el/issues/4

Re: Making Emacs more friendly to newcomers

[Po Lu]

Theodor Thornhill <theothornhill@pm.me> writes:

> I know that fsharp-mode already offers this integration with eglot. So
> it is absolutely possible. However, there are some small things I see
> which could be needed for this easier adoption for newcomers. I see some
> of this has been disussed earlier, but anyhow:

Nice.  I was not aware of that before.

> 1: VsCode offers on the home screen an option to click on what languages
> you want to install support for. This offers a nice one-click shop for
> language packs. This, I guess is the same behaviour that Doom/Spacemacs
> offers with their layers etc. In Emacs we often have to install
> lsp-client, lsp-server, language mode, company, adjust company backends.
> It would be nice to have emacs install all of the above automatically
> when clicking on Python, JS and such.

Agreed.  Stefan has a proof-of-concept package named `gnu-elpa' that
does exactly this, and it would indeed be nice if Emacs had that.

> 2: One bigger problem here is that VsCode attracts JS/TS-devs, and
> tssnerver is really not lsp-compliant, or even an lsp-server at all. So
> to get that behaviour you need you have to install
> javascript-typescript-server OR typescript-language-server.
> The latter seems to be the best, but it is now unmaintained. Also, support for JSX,
> while improved a ton lately, is not there for TSX yet. To get proper
> support for TSX you must use web-mode, but this in turn does not offer
> keyword syntax highlighting for typescript. Also, "tide" is a separate
> lsp implementation dealing only with js/typescript

IIRC, Tide uses tsserver, and people say it works quite well.  I also
recall some interesting discussions related to multiple major modes in
2016, that came up with some interesting ideas.

> 3: Eglot has some shortcomings compared to lsp-mode. In example multi
> server support, which is discussed here:
> https://github.com/joaotavora/eglot/issues/423

Yeah, but so far Eglot seems to be the only package that has copyright
assigned to the FSF, which means discussion around Emacs and LSP should
focus on improving Eglot.

> 4: Eglot chooses to "take over" emacs' default behaviour, and I believe
> this could be extended further to alleviate at least point number
> one. If eglot were capable of installing company, lsp-servers and
> file-extension-based language modes we are already there as for
> one-click functionality. It even has an eglot-stay-out-of option for
> configuration if more granular control is wanted.

As for company, I think that's not something for Eglot to do, but
automatically installing language servers is something we need.

Re: Making Emacs more friendly to newcomers

[Theodor Thornhill]

"Po Lu" <luangruo@yahoo.com> writes:

>
> Agreed.  Stefan has a proof-of-concept package named `gnu-elpa' that
> does exactly this, and it would indeed be nice if Emacs had that.
>
  
Nice!
  
>
> IIRC, Tide uses tsserver, and people say it works quite well.  I also
> recall some interesting discussions related to multiple major modes in
> 2016, that came up with some interesting ideas.
>

That's correct. Tide is nice. I just wanted to shed some light on some
issues newcomers could have when considering emacs for web dev. Based on
the assumption that web devs are the main user group coming from vs
code. (Which I know is of course not quite true :) )

>
> Yeah, but so far Eglot seems to be the only package that has copyright
> assigned to the FSF, which means discussion around Emacs and LSP should
> focus on improving Eglot.
>

Agreed!

>
> As for company, I think that's not something for Eglot to do, but
> automatically installing language servers is something we need.

Yeah. However, there is one thing with this approach. I took a look at
the eglot-fsharp.el (part of fsharp-mode, which is GPL v3
btw). Downloading of the particular server seems to be almost no issue
at all. Configuring servers, though, is an issue. Should it be eglots
responsibility to do that, or individual language modes? Consider at
some point in the future, when Eglot is as integrated with emacs as say,
syntax highlighting or indenting - should *-mode.el configure its own
lsp config? I'm just a little bit concerned this will cause maintainers
of third party lang-modes not to really care. At least if lsp-mode
already provides lsp-*.el preconfigured anyways.
        
Theo        

Re: Making Emacs more friendly to newcomers

[Po Lu]

Theodor Thornhill <theothornhill@pm.me> writes:

> Yeah. However, there is one thing with this approach. I took a look at
> the eglot-fsharp.el (part of fsharp-mode, which is GPL v3
> btw). Downloading of the particular server seems to be almost no issue
> at all. Configuring servers, though, is an issue. Should it be eglots
> responsibility to do that, or individual language modes? Consider at
> some point in the future, when Eglot is as integrated with emacs as say,
> syntax highlighting or indenting - should *-mode.el configure its own
> lsp config? I'm just a little bit concerned this will cause maintainers
> of third party lang-modes not to really care. At least if lsp-mode
> already provides lsp-*.el preconfigured anyways.

Yeah, perhaps we could have a centralized database of language servers
and their configurations for Eglot?  That would be nice.

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

>> 1: VsCode offers on the home screen an option to click on what languages
>> you want to install support for. This offers a nice one-click shop for
>> language packs. This, I guess is the same behaviour that Doom/Spacemacs
>> offers with their layers etc. In Emacs we often have to install
>> lsp-client, lsp-server, language mode, company, adjust company backends.
>> It would be nice to have emacs install all of the above automatically
>> when clicking on Python, JS and such.
>
> Agreed.  Stefan has a proof-of-concept package named `gnu-elpa' that
> does exactly this, and it would indeed be nice if Emacs had that.

Hmm... no I don't have something that does exactly that.
It goes a bit in that direction, and I hope it can grow further, but
currently it doesn't do much more than prompt you to install GNU ELPA
packages which you attempt to use their features, so it doesn't prompt
users to install lsp servers or to enable company, ...


        Stefan

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 19:45, Stefan Monnier wrote:
>>> 1: VsCode offers on the home screen an option to click on what languages
>>> you want to install support for. This offers a nice one-click shop for
>>> language packs. This, I guess is the same behaviour that Doom/Spacemacs
>>> offers with their layers etc. In Emacs we often have to install
>>> lsp-client, lsp-server, language mode, company, adjust company backends.
>>> It would be nice to have emacs install all of the above automatically
>>> when clicking on Python, JS and such.
>> Agreed.  Stefan has a proof-of-concept package named `gnu-elpa' that
>> does exactly this, and it would indeed be nice if Emacs had that.
> Hmm... no I don't have something that does exactly that.
> It goes a bit in that direction, and I hope it can grow further, but
> currently it doesn't do much more than prompt you to install GNU ELPA
> packages which you attempt to use their features, so it doesn't prompt
> users to install lsp servers or to enable company, ...

I'm not sure it would be right to enable an opinionated behavior like 
that for all users anyway. After all, LSP servers are not the only 
company backends that people use, and there are other completion UIs 
than company.

On the other hand, it would be great to have a short official guide that 
outlines the easiest way to get the "smarts" that people expect from 
code editors. One that's preferably closer to the Tutorial in 
accessibility, rather than the manual.

Posting it on the official website would help as well. This way we would 
make a pledge, of sorts, that *this* approach is supposed to work for 
everybody.

Re: Making Emacs more friendly to newcomers

[Po Lu]

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

> Hmm... no I don't have something that does exactly that.
> It goes a bit in that direction, and I hope it can grow further, but
> currently it doesn't do much more than prompt you to install GNU ELPA
> packages which you attempt to use their features, so it doesn't prompt
> users to install lsp servers or to enable company, ...

I was specifically talking about ELPA packages.

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

>> Hmm... no I don't have something that does exactly that.
>> It goes a bit in that direction, and I hope it can grow further, but
>> currently it doesn't do much more than prompt you to install GNU ELPA
>> packages which you attempt to use their features, so it doesn't prompt
>> users to install lsp servers or to enable company, ...
> I was specifically talking about ELPA packages.

Even for packages, e.g. `gnu-elpa` will suggest you install the
`company` package when you call `company-mode` but it won't make
a suggestion to enable `company-mode`.

IOW, it tries to pretend that GNU ELPA packages are pre-installed, but
not that they are pre-enabled.


        Stefan

Re: Making Emacs more friendly to newcomers

[Po Lu]

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

> Even for packages, e.g. `gnu-elpa` will suggest you install the
> `company` package when you call `company-mode` but it won't make
> a suggestion to enable `company-mode`.

Hmm, I suppose I misunderstood your message then.
Thanks for clearing it up.

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

> On Apr 22, 2020, at 12:45 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>> 1: VsCode offers on the home screen an option to click on what languages
>>> you want to install support for. This offers a nice one-click shop for
>>> language packs. This, I guess is the same behaviour that Doom/Spacemacs
>>> offers with their layers etc. In Emacs we often have to install
>>> lsp-client, lsp-server, language mode, company, adjust company backends.
>>> It would be nice to have emacs install all of the above automatically
>>> when clicking on Python, JS and such.
>> 
>> Agreed.  Stefan has a proof-of-concept package named `gnu-elpa' that
>> does exactly this, and it would indeed be nice if Emacs had that.
> 
> Hmm... no I don't have something that does exactly that.
> It goes a bit in that direction, and I hope it can grow further, but
> currently it doesn't do much more than prompt you to install GNU ELPA
> packages which you attempt to use their features, so it doesn't prompt
> users to install lsp servers or to enable company, ...
> 
> 
>        Stefan
> 

BTW, where can I find this package?

Yuan

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

> BTW, where can I find this package?

I now just pushed the code I have to elpa.git.
[ It's still at "Version: 0", so it isn't yet available as a GNU
  ELPA package. tho.  ]


        Stefan

Re: Making Emacs more friendly to newcomers

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

  > IIRC, Tide uses tsserver, and people say it works quite well.

What kind of thing is tsserver?  The word "server" has multiple meanings;
in what sense is tsserver a "server"?

Would it run on the same machine you are editing on, or another machine?

-- 
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: Making Emacs more friendly to newcomers

[조성빈]

Richard Stallman <rms@gnu.org> 작성:

> [[[ 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. ]]]
>
>> IIRC, Tide uses tsserver, and people say it works quite well.
>
> What kind of thing is tsserver?  The word "server" has multiple meanings;
> in what sense is tsserver a "server"?

It’s a LSP server that responds requests from editors with information about
types of identifiers, code completion, actions, etc...

> Would it run on the same machine you are editing on, or another machine?

It usually runs on the same machine that the codebase exists.

> -- 
> 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: Making Emacs more friendly to newcomers

[조성빈]

조성빈 <pcr910303@icloud.com> 작성:

> Richard Stallman <rms@gnu.org> 작성:
>
>> [[[ 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. ]]]
>>
>>> IIRC, Tide uses tsserver, and people say it works quite well.
>>
>> What kind of thing is tsserver?  The word "server" has multiple meanings;
>> in what sense is tsserver a "server"?
>
> It’s a LSP server that responds requests from editors with information  
> about
> types of identifiers, code completion, actions, etc...

Oops, forgot to mention the language. It’s a TypeScript[0] LSP server.

[0] https://www.typescriptlang.org

>> Would it run on the same machine you are editing on, or another machine?
>
> It usually runs on the same machine that the codebase exists.
>
>> -- 
>> 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: Making Emacs more friendly to newcomers

[Theodor Thornhill]

조성빈 <pcr910303@icloud.com> writes:

> Richard Stallman <rms@gnu.org> 작성:
>
>> What kind of thing is tsserver?  The word "server" has multiple meanings;
>> in what sense is tsserver a "server"?
>
> It’s a LSP server that responds requests from editors with information about
> types of identifiers, code completion, actions, etc...
>

Actually, tsserver is not an lsp-server, which is currently adding to
the confusion:
https://github.com/Microsoft/TypeScript/issues/11274

This is kind of a problem, since VsCode implements its own proprietary
server for JavaScript/TypeScript, and also functions as a normal
lsp-compliant editor. Assuming most people use VsCode for web-dev there
is actually a huge user base which is not actively using lsp. This
complicates lsp-development for other editors like emacs and vim. We
have to use either a wrapper server that wraps tsserver to be
lsp-compliant (https://github.com/theia-ide/typescript-language-server)
or create our own tsserver compliant implementation. The latter is what
tide has done as far as I can tell.

Right now the typescript-language-server I linked to is unmaintained,
and was the best implementation around. This affects emacs, since it is
not updated to TS 3.8 yet, and maybe never will.

>> Would it run on the same machine you are editing on, or another machine?
>
> It usually runs on the same machine that the codebase exists.
>

Yes

Theodor Thornhill

Re: Making Emacs more friendly to newcomers

[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 kind of thing is tsserver?  The word "server" has multiple meanings;
  > > in what sense is tsserver a "server"?

  > > Would it run on the same machine you are editing on, or another machine?

  > It usually runs on the same machine that the codebase exists.

Other than in the case where that machine exists for the same project
that you're contributing to, this would be SaaSS.

See https://gnu.org/philosophy/who-does-that-server-really-serve.html
for an explanation of SaaSS and why we should not tolerate 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: Making Emacs more friendly to newcomers

[조성빈]

Richard Stallman <rms@gnu.org> 작성:

> [[[ 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 kind of thing is tsserver?  The word "server" has multiple meanings;
>>> in what sense is tsserver a "server"?
>
>>> Would it run on the same machine you are editing on, or another machine?
>
>> It usually runs on the same machine that the codebase exists.
>
> Other than in the case where that machine exists for the same project
> that you're contributing to, this would be SaaSS.

The codebase is usually (almost always) on local.

> See https://gnu.org/philosophy/who-does-that-server-really-serve.html
> for an explanation of SaaSS and why we should not tolerate 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: Making Emacs more friendly to newcomers

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

  > > Other than in the case where that machine exists for the same project
  > > that you're contributing to, this would be SaaSS.

  > The codebase is usually (almost always) on local.

In other words, the language server is almost always installed and
running on your own computer.

At the basic moral level, that is a good thing.
It means you avoid SaaSS.  It is the right way to do things.

However, if the language server is based on LLVM, by suggesting
people install it we would be working towards the replacement
of GNU packages with a non-copylefted competitor.

That isn't immoral, but it is self-defeating.

-- 
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: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 26.04.2020 06:19, Richard Stallman wrote:

> However, if the language server is based on LLVM, by suggesting
> people install it we would be working towards the replacement
> of GNU packages with a non-copylefted competitor.
> 
> That isn't immoral, but it is self-defeating.

tsserver is written in JavaScript and runs on Node. Node is released 
under Apache license, but there are no GNU alternatives for it.

I don't think we have any language servers in GNU either, do we? But 
when and if an alternative based on GCC appears, we can easily start 
recommending it instead. LSP is an open protocol.

Until then, alas, AFAIK all such language tooling for editors/IDE/etc 
out there is based on LLVM or some part of it.

Re: Making Emacs more friendly to newcomers

[tomas]

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

On Sun, Apr 26, 2020 at 05:32:21PM +0300, Dmitry Gutov wrote:
> On 26.04.2020 06:19, Richard Stallman wrote:
> 
> >However, if the language server is based on LLVM, by suggesting
> >people install it we would be working towards the replacement
> >of GNU packages with a non-copylefted competitor.
> >
> >That isn't immoral, but it is self-defeating.
> 
> tsserver is written in JavaScript and runs on Node. Node is released
> under Apache license, but there are no GNU alternatives for it.
> 
> I don't think we have any language servers in GNU either, do we? But
> when and if an alternative based on GCC appears, we can easily start
> recommending it instead. LSP is an open protocol.
> 
> Until then, alas, AFAIK all such language tooling for
> editors/IDE/etc out there is based on LLVM or some part of it.

There seems to be something in the works for gcc:

  https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html

Cheers
-- t

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

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 26.04.2020 18:14, tomas@tuxteam.de wrote:
> There seems to be something in the works for gcc:
> 
>    https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html

I would say good news, but this was 3 years ago. :-(

Re: Making Emacs more friendly to newcomers

[tomas]

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

On Sun, Apr 26, 2020 at 07:32:42PM +0300, Dmitry Gutov wrote:
> On 26.04.2020 18:14, tomas@tuxteam.de wrote:
> >There seems to be something in the works for gcc:
> >
> >   https://gcc.gnu.org/legacy-ml/gcc-patches/2017-07/msg01448.html
> 
> I would say good news, but this was 3 years ago. :-(

Yes; I hoped Someone(TM) around here might have a fast path
to David Malcolm...

Cheers
-- t

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

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 04:50, Richard Stallman wrote:
> In general, for the kind of packages that we would
> like to include in Emacs, we should push for that kind of solution.

I'm not aware of any language server project where its authors would be 
amenable to including it in Emacs (or even just assigning the copyright 
to FSF).

Others are welcome to show me wrong, of course.

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

>> In general, for the kind of packages that we would
>> like to include in Emacs, we should push for that kind of solution.
> I'm not aware of any language server project where its authors would be
> amenable to including it in Emacs (or even just assigning the copyright 
> to FSF).

Including them with Emacs would be weird.  Kind of like including `diff`
with Emacs.


        Stefan

Re: Making Emacs more friendly to newcomers

[chad]

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

To be clear, I think the goal would be to have a close-to-turnkey system
for emacs that added emacs' side of the LSP equation, that would integrate
with whatever language package the user wanted (compiler, interpreter,
etc.) to use. Roughly speaking, something like emacs-lsp (
https://github.com/emacs-lsp/lsp-mode), somewhat integrated into emacs.
Then a hypothetical user that wanted to program in, say, OCaml, would
install either ocaml-language-server or ocaml-lsp-server, and emacs-lsp
would pick it up. In some cases, emacs would probably want "links"
(instructions, documentation, etc.) for getting the common language server
support, but usually these are bundled the toolchain for the language
itself, outside of Emacs. For example, the Go language server support is
installed with "go get".

HTH,
~Chad

On Mon, Apr 20, 2020 at 8:45 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> In general, for the kind of packages that we would
> >> like to include in Emacs, we should push for that kind of solution.
> > I'm not aware of any language server project where its authors would be
> > amenable to including it in Emacs (or even just assigning the copyright
> > to FSF).
>
> Including them with Emacs would be weird.  Kind of like including `diff`
> with Emacs.
>
>
>         Stefan
>
>
>

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

Re: Making Emacs more friendly to newcomers

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

  > > In general, for the kind of packages that we would
  > > like to include in Emacs, we should push for that kind of solution.

  > I'm not aware of any language server project where its authors would be 
  > amenable to including it in Emacs (or even just assigning the copyright 
  > to FSF).

You may be right about that.  Also, as someone else pointed out, it
might be nonmodular to include language servers in Emacs at all.

However, that makes me wonder what this scenario really consists of:

  >   I don't think anyone would mind if a
  > package shipped with Emacs automatically downloaded and installed a
  > free language server. (and I haven't actually seen any non-free language
  > servers.)

What is "a package shipped with Emacs", if it does not mean "a part of
Emacs"?  Is there such a thing?  What does "shipped with" mean here?

Anyway, the general idea of package installation in the GNU/Linux
distros I know about is that the _user_ decides when to install a
package.  One package (such as Emacs) has no business trying to
install another package.

So unless said language server is a part of Emacs (which might be
undesirable), nothing "shippped with Emacs" should install 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: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 06:19, Richard Stallman wrote:
> What is "a package shipped with Emacs", if it does not mean "a part of
> Emacs"?  Is there such a thing?  What does "shipped with" mean here?

eglot is currently distributed via GNU ELPA, so it itself is one 'M-x 
package-install' away.

> Anyway, the general idea of package installation in the GNU/Linux
> distros I know about is that the_user_  decides when to install a
> package.  One package (such as Emacs) has no business trying to
> install another package.

I think this conundrum is easily solved with a yes/no prompt.

Re: Making Emacs more friendly to newcomers

[ndame]

> The article is here:
>
> https://download.blender.org/documentation/pdf/LXF204.feat_3d.5cjt.pdf

That's not it, google found a version, some excerpts:

"Blender developers – would defend the software’s defiantly idiosyncratic UI on the grounds that ‘different doesn’t always mean worse’. Blender could do everything that other 3D packages could, they argued, and given a little time, it was possible to adapt your old working methods to a new combination of icons, keyboard shortcuts and menu commands. But for artists working in visual effects or game development – notoriously high-pressure industries, particularly when deadlines are looming – time is at a premium. Many people who might otherwise have loved Blender got no further than its splash screen"

...

"Others struck at the heart of Blender veterans’ sense of identity and even their muscle memory. In almost every other 3D application, you leftclick to select things. In Blender, prior to 2.80, you rightclicked by default. Supporters argued that it made for a faster, more precise workflow – but it was also alien to artists coming to Blender from other software."

...


https://www.pressreader.com/australia/linux-format/20191217/281745566267591



There are obvious similarities with Emacs' current situation.

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

ndame <ndame@protonmail.com> writes:

>> The article is here:
>>
>> https://download.blender.org/documentation/pdf/LXF204.feat_3d.5cjt.pdf
>
> That's not it, google found a version, some excerpts:
>
> "Blender developers – would defend the software’s defiantly idiosyncratic UI on
> the grounds that ‘different doesn’t always mean worse’. Blender could do
> everything that other 3D packages could, they argued, and given a little time,
> it was possible to adapt your old working methods to a new combination of icons,
> keyboard shortcuts and menu commands. But for artists working in visual effects
> or game development – notoriously high-pressure industries, particularly when
> deadlines are looming – time is at a premium. Many people who might otherwise
> have loved Blender got no further than its splash screen"
>
> ...
>
> "Others struck at the heart of Blender veterans’ sense of identity and even
> their muscle memory. In almost every other 3D application, you leftclick to
> select things. In Blender, prior to 2.80, you rightclicked by default.
> Supporters argued that it made for a faster, more precise workflow – but it was
> also alien to artists coming to Blender from other software."
>
> ...
>
>
> https://www.pressreader.com/australia/linux-format/20191217/281745566267591
>
>
>
> There are obvious similarities with Emacs' current situation.
The link from ndame links to is the correct article. I didn't know it
was avialable online.

I forgott to say unfortunately, I am sorry; Linux Format is a payed printed
magazine, so you have to either be a subscriber to read the full article
online, or to buy a paper copy of the magazine. I think it is worth, but
it's a personal choice.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 27.04.2020 20:50, ndame wrote:
> 
>> The article is here:
>>
>> https://download.blender.org/documentation/pdf/LXF204.feat_3d.5cjt.pdf
> 
> That's not it, google found a version, some excerpts:

Yeah, the above is a 5-year old article. But it was interesting too, and 
especially the emphasis on animators generally needing dedicated 
training to start being productive.

> "Blender developers – would defend the software’s defiantly idiosyncratic UI on the grounds that ‘different doesn’t always mean worse’. Blender could do everything that other 3D packages could, they argued, and given a little time, it was possible to adapt your old working methods to a new combination of icons, keyboard shortcuts and menu commands. But for artists working in visual effects or game development – notoriously high-pressure industries, particularly when deadlines are looming – time is at a premium. Many people who might otherwise have loved Blender got no further than its splash screen"
> 
> ...
> 
> "Others struck at the heart of Blender veterans’ sense of identity and even their muscle memory. In almost every other 3D application, you leftclick to select things. In Blender, prior to 2.80, you rightclicked by default. Supporters argued that it made for a faster, more precise workflow – but it was also alien to artists coming to Blender from other software."
> 
> ...
> 
> 
> https://www.pressreader.com/australia/linux-format/20191217/281745566267591

That's a very good read. Another quote, not much relevant for Emacs, but 
it could make for a good promo material for FSF:

“We don’t see open source as free. We see it as free-ing,” says Bell. 
“You could cer­tainly save money if you wanted to, but I see it as an 
op­por­tu­nity to take a por­tion of the bud­get and re­di­rect it to 
our core soft­ware. We truly hope that oth­ers will take the 
de­vel­op­ment work we’ve put in and push it fur­ther.”

> There are obvious similarities with Emacs' current situation.

I also see a lot of parallels between the programs themselves.

Re: Making Emacs more friendly to newcomers

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

  > https://www.pressreader.com/australia/linux-format/20191217/281745566267591

That page doesn't contain the article, only nonfree Javascript code which
we should not lead people to run.

  > That's not it, google found a version, some excerpts:

Since you read the article, could you tell us in which year Blender
changed interfaces?  And can someone find, somewhere, a list of what
the changes were, and show us that list?

-- 
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: Making Emacs more friendly to newcomers

[ndame]

>
> Since you read the article, could you tell us in which year Blender
> changed interfaces?

In version 2.80 in 2019.


The relevant part:


A game-changing release

When Roosendaal first proposed Blender 2.80 in 2015, it was as a “workflow release” – a chance to stop focusing on new features for a while in favour of bigger structural goals. At the time, he thought the work might take “9-12 months”. It turned out it would take three years longer.

But those extra years would buy the Blender Foundation time to address some of the real drawbacks in the software: issues that prevented artists used to commercial 3D applications from switching over to Blender. The biggest was the user interface. Before 2.80, diehard Blender users – including many

Blender developers – would defend the software’s defiantly idiosyncratic UI on the grounds that ‘different doesn’t always mean worse’. Blender could do everything that other 3D packages could, they argued, and given a little time, it was possible to adapt your old working methods to a new combination of icons, keyboard shortcuts and menu commands.

But for artists working in visual effects or game development – notoriously high-pressure industries, particularly when deadlines are looming – time is at a premium. Many people who might otherwise have loved Blender got no further than its splash screen. Some of the changes made in Blender 2.80 were cosmetic: the interface has a more industry-standard dark grey colour scheme, designed to prevent it from drawing the user’s eye away from the 3D scene on display in the viewport. Others struck at the heart of

Blender veterans’ sense of identity and even their muscle memory. In almost every other 3D application, you leftclick to select things. In Blender, prior to 2.80, you rightclicked by default. Supporters argued that it made for a faster, more precise workflow – but it was also alien to artists coming to Blender from other software.

Other changes were intended specifically to help artists make that transition. A toggleable ‘keymap’ switched Blender’s keyboard shortcuts from their traditional settings to ones more familiar to users of other 3D applications: tools like Pixologic’s Zbrush, used for sculpting organic characters, Autodesk’s Maya, used for general-purpose modelling and animation, and Sidefx’s Houdini, used for creating physically based effects like fire, water and smoke.

Re: Making Emacs more friendly to newcomers

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

  > A game-changing release

Thanks for showing us that.

I see the logic of this -- but I think that trying to do this with
Emacs would be a more drastic UI change than the one Blender made,
because the keyboard is the principal interface rather than a
secondary one.

At the same time I don't think we could get a lot of boost in usags
from it.  Blender was the only libre video editing program competing
with proprietary programs which, as a side issue, very expensive too.
By contrast, there are already other libre text editors.

-- 
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: Making Emacs more friendly to newcomers

[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. ]]]
>
>   > A game-changing release
>
> Thanks for showing us that.
>
> I see the logic of this -- but I think that trying to do this with
> Emacs would be a more drastic UI change than the one Blender made,
> because the keyboard is the principal interface rather than a
> secondary one.

Hope you don't take it personal but you are wrong about keyboard in 3D
applications. Both keyboard and mouse are primary input methods,
and 3D modellers/animators etc are very religious about their workflow
and habits. They are very habitual creatures to their shorctuts, just
like Emacs users.

> Emacs would be a more drastic UI change than the one Blender made,

Njah, they rewrote their GUI code almost completely. But anyway, would
that necessary be a bad thing?

You can still have Emacs traditional/classic/call-it-whatever
mode and other modes that emulate other text editors. It already exists
in Emacs, that is what evil & co does, there is CUA-mode etc.

Back in times, 1970-something, when you and your friends created Emacs,
there were probably no standard, world-wide, applicaiton-wide
terminology, workflow etc. At least it was different from what it is
today. Emacs is, like Blender, an application made before certain
standards even existed, but the world has changed, standards/habits has
become established and they are somewhat different than what Emacs uses.

It is just a surface anyway, and I am quite sure that veterans used to
Emacs would have no difficult time to keep their habits even if Emacs
changed some default terminology, shortcuts, looks and even interaction
mode. I know it is beating a dead horse, I have seen it being brought up
different times since I have started to use Emacs back in year '99 or there
around. It is just my personal opinion.

> At the same time I don't think we could get a lot of boost in usags
> from it.

Why? If you offerered a more polished "in-time" version of Emacs, I believe
Emacs is still superior as a tool to other editors/tools.

Emacs has quite some features that can be or are "killer" features,
that just has to be exposed a tad bit more. Shell/mail/dired/org are
probably ones, also a concept, search inteface to anything in Emacs
(pun intended - I think of anything/Helm as interaction model), easy
and tight integration with other tools and probably more.

All those things are already explorable and adaptable, ready to use,
but they need (somewhat) painfull and tedious assembling into the final
experience. Most people not familiar with Emacs are probably not aware
how to use it in more advanced way then just as a text editor with
"strange" keyboard shortcuts. They don't know what is available, what
they need to setup, and how, to get their imagined interaction model,
wofrklow, etc (iff they even have something already imagined).

I think Emacs is great, and choice is great! I value freedom foremost.
But as it is now, for many of modern features, choice is mandatory.

Emacs is already super-adaptable, it just needs a little bit more stuff
pre-integrated, turned on, and made a part of it and currage to make a
decision. Yes I love freedom, and I love to be able to tailor it to my
choice, but while I can make my choice between completion frameworks,
visual parts, shortcuts etc, people new to it have to look up all that
stuff, learn about it, search, spend time on configuring, testing
configuration and so on. It is that time consuming part that lots of
folks don't wanna do for various reasons.  It takes time to learn what
to setup and how to set it up. Many people are not willing or simply
can't spend that time.Many don't even care, they just want to have
something they can use. If their reserved words are blue or green, or if
symbol names are complited by language server or something else, they
probably don't care, people usually want just somethigni that works.

Make some more default choices, add some more modern functionality out
of the box, and let those who does not like defaults just re-configure
to whatever they want, they probably already do it anyway.

Question is also do you want those people who are unvilling to scratch
the surface and deep-dive into Emacs and spend time to learn it and
configure it, to use Emacs?

Well why not? More users means more momentum, more people contributing,
more cash to FSF (maybe :-)) etc, which results in Emacs and other FSF
software been even better, world realizing the power of open source
(I think it already did) and generaly promoting the FSF/Gnu ideals?
I believe that Emacs was, and probably still is the most advanced of
libre editors. Actually I don't see Emacs as a text editor longer,
but rather as a usefull tool for my every day computer interaction.

As a note, I know starter kits like Spacemacs, Prelude & Co are out
there, but somehow that does not seem to cut it.

> By contrast, there are already other libre text editors.

Why is that an argument if there are other libre text editors? Blender
was free to use for a long time before it become widely adopted. It wasn't
the kostenloss that made it widely adopted, it was when they turned it
into more in-time-with-standards (in combination with kostenloss) that
seems to helped most with wider adoption.

By the way, isn't evolution about adaptation? I mean even software has
to adapt, otherwise it becomes obsolete.

When we speak about Emacs and adoption, I think Emacs has actually got a
revival, compared to how I saw it used for 20 years ago, I think it is
quite a lot life about Emacs nowdays. There are people blogging, doing
videos, reddit seems quite active, the mailing list has become likea
spam :-), I don't remember it was active like this before, people are
writing new packages and so on. But compared to some other, slightly
less free offerings Emacs is not the most used/widespread tool. Yet :-).
Of course I dont' have any statistics, it is just a feeling I have, a
speculation based on what I see people talking about on the Internet.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 02.05.2020 18:52, Arthur Miller wrote:
> When we speak about Emacs and adoption, I think Emacs has actually got a
> revival, compared to how I saw it used for 20 years ago, I think it is
> quite a lot life about Emacs nowdays. There are people blogging, doing
> videos, reddit seems quite active, the mailing list has become likea
> spam:-), I don't remember it was active like this before, people are
> writing new packages and so on.

Was it package.el that did this? It sounds like the most likely culprit.

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 02.05.2020 18:52, Arthur Miller wrote:
>> When we speak about Emacs and adoption, I think Emacs has actually got a
>> revival, compared to how I saw it used for 20 years ago, I think it is
>> quite a lot life about Emacs nowdays. There are people blogging, doing
>> videos, reddit seems quite active, the mailing list has become likea
>> spam:-), I don't remember it was active like this before, people are
>> writing new packages and so on.
>
> Was it package.el that did this? It sounds like the most likely culprit.
I don't know; probably; it certainly helped. Melpa and github maybe have a
fingers there too. Maybe also millenial kids used to computers in the
look for customizable/better software? Need to work with "cloud"
(AWS/Azure) as well as with other devices (IoS/Android), probably made
some people switch to certain Unix like OS, or at least to work with
console which exposed them to terminal editors? I don't know, but it
seems like both Vi(m) & Emacs have got a revival lately.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 02.05.2020 20:00, Arthur Miller wrote:
> I don't know, but it
> seems like both Vi(m) & Emacs have got a revival lately.

That's true for FOSS editors in general, though. We didn't have so many 
good options before.

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 02.05.2020 20:00, Arthur Miller wrote:
>> I don't know, but it
>> seems like both Vi(m) & Emacs have got a revival lately.
>
> That's true for FOSS editors in general, though. We didn't have so many good
> options before.

Indeed, seems as a general trend, we have never had so much FOSS
software in general, not just editos, but everything, from AI research
to Game Engines, 3D Editors, compilers, libraries, you name it. Seems
like world has realized power of open source, which is great.

Re: Making Emacs more friendly to newcomers

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

  > Seems
  > like world has realized power of open source, which is great.

If people have realized the usefulness of the existing free programs,
that is good.

If people realize the value of the _freedom_ that free software gives,
and learn to demand this freedom, that would be GREAT.

Using the term "open source" tends to cover up that crucial point.
For the free software movement, that is self-defeating.  So please
let's make an effort to call our work "free", "libre", or both -- not
"open".

See https://gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source.  See also https://thebaffler.com/salvos/the-meme-hustler for
Evgeny Morozov's article on the same 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: Making Emacs more friendly to newcomers

[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. ]]]
>
>   > Seems
>   > like world has realized power of open source, which is great.
>
> If people have realized the usefulness of the existing free programs,
> that is good.
>
> If people realize the value of the _freedom_ that free software gives,
> and learn to demand this freedom, that would be GREAT.
>
> Using the term "open source" tends to cover up that crucial point.
> For the free software movement, that is self-defeating.  So please
> let's make an effort to call our work "free", "libre", or both -- not
> "open".
>
> See https://gnu.org/philosophy/open-source-misses-the-point.html
> for more explanation of the difference between free software and open
> source.  See also https://thebaffler.com/salvos/the-meme-hustler for
> Evgeny Morozov's article on the same point.

Yes of course RMS, I am completely with you when it comes to free
software and freedom. I definitely appreciate all you have done
through history, not less initiating everything.

It is just that sometimes, in everyday speech we don't always use
official, full, long names for stuff or hard distinctions because
we tend to shortcut things in speech. It happends in all languages,
fields of human activity etc. So we don't always say GNU/Linux, we
say Linux even when we mean GNU/Linux, just as we don't always say
Microsoft Windows but just Windows, or Apple OSX but just OSX etc.
Same thing happened there, I said open source as an umbrella term,
with no wishes diminish value of free software or not being aware
of distinction.

As a side not, personally I think that once most people realize
the power of community collaboration and openess, which might be
happening, maybe there will even not be a need for enforcing
"freeiness" as with GPL3, just as we don't need a law to enforce
other things in life when they become peoples identity becuase
people wish to do those things anyway. But maybe it is just utopia
thinking, don't know, but I think both "open source" and "free software"
is on the raise (just my personal opinion).

Re: Making Emacs more friendly to newcomers

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

  > It is just that sometimes, in everyday speech we don't always use
  > official, full, long names for stuff

Since "free software" is only two charactes longer than "open source",
how about making the effort to acquire that habit?  It will help our
cause, and once you learn the habit, you will hardly mind those extra
characters.

  > say Linux even when we mean GNU/Linux, just as we don't always say
  > Microsoft Windows but just Windows, or Apple OSX but just OSX etc.

They are similar in being shortenings, but there is a crucial difference.

Saying just "Windows" does not lead to forgetting that it comes from Microsoft.
Saying just "OSX" does not lead to forgetting that it comes from Apple.
There is no reason to make an effort to avoid those shortenings.

But saying just "Linux" instead of "GNU/Linux" misrepresents who
developed it.  That hampers what the GNU Project can achieve.  So how
about making the effort to avoid that particular shortening?

-- 
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: Making Emacs more friendly to newcomers

[Nikita Mogilevsky]

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

Hello, folks. I'd like to throw my two cents in as a relatively new user.
I've been using emacs for org-mode, coding, and irc on and off for a few
years.

The display interface:
There is already a thread about emacs' square appearance, but many features
of emacs would benefit from looking modernized. I agree with RMS that emacs
will need some reimagined graphics library implementation to make that
possible.

Customize:
This feature is conceptually simple but I found it almost hostile to
interact with. Between, states and unintuitive input fields. I found it
hard to understand what many functions and variables were meant to do or
represent. The documentation for these values showed elisp, so I quickly
transitioned away from customize. I don't know what I would improve here
but I think that many new users are guided to this feature and I don't
recommend them to play with it from personal experiences.

How should we poll new users and their initial interactions with emacs?
Would a setup wizard be helpful for common bindings like modern kill-yank
equivalents? While the philosophy funnels towards abandoning mouse cursors
and buttons what would be intuitive features for transitioning from that
kind of behavior?

On Tue, May 5, 2020, 21:47 Richard Stallman <rms@gnu.org> wrote:

> [[[ 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. ]]]
>
>   > It is just that sometimes, in everyday speech we don't always use
>   > official, full, long names for stuff
>
> Since "free software" is only two charactes longer than "open source",
> how about making the effort to acquire that habit?  It will help our
> cause, and once you learn the habit, you will hardly mind those extra
> characters.
>
>   > say Linux even when we mean GNU/Linux, just as we don't always say
>   > Microsoft Windows but just Windows, or Apple OSX but just OSX etc.
>
> They are similar in being shortenings, but there is a crucial difference.
>
> Saying just "Windows" does not lead to forgetting that it comes from
> Microsoft.
> Saying just "OSX" does not lead to forgetting that it comes from Apple.
> There is no reason to make an effort to avoid those shortenings.
>
> But saying just "Linux" instead of "GNU/Linux" misrepresents who
> developed it.  That hampers what the GNU Project can achieve.  So how
> about making the effort to avoid that particular shortening?
>
> --
> 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)
>
>
>
>

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

Re: Making Emacs more friendly to newcomers

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

  > Customize:
  > This feature is conceptually simple but I found it almost hostile to
  > interact with. Between, states and unintuitive input fields. I found it
  > hard to understand what many functions and variables were meant to do or
  > represent. The documentation for these values showed elisp, so I quickly
  > transitioned away from customize. I don't know what I would improve here
  > but I think that many new users are guided to this feature and I don't
  > recommend them to play with it from personal experiences.

I agree that it has big problems.

New users could tell us some aspects they notice as difficult.  I
don't think we can expect them to tell us what would make it better
for them -- not in general.

All I can suggest is for someone to try implementing a nicer interface
and invite some new users to try it, saying which aspects they find
less than ideal.  Then repeat.

Perhaps we should have separate customize code for graphical
displays.  I expect most new users use those.  If it doesn't have
to share code with the tty interface, it could be improved more.


-- 
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: Making Emacs more friendly to newcomers

[ndame]

>
> You can still have Emacs traditional/classic/call-it-whatever
> mode and other modes that emulate other text editors.

Veterans said they don't like when emacs defaults change and they
have to modify their configs to go back to old defaults.

The solution discussed recently when if emacs is started without
config then it offers modern settings to the user can be a good workaround.

This may not work always, because I saw 1-2 line config files created
by a given *nix distribution, so in that case the check would
fail for new users.

So in addition the other suggestion about a big, conspicuous button added
to the splash screen should also be implemented. A button with text like
"I'm new to emacs, give me friendly settings!" which when pressed sets up
emacs to be similar to the usual standards.


> It already exists
> in Emacs, that is what evil & co does, there is CUA-mode etc.


Emacs should have keybinding-themes like in other editors which
offer various keybinding variants.  E.g in IntelliJ:

IntelliJ IDEA automatically selects a predefined keymap based on your environment. Make sure that it matches the OS you are using or select the one that matches shortcuts from another IDE or editor you are used to (for example, Eclipse or NetBeans).

https://www.jetbrains.com/help/idea/configuring-keyboard-and-mouse-shortcuts.html


The tricky thing is these key-themes should be reflected in the documentation too, so,
for example, you couldn't have hardcoded keys in info, but rather info should be
an active document, that is, when it talks about keys invoking commands then
it should query the active bindings for the commands and show those to  present
a documentation which is consistent with the current keymap-theme.

RE: Making Emacs more friendly to newcomers

[Drew Adams]

> Question is also do you want those people who are
> unvilling to scratch the surface and deep-dive
> into Emacs and spend time to learn it and configure
> it, to use Emacs?

In general, I don't care.  "Those people" are really
all kinds of people, with different reluctance to
scratch the surface.

You can do a lot with Emacs without scratching any
surface.  Do I want someone who doesn't scratch the
surface at all to use Emacs?  Sure, if they like.
But if they don't like, that's OK too.

Emacs may not be for everyone, but I've seen all
kinds of people, including non-scratchers of all
sorts, come to use it productively, and even come
to love it.  Are there others who will never take
advantage of it or appreciate it?  Sure.

FWIW, I really do NOT think that anyone who's
been involved with Emacs development has little
care for newbies or for making Emacs flexible and
easy to use.

The opposite is the case - everyone I've ever see
take an interest in Emacs cares very much about
usability, discoverability, etc.

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I really do NOT think that anyone who's
> been involved with Emacs development has little
> care for newbies or for making Emacs flexible and
> easy to use.

I do NOT think something like that either Drew, nor did
I state that, just to be clear. Emacs is a prime example of flexibility,
sure! I wrote, Emacs is super-adaptable. Ease of use can be debatable,
what is easy for you and me does not necessary mean easy for somebody else.

> The opposite is the case - everyone I've ever see
> take an interest in Emacs cares very much about
> usability, discoverability, etc.

I didn't say Eamcs devs don't care about it either, I am sorry if I sound
to you like that.

Usability, discoverability and other user friendliness have many faces.
What I tried to say, is that that Emacs might have used some kind of a
facelift to reflect more of a time we live in.

Yes, sure, there are examples were people have not scratched under the
surface of Emacs, and lots of people use it with out-of-the-box
settings. But it wasn't point that it is not possible, or that there are
no users who does not do something with Emacs. The point is that
many users are not finding Emacs that useful, and are probably not even
trying it or switching after very short period to something else because
of Emacs not conforming to some basic expectations they happened to have.

Sure, one can never please everyone, that is just how life is. No matter
how one make something or how good one try, there will always be someone
who will want it differently, but nowdays, there are some basics that
most software seems to follow, and some people seems to be lost of those
are not met.

RE: Making Emacs more friendly to newcomers

[Drew Adams]

> > FWIW, I really do NOT think that anyone who's
> > been involved with Emacs development has little
> > care for newbies or for making Emacs flexible and
> > easy to use.
> 
> I do NOT think something like that either Drew, nor did
> I state that, just to be clear. Emacs is a prime example of
> flexibility, sure! I wrote, Emacs is super-adaptable.
> Ease of use can be debatable, what is easy for you and me
> does not necessary mean easy for somebody else.

I wasn't saying anything about what you said,
beyond responding to your question:

 > Question is also do you want those people who are
 > unvilling to scratch the surface and deep-dive
 > into Emacs and spend time to learn it and configure
 > it, to use Emacs?

There's nothing personal in my answer to that
question.  It's a reasonable question.  And I
gave my honest answer to it - zero about you.

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Drew Adams <drew.adams@oracle.com> writes:

>> > FWIW, I really do NOT think that anyone who's
>> > been involved with Emacs development has little
>> > care for newbies or for making Emacs flexible and
>> > easy to use.
>> 
>> I do NOT think something like that either Drew, nor did
>> I state that, just to be clear. Emacs is a prime example of
>> flexibility, sure! I wrote, Emacs is super-adaptable.
>> Ease of use can be debatable, what is easy for you and me
>> does not necessary mean easy for somebody else.
>
> I wasn't saying anything about what you said,
> beyond responding to your question:
>
>  > Question is also do you want those people who are
>  > unvilling to scratch the surface and deep-dive
>  > into Emacs and spend time to learn it and configure
>  > it, to use Emacs?
>
> There's nothing personal in my answer to that
> question.  It's a reasonable question.  And I
> gave my honest answer to it - zero about you.

Aha, OK, then I have slightly missunderstand what you ment. Sorry.

RE: Making Emacs more friendly to newcomers

[Drew Adams]

> Aha, OK, then I have slightly missunderstand what you ment. Sorry.

No problem; thanks.  There are lots of strong
opinions & arguments being expressed.  That's
OK, as long as the opinions & arguments are
about the opinions & arguments. ;-)

Re: Making Emacs more friendly to newcomers

[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 would be a more drastic UI change than the one Blender made,

  > Njah, they rewrote their GUI code almost completely.

I think we are talking past each other.

I don't use Blender, I don't know the field of animation, and I could
be misunderstanding everything about it.  But I think that in Blender,
the command set is just an interface, whereas in Emacs, the commands
are what it is.

I think that animation is fundamentally more complex than text.  Not
just a little more complex, but enormously and deeply so.  I expect
Blender has a lot of very different and very complex things it can do
to the animation being edited.  So a Blender user would be thinking
all the time about which complex and sophisticated operation perse
wants to do next, and the commands to invoke the operation would be
secondary.

Whereas in Emacs, I think, we are focused on lots of commands to
do more-or-less transparent things with text.

							 But anyway, would
  > that necessary be a bad thing?

You can develop another interface to Emacs.  We could support it as an option,
but it would not be Emacs.

-- 
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: Making Emacs more friendly to newcomers

[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. ]]]
>
>   > > Emacs would be a more drastic UI change than the one Blender made,
>
>   > Njah, they rewrote their GUI code almost completely.
>
> I think we are talking past each other.
Easy happends on the Internet, but I don't think we are, at least not
completely.

> be misunderstanding everything about it.  But I think that in Blender,
> the command set is just an interface, whereas in Emacs, the commands
> are what it is.

> You can develop another interface to Emacs.  We could support it as an option,
> but it would not be Emacs.

It probably depends on what you define as a command as well as what you
see as Emacs identity. If you identify Emacs as a set of shortcuts and
terminology then changig C-x C-f to C-o and cutting instead of'killing'
stuff will probably introde on it's identity. I personally don't identify
Emacs as a bunch of shortcuts. To me the identity lies more deeply under
the surface, and the outer surface is just a handle to operate Emacs.
The beauty and practicality of Emacs is that handle can be easily exchanged.

> I think that animation is fundamentally more complex than text.  Not
> just a little more complex, but enormously and deeply so.  I expect
> Blender has a lot of very different and very complex things it can do
> to the animation being edited.  So a Blender user would be thinking
> all the time about which complex and sophisticated operation perse
> wants to do next, and the commands to invoke the operation would be
> secondary.
>
> Whereas in Emacs, I think, we are focused on lots of commands to
> do more-or-less transparent things with text.
I am neither modeller nor animator myself, so I am not an expert either.
I don't think though the complexity matter so much, at least not in
context of this discussion.

Regardless of what complex operations an animator would think of in a 3D
application and what an Emacs user would think in an Editor, the
priniple is same: one think in terms of what one would do to a content
one works with. The commands to invoke those are secondary. When I
write this email, and type a misstake, I think in terms of moving the
cursor to correct place and deleting characters etc. Which shortcuts I
use, or mouse movements, etc, is secondary. If I wrote this in browser
instead of Emacs, I would involve different set of shortcuts but they
would execute "same" set of commands. Even though those commands are named
differently and implemented differently (different programming language,
environment etc) I still think in same logical terms of moving cursor
and replacing characters.

So if newcomers open Emacs and want to do simple things like
cut/copy/paste, open file etc, something that has very similar set of
shortcuts in very many applications nowdays, they would just type a
misstake in their content in Emacs, which probably leads to frustration.
Then they will open fine manual and stat searching for cut and copy and
paste and found nothing because we call it differen around here :-).
OK, I am carricaturing, it is not really true at least not for those simple
cases, but I hope it illustrates what I mean.

Re: Making Emacs more friendly to newcomers

[ndame]

> > We should prioritize existing users over hypothetical users that don't
> > even exist yet.

> And then, another 20 years pass, the current users get too old/change careers/retire/etc, and Emacs's userbase shrinks even more.

True, that's why some solution is needed which makes emacs more accessible
for new users who wants to try emacs.

The solution mentioned earlier in the thread can work well: Emacs defaults
stay Emacs-like to satisfy the veterans, but if a new user downloads
emacs and starts it without a config file then an optional initial config is
prominently offered which can ease the transition for new users, make emacs
less alien, more similar to existing systems.

Re: Making Emacs more friendly to newcomers

[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 solution mentioned earlier in the thread can work well: Emacs defaults
  > stay Emacs-like to satisfy the veterans, but if a new user downloads
  > emacs and starts it without a config file then an optional initial config is
  > prominently offered which can ease the transition for new users, make emacs
  > less alien, more similar to existing systems.

I agree this could be a good thing if it is done well.

It would be nice to make it easy for a user's configuration to
select this alternate interface even after making a nontrivial .emacs file
and specifying other parameters.

-- 
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: "Why is emacs so square?"

[Drew Adams]

> I'd like to remind all of us that
> there's a lot of "propaganda" out there telling everyone to turn off
> GUI features such as the menu bar and the tool bar.  The network is
> full of personal init files that "proudly" do that, and forums like
> Reddit are full of such advice to every newbie who asks about
> configuring their Emacs.  It is hard to be enthusiastic about making
> these features more modern when the community seems to be divided on
> whether they should at all be present.  IMO, we should first get our
> act together and decide whether these features are important, and then
> speak up according to those decisions when we see advice to the
> contrary.

+1

And count me as one vote for the menu-bar being
important, especially for discoverability.  The
tool-bar is less important, IMO, but I'd still
vote to keep it.

Re: "Why is emacs so square?"

[Joseph Garvin]

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

I think part of the problem with things like the menu bar is that if you're
using emacs at all you are demonstrating a willingness to tolerate:

* A UI that doesn't look or behave like any other application
* Keyboard shortcuts inconsistent with every other application
* A bizarre ancient vocabulary inconsistent with every other application.
e.g. no Microsoft word user has ever considered themselves to have opened a
"buffer". They open "files". They move "windows" around, not "frames." They
cut and paste not kill and yank, etc.

You are basically making a commitment to being or becoming a power user. I
certainly would not have put up with it if I didn't think it was going to
save me a lot of time as a software developer (and it does, everyday). I
doubt anyone invests the mental effort to deal with learning emacs nowadays
unless this is their goal. If you just want to do "casual" text editing
emacs is a very weird choice in 2020.

If you're a new user the idea that seeing kill and yank in the menu bar as
options helps discoverablity doesn't really hold when already nothing is
named the way you expect or acts the way you expect. If you're an
experienced user, then I would guess that like me C-h f,v,k and blog posts
are 99% of your discoverablity experience.

On Thu, Apr 16, 2020, 9:58 AM Drew Adams <drew.adams@oracle.com> wrote:

> > I'd like to remind all of us that
> > there's a lot of "propaganda" out there telling everyone to turn off
> > GUI features such as the menu bar and the tool bar.  The network is
> > full of personal init files that "proudly" do that, and forums like
> > Reddit are full of such advice to every newbie who asks about
> > configuring their Emacs.  It is hard to be enthusiastic about making
> > these features more modern when the community seems to be divided on
> > whether they should at all be present.  IMO, we should first get our
> > act together and decide whether these features are important, and then
> > speak up according to those decisions when we see advice to the
> > contrary.
>
> +1
>
> And count me as one vote for the menu-bar being
> important, especially for discoverability.  The
> tool-bar is less important, IMO, but I'd still
> vote to keep it.
>
>

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

Re: "Why is emacs so square?"

[Ahmed Khanzada]

Joseph, a few things come to mind from reading your email:

1. Terminal-based Vim is not like a modern application, yet is more
popular than Emacs.

2. The audience for Emacs are people interested in using free
software and Lisp to extend their text editing experience. Very few of
these will be "casual editors", and in fact the FSF provides libre casual
editing software through the GNOME project.

3. If Emacs was to become a "modern" app tomorrow, an editor extended
in Lisp still only has appeal for a minority of programmers, much like
the Lisp language itself. Most programmers looking for easy and modern
experiences will likely stick with Atom and Sublime.

4. Most of the push for a "modern look" comes from the desire for Emacs
to play more nicely with proprietary platforms. Rather, the goal of
Emacs is to support platforms like GNU/Linux. Platforms that respect
your freedom, and also do not push a corporate UI/UX vision of "modernity".

(Perhaps if we do move forward with modernization, we should think of
modernization in the context of something like GNOME rather than MacOS
or Windows. Surely Emacs could be a better citizen of GNOME.)

5. Given that many of the people complaining about how Emacs looks are not
submitting patches to fix the problem themselves, resources would be diverted
from actual functionality to "modernity".

6. By the time we do major code refactoring "modernizing" Emacs on the
major proprietary platforms, what is "modern" has now once again
changed, and our resources were put towards a project with a poor return on
investment.

Basically, I don't see a "modernizing" project playing out well. We will
spend extensive time and energy on a moving target, and even if we
succeed, our Lisp-based vision still has limited appeal. Additionally, I
don't think "modernizing" Emacs advances the cause of free software,
given that there are other more popular casual libre tools for text editing
that individuals can use.

Re: "Why is emacs so square?"

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

I think you've stated the arguments very well.  There are a couple of
points where I would say something less strong.

  > 3. If Emacs was to become a "modern" app tomorrow, an editor extended
  > in Lisp still only has appeal for a minority of programmers, much like
  > the Lisp language itself. Most programmers looking for easy and modern
  > experiences will likely stick with Atom and Sublime.

If Emacs were 100% as convenient and attractive as other editors,
it is possible that a lot of users would use it.  30 years ago,
the user profile of Emacs was much broader than it is today.
It would be good to make this happen again.

But that would require a number of changes, and I don't think that
round corners would get us close to there.

Thus, I think your point 3 is not valid in the universal sense that it
is presented in, but it is valid for the this particular issue.

If there are people who want to work on rounded corners, and assuming
they do a good job, I won't argue against it.  But if you want
to attract more users to Emacs, I think there are more important
areas for improvement.

-- 
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: "Why is emacs so square?"

[Po Lu]

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

Richard Stallman <rms@gnu.org> writes:

> If Emacs were 100% as convenient and attractive as other editors,
> it is possible that a lot of users would use it.  30 years ago,
> the user profile of Emacs was much broader than it is today.
> It would be good to make this happen again.

I would personally say that several of the starter packs (Spacemacs and
Doom immediately come to mind) are "attractive" and "modern", and don't
really sacrifice any functionality to achieve that.  Spacemacs is also
very easy to set-up and use.  (Doom's also getting there).
> But that would require a number of changes, and I don't think that
> round corners would get us close to there.

Agreed.

> If there are people who want to work on rounded corners, and assuming
> they do a good job, I won't argue against it.  But if you want
> to attract more users to Emacs, I think there are more important
> areas for improvement.

I'm working on something that uses GTK foreign rendering to draw button
and input field backgrounds as face boxes;  I should be able to get it
in a usable state soon (right now it only works on top of another set of
patches I'm working on that make Emacs a pure GTK app).


[-- Attachment #2: Screenshot --]
[-- Type: image/png, Size: 131103 bytes --]

Re: "Why is emacs so square?"

[ndame]

>
> I'm working on something that uses GTK foreign rendering to draw button
> and input field backgrounds as face boxes; I should be able to get it
> in a usable state soon (right now it only works on top of another set of
> patches I'm working on that make Emacs a pure GTK app).

Looks good. These are the changes Emacs needs, so it has a nicer first
impression for users who come from mainstream tools to give it a try.

Emacs shouldn't look old fashioned out of the box. It would be great
if it could use GTK widgets on all major GUI platforms, instead of
text buttons and stuff.

Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[Po Lu]

ndame <ndame@protonmail.com> writes:

> Looks good. These are the changes Emacs needs, so it has a nicer first
> impression for users who come from mainstream tools to give it a try.

I don't think the general goal is for Emacs to imitate popular tools, but
instead to make it a mainstream tool.  To achieve this, we do need to
make Emacs more friendly for newcomers, but we shouldn't erase the
traits that make Emacs unique (such as extreme extensibility and
customizability).

IOW, everything added to make Emacs more friendly should be optional
(but easily discoverable), and should not break backwards-compatiblity with
existing configurations.

Emacs has endured for 40+ years. I doubt that without the Emacsen I
remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
the various improvements they curtailed that Emacs would still be where
it is now.  Let's help Emacs endure another 40 years.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[Eduardo Ochs]

There are several different ways of making Emacs more friendly for
newcomers, and we should take a look at all these different ways and
try to connect them somehow.

I gave a presentation about my way at the last EmacsConf. It's here:

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

and I mentioned briefly in the presentation - in slides 11-13 - how
I've been using it to teach Emacs to lots of beginners. To make a long
story very short:

  0) install Emacs and eev in their machines,

  1) teach them the basics of Lisp _IN THE FIRST FIVE MINUTES_,

  2) show them how to navigate using the keys M-e, M-j, and M-k,
     and the menu bar and the tool bar.

From the docs:

  M-e   - to follow a hyperlink.  Mnemonic: "(e)valuate"/"(e)xecute".

  M-j   - to jump to certain predefined places. In particular, M-j
          without a numeric argument takes you to a buffer with basic
          help and a list of jump targets. See:

          http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.2

  M-k   - to go back.  Mnemonic: "(k)ill buffer".


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


On Sun, 19 Apr 2020 at 07:16, Po Lu <luangruo@yahoo.com> wrote:
>
> ndame <ndame@protonmail.com> writes:
>
> > Looks good. These are the changes Emacs needs, so it has a nicer first
> > impression for users who come from mainstream tools to give it a try.
>
> I don't think the general goal is for Emacs to imitate popular tools, but
> instead to make it a mainstream tool.  To achieve this, we do need to
> make Emacs more friendly for newcomers, but we shouldn't erase the
> traits that make Emacs unique (such as extreme extensibility and
> customizability).
>
> IOW, everything added to make Emacs more friendly should be optional
> (but easily discoverable), and should not break backwards-compatiblity with
> existing configurations.
>
> Emacs has endured for 40+ years. I doubt that without the Emacsen I
> remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
> the various improvements they curtailed that Emacs would still be where
> it is now.  Let's help Emacs endure another 40 years.
>

Re: Making Emacs more friendly to newcomers

[Po Lu]

Eduardo Ochs <eduardoochs@gmail.com> writes:

> There are several different ways of making Emacs more friendly for
> newcomers, and we should take a look at all these different ways and
> try to connect them somehow.
>
> I gave a presentation about my way at the last EmacsConf. It's here:
>
>   http://angg.twu.net/emacsconf2019.html
>
> and I mentioned briefly in the presentation - in slides 11-13 - how
> I've been using it to teach Emacs to lots of beginners. To make a long
> story very short:
>
>   0) install Emacs and eev in their machines,
>
>   1) teach them the basics of Lisp _IN THE FIRST FIVE MINUTES_,
>
>   2) show them how to navigate using the keys M-e, M-j, and M-k,
>      and the menu bar and the tool bar.
>
> From the docs:
>
>   M-e   - to follow a hyperlink.  Mnemonic: "(e)valuate"/"(e)xecute".
>
>   M-j   - to jump to certain predefined places. In particular, M-j
>           without a numeric argument takes you to a buffer with basic
>           help and a list of jump targets. See:
>
>           http://angg.twu.net/eev-intros/find-eev-quick-intro.html#7.2
>
>   M-k   - to go back.  Mnemonic: "(k)ill buffer".
>
>
> Cheers,
>   Eduardo Ochs
>   http://angg.twu.net/#eev
>   http://angg.twu.net/emacsconf2019.html
>
>

Your perspective is interesting.  However, I think new users should be
allowed to slowly adapt to the Emacs way, while being able to utilize their
existing workflow and habits, instead of being fed a new set of habits
and workflows in the first 5 minutes.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> ndame <ndame@protonmail.com> writes:
>
>> Looks good. These are the changes Emacs needs, so it has a nicer first
>> impression for users who come from mainstream tools to give it a try.
>
> I don't think the general goal is for Emacs to imitate popular tools, but
> instead to make it a mainstream tool.  To achieve this, we do need to
> make Emacs more friendly for newcomers, but we shouldn't erase the
> traits that make Emacs unique (such as extreme extensibility and
> customizability).
>
> IOW, everything added to make Emacs more friendly should be optional
> (but easily discoverable), and should not break backwards-compatiblity with
> existing configurations.

I personally find that the stance of trying to not breaking anything is
one of the big reasons that Emacs has a nonusable-without-configuration UX.
Major version numbers are there for a reason… and we can expect for annoyed
people to set some variables to get old behavior.

> Emacs has endured for 40+ years. I doubt that without the Emacsen I
> remember using with squeals of delight (Epoch, XEmacs, Emacs 19), and
> the various improvements they curtailed that Emacs would still be where
> it is now.  Let's help Emacs endure another 40 years.

Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?")

[ndame]

>
> I personally find that the stance of trying to not breaking anything is
> one of the big reasons that Emacs has a nonusable-without-configuration UX.
> Major version numbers are there for a reason… and we can expect for annoyed
> people to set some variables to get old behavior.

Yes, these changes should be clearly marked in NEWS, so those who don't want
them, can revert them.

Out of the box Emacs should be instantly usable for newcomers and older users
could adapt for the sake of Emacs. I wouldn't mind adding a line to my .emacs to
turn something off which I don't need, but which can make the life of new
users easier.

For example, CUA mode could be on by default. I would turn it off, but it could
make the life of new users easier if they didn't have to turn it on explicitly
and they could use their copy/paste keys from the start like they are used it to
in other tools.

Re: Making Emacs more friendly to newcomers

[Po Lu]

ndame <ndame@protonmail.com> writes:

> Yes, these changes should be clearly marked in NEWS, so those who don't want
> them, can revert them.

Massive features that drastically change behaviour should be off by
default.  Stability over users. What's wrong with a button on the fancy
splash screen?

> Out of the box Emacs should be instantly usable for newcomers and older users
> could adapt for the sake of Emacs. I wouldn't mind adding a line to my .emacs to
> turn something off which I don't need, but which can make the life of new
> users easier.

You can't turn massive changes off by adding "one line to my .emacs".
You can however turn them on by adding a button to the splash screen.

Emacs cannot and will never be usable out-of-the-box for 100% of all
usecases.  You can however make it easier for people to start, and again
that's when the "button on splash screen" approach comes in.

> For example, CUA mode could be on by default. I would turn it off, but it could
> make the life of new users easier if they didn't have to turn it on explicitly
> and they could use their copy/paste keys from the start like they are used it to
> in other tools.

That mentality would lead to an unacceptable maintainence burden for a lot of
people.  Again: what's wrong with putting a button on the splash screen?

Re: Making Emacs more friendly to newcomers

[ndame]

>
> > Yes, these changes should be clearly marked in NEWS, so those who don't want
> > them, can revert them.
>
> Massive features that drastically change behaviour should be off by
> default. Stability over users. What's wrong with a button on the fancy
> splash screen?

A button can work too. Or if emacs is started with no config file then it can
ask "Are you using Emacs for the first time?" If the user says yes then it
can offer to set some convenience features like CUA mode.

And if the user says no then everything is as usual.

Re: Making Emacs more friendly to newcomers

[Po Lu]

ndame <ndame@protonmail.com> writes:

> A button can work too. Or if emacs is started with no config file then it can
> ask "Are you using Emacs for the first time?" If the user says yes then it
> can offer to set some convenience features like CUA mode.
>
> And if the user says no then everything is as usual.

The latter now occours to me as being the best solution.  Thanks for
bringing it up.  I believe it would be nice if we had both too.

Re: Making Emacs more friendly to newcomers

[Sébastien Gendre]

# Re: Making Emacs more friendly to newcomers

Based on some suggestions on this topic, and some personal
reflections, I have a suggestion. (Sorry, I didn't read all messages,
maybe someone had already suggest the same thing)

Let's see some use-cases:
- Bob: A newcomer, who just discover Emacs. He search somthing who is
  visually modern, with all features he need to start writing code in
  most popular languages: Code colouration, auto-completion, code
  navigation, code documentation and functions/methods signature
  automatically shown, code errors/warnings signalling, REPL
  integration, snippets, strong GIT integration, etc. He also want to
  use basic features without the need to read a tutorial. Just install
  and go. But he is ok to read some tuto or manuals for advanced
  features. If we ask him question(s) about what to enable or not, he
  probably cannot respond (or thing he cannot). For him, Emacs need to
  be the most out of the box possible.
- Alice: A long time user. She got a personal Emacs configuration she
  had perfected over the years. She chose herself what system is used
  to show function completion, which code parser is used for her daily
  used languages. She add some packages to integrate with special
  tools used at her work. Emacs is her home and office: She use it as
  much for her personal project than for her work. She also made a
  personal workflow with org-mode and write some personal Elisp
  functions and advices. She forge the tools to her need. She do not
  want to have an update of Emacs who break her configuration, her
  workflow or her muscle memory.
- Mei: She simply want to use SpaceEmacs. She need to be sure
  SpaceEmacs would work out of the box and be able to override all
  defaults Emacs configuration. So SpaceEmacs developers need a way to
  doing their work without the need to deactivate a hundred of default
  features one after another and risk to forget one. This possibility
  should be well documented. As the need of Mei is covered by
  SpaceEmacs, she doesn't have special request about Emacs except make
  it easy to use SpaceEmacs.
- Roberto: He work on a pre-configuration of Emacs, similar to
  SpaceEmacs. He need a simple and documented way to deactivate all
  default configurations that would make is work difficult. If
  possible, in one move. And, of course, he need to know what is
  deactivated so he can choose wisely what to enable and what to not.
  
  
For these 4 use-cases, we can simply provide 2 flavors of Emacs:
- Emacs: With all the 2020 features, a modern interface, all needed
  modern features to start coding with most popular languages and easy
  to use for basic usages
- Emacs Vanilla: All the new features are still there, but deactivate
  to not break anything


And these 2 flavors can be in the same text editor: For switch from a
flavor to another, simply enable the global-minor-mode `vanilla-mode`.
And if Emacs detect, after an update or a first start, an already
existing configuration that it could break because of some features:
Emacs simply activate `vanilla-mode` automatically.


For our use-cases, this would be:
- Bob simply download and run Emacs. He got everything he wanted and
  start to code. Emacs can manage Bob projects, show documentation and
  errors, etc. Then, after some times, Bob can read some manuals to
  personalise his installation of Emacs.
- Alice update Emacs. When she restart it, Emacs detect an already
  existing configuration that it could break by enabling some
  features. So, Emacs simply enable `vanilla-mode` and add it to the
  `init.el`. Emacs also show a message to Alice: "Emacs detected that
  you have some personal configuration, so it active Vanilla-mode to
  avoid breaking your configuration. Vanilla-mode deactivate some
  features that you can re-enable manually.". This message is
  accompanied by a clickable link to the documentation about the
  `vanilla-mode` to see what it does in the details and what is
  deactivate.
- Mei simply download Emacs and SpaceEmacs. She follow SpaceEmacs
  instruction and everything work.
- Roberto add `(vanilla-mode)` to his `init.el` file and start writing
  his pre-configuration of Emacs. He is certain that no future version
  of Emacs would break his work and he can share publicly his
  configuration as SpaceEmacs or Doom Emacs do.

  
It's just a starting point, but I think this could be a simple but
very useful solution.

Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

Sébastien Gendre <seb@k-7.ch> writes:

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages
> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything

I'm personally not against the idea of having a separate backwards
compatibility mode.

But I guess we would need to pull in several third-party packages to
have a modern "batteries included" Emacs.  AFAIK, that is
unfortunately not possible given the copyright assignment requirement.
But perhaps a default "modern" mode could be a bit less ambitious.

Best regards,
Stefan Kangas

Re: Making Emacs more friendly to newcomers

[Tim Cross]

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

How will any of this differ from the many existing canned default setups
already available? In fact, given the limitation on only using Emacs
built-in packages, is it even possible to do a setup which is even close to
some of these canned setups, many of which appear to be targeted at new
users (spacemacs, doom, prelude, etc). Are we just talking about a GNU
canned configuration?

On Mon, 20 Apr 2020 at 10:37, Stefan Kangas <stefan@marxist.se> wrote:

> Sébastien Gendre <seb@k-7.ch> writes:
>
> > For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> > - Emacs: With all the 2020 features, a modern interface, all needed
> >   modern features to start coding with most popular languages and easy
> >   to use for basic usages
> > - Emacs Vanilla: All the new features are still there, but deactivate
> >   to not break anything
>
> I'm personally not against the idea of having a separate backwards
> compatibility mode.
>
> But I guess we would need to pull in several third-party packages to
> have a modern "batteries included" Emacs.  AFAIK, that is
> unfortunately not possible given the copyright assignment requirement.
> But perhaps a default "modern" mode could be a bit less ambitious.
>
> Best regards,
> Stefan Kangas
>
>

-- 
regards,

Tim

--
Tim Cross

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

Re: Making Emacs more friendly to newcomers

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> How will any of this differ from the many existing canned default setups already available? In fact, given the limitation on only using Emacs built-in packages, is it even possible to do a setup which is even close to some of these canned setups, many of which appear to
> be targeted at new users (spacemacs, doom, prelude, etc). Are we just talking about a GNU canned configuration?

More of a few well thought-out tips that are easily discoverable by
users.

>  But I guess we would need to pull in several third-party packages to
>  have a modern "batteries included" Emacs.  AFAIK, that is
>  unfortunately not possible given the copyright assignment requirement.
>  But perhaps a default "modern" mode could be a bit less ambitious.

Agreed, but I believe most package maintainers would be willing to
assign copyright to the FSF.  (For instance Eglot would count as an
important package, and it's in ELPA).

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

For the record, I have a proof-of-concept package for GNU ELPA which
I call `gnu-elpa` and which just adds "most" of the autoloads found in
GNU ELPA packages (along with the corresponding changes to
`auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
will prompt the user if they want to install the corresponding package.

It's not as good as activating `eglot` and `company`, but I think such
a `gnu-elpa` package should ideally be bundled with Emacs-28.


        Stefan

Re: Making Emacs more friendly to newcomers

[Po Lu]

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

> For the record, I have a proof-of-concept package for GNU ELPA which
> I call `gnu-elpa` and which just adds "most" of the autoloads found in
> GNU ELPA packages (along with the corresponding changes to
> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
> will prompt the user if they want to install the corresponding package.

That's interesting.  I remember someone working on something similar,
but would find autoloads inside any package.el repository (it would
download, extract and cache the autoloads from a list of packages
beforehand).

> It's not as good as activating `eglot` and `company`, but I think such
> a `gnu-elpa` package should ideally be bundled with Emacs-28.

Yeah, that would be nice.

Re: Making Emacs more friendly to newcomers

[Simen Heggestøyl]

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

> For the record, I have a proof-of-concept package for GNU ELPA which
> I call `gnu-elpa` and which just adds "most" of the autoloads found in
> GNU ELPA packages (along with the corresponding changes to
> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
> will prompt the user if they want to install the corresponding package.
>
> It's not as good as activating `eglot` and `company`, but I think such
> a `gnu-elpa` package should ideally be bundled with Emacs-28.

That sounds really nice.

-- Simen

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

> On Apr 21, 2020, at 9:57 AM, Simen Heggestøyl <simenheg@runbox.com> wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>> For the record, I have a proof-of-concept package for GNU ELPA which
>> I call `gnu-elpa` and which just adds "most" of the autoloads found in
>> GNU ELPA packages (along with the corresponding changes to
>> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
>> will prompt the user if they want to install the corresponding package.
>> 
>> It's not as good as activating `eglot` and `company`, but I think such
>> a `gnu-elpa` package should ideally be bundled with Emacs-28.
> 
> That sounds really nice.
> 
> — Simen
> 

I like the idea. If I open a Racket file in VSCode, it show a prompt that asks me if I want to search the “market place” for a racket plugin. If I click yes and click install, everything magically works. Now my racket buffer has completion, highlight, etc. For more popular languages like python, VSCode even auto detects for linters and python executables, etc. And with one click it finds (or downloads) linters and executables and sets them up for me. Maybe it is hard to make Emacs as pretty as VSCode (with all the fancy visual web tech); but making Emacs smarter and more helpful should be a tractable task. We already have Customize, all we need to do next is to add some smart helper functions that install packages and setup stuff. 

Yuan

Re: Making Emacs more friendly to newcomers

[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 the record, I have a proof-of-concept package for GNU ELPA which
  > >> I call `gnu-elpa` and which just adds "most" of the autoloads found in
  > >> GNU ELPA packages (along with the corresponding changes to
  > >> `auto-mode-alist`), such that `M-x eglot` or opening a smalltalk file
  > >> will prompt the user if they want to install the corresponding package.

It is ok to do this with GNU ELPA,
because we could move those packages into the Emacs distribution
if that ever seems advantageous for any reason.
We don't have an essential need to make a distinction between
the packages in GNU ELPA and the ones in the Emacs distinction itself.

-- 
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: Making Emacs more friendly to newcomers

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> I like the idea. If I open a Racket file in VSCode, it show a prompt
> that asks me if I want to search the “market place” for a racket
> plugin. If I click yes and click install, everything magically
> works. Now my racket buffer has completion, highlight, etc. For more
> popular languages like python, VSCode even auto detects for linters
> and python executables, etc. And with one click it finds (or
> downloads) linters and executables and sets them up for me. Maybe it
> is hard to make Emacs as pretty as VSCode (with all the fancy visual
> web tech); but making Emacs smarter and more helpful should be a
> tractable task. We already have Customize, all we need to do next is
> to add some smart helper functions that install packages and setup
> stuff.

I'd say Emacs can be made to look just as nice as VS Code with some
minor tweaks, and yeah it would be nice if Stefan's package (or
something similar) would be able to suggest Geiser upon opening a Scheme
(or Racket) file.

Re: Making Emacs more friendly to newcomers

[Ahmed Khanzada]

> I'd say Emacs can be made to look just as nice as VS Code with some
> minor tweaks, and yeah it would be nice if Stefan's package (or
> something similar) would be able to suggest Geiser upon opening a Scheme
> (or Racket) file.

I wonder what kind of effect it will have on the community when
packages in the same domain compete to be "anointed" as the package that
Emacs shall recommend for a particular file type or feature.

Or do we approach it like the EU did with web browsers, and when Emacs
boots, we suggest either enabling Ivy, Helm, or Company for text
completion? There are never more than a few packages seriously competing in the
same domain anyway, if one can even call it competition.

Re: Making Emacs more friendly to newcomers

[Stefan Kangas]

Ahmed Khanzada <me@enzu.ru> writes:

> Or do we approach it like the EU did with web browsers, and when Emacs
> boots, we suggest either enabling Ivy, Helm, or Company for text
> completion? There are never more than a few packages seriously competing in the
> same domain anyway, if one can even call it competition.

I think we should offer a multiple choice question, ideally with some
brief explanation of the differences between the packages.

It would also be good if one could easily switch between alternatives.

Best regards,
Stefan Kangas

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Wed, 22 Apr 2020 23:33:32 -0700
> From: Ahmed Khanzada <me@enzu.ru>
> Cc: Yuan Fu <casouri@gmail.com>, Tim Cross <theophilusx@gmail.com>,
>  Stefan Kangas <stefan@marxist.se>, Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Sébastien Gendre <seb@k-7.ch>,
>  Simen Heggestøyl <simenheg@runbox.com>
> 
> I wonder what kind of effect it will have on the community when
> packages in the same domain compete to be "anointed" as the package that
> Emacs shall recommend for a particular file type or feature.

We have several of such "competitors" already in core.  Did anything
bad happen?

And it isn't like packages are lining up to be included in Emacs, or
even "anointed" by it, is it?  Boy, I'd like to be there.

Re: Making Emacs more friendly to newcomers

[Po Lu]

Sébastien Gendre <seb@k-7.ch> writes:


> Let's see some use-cases:
> - Bob: A newcomer, who just discover Emacs. He search somthing who is
>   visually modern, with all features he need to start writing code in
>   most popular languages: Code colouration, auto-completion, code
>   navigation, code documentation and functions/methods signature
>   automatically shown, code errors/warnings signalling, REPL
>   integration, snippets, strong GIT integration, etc. He also want to
>   use basic features without the need to read a tutorial. Just install
>   and go. But he is ok to read some tuto or manuals for advanced
>   features. If we ask him question(s) about what to enable or not, he
>   probably cannot respond (or thing he cannot). For him, Emacs need to
>   be the most out of the box possible.
> - Alice: A long time user. She got a personal Emacs configuration she
>   had perfected over the years. She chose herself what system is used
>   to show function completion, which code parser is used for her daily
>   used languages. She add some packages to integrate with special
>   tools used at her work. Emacs is her home and office: She use it as
>   much for her personal project than for her work. She also made a
>   personal workflow with org-mode and write some personal Elisp
>   functions and advices. She forge the tools to her need. She do not
>   want to have an update of Emacs who break her configuration, her
>   workflow or her muscle memory.
> - Mei: She simply want to use SpaceEmacs. She need to be sure
>   SpaceEmacs would work out of the box and be able to override all
>   defaults Emacs configuration. So SpaceEmacs developers need a way to
>   doing their work without the need to deactivate a hundred of default
>   features one after another and risk to forget one. This possibility
>   should be well documented. As the need of Mei is covered by
>   SpaceEmacs, she doesn't have special request about Emacs except make
>   it easy to use SpaceEmacs.
> - Roberto: He work on a pre-configuration of Emacs, similar to
>   SpaceEmacs. He need a simple and documented way to deactivate all
>   default configurations that would make is work difficult. If
>   possible, in one move. And, of course, he need to know what is
>   deactivated so he can choose wisely what to enable and what to not.

You have summed up the use-cases rather well.  Thanks.

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages
> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything
> And these 2 flavors can be in the same text editor: For switch from a
> flavor to another, simply enable the global-minor-mode `vanilla-mode`.
> And if Emacs detect, after an update or a first start, an already
> existing configuration that it could break because of some features:
> Emacs simply activate `vanilla-mode` automatically.

I'm afraid it's not that simple.  I don't think we need any radical
changes in Emacs to be turned on by default, but maybe something like a
set-up wizard or "New to Emacs? Click here" would be useful.

> - Alice update Emacs. When she restart it, Emacs detect an already
>   existing configuration that it could break by enabling some
>   features. So, Emacs simply enable `vanilla-mode` and add it to the
>   `init.el`. Emacs also show a message to Alice: "Emacs detected that
>   you have some personal configuration, so it active Vanilla-mode to
>   avoid breaking your configuration. Vanilla-mode deactivate some
>   features that you can re-enable manually.". This message is
>   accompanied by a clickable link to the documentation about the
>   `vanilla-mode` to see what it does in the details and what is
>   deactivate.

I'm not sure whether Emacs can reliably detect updates or not.  IIRC,
there was a discussion a while back that said no.  Plus, as I've
previously mentioned, I don't think Emacs should adopt any drastic
changes as the default configuration, but instead make the changes
easily discoverable.  (or at least until all of us old farts have had
another decade or 2 to adjust).

Re: Making Emacs more friendly to newcomers

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> Sébastien Gendre <seb@k-7.ch> writes:
>
>
>> Let's see some use-cases:
>> - Bob: A newcomer, who just discover Emacs. He search somthing who is
>>   visually modern, with all features he need to start writing code in
>>   most popular languages: Code colouration, auto-completion, code
>>   navigation, code documentation and functions/methods signature
>>   automatically shown, code errors/warnings signalling, REPL
>>   integration, snippets, strong GIT integration, etc. He also want to
>>   use basic features without the need to read a tutorial. Just install
>>   and go. But he is ok to read some tuto or manuals for advanced
>>   features. If we ask him question(s) about what to enable or not, he
>>   probably cannot respond (or thing he cannot). For him, Emacs need to
>>   be the most out of the box possible.
>> - Alice: A long time user. She got a personal Emacs configuration she
>>   had perfected over the years. She chose herself what system is used
>>   to show function completion, which code parser is used for her daily
>>   used languages. She add some packages to integrate with special
>>   tools used at her work. Emacs is her home and office: She use it as
>>   much for her personal project than for her work. She also made a
>>   personal workflow with org-mode and write some personal Elisp
>>   functions and advices. She forge the tools to her need. She do not
>>   want to have an update of Emacs who break her configuration, her
>>   workflow or her muscle memory.
>> - Mei: She simply want to use SpaceEmacs. She need to be sure
>>   SpaceEmacs would work out of the box and be able to override all
>>   defaults Emacs configuration. So SpaceEmacs developers need a way to
>>   doing their work without the need to deactivate a hundred of default
>>   features one after another and risk to forget one. This possibility
>>   should be well documented. As the need of Mei is covered by
>>   SpaceEmacs, she doesn't have special request about Emacs except make
>>   it easy to use SpaceEmacs.
>> - Roberto: He work on a pre-configuration of Emacs, similar to
>>   SpaceEmacs. He need a simple and documented way to deactivate all
>>   default configurations that would make is work difficult. If
>>   possible, in one move. And, of course, he need to know what is
>>   deactivated so he can choose wisely what to enable and what to not.
>
> You have summed up the use-cases rather well.  Thanks.
>
>> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
>> - Emacs: With all the 2020 features, a modern interface, all needed
>>   modern features to start coding with most popular languages and easy
>>   to use for basic usages
>> - Emacs Vanilla: All the new features are still there, but deactivate
>>   to not break anything
>> And these 2 flavors can be in the same text editor: For switch from a
>> flavor to another, simply enable the global-minor-mode `vanilla-mode`.
>> And if Emacs detect, after an update or a first start, an already
>> existing configuration that it could break because of some features:
>> Emacs simply activate `vanilla-mode` automatically.
>
> I'm afraid it's not that simple.  I don't think we need any radical
> changes in Emacs to be turned on by default, but maybe something like a
> set-up wizard or "New to Emacs? Click here" would be useful.

I can’t understand why you’re so opposed to changing defaults. Defaults
matter, and I think that users who are already accustomed to Emacs will
have an easier time changing options. (Like adding `(vanilla-mode 1)`
to init.el.)

>> - Alice update Emacs. When she restart it, Emacs detect an already
>>   existing configuration that it could break by enabling some
>>   features. So, Emacs simply enable `vanilla-mode` and add it to the
>>   `init.el`. Emacs also show a message to Alice: "Emacs detected that
>>   you have some personal configuration, so it active Vanilla-mode to
>>   avoid breaking your configuration. Vanilla-mode deactivate some
>>   features that you can re-enable manually.". This message is
>>   accompanied by a clickable link to the documentation about the
>>   `vanilla-mode` to see what it does in the details and what is
>>   deactivate.
>
> I'm not sure whether Emacs can reliably detect updates or not.

Adding a variable that makes Emacs warn if it’s version number is
different from its value might work.

> IIRC,
> there was a discussion a while back that said no.  Plus, as I've
> previously mentioned, I don't think Emacs should adopt any drastic
> changes as the default configuration, but instead make the changes
> easily discoverable.

The features that are best discoverable are the ones that are default.

> (or at least until all of us old farts have had
> another decade or 2 to adjust).

Defaults have to change for experienced users to adjust. And for them,
adjusting is an easy task, not something that takes a decade.

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I can’t understand why you’re so opposed to changing defaults. Defaults
> matter, and I think that users who are already accustomed to Emacs will
> have an easier time changing options. (Like adding `(vanilla-mode 1)`
> to init.el.)

I oppose changing defaults, because I value my tools remaining stable.
Having to frequently adjust my user-emacs-directory to encompass the
latest fancy new idea is an unacceptable maintenance burden to me.  Not
to mention in practice, those changes are going to be far larger than a
hypothetical `vanilla-mode'.

> Adding a variable that makes Emacs warn if it’s version number is
> different from its value might work.

I'm not sure what you're talking about; Variables don't persist across
Emacs sessions.

> The features that are best discoverable are the ones that are default.

And since changing the defaults radically end up hurting existing users,
and also existing packages and potentially the existing ecosystem.  You
have to find a balance between that, and changing the defaults is not
the balance you want.

> Defaults have to change for experienced users to adjust. And for them,
> adjusting is an easy task, not something that takes a decade.

"For existing users to adjust" is not an excuse -- that puts an extra
burden on users.

Re: Making Emacs more friendly to newcomers

[조성빈]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> writes:
>
>> I can’t understand why you’re so opposed to changing defaults. Defaults
>> matter, and I think that users who are already accustomed to Emacs will
>> have an easier time changing options. (Like adding `(vanilla-mode 1)`
>> to init.el.)
>
> I oppose changing defaults, because I value my tools remaining stable.
> Having to frequently adjust my user-emacs-directory to encompass the
> latest fancy new idea is an unacceptable maintenance burden to me.

Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
‘vanilla-mode’ will be the current situation of Emacs - it will try to
be stable.

> Not
> to mention in practice, those changes are going to be far larger than a
> hypothetical `vanilla-mode'.

Why? If you’re fine with the current level of changes in Emacs, that would
be the level of changes in ‘vanilla-mode’.

>> Adding a variable that makes Emacs warn if it’s version number is
>> different from its value might work.
>
> I'm not sure what you're talking about; Variables don't persist across
> Emacs sessions.

I’m saying that one can add a variable like ‘expected-emacs-version’ and
when Emacs is loading init.el and ‘expected-emacs-version’ is different
from the current version, Emacs can warn you.

>> The features that are best discoverable are the ones that are default.
>
> And since changing the defaults radically end up hurting existing users,

No, it doesn’t. Better defaults help users and allow them to lighten their
configuration.

> and also existing packages and potentially the existing ecosystem.  You
> have to find a balance between that, and changing the defaults is not
> the balance you want.

The balance I’m suggesting (actually ndame) is to add a ‘vanilla-mode’ for
people who value stability over features.

>> Defaults have to change for experienced users to adjust. And for them,
>> adjusting is an easy task, not something that takes a decade.
>
> "For existing users to adjust" is not an excuse -- that puts an extra
> burden on users.

No, it doesn’t - see previous comments.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: 조성빈 <pcr910303@icloud.com>
> Date: Mon, 20 Apr 2020 22:07:55 +0900
> Cc: Sébastien Gendre <seb@k-7.ch>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
> ‘vanilla-mode’ will be the current situation of Emacs - it will try to
> be stable.

It's not that simple.  Some features that are turned on cannot be
easily turned off afterwards.

> > And since changing the defaults radically end up hurting existing users,
> 
> No, it doesn’t. Better defaults help users and allow them to lighten their
> configuration.

Experience shows that you are in disagreement with a large bulk of our
users.  They tend to complain loudly when they bump into some changes
of defaults that they dislike, or find that behavior they were
accustomed to changed too radically.

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:


> Then you can turn on ‘vanilla-mode’ on your init.el and call it a day.
> ‘vanilla-mode’ will be the current situation of Emacs - it will try to
> be stable.

Experience shows that major changes are not as easy to revert as a
single `(vanilla-mode 1)'.

> Why? If you’re fine with the current level of changes in Emacs, that would
> be the level of changes in ‘vanilla-mode’.

What do you mean?  I haven't seen the default binding for `C-v` changed
in about 25 years.  It would be a shame if it changed now.

> I’m saying that one can add a variable like ‘expected-emacs-version’ and
> when Emacs is loading init.el and ‘expected-emacs-version’ is different
> from the current version, Emacs can warn you.

That assumes the person with the config puts that variable in, and
anyway it makes for more maintenance burden.


> No, it doesn’t. Better defaults help users and allow them to lighten their
> configuration.

There is no "better default".  There's only the default that remains
stable and so far happens to work for everyone.

> The balance I’m suggesting (actually ndame) is to add a ‘vanilla-mode’ for
> people who value stability over features.

You can't stuff major changes in a `vanilla-mode'.

> No, it doesn’t - see previous comments.

Yes it does.  I can't be bothered to put an extra line in my .emacs for
every tiny change users decide they want.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 05:06, Po Lu wrote:
>> No, it doesn’t - see previous comments.
> Yes it does.  I can't be bothered to put an extra line in my .emacs for
> every tiny change users decide they want.

Please keep in mind that if we hope to make Emacs reach, say, 30% share 
among programmers, the extra 25% would be new users.

So for all questions about changing defaults, we should ask ourselves, 
do we prioritize the existing 5% (or 3%, as SO poll says) userbase that 
will naturally continue shrinking over the years, or whether we prefer 
to make life easier and more productive for the users that should come 
later.

And it's not like existing, long-time users can't grow to like the new 
defaults (even after a certain amount of grumbling). I think the Xref 
example shows that.

Re: Making Emacs more friendly to newcomers

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Please keep in mind that if we hope to make Emacs reach, say, 30%
> share among programmers, the extra 25% would be new users.

We should prioritize existing users over hypothetical users that don't
even exist yet.

> So for all questions about changing defaults, we should ask ourselves,
> do we prioritize the existing 5% (or 3%, as SO poll says) userbase
> that will naturally continue shrinking over the years, or whether we
> prefer to make life easier and more productive for the users that
> should come later.

One exists.  The other doesn't.
Which one would you choose?

> And it's not like existing, long-time users can't grow to like the new
> defaults (even after a certain amount of grumbling). I think the Xref 
> example shows that.

Xref was bad enough.  Changing C-a to "select all" would be worse.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 07:42, Po Lu wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Please keep in mind that if we hope to make Emacs reach, say, 30%
>> share among programmers, the extra 25% would be new users.
> 
> We should prioritize existing users over hypothetical users that don't
> even exist yet.

And then, another 20 years pass, the current users get too old/change 
careers/retire/etc, and Emacs's userbase shrinks even more.

I don't want Emacs to die out, and it will if we don't do the work of 
attracting new users.

>> So for all questions about changing defaults, we should ask ourselves,
>> do we prioritize the existing 5% (or 3%, as SO poll says) userbase
>> that will naturally continue shrinking over the years, or whether we
>> prefer to make life easier and more productive for the users that
>> should come later.
> 
> One exists.  The other doesn't.
> Which one would you choose?

Also note that we don't really have the ability to poll even our 
existing users, to find out whether they would like a given change. Even 
disregarding those who would change their mind later.

>> And it's not like existing, long-time users can't grow to like the new
>> defaults (even after a certain amount of grumbling). I think the Xref
>> example shows that.
> 
> Xref was bad enough. 

Give it time.

> Changing C-a to "select all" would be worse.

I didn't talk about that, but...

I think it's possible to support two sets of keybindings. That's 
definitely extra work, though.

Including simply designing a set of bindings that is both compatible 
with CUA and yet retains the current design principles to some extent 
(so far I have no good ideas on that front).

Re: Making Emacs more friendly to newcomers

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:


> And then, another 20 years pass, the current users get too old/change
> careers/retire/etc, and Emacs's userbase shrinks even more.

I have seen people say Emacs will die by 2000 in the 90s.
I've also seen people say Emacs will die by 2010 in the 2000s.
I've also seen people say Emacs will die by 2020 in the 2010s.

Since all of those predictions of doom have consistently failed, I'm not
inclined to believe any of this either.

> I don't want Emacs to die out, and it will if we don't do the work of
> attracting new users.

And we're attracting a fair amount of new users.  What I would hate to
see is Emacs prioritizing "attracting users" over "being useful".  I'm
sure many in the community agree with me.

> Also note that we don't really have the ability to poll even our
> existing users, to find out whether they would like a given
> change. Even disregarding those who would change their mind later.

The anecdotal experience of many people I know (and I'm sure many people
on this list too) would agree that drastic changes are a bad thing.

> Give it time.

Also, Xref was actually useful in a way.  Drastic redesigning just to
attract new users does not.


> I think it's possible to support two sets of keybindings. That's
> definitely extra work, though.

We already have Cua Mode.  Having a button on the splash screen that
says "enable Cua" should be enough.

> Including simply designing a set of bindings that is both compatible
> with CUA and yet retains the current design principles to some extent 
> (so far I have no good ideas on that front).

I don't think that's possible, at least without 20 years advance notice.

Re: Making Emacs more friendly to newcomers

[Sergey Organov]

Po Lu <luangruo@yahoo.com> writes:

[...]

> And we're attracting a fair amount of new users.  What I would hate to
> see is Emacs prioritizing "attracting users" over "being useful".  I'm
> sure many in the community agree with me.

Indeed! Emacs is the only editor that I grew to like. Other editors and
IDEs I've used I grew to hate.

-- Sergey

Re: Making Emacs more friendly to newcomers

[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 for all questions about changing defaults, we should ask ourselves, 
  > do we prioritize the existing 5% (or 3%, as SO poll says) userbase that 
  > will naturally continue shrinking over the years, or whether we prefer 
  > to make life easier and more productive for the users that should come 
  > later.

This is entirely logical
if our main priority is how successful Emacs is,
rather than 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: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 06:19, Richard Stallman wrote:
>    > So for all questions about changing defaults, we should ask ourselves,
>    > do we prioritize the existing 5% (or 3%, as SO poll says) userbase that
>    > will naturally continue shrinking over the years, or whether we prefer
>    > to make life easier and more productive for the users that should come
>    > later.
> 
> This is entirely logical
> if our main priority is how successful Emacs is,
> rather than what it does.

Given that I've had multiple *useful* proposal about changing defaults 
shot down because of the worry that existing users might be 
inconvenienced (having been used to the current behavior), it's a false 
dichotomy.

Re: Making Emacs more friendly to newcomers

[Ahmed Khanzada]

> So for all questions about changing defaults, we should ask ourselves,
> do we prioritize the existing 5% (or 3%, as SO poll says) userbase that
> will naturally continue shrinking over the years, or whether we prefer
> to make life easier and more productive for the users that should come
> later.

Looking at the amount of currently maintained elisp packages online
these days, I suspect Emacs actually has more users than ever, it is
just that our segment of the overall market is smaller.

Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
VM. Is the idea that if we compete in the same modes as the modernist
editors, we can steal enough people from them that we will advance the
cause of free software?

That's not a rhetorical question, I am curious. Right now with the
status quo, we know we are at least satisfying a core audience that has
self-selected themselves as Emacs users through the hazing that is
figuring the damn thing out.

Playing towards your core audience has both benefits and drawbacks.

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 23.04.2020 10:04, Ahmed Khanzada wrote:
> Looking at the amount of currently maintained elisp packages online
> these days, I suspect Emacs actually has more users than ever, it is
> just that our segment of the overall market is smaller.

And yet, the number of core contributors stays where it was, at best.

> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
> VM. Is the idea that if we compete in the same modes as the modernist
> editors, we can steal enough people from them that we will advance the
> cause of free software?

Sure. But also how about just "help more people enjoy Emacs's power and 
flexibility"?

We don't really have to compete for the _exact_ same audience. But we 
can expand ours.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Date: Thu, 23 Apr 2020 00:04:13 -0700
> From: Ahmed Khanzada <me@enzu.ru>
> Cc: Po Lu <luangruo@yahoo.com>,
>  Sébastien Gendre <seb@k-7.ch>,
>  조성빈 <pcr910303@icloud.com>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
> VM. Is the idea that if we compete in the same modes as the modernist
> editors, we can steal enough people from them that we will advance the
> cause of free software?

More users generally means more contributors, more future developers,
and better Emacs.  And yes, it advances the cause of Free Software,
like any other free package that attracts users.

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

> On Apr 23, 2020, at 10:56 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>> From: Ahmed Khanzada <me@enzu.ru>
>> Cc: Po Lu <luangruo@yahoo.com>,
>> Sébastien Gendre <seb@k-7.ch>,
>> 조성빈 <pcr910303@icloud.com>,
>> Emacs developers <emacs-devel@gnu.org>
>> 
>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>> VM. Is the idea that if we compete in the same modes as the modernist
>> editors, we can steal enough people from them that we will advance the
>> cause of free software?
> 
> More users generally means more contributors, more future developers,
> and better Emacs.  And yes, it advances the cause of Free Software,
> like any other free package that attracts users.
> 

Exactly. New users today means people fixes bugs and implement cool features tomorrow. A very good deal.

Yuan

Re: Making Emacs more friendly to newcomers

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>> From: Ahmed Khanzada <me@enzu.ru>
>> Cc: Po Lu <luangruo@yahoo.com>,
>>  Sébastien Gendre <seb@k-7.ch>,
>>  조성빈 <pcr910303@icloud.com>,
>>  Emacs developers <emacs-devel@gnu.org>
>> 
>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>> VM. Is the idea that if we compete in the same modes as the modernist
>> editors, we can steal enough people from them that we will advance the
>> cause of free software?
>
> More users generally means more contributors, more future developers,
> and better Emacs.  And yes, it advances the cause of Free Software,
> like any other free package that attracts users.
Definitely! Users are important.

There is an interesting interviw/article in Linux Format from January
this year with Ton Roosendaal, the creator of 3D modelling/animation
package Blender. Blender went form relatively non-popular 3D application
on the verge of extinction to become a multimillion industry accepted
application. He touches on tradeoffs Blender made between "old wyas" and
more accepted "modern standards" and importance to appeal to "masses".
In sense it touches on similar questions as Emacs is faced with, so it
might be an interesting read. Just as a side note ... 

Re: Making Emacs more friendly to newcomers

[Jean-Christophe Helary]

> On Apr 28, 2020, at 1:09, Arthur Miller <arthur.miller@live.com> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Thu, 23 Apr 2020 00:04:13 -0700
>>> From: Ahmed Khanzada <me@enzu.ru>
>>> Cc: Po Lu <luangruo@yahoo.com>,
>>> Sébastien Gendre <seb@k-7.ch>,
>>> 조성빈 <pcr910303@icloud.com>,
>>> Emacs developers <emacs-devel@gnu.org>
>>> 
>>> Let's say tomorrow Emacs is like VS Code running Emacs Lisp in a Guile
>>> VM. Is the idea that if we compete in the same modes as the modernist
>>> editors, we can steal enough people from them that we will advance the
>>> cause of free software?
>> 
>> More users generally means more contributors, more future developers,
>> and better Emacs.  And yes, it advances the cause of Free Software,
>> like any other free package that attracts users.
> Definitely! Users are important.
> 
> There is an interesting interviw/article in Linux Format from January
> this year with Ton Roosendaal, the creator of 3D modelling/animation
> package Blender. Blender went form relatively non-popular 3D application
> on the verge of extinction to become a multimillion industry accepted
> application. He touches on tradeoffs Blender made between "old wyas" and
> more accepted "modern standards" and importance to appeal to "masses".
> In sense it touches on similar questions as Emacs is faced with, so it
> might be an interesting read. Just as a side note ... 

The article is here:

https://download.blender.org/documentation/pdf/LXF204.feat_3d.5cjt.pdf


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

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Sébastien Gendre <seb@k-7.ch>
> Date: Mon, 20 Apr 2020 00:44:40 +0200
> 
> - Alice: A long time user. She got a personal Emacs configuration she
>   had perfected over the years. She chose herself what system is used
>   to show function completion, which code parser is used for her daily
>   used languages. She add some packages to integrate with special
>   tools used at her work. Emacs is her home and office: She use it as
>   much for her personal project than for her work. She also made a
>   personal workflow with org-mode and write some personal Elisp
>   functions and advices. She forge the tools to her need. She do not
>   want to have an update of Emacs who break her configuration, her
>   workflow or her muscle memory.

There's a flaw in this description of how long-time Emacs users
concoct their configurations.  What's in their configuration depends
_heavily_ on the defaults: the features whose defaults satisfy such
users are never touched in the init file.  Any "vanilla" Emacs that
turns off many features will run a high risk of breaking such
configurations, because it violates the assumptions on which those
configurations rely.

At least, that's how I maintain my init files.

> For these 4 use-cases, we can simply provide 2 flavors of Emacs:
> - Emacs: With all the 2020 features, a modern interface, all needed
>   modern features to start coding with most popular languages and easy
>   to use for basic usages

The first and the most important problem with this is to identify what
you informally call "all the 2020 features, a modern interface, all
needed modern features to start coding with most popular languages and
easy to use for basic usages".  If you review past discussions on this
and related subjects, you will see that opinions on what should be
part of that set of features vary widely, so much so that I don't
believe any significant agreement is practical.  It _might_ be
possible to come up with a relatively short list of features that
could "modernize" Emacs, about which enough people will agree that
they should be part of "2020 features".  However, I'm not sure even
this limited goal is possible, and will continue to be unsure unless
and until someone comes up with such a list, and we see what's in it
and how many people agree on the list.

On top of that, the list (and the dispute to go with it) will need to
be updated with each major release.

Suppose we do have such a list -- will that be enough to make Emacs
sufficiently more attractive to Bob and his friends?  I don't know.
One problem is that we don't have many such Bob's on our team or even
reading this list, and those few who are very quickly become Alice's.
So their voice is never heard.  We don't have any HFE experts on
board, who could pretend to be a Bob.  So who will be able to
represent them and make sure the list of said features will be to
their liking?

> - Emacs Vanilla: All the new features are still there, but deactivate
>   to not break anything

I'm guessing that by "new" you mean all those "modern" features that
we don't currently turn on by default.  Otherwise, I don't see any
useful purpose for such a "vanilla" Emacs.

> And if Emacs detect, after an update or a first start, an already
> existing configuration that it could break because of some features:
> Emacs simply activate `vanilla-mode` automatically.

I don't see how Emacs can do that, when many dozens of optional
features are involved.  How do you write code that detects whether a
given feature can break something?  Ideally, we will have already
considered that, and make every effort not to break any existing
feature or muscle memory.  And who will write and maintain such code,
and update it with each release?  Are you aware of any other project
that does anything similar?

> It's just a starting point, but I think this could be a simple but
> very useful solution.

This assumes that someone does all the research and design and
implementation needed for that, and that we as a project commit to
maintaining these very non-trivial facilities for the years to come.
You may not realize it, but this is a very far cry from what we do
now.  For example, it is a long and frustrating uphill battle just to
make sure that NEWS provides information for how to get back old
behavior, for every one of those new features that do change behavior.
Please try to imagine (and describe to us, if possible) what kind of
development procedures will have to be put in place to support what
you propose, which is much more complex and problematic.

Re: Making Emacs more friendly to newcomers

[Sébastien Gendre]

Having a Vanilla-mode are maybe wore difficult than it seems.

So, let's forget Vanilla-mode and see another solution who can be more
feasible.

Maybe we can take inspiration from the work of Spacemacs and Doom
Emacs: Offer an official pre-configuration of Emacs, on the side of
Emacs itself. This pre-configuration will be more focused on new users
and
new features when Emacs itself would be more focused on stability.

Here is, in more detail, what I have in mind.

On one side, continue to develop Emacs as today :
- Keep same defaults
- If a new features is proposed, check if it break any compatibility
  or defaults
- If no, include it in Emacs
- If yes, try to modify this feature to not break any compatibility or
  defaults and if its a success, include this feature in Emacs
- If it's not possible, include the feature but deactivate it by
  default or make a package on ELPA
  
  
I don't think this side is different from what development on Emacs is
today. We can call this side Emacs vanilla, or Emacs core, or Emacs
base. Anything that reflect that this is the common base for everyone.


On another side, we can create a pre-configuration (like what
Spacemacs or Doom Emacs do) :
- All this pre-configuration is a set of files to be put inside the
  .emacs.d to start using it (like Spacemacs)
- Main goal is to have a pre-configuration that provide what is
  commonly expected from a modern text editor [1], out of the box
- Easy to use for the common tasks
- Enable some features that are not enabled by default
- Modify some defaults behaviours of Emacs to reflect more what new
  users search in a text editor
- Can include some packages from ELPA (if no legal or licence issue)
- This pre-configuration can be done by a dedicated team who
  collaborate with who work directly on Emacs
- The structure of this pre-configuration need to be made to not
  conflict with user personal configuration (ex: avoid to put anything
  in the init.el, use separate sub-directory inside .emacs.d, etc)
  
  
The actual Emacs show that the first side is possible. And projects
like Spacemacs and Doom Emacs show that the second side is also
possible. So I think this solution is feasible. And a direct
collaboration of the both side can make the process more easy.

A remaining problem is: How provide the pre-configuration easily and
out of the box for new users, without breaking long time Emacs users
configuration?

A possibility would be:
- When Emacs start, it check if a configuration already exist on the
  user directory (~/.emacs.d or ~/.emacs)
- If yes, Emacs start
- If no, Emacs restore the pre-configuration inside ~/.emacs.d then
  start

With this, new user can use the "modern, shiny, OOTB Emacs", out of
the box, by simply download and run it. And the long time user can
have a stable Emacs who don't break their configuration. For someone
who want to use Spacemacs, simply extract it as ~/.emacs.d before
start Emacs. And for someone who want to start Emacs without a
pre-configuration, simply create an empty directory for ~/.emacs.d.

Of course, the pre-configuration can be updated automatically with
Emacs. As the files of this pre-configuration are separated from user
specific configuration.

Open questions remain:
- Does the pre-configuration release cycle are synchronised with Emacs
or
  completely independent?
- Does the user can block the pre-configuration update, to avoid
  breaking its configuration based on a specific version of the
  pre-configuration?

But I think this can be a realisable solution. 

[1] List of features to be defined, but I imagine some out of the box
auto-completion, code navigation, functions documentation + functions
signatures + errors showing automatically, strong integration with git
(Magit?) and debuger, major containers engines (docker, kubernetes)
integration, etc. With a great support of the most populare
programming languages. And maybe have a special attention to integrate
with web technologies and tools for web developer.



PS: Or maybe we think to much about this problem. And making an LTS
versions of Emacs, like Ubuntu does, is the solution.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Sébastien Gendre <seb@k-7.ch>
> Date: Tue, 21 Apr 2020 14:43:47 +0200
> 
> On another side, we can create a pre-configuration (like what
> Spacemacs or Doom Emacs do) :
> - All this pre-configuration is a set of files to be put inside the
>   .emacs.d to start using it (like Spacemacs)
> - Main goal is to have a pre-configuration that provide what is
>   commonly expected from a modern text editor [1], out of the box
> - Easy to use for the common tasks
> - Enable some features that are not enabled by default
> - Modify some defaults behaviours of Emacs to reflect more what new
>   users search in a text editor
> - Can include some packages from ELPA (if no legal or licence issue)
> - This pre-configuration can be done by a dedicated team who
>   collaborate with who work directly on Emacs
> - The structure of this pre-configuration need to be made to not
>   conflict with user personal configuration (ex: avoid to put anything
>   in the init.el, use separate sub-directory inside .emacs.d, etc)

As was already said in this thread, the main problem with this is to
come up with the list of features to turn on.  Did you ask yourself
why there's Spacemacs and Doom Emacs (and a few more variants), and
not just one?  It tells us something about the commonality of
preferences.

> A remaining problem is: How provide the pre-configuration easily and
> out of the box for new users, without breaking long time Emacs users
> configuration?
> 
> A possibility would be:
> - When Emacs start, it check if a configuration already exist on the
>   user directory (~/.emacs.d or ~/.emacs)
> - If yes, Emacs start
> - If no, Emacs restore the pre-configuration inside ~/.emacs.d then
>   start

Does this mean users who download this "shiny Emacs" will be unable to
upgrade to a newer version?

> Of course, the pre-configuration can be updated automatically with
> Emacs. As the files of this pre-configuration are separated from user
> specific configuration.

So you propose to have config files that users shall never touch?  How
likely is this going to hold, what with Emacs users being very
inquisitive folks?

> [1] List of features to be defined, but I imagine some out of the box
> auto-completion, code navigation, functions documentation + functions
> signatures + errors showing automatically, strong integration with git
> (Magit?) and debuger, major containers engines (docker, kubernetes)
> integration, etc. With a great support of the most populare
> programming languages. And maybe have a special attention to integrate
> with web technologies and tools for web developer.

This is the main problem to solve, so its place is hardly in the
footnotes ;-)

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 21.04.2020 17:38, Eli Zaretskii wrote:
>> A remaining problem is: How provide the pre-configuration easily and
>> out of the box for new users, without breaking long time Emacs users
>> configuration?
>>
>> A possibility would be:
>> - When Emacs start, it check if a configuration already exist on the
>>    user directory (~/.emacs.d or ~/.emacs)
>> - If yes, Emacs start
>> - If no, Emacs restore the pre-configuration inside ~/.emacs.d then
>>    start
> Does this mean users who download this "shiny Emacs" will be unable to
> upgrade to a newer version?

The pre-configuration could contain just one line:

   (require 'shiny-settings)

where shiny-settings.el is distributed with Emacs and is updated 
together with new releases.

Although, after 5-10 years pass, we'll surely encounter users of 
previous versions unhappy with changes to their shiny-settings too. :-)

Re: Making Emacs more friendly to newcomers

[Stefan Monnier]

> The pre-configuration could contain just one line:
>
>   (require 'shiny-settings)

Nitpick: `require` is *really* not the right job since just loading
a file should not change Emacs's behavior substantially.

Ideally, it should be a custom-theme, but second best could be
a minor-mode.


        Stefan

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 22 Apr 2020 04:35:48 +0300
> 
> > Does this mean users who download this "shiny Emacs" will be unable to
> > upgrade to a newer version?
> 
> The pre-configuration could contain just one line:
> 
>    (require 'shiny-settings)
> 
> where shiny-settings.el is distributed with Emacs and is updated 
> together with new releases.

So we expect users not to customize their Emacs, as long as they use
the "shiny Emacs"?  What are the chances of that to work?

Re: Making Emacs more friendly to newcomers

[chad]

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

On Wed, Apr 22, 2020 at 6:27 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: emacs-devel@gnu.org
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Wed, 22 Apr 2020 04:35:48 +0300
> >
> > > Does this mean users who download this "shiny Emacs" will be unable to
> > > upgrade to a newer version?
> >
> > The pre-configuration could contain just one line:
> >
> >    (require 'shiny-settings)
> >
> > where shiny-settings.el is distributed with Emacs and is updated
> > together with new releases.
>
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?
>

Spacemacs, Doom, and Prelude (to name just three of the more popular
options) all make this work out-of-tree, so it certainly seems possible.
From my reading, the first two (at least) are strongly expected to be
customized after installation, and to have those customizations survive
updates of the "kit".

Spacemacs in particular adds a "layer" concept to emacs customization so
that bundles of related options/code/packages/config can be turned on or
off as a group.  Details can be found at:
https://www.spacemacs.org/doc/LAYERS.html. I would personally hope that we
could streamline this process, which seems pretty bulky from the outside.
Maybe inviting the Spacemacs people to share their experience that led to
creating their layers system would be helpful to us both. (I would have
CC'd them onthis message, but their team seems to be heavily based around
github (pull requests, gitter sharing, etc.), so it's not obvious to me
whom to contact. I can look into finding a contact if people think it's
worthwhile.

~Chad

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

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

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



> On Apr 22, 2020, at 1:46 PM, chad <yandros@gmail.com> wrote:
> 
> On Wed, Apr 22, 2020 at 6:27 AM Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> wrote:
> > Cc: emacs-devel@gnu.org <mailto:emacs-devel@gnu.org>
> > From: Dmitry Gutov <dgutov@yandex.ru <mailto:dgutov@yandex.ru>>
> > Date: Wed, 22 Apr 2020 04:35:48 +0300
> > 
> > > Does this mean users who download this "shiny Emacs" will be unable to
> > > upgrade to a newer version?
> > 
> > The pre-configuration could contain just one line:
> > 
> >    (require 'shiny-settings)
> > 
> > where shiny-settings.el is distributed with Emacs and is updated 
> > together with new releases.
> 
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?
> 
> Spacemacs, Doom, and Prelude (to name just three of the more popular options) all make this work out-of-tree, so it certainly seems possible. From my reading, the first two (at least) are strongly expected to be customized after installation, and to have those customizations survive updates of the "kit".
> 
> Spacemacs in particular adds a "layer" concept to emacs customization so that bundles of related options/code/packages/config can be turned on or off as a group.  Details can be found at: https://www.spacemacs.org/doc/LAYERS.html <https://www.spacemacs.org/doc/LAYERS.html>. I would personally hope that we could streamline this process, which seems pretty bulky from the outside. Maybe inviting the Spacemacs people to share their experience that led to creating their layers system would be helpful to us both. (I would have CC'd them onthis message, but their team seems to be heavily based around github (pull requests, gitter sharing, etc.), so it's not obvious to me whom to contact. I can look into finding a contact if people think it's worthwhile.
> 
> ~Chad
> 

I’ve used Spacemacs for quite a while back in 2017 when I just started using Emacs. It’s more of a gigantic community-driven config than an out-of-box for-dummy kit. What I envisioned is more like what VSCode does: automatically installing appropriate packages and downloading and setting up external programs. I would use it if there is such feature - many of my configs are just (use-package package) with some code adding hooks and auto-mode-alist.

Some ideas: 
1. Is it ok to include MELPA (opt-in) as one of the mirrors? Say a newbie type M-x auto-package-mode, and boom, all the auto installing package features are on, and MELPA is added to package-archives. 
2. Could Emacs downloads some external programs (like LSP servers) for users? I would definitely let Emacs do the dirty work if it works reliably. But maybe there are security/maintenance concerns.
3. It would be cool if Customize can customize mode hooks and auto-mode-alist and other usual stuff.

Yuan



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

Re: Making Emacs more friendly to newcomers

[chad]

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

On Wed, Apr 22, 2020 at 3:52 PM Yuan Fu <casouri@gmail.com> wrote:

>
> Some ideas:
> 3. It would be cool if Customize can customize mode hooks and
> auto-mode-alist and other usual stuff.
>

It seems like most elisp packages could come with a standardized "Here's
the normal setup for this mode/package; would you like to run it now, have
it run on each startup, or see a new buffer where you can examine it now?",
analogous to how customize-theme prompts to
disallow/allow-once/allow-always code upon loading the theme. (Honestly, I
assume this never happened because most emacs devs seem to prefer
managing snippets of elisp over using customize.) Use-package gets part of
the way there; seems like it could easily get the typical setup hooks for a
package from the package itself.

~Chad

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

Re: Making Emacs more friendly to newcomers

[Yuan Fu]

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



> On Apr 22, 2020, at 8:12 PM, chad <yandros@gmail.com> wrote:
> 
> 
> On Wed, Apr 22, 2020 at 3:52 PM Yuan Fu <casouri@gmail.com <mailto:casouri@gmail.com>> wrote:
> 
> Some ideas: 
> 3. It would be cool if Customize can customize mode hooks and auto-mode-alist and other usual stuff.
> 
> It seems like most elisp packages could come with a standardized "Here's the normal setup for this mode/package; would you like to run it now, have it run on each startup, or see a new buffer where you can examine it now?", analogous to how customize-theme prompts to disallow/allow-once/allow-always code upon loading the theme.

If Customize can provide a interface, I’m sure packages will (slowly) adapt to it, just as they adapt to defcustom.

> (Honestly, I assume this never happened because most emacs devs seem to prefer managing snippets of elisp over using customize.)

Mainly for maintenance reasons, I guess. Custom file is usually not version-controlled. That’s not necessarily a bad thing, I find Customize useful for storing local configurations that could differ between machines (executable paths, etc). Maybe Customize could separate into two files, one version controlled, one local. And I can put many of my random setq’s into Customize. 




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

Re: Making Emacs more friendly to newcomers

[Dmitry Gutov]

On 22.04.2020 16:22, Eli Zaretskii wrote:
>> The pre-configuration could contain just one line:
>>
>>     (require 'shiny-settings)
>>
>> where shiny-settings.el is distributed with Emacs and is updated
>> together with new releases.
> So we expect users not to customize their Emacs, as long as they use
> the "shiny Emacs"?  What are the chances of that to work?

Just make sure the custom file is loaded after.

Re: Making Emacs more friendly to newcomers

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 조성빈 <pcr910303@icloud.com>,  Richard Stallman
>  <rms@gnu.org>,  Ahmed Khanzada <me@enzu.ru>,  "joseph.h.garvin@gmail.com"
>  <joseph.h.garvin@gmail.com>,  "stefan@marxist.se" <stefan@marxist.se>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>,  "eliz@gnu.org"
>  <eliz@gnu.org>,  "drew.adams@oracle.com" <drew.adams@oracle.com>
> Date: Sun, 19 Apr 2020 16:21:40 +0800
> 
> Again: what's wrong with putting a button on the splash screen?

Nothing.  The only problem is to decide what will that button
activate.  I think you will find that opinions vary widely about that.

P.S. And why does every message from you get sent twice to each
addressee?

RE: Making Emacs more friendly to newcomers

[Drew Adams]

> P.S. And why does every message from you get sent twice to each
> addressee?

+1

Re: Making Emacs more friendly to newcomers

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Nothing.  The only problem is to decide what will that button
> activate.  I think you will find that opinions vary widely about that.

Well, for starters things like CUA mode, maybe a hypothetical `gtk'
theme, and other things like that.  But that will likely require a lot
of debate yes.

> P.S. And why does every message from you get sent twice to each
> addressee?

I'm not sure, I'll look into it.  Sorry!

Re: Making Emacs more friendly to newcomers

[Po Lu]

조성빈 <pcr910303@icloud.com> writes:

> I personally find that the stance of trying to not breaking anything is
> one of the big reasons that Emacs has a nonusable-without-configuration UX.
> Major version numbers are there for a reason… and we can expect for annoyed
> people to set some variables to get old behavior.

Major version numbers are there to announce new features.  With massive
changes (such as the ones that are being proposed here), you can't just
"flip a variable to get the old behaviour".  Especially people with 20
years of muscle memory and 200,000+ line configs.

Again: what's wrong with the "if you're new to Emacs, click here" button?