* Re: Making Emacs more friendly to newcomers
@ 2020-04-20 6:22 ndame
2020-04-20 10:08 ` Po Lu
0 siblings, 1 reply; 108+ messages in thread
From: ndame @ 2020-04-20 6:22 UTC (permalink / raw)
To: Emacs developers
[-- 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 --]
^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 6:22 Making Emacs more friendly to newcomers ndame @ 2020-04-20 10:08 ` Po Lu 2020-04-21 1:50 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-20 10:08 UTC (permalink / raw) To: ndame; +Cc: Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 10:08 ` Po Lu @ 2020-04-21 1:50 ` Richard Stallman 2020-04-21 2:09 ` Po Lu 2020-04-21 2:10 ` Dmitry Gutov 0 siblings, 2 replies; 108+ messages in thread From: Richard Stallman @ 2020-04-21 1:50 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel, ndame [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 1:50 ` Richard Stallman @ 2020-04-21 2:09 ` Po Lu 2020-04-21 8:44 ` Theodor Thornhill 2020-04-21 2:10 ` Dmitry Gutov 1 sibling, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-21 2:09 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:09 ` Po Lu @ 2020-04-21 8:44 ` Theodor Thornhill 2020-04-22 4:30 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: Theodor Thornhill @ 2020-04-21 8:44 UTC (permalink / raw) To: Po Lu, Richard Stallman; +Cc: emacs-devel, ndame "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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 8:44 ` Theodor Thornhill @ 2020-04-22 4:30 ` Po Lu 2020-04-22 7:01 ` Theodor Thornhill ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: Po Lu @ 2020-04-22 4:30 UTC (permalink / raw) To: Theodor Thornhill; +Cc: Richard Stallman, emacs-devel, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 4:30 ` Po Lu @ 2020-04-22 7:01 ` Theodor Thornhill 2020-04-23 3:10 ` Po Lu 2020-04-22 16:45 ` Stefan Monnier 2020-04-24 2:34 ` Richard Stallman 2 siblings, 1 reply; 108+ messages in thread From: Theodor Thornhill @ 2020-04-22 7:01 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel, ndame "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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 7:01 ` Theodor Thornhill @ 2020-04-23 3:10 ` Po Lu 0 siblings, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-23 3:10 UTC (permalink / raw) To: Theodor Thornhill; +Cc: emacs-devel, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 4:30 ` Po Lu 2020-04-22 7:01 ` Theodor Thornhill @ 2020-04-22 16:45 ` Stefan Monnier 2020-04-22 17:16 ` Dmitry Gutov ` (2 more replies) 2020-04-24 2:34 ` Richard Stallman 2 siblings, 3 replies; 108+ messages in thread From: Stefan Monnier @ 2020-04-22 16:45 UTC (permalink / raw) To: Po Lu; +Cc: ndame, Richard Stallman, Theodor Thornhill, emacs-devel >> 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 16:45 ` Stefan Monnier @ 2020-04-22 17:16 ` Dmitry Gutov 2020-04-23 3:11 ` Po Lu 2020-04-26 18:40 ` Yuan Fu 2 siblings, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-22 17:16 UTC (permalink / raw) To: Stefan Monnier, Po Lu Cc: emacs-devel, Richard Stallman, Theodor Thornhill, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 16:45 ` Stefan Monnier 2020-04-22 17:16 ` Dmitry Gutov @ 2020-04-23 3:11 ` Po Lu 2020-04-23 12:55 ` Stefan Monnier 2020-04-26 18:40 ` Yuan Fu 2 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-23 3:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: ndame, Richard Stallman, Theodor Thornhill, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 3:11 ` Po Lu @ 2020-04-23 12:55 ` Stefan Monnier 2020-04-24 5:24 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: Stefan Monnier @ 2020-04-23 12:55 UTC (permalink / raw) To: Po Lu; +Cc: emacs-devel, Richard Stallman, Theodor Thornhill, ndame >> 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 12:55 ` Stefan Monnier @ 2020-04-24 5:24 ` Po Lu 0 siblings, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-24 5:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: ndame, Richard Stallman, Theodor Thornhill, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 16:45 ` Stefan Monnier 2020-04-22 17:16 ` Dmitry Gutov 2020-04-23 3:11 ` Po Lu @ 2020-04-26 18:40 ` Yuan Fu 2020-04-27 4:00 ` Stefan Monnier 2 siblings, 1 reply; 108+ messages in thread From: Yuan Fu @ 2020-04-26 18:40 UTC (permalink / raw) To: Stefan Monnier Cc: Po Lu, emacs-devel, Richard Stallman, Theodor Thornhill, ndame > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-26 18:40 ` Yuan Fu @ 2020-04-27 4:00 ` Stefan Monnier 0 siblings, 0 replies; 108+ messages in thread From: Stefan Monnier @ 2020-04-27 4:00 UTC (permalink / raw) To: Yuan Fu; +Cc: Po Lu, emacs-devel, Richard Stallman, Theodor Thornhill, ndame > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 4:30 ` Po Lu 2020-04-22 7:01 ` Theodor Thornhill 2020-04-22 16:45 ` Stefan Monnier @ 2020-04-24 2:34 ` Richard Stallman 2020-04-24 2:39 ` 조성빈 2 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-24 2:34 UTC (permalink / raw) To: Po Lu; +Cc: ndame, theothornhill, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-24 2:34 ` Richard Stallman @ 2020-04-24 2:39 ` 조성빈 2020-04-24 2:42 ` 조성빈 ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: 조성빈 @ 2020-04-24 2:39 UTC (permalink / raw) To: Richard Stallman; +Cc: Po Lu, ndame, theothornhill, emacs-devel 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-24 2:39 ` 조성빈 @ 2020-04-24 2:42 ` 조성빈 2020-04-24 7:33 ` Theodor Thornhill 2020-04-25 3:30 ` Richard Stallman 2 siblings, 0 replies; 108+ messages in thread From: 조성빈 @ 2020-04-24 2:42 UTC (permalink / raw) To: Richard Stallman; +Cc: Po Lu, ndame, theothornhill, emacs-devel 조성빈 <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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-24 2:39 ` 조성빈 2020-04-24 2:42 ` 조성빈 @ 2020-04-24 7:33 ` Theodor Thornhill 2020-04-25 3:30 ` Richard Stallman 2 siblings, 0 replies; 108+ messages in thread From: Theodor Thornhill @ 2020-04-24 7:33 UTC (permalink / raw) To: 조성빈, Richard Stallman; +Cc: Po Lu, ndame, emacs-devel 조성빈 <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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-24 2:39 ` 조성빈 2020-04-24 2:42 ` 조성빈 2020-04-24 7:33 ` Theodor Thornhill @ 2020-04-25 3:30 ` Richard Stallman 2020-04-25 3:32 ` 조성빈 2 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-25 3:30 UTC (permalink / raw) To: ì¡°ì±ë¹ Cc: luangruo, emacs-devel, theothornhill, ndame [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-25 3:30 ` Richard Stallman @ 2020-04-25 3:32 ` 조성빈 2020-04-26 3:19 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: 조성빈 @ 2020-04-25 3:32 UTC (permalink / raw) To: Richard Stallman; +Cc: Po Lu, ndame, theothornhill, emacs-devel 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-25 3:32 ` 조성빈 @ 2020-04-26 3:19 ` Richard Stallman 2020-04-26 14:32 ` Dmitry Gutov 0 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-26 3:19 UTC (permalink / raw) To: ì¡°ì±ë¹ Cc: luangruo, emacs-devel, theothornhill, ndame [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-26 3:19 ` Richard Stallman @ 2020-04-26 14:32 ` Dmitry Gutov 2020-04-26 15:14 ` tomas 0 siblings, 1 reply; 108+ messages in thread From: Dmitry Gutov @ 2020-04-26 14:32 UTC (permalink / raw) To: rms, 조성빈 Cc: luangruo, ndame, theothornhill, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-26 14:32 ` Dmitry Gutov @ 2020-04-26 15:14 ` tomas 2020-04-26 16:32 ` Dmitry Gutov 0 siblings, 1 reply; 108+ messages in thread From: tomas @ 2020-04-26 15:14 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-26 15:14 ` tomas @ 2020-04-26 16:32 ` Dmitry Gutov 2020-04-26 16:36 ` tomas 0 siblings, 1 reply; 108+ messages in thread From: Dmitry Gutov @ 2020-04-26 16:32 UTC (permalink / raw) To: tomas, emacs-devel 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. :-( ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-26 16:32 ` Dmitry Gutov @ 2020-04-26 16:36 ` tomas 0 siblings, 0 replies; 108+ messages in thread From: tomas @ 2020-04-26 16:36 UTC (permalink / raw) To: Dmitry Gutov; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 1:50 ` Richard Stallman 2020-04-21 2:09 ` Po Lu @ 2020-04-21 2:10 ` Dmitry Gutov 2020-04-21 3:45 ` Stefan Monnier 2020-04-22 3:19 ` Richard Stallman 1 sibling, 2 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-21 2:10 UTC (permalink / raw) To: rms, Po Lu; +Cc: ndame, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:10 ` Dmitry Gutov @ 2020-04-21 3:45 ` Stefan Monnier 2020-04-21 4:44 ` chad 2020-04-22 3:19 ` Richard Stallman 1 sibling, 1 reply; 108+ messages in thread From: Stefan Monnier @ 2020-04-21 3:45 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Po Lu, emacs-devel, rms, ndame >> 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 3:45 ` Stefan Monnier @ 2020-04-21 4:44 ` chad 0 siblings, 0 replies; 108+ messages in thread From: chad @ 2020-04-21 4:44 UTC (permalink / raw) To: Stefan Monnier Cc: Po Lu, ndame, EMACS development team, Richard Stallman, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:10 ` Dmitry Gutov 2020-04-21 3:45 ` Stefan Monnier @ 2020-04-22 3:19 ` Richard Stallman 2020-04-22 3:31 ` Dmitry Gutov 1 sibling, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-22 3:19 UTC (permalink / raw) To: Dmitry Gutov; +Cc: luangruo, ndame, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 3:19 ` Richard Stallman @ 2020-04-22 3:31 ` Dmitry Gutov 0 siblings, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-22 3:31 UTC (permalink / raw) To: rms; +Cc: luangruo, ndame, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers
@ 2020-04-27 17:50 ndame
2020-04-27 18:07 ` Arthur Miller
` (2 more replies)
0 siblings, 3 replies; 108+ messages in thread
From: ndame @ 2020-04-27 17:50 UTC (permalink / raw)
To: Emacs developers
> 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.
^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-27 17:50 ndame @ 2020-04-27 18:07 ` Arthur Miller 2020-04-28 0:13 ` Dmitry Gutov 2020-04-30 2:26 ` Richard Stallman 2 siblings, 0 replies; 108+ messages in thread From: Arthur Miller @ 2020-04-27 18:07 UTC (permalink / raw) To: ndame; +Cc: Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-27 17:50 ndame 2020-04-27 18:07 ` Arthur Miller @ 2020-04-28 0:13 ` Dmitry Gutov 2020-04-30 2:26 ` Richard Stallman 2 siblings, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-28 0:13 UTC (permalink / raw) To: ndame, Emacs developers 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 certainly save money if you wanted to, but I see it as an opportunity to take a portion of the budget and redirect it to our core software. We truly hope that others will take the development work we’ve put in and push it further.” > There are obvious similarities with Emacs' current situation. I also see a lot of parallels between the programs themselves. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-27 17:50 ndame 2020-04-27 18:07 ` Arthur Miller 2020-04-28 0:13 ` Dmitry Gutov @ 2020-04-30 2:26 ` Richard Stallman 2020-04-30 5:58 ` ndame 2 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-30 2:26 UTC (permalink / raw) To: ndame; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-30 2:26 ` Richard Stallman @ 2020-04-30 5:58 ` ndame 2020-05-02 2:21 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: ndame @ 2020-04-30 5:58 UTC (permalink / raw) To: rms@gnu.org; +Cc: emacs-devel@gnu.org > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-30 5:58 ` ndame @ 2020-05-02 2:21 ` Richard Stallman 2020-05-02 15:52 ` Arthur Miller 0 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-05-02 2:21 UTC (permalink / raw) To: ndame; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 2:21 ` Richard Stallman @ 2020-05-02 15:52 ` Arthur Miller 2020-05-02 15:59 ` Dmitry Gutov ` (3 more replies) 0 siblings, 4 replies; 108+ messages in thread From: Arthur Miller @ 2020-05-02 15:52 UTC (permalink / raw) To: Richard Stallman; +Cc: emacs-devel, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 15:52 ` Arthur Miller @ 2020-05-02 15:59 ` Dmitry Gutov 2020-05-02 17:00 ` Arthur Miller 2020-05-02 16:25 ` ndame ` (2 subsequent siblings) 3 siblings, 1 reply; 108+ messages in thread From: Dmitry Gutov @ 2020-05-02 15:59 UTC (permalink / raw) To: Arthur Miller, Richard Stallman; +Cc: ndame, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 15:59 ` Dmitry Gutov @ 2020-05-02 17:00 ` Arthur Miller 2020-05-02 18:20 ` Dmitry Gutov 0 siblings, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-05-02 17:00 UTC (permalink / raw) To: Dmitry Gutov; +Cc: ndame, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 17:00 ` Arthur Miller @ 2020-05-02 18:20 ` Dmitry Gutov 2020-05-02 18:55 ` Arthur Miller 0 siblings, 1 reply; 108+ messages in thread From: Dmitry Gutov @ 2020-05-02 18:20 UTC (permalink / raw) To: Arthur Miller; +Cc: ndame, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 18:20 ` Dmitry Gutov @ 2020-05-02 18:55 ` Arthur Miller 2020-05-04 3:05 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-05-02 18:55 UTC (permalink / raw) To: Dmitry Gutov; +Cc: ndame, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 18:55 ` Arthur Miller @ 2020-05-04 3:05 ` Richard Stallman 2020-05-05 14:08 ` Arthur Miller 0 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-05-04 3:05 UTC (permalink / raw) To: Arthur Miller; +Cc: ndame, emacs-devel, dgutov [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-04 3:05 ` Richard Stallman @ 2020-05-05 14:08 ` Arthur Miller 2020-05-06 4:46 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-05-05 14:08 UTC (permalink / raw) To: Richard Stallman; +Cc: ndame, emacs-devel, dgutov 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). ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-05 14:08 ` Arthur Miller @ 2020-05-06 4:46 ` Richard Stallman 2020-05-06 18:14 ` Nikita Mogilevsky 0 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-05-06 4:46 UTC (permalink / raw) To: Arthur Miller; +Cc: emacs-devel, dgutov, ndame [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-06 4:46 ` Richard Stallman @ 2020-05-06 18:14 ` Nikita Mogilevsky 2020-05-07 2:48 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: Nikita Mogilevsky @ 2020-05-06 18:14 UTC (permalink / raw) To: rms; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-06 18:14 ` Nikita Mogilevsky @ 2020-05-07 2:48 ` Richard Stallman 0 siblings, 0 replies; 108+ messages in thread From: Richard Stallman @ 2020-05-07 2:48 UTC (permalink / raw) To: Nikita Mogilevsky; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 15:52 ` Arthur Miller 2020-05-02 15:59 ` Dmitry Gutov @ 2020-05-02 16:25 ` ndame 2020-05-02 19:04 ` Drew Adams 2020-05-03 3:42 ` Richard Stallman 3 siblings, 0 replies; 108+ messages in thread From: ndame @ 2020-05-02 16:25 UTC (permalink / raw) To: Arthur Miller; +Cc: Richard Stallman, emacs-devel@gnu.org > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Making Emacs more friendly to newcomers 2020-05-02 15:52 ` Arthur Miller 2020-05-02 15:59 ` Dmitry Gutov 2020-05-02 16:25 ` ndame @ 2020-05-02 19:04 ` Drew Adams 2020-05-02 19:36 ` Arthur Miller 2020-05-03 3:42 ` Richard Stallman 3 siblings, 1 reply; 108+ messages in thread From: Drew Adams @ 2020-05-02 19:04 UTC (permalink / raw) To: Arthur Miller, Richard Stallman; +Cc: ndame, emacs-devel > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 19:04 ` Drew Adams @ 2020-05-02 19:36 ` Arthur Miller 2020-05-02 20:05 ` Drew Adams 0 siblings, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-05-02 19:36 UTC (permalink / raw) To: Drew Adams; +Cc: ndame, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Making Emacs more friendly to newcomers 2020-05-02 19:36 ` Arthur Miller @ 2020-05-02 20:05 ` Drew Adams 2020-05-02 21:16 ` Arthur Miller 0 siblings, 1 reply; 108+ messages in thread From: Drew Adams @ 2020-05-02 20:05 UTC (permalink / raw) To: Arthur Miller; +Cc: ndame, Richard Stallman, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 20:05 ` Drew Adams @ 2020-05-02 21:16 ` Arthur Miller 2020-05-02 22:16 ` Drew Adams 0 siblings, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-05-02 21:16 UTC (permalink / raw) To: Drew Adams; +Cc: ndame, Richard Stallman, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Making Emacs more friendly to newcomers 2020-05-02 21:16 ` Arthur Miller @ 2020-05-02 22:16 ` Drew Adams 0 siblings, 0 replies; 108+ messages in thread From: Drew Adams @ 2020-05-02 22:16 UTC (permalink / raw) To: Arthur Miller; +Cc: emacs-devel, Richard Stallman, ndame > 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. ;-) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-02 15:52 ` Arthur Miller ` (2 preceding siblings ...) 2020-05-02 19:04 ` Drew Adams @ 2020-05-03 3:42 ` Richard Stallman 2020-05-05 13:58 ` Arthur Miller 3 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-05-03 3:42 UTC (permalink / raw) To: Arthur Miller; +Cc: ndame, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-05-03 3:42 ` Richard Stallman @ 2020-05-05 13:58 ` Arthur Miller 0 siblings, 0 replies; 108+ messages in thread From: Arthur Miller @ 2020-05-05 13:58 UTC (permalink / raw) To: Richard Stallman; +Cc: ndame, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers @ 2020-04-21 15:27 ndame 2020-04-22 3:14 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: ndame @ 2020-04-21 15:27 UTC (permalink / raw) To: Emacs developers > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 15:27 ndame @ 2020-04-22 3:14 ` Richard Stallman 0 siblings, 0 replies; 108+ messages in thread From: Richard Stallman @ 2020-04-22 3:14 UTC (permalink / raw) To: ndame; +Cc: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: "Why is emacs so square?"
@ 2020-04-16 14:58 Drew Adams
2020-04-16 15:34 ` Joseph Garvin
0 siblings, 1 reply; 108+ messages in thread
From: Drew Adams @ 2020-04-16 14:58 UTC (permalink / raw)
To: Eli Zaretskii, rms; +Cc: emacs-devel, stefan, ndame
> 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.
^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: "Why is emacs so square?" 2020-04-16 14:58 "Why is emacs so square?" Drew Adams @ 2020-04-16 15:34 ` Joseph Garvin 2020-04-17 22:05 ` Ahmed Khanzada 0 siblings, 1 reply; 108+ messages in thread From: Joseph Garvin @ 2020-04-16 15:34 UTC (permalink / raw) To: Drew Adams; +Cc: Eli Zaretskii, ndame, stefan, rms, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: "Why is emacs so square?" 2020-04-16 15:34 ` Joseph Garvin @ 2020-04-17 22:05 ` Ahmed Khanzada 2020-04-19 2:18 ` Richard Stallman 0 siblings, 1 reply; 108+ messages in thread From: Ahmed Khanzada @ 2020-04-17 22:05 UTC (permalink / raw) To: Joseph Garvin; +Cc: rms, stefan, emacs-devel, Eli Zaretskii, Drew Adams, ndame 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: "Why is emacs so square?" 2020-04-17 22:05 ` Ahmed Khanzada @ 2020-04-19 2:18 ` Richard Stallman 2020-04-19 2:33 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-19 2:18 UTC (permalink / raw) To: Ahmed Khanzada Cc: joseph.h.garvin, stefan, emacs-devel, eliz, drew.adams, ndame [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: "Why is emacs so square?" 2020-04-19 2:18 ` Richard Stallman @ 2020-04-19 2:33 ` Po Lu 2020-04-19 4:55 ` ndame 0 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-19 2:33 UTC (permalink / raw) To: Richard Stallman Cc: Ahmed Khanzada, joseph.h.garvin, stefan, emacs-devel, eliz, drew.adams, ndame [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: "Why is emacs so square?" 2020-04-19 2:33 ` Po Lu @ 2020-04-19 4:55 ` ndame 2020-04-19 6:14 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") Po Lu 0 siblings, 1 reply; 108+ messages in thread From: ndame @ 2020-04-19 4:55 UTC (permalink / raw) To: Po Lu Cc: Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 2020-04-19 4:55 ` ndame @ 2020-04-19 6:14 ` Po Lu 2020-04-19 6:54 ` Eduardo Ochs 2020-04-19 8:05 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 조성빈 0 siblings, 2 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 6:14 UTC (permalink / raw) To: ndame Cc: Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.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. 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 2020-04-19 6:14 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") Po Lu @ 2020-04-19 6:54 ` Eduardo Ochs 2020-04-19 7:22 ` Making Emacs more friendly to newcomers Po Lu 2020-04-19 8:05 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 조성빈 1 sibling, 1 reply; 108+ messages in thread From: Eduardo Ochs @ 2020-04-19 6:54 UTC (permalink / raw) To: Po Lu Cc: Ahmed Khanzada, joseph.h.garvin@gmail.com, Richard Stallman, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com, ndame 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. > ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 6:54 ` Eduardo Ochs @ 2020-04-19 7:22 ` Po Lu 0 siblings, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 7:22 UTC (permalink / raw) To: Eduardo Ochs Cc: ndame, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 2020-04-19 6:14 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") Po Lu 2020-04-19 6:54 ` Eduardo Ochs @ 2020-04-19 8:05 ` 조성빈 2020-04-19 8:12 ` ndame 2020-04-19 8:16 ` Po Lu 1 sibling, 2 replies; 108+ messages in thread From: 조성빈 @ 2020-04-19 8:05 UTC (permalink / raw) To: Po Lu Cc: ndame, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 2020-04-19 8:05 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 조성빈 @ 2020-04-19 8:12 ` ndame 2020-04-19 8:21 ` Making Emacs more friendly to newcomers Po Lu 2020-04-19 8:16 ` Po Lu 1 sibling, 1 reply; 108+ messages in thread From: ndame @ 2020-04-19 8:12 UTC (permalink / raw) To: 조성빈 Cc: Po Lu, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:12 ` ndame @ 2020-04-19 8:21 ` Po Lu 2020-04-19 8:25 ` ndame 2020-04-19 13:35 ` Eli Zaretskii 0 siblings, 2 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 8:21 UTC (permalink / raw) To: ndame Cc: 조성빈, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com 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? ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:21 ` Making Emacs more friendly to newcomers Po Lu @ 2020-04-19 8:25 ` ndame 2020-04-19 9:30 ` Po Lu 2020-04-19 22:44 ` Sébastien Gendre 2020-04-19 13:35 ` Eli Zaretskii 1 sibling, 2 replies; 108+ messages in thread From: ndame @ 2020-04-19 8:25 UTC (permalink / raw) To: Po Lu Cc: 조성빈, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com > > > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:25 ` ndame @ 2020-04-19 9:30 ` Po Lu 2020-04-19 22:44 ` Sébastien Gendre 1 sibling, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 9:30 UTC (permalink / raw) To: ndame Cc: 조성빈, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:25 ` ndame 2020-04-19 9:30 ` Po Lu @ 2020-04-19 22:44 ` Sébastien Gendre 2020-04-20 0:36 ` Stefan Kangas ` (2 more replies) 1 sibling, 3 replies; 108+ messages in thread From: Sébastien Gendre @ 2020-04-19 22:44 UTC (permalink / raw) To: emacs-devel # 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 22:44 ` Sébastien Gendre @ 2020-04-20 0:36 ` Stefan Kangas 2020-04-20 3:32 ` Tim Cross 2020-04-20 4:53 ` Po Lu 2020-04-20 14:22 ` Eli Zaretskii 2 siblings, 1 reply; 108+ messages in thread From: Stefan Kangas @ 2020-04-20 0:36 UTC (permalink / raw) To: Sébastien Gendre; +Cc: Emacs developers 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 0:36 ` Stefan Kangas @ 2020-04-20 3:32 ` Tim Cross 2020-04-20 9:54 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: Tim Cross @ 2020-04-20 3:32 UTC (permalink / raw) To: Stefan Kangas; +Cc: Sébastien Gendre, Emacs developers [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 3:32 ` Tim Cross @ 2020-04-20 9:54 ` Po Lu 2020-04-20 13:50 ` Stefan Monnier 0 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-20 9:54 UTC (permalink / raw) To: Tim Cross; +Cc: Stefan Kangas, Sébastien Gendre, Emacs developers 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). ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 9:54 ` Po Lu @ 2020-04-20 13:50 ` Stefan Monnier 2020-04-21 8:52 ` Po Lu 2020-04-21 13:57 ` Simen Heggestøyl 0 siblings, 2 replies; 108+ messages in thread From: Stefan Monnier @ 2020-04-20 13:50 UTC (permalink / raw) To: Po Lu; +Cc: Tim Cross, Stefan Kangas, Sébastien Gendre, Emacs developers 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 13:50 ` Stefan Monnier @ 2020-04-21 8:52 ` Po Lu 2020-04-21 13:57 ` Simen Heggestøyl 1 sibling, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-21 8:52 UTC (permalink / raw) To: Stefan Monnier Cc: Tim Cross, Stefan Kangas, Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 13:50 ` Stefan Monnier 2020-04-21 8:52 ` Po Lu @ 2020-04-21 13:57 ` Simen Heggestøyl 2020-04-21 15:36 ` Yuan Fu 1 sibling, 1 reply; 108+ messages in thread From: Simen Heggestøyl @ 2020-04-21 13:57 UTC (permalink / raw) To: Stefan Monnier Cc: Po Lu, Tim Cross, Stefan Kangas, Sébastien Gendre, Emacs developers 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 13:57 ` Simen Heggestøyl @ 2020-04-21 15:36 ` Yuan Fu 2020-04-22 3:14 ` Richard Stallman 2020-04-22 4:33 ` Po Lu 0 siblings, 2 replies; 108+ messages in thread From: Yuan Fu @ 2020-04-21 15:36 UTC (permalink / raw) To: Simen Heggestøyl Cc: Tim Cross, Stefan Kangas, Emacs developers, Po Lu, Stefan Monnier, Sébastien Gendre > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 15:36 ` Yuan Fu @ 2020-04-22 3:14 ` Richard Stallman 2020-04-22 4:33 ` Po Lu 1 sibling, 0 replies; 108+ messages in thread From: Richard Stallman @ 2020-04-22 3:14 UTC (permalink / raw) To: Yuan Fu; +Cc: theophilusx, stefan, emacs-devel, luangruo, monnier, seb, simenheg [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 15:36 ` Yuan Fu 2020-04-22 3:14 ` Richard Stallman @ 2020-04-22 4:33 ` Po Lu 2020-04-23 6:33 ` Ahmed Khanzada 1 sibling, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-22 4:33 UTC (permalink / raw) To: Yuan Fu Cc: Simen Heggestøyl, Stefan Monnier, Tim Cross, Stefan Kangas, Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 4:33 ` Po Lu @ 2020-04-23 6:33 ` Ahmed Khanzada 2020-04-23 10:14 ` Stefan Kangas 2020-04-23 14:55 ` Eli Zaretskii 0 siblings, 2 replies; 108+ messages in thread From: Ahmed Khanzada @ 2020-04-23 6:33 UTC (permalink / raw) To: Po Lu Cc: Yuan Fu, Tim Cross, Stefan Kangas, Emacs developers, Stefan Monnier, Sébastien Gendre, Simen Heggestøyl > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 6:33 ` Ahmed Khanzada @ 2020-04-23 10:14 ` Stefan Kangas 2020-04-23 14:55 ` Eli Zaretskii 1 sibling, 0 replies; 108+ messages in thread From: Stefan Kangas @ 2020-04-23 10:14 UTC (permalink / raw) To: Ahmed Khanzada Cc: Yuan Fu, Tim Cross, Emacs developers, Po Lu, Stefan Monnier, Sébastien Gendre, Simen Heggestøyl 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 6:33 ` Ahmed Khanzada 2020-04-23 10:14 ` Stefan Kangas @ 2020-04-23 14:55 ` Eli Zaretskii 1 sibling, 0 replies; 108+ messages in thread From: Eli Zaretskii @ 2020-04-23 14:55 UTC (permalink / raw) To: Ahmed Khanzada Cc: casouri, theophilusx, stefan, emacs-devel, luangruo, monnier, seb, simenheg > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 22:44 ` Sébastien Gendre 2020-04-20 0:36 ` Stefan Kangas @ 2020-04-20 4:53 ` Po Lu 2020-04-20 6:08 ` 조성빈 2020-04-20 14:22 ` Eli Zaretskii 2 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-20 4:53 UTC (permalink / raw) To: Sébastien Gendre; +Cc: emacs-devel 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). ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 4:53 ` Po Lu @ 2020-04-20 6:08 ` 조성빈 2020-04-20 9:53 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: 조성빈 @ 2020-04-20 6:08 UTC (permalink / raw) To: Po Lu; +Cc: Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 6:08 ` 조성빈 @ 2020-04-20 9:53 ` Po Lu 2020-04-20 13:07 ` 조성빈 0 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-20 9:53 UTC (permalink / raw) To: 조성빈; +Cc: Sébastien Gendre, Emacs developers 조성빈 <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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 9:53 ` Po Lu @ 2020-04-20 13:07 ` 조성빈 2020-04-20 15:32 ` Eli Zaretskii 2020-04-21 2:06 ` Po Lu 0 siblings, 2 replies; 108+ messages in thread From: 조성빈 @ 2020-04-20 13:07 UTC (permalink / raw) To: Po Lu; +Cc: Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 13:07 ` 조성빈 @ 2020-04-20 15:32 ` Eli Zaretskii 2020-04-21 2:06 ` Po Lu 1 sibling, 0 replies; 108+ messages in thread From: Eli Zaretskii @ 2020-04-20 15:32 UTC (permalink / raw) To: 조성빈; +Cc: luangruo, seb, emacs-devel > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 13:07 ` 조성빈 2020-04-20 15:32 ` Eli Zaretskii @ 2020-04-21 2:06 ` Po Lu 2020-04-21 2:17 ` Dmitry Gutov 1 sibling, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-21 2:06 UTC (permalink / raw) To: 조성빈; +Cc: Sébastien Gendre, Emacs developers 조성빈 <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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:06 ` Po Lu @ 2020-04-21 2:17 ` Dmitry Gutov 2020-04-21 4:42 ` Po Lu ` (2 more replies) 0 siblings, 3 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-21 2:17 UTC (permalink / raw) To: Po Lu, 조성빈; +Cc: Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:17 ` Dmitry Gutov @ 2020-04-21 4:42 ` Po Lu 2020-04-21 13:55 ` Dmitry Gutov 2020-04-22 3:19 ` Richard Stallman 2020-04-23 7:04 ` Ahmed Khanzada 2 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-21 4:42 UTC (permalink / raw) To: Dmitry Gutov Cc: 조성빈, Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 4:42 ` Po Lu @ 2020-04-21 13:55 ` Dmitry Gutov 2020-04-22 4:41 ` Po Lu 0 siblings, 1 reply; 108+ messages in thread From: Dmitry Gutov @ 2020-04-21 13:55 UTC (permalink / raw) To: Po Lu; +Cc: Sébastien Gendre, 조성빈, Emacs developers 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). ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 13:55 ` Dmitry Gutov @ 2020-04-22 4:41 ` Po Lu 2020-04-22 8:13 ` Sergey Organov 0 siblings, 1 reply; 108+ messages in thread From: Po Lu @ 2020-04-22 4:41 UTC (permalink / raw) To: Dmitry Gutov Cc: 조성빈, Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 4:41 ` Po Lu @ 2020-04-22 8:13 ` Sergey Organov 0 siblings, 0 replies; 108+ messages in thread From: Sergey Organov @ 2020-04-22 8:13 UTC (permalink / raw) To: Po Lu Cc: Emacs developers, Sébastien Gendre, 조성빈, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:17 ` Dmitry Gutov 2020-04-21 4:42 ` Po Lu @ 2020-04-22 3:19 ` Richard Stallman 2020-04-22 11:33 ` Dmitry Gutov 2020-04-23 7:04 ` Ahmed Khanzada 2 siblings, 1 reply; 108+ messages in thread From: Richard Stallman @ 2020-04-22 3:19 UTC (permalink / raw) To: Dmitry Gutov; +Cc: luangruo, seb, pcr910303, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 3:19 ` Richard Stallman @ 2020-04-22 11:33 ` Dmitry Gutov 0 siblings, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-22 11:33 UTC (permalink / raw) To: rms; +Cc: luangruo, seb, pcr910303, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 2:17 ` Dmitry Gutov 2020-04-21 4:42 ` Po Lu 2020-04-22 3:19 ` Richard Stallman @ 2020-04-23 7:04 ` Ahmed Khanzada 2020-04-23 14:20 ` Dmitry Gutov 2020-04-23 14:56 ` Eli Zaretskii 2 siblings, 2 replies; 108+ messages in thread From: Ahmed Khanzada @ 2020-04-23 7:04 UTC (permalink / raw) To: Dmitry Gutov Cc: Po Lu, Sébastien Gendre, 조성빈, Emacs developers > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 7:04 ` Ahmed Khanzada @ 2020-04-23 14:20 ` Dmitry Gutov 2020-04-23 14:56 ` Eli Zaretskii 1 sibling, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-23 14:20 UTC (permalink / raw) To: Ahmed Khanzada Cc: Po Lu, 조성빈, Sébastien Gendre, Emacs developers 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 7:04 ` Ahmed Khanzada 2020-04-23 14:20 ` Dmitry Gutov @ 2020-04-23 14:56 ` Eli Zaretskii 2020-04-23 15:32 ` Yuan Fu 2020-04-27 16:09 ` Arthur Miller 1 sibling, 2 replies; 108+ messages in thread From: Eli Zaretskii @ 2020-04-23 14:56 UTC (permalink / raw) To: Ahmed Khanzada; +Cc: luangruo, emacs-devel, pcr910303, seb, dgutov > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 14:56 ` Eli Zaretskii @ 2020-04-23 15:32 ` Yuan Fu 2020-04-27 16:09 ` Arthur Miller 1 sibling, 0 replies; 108+ messages in thread From: Yuan Fu @ 2020-04-23 15:32 UTC (permalink / raw) To: Eli Zaretskii Cc: Ahmed Khanzada, 조성빈, EMACS development team, Po Lu, Sébastien Gendre, dgutov > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 14:56 ` Eli Zaretskii 2020-04-23 15:32 ` Yuan Fu @ 2020-04-27 16:09 ` Arthur Miller 2020-04-27 16:43 ` Jean-Christophe Helary 1 sibling, 1 reply; 108+ messages in thread From: Arthur Miller @ 2020-04-27 16:09 UTC (permalink / raw) To: Eli Zaretskii Cc: Ahmed Khanzada, pcr910303, emacs-devel, luangruo, seb, dgutov 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 ... ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-27 16:09 ` Arthur Miller @ 2020-04-27 16:43 ` Jean-Christophe Helary 0 siblings, 0 replies; 108+ messages in thread From: Jean-Christophe Helary @ 2020-04-27 16:43 UTC (permalink / raw) To: Emacs developers > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 22:44 ` Sébastien Gendre 2020-04-20 0:36 ` Stefan Kangas 2020-04-20 4:53 ` Po Lu @ 2020-04-20 14:22 ` Eli Zaretskii 2020-04-21 12:43 ` Sébastien Gendre 2 siblings, 1 reply; 108+ messages in thread From: Eli Zaretskii @ 2020-04-20 14:22 UTC (permalink / raw) To: Sébastien Gendre; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-20 14:22 ` Eli Zaretskii @ 2020-04-21 12:43 ` Sébastien Gendre 2020-04-21 14:38 ` Eli Zaretskii 0 siblings, 1 reply; 108+ messages in thread From: Sébastien Gendre @ 2020-04-21 12:43 UTC (permalink / raw) To: Eli Zaretskii, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 12:43 ` Sébastien Gendre @ 2020-04-21 14:38 ` Eli Zaretskii 2020-04-22 1:35 ` Dmitry Gutov 0 siblings, 1 reply; 108+ messages in thread From: Eli Zaretskii @ 2020-04-21 14:38 UTC (permalink / raw) To: Sébastien Gendre; +Cc: emacs-devel > 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 ;-) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-21 14:38 ` Eli Zaretskii @ 2020-04-22 1:35 ` Dmitry Gutov 2020-04-22 3:26 ` Stefan Monnier 2020-04-22 13:22 ` Eli Zaretskii 0 siblings, 2 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-22 1:35 UTC (permalink / raw) To: Eli Zaretskii, Sébastien Gendre; +Cc: emacs-devel 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. :-) ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 1:35 ` Dmitry Gutov @ 2020-04-22 3:26 ` Stefan Monnier 2020-04-22 13:22 ` Eli Zaretskii 1 sibling, 0 replies; 108+ messages in thread From: Stefan Monnier @ 2020-04-22 3:26 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, Sébastien Gendre, emacs-devel > 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 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 1:35 ` Dmitry Gutov 2020-04-22 3:26 ` Stefan Monnier @ 2020-04-22 13:22 ` Eli Zaretskii 2020-04-22 17:46 ` chad 2020-04-22 17:55 ` Dmitry Gutov 1 sibling, 2 replies; 108+ messages in thread From: Eli Zaretskii @ 2020-04-22 13:22 UTC (permalink / raw) To: Dmitry Gutov; +Cc: seb, emacs-devel > 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? ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 13:22 ` Eli Zaretskii @ 2020-04-22 17:46 ` chad 2020-04-22 22:52 ` Yuan Fu 2020-04-22 17:55 ` Dmitry Gutov 1 sibling, 1 reply; 108+ messages in thread From: chad @ 2020-04-22 17:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: EMACS development team, seb, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 17:46 ` chad @ 2020-04-22 22:52 ` Yuan Fu 2020-04-23 0:12 ` chad 0 siblings, 1 reply; 108+ messages in thread From: Yuan Fu @ 2020-04-22 22:52 UTC (permalink / raw) To: chad Cc: Eli Zaretskii, Dmitry Gutov, Sébastien Gendre, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 22:52 ` Yuan Fu @ 2020-04-23 0:12 ` chad 2020-04-23 0:49 ` Yuan Fu 0 siblings, 1 reply; 108+ messages in thread From: chad @ 2020-04-23 0:12 UTC (permalink / raw) To: Yuan Fu Cc: Eli Zaretskii, Dmitry Gutov, Sébastien Gendre, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-23 0:12 ` chad @ 2020-04-23 0:49 ` Yuan Fu 0 siblings, 0 replies; 108+ messages in thread From: Yuan Fu @ 2020-04-23 0:49 UTC (permalink / raw) To: chad Cc: Eli Zaretskii, Dmitry Gutov, Sébastien Gendre, EMACS development team [-- 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 --] ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-22 13:22 ` Eli Zaretskii 2020-04-22 17:46 ` chad @ 2020-04-22 17:55 ` Dmitry Gutov 1 sibling, 0 replies; 108+ messages in thread From: Dmitry Gutov @ 2020-04-22 17:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: seb, emacs-devel 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. ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:21 ` Making Emacs more friendly to newcomers Po Lu 2020-04-19 8:25 ` ndame @ 2020-04-19 13:35 ` Eli Zaretskii 2020-04-19 19:14 ` Drew Adams 2020-04-19 22:50 ` Po Lu 1 sibling, 2 replies; 108+ messages in thread From: Eli Zaretskii @ 2020-04-19 13:35 UTC (permalink / raw) To: Po Lu Cc: me, joseph.h.garvin, rms, stefan, emacs-devel, pcr910303, drew.adams, ndame > 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? ^ permalink raw reply [flat|nested] 108+ messages in thread
* RE: Making Emacs more friendly to newcomers 2020-04-19 13:35 ` Eli Zaretskii @ 2020-04-19 19:14 ` Drew Adams 2020-04-19 22:50 ` Po Lu 1 sibling, 0 replies; 108+ messages in thread From: Drew Adams @ 2020-04-19 19:14 UTC (permalink / raw) To: Eli Zaretskii, Po Lu Cc: me, joseph.h.garvin, rms, stefan, emacs-devel, pcr910303, ndame > P.S. And why does every message from you get sent twice to each > addressee? +1 ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 13:35 ` Eli Zaretskii 2020-04-19 19:14 ` Drew Adams @ 2020-04-19 22:50 ` Po Lu 1 sibling, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 22:50 UTC (permalink / raw) To: Eli Zaretskii Cc: me, joseph.h.garvin, rms, stefan, emacs-devel, pcr910303, drew.adams, ndame 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! ^ permalink raw reply [flat|nested] 108+ messages in thread
* Re: Making Emacs more friendly to newcomers 2020-04-19 8:05 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 조성빈 2020-04-19 8:12 ` ndame @ 2020-04-19 8:16 ` Po Lu 1 sibling, 0 replies; 108+ messages in thread From: Po Lu @ 2020-04-19 8:16 UTC (permalink / raw) To: 조성빈 Cc: ndame, Richard Stallman, Ahmed Khanzada, joseph.h.garvin@gmail.com, stefan@marxist.se, emacs-devel@gnu.org, eliz@gnu.org, drew.adams@oracle.com 조성빈 <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? ^ permalink raw reply [flat|nested] 108+ messages in thread
end of thread, other threads:[~2020-05-07 2:48 UTC | newest] Thread overview: 108+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-04-20 6:22 Making Emacs more friendly to newcomers ndame 2020-04-20 10:08 ` Po Lu 2020-04-21 1:50 ` Richard Stallman 2020-04-21 2:09 ` Po Lu 2020-04-21 8:44 ` Theodor Thornhill 2020-04-22 4:30 ` Po Lu 2020-04-22 7:01 ` Theodor Thornhill 2020-04-23 3:10 ` Po Lu 2020-04-22 16:45 ` Stefan Monnier 2020-04-22 17:16 ` Dmitry Gutov 2020-04-23 3:11 ` Po Lu 2020-04-23 12:55 ` Stefan Monnier 2020-04-24 5:24 ` Po Lu 2020-04-26 18:40 ` Yuan Fu 2020-04-27 4:00 ` Stefan Monnier 2020-04-24 2:34 ` Richard Stallman 2020-04-24 2:39 ` 조성빈 2020-04-24 2:42 ` 조성빈 2020-04-24 7:33 ` Theodor Thornhill 2020-04-25 3:30 ` Richard Stallman 2020-04-25 3:32 ` 조성빈 2020-04-26 3:19 ` Richard Stallman 2020-04-26 14:32 ` Dmitry Gutov 2020-04-26 15:14 ` tomas 2020-04-26 16:32 ` Dmitry Gutov 2020-04-26 16:36 ` tomas 2020-04-21 2:10 ` Dmitry Gutov 2020-04-21 3:45 ` Stefan Monnier 2020-04-21 4:44 ` chad 2020-04-22 3:19 ` Richard Stallman 2020-04-22 3:31 ` Dmitry Gutov -- strict thread matches above, loose matches on Subject: below -- 2020-04-27 17:50 ndame 2020-04-27 18:07 ` Arthur Miller 2020-04-28 0:13 ` Dmitry Gutov 2020-04-30 2:26 ` Richard Stallman 2020-04-30 5:58 ` ndame 2020-05-02 2:21 ` Richard Stallman 2020-05-02 15:52 ` Arthur Miller 2020-05-02 15:59 ` Dmitry Gutov 2020-05-02 17:00 ` Arthur Miller 2020-05-02 18:20 ` Dmitry Gutov 2020-05-02 18:55 ` Arthur Miller 2020-05-04 3:05 ` Richard Stallman 2020-05-05 14:08 ` Arthur Miller 2020-05-06 4:46 ` Richard Stallman 2020-05-06 18:14 ` Nikita Mogilevsky 2020-05-07 2:48 ` Richard Stallman 2020-05-02 16:25 ` ndame 2020-05-02 19:04 ` Drew Adams 2020-05-02 19:36 ` Arthur Miller 2020-05-02 20:05 ` Drew Adams 2020-05-02 21:16 ` Arthur Miller 2020-05-02 22:16 ` Drew Adams 2020-05-03 3:42 ` Richard Stallman 2020-05-05 13:58 ` Arthur Miller 2020-04-21 15:27 ndame 2020-04-22 3:14 ` Richard Stallman 2020-04-16 14:58 "Why is emacs so square?" Drew Adams 2020-04-16 15:34 ` Joseph Garvin 2020-04-17 22:05 ` Ahmed Khanzada 2020-04-19 2:18 ` Richard Stallman 2020-04-19 2:33 ` Po Lu 2020-04-19 4:55 ` ndame 2020-04-19 6:14 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") Po Lu 2020-04-19 6:54 ` Eduardo Ochs 2020-04-19 7:22 ` Making Emacs more friendly to newcomers Po Lu 2020-04-19 8:05 ` Making Emacs more friendly to newcomers (was: "Why is emacs so square?") 조성빈 2020-04-19 8:12 ` ndame 2020-04-19 8:21 ` Making Emacs more friendly to newcomers Po Lu 2020-04-19 8:25 ` ndame 2020-04-19 9:30 ` Po Lu 2020-04-19 22:44 ` Sébastien Gendre 2020-04-20 0:36 ` Stefan Kangas 2020-04-20 3:32 ` Tim Cross 2020-04-20 9:54 ` Po Lu 2020-04-20 13:50 ` Stefan Monnier 2020-04-21 8:52 ` Po Lu 2020-04-21 13:57 ` Simen Heggestøyl 2020-04-21 15:36 ` Yuan Fu 2020-04-22 3:14 ` Richard Stallman 2020-04-22 4:33 ` Po Lu 2020-04-23 6:33 ` Ahmed Khanzada 2020-04-23 10:14 ` Stefan Kangas 2020-04-23 14:55 ` Eli Zaretskii 2020-04-20 4:53 ` Po Lu 2020-04-20 6:08 ` 조성빈 2020-04-20 9:53 ` Po Lu 2020-04-20 13:07 ` 조성빈 2020-04-20 15:32 ` Eli Zaretskii 2020-04-21 2:06 ` Po Lu 2020-04-21 2:17 ` Dmitry Gutov 2020-04-21 4:42 ` Po Lu 2020-04-21 13:55 ` Dmitry Gutov 2020-04-22 4:41 ` Po Lu 2020-04-22 8:13 ` Sergey Organov 2020-04-22 3:19 ` Richard Stallman 2020-04-22 11:33 ` Dmitry Gutov 2020-04-23 7:04 ` Ahmed Khanzada 2020-04-23 14:20 ` Dmitry Gutov 2020-04-23 14:56 ` Eli Zaretskii 2020-04-23 15:32 ` Yuan Fu 2020-04-27 16:09 ` Arthur Miller 2020-04-27 16:43 ` Jean-Christophe Helary 2020-04-20 14:22 ` Eli Zaretskii 2020-04-21 12:43 ` Sébastien Gendre 2020-04-21 14:38 ` Eli Zaretskii 2020-04-22 1:35 ` Dmitry Gutov 2020-04-22 3:26 ` Stefan Monnier 2020-04-22 13:22 ` Eli Zaretskii 2020-04-22 17:46 ` chad 2020-04-22 22:52 ` Yuan Fu 2020-04-23 0:12 ` chad 2020-04-23 0:49 ` Yuan Fu 2020-04-22 17:55 ` Dmitry Gutov 2020-04-19 13:35 ` Eli Zaretskii 2020-04-19 19:14 ` Drew Adams 2020-04-19 22:50 ` Po Lu 2020-04-19 8:16 ` Po Lu
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.