The problem with an insider discussion like this is that it assumes it's a good goal for emacs to become more popular. But an organization starting from scratch to build a better editor today...
The problem with an insider discussion like this is that it assumes it's a good goal for emacs to become more popular. But an organization starting from scratch to build a better editor today might be better off forking VS Code than emacs? Or reusing large parts of VS Code. Or maybe doing something else entirely, as an attempt to reinvent what an editor can be?
Maybe it's fine for the emacs folks to concentrate on preservation and stability, as an exercise in retro programming, like the game emulator folks do? This seems to be how it's going to go in practice, so why fight it?
And this also seems to be true for many Debian packages? A lot of it seems like an exercise in historical preservation of the old ways of computing. And this is fine. It can be fun for new people to learn about old stuff. The old stuff doesn't have to change to be interesting.
Why fork VS Code? I learned emacs and elisp when I learned to code. I am not a professional programmer and never will be. However, I've found enormous value in having a tool that I can configure...
Why fork VS Code?
I learned emacs and elisp when I learned to code. I am not a professional programmer and never will be. However, I've found enormous value in having a tool that I can configure to my exact needs. And the Emacs community, in my experience, has been very open and friendly.
I tried VS Code out of curiosity. It consumed 100% of my CPU. I reinstalled and removed all add-ons. It was still super heavy-- it's an electron based app after all. Most disappointing though was that it wasn't as intuitive as I expected. I was hoping it would be usable "out of the box" but it seemed that I would need to spend time to learn it and configure.
According to the article nobody has volunteered to clean up the emacs UI code and they've been waiting years. So to me that sounds like legacy code that's hard to work on? But maybe the Lite...
According to the article nobody has volunteered to clean up the emacs UI code and they've been waiting years. So to me that sounds like legacy code that's hard to work on?
But maybe the Lite editor just posted today on Hacker News would be a better starting point?
Anyway, my main point is that, inside a community, building on what you're already familiar with seems easier, but from the outside it's a lot of legacy stuff to deal with that maybe you don't value as much and you might as well start somewhere else.
Maybe it's fine for the emacs folks to concentrate on preservation and stability, as an exercise in retro programming, like the game emulator folks do?
I mean, accept that emacs is only going to be interesting to its current userbase and maybe a few others who are interested in the history of computers, and that's okay. Declare dramatic growth in...
I mean, accept that emacs is only going to be interesting to its current userbase and maybe a few others who are interested in the history of computers, and that's okay. Declare dramatic growth in the number of users to be a non-goal. It doesn't need to be reinvented since that would just detract from the antique look and feel.
Like, you don't need to remodel a Victorian house to make it look modern.
I see. Well I use Emacs because I find it useful. It supports current technologies while giving me the power to easily configure it to my liking. It also has numerous packages and features that...
I see. Well I use Emacs because I find it useful. It supports current technologies while giving me the power to easily configure it to my liking. It also has numerous packages and features that cannot be easily replicated elsewhere. I think many feel this way. This is definitely not about history, Emacs is both current and relevant.
I don’t think it makes sense to target VS Code users though. From their point of view, Emacs offers solutions to problems that do not exist.
It can be both. To continue the analogy, lots of people like living in older buildings. There are things you want to modernize, without necessarily changing the building's look too much. Computing...
It can be both. To continue the analogy, lots of people like living in older buildings. There are things you want to modernize, without necessarily changing the building's look too much.
Computing is a young field so we don't have a lot of examples of this yet, but I imagine the programmer-archeologist in A Deepness of The Sky would be doing some Unix scripting now and then.
I’m not sure if the notion of archeology makes sense for something that’s not only being used for its original purpose but also undergoing significant changes as well as new additions.
I’m not sure if the notion of archeology makes sense for something that’s not only being used for its original purpose but also undergoing significant changes as well as new additions.
The quotes in the article give me the impression that some of the Emacs developers are slightly detached from reality. While I agree that much can (and should) be done to make Emacs friendlier to...
The quotes in the article give me the impression that some of the Emacs developers are slightly detached from reality. While I agree that much can (and should) be done to make Emacs friendlier to a broader audience, the adaptations required to get close to the success of VS Code go way beyond retouching the UI. Vim is certainly more popular than Emacs and is still not even close to VS Code in popularity.
VS Code comes prepackaged with a bunch of stuff and makes it very easy to install everything else without editing a single configuration file. On Emacs you can install and configure packages “graphically” but it’s kind of a mess.
The editor that comes with a button that sets everything with sensible defaults will likely win. Even distributions like Spacemacs require external packages for all sorts of basic stuff, and methods of installation are frequently platform specific. You need dictionaries, linters, runtimes, etc, and sometimes must also manually point variables to them.
I do feel I got enough rewards from the time invested, but it’s unreasonable to expect people to choose this instead of a “solve almost everything” button.
I agree with you so much. I'm actually kind of glad that Vi(m) won the 'editor war' because of just how stupid the whole thing is. Both Vi(m) and emacs are far behind development environments like...
I agree with you so much. I'm actually kind of glad that Vi(m) won the 'editor war' because of just how stupid the whole thing is. Both Vi(m) and emacs are far behind development environments like any of the Visual Studios, JetBrains, or whatever commercial IDE/Editor you would prefer.
To explain why, just take a look at Emmit. Emmit is a de-facto standard feature of most web-facing IDEs, and on most of them all you have to do is type in your string and press tab. Compare that to Vim, where the package is not installed by default and it's activated by the absolutely mind-boggling combination of pressing ctrl-y and then the comma key. Not only do I have no idea why the command is so obtuse, it's also considerably more difficult than pressing tab. Furthermore, most of the editors I have used with Emmit also will automatically put the cursor to where you'd be entering data and let you switch between any other fields simply by pressing tab again. That doesn't seem to exist in the Vim extension - though to be fair, it may be there and I just didn't have the patience to find out what obscure keypress combination needed for it.
You could argue that the differences could be solved by configuration, but my response to you would be "why bother?" I'm sure it's not difficult if you know how to configure vi already, but very few people do, and why would they bother learning how to configure vi when they can simply download and run a free editor that already has it done for me, has all the plugins I may need available in a central repository with an easy search function that's built right in the editor, and uses all of the same de-facto standard shortcuts that I'm already familiar with because every other modern program uses them?
(We could go onto how I think that the mode in which vi operates is more of a hinderance than a help, but I'd rather not start that flame war.)
Yeah I don’t think this is necessarily a matter of Emacs and Vim being behind, they’re just different and tend to needs that are not that of the majority. And that’s kinda okay.
Yeah I don’t think this is necessarily a matter of Emacs and Vim being behind, they’re just different and tend to needs that are not that of the majority. And that’s kinda okay.
I agree. Some folks, myself included, enjoy older editors for a variety of reasons. I usually use nano for its simplicity and ease of use, and am starting to learn acme as I crawl my way through...
I agree. Some folks, myself included, enjoy older editors for a variety of reasons.
I usually use nano for its simplicity and ease of use, and am starting to learn acme as I crawl my way through Plan 9.
I know what I wrote probably sounds a little bit combative, but that's basically what I was trying to say in a nutshell. It's why I get angry whenever people start arguing about the superiority of...
I know what I wrote probably sounds a little bit combative, but that's basically what I was trying to say in a nutshell. It's why I get angry whenever people start arguing about the superiority of any particular editor.
You can get the functionality you want with coc.nvim and coc-emmet. And flexible configuration is part of the beauty of vim and emacs. Everyone who uses vim for a while creates their own personal...
You can get the functionality you want with coc.nvim and coc-emmet. And flexible configuration is part of the beauty of vim and emacs. Everyone who uses vim for a while creates their own personal vimrc which works for them, rather than a one-size-fits-all solution. The one-size-fits-all solution may be easier at the beginning, but in the long run it's nicer to use software that works how you want it.
Overall though, I do agree that configuring vim is more difficult than it should be. That's why I'm a huge fan of the onivim project, which promises to combine vscode plugin support and vim's modal editing.
I bought a pre-alpha license for $1 ages ago, I'm eager to see where it's going to lead.
Overall though, I do agree that configuring vim is more difficult than it should be. That's why I'm a huge fan of the onivim project, which promises to combine vscode plugin support and vim's modal editing.
I bought a pre-alpha license for $1 ages ago, I'm eager to see where it's going to lead.
Vim didn’t win, though. It only "won" if you consider Vim vs. Emacs in a vacuum. Most developers I’ve encountered use some combination of language-specific IDEs (i.e., JetBrains stuff), or for...
Vim didn’t win, though. It only "won" if you consider Vim vs. Emacs in a vacuum. Most developers I’ve encountered use some combination of language-specific IDEs (i.e., JetBrains stuff), or for general purpose text editing, use something like Sublime or NotePad++.
Those who use Emacs, Vim, or other terminal-based editors are a vast minority, in my experience, and various surveys seem to back this up (but it all depends on the distribution you sample from—if you survey Hacker News or a specific subreddit, you’re going to get skewed results).
According to the Stack Overflow developer survey, Vim is significantly more popular than Emacs. And at least somewhat competitive popularity-wise with other tools. I don't know how accurate the...
According to the Stack Overflow developer survey, Vim is significantly more popular than Emacs. And at least somewhat competitive popularity-wise with other tools. I don't know how accurate the Stack Overflow developer survey is for the general dev community though.
I'd assume the number for Vim is much higher. People can use other editors with Vim bindings. The vscode vim bindings alone have 1.6 million installs....
An editor is much, much more than the keybindings you use for basic navigation and editing operations. Counting those who use Vim bindings in their text editor as "using Vim" is not meaningful. If...
An editor is much, much more than the keybindings you use for basic navigation and editing operations. Counting those who use Vim bindings in their text editor as "using Vim" is not meaningful. If you’re going to do that, you have to count every single macOS and iOS user who uses the default bindings as "using Emacs", since every native text field in those OSes allows for the basic movement, yank/kill, etc.
Edit:
I guess you’d also have to consider counting every shell/REPL that uses readline as "using Emacs" as well.
The Vi vs. Emacs war was essentially always in a vacuum, though. Even if we restrict ourselves to terminal-based editors, there are still a ton of more generally user-friendly editors around. The...
The Vi vs. Emacs war was essentially always in a vacuum, though. Even if we restrict ourselves to terminal-based editors, there are still a ton of more generally user-friendly editors around. The biggest reason why the war was so stupid for such a long time was that they had both lost.
Got it. I was just confirming that you weren't making the claim that an editor should simply work "out of the box" for any and all programming endeavors. Naturally, I would expect that some degree...
Got it. I was just confirming that you weren't making the claim that an editor should simply work "out of the box" for any and all programming endeavors. Naturally, I would expect that some degree of configuration would be necessary.
Emacs provides a framework that a user can work within to achieve a very efficient and capable workspace for text editing. You don't need to understand anything tricky to start learning. Learn...
Emacs provides a framework that a user can work within to achieve a very efficient and capable workspace for text editing.
You don't need to understand anything tricky to start learning. Learn just barely enough to do some work and learn more as you go. The interface has the key strokes as labels so you can adjust at a pace you choose.
I promise anyone reading, you'll slowly learn to love it.
And second to that. The foundations behind software like Emacs are principled.
For me personally, I never really dove into Emacs simply because it had a much steeper initial learning curve to do the basics, and not every server I worked had it pre-installed (hence Vim's...
For me personally, I never really dove into Emacs simply because it had a much steeper initial learning curve to do the basics, and not every server I worked had it pre-installed (hence Vim's mandatory user growth). For building a user base, ease of on-boarding is king. Vim does that pretty well, as 4 commands can get you going and the power can come easily with time. VSCode shot to popularity in part because it was very easy to become productive enough very quickly.
The gatekeeping by RMS here is staggering. And then more from others: Yeah, you are saying that emacs is only for a snooty elite when you say that, you just don't realize it because you're blinded...
The gatekeeping by RMS here is staggering.
Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things.
The code to interface Emacs to X-based GUIs needs rewriting by an expert, and has needed it for decades. Until it gets that rewrite, changes in it are likely to break something.
And then more from others:
Yes, make Emacs appealing and user friendly. But don't forget that a masterful tool in the end requires mastery, which can't come for free. I certainly draw the line at saying Emacs is for everyone. I'm not saying it's only for some sort of snooty "elite" but I am saying that it's for those who are willing to learn, seeing some extra work as the aforementioned long-term investment, and who have the patience reach a worthy goal a little later rather than right this very minute.
Yeah, you are saying that emacs is only for a snooty elite when you say that, you just don't realize it because you're blinded by your own privilege. And of course RMS agreed with this. There's also a lot of "sure, someone can do this, but it's definitely not me".
All of this reminds me a lot of another older open source software community that's declining: Perl. Lots of gatekeeping and "we cannot change how we've been doing things for 30 years because we might break 30 year old code". No, really, words to that effect have been posted many times to the developer mailing list. The Perl community is pathologically afraid of breaking backwards compatibility and is convinced that its way of doing things is the One True Way™ (ironic for a language whose motto is "There's More Than One Way To Do It"). Like its barebones approach to object orientation (which isn't, really, in a number of ways; Rust is more OO than Perl). Lots of middle-age white men who don't want to change because they don't want to change, and they expect others to fix all the problems they see.
emacs and perl are products of another time, and they refuse to adapt because of the staggering amount of gatekeeping and privilege of their core developers / users. I don't expect either tool to have much currency once the current userbase retires. They're becoming the new COBOL.
I don't really have a bone in this since I'm not a programmer and the little code I do write I tend to just use either Kate or Nano but saying "I don't wanna do this" isn't gatekeeping surely?...
I don't really have a bone in this since I'm not a programmer and the little code I do write I tend to just use either Kate or Nano but saying "I don't wanna do this" isn't gatekeeping surely? It's someone contributing free time for no other reasons than they want to and in this case don't feel it?
It's about how they say it and the context in which it's said. If we can agree that the rest is gatekeeping, then saying "let someone else do it" takes on a different meaning for me. "Keep the...
It's about how they say it and the context in which it's said. If we can agree that the rest is gatekeeping, then saying "let someone else do it" takes on a different meaning for me. "Keep the newbs out, but I guess if they want to do this thing to make it easier for them to use it, they can, but we (the people who are best qualified to do it) aren't going to". It's very much a "let them eat cake, let them help themselves, pull yourself up by your bootstraps" kind of attitude.
There's a balance between the volunteerism of open source and the requirement for software to be accessible. If you want more people to use your software (not wanting this is gatekeeping by definition), then you need to compromise. This refusal to compromise is part of the problem.
I don't think it is. Or rather I don't want there to be. It is really difficult to justify in a larger project maintained by volonteers that they have to do something, at all, without treating...
I don't think it is. Or rather I don't want there to be.
It is really difficult to justify in a larger project maintained by volonteers that they have to do something, at all, without treating them as your employees. And that way projects die quickly in my experience, unless those that do the demanding also pay for it (which also in my experience they very seldomly do. "The more people demand, the less they pay" is a bit too drastic a phrase I guess but it sort of served me well).
At the same time, focusing on accessibility is really important - so I agree with you (and disagree with you at the same time) - but I think its best spent in areas where you have the least chance of finding users able to to contribute directly to the code. Emacs being... well being very very emacs is aimed at a core set of users, who are more likely to be able to create the change they wish to see, fork the project as needed and implement their solutions.
Front facing, GUI-centric projects aimed at less technically apt users demand more care towards different levels of skill.
The problem is that the balance, right now, is putting too much weight on project maintainers and contributors the larger the project. To the point where many projects simply get pulled and kept as private repos by maintainers (and I have seen first hand the burnouts that happen in Open Source projects with maintainers and contributors of varying levels simply stopping or worse disappearing).
As you say though, accessibility is important - but ALL work need to be weighed against contributor joy.
I don't see how this is gatekeeping. There already is intuitive software for text editing. People who choose to use software like emacs (or vim) are inherently a group of people who want to spend...
I don't see how this is gatekeeping. There already is intuitive software for text editing. People who choose to use software like emacs (or vim) are inherently a group of people who want to spend more time to learn more complex software for efficiency benefits down the road.
How does privilege factor into the choice to keep complex, capable software complex?
You don't see how the dismissive, snide comment by RMS about cosmetics are gatekeeping? If you don't see how privilege is a factor here then I think you need to learn what privilege is and examine...
You don't see how the dismissive, snide comment by RMS about cosmetics are gatekeeping?
If you don't see how privilege is a factor here then I think you need to learn what privilege is and examine your own.
He's essentially just saying "don't judge a book by it's cover". Personally, I'm a big fan of not judging things by their appearances, so I actually agree with RMS here. Can you please explain how...
He's essentially just saying "don't judge a book by it's cover". Personally, I'm a big fan of not judging things by their appearances, so I actually agree with RMS here.
Can you please explain how privilege is a factor here, because I'm not seeing it.
I don’t necessarily agree with your other remarks, but this quote makes it very clear to me that Stallman is gatekeeping with prejudice, no doubt about it:
I don’t necessarily agree with your other remarks, but this quote makes it very clear to me that Stallman is gatekeeping with prejudice, no doubt about it:
Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things.
The problem with an insider discussion like this is that it assumes it's a good goal for emacs to become more popular. But an organization starting from scratch to build a better editor today might be better off forking VS Code than emacs? Or reusing large parts of VS Code. Or maybe doing something else entirely, as an attempt to reinvent what an editor can be?
Maybe it's fine for the emacs folks to concentrate on preservation and stability, as an exercise in retro programming, like the game emulator folks do? This seems to be how it's going to go in practice, so why fight it?
And this also seems to be true for many Debian packages? A lot of it seems like an exercise in historical preservation of the old ways of computing. And this is fine. It can be fun for new people to learn about old stuff. The old stuff doesn't have to change to be interesting.
Why fork VS Code?
I learned emacs and elisp when I learned to code. I am not a professional programmer and never will be. However, I've found enormous value in having a tool that I can configure to my exact needs. And the Emacs community, in my experience, has been very open and friendly.
I tried VS Code out of curiosity. It consumed 100% of my CPU. I reinstalled and removed all add-ons. It was still super heavy-- it's an electron based app after all. Most disappointing though was that it wasn't as intuitive as I expected. I was hoping it would be usable "out of the box" but it seemed that I would need to spend time to learn it and configure.
According to the article nobody has volunteered to clean up the emacs UI code and they've been waiting years. So to me that sounds like legacy code that's hard to work on?
But maybe the Lite editor just posted today on Hacker News would be a better starting point?
Anyway, my main point is that, inside a community, building on what you're already familiar with seems easier, but from the outside it's a lot of legacy stuff to deal with that maybe you don't value as much and you might as well start somewhere else.
Ah, okay. Thank you for clarifying.
What does that mean?
I mean, accept that emacs is only going to be interesting to its current userbase and maybe a few others who are interested in the history of computers, and that's okay. Declare dramatic growth in the number of users to be a non-goal. It doesn't need to be reinvented since that would just detract from the antique look and feel.
Like, you don't need to remodel a Victorian house to make it look modern.
I see. Well I use Emacs because I find it useful. It supports current technologies while giving me the power to easily configure it to my liking. It also has numerous packages and features that cannot be easily replicated elsewhere. I think many feel this way. This is definitely not about history, Emacs is both current and relevant.
I don’t think it makes sense to target VS Code users though. From their point of view, Emacs offers solutions to problems that do not exist.
It can be both. To continue the analogy, lots of people like living in older buildings. There are things you want to modernize, without necessarily changing the building's look too much.
Computing is a young field so we don't have a lot of examples of this yet, but I imagine the programmer-archeologist in A Deepness of The Sky would be doing some Unix scripting now and then.
I’m not sure if the notion of archeology makes sense for something that’s not only being used for its original purpose but also undergoing significant changes as well as new additions.
Yeah, I didn't mean to say it's dead. Let's go with the house analogy.
The quotes in the article give me the impression that some of the Emacs developers are slightly detached from reality. While I agree that much can (and should) be done to make Emacs friendlier to a broader audience, the adaptations required to get close to the success of VS Code go way beyond retouching the UI. Vim is certainly more popular than Emacs and is still not even close to VS Code in popularity.
VS Code comes prepackaged with a bunch of stuff and makes it very easy to install everything else without editing a single configuration file. On Emacs you can install and configure packages “graphically” but it’s kind of a mess.
The editor that comes with a button that sets everything with sensible defaults will likely win. Even distributions like Spacemacs require external packages for all sorts of basic stuff, and methods of installation are frequently platform specific. You need dictionaries, linters, runtimes, etc, and sometimes must also manually point variables to them.
I do feel I got enough rewards from the time invested, but it’s unreasonable to expect people to choose this instead of a “solve almost everything” button.
And Emacs will never have such button.
I agree with you so much. I'm actually kind of glad that Vi(m) won the 'editor war' because of just how stupid the whole thing is. Both Vi(m) and emacs are far behind development environments like any of the Visual Studios, JetBrains, or whatever commercial IDE/Editor you would prefer.
To explain why, just take a look at Emmit. Emmit is a de-facto standard feature of most web-facing IDEs, and on most of them all you have to do is type in your string and press tab. Compare that to Vim, where the package is not installed by default and it's activated by the absolutely mind-boggling combination of pressing ctrl-y and then the comma key. Not only do I have no idea why the command is so obtuse, it's also considerably more difficult than pressing tab. Furthermore, most of the editors I have used with Emmit also will automatically put the cursor to where you'd be entering data and let you switch between any other fields simply by pressing tab again. That doesn't seem to exist in the Vim extension - though to be fair, it may be there and I just didn't have the patience to find out what obscure keypress combination needed for it.
You could argue that the differences could be solved by configuration, but my response to you would be "why bother?" I'm sure it's not difficult if you know how to configure vi already, but very few people do, and why would they bother learning how to configure vi when they can simply download and run a free editor that already has it done for me, has all the plugins I may need available in a central repository with an easy search function that's built right in the editor, and uses all of the same de-facto standard shortcuts that I'm already familiar with because every other modern program uses them?
(We could go onto how I think that the mode in which vi operates is more of a hinderance than a help, but I'd rather not start that flame war.)
Yeah I don’t think this is necessarily a matter of Emacs and Vim being behind, they’re just different and tend to needs that are not that of the majority. And that’s kinda okay.
I agree. Some folks, myself included, enjoy older editors for a variety of reasons.
I usually use nano for its simplicity and ease of use, and am starting to learn acme as I crawl my way through Plan 9.
I know what I wrote probably sounds a little bit combative, but that's basically what I was trying to say in a nutshell. It's why I get angry whenever people start arguing about the superiority of any particular editor.
You can get the functionality you want with coc.nvim and coc-emmet. And flexible configuration is part of the beauty of vim and emacs. Everyone who uses vim for a while creates their own personal vimrc which works for them, rather than a one-size-fits-all solution. The one-size-fits-all solution may be easier at the beginning, but in the long run it's nicer to use software that works how you want it.
Overall though, I do agree that configuring vim is more difficult than it should be. That's why I'm a huge fan of the onivim project, which promises to combine vscode plugin support and vim's modal editing.
I bought a pre-alpha license for $1 ages ago, I'm eager to see where it's going to lead.
Vim didn’t win, though. It only "won" if you consider Vim vs. Emacs in a vacuum. Most developers I’ve encountered use some combination of language-specific IDEs (i.e., JetBrains stuff), or for general purpose text editing, use something like Sublime or NotePad++.
Those who use Emacs, Vim, or other terminal-based editors are a vast minority, in my experience, and various surveys seem to back this up (but it all depends on the distribution you sample from—if you survey Hacker News or a specific subreddit, you’re going to get skewed results).
According to the Stack Overflow developer survey, Vim is significantly more popular than Emacs. And at least somewhat competitive popularity-wise with other tools. I don't know how accurate the Stack Overflow developer survey is for the general dev community though.
I'd assume the number for Vim is much higher. People can use other editors with Vim bindings. The vscode vim bindings alone have 1.6 million installs. https://marketplace.visualstudio.com/items?itemName=vscodevim.vim
I've been using vim bindings in Visual Studio, vscode, Sublime, etc.
An editor is much, much more than the keybindings you use for basic navigation and editing operations. Counting those who use Vim bindings in their text editor as "using Vim" is not meaningful. If you’re going to do that, you have to count every single macOS and iOS user who uses the default bindings as "using Emacs", since every native text field in those OSes allows for the basic movement, yank/kill, etc.
Edit:
I guess you’d also have to consider counting every shell/REPL that uses
readlineas "using Emacs" as well.The Vi vs. Emacs war was essentially always in a vacuum, though. Even if we restrict ourselves to terminal-based editors, there are still a ton of more generally user-friendly editors around. The biggest reason why the war was so stupid for such a long time was that they had both lost.
You don't need to use any external packages for VS Code?
You do, but there's a consistent graphical interface to help you install and configure packages. Emacs is way more init-file oriented.
Got it. I was just confirming that you weren't making the claim that an editor should simply work "out of the box" for any and all programming endeavors. Naturally, I would expect that some degree of configuration would be necessary.
Emacs provides a framework that a user can work within to achieve a very efficient and capable workspace for text editing.
You don't need to understand anything tricky to start learning. Learn just barely enough to do some work and learn more as you go. The interface has the key strokes as labels so you can adjust at a pace you choose.
I promise anyone reading, you'll slowly learn to love it.
And second to that. The foundations behind software like Emacs are principled.
For me personally, I never really dove into Emacs simply because it had a much steeper initial learning curve to do the basics, and not every server I worked had it pre-installed (hence Vim's mandatory user growth). For building a user base, ease of on-boarding is king. Vim does that pretty well, as 4 commands can get you going and the power can come easily with time. VSCode shot to popularity in part because it was very easy to become productive enough very quickly.
The gatekeeping by RMS here is staggering.
And then more from others:
Yeah, you are saying that emacs is only for a snooty elite when you say that, you just don't realize it because you're blinded by your own privilege. And of course RMS agreed with this. There's also a lot of "sure, someone can do this, but it's definitely not me".
All of this reminds me a lot of another older open source software community that's declining: Perl. Lots of gatekeeping and "we cannot change how we've been doing things for 30 years because we might break 30 year old code". No, really, words to that effect have been posted many times to the developer mailing list. The Perl community is pathologically afraid of breaking backwards compatibility and is convinced that its way of doing things is the One True Way™ (ironic for a language whose motto is "There's More Than One Way To Do It"). Like its barebones approach to object orientation (which isn't, really, in a number of ways; Rust is more OO than Perl). Lots of middle-age white men who don't want to change because they don't want to change, and they expect others to fix all the problems they see.
emacs and perl are products of another time, and they refuse to adapt because of the staggering amount of gatekeeping and privilege of their core developers / users. I don't expect either tool to have much currency once the current userbase retires. They're becoming the new COBOL.
I don't really have a bone in this since I'm not a programmer and the little code I do write I tend to just use either Kate or Nano but saying "I don't wanna do this" isn't gatekeeping surely? It's someone contributing free time for no other reasons than they want to and in this case don't feel it?
(the rest though... oof)
It's about how they say it and the context in which it's said. If we can agree that the rest is gatekeeping, then saying "let someone else do it" takes on a different meaning for me. "Keep the newbs out, but I guess if they want to do this thing to make it easier for them to use it, they can, but we (the people who are best qualified to do it) aren't going to". It's very much a "let them eat cake, let them help themselves, pull yourself up by your bootstraps" kind of attitude.
There's a balance between the volunteerism of open source and the requirement for software to be accessible. If you want more people to use your software (not wanting this is gatekeeping by definition), then you need to compromise. This refusal to compromise is part of the problem.
I don't think it is. Or rather I don't want there to be.
It is really difficult to justify in a larger project maintained by volonteers that they have to do something, at all, without treating them as your employees. And that way projects die quickly in my experience, unless those that do the demanding also pay for it (which also in my experience they very seldomly do. "The more people demand, the less they pay" is a bit too drastic a phrase I guess but it sort of served me well).
At the same time, focusing on accessibility is really important - so I agree with you (and disagree with you at the same time) - but I think its best spent in areas where you have the least chance of finding users able to to contribute directly to the code. Emacs being... well being very very emacs is aimed at a core set of users, who are more likely to be able to create the change they wish to see, fork the project as needed and implement their solutions.
Front facing, GUI-centric projects aimed at less technically apt users demand more care towards different levels of skill.
The problem is that the balance, right now, is putting too much weight on project maintainers and contributors the larger the project. To the point where many projects simply get pulled and kept as private repos by maintainers (and I have seen first hand the burnouts that happen in Open Source projects with maintainers and contributors of varying levels simply stopping or worse disappearing).
As you say though, accessibility is important - but ALL work need to be weighed against contributor joy.
I don't see how this is gatekeeping. There already is intuitive software for text editing. People who choose to use software like emacs (or vim) are inherently a group of people who want to spend more time to learn more complex software for efficiency benefits down the road.
How does privilege factor into the choice to keep complex, capable software complex?
You don't see how the dismissive, snide comment by RMS about cosmetics are gatekeeping?
If you don't see how privilege is a factor here then I think you need to learn what privilege is and examine your own.
He's essentially just saying "don't judge a book by it's cover". Personally, I'm a big fan of not judging things by their appearances, so I actually agree with RMS here.
Can you please explain how privilege is a factor here, because I'm not seeing it.
I don’t necessarily agree with your other remarks, but this quote makes it very clear to me that Stallman is gatekeeping with prejudice, no doubt about it: