Making Emacs Popular Again(lwn.net)
lwn.net
Making Emacs Popular Again
https://lwn.net/SubscriberLink/819452/1480c3a59d3d9093/
781 コメント
New employee 3 workflow at company X:
1. Install Emacs
2. Sync existing config via git
3. Work
New employee 4 workflow at company X:
1. Install Emacs
2. Spend 2 hours learning default Emacs
3. Work
New employee 5 workflow at company X:
1. Install Emacs
2. Spend 1 - 2 hours learning default Emacs
3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality
4. Work
You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done.
I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config.
I have no idea why you would be running Emacs in a terminal in the first place.
1. Install Emacs
2. Sync existing config via git
3. Work
New employee 4 workflow at company X:
1. Install Emacs
2. Spend 2 hours learning default Emacs
3. Work
New employee 5 workflow at company X:
1. Install Emacs
2. Spend 1 - 2 hours learning default Emacs
3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality
4. Work
You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done.
I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config.
I have no idea why you would be running Emacs in a terminal in the first place.
Don't forget:
New employee 6 workflow at company X:
1. Install Spacemacs, don't bother fiddling with the config
2. Spend a few hours working through the tutorial or reviewing the excellent docs [1]
3. Work. Become a better developer [2].
[1]:https://www.spacemacs.org/doc/DOCUMENTATION.html
[2]:https://blog.osteele.com/2004/11/ides
New employee 6 workflow at company X:
1. Install Spacemacs, don't bother fiddling with the config
2. Spend a few hours working through the tutorial or reviewing the excellent docs [1]
3. Work. Become a better developer [2].
[1]:https://www.spacemacs.org/doc/DOCUMENTATION.html
[2]:https://blog.osteele.com/2004/11/ides
1. Install Spacemacs.
2. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it.
3. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug.
4. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that broke it. Dunno how to debug.
5. Complain on HN, get told you need to be using the master/develop version of packages because upstream devs don't care about maintaining stable releases.
6. Use unstable packages. Observe new errors whenever you update or do anything. Hope it doesn't break more than it's already broken.
2. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it.
3. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug.
4. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that broke it. Dunno how to debug.
5. Complain on HN, get told you need to be using the master/develop version of packages because upstream devs don't care about maintaining stable releases.
6. Use unstable packages. Observe new errors whenever you update or do anything. Hope it doesn't break more than it's already broken.
This.
While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.
I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.
vim is a similar rabbit hole, maybe less deep.
The real question is: can VS Code make you productive enough in less time?
While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.
I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.
vim is a similar rabbit hole, maybe less deep.
The real question is: can VS Code make you productive enough in less time?
Pretty much, yeah, from what I've seen. Against the shockingly low ambient baseline of "editors that aren't Vim
or Emacs", VS Code's highly usable OOTB experience and broad extension ecosystem are enough of an improvement to constitute a real win despite being so poor by comparison with a thoroughly evolved configuration of either of the Two True Editors.
I stick with Emacs because, now having invested more than a decade in learning to get the most out of it, I can do a lot of things in seconds that take VS Code users minutes or hours. But the converse is also true, and I think will only become more so. Especially in the realm of remote collaboration and mentorship, which has never been more important than it is today, VS Code does things that Emacs simply can't, and almost certainly never will.
That's fine, of course. That different tools should specialize in different things is perfectly reasonable, and I don't have the kind of emotional attachment to Emacs that would give me cause to be upset with its dwindling user share or its lack of broad appeal. It serves me very well, but it's not something I advocate, although of course I mentor those who take an interest.
I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for the mentoring-in-programming aspect of my role. That's where pretty much everyone else is, or is going. And in that context, its less fluent and less extensible user interface is probably a boon, once I get over being frustrated by it. In the context of teaching someone less experienced, acting with the speed of thought is really best avoided; if you don't explain why you're doing what you're doing, or offer the chance for questions and discussion, essentially the entire point is lost.
I stick with Emacs because, now having invested more than a decade in learning to get the most out of it, I can do a lot of things in seconds that take VS Code users minutes or hours. But the converse is also true, and I think will only become more so. Especially in the realm of remote collaboration and mentorship, which has never been more important than it is today, VS Code does things that Emacs simply can't, and almost certainly never will.
That's fine, of course. That different tools should specialize in different things is perfectly reasonable, and I don't have the kind of emotional attachment to Emacs that would give me cause to be upset with its dwindling user share or its lack of broad appeal. It serves me very well, but it's not something I advocate, although of course I mentor those who take an interest.
I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for the mentoring-in-programming aspect of my role. That's where pretty much everyone else is, or is going. And in that context, its less fluent and less extensible user interface is probably a boon, once I get over being frustrated by it. In the context of teaching someone less experienced, acting with the speed of thought is really best avoided; if you don't explain why you're doing what you're doing, or offer the chance for questions and discussion, essentially the entire point is lost.
> I can do a lot of things in seconds that take VS Code users minutes or hours.
Out of curiosity could you provide some examples of some of these?
Out of curiosity could you provide some examples of some of these?
"Out of curiosity" = "I'm going to nitpick this to hell and back"
Ahh, that's not what I was going for. I'm actually just curious. I'm willing to give emacs a try, but it just seems like it has kind of a steep learning curve, so want some strong reasons to know if it's worthwhile. This was the best I could find googling: https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time...
I mean, a lot of it is just the kind of complex one-off text transformations that would normally require a throwaway script or program to express. (They do in Emacs too, but you can write it as inline Lisp forms in the replacement side of a PCRE find-and-replace, and not deal with any boilerplate.) Refactors and stuff like that all happen through LSP providers, just like in VS Code.
If you're looking for a strong reason to think Emacs is worthwhile as a totally new user, I'd point instead to Magit, an extremely powerful and comfortable git porcelain, and Org-mode, which is simply the most powerful and flexible single-user notetaking/outlining/live code notebook tool yet created. Those are the two Emacs features I see most often mentioned as the subject of sentences like "I don't use Emacs for anything else, but I do use it for X because nothing else comes close".
That said, as I mentioned above, I'm not really here to evangelize Emacs. It definitely does have a steep learning curve, enough so that unless you see a clear killer feature (in my case, TRAMP's transparent remote file editing, since I edited remote files a lot in those days), it's not likely to be worth the trouble.
If you're looking for a strong reason to think Emacs is worthwhile as a totally new user, I'd point instead to Magit, an extremely powerful and comfortable git porcelain, and Org-mode, which is simply the most powerful and flexible single-user notetaking/outlining/live code notebook tool yet created. Those are the two Emacs features I see most often mentioned as the subject of sentences like "I don't use Emacs for anything else, but I do use it for X because nothing else comes close".
That said, as I mentioned above, I'm not really here to evangelize Emacs. It definitely does have a steep learning curve, enough so that unless you see a clear killer feature (in my case, TRAMP's transparent remote file editing, since I edited remote files a lot in those days), it's not likely to be worth the trouble.
This. After having fiddled around with Emacs over the weekend, having tried out Spacemacs and Doom and working through some tutorials, I concluded that I definitely won't replace VSCode with Emacs for coding any time soon.
As a Git & PIM-Tool, it seems to be useful though.
Come now, that’s a bit harsh... he didn’t nitpick at all, just asked for some pointers!
> I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.
I moved to Spacemacs becaues I wanted to write clojure without maintaining my own Clojure IDE in vim+tmux (this was around 2014, maybe 2015). I was productive in Spacemacs in around 10 minutes. I went from never using Emacs to fixing bugs and writing extensions in Emacs in less than two weeks because Spacemacs pervasively uses which-key to provide discoverability and had vim-style shortcuts I could use for real work (rather than learning a new set of keybindings). The groupings of things into layers makes studying what ecosystem packages provide what functionality much easier than blindly googling "how to do X in emacs" and getting 3000 "unique" (read: half-baked if you're lucky) solutions.
This idea that you should suffer for hours/days/weeks building your init.el from scratch while adapting to terminology, keybindings, and a lack of familiarity with the ecosystem is absolutely insane. If you can use vi, you're better off with Spacemacs.
I moved to Spacemacs becaues I wanted to write clojure without maintaining my own Clojure IDE in vim+tmux (this was around 2014, maybe 2015). I was productive in Spacemacs in around 10 minutes. I went from never using Emacs to fixing bugs and writing extensions in Emacs in less than two weeks because Spacemacs pervasively uses which-key to provide discoverability and had vim-style shortcuts I could use for real work (rather than learning a new set of keybindings). The groupings of things into layers makes studying what ecosystem packages provide what functionality much easier than blindly googling "how to do X in emacs" and getting 3000 "unique" (read: half-baked if you're lucky) solutions.
This idea that you should suffer for hours/days/weeks building your init.el from scratch while adapting to terminology, keybindings, and a lack of familiarity with the ecosystem is absolutely insane. If you can use vi, you're better off with Spacemacs.
As a counterexample to that somewhat... I initially tried learning emacs with spacemacs, and the amount of customization in spacemacs’s config made it difficult for me to compare it to much of the emacs documentation out there. Whatever documentation spacemacs had at the time was confusing enough to me that it wasn’t quite enough.
I later ended up starting with a stock config, and I probably could pick up spacemacs now if I wanted to, but at this point I don’t feel the need.
I later ended up starting with a stock config, and I probably could pick up spacemacs now if I wanted to, but at this point I don’t feel the need.
> vim is a similar rabbit hole, maybe less deep.
Vim was for a long time and still pretty much is mostly a text editor. It is light, work well with large files and is installed on most Unix machines. I don't think trying to turn it into an IDE makes much sense but if you want to develop with it, installing a language server client takes two minutes and you don't need much more.
As a text editor, Vim is really nice. Modal editing can be very pleasant if it clicks with you.
Vim was for a long time and still pretty much is mostly a text editor. It is light, work well with large files and is installed on most Unix machines. I don't think trying to turn it into an IDE makes much sense but if you want to develop with it, installing a language server client takes two minutes and you don't need much more.
As a text editor, Vim is really nice. Modal editing can be very pleasant if it clicks with you.
If you install Spacemacs from develop branch, don't change the defaults and enable just the git plugin, it's pretty much always going to work just fine unless elpa is down or something.
I install Spacemacs in every machine for the sole reason of using Magit with vim bindings. It's so far beyond all other git clients it's even hard to explain to others sometimes. If Magit existed as a native standalone app, I would be happy to pay €50-100 for it, right away. But, but... :/
I install Spacemacs in every machine for the sole reason of using Magit with vim bindings. It's so far beyond all other git clients it's even hard to explain to others sometimes. If Magit existed as a native standalone app, I would be happy to pay €50-100 for it, right away. But, but... :/
You can always donate the same funds to the development of magit.
I cannot recommend Spacemacs enough. I was a pretty dedicated Vim user for years but grew tired of the brittle tooling and subpar extensibility and decided to give Emacs a try. My first experience with Emacs was dreadful - the default keybinds were counter-intuitive and hard to use (no, I should not have to remap my control key to caps lock just to avoid carpal tunnel), basic features were absent yet included was a web browser, mail client, etc.
A month or two later I gave Spacemacs a try, and I've been using it ever since. Not only does it have sane defaults like evil-mode for Vim emulation, but a lot of terrific packages like Magit and Org-mode are builtin. I also use the Spacemacs docs as my first resort when I want to install something new or fiddle with settings, rather than the subpar GNU Emacs documentation which never quite tells me the exact information I'm looking for.
A month or two later I gave Spacemacs a try, and I've been using it ever since. Not only does it have sane defaults like evil-mode for Vim emulation, but a lot of terrific packages like Magit and Org-mode are builtin. I also use the Spacemacs docs as my first resort when I want to install something new or fiddle with settings, rather than the subpar GNU Emacs documentation which never quite tells me the exact information I'm looking for.
+1 I was really attached to my vim config but decided to try out SpaceVim [1] (the vim version of SpaceMacs) after a stint using VSCode and after reinstalling my OS (before pulling in my usual vim .git) and I was surprised it was almost the same as what I spent years perfecting but with a far better and logical key mapping scheme that fit neatly across plugins + a nice programming language extension/layer scheme.
It's the oh-my-zsh of vim/emacs.
After a year of SpaceVim, when I finally found time, I ended up switching back to my more lightweight and stripped down version of NeoVim but copied the keymapping approach and some of the individual configs. It was a great starting point.
If you're a) new to vim/emacs or b) tired of maintaining your own config for w/e reason, Space[x] is entirely usable in it's default state with good documentation. It also updates often and stays on the cutting edge of various plugins and progression in the community, but with the stability of a larger community.
It defeats a lot of the learning/config curve arguments again vim/emacs.
[1] https://spacevim.org/
It's the oh-my-zsh of vim/emacs.
After a year of SpaceVim, when I finally found time, I ended up switching back to my more lightweight and stripped down version of NeoVim but copied the keymapping approach and some of the individual configs. It was a great starting point.
If you're a) new to vim/emacs or b) tired of maintaining your own config for w/e reason, Space[x] is entirely usable in it's default state with good documentation. It also updates often and stays on the cutting edge of various plugins and progression in the community, but with the stability of a larger community.
It defeats a lot of the learning/config curve arguments again vim/emacs.
[1] https://spacevim.org/
Weird. I tried spacevim, via their docker container. First impressions were 100% CPU use after entering:
int main(
If one needs a docker container to run a text editor, I think that says all that needs to be said about it.
Well, sort of. Something like spacevim requires some dependencies I imaging. Docker is sort of a package manager, so it makes sense to run the 1.1G docker image to see what you're getting into.
Anyway, this way I saw an issue early on that stopped me from going any further, and saved me much time and heart ache.
Sticking to my plain old .vimrc for now.
Anyway, this way I saw an issue early on that stopped me from going any further, and saved me much time and heart ache.
Sticking to my plain old .vimrc for now.
Sorry, but that's not true anymore. The spacemacs project has kind of gone off the rails and it doesn't seem like they have any idea about what they really want to do.
The next release has been coming for several years and it's not yet there. This means that you can either choose between the master branch and get hopelessly outdated stuff or the development branch which is so chaotic that you better be ready for things to break constantly.
I used spacemacs for years, then I tried doom emacs and it took me all of 15 seconds to realize that I should switch.
The next release has been coming for several years and it's not yet there. This means that you can either choose between the master branch and get hopelessly outdated stuff or the development branch which is so chaotic that you better be ready for things to break constantly.
I used spacemacs for years, then I tried doom emacs and it took me all of 15 seconds to realize that I should switch.
While the most practical employee 7 installs Prelude[1]:
1. Install Prelude 2. Work
[1] http://batsov.com/prelude/
1. Install Prelude 2. Work
[1] http://batsov.com/prelude/
I tried spacemacs last month.
It didn't work. So I gave up.
PS: I am on windows.
It didn't work. So I gave up.
PS: I am on windows.
New employees 4 and 5 are completely fictitious and only exist in your imagination/reality bubble. In the real world no mortal has ever learned how to use Emacs in 2 hours to be able to work effectively. And like the OC said the documentation for extra packages are horrible, full of bugs and may take additional week to understand how to use effectively.
It's a text editor. You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.
More sophisticated ide like features normally constitute reading the documentation for a particular project like cider for clojure.
I have no idea why you consider 4 and 5 fictitious. One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
More sophisticated ide like features normally constitute reading the documentation for a particular project like cider for clojure.
I have no idea why you consider 4 and 5 fictitious. One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
> You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.
It is one thing to know enough and quite other to be proficient in using them effectively. With the horrible and unintuitive default keybindings it takes even longer to develop muscle memory.
> One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
Yes one can in theory. But again if everybody could become proficient in something just by reading manuals then we could shut down our expensive schools and colleges and any sort of practical training. Also, everyone could then program in `ed` or TECO.
Curious, have you actually met any other person who's not an emacs user in real life, like ever? Here's an experiment, go to any decent software company and ask 5 new hires who've never used Emacs, give them the manual and see how long it takes them to actually do something significant? Then give them VSCode and compare notes.
It is one thing to know enough and quite other to be proficient in using them effectively. With the horrible and unintuitive default keybindings it takes even longer to develop muscle memory.
> One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.
Yes one can in theory. But again if everybody could become proficient in something just by reading manuals then we could shut down our expensive schools and colleges and any sort of practical training. Also, everyone could then program in `ed` or TECO.
Curious, have you actually met any other person who's not an emacs user in real life, like ever? Here's an experiment, go to any decent software company and ask 5 new hires who've never used Emacs, give them the manual and see how long it takes them to actually do something significant? Then give them VSCode and compare notes.
Did you mean to ask if I'd ever met an Emacs user? I'm pretty sure we both pass people who haven't heard of any text editor or IDE all the time.
I'm not likely to meet many Emacs users regularly as I don't work in tech I'm just interested in it. I've met Emacs and vim users at a clojure meet up but that isn't exactly shocking.
I'm not likely to meet many Emacs users regularly as I don't work in tech I'm just interested in it. I've met Emacs and vim users at a clojure meet up but that isn't exactly shocking.
I second this so much. Emacs configs like Spacemacs, Doom, or M-Emacs provide an excellent out-of-the box experience.
Disclaimer: mostly vim guy. I agree that Emacs is super powerful for power users, don't agree that it's intuitive or easy for new users. Also I found spacemacs to be pretty brittle when I last tried it a year ago.
Agreed on Spacemacs. Seems like a lot of stuff I had to switch to the Develop branch for it to work right. Supposedly the next release is coming out soon which will fix a lot. I’ve since switched to Doom which I like better anyways though.
You forgot new employee 0:
1. Install Emacs
2. Finds magit
3. Questions reality before swimming in new found joy
1. Install Emacs
2. Finds magit
3. Questions reality before swimming in new found joy
Magit is so good that it should be shipped by default into Emacs.
Alas the process of integrating any outside code into Emacs is tangled behind three layers of bulletproof glass.
I'm not against the glass, as it's a good defence against hostile thieves, but it sure kills any desire to merge outside code
Alas the process of integrating any outside code into Emacs is tangled behind three layers of bulletproof glass.
I'm not against the glass, as it's a good defence against hostile thieves, but it sure kills any desire to merge outside code
magit is clearly a cosmic planet alignment, whatever happens is a choice from the universe I won't question
> if you do this in the time you would be watching Netflix instead of the time you are supposed to be working
And why would I be doing that? Configuring and learning your work tools is part of work, it should be done in work time.
And why would I be doing that? Configuring and learning your work tools is part of work, it should be done in work time.
Think they key here is you read a book whilst the prev op just assumed reading random guides on the Internet would be an appropriate way to learn a piece of software for professional use.
[deleted]
> I have no idea why you would be running Emacs in a terminal in the first place.
I don't see an advantage of using it outside of the terminal in the first place to be honest.
That's the good part about vim. Or if it's complicated for you, use nano. Done. Editing of files while you're in the terminal.
And yes vimscript is annoying, but it seems to be simple enough for most of the basic stuff.
Otherwise there are plenty of GUI editors that work fine.
I don't see an advantage of using it outside of the terminal in the first place to be honest.
That's the good part about vim. Or if it's complicated for you, use nano. Done. Editing of files while you're in the terminal.
And yes vimscript is annoying, but it seems to be simple enough for most of the basic stuff.
Otherwise there are plenty of GUI editors that work fine.
https://blog.aaronbieber.com/2016/12/29/don-t-use-terminal-e...
Accepting the terminal version is accepting an inferior environment with no upside.
Accepting the terminal version is accepting an inferior environment with no upside.
Interesting to know. Though calling the terminal only version an "inferior version" to me sounds like they are aware of its caveats.
TRAMP sounds nice but a lot of times I can't have emacs on the other side. And vim with screen/tmux works fine
TRAMP sounds nice but a lot of times I can't have emacs on the other side. And vim with screen/tmux works fine
This view is obviously biased against Emacs, but I don't disagree completely with the premise.
As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria.
Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them I guess.
[1] https://chrisdone.com/posts/emacs-users-are-like-igor/
[2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html
As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria.
Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them I guess.
[1] https://chrisdone.com/posts/emacs-users-are-like-igor/
[2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows.
I've been writing software for ~24 years, and I can understand the need for this in the past.
Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar.
The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?
I've been writing software for ~24 years, and I can understand the need for this in the past.
Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar.
The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?
> Can you talk about a few use cases where emacs is just better than an IDE could be?
I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues.
Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though.
Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive)
I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues.
Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though.
Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive)
A +1 here for your comment...
I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim
I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim
You can do one thing in JetBrains: edit code. That's it.
In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface. I edit remote files, I edit files via sudo on my machine. I control git. Yes, JetBrains can do git, too. My colleagues sometimes use it. Actually, they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows. Not different people. Everybody individually! Why? Because they know how to do different things in different tools. Meanwhile, I just use magit. Magit is absolutely fantastic, there is no better git interface, and I've tried many. Even for our backend Kotlin code, which I have to use IntelliJ for, I jump back to Emacs to use git, and edit yaml/graphql/etc files.
I've probably forgotten a couple of things here. And the cool part is that Emacs now supports LSP very well, and LSP is starting to support a lot of languages very well. So I don't even miss IDE features, such as refactoring. Add to that block selection, the best undo mode, actually robust modal editing (evil!) fantastic documentation, great flexibility, keyboard macros (I use them ~2-3 a week, and they're great every time)
… the list goes on. I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface. I edit remote files, I edit files via sudo on my machine. I control git. Yes, JetBrains can do git, too. My colleagues sometimes use it. Actually, they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows. Not different people. Everybody individually! Why? Because they know how to do different things in different tools. Meanwhile, I just use magit. Magit is absolutely fantastic, there is no better git interface, and I've tried many. Even for our backend Kotlin code, which I have to use IntelliJ for, I jump back to Emacs to use git, and edit yaml/graphql/etc files.
I've probably forgotten a couple of things here. And the cool part is that Emacs now supports LSP very well, and LSP is starting to support a lot of languages very well. So I don't even miss IDE features, such as refactoring. Add to that block selection, the best undo mode, actually robust modal editing (evil!) fantastic documentation, great flexibility, keyboard macros (I use them ~2-3 a week, and they're great every time)
… the list goes on. I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
> You can do one thing in JetBrains: edit code. That's it.
You can also takes notes in markdown docs and/or code comments (it has a built-in TODO detector and organizer).
> they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows
I just use SmartGit for git. It's configurable with workflows (or custom commands), navigable with a keyboard, visual, clickable, and actually "smart" -- it warns you if it thinks you're about to do something stupid, like overwrite a repository's history.
> In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface.
This is good info. These are all things I really, really don't want to do in my IDE. I want my IDE to be a good IDE, and I want my other tools to be purpose-built as well.
Switching apps is not painful to me at all. I often have a screen with a git GUI, IDE, browser, and DB GUI all open at the same time.
You can also takes notes in markdown docs and/or code comments (it has a built-in TODO detector and organizer).
> they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows
I just use SmartGit for git. It's configurable with workflows (or custom commands), navigable with a keyboard, visual, clickable, and actually "smart" -- it warns you if it thinks you're about to do something stupid, like overwrite a repository's history.
> In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface.
This is good info. These are all things I really, really don't want to do in my IDE. I want my IDE to be a good IDE, and I want my other tools to be purpose-built as well.
Switching apps is not painful to me at all. I often have a screen with a git GUI, IDE, browser, and DB GUI all open at the same time.
I get it, not everybody has the mindset of living in one tool — I didn't either, before I converted to Emacs, which is a relatively recent development. Maybe 3-4 years, though I did use it ~7 years ago once, and then even further back, probably around 12 or so years ago. I don't quite remember.
But I came back to it, and stayed for good, because Emacs is really an OS with a nice editor. So you can have the same approach of do one thing and do it well, but you have different packages instead of different programs. And they synergize nicely. So it's not only an IDE. Everything I use is purpose-built for that one task, including ledger (accounting), mu4e (mail), lsp (IDE-features), org (agenda, research, documentation) magit (git) etc. None of these things are "plugins". They're programs in their own right, just like ls and mutt, and git themselves.
But I came back to it, and stayed for good, because Emacs is really an OS with a nice editor. So you can have the same approach of do one thing and do it well, but you have different packages instead of different programs. And they synergize nicely. So it's not only an IDE. Everything I use is purpose-built for that one task, including ledger (accounting), mu4e (mail), lsp (IDE-features), org (agenda, research, documentation) magit (git) etc. None of these things are "plugins". They're programs in their own right, just like ls and mutt, and git themselves.
> This is good info. These are all things I really, really don't want to do in my IDE
The point of Emacs is that it's a text-editor, and as someone editing text all day (code, documentation, etc) I want the best, most consistent text-editing and text-process possible, without having to jump from tool to tool.
With Emacs, you can mold everything you do to be consistent across all dimensions you can imagine. Once you get used to it, it is very weird (unthinkable?) to go back to other tools.
The point of Emacs is that it's a text-editor, and as someone editing text all day (code, documentation, etc) I want the best, most consistent text-editing and text-process possible, without having to jump from tool to tool.
With Emacs, you can mold everything you do to be consistent across all dimensions you can imagine. Once you get used to it, it is very weird (unthinkable?) to go back to other tools.
What are your favourite features about magit? I switch between Pycharm and Vs code and terminal for my git usage. I find Pycharm has a really great git blame ui that makes it easy to walk back in time and investigate changes. It lets you toggle "Annotations" next to the line number, that display the SHA. From there, you can right click > show diff, from which you can _also_ show annotations, and continue jumping back ad infinitum. Vs code has a plugin which does something similar, but I find the UX to be not as elegant (the annotations are way too wide; every option is hidden behind cryptic icons like "<<"; diffs open in new tabs, which makes things cluttered; and instead of right click menus they have really large hover menus which I find are super finicky to use). VS Code's conflict resolution is a little easier to use for me. Pycharm's approach is a little overly UI'd, whereas Vs code treats everything as text with helpful little overlays for quickly selecting one vs the other. Also when viewing local changes as a diff, Vs code's highlight change > right click > "stage selected lines" is more flexible then Pycharm which only shows a little checkmark near "chunks" of the diff for staging. Both editors also have a lovely feature that lets you highlight text and copy the GitHub link to the chunk or the entire file. Makes sharing really easy.
I use the git terminal for everything else; branching, checkouts, rebasing, pulling, pushing. Actually I use vim for interactive rebasing because it's fast/quick there.
I use the git terminal for everything else; branching, checkouts, rebasing, pulling, pushing. Actually I use vim for interactive rebasing because it's fast/quick there.
> What are your favourite features about magit?
For a similarly complex task, there is no program with a better UI.
Magit manages to optimize for both, speed and discoverability: 99% of all actions are 2-3 keystrokes away, and at each stage of that process, magit will tell you your options. For example, invoke magit, press 'b' brings up the branching menu, basically a keymap for letter -> action. Pressing 'c' for checkout then starts a new branch creation. The default branchpoint is your current branch. If that is fine, press enter, otherwise type out the branch name (tab completion for all possibilities, local and remote). Finally, you name your branch. So in 99% of the cases, it is b>c>enter>my_cool_new_feature>enter, done.
Before magit, using version control was a necessary evil (for me). Nowadays, it is so effortless, so natural, that it hardly registers in my attention -- similar to the way that you automatically save the file that you are working on after a couple of lines of writing without noticing that you are doing it.
All cli tools should have a magit interface. World peace and happiness would ensue.
For a similarly complex task, there is no program with a better UI.
Magit manages to optimize for both, speed and discoverability: 99% of all actions are 2-3 keystrokes away, and at each stage of that process, magit will tell you your options. For example, invoke magit, press 'b' brings up the branching menu, basically a keymap for letter -> action. Pressing 'c' for checkout then starts a new branch creation. The default branchpoint is your current branch. If that is fine, press enter, otherwise type out the branch name (tab completion for all possibilities, local and remote). Finally, you name your branch. So in 99% of the cases, it is b>c>enter>my_cool_new_feature>enter, done.
Before magit, using version control was a necessary evil (for me). Nowadays, it is so effortless, so natural, that it hardly registers in my attention -- similar to the way that you automatically save the file that you are working on after a couple of lines of writing without noticing that you are doing it.
All cli tools should have a magit interface. World peace and happiness would ensue.
> All cli tools should have a magit interface. World peace and happiness would ensue.
:) Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli. That does sound great! There are some git commands which would be super annoying to do via a UI (not to mention if you add _all_ of git's features to a UI, good luck making anything discoverable :P), but in the CLI they're kind of awkward cause unless it's something I use very frequently, I forget the syntax (looking at you git bisect). This sounds like it would make those significantly easier to use, _and_ help the developer discover new git commands they might not be aware of (looking at you, git bisect :P).
:) Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli. That does sound great! There are some git commands which would be super annoying to do via a UI (not to mention if you add _all_ of git's features to a UI, good luck making anything discoverable :P), but in the CLI they're kind of awkward cause unless it's something I use very frequently, I forget the syntax (looking at you git bisect). This sounds like it would make those significantly easier to use, _and_ help the developer discover new git commands they might not be aware of (looking at you, git bisect :P).
> Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli
It's a complete git "porcelain", in that it provides more or less full access to all git offers.
I daily rewrite git history in my feature-branches, cleaning up my commits, to provide fully atomic and clean merges back into dev.
Using magit, it's just seamless and feels immensly rewarding wrt doing a good job. Without magit? I wouldn't even bother.
Magit is not "just" a wrapper around the git CLI. It's a complete replacement, enabling you to fully exploit all of Git's power without ever leaving your editor of choice, nor exposing you to complex internals.
It's an amazing product, and I've seen people ask for a Magit-only Emacs-distro, just to replace their existing Git client.
It's a complete git "porcelain", in that it provides more or less full access to all git offers.
I daily rewrite git history in my feature-branches, cleaning up my commits, to provide fully atomic and clean merges back into dev.
Using magit, it's just seamless and feels immensly rewarding wrt doing a good job. Without magit? I wouldn't even bother.
Magit is not "just" a wrapper around the git CLI. It's a complete replacement, enabling you to fully exploit all of Git's power without ever leaving your editor of choice, nor exposing you to complex internals.
It's an amazing product, and I've seen people ask for a Magit-only Emacs-distro, just to replace their existing Git client.
I think incremental commits are among my favorites in magit. It's so quick and easy to stage and commit selectively.
The other thing I love about it is discoverability of git features. Did you know that you can stash index and working tree separately? I only know because of magit. Now that I know, I have actually used it to great success.
Also, I've become my team's go-to rebase monkey. What takes my colleagues minutes of thinking what to rebase where, and how, and how to deal with the conflicts, I'm usually done in seconds. Also, conflict resolution with magit is really very streamlined. Conflicts still suck, but less so.
Pushing/pulling to/from different remotes is quick and easy (happens often with github forks and PRs), merging and branching is a breeze, and you've got splendid auto-completion on branch and tag names (I use ivy.)
The blame mode you described exists in magit, too. You can annotate a file and drill back into a certain commit's history. Actually, the default way magit does it is dissimilar from what you might be used to from other GUI tools. Magit doesn't annotate the left or right, but instead inserts header lines for a commit. That way it's easier to see coherent commits. I find this way of displaying history nicer if your code's commit history actually contains chunks of lines for the files, and it's not so fragmented that practically every line is from a different commit/author. It's possible to do the margin-annotation you're used to from other blame tools, too, though.
The other thing I love about it is discoverability of git features. Did you know that you can stash index and working tree separately? I only know because of magit. Now that I know, I have actually used it to great success.
Also, I've become my team's go-to rebase monkey. What takes my colleagues minutes of thinking what to rebase where, and how, and how to deal with the conflicts, I'm usually done in seconds. Also, conflict resolution with magit is really very streamlined. Conflicts still suck, but less so.
Pushing/pulling to/from different remotes is quick and easy (happens often with github forks and PRs), merging and branching is a breeze, and you've got splendid auto-completion on branch and tag names (I use ivy.)
The blame mode you described exists in magit, too. You can annotate a file and drill back into a certain commit's history. Actually, the default way magit does it is dissimilar from what you might be used to from other GUI tools. Magit doesn't annotate the left or right, but instead inserts header lines for a commit. That way it's easier to see coherent commits. I find this way of displaying history nicer if your code's commit history actually contains chunks of lines for the files, and it's not so fragmented that practically every line is from a different commit/author. It's possible to do the margin-annotation you're used to from other blame tools, too, though.
Thanks for the examples! The magit page is a little hard for me to grok why it might be worth switching to something else.
> Did you know that you can stash index and working tree separately?
What does this mean? Can you give an example?
> Also, I've become my team's go-to rebase monkey.
Haha, hello friend. I love rebasing; it always breaks my heart a little when I see "Merged master into branch X" commits :P My main git rebase flow is `git checkout master; git pull upstream master; git checkout X; git rebase -i master` + vim. Having multiple branches that depend on a shared branch does get a little messy though. How does magit make this flow better?
> Conflicts still suck, but less so.
Hahaha, that's all you can hope for with merge conflicts!
> Did you know that you can stash index and working tree separately?
What does this mean? Can you give an example?
> Also, I've become my team's go-to rebase monkey.
Haha, hello friend. I love rebasing; it always breaks my heart a little when I see "Merged master into branch X" commits :P My main git rebase flow is `git checkout master; git pull upstream master; git checkout X; git rebase -i master` + vim. Having multiple branches that depend on a shared branch does get a little messy though. How does magit make this flow better?
> Conflicts still suck, but less so.
Hahaha, that's all you can hope for with merge conflicts!
`git status` always shows you some of three things: files not tracked by git, tracked files with modifications that are not staged, and tracked files with modifications that are staged.
You can stash tracked files with modifications, or tracked files without modifications separately! Scenario: I've staged a couple files for a commit I'm preparing, but I see that there's an unrelated change in the unstaged files that I want to do in a commit that should come first. So I stash everything I've staged. I do not stash what I haven't staged! Now I can create that new commit, and pop the stash later to come back to the commit I wanted to originally write.
You can stash tracked files with modifications, or tracked files without modifications separately! Scenario: I've staged a couple files for a commit I'm preparing, but I see that there's an unrelated change in the unstaged files that I want to do in a commit that should come first. So I stash everything I've staged. I do not stash what I haven't staged! Now I can create that new commit, and pop the stash later to come back to the commit I wanted to originally write.
I agree with all of this, especially discoverability of git features. I think using magit really helped me build a mental model of what git’s doing and what it can do vs. just using the git CLI on it’s own.
And yeah, incremental committing, the rebase workflow, working with multiple remotes... they’re all a breeze. With the GitHub style PR workflow, I typically set the main repo for a project as the “upstream” remote and my fork as “origin.” With the settings I’m used to for a project, pulling down the latest changes from upstream is two keystrokes: “F u”, and pushing back up to my fork is two more: “P p”.
And yeah, incremental committing, the rebase workflow, working with multiple remotes... they’re all a breeze. With the GitHub style PR workflow, I typically set the main repo for a project as the “upstream” remote and my fork as “origin.” With the settings I’m used to for a project, pulling down the latest changes from upstream is two keystrokes: “F u”, and pushing back up to my fork is two more: “P p”.
Really? There's a way to edit confluence pages in emacs? you've made me very happy!
EDIT: https://www.emacswiki.org/emacs/ConfluenceMode
EDIT: https://www.emacswiki.org/emacs/ConfluenceMode
Actually, I just use ox-confluence, which means I can export (narrowed) org-mode trees to confluence. It exports it to a buffer that I cut-and-paste into the web page.
I think confluence.el is no longer maintained, sadly. Maybe an interesting new side project :)
I think confluence.el is no longer maintained, sadly. Maybe an interesting new side project :)
> You can do one thing in JetBrains: edit code. That's it.
No, you can do more, it's just usually people don't have the mindset to do more. And to be fair, JetBrains software is not meant to do that, so it's harder to do it, preventing the people from developing the mindset. It's a loop.
No, you can do more, it's just usually people don't have the mindset to do more. And to be fair, JetBrains software is not meant to do that, so it's harder to do it, preventing the people from developing the mindset. It's a loop.
Thats just plan incorrect. JetBrains lets you do the following, out of the box:
- Edit Code - Debug Said Code - Run Said Code - Manage your repo via Git, SVN, or Perforce - Has GitHub integration built in - Has PlantUML integration for creating UML diagrams via their markdown editor (its pretty nifty and I believe now bundled by default) - Connect multiple SSH sessions - Connect multiple SFTP sessions (semantics right)
and so on and son on..I can even do remote editing as if its there, righ tin front of me. you can't even tell if the filesystem is remote because of how it populates in the IDE.
So please, what doe sit not actually do again?
and via plugins, (and a plugin ecosystem that tends to be well manicured/maintained, at that), you can add an LSP or many other languages that are supported. I've tried many many editors, and JetBrain IDE plugins are some of the highest quality i've ever worked with.
So please, tell me, what do they not do again?
- Edit Code - Debug Said Code - Run Said Code - Manage your repo via Git, SVN, or Perforce - Has GitHub integration built in - Has PlantUML integration for creating UML diagrams via their markdown editor (its pretty nifty and I believe now bundled by default) - Connect multiple SSH sessions - Connect multiple SFTP sessions (semantics right)
and so on and son on..I can even do remote editing as if its there, righ tin front of me. you can't even tell if the filesystem is remote because of how it populates in the IDE.
So please, what doe sit not actually do again?
and via plugins, (and a plugin ecosystem that tends to be well manicured/maintained, at that), you can add an LSP or many other languages that are supported. I've tried many many editors, and JetBrain IDE plugins are some of the highest quality i've ever worked with.
So please, tell me, what do they not do again?
>In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs.
No one cares (other than Emacs users). There are better tools designed for those purposes. There's a reason the UNIX philosophy of doing one thing well is still so popular and widely used. Rather than configuring and spending hours on buggy, poorly developed and indecipherable systems like Gnus, org-mode (it's like an Emacs with an Emacs, just ridiculous) etc people instead choose tools that are far better, more intuitive and works out of the box and everywhere.
> I edit remote files, I edit files via sudo on my machine.
Any decent editor or IDE can do that.
>I control git.
VSCode support for Git (and Github) blows everything else out there. And so also for languages like Python. Emacs support for any language which is not a Lisp dialect or C is horrible.
> I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
I very much doubt you actually tried to use anything else.
No one cares (other than Emacs users). There are better tools designed for those purposes. There's a reason the UNIX philosophy of doing one thing well is still so popular and widely used. Rather than configuring and spending hours on buggy, poorly developed and indecipherable systems like Gnus, org-mode (it's like an Emacs with an Emacs, just ridiculous) etc people instead choose tools that are far better, more intuitive and works out of the box and everywhere.
> I edit remote files, I edit files via sudo on my machine.
Any decent editor or IDE can do that.
>I control git.
VSCode support for Git (and Github) blows everything else out there. And so also for languages like Python. Emacs support for any language which is not a Lisp dialect or C is horrible.
> I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
I very much doubt you actually tried to use anything else.
Which tool would you suggest for Org-mode?
I have been reading up on it and it almost made me want to use emacs. But if there is a better tool designed for it's purpose..
This comment is quite harsh and definitely doesn’t seem to assume good faith in the person you’re replying to
Emacs user here. I've been thinking about this lately since I switched to VSCode because Emacs doesn't have a good TypeScript React mode and to be honest, you're right.
The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just nothing else like it, and boy is Magit slow when I have to merge big changes (probably exacerbated by Emacs Mac port's slow vfork).
The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just nothing else like it, and boy is Magit slow when I have to merge big changes (probably exacerbated by Emacs Mac port's slow vfork).
I was about to switch to VS for that reason and then I discovered Tide, which works grest as a React Typescript mode for me.
But to be honest I only use Emacs because 28 years of using it has made it feel like home, I don't usually recommend it to new people.
But to be honest I only use Emacs because 28 years of using it has made it feel like home, I don't usually recommend it to new people.
Tide + https://github.com/jscheid/prettier.el + projectile + helm work wonders. Been using this for +3 years now and its one of the bigger productivity improvements in my recent years of emacs and programming practice.
At work, I actually try to get ppl away from Jetbrains IDEs because they are slow and their typescript and prettier support seems pretty buggy to me.
Unfortunately, most developers I meet these times are not the kind of hacker types that want to understand and optimize their tools but rather just to get stuff done on the surface (which is totally fine). So emacs isn't just a good fit for them.
At work, I actually try to get ppl away from Jetbrains IDEs because they are slow and their typescript and prettier support seems pretty buggy to me.
Unfortunately, most developers I meet these times are not the kind of hacker types that want to understand and optimize their tools but rather just to get stuff done on the surface (which is totally fine). So emacs isn't just a good fit for them.
> prettier support
I use emacs/tide/prettier-js, but the prettier formatting only happens on save. Do you have settings that make emacs adhere to prettier formatting as it goes along?
I use emacs/tide/prettier-js, but the prettier formatting only happens on save. Do you have settings that make emacs adhere to prettier formatting as it goes along?
Are there problems with typescript react on spacemacs or doom emacs?
As far as I know on the Vim side you can get feature parity.
As far as I know on the Vim side you can get feature parity.
1. Nothing I've found comes anywhere close to Emacs support for keyboard macros. Zero latency to record. Records every keystroke. Very very consistent behavior. Infinite undo. Kill Ring. Register support.
Despite being an expert Emacs user, I'm mostly in VS Code these days because it has syntax highlighting, git support, and linting out of the the box. But I always go back to Emacs when I need to transform a bit of text.
2. Comparing two text snippets, as opposed to files.
There are a small set of use cases where you want to look at every position where something has changed. You can open two buffers in Emacs and use compare-windows to walk through them. Since the IDEs are all file-oriented, they don't work for this case well.
Despite being an expert Emacs user, I'm mostly in VS Code these days because it has syntax highlighting, git support, and linting out of the the box. But I always go back to Emacs when I need to transform a bit of text.
2. Comparing two text snippets, as opposed to files.
There are a small set of use cases where you want to look at every position where something has changed. You can open two buffers in Emacs and use compare-windows to walk through them. Since the IDEs are all file-oriented, they don't work for this case well.
What are some examples of keyboard macros you use? I read a lot about people loving keyboard macros, but I can honestly say I've never thought of a use-case for them. There's already a built-in IDE automation for everything I could think to do with a macro.
If you have, say, a list on consecutive lines with a blank line in between them, and you want to delete a character after the second word, add some text at the end, and delete the blank line - with keyboard macros you record these transformations once and then apply them to the rest of the items.
Somethings I find more convenient with Emacs than modern IDEs:
-Remote file editing with Tramp: This is much better even than using vi/pick over a terminal.
-Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history.
-Easy macro recording and playback.
-Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolling of required.
-Rectangular/column edits.
-Built in file manager.
-Built in shell, can run shell programs and capture their output.
-Remote file editing with Tramp: This is much better even than using vi/pick over a terminal.
-Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history.
-Easy macro recording and playback.
-Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolling of required.
-Rectangular/column edits.
-Built in file manager.
-Built in shell, can run shell programs and capture their output.
You nailed it.
I'd also add:
- incredibly ergonomic file-system navigation (helm+projectile)
First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?
I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.
I'd also add:
- incredibly ergonomic file-system navigation (helm+projectile)
First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?
I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.
> emote file editing with Tramp: This is much better even than using vi/pick over a terminal.
You're probably aware, but VSCode has great support for editing over SSH.
You're probably aware, but VSCode has great support for editing over SSH.
For those who care about this (I do): that’s a proprietary Microsoft extension and doesn’t work in the free software versions.
https://github.com/VSCodium/vscodium/issues/240
https://github.com/VSCodium/vscodium/issues/240
Apart from remote file editing everything else exists in modern IDEs. When is the last time you looked at an IDE?
Remote file-editing is also available with other editors and IDEs. Everything KDE has it out if the box for example. Vim has IIRC some protocols. VS Code got some a bit ago as I heard.
I'd be surprised if a modern editor didn't support remote editing (SSH).
> Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I thing it's a bit between exploring the possibilities of your tools, expressing yourself in some "divine art" and procrastinating under the guise of being productive. There is definitly a high amount of good customizing possible with emacs, but from my observation many end also in the trap of over-custimizing, to the point where it becomes harmful. Not to forgotten all the worthless oversmart solutions build in emacs, beacuse emacs gives them the means to do it.
> The level of customization that emacs supports seems unnecessary to me.
Emacs is a platform for textual and programatic interfaces. Similar to web-technologie. As such you can tweak little things, but also build whole apps dedicated to specific usecases with it.
> Can you talk about a few use cases where emacs is just better than an IDE could be?
It's not better than IDE, but similar level as IDE. Just that you are able to do it yourself. With an IDE, if you have a specific demand like integrating some new tool, or handling some specific filetype, you depend on the producer to build it into the IDE. Just recently IDEs have also learned to use plugins, to allow you build some stuff yourself. Ok, recently was 15-20 years ago, but emacs is 40 years old, predating them all.
I thing it's a bit between exploring the possibilities of your tools, expressing yourself in some "divine art" and procrastinating under the guise of being productive. There is definitly a high amount of good customizing possible with emacs, but from my observation many end also in the trap of over-custimizing, to the point where it becomes harmful. Not to forgotten all the worthless oversmart solutions build in emacs, beacuse emacs gives them the means to do it.
> The level of customization that emacs supports seems unnecessary to me.
Emacs is a platform for textual and programatic interfaces. Similar to web-technologie. As such you can tweak little things, but also build whole apps dedicated to specific usecases with it.
> Can you talk about a few use cases where emacs is just better than an IDE could be?
It's not better than IDE, but similar level as IDE. Just that you are able to do it yourself. With an IDE, if you have a specific demand like integrating some new tool, or handling some specific filetype, you depend on the producer to build it into the IDE. Just recently IDEs have also learned to use plugins, to allow you build some stuff yourself. Ok, recently was 15-20 years ago, but emacs is 40 years old, predating them all.
I think VSCode is a very mouse-centric experience. Using Emacs I don't touch my mouse. It's a far more efficient and comfortable (less straining) experience, for me anyway. I use both Emacs and VSCode but vastly prefer the Emacs experience. I also use Emacs for much more than simply writing code.
Emacs is also more pleasant to use because it's simply faster. VSCode is slow compared. I'm not talking about application startup time, but just about every operation you do. VSCode stutters and hitches all over the place. Input latency might also be worse, but I don't know, that's just what it feels like. It also lacks many of Emacs' powerful features like helm swooping, which is of course customized just the way I like it. VSCode's "search in all files" just doesn't cut it. And symbol fuzzy search is just for symbols, not all text. Code navigation in Emacs is lightning fast, with the right setup. My Emacs config makes a distribution tailored for me.
A great advantage Emacs used to have over other IDEs and some editors was that you would use it for all/any language. Now with editors like VSCode, which has great support for many languages, it has lost this advantage.
Emacs is also more pleasant to use because it's simply faster. VSCode is slow compared. I'm not talking about application startup time, but just about every operation you do. VSCode stutters and hitches all over the place. Input latency might also be worse, but I don't know, that's just what it feels like. It also lacks many of Emacs' powerful features like helm swooping, which is of course customized just the way I like it. VSCode's "search in all files" just doesn't cut it. And symbol fuzzy search is just for symbols, not all text. Code navigation in Emacs is lightning fast, with the right setup. My Emacs config makes a distribution tailored for me.
A great advantage Emacs used to have over other IDEs and some editors was that you would use it for all/any language. Now with editors like VSCode, which has great support for many languages, it has lost this advantage.
Although the mouse centric experience thing makes sense when _writing_ code, I don't think it makes as much sense for reading/refactoring code. I'm not an Emacs user, but watching some of my colleagues navigating a codebase with Emacs looks not only slow, but also very mentally taxing. They often switch to grep searching, then select the results in order to iterate over them in Emacs. Or they have to remember full paths to files (with autocompletion, but still). Ctrl-shift-f in Vs code looks significantly faster since it displays the results in real time and let's you see the snippet and simply click on the one you want. Also ctrl-p for finding a file quickly by searching for any part of the path. Ctrl-clicking on a method name to jump to its definition. Right click > rename to rename a symbol across files. Or a feature I love in Pycharm, alt-enter to auto import a function--without having to try to remember where it's coming from (it gives a drop-down for multiple definitions). These things speed up flows enough that I think it outweighs the cost of having to remove your hands from the keyboard. And I think reading/refactoring code is as important as writing code in development.
These are exactly the things I find better and faster in Emacs. Watch video below and imagine searching that way but for all files in your project. Results in real-time, instantly taken to content when you highlight and browse results with arrow keys or further narrow down by typing.
https://www.youtube.com/watch?v=RfasCCuCEgM
IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.
https://www.youtube.com/watch?v=RfasCCuCEgM
IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.
Oh nice! That's pretty similar to the VS Code's search experience; I didn't know emacs had that built in! I have a colleague who uses emacs and he always uses grep for stuff like this and it makes my eyes bleed :P
Never used emacs, so can't compare. But:
> I think VSCode is a very mouse-centric experience
I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen"
> VSCode is slow compared
Yeah, probably true. Never felt like it slowed me down though
> And symbol fuzzy search is just for symbols, not all text
cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).
> I think VSCode is a very mouse-centric experience
I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen"
> VSCode is slow compared
Yeah, probably true. Never felt like it slowed me down though
> And symbol fuzzy search is just for symbols, not all text
cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).
> cmd-t on vscode.
Like I said earlier, that's just for symbols, so no, it's not the same.
Like I said earlier, that's just for symbols, so no, it's not the same.
So, I write a niche language server along with an adapter for VS Code. What are you frequently jumping to that isn't a symbol?
I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references.
The only thing that wouldn't work is trying to jump to syntax, but why would you do that?
I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references.
The only thing that wouldn't work is trying to jump to syntax, but why would you do that?
I was going to say pong. Or fireplace. Or maybe the same experience on macos or linux or editing files on an embedded router remotely with tramp.
But really the customization is the use case.
just some examples:
I have written a few specialized diff functions. diff two directories, diff 20 files, diff what I have vs checked in. many different comment-out-a-region functions. remote compile. local compile, but build this part of a project or build it this way. every language I code in has customizations, for indent, for tabs, for colors, several "insert a debug printf".
They are all silly and redundant of no consequence. I frequently rewrite them or throw them away depending on the project I'm working on.
they are meta-silly even: f2 will rotate through editing my 3 startup files.
However - when the time gets tight and I have to do something on a schedule, I'm not grinding through some other person's decision of what is best, I'm just doing it. I also get better at it with time.
But really the customization is the use case.
just some examples:
I have written a few specialized diff functions. diff two directories, diff 20 files, diff what I have vs checked in. many different comment-out-a-region functions. remote compile. local compile, but build this part of a project or build it this way. every language I code in has customizations, for indent, for tabs, for colors, several "insert a debug printf".
They are all silly and redundant of no consequence. I frequently rewrite them or throw them away depending on the project I'm working on.
they are meta-silly even: f2 will rotate through editing my 3 startup files.
However - when the time gets tight and I have to do something on a schedule, I'm not grinding through some other person's decision of what is best, I'm just doing it. I also get better at it with time.
I just wrote a small function to convert Unix epoch timestamps to date-time strings. Just to be able to make sense of timestamps in some log files I was looking at.
I find this kind repetitive thing frequently comes up in the course of one's work. Not a big deal to copy and paste in a web site to convert the first few (or few hundred) times, or firing up the python interpreter. But once it becomes apparent that I will have to do this again and again it is great that Emacs gives me a way to add that small function to it.
I find this kind repetitive thing frequently comes up in the course of one's work. Not a big deal to copy and paste in a web site to convert the first few (or few hundred) times, or firing up the python interpreter. But once it becomes apparent that I will have to do this again and again it is great that Emacs gives me a way to add that small function to it.
I use an IDE for java development because the refactoring is just too useful. But Emacs macros are very useful and I haven’t found something like this in my IDE.
I wonder whether it’s possible to set up lsp-mode for my Java project.
I wonder whether it’s possible to set up lsp-mode for my Java project.
[deleted](1)
I’m not a programmer, just a tradesman who’s worn a few different hats over the eons, but I’ve noticed something as I’ve gotten older and lazier:
I am equally as unproductive regardless of my setup.
My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.
I am equally as unproductive regardless of my setup.
My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.
In order to be more productive of 10s of thousands of hours one only needs to be slightly more productive to justify spending a handful of hours. 1% per 10k hours is worth 100 hours.
Yeah, to some extent, maybe.
I appreciate what you’re saying, and I do hate being slowed down in the moment.
I’ve got a handcrafted AutoHotKey script and a 22 button gaming mouse fine tuned for 2D CAD / CAM software at work, so while I am definitely in to this sort of customisation...
If I’m honest with myself I don’t really get more work done because I end up using the time being unproductive elsewhere.
There’s definitely a certain intellectual curiosity-satisfaction to be had from customisation.
I’m just not convinced it’s a net time saver in the long run?
I appreciate what you’re saying, and I do hate being slowed down in the moment.
I’ve got a handcrafted AutoHotKey script and a 22 button gaming mouse fine tuned for 2D CAD / CAM software at work, so while I am definitely in to this sort of customisation...
If I’m honest with myself I don’t really get more work done because I end up using the time being unproductive elsewhere.
There’s definitely a certain intellectual curiosity-satisfaction to be had from customisation.
I’m just not convinced it’s a net time saver in the long run?
> because I end up using the time being unproductive elsewhere.
Isn't that literally the point? If you can do your task in 10% less time, and then end up spending that 10% procrastinating on HN, then you still win - the task gets done, and you also get to sneak in something nice. And if you find you'd rather spend that time on something else, or doing more work to finish everything faster, you can choose to do so. Optimizing work gives you choice what to do with the time saved; the default may be that you waste it, but now you have options.
Isn't that literally the point? If you can do your task in 10% less time, and then end up spending that 10% procrastinating on HN, then you still win - the task gets done, and you also get to sneak in something nice. And if you find you'd rather spend that time on something else, or doing more work to finish everything faster, you can choose to do so. Optimizing work gives you choice what to do with the time saved; the default may be that you waste it, but now you have options.
> Isn't that literally the point?
Ah, yep, you might have a point there!
Dunno how I missed that. Seems obvious now.
Ah, yep, you might have a point there!
Dunno how I missed that. Seems obvious now.
> a certain intellectual curiosity-satisfaction
User interface design (UID) and user experience (UX) are interesting topics.
Have you ever conducted an oil change at your car or some other minor mechanical task? Wasn't it fun for a moment (at least that one time)?
Machines are interesting.
User interface design (UID) and user experience (UX) are interesting topics.
Have you ever conducted an oil change at your car or some other minor mechanical task? Wasn't it fun for a moment (at least that one time)?
Machines are interesting.
[deleted]
I think most emacs user are overestimating the gain they are having by mastering art of emacs. Sure, it sounds useful to copy every 5th character in all lines that fits a certain regular expression but how many times you actually need it on your active development time and how much time you lose by doing that manually or using more traditional tools?
The coding is mostly typing and debugging. Visual studio (most ides really) is good enough at that. And to be honest emacs/vim complicates the typing part.
The coding is mostly typing and debugging. Visual studio (most ides really) is good enough at that. And to be honest emacs/vim complicates the typing part.
> Visual studio (most ides really) is good enough at that.
No. It's not.
Emacs's electric-indent is so close to the Right Thing when you're coding it's incredible -- getting almost perfectly formatted code as you type. Other editors have autoindent, but it never seems to do the right thing. Other editors also see fit to insert closing brackets/parens/quotes, and then miss detecting when I typed the closing punctuation so now I have three brackets/parens/quotes. It throws me off. Just highlight the opening punctuation mark when I close it, the way Emacs (and vim) does.
I've given Visual Studio Code a chance. Lots of chances really. Each time I find myself struggling with it more than I should, and needing that Emacs flexibility much more than I anticipated going in. Initially I feel more productive, but the more I worked with it the more it gets in the way, inducing friction and slowing me down. And then I want Emacs back.
No. It's not.
Emacs's electric-indent is so close to the Right Thing when you're coding it's incredible -- getting almost perfectly formatted code as you type. Other editors have autoindent, but it never seems to do the right thing. Other editors also see fit to insert closing brackets/parens/quotes, and then miss detecting when I typed the closing punctuation so now I have three brackets/parens/quotes. It throws me off. Just highlight the opening punctuation mark when I close it, the way Emacs (and vim) does.
I've given Visual Studio Code a chance. Lots of chances really. Each time I find myself struggling with it more than I should, and needing that Emacs flexibility much more than I anticipated going in. Initially I feel more productive, but the more I worked with it the more it gets in the way, inducing friction and slowing me down. And then I want Emacs back.
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job.
In most jobs I worked for, taking files home from employer computers would be stealing from security point of view no matter what their contents are.
So it means that one has to create those configurations from scratch every single time in each new job.
In most jobs I worked for, taking files home from employer computers would be stealing from security point of view no matter what their contents are.
So it means that one has to create those configurations from scratch every single time in each new job.
It depends on the job. Certainly you can't add any company-specific tools to your overall init file.
However, most of the stuff I do isn't that specific so I have all my customisations in a git repo that I pull from github to whatever machine I'm working on.
However, most of the stuff I do isn't that specific so I have all my customisations in a git repo that I pull from github to whatever machine I'm working on.
>This view is obviously biased against Emacs,..
Yeah, no bias in your comment. This is the kind of gatekeeping that is keeping Emacs from being popular. All of what you said works great in a "blog" and social media to get upvotes and +1s, but not in real world.
> Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason.
This is not only insulting but ignorant. Have you looked at how extensible VSCode is and how most of the users are using it before you made your comment? Just because it is great outside the box, does not mean it is not extensible or the users cannot "tune their workflow".
Yeah, no bias in your comment. This is the kind of gatekeeping that is keeping Emacs from being popular. All of what you said works great in a "blog" and social media to get upvotes and +1s, but not in real world.
> Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason.
This is not only insulting but ignorant. Have you looked at how extensible VSCode is and how most of the users are using it before you made your comment? Just because it is great outside the box, does not mean it is not extensible or the users cannot "tune their workflow".
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job.
I'm using emacs for 15 years, and it doesn't work for me. When I noticed things I'm doing often, I already have a habit of doing these things by this way. So if I wrote an elisp-function to automate things, I wouldn't use it, because my unique way doesn't include this function.
I'm trying to find a courage to migrate from emacs to some other IDE, where everything already configured, where I could create new habits relying on automation. You know, like use syntax-aware indexing software instead of "<f9> find . -name *.[ch] -exec grep -Hn something {} \; <enter>". I tried etags, but it doesn't work often enough. So my unique way is to simplify workflow and start with find/grep solution, which works in 100% of cases.
emacs is a subject of "lisp curse"[1]: it is too configurable for people to make it usable. People just hack around to make it work for them, and no one tries to make reasonable defaults, because when you set up text editor and ready to make reasonable defaults your editor already is configured and you personally doesn't need no defaults.
[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
I'm using emacs for 15 years, and it doesn't work for me. When I noticed things I'm doing often, I already have a habit of doing these things by this way. So if I wrote an elisp-function to automate things, I wouldn't use it, because my unique way doesn't include this function.
I'm trying to find a courage to migrate from emacs to some other IDE, where everything already configured, where I could create new habits relying on automation. You know, like use syntax-aware indexing software instead of "<f9> find . -name *.[ch] -exec grep -Hn something {} \; <enter>". I tried etags, but it doesn't work often enough. So my unique way is to simplify workflow and start with find/grep solution, which works in 100% of cases.
emacs is a subject of "lisp curse"[1]: it is too configurable for people to make it usable. People just hack around to make it work for them, and no one tries to make reasonable defaults, because when you set up text editor and ready to make reasonable defaults your editor already is configured and you personally doesn't need no defaults.
[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
That, and while emacs has a reputation as being the ur-editor from which all text editing innovation stems, the reality is quite the opposite. It's stagnant and hasn't been the center of text editing innovation for at least the last decade, and probably quite a bit longer before that.
It was a particularly bad string of basic package incompatibilities that woke me from my emacs evangelist phase, but it was the realization that emacs was downstream from TextMate on several non-GUI-centric features that made me realize the entire "platform" value prop was bunk. While emacs might be excused for missing tectonic shifts (e.g. away from CLI and towards GUI), entirely text-centric features like multiple arbitrary simultaneous caret, Smith Waterman quick file/action search, powerful template substitution, parsing-based syntax highlighting, navigation, and refactor tools all developed and matured outside of emacs and then slowly and painfully found their way back in, not the other way around.
Emacs was supposed to be a fertile platform for text editing innovation, but history didn't work out that way, even if you ignore the trend towards GUI innovation, which you shouldn't.
It was a particularly bad string of basic package incompatibilities that woke me from my emacs evangelist phase, but it was the realization that emacs was downstream from TextMate on several non-GUI-centric features that made me realize the entire "platform" value prop was bunk. While emacs might be excused for missing tectonic shifts (e.g. away from CLI and towards GUI), entirely text-centric features like multiple arbitrary simultaneous caret, Smith Waterman quick file/action search, powerful template substitution, parsing-based syntax highlighting, navigation, and refactor tools all developed and matured outside of emacs and then slowly and painfully found their way back in, not the other way around.
Emacs was supposed to be a fertile platform for text editing innovation, but history didn't work out that way, even if you ignore the trend towards GUI innovation, which you shouldn't.
Emacs is a gui app. You can have if you like a tool bar. A menu-bar, tabs, split windows.
If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames.
Personally I use it to render HTML mail inside emacs with what amounts to embedded chrome.
If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames.
Personally I use it to render HTML mail inside emacs with what amounts to embedded chrome.
Emacs is as much of an GUI-App as Window notepad is an editor. They both have the traits what justify to call them, but also are both on the absolute bottom-line in terms of ability.
The menubar is stuck in the 90s, the toolbar very very basic, even for the 90s. Window-Splitting is not even an GUI-feature and very basic. Only the tabs are somewhat modern, but also simple. COmpared to a modern GUI, emacs has barely anything that justify calling it GUI. Especially as most of those features are available in the terminal-version too AFAIK.
> If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames.
Calling external apps doesn't make it a better GUI. And amount of connection between emacs and Qt is very limited. This is just a crutch to fill missing areas in emacs abilities.
The menubar is stuck in the 90s, the toolbar very very basic, even for the 90s. Window-Splitting is not even an GUI-feature and very basic. Only the tabs are somewhat modern, but also simple. COmpared to a modern GUI, emacs has barely anything that justify calling it GUI. Especially as most of those features are available in the terminal-version too AFAIK.
> If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames.
Calling external apps doesn't make it a better GUI. And amount of connection between emacs and Qt is very limited. This is just a crutch to fill missing areas in emacs abilities.
> The menubar is stuck in the 90s, the toolbar very very basic, even for the 90s. Window-Splitting is not even an GUI-feature and very basic. Only the tabs are somewhat modern, but also simple
You're confusing GUI with Windows GUI API. That's like complaining that a game like Stellaris barely has any GUI, because if you force it to run in windowed mode, then maybe you'll get a context menu dropping down from the application icon in the top left corner of the window.
Emacs absolutely has a GUI. It happens to be drawn almost entirely from characters, but it's a GUI. It uses the language, can display pixel graphics (in GUI-app mode), and even supports pointer devices. The fact that 99% of that GUI is a TUI is actually a benefit (you can also use it from terminal). And with third-party plugins, it has all the sophisticated GUI controls you could dream of, except unlike in traditional GUIs, they're fully interoperable.
A good comparison may be that Emacs is the OS that ships with a tiling WM, and most people unaware of that just use it to tile notepad windows.
You're confusing GUI with Windows GUI API. That's like complaining that a game like Stellaris barely has any GUI, because if you force it to run in windowed mode, then maybe you'll get a context menu dropping down from the application icon in the top left corner of the window.
Emacs absolutely has a GUI. It happens to be drawn almost entirely from characters, but it's a GUI. It uses the language, can display pixel graphics (in GUI-app mode), and even supports pointer devices. The fact that 99% of that GUI is a TUI is actually a benefit (you can also use it from terminal). And with third-party plugins, it has all the sophisticated GUI controls you could dream of, except unlike in traditional GUIs, they're fully interoperable.
A good comparison may be that Emacs is the OS that ships with a tiling WM, and most people unaware of that just use it to tile notepad windows.
> Emacs absolutely has a GUI. It happens to be drawn almost entirely from characters,
That's a TUI, not a GUI. GUI means Graphic, not text, even if it's spatial.
> And with third-party plugins, it has all the sophisticated GUI controls you could dream of
No, it has not. I've tried enough of them to know how poor they work.
That's a TUI, not a GUI. GUI means Graphic, not text, even if it's spatial.
> And with third-party plugins, it has all the sophisticated GUI controls you could dream of
No, it has not. I've tried enough of them to know how poor they work.
Windows splitting is actually quite sophisticated you can split horizontally or vertically and split successive sections of the screen. You can balance windows in one dimension or by area. You can do this automatically as you create or destroy windows if you like.
You can have new splits inherit the file you are already editing or show a blank buffer. Further closing a split doesn't kill the buffer or make you decide at that point whether to save a buffer it just destroys the view not the thing.
Native tabs interact with splits in one of two ways. Either as an array of window arrangements at top of window or an array of buffers within a particular split.
You can manually resize a split with the mouse and in fact you can create them via the file menu which also shows the key binding to activate the functionality beside the option ensuring that the 2nd through 10 millionth time you need the functionality you can just press a few buttons.
It's not opening external apps like clicking a link in your email and having your regular web browser open the url its creating a pyqt app within the space of your emacs/tab/split that you can interact with via elisp
https://github.com/manateelazycat/emacs-application-framewor...
You can have new splits inherit the file you are already editing or show a blank buffer. Further closing a split doesn't kill the buffer or make you decide at that point whether to save a buffer it just destroys the view not the thing.
Native tabs interact with splits in one of two ways. Either as an array of window arrangements at top of window or an array of buffers within a particular split.
You can manually resize a split with the mouse and in fact you can create them via the file menu which also shows the key binding to activate the functionality beside the option ensuring that the 2nd through 10 millionth time you need the functionality you can just press a few buttons.
It's not opening external apps like clicking a link in your email and having your regular web browser open the url its creating a pyqt app within the space of your emacs/tab/split that you can interact with via elisp
https://github.com/manateelazycat/emacs-application-framewor...
As far as I am aware it still isn't as GUI oriented as ZWEI used to be.
What gui elements do you find lacking I'm not familiar with ZWEI
Basically think of using Emacs like a Jupyter Netbook, including the visualizations.
Back when I was still into Emacs (2004) this wasn't possible.
Back when I was still into Emacs (2004) this wasn't possible.
That's possible now, you can render images inside buffers.
Render images alone is too basic, that was already possible in XEmacs.
I really meant like Jupyter Notebooks, interactive images and data structures, that you can click on and change to your pleasure and plug into Elisp code to be called back.
I really meant like Jupyter Notebooks, interactive images and data structures, that you can click on and change to your pleasure and plug into Elisp code to be called back.
Org-babel does this, and is less limited in language choice than Jupyter; you can use any language for which a binding exists (there are many, including Python) in any code block, irrespective of what you use in any other. The interfaces are pretty clean, and you can have inline images, although I think not interactive ones. Data structures are expressible in code or in tables.
I don't use it much these days, having less need for that sort of highly interactive exploratory analysis, but I did find Jupyter highly limiting by comparison.
I don't use it much these days, having less need for that sort of highly interactive exploratory analysis, but I did find Jupyter highly limiting by comparison.
Thanks, I will have a look into it, if anything at least not to spread misinformation.
You can integrate jupyter notebooks into emacs so in particular everything "like jupyter" and more.
That is not the same as it doesn't work with Elisp, and hardly brings any value from Emacs itself.
Oh I see. Ya fair. Though honestly even in Jupyter notebooks I don't often see many people making use of anything more then static renders.
Completely agree. There hasn't been any innovation from Emacs since the 90s. Instead more and more effort has gone into adding useless capabilities into emacs such as mail/news readers, organization systems and even window managers. There's some truth to the statement that "Emacs is an operating system lacking a decent text editor" except that even as an operating system it sucks.
Have you tried spacemacs?
> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone.
The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment.
I can't speak for VS Code, as I've only ever played with it a couple of times, but can I do the same thing there? I don't want to spend hours finding and installing packages to recreate my dev environment, or play with various GUI settings to recreate my preferred theme. With Emacs, I can `package-install-selected-packages` on a new build, and I'm using an exact clone of my usual config.
The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment.
I can't speak for VS Code, as I've only ever played with it a couple of times, but can I do the same thing there? I don't want to spend hours finding and installing packages to recreate my dev environment, or play with various GUI settings to recreate my preferred theme. With Emacs, I can `package-install-selected-packages` on a new build, and I'm using an exact clone of my usual config.
There is an integrated settings/extensions sync feature (not yet available on the main release, probably next month). [1]
Or there is a popular extension that does exactly the same thing. [2]
Or you can also do it manually, import/export your settings in JSON and generate a list of `code --install-extension x` that you run on your other machines. [3]
[1] https://code.visualstudio.com/docs/editor/settings-sync
[2] https://marketplace.visualstudio.com/items?itemName=Shan.cod...
[3] https://stackoverflow.com/a/49398449/652669
Or there is a popular extension that does exactly the same thing. [2]
Or you can also do it manually, import/export your settings in JSON and generate a list of `code --install-extension x` that you run on your other machines. [3]
[1] https://code.visualstudio.com/docs/editor/settings-sync
[2] https://marketplace.visualstudio.com/items?itemName=Shan.cod...
[3] https://stackoverflow.com/a/49398449/652669
> The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment.
I just want to pull this particular sentence out for emphasis in case anyone is reading the "New employee 2 workflow at company X" comment and thinking that it's even the least bit true.
I just want to pull this particular sentence out for emphasis in case anyone is reading the "New employee 2 workflow at company X" comment and thinking that it's even the least bit true.
For me it is
home-manager switch
Nix support for VS Code is pretty painful. Only a tiny subset of extensions are listed in nixpkgs, and those are often broken (e.g. Python) when old binary versions are pulled from the CDN.
If somebody could make a VS code extension that seamlessly pulls down other extensions by altering the nix config, it'd be perfect.
If somebody could make a VS code extension that seamlessly pulls down other extensions by altering the nix config, it'd be perfect.
Thanks for the information! I haven't tried configuring VS Code through Nix yet. I guess I'll wait a while before doing another attempt.
I've never needed more than 2-3 VSCode packages for a given workflow. They're usually easy to find and at the top of the list when I search for a language. Settings live in a settings.json file in your home directory and/or workspace (the latter is so that shared settings can be committed to version-control). You can have both and they get merged, with the project settings overriding user-level settings.
I'm not familiar with emacs. Does that mean that you don't need to install any supporting software like indexers, linters, syntax highlighters, etc? Does the emacs file contain all that or tell it how to download all the plugins?
If you could just copy one file and get all that, that's pretty cool.
If you could just copy one file and get all that, that's pretty cool.
No. It doesn’t. You still need to install and configure plenty of 3rd party packages and tools that are completely outside of emacs. For C++, things like cscope, ctags (or maybe etags or gtags), clang autocomplete tooling, etc.
These, their dependencies and layouts, typically change from machine to machine, OS to OS, distribution to distribution and version to version. So placing it in your emacs config isn’t really portable.
These, their dependencies and layouts, typically change from machine to machine, OS to OS, distribution to distribution and version to version. So placing it in your emacs config isn’t really portable.
Same for vscode? ex: if you want eslint, you install it from npm.
My experience with VS code has been a couple clicks for C++, Python (2 & 3), and a smattering of other languages and configuration files (YAML, cmake, etc.) on a fairly large (~1MLoC) enterprise code base.
Another click for remote editing over ssh.
No pain and most importantly no constant tinkering.
VS Code started very humbly a few years back and was useless to me because it only supported JavaScript and a couple other things with no plugins to speak of. It has since grown into a seriously powerful tool.
Another click for remote editing over ssh.
No pain and most importantly no constant tinkering.
VS Code started very humbly a few years back and was useless to me because it only supported JavaScript and a couple other things with no plugins to speak of. It has since grown into a seriously powerful tool.
The 'one file' installs the other tools for you. At least mine does. I move between machines regularly, and when I do I just install emacs according to the recommended method for the particular OS and copy my init.el file to the new machine. All the packages I depend on are installed the first time I run emacs. And my init.el would be considered pretty basic by the standards of an advanced user.
You install something like spacemacs or doom emacs for vs code parity. And then it lazy loads packages based on the file type.
You enable features in config by uncommenting, and it auto installs.
You enable features in config by uncommenting, and it auto installs.
The "Emacs file" can contain that yes. Since .emacs is written in Lisp (Emacs Lisp) you can basically tell it to do anything om start up.
I am not a passionate Emacs user and I strongly dislike the weird bugs that rear their heads sometimes. I was always a vim user, but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation. I would even go as far as saying that Evil is vi implemented in Emacs Lisp.
I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi.
Would like to switch otherwise, but non-leaky vi support and good latency are essentials.
Edit, forgot to add: something as good and keyboard-driven as magit.
I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi.
Would like to switch otherwise, but non-leaky vi support and good latency are essentials.
Edit, forgot to add: something as good and keyboard-driven as magit.
> but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation
I switched to emacs for similar reasons (plus the fact that it supported embedded repls that actually worked). But eventually switched to neovim, because it could do things like completion and repls. vim 8 can now as well.
> I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi.
> Would like to switch otherwise, but non-leaky vi support and good latency are essentials.
Same. Also start-up time. I love typing `v <filename>` in a terminal and instantly getting an editor. Lower memory usage is also nice.
I switched to emacs for similar reasons (plus the fact that it supported embedded repls that actually worked). But eventually switched to neovim, because it could do things like completion and repls. vim 8 can now as well.
> I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi.
> Would like to switch otherwise, but non-leaky vi support and good latency are essentials.
Same. Also start-up time. I love typing `v <filename>` in a terminal and instantly getting an editor. Lower memory usage is also nice.
How long did it take you to switch? I tried spacemacs for a few months but got tired after I was always accidentally breaking things
Not too long. I also began using Emacs with spacemacs, but it was buggy and slow. Then I just started with a completely pristine Emacs configuration and just added through use-package:
- evil for vi emulation
- general/which-key so I could define spacemacs-like bindings that start with SPC.
- ivy for quick search of buffers, files, etc
Then I added things on a by-need basis. I would say that the most important additions were magit for Git, projectile for quickly switching between project files, and some Rust packages.
This is now my emacs configuration:
https://github.com/danieldk/nix-home/blob/master/cfg/emacs.n...
Rust configuration:
https://github.com/danieldk/nix-home/blob/master/cfg/rust.ni...
(Sorry for posting Nix files, but it's pretty close to what it would look like in a regular init.el.)
- evil for vi emulation
- general/which-key so I could define spacemacs-like bindings that start with SPC.
- ivy for quick search of buffers, files, etc
Then I added things on a by-need basis. I would say that the most important additions were magit for Git, projectile for quickly switching between project files, and some Rust packages.
This is now my emacs configuration:
https://github.com/danieldk/nix-home/blob/master/cfg/emacs.n...
Rust configuration:
https://github.com/danieldk/nix-home/blob/master/cfg/rust.ni...
(Sorry for posting Nix files, but it's pretty close to what it would look like in a regular init.el.)
How does emacs have better support for completion than vim?
Is this language specific? For typescript at least Vim can use the same completion server as VS code (and so can emacs for that matter).
Wouldn't class myself as an experienced Emacs user.
Used it for 5 or so years. Learnt enough to get by and have my own config that works for me. Not got as far as writing my own elsip functions.
When I set up a new computer
1) Check out my emacs config from git 2) Start emacs 3) Wait for emacs to automatically download all the packages declared in my config using use-package.
If you never used Emacs before fair enough it's harder than VS Code. VS Code does let you get going knowing less by clicking buttons. It's the same as comparing any CLI app with a full blown point and click GUI.
My take on getting a new user setup... "use what ever IDE you are comfortable with, I do not care. This is the IDE I use, here is how I have it set up if you want to use it also. Person C uses this IDE instead if you want to use that, ask them for there setup. No one here uses your IDE? You are on your own setting it up but can help with any project specific questions you need to know to get your IDE of choice running".
As far as code searching goes I find myself often outside of any IDE using the silver searcher (ag) so use emacs projectile for the exact same functionality but within emacs. Sometimes the only feature I miss from a full blown IDE like InteliJ is find usages.
Used it for 5 or so years. Learnt enough to get by and have my own config that works for me. Not got as far as writing my own elsip functions.
When I set up a new computer
1) Check out my emacs config from git 2) Start emacs 3) Wait for emacs to automatically download all the packages declared in my config using use-package.
If you never used Emacs before fair enough it's harder than VS Code. VS Code does let you get going knowing less by clicking buttons. It's the same as comparing any CLI app with a full blown point and click GUI.
My take on getting a new user setup... "use what ever IDE you are comfortable with, I do not care. This is the IDE I use, here is how I have it set up if you want to use it also. Person C uses this IDE instead if you want to use that, ask them for there setup. No one here uses your IDE? You are on your own setting it up but can help with any project specific questions you need to know to get your IDE of choice running".
As far as code searching goes I find myself often outside of any IDE using the silver searcher (ag) so use emacs projectile for the exact same functionality but within emacs. Sometimes the only feature I miss from a full blown IDE like InteliJ is find usages.
[deleted]
In the long run (now 20 years) the switch from Microsoft products to Emacs was a giant net win for me. Since I am no longer at the mercy of volatile business, but enjoy stability und functionality at its best.
The initial investment in configuration and learning had enormous dividends. Don think short term.
I would expect an experienced emacs user to have a config already that more or less "works". Was this a junior developer that just decided to start using emacs one day?
I'm not an emacs person myself, but every emacs person I have ever met already has it setup and customized and just brings their config. A new dev starting with emacs on a new job... just sounds like a bad recipe and misunderstood priorities.
I'm not an emacs person myself, but every emacs person I have ever met already has it setup and customized and just brings their config. A new dev starting with emacs on a new job... just sounds like a bad recipe and misunderstood priorities.
> already has it setup and customized and just brings their config
You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file.
I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.
You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file.
I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.
> You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file.
Yes. I've spent 10 years crafting this file I'm using now. One bit at a time, every time I found something which could improve my productivity and editing experience.
And I can now bring that with me anywhere at literally zero cost.
I'm not sure why anyone would frame that as a bad thing?
Yes. I've spent 10 years crafting this file I'm using now. One bit at a time, every time I found something which could improve my productivity and editing experience.
And I can now bring that with me anywhere at literally zero cost.
I'm not sure why anyone would frame that as a bad thing?
You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.
Not really. The most common keybindings of GUI text editing have largely converged, and those that haven't collectively account for similar total complexity to, say, basic file/buffer management and movement in emacs.
Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
While I think you're right on the whole here about "Emacs people," but you did an interesting thing in the first sentence: you contrasted experienced Emacs user with junior developer. And I think that actually points to a problem: people who are experienced developers but not experienced Emacs users are going to be in much the same position as the OP's description.
While I know the basics of Emacs, every time I try to get serious with it and make it my One True Editor, I end up spending days screwing around with packages and configuration files to try to figure out how to have similar functionality to what I get either out of the box or with fairly minimal effort in arguably lesser editors. I'm sure Emacs can do all of what I need and nearly all of what I want, but most of the time I'm damned if I can figure out how to get there from where I'm starting.
If I was really going to try to give advice on how to make Emacs more popular, it'd center around the package/extension system. It's great that it has package repositories and a built-in management system now, and the documentation for the core editor is terrific... but the documentation for packages is wildly variable, and what's worse, packages interact with one another, depend on one another, and/or conflict with one another in ways that are just utterly mystifying to a newbie.
I don't care about making Emacs "pretty," and while it'd be nice if it used less weird terminology by today's standards, I can deal with it. What I want is sane defaults and good guidance. Spacemacs' concept of layers -- where I can just say "I would like you to install and enable all the crap that lets me smartly edit PHP files, please" -- is absolutely onto something, although I would still argue that it might need to offer a little less choice by default. Don't make me choose whether I want Helm or Ivy because I have no idea, and for God's sake, enable sensible layers/packages by default: assume that yes, I do want autocompletion and git integration and such. If you must, let me click a button to choose between "batteries included" and "advanced" configuration. This is stuff that mainline Emacs should be doing.
And, actually, that's one other thing Emacs could stand to do better: learn from VS Code's configuration system that lets you use dropdowns and checkboxes and simple text fields for nearly everything, and has a button to go into the configuration files when you need it. Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over.
As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again. Until then, I'm probably gonna keep doing my technical writing in BBEdit and my coding in Visual Code. (I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.)
While I know the basics of Emacs, every time I try to get serious with it and make it my One True Editor, I end up spending days screwing around with packages and configuration files to try to figure out how to have similar functionality to what I get either out of the box or with fairly minimal effort in arguably lesser editors. I'm sure Emacs can do all of what I need and nearly all of what I want, but most of the time I'm damned if I can figure out how to get there from where I'm starting.
If I was really going to try to give advice on how to make Emacs more popular, it'd center around the package/extension system. It's great that it has package repositories and a built-in management system now, and the documentation for the core editor is terrific... but the documentation for packages is wildly variable, and what's worse, packages interact with one another, depend on one another, and/or conflict with one another in ways that are just utterly mystifying to a newbie.
I don't care about making Emacs "pretty," and while it'd be nice if it used less weird terminology by today's standards, I can deal with it. What I want is sane defaults and good guidance. Spacemacs' concept of layers -- where I can just say "I would like you to install and enable all the crap that lets me smartly edit PHP files, please" -- is absolutely onto something, although I would still argue that it might need to offer a little less choice by default. Don't make me choose whether I want Helm or Ivy because I have no idea, and for God's sake, enable sensible layers/packages by default: assume that yes, I do want autocompletion and git integration and such. If you must, let me click a button to choose between "batteries included" and "advanced" configuration. This is stuff that mainline Emacs should be doing.
And, actually, that's one other thing Emacs could stand to do better: learn from VS Code's configuration system that lets you use dropdowns and checkboxes and simple text fields for nearly everything, and has a button to go into the configuration files when you need it. Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over.
As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again. Until then, I'm probably gonna keep doing my technical writing in BBEdit and my coding in Visual Code. (I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.)
> Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over.
I’ve used GNU Emacs for twenty years and totally agree. I avoid the customization menus wherever I can.
I’ve used GNU Emacs for twenty years and totally agree. I avoid the customization menus wherever I can.
> As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again
You're doing yourself a discervice for not just using Spacemacs develop branch. It's actually more stable than the master branch.
You're doing yourself a discervice for not just using Spacemacs develop branch. It's actually more stable than the master branch.
I use and love Spacemacs, but their branch handling is a major PR fuckup. The last stable version should be phased out now. The develop branch works way better. They should rethink their release model.
True, just think they need to embrace the fast development cadence of develop and just make that master.
Interesting. I switched to the develop branch the other day (yes, just to try to get LSP working!) and ran into some glitch that I didn't have the time to investigate -- a complaint about the .spacemacs file missing a variable or something. I'll probably try again this weekend.
You need to run SPC f e D to do a 3-way merge of your .spacemacs everytime after you upgrade Spacemacs.
As changes to Spacemacs are made, there might need more or less things in the .spacemacs file. So you always need to do a manual merge of the changes.
As changes to Spacemacs are made, there might need more or less things in the .spacemacs file. So you always need to do a manual merge of the changes.
Thanks for the tip. I had no idea that was a thing -- although it absolutely makes sense, thinking about it!
> I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.
Please produce that post. Also, why not developing in BBEdit?
Please produce that post. Also, why not developing in BBEdit?
BBEdit's indenting and completion engines just aren't as smart as other editors -- I suspect in the latter case they'll have to add LSP support on their own (right now I don't think it can even be added externally because their API doesn't expose the right event hooks), and in the former case, I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting. With those objections aside, BBEdit is still pretty good for development.
For the technical writing, I actually wrote a comment here somewhere about that in another post; I'll have to dig it up and turn it into a blog post at some point. But I called it a "fast Swiss army knife for text." Its "open file by name via fuzzy searching" command lets you enter multiple files, its multi-file search window lets you save file filters with meaningful names (and you can save grep patterns the same way, and in BBEdit 13 there's even a "Pattern Playground" that lets you nondestructively test out complex regexes on your current document). Projects get their own persistent scratchpads and Unix worksheets. And, a bit relevant to an Emacs thread, BBEdit has a bit of Emacs-ish keybinding support over and what Mac editors normally do, although it's decidedly not an Emacs emulation layer.
For the technical writing, I actually wrote a comment here somewhere about that in another post; I'll have to dig it up and turn it into a blog post at some point. But I called it a "fast Swiss army knife for text." Its "open file by name via fuzzy searching" command lets you enter multiple files, its multi-file search window lets you save file filters with meaningful names (and you can save grep patterns the same way, and in BBEdit 13 there's even a "Pattern Playground" that lets you nondestructively test out complex regexes on your current document). Projects get their own persistent scratchpads and Unix worksheets. And, a bit relevant to an Emacs thread, BBEdit has a bit of Emacs-ish keybinding support over and what Mac editors normally do, although it's decidedly not an Emacs emulation layer.
> I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting
Yeah, either that or they are procrastinating on some quirk deep in their engine they should rewrite already.
Yeah, either that or they are procrastinating on some quirk deep in their engine they should rewrite already.
Younger self used to Borland and Microsoft IDEs, when going into Xenix, DG/UX and frieds, "where is my IDE?!?".
The TA on my 2nd year university pissed off with everyone of us using Emacs as Notepad, instead of spending one hour talking about Pascal, decided to teach us how to use Emacs properly.
I was one of the few that kept with it, although I ended up moving into XEmacs, which had a much better experience.
The large majority of my fellow students decided to adopt Joe, JED instead.
After university and after a couple of years on the job market eventually all of us moved back into IDE land.
So not sure what Emacs can really do to still cater to younger generations, if even for us it was seen as something to endure on university computer systems, back when options were quite limited.
The TA on my 2nd year university pissed off with everyone of us using Emacs as Notepad, instead of spending one hour talking about Pascal, decided to teach us how to use Emacs properly.
I was one of the few that kept with it, although I ended up moving into XEmacs, which had a much better experience.
The large majority of my fellow students decided to adopt Joe, JED instead.
After university and after a couple of years on the job market eventually all of us moved back into IDE land.
So not sure what Emacs can really do to still cater to younger generations, if even for us it was seen as something to endure on university computer systems, back when options were quite limited.
I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything.
I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it".
If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics.
Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.
I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it".
If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics.
Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.
> I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything.
I will ask this question in my next job interview. This is a red flag for me. I wouldn't want to work in a company that forces the developers onto a specific editor/IDE.
I will ask this question in my next job interview. This is a red flag for me. I wouldn't want to work in a company that forces the developers onto a specific editor/IDE.
These kinds of discussions tend to overlook that using tools that you enjoy using and are familiar with can be a virtue in itself.
I doubt that any of the editors/IDEs under discussion make it impossible to do the work we need to do. And I'm willing to bet that forcing an employee to use a tool they don't enjoy will have a much higher impact on their productivity than any marginal differences in functionality between that tool and their preferred option.
I use vim because I enjoy using it and it is sufficient for the tasks I need to do. The idea that this reason is not enough and I need to justify my choice by proving it is a more productive option than all other editors/ides strikes me as deeply odd.
I doubt that any of the editors/IDEs under discussion make it impossible to do the work we need to do. And I'm willing to bet that forcing an employee to use a tool they don't enjoy will have a much higher impact on their productivity than any marginal differences in functionality between that tool and their preferred option.
I use vim because I enjoy using it and it is sufficient for the tasks I need to do. The idea that this reason is not enough and I need to justify my choice by proving it is a more productive option than all other editors/ides strikes me as deeply odd.
I think the productivity graphs look like:
| 22
| 22
| 1111121111
| 1 22
|1 22
|122
-------------> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone.
The fact that you don't have one for VS Code shows that any modifications to make it better are too difficult and that you just have to make do with how it comes out of the box.
The fact that you don't have one for VS Code shows that any modifications to make it better are too difficult and that you just have to make do with how it comes out of the box.
In reality, it is very easy in vscode. The difference is, that in vscode it is a easily readable json. Much, much! better than in both emacs and vim.
Edit: downvoting doesn't change reality
Edit: downvoting doesn't change reality
In vim, configuration is either through running commands you could run in normal mode in vim, or through vimscript functions. I assume emacs is similar in that regard.
JSON isn't really that easy to read unless it's pretty formatted, and it's somewhat difficult to write (making sure you have every double-quote, every comma, every closing and opening bracket/brace, etc. I always have to run a JSON linter to make sure I didn't miss anything when writing JSON by hand.
JSON isn't really that easy to read unless it's pretty formatted, and it's somewhat difficult to write (making sure you have every double-quote, every comma, every closing and opening bracket/brace, etc. I always have to run a JSON linter to make sure I didn't miss anything when writing JSON by hand.
In Emacs it’s easily readable ELisp. Much, much better than JSON.
Well, more versatile, anyway.
Well, more versatile, anyway.
So which is it: VS Code is maximally unsuited for everyone or the previous argument was nonsense?
Your comment doesn't make sense. What are you trying to say?
ELI5:
- Article: Non-trivial config is bad. Hence emacs is bad but VS is good.
- My post: Not having non-trivial config is bad.
- Your post: VS has non-trivial config and even more/better than emacs.
- My reply: So do you agree with article and now VS is "maximally unsuitable for everyone" (the quote for "bad" from the article)? Or do you disagree with article?
- Article: Non-trivial config is bad. Hence emacs is bad but VS is good.
- My post: Not having non-trivial config is bad.
- Your post: VS has non-trivial config and even more/better than emacs.
- My reply: So do you agree with article and now VS is "maximally unsuitable for everyone" (the quote for "bad" from the article)? Or do you disagree with article?
You didn't read the comments correctly, hence your confused reply.
I use VS Code sparsely but this is what has worked for me https://marketplace.visualstudio.com/items?itemName=Shan.cod...
I don't contest that VSCode has achieved better out of the box functionality than emacs but it still needs a lot of configuration. My experience is only with C++ extension where intellisense update just goes on indefinitely. Navigation to a function takes ages. Then I exclude some source directories and restart VSCode. And not to talk of resource hog that it is. When it works it is pretty good and that's why I stick to it. May be other language extensions are better.
I would say it is the best editor with the resource usage of a full blown IDE.
The experience varies widely by language. TypeScript support is top-notch. Clojure support used to be bad and then got good. Rust support has been bad for a long time but the nascent rust-analyzer project makes it fantastic. Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one. C# support is quite solid. Etc.
Only a couple of languages get first-party support from MS. The rest depend on their respective communities to build extensions. VSCode has a great plugin architecture, but it's entirely possible to write a bad plugin for it, especially if it's simply not a popular enough editor in that community yet. Still, none of the above required dependency-juggling or stepped on each others' toes. Only a couple cases required a configuration step to get them fully working. My worst VSCode setup experiences haven't wasted as much time as the Emacs golden path did.
Only a couple of languages get first-party support from MS. The rest depend on their respective communities to build extensions. VSCode has a great plugin architecture, but it's entirely possible to write a bad plugin for it, especially if it's simply not a popular enough editor in that community yet. Still, none of the above required dependency-juggling or stepped on each others' toes. Only a couple cases required a configuration step to get them fully working. My worst VSCode setup experiences haven't wasted as much time as the Emacs golden path did.
> Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one.
Which one?
Which one?
This one: https://marketplace.visualstudio.com/items?itemName=ms-pyrig...
I only found out about it by asking here on HN
I only found out about it by asking here on HN
I largely agree with this and I wasted a lot of time in school and earlier in my career on these tools because of how often they’re positively talked about in online communities and positively compared to what seem to be otherwise obviously better tools.
In a few years, VS Code has achieved better out of the box functionality for [people who don't already know / don't want to learn emacs].
Emacs has a challenging learning curve. I don't think it's realistic to insist new employees use Emacs that haven't already chosen the path for themselves.
Real scenario (for someone experienced with and asking to use Emacs):
1. Install Emacs
2. Clone config
3. Work
Emacs has a challenging learning curve. I don't think it's realistic to insist new employees use Emacs that haven't already chosen the path for themselves.
Real scenario (for someone experienced with and asking to use Emacs):
1. Install Emacs
2. Clone config
3. Work
> In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years.
That's not as clever as you seem to think it is. Emacs was created for a different world. Of course new tools have an easier time in the world for which they were created and with no legacy baggage.
That's not as clever as you seem to think it is. Emacs was created for a different world. Of course new tools have an easier time in the world for which they were created and with no legacy baggage.
You’re essentially saying that emacs has been stagnant and hasn’t changed with the world around it. Yes, absolutely. That’s why it’s not a surprise it is losing popularity.
Clunkiness and baggage is not a foregone conclusion for software. Software can keep up with a changing world, discarding old baggage along the way. In the end it doesn’t matter. Whether it is old software that adapts and changes or new software that supplants stagnant, clunky software. The world uses whatever is easiest and most relevant and goes on.
Clunkiness and baggage is not a foregone conclusion for software. Software can keep up with a changing world, discarding old baggage along the way. In the end it doesn’t matter. Whether it is old software that adapts and changes or new software that supplants stagnant, clunky software. The world uses whatever is easiest and most relevant and goes on.
Workflow on midsized personal project with editor that I'm comfortable with and have customized over the majority of time I've been programming: work.
Look, obviously VS Code has emacs beat in the vast majority usability features. Emacs works for a lot of what I work on. For the things it doesn't work for, I use the tool that works better.
I have lots of personal qualms with emacs, but to declare it "maximally unsuitable," is overkill.
Look, obviously VS Code has emacs beat in the vast majority usability features. Emacs works for a lot of what I work on. For the things it doesn't work for, I use the tool that works better.
I have lots of personal qualms with emacs, but to declare it "maximally unsuitable," is overkill.
> In a few years, VS Code has achieved better out of the box functionality
How many years will it take until stock vscode stops lagging randomly every 10 key strokes?
How many years will it take until stock vscode stops lagging randomly every 10 key strokes?
laughs in visual studio
Remember that you can open the dev tools and profile VS Code itself. I've debugged a few weird issues that way.
Remember that you can open the dev tools and profile VS Code itself. I've debugged a few weird issues that way.
Hybris & Curiosity => Vim => Emacs => Evil Emacs => Spacemacs => Evil Emacs => Org-mode videos on Youtube => Silent Despair => VS Code + Vim keys (w/o Ctrl*) => Peace of mind.
What are you guys talking about...
1. nano code.txt 2. ??? 3. Profit!
1. nano code.txt 2. ??? 3. Profit!
> this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing
Exactly, the bottleneck is thinking, so why do I need the slick point-and-click tools in an IDE?
Exactly, the bottleneck is thinking, so why do I need the slick point-and-click tools in an IDE?
> and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing.
This is like saying we should just throw out every helpful thing that helps us write code faster/better. On one hand you argue for VSCode's OOTB experience (extensions which are MODES), and on the other hand you're saying modes doesn't matter when it comes to Emacs.
Why not rip out every helpful thing from VSCode, too, then? No refactoring, no completion, because that doesn't save time?
Why even learn to type with more than 1 digit?
This is like saying we should just throw out every helpful thing that helps us write code faster/better. On one hand you argue for VSCode's OOTB experience (extensions which are MODES), and on the other hand you're saying modes doesn't matter when it comes to Emacs.
Why not rip out every helpful thing from VSCode, too, then? No refactoring, no completion, because that doesn't save time?
Why even learn to type with more than 1 digit?
This was kind of my experience with vim. I like vim's UI but I work on multiple languages so I need a bunch of plugins and tweaks. I finally gave up on it after a plugin update broke it one too many times and I didn't have the heart to debug the wall of errors it barfed up on startup.
I switched to Sublime Text with the Vintage plugin (vim keybindings). Package Control is just so painless to use, and in a few years of use I have to yet to have a plugin break anything.
I switched to Sublime Text with the Vintage plugin (vim keybindings). Package Control is just so painless to use, and in a few years of use I have to yet to have a plugin break anything.
This is being replaced by:
1. New employee is added to cloud access management. 2. New employe logs into AWS Code, Apache CHE or Githubs new web editor. 3. ??? 4. Beer.
1. New employee is added to cloud access management. 2. New employe logs into AWS Code, Apache CHE or Githubs new web editor. 3. ??? 4. Beer.
VS Code has its pros and I use it daily, but I have to spend quite a bit of time configuring a fresh install of it. Probably not as much as I would Emacs, had I used it, but it's not insignificant. And that includes changing the theme.
There's a sync extension. I think it's making it into the core functionalities.
Good news!
I use emacs, and I do not have much problem with configs. I mostly work vanilla, and all the configs I needed were done when I was starting out with emacs.
Now emacs is ubiquitous to me and the last time I visited my init file was last year actually!
Now emacs is ubiquitous to me and the last time I visited my init file was last year actually!
Or even better
New employee workflow at company Z
1. Install the Jetbtains toolbox
2. Have IDEs for several languages with consistent features and semantics.
3. Minimal to no configuration needed
4. Profit.
New employee workflow at company Z
1. Install the Jetbtains toolbox
2. Have IDEs for several languages with consistent features and semantics.
3. Minimal to no configuration needed
4. Profit.
I can use 40% more cores when compiling than my CLion using colleagues because vim doesn't need 10GB of RAM. I tried using CLion, but it was just too slow. Maybe I was holding it wrong.
Off-course, if majority of your time is spent compiling gigantic C++ codebases, more power to you for using VIM. CPU load in code compilation hasn't been the bottleneck I ever faced and I think this applies to most folks. Plus CLion doesn't just arbitrarily start consuming CPU, if it is not doing indexing(and VIM simply can't do the kind of indexing that CLion does), it doesn't consume much CPU. In the idle state, it consumes very little CPU.
Then again, some seconds of CPU might be a good tradeoff against productivity in some scenarios.
Then again, some seconds of CPU might be a good tradeoff against productivity in some scenarios.
I don't spend the majority of my time compiling (a decent chunk though!), but then again, I also don't spend a large part of my time doing the complex refactorings that an IDE would make much easier. I don't think either vim or clion has dramatic advantages over the other.
The last time I used a Jetbrains product, it took several seconds to simply open the IDEs Settings page. I'm not kidding, several seconds. Sometimes it would also completely freeze up for seconds when Java's GC kicked in. Great experience...
My progression in editors was something like Sublime -> GVim -> Spacemacs -> VSCode -> Jetbrains.
After all those years, there are 2 main takeaways for me.
1. I love modal editing, not necessarily Vim
2. My time is better spent doing actual work or enjoying my hobbies than fiddling around with configurations.
After all those years, there are 2 main takeaways for me.
1. I love modal editing, not necessarily Vim
2. My time is better spent doing actual work or enjoying my hobbies than fiddling around with configurations.
Lol, tell that to my coworkers who take days trying to fix some problem with their Pycharm, while I just keep coding on my trusty Emacs.
What is the problem that take days to fix with Pycharm. Just curious. I have been using Jetbrains products for 5-6 years now, and have never faced a problem which took days to fix. Sure, there were some bugs here and there, but no showstoppers, and all were already filed in their bug tracker before I could file them.
Also, Pycharm does far more than even a heavily customized .emacs can do (I used to have one very custom emacs setup). There is simply no comparison feature wise. Not to mention, things that emacs can do, Pycharm should be doing in even a very problematic bug ridden state.
Also, Pycharm does far more than even a heavily customized .emacs can do (I used to have one very custom emacs setup). There is simply no comparison feature wise. Not to mention, things that emacs can do, Pycharm should be doing in even a very problematic bug ridden state.
In what sad, warped alternative reality did this happen?
Trying vscode even in comparison to eclipse made me want to kill myself especially when everyone was saying how great it was.
Did exactly what you're describing here. 4 hours of fucking about to achieve nothing.
Did exactly what you're describing here. 4 hours of fucking about to achieve nothing.
This is exactly what the IDE people say about VSCode
I actually like this viewpoint because I have done both and generally I disagree with you. But here's my take.
I use VSCode often because its "just easier". The extensions are at best (in my opinion) ok approximations to what I can get with emacs. Especially for a language I'm inexperienced with in emacs VSCode is a nice integration layer while I adjust my configuration.
Emacs (and to that point vim) is vastly superior to any offering VSCode has. The problem is you have to be productive. Many nights I labored over my emacs configuration to tailor to my job. I've done this for the last 10 years. It takes effort. To that, you have a point. VSCode is effortless. On that, VScode doesnt feel like anything to me except a bridge layer. Emacs and vim offer a vastly better experience (without the git politics!) if you're willing to spend the time customizing it. But that is the difference - are you willing to spend the time? Many developers are not and that's fine. But for a marginal additional investment you can have something better.
Something to think about at least. I can install my Emacs configuration in 30 seconds from my github.
I use VSCode often because its "just easier". The extensions are at best (in my opinion) ok approximations to what I can get with emacs. Especially for a language I'm inexperienced with in emacs VSCode is a nice integration layer while I adjust my configuration.
Emacs (and to that point vim) is vastly superior to any offering VSCode has. The problem is you have to be productive. Many nights I labored over my emacs configuration to tailor to my job. I've done this for the last 10 years. It takes effort. To that, you have a point. VSCode is effortless. On that, VScode doesnt feel like anything to me except a bridge layer. Emacs and vim offer a vastly better experience (without the git politics!) if you're willing to spend the time customizing it. But that is the difference - are you willing to spend the time? Many developers are not and that's fine. But for a marginal additional investment you can have something better.
Something to think about at least. I can install my Emacs configuration in 30 seconds from my github.
Everywhere in this thread I see vague and generic statements like this. Do you have concrete examples of specific things in your 10 year old Emacs configuration you "labored over" that can do something VSCode (and its extensions) can't and which makes Emacs "vastly superior"? If so please share, otherwise don't bother. We have already heard all this vague nonsense for years.
There are loads of examples in the comments here. Have you read them?
I use vi.
Never had to install anything across thousands of servers.
Never had to install anything across thousands of servers.
That's true, but I'd rather use tramp-mode and keep my setup instead of
sacrificing it for the sake of consistency across servers.
It won't really be consistent anyways, you'll get some plugins here and
there I guess.
Better yet, install vscode, then install either the vim or emacs plugin. The best of all worlds!
Eh. Sort of. Like the other person who replied about the Emacs plugin, I find myself running into issues with the Vim plugin -- usually not the keybindings as much as the ex-style commands. For instance, ":20,27m." will move a block of text in Vi/Vim to under the current location; that doesn't work in VSCode Vim. Worse for me personally, I've gotten really used to the ":find" command being the (rough) equivalent of a fuzzy file search: ":find App.php" will find that file no matter where it is in the current project, but again, not a VSCode Vim command.
It's a good emulation, but it's not a great emulation.
It's a good emulation, but it's not a great emulation.
Ctrl+p will let you search nicely for files in vscode. At least the VI integration is better than the extension I use with Visual Studio.
Oh, yeah, I do use that (well, Cmd-P over here in Mac-world). It's just when I get into Vim mode I type ":find" reflexively and I get disappointed for a moment. :)
(Ironically, there's a Vim plugin called CtrlP to do the same thing that I never use because I find it confusing and weird compared to everybody else's implementation of the same idea...)
(Ironically, there's a Vim plugin called CtrlP to do the same thing that I never use because I find it confusing and weird compared to everybody else's implementation of the same idea...)
Kind of. I haven't found a VSCode emacs package that does more than superficially handle emacs keybindings; there's always mismatches that trip me up.
Does it need to be popular or need more users to become maintainers?
I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
If I had a horse in the race I'd focus on the developer experience. Make it easier to extend, make the runtime faster (the native compilation stuff is super cool), better unicode support, alternate input methods, etc. If people want to use it for publishing it should be easy to write a package to cater to those users.
For me, a long time emacs user, I think the biggest concern I have is ensuring that the project is sustained by new developers.
I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
If I had a horse in the race I'd focus on the developer experience. Make it easier to extend, make the runtime faster (the native compilation stuff is super cool), better unicode support, alternate input methods, etc. If people want to use it for publishing it should be easy to write a package to cater to those users.
For me, a long time emacs user, I think the biggest concern I have is ensuring that the project is sustained by new developers.
Developer experience is more than just technical too. I know some package authors (and myself personally) find themselves very disillusioned with the GNU approach to contribution, especially regarding licensing and copyright assignment.
> very disillusioned with the GNU approach to contribution, especially regarding licensing and copyright assignment.
TBF, given the historical FUD baggage, I don't fault them for trying to play extra safe as stewards of the project. Also, Emacs makes it so easy to get packages out-of-band (eg: MELPA, Borg, Straight, Quelpa) that I don't think the copyright assignment is a big deal unless one wants to get code merged into base Emacs.
TBF, given the historical FUD baggage, I don't fault them for trying to play extra safe as stewards of the project. Also, Emacs makes it so easy to get packages out-of-band (eg: MELPA, Borg, Straight, Quelpa) that I don't think the copyright assignment is a big deal unless one wants to get code merged into base Emacs.
Re copyright, what would you prefer? Alternatively, what would you even do with the copyright to your fixes and additions to GNU emacs?
I submitted a miniscule patch to tcl-mode (or font-lock) a couple decades ago. It was to speed up syntax highlighting for a particular style of commenting. Maybe a 3-6 line patch, tops.
I spent 20x more time back and forth on copyright assignments, including getting a release from my company, etc to get the patch in. I pushed through because I felt like I was always "just one more yak shave away from finishing", but if I knew at the start how much time it was going to take, I'd have kept the patch on our own private site-lisp. That's a problem, IMO.
I spent 20x more time back and forth on copyright assignments, including getting a release from my company, etc to get the patch in. I pushed through because I felt like I was always "just one more yak shave away from finishing", but if I knew at the start how much time it was going to take, I'd have kept the patch on our own private site-lisp. That's a problem, IMO.
The copyright release process where I work is pretty liberal, but the amount of people I have to get involved is fairly prohibitive. If your boss doesn't like doing paperwork, you're not going to get a release...
You don't have to assign the copyright when your total contribution is below 15 lines of so.
Just something to note.
Just something to note.
My memory is that my correspondence was directly with rms on this patch and it was required at the time, but the fact that it would no longer required is definitely beneficial, so thanks for that update!
a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all.
it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL.
at the end of the day a lot of people just want to contribute meaningfully to a project that they use and enjoy, but the headache of licensing and catching flak by choosing the wrong one (and since all the communities have opposing thoughts, they're all the wrong one to certain folks), it just becomes easy to 'forget to contribute' -- especially when your patch or whatever is working fine locally and there is little practical incentive to catch that much heat.
I think the legalese issues turns a lot of would-be contributors into local-patcher type developers, and then they leave for greener pastures once what they needed patched is on their own machine -- especially for projects like emacs where 90 percent of development is going to be towards extensions.
...and I say all this from a position of love and admiration for GNU and the FSF.
it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL.
at the end of the day a lot of people just want to contribute meaningfully to a project that they use and enjoy, but the headache of licensing and catching flak by choosing the wrong one (and since all the communities have opposing thoughts, they're all the wrong one to certain folks), it just becomes easy to 'forget to contribute' -- especially when your patch or whatever is working fine locally and there is little practical incentive to catch that much heat.
I think the legalese issues turns a lot of would-be contributors into local-patcher type developers, and then they leave for greener pastures once what they needed patched is on their own machine -- especially for projects like emacs where 90 percent of development is going to be towards extensions.
...and I say all this from a position of love and admiration for GNU and the FSF.
A cheeky license, or, worse, no license at all is a potential hole for a lawsuit. That is, of time and money wasted, and of the project being at risk.
I see why you might go with Apache, or MIT, or even straight public domain licenses. But as a maintainer, I would not accept a contribution which is not properly licensed, or which is licensed in a way not compatible with the project's license. Usually such a contribution is less valuable than the rest of the project, so there's no point to introduce a real legal risk of project's closure for the sake of such a contribution.
I see why you might go with Apache, or MIT, or even straight public domain licenses. But as a maintainer, I would not accept a contribution which is not properly licensed, or which is licensed in a way not compatible with the project's license. Usually such a contribution is less valuable than the rest of the project, so there's no point to introduce a real legal risk of project's closure for the sake of such a contribution.
I can relate. Used to be a hardcore GNU fan, but these days I'm probably closer to sqlite thinking (public domain, but work hard to avoid contamination).
As for contributions, presumably GNU wants ownership, but do they have a problem with assigning back what amounts to public domain rights to the author?
And I suppose, for most contributions, does it really matter? The awful truth is that I can't think of anything I've ever written that had freestanding value, as opposed to value as an enhancement to something else.
As for contributions, presumably GNU wants ownership, but do they have a problem with assigning back what amounts to public domain rights to the author?
And I suppose, for most contributions, does it really matter? The awful truth is that I can't think of anything I've ever written that had freestanding value, as opposed to value as an enhancement to something else.
Yeah I completely agree. It's like, I agree with GNU and the FSF, but that doesn't mean I'm as strict as they are. I want to contribute to MIT, Apache, and BSD licensed projects as well, or I want to just not think about it and work on some project that has no licensing info whatsoever.
But (some definitely not all) folks are pretty all or nothing. There's a lot of jerk developers on the net though, maybe it's better to just ignore them?
But (some definitely not all) folks are pretty all or nothing. There's a lot of jerk developers on the net though, maybe it's better to just ignore them?
> love and admiration
I don't know about that, I hate agendas. A hammer does not have one, and that does not make it a less useful tool.
I don't know about that, I hate agendas. A hammer does not have one, and that does not make it a less useful tool.
> A hammer does not have [an agenda], and that does not make it a less useful tool.
Sure, but by default all software has a copyright agenda built in. We can remove copyright, but there are two approaches:
- Remove copyright so that anyone can use your code, but then they can re-add copyright to your code and sue other people for violating their copyright.
- Remove copyright so that anyone can use your code and ensure that nobody can re-add copyright to your code.
I used to be in the former camp, but I've slowly moved to the latter.
Sure, but by default all software has a copyright agenda built in. We can remove copyright, but there are two approaches:
- Remove copyright so that anyone can use your code, but then they can re-add copyright to your code and sue other people for violating their copyright.
- Remove copyright so that anyone can use your code and ensure that nobody can re-add copyright to your code.
I used to be in the former camp, but I've slowly moved to the latter.
It's kinda why I like the Mozilla license (MPL). Anyone can freely use (leech even) on the project, but if they make improvements or changes to the project they have to share. It also doesn't try to control how the consumer of the project is allowed to deploy such software either.
A hammer is not made up of sentient beings who have moral obligations.
There's a world of difference between releasing contributions under the same copyright (i.e. if you're contributing to a GPL'd project, release your code under the same GPL license) and assigning copyright to the FSF. I think that's the turn-off for many. It isn't a matter of 'what would you even do with' the contribution, it's a matter of recognition and making it much harder to change the licensing terms down the road.
For those who just want to bury their head in the sand and pretend copyright doesn't exist, they will be the first to complain when the code that they wrote is taken private and commercialized (i.e. look at the licenses this has been an issue for)... making code 'public domain' allows for that.
For those who just want to bury their head in the sand and pretend copyright doesn't exist, they will be the first to complain when the code that they wrote is taken private and commercialized (i.e. look at the licenses this has been an issue for)... making code 'public domain' allows for that.
What happens when the woke takeover of the SFS is finally complete and emacs is re-licensed under a new social justice license where you can only use it if you don't oppress minorities?
I don't trust the FSF further than I can throw them and I don't trust them with my copyrights.
I don't trust the FSF further than I can throw them and I don't trust them with my copyrights.
Agreed... that was my point. Specifically, it doesn't matter who takes over or what the changes are, only that direction/priorities may change and be inconsistent with the intent of the original contributor.
The existing code cannot just be "re-licensed". It's true that they might decide to make future versions available only under some weird license, but that wouldn't cause prior contributions to become unavailable. Continuing the code line under the original license would always be possible, given effort.
That's when we fork emacs with the GPL license. You can't retroactively change the license to the code you published as GPL before
Good point!
Why would you want to become a maintainer when your suggestions will be blocked by a guy who doesn't even know what org-mode is, hasn't coded in decades, and insists the terminology has to pretend it's 1968?
Popularity means more users and more contributors. I guess most of the core emacs devs are greybeards who started programming in the 80s or earlier, so what happens when they grow too old? Who will replace them?
> I guess most of the core emacs devs are greybeards who started programming in the 80s or earlier, so what happens when they grow too old? Who will replace them?
What makes you say that? I don't think this is true. Not among the package maintainers anyways, and also of note here is remacs - I can't imagine greybeards programming in rust.
And popularity does not always mean more contributors, not when they are just the consumers of the product. The drop off in delta contributors / delta consumers is fast.
What makes you say that? I don't think this is true. Not among the package maintainers anyways, and also of note here is remacs - I can't imagine greybeards programming in rust.
And popularity does not always mean more contributors, not when they are just the consumers of the product. The drop off in delta contributors / delta consumers is fast.
>What makes you say that? I don't think this is true.
the same thing that probably made you say this :
>I can't imagine greybeards programming in rust.
emacs is an older software package, from the 'original home of hackers', extended in a (sorta) language that is notoriously connected to old-school AI and academic programming. The holy war of vi vs. emacs has raged for decades -- and emacs/vi/lisp jokes are some of the oldest computer geek jokes in existence.
I can imagine the fans skew older then say fans of something like Electron or Flutter.
The only computer-geek-joke-theme that I can think of that'd be older would be the billions of COBOL jokes -- but that's just because i'm too young to have heard the billions of punch-card and wire-routing jokes that inevitably existed before I was here.
the same thing that probably made you say this :
>I can't imagine greybeards programming in rust.
emacs is an older software package, from the 'original home of hackers', extended in a (sorta) language that is notoriously connected to old-school AI and academic programming. The holy war of vi vs. emacs has raged for decades -- and emacs/vi/lisp jokes are some of the oldest computer geek jokes in existence.
I can imagine the fans skew older then say fans of something like Electron or Flutter.
The only computer-geek-joke-theme that I can think of that'd be older would be the billions of COBOL jokes -- but that's just because i'm too young to have heard the billions of punch-card and wire-routing jokes that inevitably existed before I was here.
>>What makes you say that? I don't think this is true.
>the same thing that probably made you say this :
>>I can't imagine greybeards programming in rust.
Guilty. I clearly had a blind spot there.
>the same thing that probably made you say this :
>>I can't imagine greybeards programming in rust.
Guilty. I clearly had a blind spot there.
At the time Emacs was created, Lisp was one of the few languages that had automatic memory management and higher-order functions and error handling, but those have been lifted so often that they're now table stakes for modern languages.
I'm pushing 50 and excited about Rust because it's finally conceivable to have software that works reliably. I like Emacs, but it's not like I haven't seen my share of crashes in its kinda clunky C runtime. Hell, Rust even has macros.
I'm pushing 50 and excited about Rust because it's finally conceivable to have software that works reliably. I like Emacs, but it's not like I haven't seen my share of crashes in its kinda clunky C runtime. Hell, Rust even has macros.
> it's finally conceivable to have software that works reliably.
Care to elaborate what you mean by that?
Care to elaborate what you mean by that?
The industry has been trying to write C and then C++ for decades, but it all blows up randomly. Buffer overruns, use after free, shared mutable state. Apparently tooling exists that tries to make Rust-like guarantees, but it's so costly I've literally never seen it used.
I don't get it. What about the JVM or ObjC or C#? How is it that only with Rust the things you stated are coming to us?
Much as Elisp is written in C, the JVM and CLR are each written in C++ and assembly, hosted on an OS written in C and assembly, and I've seen all of these crash.
Thanks, I know see better what you mean. But, wasn't that achieved prior to Rust by realtime OSs like QNX?
I don't know much about QNX, but I haven't heard anything about seL4-type rigor going into it, so I wouldn't bet on it working a lot better than Linux or Windows.
> What makes you say that? I don't think this is true. Not among the package maintainers anyways
I was talking about the "core developers" who work on the emacs core, not packages. AFAIK most of them has a long history with emacs, using it for decades, so they can't be that young.
But of course I know mostly about the maintaners and stuff. It's possible there are lots of younger contributors.
I was talking about the "core developers" who work on the emacs core, not packages. AFAIK most of them has a long history with emacs, using it for decades, so they can't be that young.
But of course I know mostly about the maintaners and stuff. It's possible there are lots of younger contributors.
Perhaps adding JavaScript to the list of languages that you can extend Emacs with would be a good start - https://www.emacswiki.org/emacs/CategoryExtensionLanguage
Or, emacs in the browser. Popular editors like VS Code use monaco and now github has codespaces [1] which is running in the browser.
People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, call JS code, or embed emacs into a page as easily as monaco. Maybe the GUI components could be made out of HTML 5?
1. https://techcrunch.com/2020/05/06/github-gets-a-built-in-ide...
PS. Rough sledding for Gitpod with this announcement.
People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, call JS code, or embed emacs into a page as easily as monaco. Maybe the GUI components could be made out of HTML 5?
1. https://techcrunch.com/2020/05/06/github-gets-a-built-in-ide...
PS. Rough sledding for Gitpod with this announcement.
So something similar to what Neovim is doing where it can be a headless backend for any editor that implements their protocol? Like eventually if JetBrains bothers, you wont need a VIM emulator for IntelliJ and co, you can just run Neovim and have it work with IntelliJ directly, without losing any of IntelliJ's benefits. Note: I also mean PyCharm, GoLand, and so on...
Neovim literally has like over 30 projects for new UIs:
https://github.com/neovim/neovim/wiki/Related-projects
Neovim literally has like over 30 projects for new UIs:
https://github.com/neovim/neovim/wiki/Related-projects
Emacs in the browser, you say? smug Willy Wonka face
http://www.ymacs.org/
http://www.ymacs.org/
That’s a cool project and a nice effort. It renders pretty well on my iPhone too. Not able to edit on the phone, but still.
I see some other good ideas here too that could maybe give emacs a fresh breath in the new world of IDEs in the browser/cloud.
I see some other good ideas here too that could maybe give emacs a fresh breath in the new world of IDEs in the browser/cloud.
Last updated 2012.
Agree, browser-based front-ends make so much sense today - conceivably including one for emacs (which can work in the client-server mode anyway).
Would you realistically be able to bind enough emacs keybinds in a web page so that it feels natural? Or would you need some extra extension to help with that?
I'm not very familiar with how easy it is to capture browser keybinds in a web page.
I'm not very familiar with how easy it is to capture browser keybinds in a web page.
You pretty much need an extension that runs in a separate window. You can already use Emacs through the Secure Shell[1] Chrome extension, but if you run it in a tab the browser eats too many key combinations for it to be useful. If you launch it in a separate window, then very few key combinations get intercepted and it works quite well.
[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...
[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...
For the backend or the gui-interface?
I dunno... I think newer editors are often easier to extend than emacs. Think atom or vscode or even sublime.
They're all extensible enough such that emacs has no real major advantage IMHO. They can be extended with mainstream languages that many programmers already know, instead of an idiosyncratic lisp with no practical application outside of emacs itself.
Emacs still has some great modes (like tramp) - but overall, I don't think its customization is really a special killer emacs feature anymore.
They're all extensible enough such that emacs has no real major advantage IMHO. They can be extended with mainstream languages that many programmers already know, instead of an idiosyncratic lisp with no practical application outside of emacs itself.
Emacs still has some great modes (like tramp) - but overall, I don't think its customization is really a special killer emacs feature anymore.
I've had to write simple plugins for both SublimeText and VSCode to get the equivalent of a one-liner in Emacs. Comparing anything with Emacs extensibility is not even fair. There are hooks for everything, you can invoke other people packages from your own code, if you want trouble you can overwrite other people's packages specific functions, etc.
Emacs has a lot of flaws though. I don't really recommend people using it. Even after showing the neat stuff, I can do with it.
Emacs has a lot of flaws though. I don't really recommend people using it. Even after showing the neat stuff, I can do with it.
> I dunno... I think newer editors are often easier to extend than emacs. Think atom or vscode or even sublime.
Can't see how. It's hard to be easier to extend than being able to just wrtie a line of code in an init file, do M-x eval-region on it, and be done. You can extend Emacs 100% through ad-hoc manner, and none of that requires any extra infrastructure. I don't think VSCode or Atom are approaching anywhere close this level of flexibility.
Can't see how. It's hard to be easier to extend than being able to just wrtie a line of code in an init file, do M-x eval-region on it, and be done. You can extend Emacs 100% through ad-hoc manner, and none of that requires any extra infrastructure. I don't think VSCode or Atom are approaching anywhere close this level of flexibility.
I’ve been porting the Sly IDE to Sublime and basically I would say Sublime is a hostile development environment, a lot of times errors dont trigger stack traces and just silently fail which is super frustrating.
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Color me surprised! I'm turning into a stereotypical Linux greybeard but I must be true to my nature, and endorse Linux for writers.
There's this famous story, about the secretaries who mastered Emacs and preferred it to the other 'easier' administrative programs they were offered.
https://groups.google.com/d/msg/gnu.emacs.help/QU6xN34ollo/K....
"Shel wrote Mailman in Lisp. Emacs-Lisp… Mailman was the Customer Service customer-email processing application for … four, five years? A long time, anyway. It was written in Emacs. Everyone loved it."
"People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them."
Hell, there's even a 1-hour series on YouTube called "Emacs for Writers."
https://www.youtube.com/watch?v=FtieBc3KptU
Spoiler: I skimmed it and it's as I thought - it's largely about Emacs and org-mode. Honestly, I can't argue with the classics. Here's my pitch.
Writers of the world: You are information workers. That means you have problems with the organization of information, probably, and - related - information overload.
Let Emacs help you with this!
It has a mode, org-mode, which is usually overcomplicated, but is basically as simple as markdown (no, really). Has anyone ever walked away from Markdown because it was too difficult to understand? Probably not. It doesn't have to be any harder with org-mode. In fact, in the next two lines, I'll teach you about 95% of how I use it - everything, in two lines.
* an asterisk before a line makes it like a sublayer of the layer/line above it; if you're on a sublayer, add another asterisk to make a sublayer of a sublayer, and so on ad infinitum...
* press tab to expand a layer or a sublayer you are on; press tab again to contract or hide it
That's it! That's 95% of the value of org-mode right there. It's the simplest way to organize information, in my experience.
Now, there are other advantages too, like: Emacs works with plain text, and plain text is super portable (everything can read plain text), fast to load, and can even be a convenient method of organizing things, if you give your files descriptive names and learn to use 'ls' to list things. Because those files are plain text, they take up almost no space, so it's fine if your computer has a zillion of them, it'll be blazing fast.
I could go on, but these two things alone make Emacs worth your time, and there's plenty of other advantages, like using LaTeX to make PDF's, you can 'grow into' also.
Color me surprised! I'm turning into a stereotypical Linux greybeard but I must be true to my nature, and endorse Linux for writers.
There's this famous story, about the secretaries who mastered Emacs and preferred it to the other 'easier' administrative programs they were offered.
https://groups.google.com/d/msg/gnu.emacs.help/QU6xN34ollo/K....
"Shel wrote Mailman in Lisp. Emacs-Lisp… Mailman was the Customer Service customer-email processing application for … four, five years? A long time, anyway. It was written in Emacs. Everyone loved it."
"People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them."
Hell, there's even a 1-hour series on YouTube called "Emacs for Writers."
https://www.youtube.com/watch?v=FtieBc3KptU
Spoiler: I skimmed it and it's as I thought - it's largely about Emacs and org-mode. Honestly, I can't argue with the classics. Here's my pitch.
Writers of the world: You are information workers. That means you have problems with the organization of information, probably, and - related - information overload.
Let Emacs help you with this!
It has a mode, org-mode, which is usually overcomplicated, but is basically as simple as markdown (no, really). Has anyone ever walked away from Markdown because it was too difficult to understand? Probably not. It doesn't have to be any harder with org-mode. In fact, in the next two lines, I'll teach you about 95% of how I use it - everything, in two lines.
* an asterisk before a line makes it like a sublayer of the layer/line above it; if you're on a sublayer, add another asterisk to make a sublayer of a sublayer, and so on ad infinitum...
* press tab to expand a layer or a sublayer you are on; press tab again to contract or hide it
That's it! That's 95% of the value of org-mode right there. It's the simplest way to organize information, in my experience.
Now, there are other advantages too, like: Emacs works with plain text, and plain text is super portable (everything can read plain text), fast to load, and can even be a convenient method of organizing things, if you give your files descriptive names and learn to use 'ls' to list things. Because those files are plain text, they take up almost no space, so it's fine if your computer has a zillion of them, it'll be blazing fast.
I could go on, but these two things alone make Emacs worth your time, and there's plenty of other advantages, like using LaTeX to make PDF's, you can 'grow into' also.
I think you've misunderstood why someone would prefer Scrivener or a word processor: a rich-text ecosystem that "just works", in terms of WYSIWG / rich text editing; being the de facto standard for many non-technical user; and being more than "as simple as Markdown", but actively providing a tight ecosystem focused on writing.
Is it possible to recreate some of this functionality in emacs? Definitely. But, it requires a lot of patience, exploration, and determination.
Your editor wants to add track changes and inline comments to your manuscript draft. How do they do that in your org-mode file?
You've received a .docx draft from a friend, or copy for your book blurb, or a press release for your upcoming publication. How do you edit that .docx and return it in better shape than you found it?
You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of. How do you quickly navigate between these multiple sources of content, marking things up, merging different aspects of documents?
I'm a die-hard emacser, and I do a lot of personal and academic writing in LaTeX. But honestly, have you ever had to reformat a LaTeX manuscript for journal publication? It can take hours just to get the damn file to compile.
emacs is worth the time, if you're inclined to tinker and invest the effort to get it to work—but for me, at least, that's a hobby. It's disingenuous to present it as a real competitor to industry-standard workhorse word processors. And most writers with a day job can barely find time to write, "investing time in emacs" is a nonstarter for getting things done! In fact, I tune my own org-basaed PIM system as a way to avoid getting real work done...
Is it possible to recreate some of this functionality in emacs? Definitely. But, it requires a lot of patience, exploration, and determination.
Your editor wants to add track changes and inline comments to your manuscript draft. How do they do that in your org-mode file?
You've received a .docx draft from a friend, or copy for your book blurb, or a press release for your upcoming publication. How do you edit that .docx and return it in better shape than you found it?
You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of. How do you quickly navigate between these multiple sources of content, marking things up, merging different aspects of documents?
I'm a die-hard emacser, and I do a lot of personal and academic writing in LaTeX. But honestly, have you ever had to reformat a LaTeX manuscript for journal publication? It can take hours just to get the damn file to compile.
emacs is worth the time, if you're inclined to tinker and invest the effort to get it to work—but for me, at least, that's a hobby. It's disingenuous to present it as a real competitor to industry-standard workhorse word processors. And most writers with a day job can barely find time to write, "investing time in emacs" is a nonstarter for getting things done! In fact, I tune my own org-basaed PIM system as a way to avoid getting real work done...
> Your editor wants to add track changes and inline comments to your manuscript draft. How do they do that in your org-mode file?
https://orgmode.org/manual/Comment-Lines.html
> You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of.
https://orgmode.org/manual/Tags.html
https://orgmode.org/manual/Internal-Links.html
https://orgmode.org/manual/External-Links.html
https://orgmode.org/manual/Handling-Links.html
https://orgmode.org/manual/Comment-Lines.html
> You're writing a novel, and it has extensive research notes, background material, and miscellany you're keeping track of.
https://orgmode.org/manual/Tags.html
https://orgmode.org/manual/Internal-Links.html
https://orgmode.org/manual/External-Links.html
https://orgmode.org/manual/Handling-Links.html
To be clear, by "your editor", I don't mean emacs—I mean the person who works at a publisher: she knows that a gnu is just a wildebeest and inheritance bequeathal of wealth; assumes "C-c ;" is just an obscure emoji; and will not waste her time indulging a writer who uses an obscure [1], roundabout way of entering text into M$ Word.
Look, again, you're preaching to the choir—I use emacs every day. But writing a Python script to generate my org-native ToC to navigate reference materials is just...a very different, more work-intensive beast than an interactive drag-and-drop IDE tailored to the needs of professional writers. Impossible to approximate, with enough determination? No. Possible to start using intuitively within the first 15 minutes? Also: no.
[1] https://insights.stackoverflow.com/survey/2019#technology-_-...
Look, again, you're preaching to the choir—I use emacs every day. But writing a Python script to generate my org-native ToC to navigate reference materials is just...a very different, more work-intensive beast than an interactive drag-and-drop IDE tailored to the needs of professional writers. Impossible to approximate, with enough determination? No. Possible to start using intuitively within the first 15 minutes? Also: no.
[1] https://insights.stackoverflow.com/survey/2019#technology-_-...
I understood what you meant.
"Open my doc in notepad or any other text editor. Put comments wherever you want; if you'd be so kind as to put them on their own line with a # at the start it would save me some time."
Easy peasy.
The beauty of org is that it's just a text file. You don't need Emacs to edit it.
"Open my doc in notepad or any other text editor. Put comments wherever you want; if you'd be so kind as to put them on their own line with a # at the start it would save me some time."
Easy peasy.
The beauty of org is that it's just a text file. You don't need Emacs to edit it.
And then you have line endings and weird control characters and emoji don’t work in Emacs, etc etc
I too have used Emacs a lot. I’m getting off the boat.
I too have used Emacs a lot. I’m getting off the boat.
UTF Emojis work in Emacs, and control characters are displayed and easily removed.
If you're git-savvy it's even easier to merge the comments in by using Magit and reviewing the changes individually.
If you're git-savvy it's even easier to merge the comments in by using Magit and reviewing the changes individually.
I find word processors with all their formatting, hyphenation etc. capabilities more of a distraction than help. IMHO they are better for publishing a text than for writing it. Even a simple text editor seems like a better choice.
> Does it need to be popular or need more users to become maintainers?
Yes.
> I use emacs because I can't imagine using anything else that has half the features and is harder to extend.
Maybe imagine harder or (just an idea) stop imagining and see the real world?
> It's a programming environment that happens to have a text editor built in.
Read the history of emacs again. It originated as a set of macros over TECO to make editing easier (hence the name emacs). Editing is always the primary function, the lisp interpreter was an afterthought.
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Read the linked thread again. One "such user" is RMS. That pretty much has been his goal since the 90s to make Emacs a better word processor.
Yes.
> I use emacs because I can't imagine using anything else that has half the features and is harder to extend.
Maybe imagine harder or (just an idea) stop imagining and see the real world?
> It's a programming environment that happens to have a text editor built in.
Read the history of emacs again. It originated as a set of macros over TECO to make editing easier (hence the name emacs). Editing is always the primary function, the lisp interpreter was an afterthought.
> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.
Read the linked thread again. One "such user" is RMS. That pretty much has been his goal since the 90s to make Emacs a better word processor.
Is it really too hard to imagine why the creator of the Free Software Foundation would rather people use a free software text editor over the current proprietary alternatives?
That's so well stated, /u/agentuitra. Thank you.
I largely agree with you. Out of curiosity, where do you think Unicode support could be better?
Completeness, speed, and defaults would be nice.
I'm mostly satisfied as a user. I'm working on a mode for editing emojicode[0] and it's a weird edge case but it'd be nice if emacs worked out of the box with nice defaults for this sort of thing. More experienced library authors might have more to say about it.
[0] https://www.emojicode.org/
I'm mostly satisfied as a user. I'm working on a mode for editing emojicode[0] and it's a weird edge case but it'd be nice if emacs worked out of the box with nice defaults for this sort of thing. More experienced library authors might have more to say about it.
[0] https://www.emojicode.org/
[deleted]
[deleted]
I hear a lot about the declining popularity of Emacs, but I always wonder how much it is overstating the case. As a tech enthusiast but (mostly) non-programmer, my perception has actually been that the "cool factor" of Emacs has been on the rise. Around 2011 or so, I hardly ever saw mention of it online. Now a day hardly go by on places like Reddit's "unixporn" board that someone doesn't post their slick setup with Emacs/Doom Emacs/Spacemacs on display.
I know that that Reddit board is sort of ridiculous and the jokes about it write themselves, but I nonetheless feel that Emacs has attained a certain counter-cultural "cool"/cachet in recent years that it lacked a decade ago. In my opinion, this is a good sign for its future, all things considered. These threads are always full of comments about how vscode has surpassed it, etc., but I don't think anything can change that--Emacs will ever truly satisfy those for whom vscode is presently the superior tool, and conversely, vscode is unlikely to satisfy the Emacs user.
Like vscode, Emacs is in every sense a practical tool; it is simply that it is practical in service of different needs. It is a practical tool for someone who takes active pleasure in the cultivation of a practical tool, in the process of learning and discovery involved. Because this will never describe a majority of users, I don't think Emacs will ever capture a majority of developers or whatever, but it seems poised to continue to attract very dedicated ones who find the cultivation of a personal work environment in a ridiculously powerful 40-year-old program appealing in and of itself.
I know that that Reddit board is sort of ridiculous and the jokes about it write themselves, but I nonetheless feel that Emacs has attained a certain counter-cultural "cool"/cachet in recent years that it lacked a decade ago. In my opinion, this is a good sign for its future, all things considered. These threads are always full of comments about how vscode has surpassed it, etc., but I don't think anything can change that--Emacs will ever truly satisfy those for whom vscode is presently the superior tool, and conversely, vscode is unlikely to satisfy the Emacs user.
Like vscode, Emacs is in every sense a practical tool; it is simply that it is practical in service of different needs. It is a practical tool for someone who takes active pleasure in the cultivation of a practical tool, in the process of learning and discovery involved. Because this will never describe a majority of users, I don't think Emacs will ever capture a majority of developers or whatever, but it seems poised to continue to attract very dedicated ones who find the cultivation of a personal work environment in a ridiculously powerful 40-year-old program appealing in and of itself.
Anecdotally, I started learning Emacs a few months ago and am very happy with my decision. I first considered trying roughly 10 years ago, but didn't see the thriving package ecosystem I see today, starting with projects like Spacemacs and Doom. After some time trialing my options, I stuck with Spacemacs, and that choice saved me time in reaching my goal of transitioning my knowledge and project management to org-mode.
Even with training wheels, though, getting started wasn't simple. It's had a very choose-your-own-adventure feel to it. After some early thrashing, I've now found my favorite resources, have a decent sense of what's out there, and am even using org-mode to track my overall learning progress. It's become self-reinforcing.
With more modern tools getting better and better, I find it no surprise that VS Code and others are gaining market share, and that the Emacs user profile is becoming less diverse. But I think there will always be a place for a tool(box) as powerful and configurable as Emacs.
Even with training wheels, though, getting started wasn't simple. It's had a very choose-your-own-adventure feel to it. After some early thrashing, I've now found my favorite resources, have a decent sense of what's out there, and am even using org-mode to track my overall learning progress. It's become self-reinforcing.
With more modern tools getting better and better, I find it no surprise that VS Code and others are gaining market share, and that the Emacs user profile is becoming less diverse. But I think there will always be a place for a tool(box) as powerful and configurable as Emacs.
I once opened a textbook of Chinese, read a few first pages and had to put the book away - the characters, while seeming difficult to remember at first, started infiltrating my brain with a frightening efficiency... Same with learning emacs. There is something about it that you mind-meld with it and using it becomes part of your nature.
I've started learning Emacs a few weeks ago, and have had a similar experience as you. One different is that I considered going with Spacemacs / Doom but decided to take the route of starting from an empty init file and slowly building up from there (at least for now).
I identify strongly with the feeling of thrashing; the wealth of different information and flexibility of the program itself can be overwhelming. Would you be willing to share some of your favorite resources (and why you chose them)? That would be immensely helpful for a beginner like me.
I think there's a lot to learn from starting from scratch, and it's something I hope to do too.
Gladly! I'll keep the list to what I've studied so far. Here goes: - If you ever want to explore, say, Doom (Spacemacs is likely too bloated for someone who gravitates to a vanilla config), chemacs[1] is a nifty, simple profile switcher - I think there's a lot of value in studying what they've done with their mnemonic keybinding systems (I love being able to narrow to an org-mode subtree and widen again with =, n= and =, N=, respectively, as but one of many examples) - Sasha Chua is a good source, as she's very knowledgeable and put out a drawn 1-pager[2] on starting Emacs - it's geared towards standard Emacs keybindings - Personally, I'm a huge fan of Evil-mode for Vim keybindings, as they're powerful and portable and I had basic familiarity with Vim before picking up Emacs - I haven't found a rough edge in Evil-mode yet - it seems very refined - Dired is worth getting a handle on early since any improvement in how you can navigate Emacs translates - Magit is pure magic, and I now have my full ~/org under version control with what feels like near-0 overhead - Seorenn makes mostly Spacemacs videos[3] and Zaiste Programming makes Doom videos[4], but I find them useful regardless of my config - you may just want to skip to the videos on packages that interest you - If you haven't yet, choosing either Helm or Ivy is huge - Personally, I'm happy with helm in Spacemacs and I was happy with ivy when I used Doom - heck, even my friend is happy with Ido - It's fun to explore more efficient ways of jumping around - the Avy package is very popular for this (check out `avy-goto-char-timer` in particular) - Also, I'll note that I've been able to find a clean 1- or 2-pager reference card for every major package I've searched for
But, truly, the jackpot for me has been org-mode. At first, I used it as just another knowledge repo, like a more efficient (yet local and text-centric) version of Evernote. But, now, I'm working through the book _Getting Things Done_ and believe that there is no better tool on the planet than Emacs and org-mode for implementing the core and majority of that system. Regardless, having a specific implementation goal has aided my learning dramatically.
Specific to org-mode: - I started with the Org-mode Compact Guide[5], which I'd study and practice during 20-30 minute sessions every other day or so - it moves fast and I was happy with my org-mode skill after only having worked through Chapter 2 - However, perhaps the best way to start learning org-mode is Worg[6] - Occasionally, I've found that the Compact Guide lacks an important command for my own workflow, so I'll usually go to the Org-mode Manual[7] itself - When learning to configure Refiling, though, I found this[8] to be the best resource - Finally, I'm a big fan of "org indent mode" - it keeps Git diffs clean when changing indentation yet displays my contents appropriately indented
This is a lot, and I'm sure your path will be different than mine, but I hope you find some nuggets in there. Best of luck!
[1] https://github.com/plexus/chemacs [2] https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand... [3] https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nn... [4] https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB... [5] https://orgmode.org/guide/ [6] https://orgmode.org/worg/ [7] https://orgmode.org/org.html [8] https://blog.aaronbieber.com/2017/03/19/organizing-notes-wit...
Gladly! I'll keep the list to what I've studied so far. Here goes: - If you ever want to explore, say, Doom (Spacemacs is likely too bloated for someone who gravitates to a vanilla config), chemacs[1] is a nifty, simple profile switcher - I think there's a lot of value in studying what they've done with their mnemonic keybinding systems (I love being able to narrow to an org-mode subtree and widen again with =, n= and =, N=, respectively, as but one of many examples) - Sasha Chua is a good source, as she's very knowledgeable and put out a drawn 1-pager[2] on starting Emacs - it's geared towards standard Emacs keybindings - Personally, I'm a huge fan of Evil-mode for Vim keybindings, as they're powerful and portable and I had basic familiarity with Vim before picking up Emacs - I haven't found a rough edge in Evil-mode yet - it seems very refined - Dired is worth getting a handle on early since any improvement in how you can navigate Emacs translates - Magit is pure magic, and I now have my full ~/org under version control with what feels like near-0 overhead - Seorenn makes mostly Spacemacs videos[3] and Zaiste Programming makes Doom videos[4], but I find them useful regardless of my config - you may just want to skip to the videos on packages that interest you - If you haven't yet, choosing either Helm or Ivy is huge - Personally, I'm happy with helm in Spacemacs and I was happy with ivy when I used Doom - heck, even my friend is happy with Ido - It's fun to explore more efficient ways of jumping around - the Avy package is very popular for this (check out `avy-goto-char-timer` in particular) - Also, I'll note that I've been able to find a clean 1- or 2-pager reference card for every major package I've searched for
But, truly, the jackpot for me has been org-mode. At first, I used it as just another knowledge repo, like a more efficient (yet local and text-centric) version of Evernote. But, now, I'm working through the book _Getting Things Done_ and believe that there is no better tool on the planet than Emacs and org-mode for implementing the core and majority of that system. Regardless, having a specific implementation goal has aided my learning dramatically.
Specific to org-mode: - I started with the Org-mode Compact Guide[5], which I'd study and practice during 20-30 minute sessions every other day or so - it moves fast and I was happy with my org-mode skill after only having worked through Chapter 2 - However, perhaps the best way to start learning org-mode is Worg[6] - Occasionally, I've found that the Compact Guide lacks an important command for my own workflow, so I'll usually go to the Org-mode Manual[7] itself - When learning to configure Refiling, though, I found this[8] to be the best resource - Finally, I'm a big fan of "org indent mode" - it keeps Git diffs clean when changing indentation yet displays my contents appropriately indented
This is a lot, and I'm sure your path will be different than mine, but I hope you find some nuggets in there. Best of luck!
[1] https://github.com/plexus/chemacs [2] https://sachachua.com/blog/2013/05/how-to-learn-emacs-a-hand... [3] https://www.youtube.com/playlist?list=PLPNohcoOBa5GGreLyc3nn... [4] https://www.youtube.com/watch?v=rCMh7srOqvw&list=PLhXZp00uXB... [5] https://orgmode.org/guide/ [6] https://orgmode.org/worg/ [7] https://orgmode.org/org.html [8] https://blog.aaronbieber.com/2017/03/19/organizing-notes-wit...
I consider the article a bit absurd. Emacs is only less popular relative to the set of editors one can pick today. Emacs has never been more popular or alive. melpa, emacsrocks, famous magit/org, even emacs confs and emacs talks at lisp confs..
Plus maybe "more is less" is adequate when it comes to emacs. Too many people may create friction or waste. Let it be low and slow, it's fine, emacs has stopped sprinting, it's in a nice hike.
Plus maybe "more is less" is adequate when it comes to emacs. Too many people may create friction or waste. Let it be low and slow, it's fine, emacs has stopped sprinting, it's in a nice hike.
You know that is not an article but discussion about emails from emacs development list, right?
I couldn't read after the introduction.
Oh definitely. Almost 30 year Emacs user here. When I saw what was happening with productivity leaps like swiper and helm, and Spacemacs working to make Emacs look nicer without turning it into another CUA+TEXTAREA also-ran, I called it the Emacs Renaissance!
A lot of times I’ve noticed people arguing that some nice thing in Emacs “could be” implemented in their chosen editor. I think they underestimate the value difference between that and “has been” implemented.
A lot of times I’ve noticed people arguing that some nice thing in Emacs “could be” implemented in their chosen editor. I think they underestimate the value difference between that and “has been” implemented.
I haven't heard of the decline or rise of the popularity of emacs, but from personal experience it is holding up quite well!
I think par-edit is superb for anyone building stuff in some lisp dialect. org-mode is unbeatable and I saw quite a few stories on reddit of people getting drawn to emacs because of org-mode. Recently I picked up rust development and the rust-mode is working very well for me, much better than VSCode or the Intellij plugin.
Around university I see many lecturers using emacs too.
I think par-edit is superb for anyone building stuff in some lisp dialect. org-mode is unbeatable and I saw quite a few stories on reddit of people getting drawn to emacs because of org-mode. Recently I picked up rust development and the rust-mode is working very well for me, much better than VSCode or the Intellij plugin.
Around university I see many lecturers using emacs too.
> I hear a lot about the declining popularity of Emacs, but I always wonder how much it is overstating the case.
Google Trends certainly reports that emacs has experienced a dramatic decline in popularity since 2004.
https://trends.google.com/trends/explore?date=all&q=emacs
Google Trends certainly reports that emacs has experienced a dramatic decline in popularity since 2004.
https://trends.google.com/trends/explore?date=all&q=emacs
The Internet has experienced a similar dramatic decline in popularity.
https://trends.google.com/trends/explore?date=all&q=emacs,in...
https://trends.google.com/trends/explore?date=all&q=emacs,in...
Vim seems quite stable. VS Code is even rising.
https://trends.google.com/trends/explore?date=all&q=emacs,vi...
https://trends.google.com/trends/explore?date=all&q=emacs,vi...
My personal experience years ago was that there was a cool factor, and I learned it, and it's still a pain to use (compared to let's say VS Code), and I think that cool factor was just never a thing.
> cool factor
I agree there's a certain respect afforded to people who are adept with terminal editors, but there is a practical reason to master them: they're always there, no matter how many layers of SSH you've gone through to get where you are.
I agree there's a certain respect afforded to people who are adept with terminal editors, but there is a practical reason to master them: they're always there, no matter how many layers of SSH you've gone through to get where you are.
actually emacs is rarely there, vim is though.
> "Perhaps we should implement a mode that puts cosmetics on Emacs so it will appeal to those who judge by the surface of things."
I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.
In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.
> 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.
And the old "I have suffered therefore the others have to suffer".
I'm sorry to react to first quote, but as I kept reading I kept coming back to it. My thoughts on that : how you present yourself is how you want (and are going) to be judged.
In general I think Emacs has been user-hostile, as said here, just by its terminology. Nobody outside a minority of devs (a minority even among programmers) refers to Ctrl+c as C-c.
> 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.
And the old "I have suffered therefore the others have to suffer".
I don't think emacs is "user-hostile" on purpose. You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.
Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.
Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.
So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.
Today's users expect different things than users did in the 70s (who expected different things than users in the 80s, 90s, so on). Emacs has been relatively consistent through time, which has been a huge boon to emacs users. The tradeoff is against current user's intuitions -- for better or worse, emacs does not work like other popular software today.
Calling this "user-hostile" comes off somewhat entitled. Emacs developers in the 70s/80s/90s/00s simply didn't know enough about today's users to cater to us, even if they wanted to. That's hardly their fault.
So, todays way and the emacs way have diverged some, and it does take a bit of effort to learn. Not because emacs hates you! But because emacs is ancient. The (objective, non-stockholm-syndrome) reward for your efforts to understand it are a) mastery of a system useful enough to survive this long, and b) mastery of a system that isn't likely to change out from under you.
> You have to keep in mind, it's nearly 45 years old. This is almost unprecedented in computing.
We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.
GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.
We can acknowledge Emacs's longevity without straying into unsupportable hyperbole. Emacs is nowhere close to unprecedented in its age and not remotely close to the oldest piece of software still in existence.
GNU Emacs is from 1984. It is a reimplementation of the earlier 1972 Emacs. This matters, since if you're including reimplementations then obviously Unix itself, which is used by many of us every day, it older. And if you start counting from 1984...that's not especially old.
Fair enough! But the point stands, no?
I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? That is the part I find unprecedented (and the part relevant to GP).
I pointed out emacs' age to note how users expectations of editors have evolved over that time. Certainly there is older software -- but is there any other user-facing software that has survived such a dramatically shifting landscape? That is the part I find unprecedented (and the part relevant to GP).
> is there any other user-facing software that has survived such a dramatically shifting landscape?
Yes. Microsoft Word, for example, is older than GNU Emacs.
Yes. Microsoft Word, for example, is older than GNU Emacs.
Just because something is old doesn't make it not user hostile. If anything it encourages it as we are always getting better at making better interfaces.
Cars from the 70's don't have airbags. So, by comparison to what is available today, they are user hostile.
Cars from the 70's don't have airbags. So, by comparison to what is available today, they are user hostile.
Hm. I take your point, but I'm not sure the analogy works.
Maybe better: "Old" (pick a date) cars had a manual transmission. Compared to automatic transmissions, you might consider that user hostile. But back then no one knew what they were missing and got along just fine.
Nowadays, some people still like manual transmissions! Not everyone, but some folks still buy them. Some even claim they're better than automatics! "They're cheaper, easier to maintain!" Are they user-hostile? I guess it depends on who the user is.
(Airbags seem like a strict improvement, sure. But part of that comes from them not being part of the "interface" of the car -- we don't interact with them, we don't form preferences about them, gain familiarity with them, etc. Perhaps they correspond better to multi-cored CPUs, multithreading, or high-res color displays (features emacs has kept with the times on, more or less). It's much harder to come up with similar strict improvements in the UI world.)
Maybe better: "Old" (pick a date) cars had a manual transmission. Compared to automatic transmissions, you might consider that user hostile. But back then no one knew what they were missing and got along just fine.
Nowadays, some people still like manual transmissions! Not everyone, but some folks still buy them. Some even claim they're better than automatics! "They're cheaper, easier to maintain!" Are they user-hostile? I guess it depends on who the user is.
(Airbags seem like a strict improvement, sure. But part of that comes from them not being part of the "interface" of the car -- we don't interact with them, we don't form preferences about them, gain familiarity with them, etc. Perhaps they correspond better to multi-cored CPUs, multithreading, or high-res color displays (features emacs has kept with the times on, more or less). It's much harder to come up with similar strict improvements in the UI world.)
> "user-hostile" on purpose
I seem to recall reading that the keyboards that emacs was originally developed for had the CTRL key in the middle left (where the modern, useless, "caps lock" key is). The awkwardness of the CTRL key on modern keyboards makes emacs seem unnecessarily user-hostile as well, but that's also not something that Stallman could reasonably have predicted.
I seem to recall reading that the keyboards that emacs was originally developed for had the CTRL key in the middle left (where the modern, useless, "caps lock" key is). The awkwardness of the CTRL key on modern keyboards makes emacs seem unnecessarily user-hostile as well, but that's also not something that Stallman could reasonably have predicted.
> And the old "I have suffered therefore the others have to suffer".
Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.
Actually, its an extremely important point. Tools which optimise for the professional are better than those which do so for the noob. Whenever you can achieve both, do so, but never side with the beginner otherwise. People should learn their tools, and they shouldn't be beginners for long, so making things "friendly" at the cost of rewarding expertise is poor design.
This is absolutely true. However, if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should. One way to do that is to not gratuitously invent new terms, and to use terms people are familiar with.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.
Using conventions like "M-x" throughout the documentation, even with a note at the front of the manual that "We refer to Alt as Meta for historical reasons.", is needlessly baroque. Worse yet, maintaining a distinction that those aren't effectively the same thing for almost all users is needlessly unhelpful. (Yes, it's possible to make Alt and Meta different keys under X with use of modifier maps. That explanation belongs in an "advanced keybindings" chapter late in the documentation.)
It's certainly possible to learn that, and a hundred other gratuitous weirdnesses, but they don't actually add value that justifies imposing that weirdness on every user.
I think maybe you're over-emphasizing the problem with this terminology. When I first started learning Emacs it took me all of 5 minutes to get used to the new terms, it isn't that hard. Maybe there's an argument for the lack of value of using older terminology, but again, I think this problem is overblown.
I'm not trying to say this is the most critical problem; I'm saying it's one example of many, and it spends a lot of "weirdness budget" without necessarily providing value in exchange. "kill/yank" is another example, and there are many more where those come from; the volume of them creates a "thousand papercuts" problem.
In the Rust language design, we're careful about what we spend our "weirdness budget" on. We've already spent a fair bit of it on terms related to ownership and borrowing, because those are fundamental and central to the language. We spent some on having a one-character '?' operator for error-checking, because error-checking occurs so often. But we're not going to gratuitously introduce new vocabulary for existing concepts that already have a name people would be more familiar with, and we're extremely hesitant to introduce gratuitous syntax abbreviations just so people can type a little less, because they'd be harder to read and understand.
In the Rust language design, we're careful about what we spend our "weirdness budget" on. We've already spent a fair bit of it on terms related to ownership and borrowing, because those are fundamental and central to the language. We spent some on having a one-character '?' operator for error-checking, because error-checking occurs so often. But we're not going to gratuitously introduce new vocabulary for existing concepts that already have a name people would be more familiar with, and we're extremely hesitant to introduce gratuitous syntax abbreviations just so people can type a little less, because they'd be harder to read and understand.
I agree that a lot of things are weird and could be modernized.
That said, as someone who very slowly got into Emacs and now am full on into it, all this weirdness slowly became more of a an, oh this actually makes a lot of sense, and, you know what, I might like it better.
I still find it weird for a frame to be a window and a window a frame. But logically, I think the Emacs names make more sense. The thing with a frame is a frame, and the sections within it are the windows. I wouldn't mind if it was renamed frame to window and window to panes tough.
Similarly, C-c and M-m used to confuse me a lot. But now I find them way nicer, why have to type all of Ctrl and alt. Also on Mac alt is called command, so having a Meta as a more generic name for the key kind of works.
Kill was weird to me, until I realized kill and delete both exist, but behave differently. There's a kill-ring, text that is killed go in it, text that is deleted doesn't. When you program extensions this is a very important distinction. You don't want programmatic edits to all go in the kill ring and polute it.
Would it be nicer if the more common user used one, which is kill, be named delete which is more familiar to people maybe.
Like I said, I wouldn't mind someone making a big refactor of it all and renaming everything to be less weird to modern times, but I think as you learn those "weirdness" they stop being weird.
Basically, I mean there's a big difference between a quirk, and just something you're not familiar with. I think Emacs names are mostly unfamiliar.
Emacs also has real quirks though, and I think those are more important to address. Like there's a lot of legacy cruft, having to still support working on defunct terminals, and all kind of stuff. Like ESC being a weird Meta key because of terminals that don't support meta. Or the entire UX which is crap by default.
That said, as someone who very slowly got into Emacs and now am full on into it, all this weirdness slowly became more of a an, oh this actually makes a lot of sense, and, you know what, I might like it better.
I still find it weird for a frame to be a window and a window a frame. But logically, I think the Emacs names make more sense. The thing with a frame is a frame, and the sections within it are the windows. I wouldn't mind if it was renamed frame to window and window to panes tough.
Similarly, C-c and M-m used to confuse me a lot. But now I find them way nicer, why have to type all of Ctrl and alt. Also on Mac alt is called command, so having a Meta as a more generic name for the key kind of works.
Kill was weird to me, until I realized kill and delete both exist, but behave differently. There's a kill-ring, text that is killed go in it, text that is deleted doesn't. When you program extensions this is a very important distinction. You don't want programmatic edits to all go in the kill ring and polute it.
Would it be nicer if the more common user used one, which is kill, be named delete which is more familiar to people maybe.
Like I said, I wouldn't mind someone making a big refactor of it all and renaming everything to be less weird to modern times, but I think as you learn those "weirdness" they stop being weird.
Basically, I mean there's a big difference between a quirk, and just something you're not familiar with. I think Emacs names are mostly unfamiliar.
Emacs also has real quirks though, and I think those are more important to address. Like there's a lot of legacy cruft, having to still support working on defunct terminals, and all kind of stuff. Like ESC being a weird Meta key because of terminals that don't support meta. Or the entire UX which is crap by default.
[deleted]
Meta is not always Alt. Some people use ESC for the Meta keybindings.
So? Alt is not always Alt either, and apparently for a lot of people Ctrl is actually Caps Lock (to help with RSI?).
I think you misunderstood. Control, alt, meta, hyper, and super are (at least on my current OS) distinct modifiers. There are also keys bearing some of those names on most keyboards which makes things confusing to talk about.
Each modifier can be mapped to any physical key. For example, I'm one of those control as caps lock people you mentioned. I then have hyper on the left control key, alt and meta (yes both) on the left alt key, level 3 on the right alt key, and compose on the right control key.
Each modifier can be mapped to any physical key. For example, I'm one of those control as caps lock people you mentioned. I then have hyper on the left control key, alt and meta (yes both) on the left alt key, level 3 on the right alt key, and compose on the right control key.
I've never seen a keyboard with hyper or super. I doubt many people have, since they were only present on hardware obsoleted decades ago. Meta, aka the windows key on most PC keyboard, is usually present, but most people wouldn't know its name. On Windows, it's not even usefully bindable since Windows uses various shortcuts for it by default. On Linux, it's not bound to Meta by default by most distributions. So for the vast majority of people, it's just Alt.
I don't think Emacs has done itself any favours by using obscure and non-standard terminology based upon machines from the '70s which few people have heard of, let alone experienced. For the vast, vast majority of us, we all have bog-standard PC or Mac keyboards, and have done for the past 30+ years. It would have been in everyone's interest to standardise on terminology and keybindings which were immediately understandable and usable by all.
Given that every other application uses the standard terminology and keybindings, and that I don't see much in the way of compelling advantage to keeping the non-standard bindings other than habit, I think preserving backward compatibility for four decades was laudable but misguided.
I don't think Emacs has done itself any favours by using obscure and non-standard terminology based upon machines from the '70s which few people have heard of, let alone experienced. For the vast, vast majority of us, we all have bog-standard PC or Mac keyboards, and have done for the past 30+ years. It would have been in everyone's interest to standardise on terminology and keybindings which were immediately understandable and usable by all.
Given that every other application uses the standard terminology and keybindings, and that I don't see much in the way of compelling advantage to keeping the non-standard bindings other than habit, I think preserving backward compatibility for four decades was laudable but misguided.
Neither have I outside of photographs! The trouble is that they did exist previously and X11 settled on an abstracted model that supports 5 modifiers (in addition to control, shift, and lock). You have to bear in mind that Emacs can't just stop supporting certain (now defunct to the mainstream) modifiers as many users have setups which depend on them.
I suppose that cosmetically they could update the documentation by changing M- to A- or Alt- or something. Would it really make a difference though?
Aside: Not meaning to be pedantic, but at least under X11 Super is the "Windows Key" and Meta doesn't exist by default. I just checked and (on my machine) the keycap with the Windows logo maps to X11 keycode 133 (hardware specific) which produces keysym Super_L at both levels 1 and 3 which in turn maps to mod4.
I suppose that cosmetically they could update the documentation by changing M- to A- or Alt- or something. Would it really make a difference though?
Aside: Not meaning to be pedantic, but at least under X11 Super is the "Windows Key" and Meta doesn't exist by default. I just checked and (on my machine) the keycap with the Windows logo maps to X11 keycode 133 (hardware specific) which produces keysym Super_L at both levels 1 and 3 which in turn maps to mod4.
Could you explain your rationale for this configuration?
Unfortunately I didn't notice your reply earlier (the consequence of being productive).
Rereading my previous comment I've realized there are some slight inaccuracies - keybindings are conceptually a bit complicated (at least under the historical X11 model). My Alt keycap actually just produces the corresponding Alt keysym, which maps to mod1. My confusion was due to the Meta keysym also mapping to mod1 (this is the default configuration) even though no key on my keyboard is currently configured to emit it. I set everything up quite a while ago and then forgot some of the details.
* Caps Lock -> Control: This is simply more comfortable for frequent use, particularly in combination with the Vi directional keybindings (hjkl).
* Right Alt -> Level 3: AKA AltGr, this is useful for entering common Unicode characters.
* Right Control -> Compose: Useful for a number of other Unicode operations. I don't seem to make much use of it in practice though.
* Left Control -> Hyper (-> mod3): I had a free key. This gives me an extra modifier for use with things like my window manager that's pretty much guaranteed not to conflict.
* Shift + Space -> Underscore: Makes C programming _way_ nicer.
* AltGr + Space -> Nonbreaking Space: I don't actually remember why I configured this one. I never use it.
* Shift + Shift (ie left & right) -> Caps Lock: I don't actually use it, but this way it's still available.
Rereading my previous comment I've realized there are some slight inaccuracies - keybindings are conceptually a bit complicated (at least under the historical X11 model). My Alt keycap actually just produces the corresponding Alt keysym, which maps to mod1. My confusion was due to the Meta keysym also mapping to mod1 (this is the default configuration) even though no key on my keyboard is currently configured to emit it. I set everything up quite a while ago and then forgot some of the details.
* Caps Lock -> Control: This is simply more comfortable for frequent use, particularly in combination with the Vi directional keybindings (hjkl).
* Right Alt -> Level 3: AKA AltGr, this is useful for entering common Unicode characters.
* Right Control -> Compose: Useful for a number of other Unicode operations. I don't seem to make much use of it in practice though.
* Left Control -> Hyper (-> mod3): I had a free key. This gives me an extra modifier for use with things like my window manager that's pretty much guaranteed not to conflict.
* Shift + Space -> Underscore: Makes C programming _way_ nicer.
* AltGr + Space -> Nonbreaking Space: I don't actually remember why I configured this one. I never use it.
* Shift + Shift (ie left & right) -> Caps Lock: I don't actually use it, but this way it's still available.
Thanks! I like the underscore idea. First time I've seen it. (As you can see I'm not the fastest replier myself. ;-)
"M = Alt", "C = Control" is such a trivial thing to remember, yet it is brought up as a critical emacs deficiency every time. Why isn't this argument brought up in every Mac/PC discussion, or Xbox versus playstation?
There's some bad stuff in emacs but to concern yourself with Meta as opposed to M- is plain silly.
> if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should
Yes, but it's incredibly difficult and frankly the emacs devs have enough to do (and they do it well), and UI design is a very different skillset from programming. Frankly the learning curve for emacs is not going to improve, muchas we both might wish it.
The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
> if you can make a tool more learnable for new users without sacrificing its optimization for power users, you should
Yes, but it's incredibly difficult and frankly the emacs devs have enough to do (and they do it well), and UI design is a very different skillset from programming. Frankly the learning curve for emacs is not going to improve, muchas we both might wish it.
The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
> The biggest problem is people want the benefits of freely downloadable software but mainly aren't prepared to give anything back. Go and assist with emacs or some other project.
I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributions.
If you don't recognize Josh's name, you can get an idea of some of what he's done from his website, which is linked in his bio: https://joshtriplett.org/
> I work on Linux, primarily on the RCU subsystem and on Sparse-related code. I maintain the rcutorture test module.
> I co-maintain the X C Binding (XCB). I developed the XML-XCB format to describe the X Window System protocol. I also work on other Xorg projects on Freedesktop.org.
> I maintained the Sparse semantic parser and static analysis tool for C for several years, before passing it on to Christopher Li.
> I maintain several packages in the Debian project.
I don't really buy this line of argument in general, but I think Josh is a particularly poor candidate to pull rank on because they don't contribute to open source. I don't know Josh, but I recognize his name from his open source contributions.
If you don't recognize Josh's name, you can get an idea of some of what he's done from his website, which is linked in his bio: https://joshtriplett.org/
> I work on Linux, primarily on the RCU subsystem and on Sparse-related code. I maintain the rcutorture test module.
> I co-maintain the X C Binding (XCB). I developed the XML-XCB format to describe the X Window System protocol. I also work on other Xorg projects on Freedesktop.org.
> I maintained the Sparse semantic parser and static analysis tool for C for several years, before passing it on to Christopher Li.
> I maintain several packages in the Debian project.
Consider me very regretful indeed. Most people who moan seem to have nothing to contribute, well I got it very wrong this time. Apologies to @JoshTriplett if you're reading this, and Ill check out your stuff tomorrow.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
Ah shit, I recognise your name too. I've just been spanked by Dan Luu. This has not been a good night.
I appreciate the sentiment. I would gently suggest focusing the regret on the message rather than the recipient; it wouldn't have been better if written to a novice user.
Heh. My website is drastically outdated (by a decade), but thank you nonetheless.
> it's incredibly difficult
Right. I see this point ignored very frequently (sometimes because it's obvious and sometimes because people are being dumb).
A lot of the things that would make emacs more like other editors are extremely difficult to retrofit. I expect there is still SOME low-hanging fruit, but a lot of the low-hanging fruit has already been picked, and a lot of the remaining changes that people would like are a lot of work.
Right. I see this point ignored very frequently (sometimes because it's obvious and sometimes because people are being dumb).
A lot of the things that would make emacs more like other editors are extremely difficult to retrofit. I expect there is still SOME low-hanging fruit, but a lot of the low-hanging fruit has already been picked, and a lot of the remaining changes that people would like are a lot of work.
Let's discuss that. Emacs is so flexible it should be possible to do anything. Binding cut/copy/paste functionality to the conventional keys would be trivial. A few rebound key bindings, not a problem, so you're getting at something larger; what is it?
BTW the current key bindings are so good because I can do a lot without my hands leaving the keyboard, or even moving off the home keys. That was the very point of choosing them originally AFAIK. I recall learning these new keys many years ago, it was surprisingly fast and when I'd learnt them, amazingly quick to sink into muscle memory.
BTW the current key bindings are so good because I can do a lot without my hands leaving the keyboard, or even moving off the home keys. That was the very point of choosing them originally AFAIK. I recall learning these new keys many years ago, it was surprisingly fast and when I'd learnt them, amazingly quick to sink into muscle memory.
Unfortunately the rest of the software world settled on keybindings for cut and copy that generate almost the greatest possible pain for Emacs to migrate to them. C-c and C-x are used for dozens of the most important commands. It's technically feasible, but switching would be hard and existing users would be really upset.
I assure you I'd never propose to change emacs bindings at all, merely have a switchable alternate set. I think that would be possible? But even if you did so, there's too much else, far deeper that couldn't be amended. I think we agree it's not a credible proposition. I suspect emacs' enormous toolkit can't be exposed consistently without making it inconsistent. I can live with emacs as it is, very happily.
I misread what you were saying, sorry. Too late to delete other post, please ignore it.
> Go and assist with emacs
I have a freaking book to write...
I have a freaking book to write...
You can absolutely do both.
In VSCode, if I don't know how to perform an action, I just hit Ctrl+Shift+P and the fuzzy search panel with all the possible action shows up, with the associated keyboard shortcut next to it so I can remember it for next time.
In emacs, I have absolutely no idea how to discover features, and if I find something I still have to understand what the M- and C- mean
In emacs, I have absolutely no idea how to discover features, and if I find something I still have to understand what the M- and C- mean
> In emacs, I have absolutely no idea how to discover features
The built-in "help" functionality[1] is really great. C-h a will find useful documentation for what you need 90% of the time, and the manual is there for most of the rest. It's particularly useful for keybindings - C-h w for "what's the keyboard shortcut for this command" and C-h k for "what command does this keyboard shortcut run.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/He...
The built-in "help" functionality[1] is really great. C-h a will find useful documentation for what you need 90% of the time, and the manual is there for most of the rest. It's particularly useful for keybindings - C-h w for "what's the keyboard shortcut for this command" and C-h k for "what command does this keyboard shortcut run.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/He...
When it was written, there were no widespread GUIs. Standardized keyboard layouts on computers were just starting to be a thing. Many of its users were using terminals, not workstations or PCs. So they adopted, and probably more often invented, terminology and conventions for a world that predated almost everything people today know and understand.
So it's not user-hostile, it's just really old. The knee-jerk answer would be 'well just update the conventions/terminology'. The problem is, update it to what? There is no timeless terminology they can use. As the tech industry increasingly resembles the fashion industry, they'd need to slap a new coat of UI paint on it at least every 10 years to keep up... as what was 'user friendly' terminology today won't be in not too many years. So now the developers are spending a big chunk of their time 'modernizing' it rather than actually making it better... not something most developers are interested in doing for a passion project.
So it's not user-hostile, it's just really old. The knee-jerk answer would be 'well just update the conventions/terminology'. The problem is, update it to what? There is no timeless terminology they can use. As the tech industry increasingly resembles the fashion industry, they'd need to slap a new coat of UI paint on it at least every 10 years to keep up... as what was 'user friendly' terminology today won't be in not too many years. So now the developers are spending a big chunk of their time 'modernizing' it rather than actually making it better... not something most developers are interested in doing for a passion project.
> So it's not user-hostile, it's just really old.
Expecting people to adapt to 1984 - which, just a reminder folks, is more than 30 years ago - rather than updating your documentation and maybe some keybindings to better reflect today is in fact incredibly fucking user hostile.
Expecting people to adapt to 1984 - which, just a reminder folks, is more than 30 years ago - rather than updating your documentation and maybe some keybindings to better reflect today is in fact incredibly fucking user hostile.
> Many of its users were using terminals
Perhaps an example will be more vivid. In the eighties most people who were on the internet worked on a 24 line by 80 column terminal. Some people used Emacs buffers as a predecessor to multiple windows on large screens:
- Edit your code, perhaps splitting the screen in two buffers to look at different files or places in a large file.
- Split yet again one buffer for compilation error messages.
- Split the other one for a shell subprocess to run the program, check mail, etc.
Basically all-Emacs all day. Not my setup, but I saw it done often enough.
Perhaps an example will be more vivid. In the eighties most people who were on the internet worked on a 24 line by 80 column terminal. Some people used Emacs buffers as a predecessor to multiple windows on large screens:
- Edit your code, perhaps splitting the screen in two buffers to look at different files or places in a large file.
- Split yet again one buffer for compilation error messages.
- Split the other one for a shell subprocess to run the program, check mail, etc.
Basically all-Emacs all day. Not my setup, but I saw it done often enough.
> I think Emacs has been user-hostile
I don't agree. It requires a bit of learning if you are used to something else.
>I have suffered therefore the others have to suffer
This isn't true. Try, instead "I put some effort into learning it, and you can too."
Deeper understanding leads to higher productivity.
I don't agree. It requires a bit of learning if you are used to something else.
>I have suffered therefore the others have to suffer
This isn't true. Try, instead "I put some effort into learning it, and you can too."
Deeper understanding leads to higher productivity.
Ah yeah, the minutes of saved effort after pouring hours of effort into trying to understand esoteric arcane emacs-only concepts and writing some Elisp.
seriously though, it's a rabbit hole. Been there myself, now I just us vscode and it's a breeze!
seriously though, it's a rabbit hole. Been there myself, now I just us vscode and it's a breeze!
> Nobody outside a minority of devs refers to Ctrl+c as C-c.
First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).
First, C-c is not Ctrl + c; second, it really helps to use compact notation when you read a lot of keybindings; and third, this is approximately the most minor complication in the learning curve of Emacs (otherwise nobody would learn vim, with its insane key mappings and invisible mode transitions).
[deleted]
What is C-c? I have never used emacs so these comments are very confusing.
Emacs' notation for keybindings uses C for indicating the Ctrl/Cmd key and M for the Meta (alt).
Things like C-c C-v are chords. <Ctrl+c> and <Ctrl+v>.
I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
Things like C-c C-v are chords. <Ctrl+c> and <Ctrl+v>.
I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
> I might be wrong, but I believe that the reason that parent commenter said that "C is not Ctrl" is due to the fact that you can map these keys to any where you want. Most emacs and lispers prefer to have C key bound to caps lock.
Yeah, but it's still a control key. I mean, xev literally registers "Control_L" when I press the key that is physically labeled "Caps Lock".
Yeah, but it's still a control key. I mean, xev literally registers "Control_L" when I press the key that is physically labeled "Caps Lock".
C-c is a chord (two keys pressed at once); C-c C-v is a chord progression (first one chord, then the other), more often referred as a sequence in this context.
Right you are. Using Emacs for 20 years and I still can't get to explain it to people properly.
That just proves OP’s point, imo.
Were this an actual conversation where someone wants to start with emacs, I would be showing the sequences (as in "see, Ctrl-x and Ctrl-f gives you a prompt to write a file. Now try Ctrl-x and Ctrl-s...") and I would show the part of emacs that gives the user feedback about the command.
Discussions about terminology are totally secondary, and honestly, I was just trying to find a polite way to show that I don't want to get into an argument about terminology.
Discussions about terminology are totally secondary, and honestly, I was just trying to find a polite way to show that I don't want to get into an argument about terminology.
"You have to press these 2 keys at the same time" I don't understand your difficulty.
That's to avoid overstretching your pinky
On an ordinary PC keyboard with sufficient travel, you can use your palm instead of your pinky, and I highly recommend it.
It's the notation for the shortcut Ctrl+c, which would be used in windows to copy and Ctrl+v for paste.
It's written in most emacs documentation as C-c for brevity.
It's written in most emacs documentation as C-c for brevity.
Exactly what I mean. It is insane. I can't get it straight. I really tried years ago. But it is plain and simple stupid.
Words once written don't need to be abbreviated. Abbrevation is only useful when writting for speed. When writting for being read don't use them.
Words once written don't need to be abbreviated. Abbrevation is only useful when writting for speed. When writting for being read don't use them.
I think that is wrong actually.
I find it harder to scan my eyes over Ctrl+Alt+a than C-M-a (notice that Apple, too, uses single glyphs for modifier keys).
I find it harder to scan my eyes over Ctrl+Alt+a than C-M-a (notice that Apple, too, uses single glyphs for modifier keys).
I've used macOS for ten years now and I'm still regularly confused by Apple's modifier key glyphs.
Those aren't "Apple's glyphs", they're part of the ISO/IEC 9995 standard for common keyboard layouts. https://en.wikipedia.org/wiki/ISO/IEC_9995 Perhaps Emacs and the Linux desktop should start using these characters by default, seeing as they now have good Unicode support.
Control and Option/Alternate are different. Most keyboards and most software don't use either set.
microcolonel(2)
My keyboard doesn't have a 'ctrl' key, it has 'control'. I don't know why removing all the vowels from the word is considered more 'correct' than referring to the key by the first letter. Both 'C-' and 'Ctrl+' are ways of shortening the word.
It also takes what, five minutes to get accustomed to? Even old dogs can learn this new trick.
It also takes what, five minutes to get accustomed to? Even old dogs can learn this new trick.
I use emacs and have for a really long time. Unfortunately, I don't recommend it to anyone because I think the costs of learning it outweigh the benefits.
When I read this article, I was surprised that my gripes don't overlap much with those listed in the article. I do really like the idea of "new user detection", which would take a user through a short configuration process if the .emacs file was missing.
I think my main gripe is async. I really love emacs for tramp, but there are so many operations that block working on all buffers while one buffer is waiting for i/o.
When I read this article, I was surprised that my gripes don't overlap much with those listed in the article. I do really like the idea of "new user detection", which would take a user through a short configuration process if the .emacs file was missing.
I think my main gripe is async. I really love emacs for tramp, but there are so many operations that block working on all buffers while one buffer is waiting for i/o.
Choosing an editor like emacs or vi is a major decision which will have long-lasting effects. I love vi, and the homerow movement keys are now hard-wired into my brain, so much so that using 'normal' applications is noticeably frustrating. Sure, I can try to add plugins to everything, but that only goes so far and requires a lot of setup work on every new computer or VM. That said, the old school editors bring plenty to the table for programmers if you take the time to learn them well.
Honestly emacs sounds wonderful on many levels, but I learned vi first and I think that will keep me from ever switching. There's probably a vi-mode for emacs I guess... anyone have any comments on that?
Honestly emacs sounds wonderful on many levels, but I learned vi first and I think that will keep me from ever switching. There's probably a vi-mode for emacs I guess... anyone have any comments on that?
I’m also a long time vim user. I basically cannot edit text without vim keybindings these days.
A few weeks back I decided to give emacs a third try, after installing it once a while ago and giving up, installing it again with spacemacs a bit later and giving up when I couldn’t figure out what layer of that behemoth errors were coming from or how to fix them.
Anyway, I finally decided to give it another shot with vanilla, with the first thing to do being to get evil mode working (which is vim keybindings). Getting to that point was a struggle, honestly. I felt handicapped without vim bindings, and I ran into some errors downloading packages after I added MELPA to my .emacs file. After an hour or two, I managed to get evil mode going, and I guess just the little bit of familiarity in what was otherwise a VERY overwhelming and unfamiliar experience made everything feel much easier.
Getting to where it was easy to install and see the effects of new plugins one at a time rather than getting the massive overload of spacemacs was super helpful. It made the learning curve smoother for sure.
I mostly did all of this because I wanted to try org mode, and honestly that has been amazing. It’s a very very good way of taking notes and tracking tasks. I’ll probably spend some time next time I’m feeling like tinkering trying to get it more like an IDE, but for now I’m happy just with org mode.
A few weeks back I decided to give emacs a third try, after installing it once a while ago and giving up, installing it again with spacemacs a bit later and giving up when I couldn’t figure out what layer of that behemoth errors were coming from or how to fix them.
Anyway, I finally decided to give it another shot with vanilla, with the first thing to do being to get evil mode working (which is vim keybindings). Getting to that point was a struggle, honestly. I felt handicapped without vim bindings, and I ran into some errors downloading packages after I added MELPA to my .emacs file. After an hour or two, I managed to get evil mode going, and I guess just the little bit of familiarity in what was otherwise a VERY overwhelming and unfamiliar experience made everything feel much easier.
Getting to where it was easy to install and see the effects of new plugins one at a time rather than getting the massive overload of spacemacs was super helpful. It made the learning curve smoother for sure.
I mostly did all of this because I wanted to try org mode, and honestly that has been amazing. It’s a very very good way of taking notes and tracking tasks. I’ll probably spend some time next time I’m feeling like tinkering trying to get it more like an IDE, but for now I’m happy just with org mode.
That's how I settled things down finally, Emacs for org-mode and magit (actually spacemacs) synced with all my devices with syncthing, on mobile I use orgzly, and everything is under version control. I use Vim for everything else.
I was in your shoes about 2 weeks ago. I also learned vi first and have been using it regularly for a couple of years now but was curious about emacs. At home, I installed spacemacs which uses vi keybindings. For work due to some security stuff I went with vanilla emacs, with evil mode installed (evil also adds vi keybindings).
I spent 2 evenings picking it up and getting my dot files in order. I primarily wanted to use org mode and only use it for that at the moment, I’m still using vi for coding because of a vimrc that lets me navigate the code base at work really easily but org mode has made task tracking a joy and also it auto-prepares my agenda based on my org file. All in all, I’d say it’s a worth a shot and you also get to keep vi keybindings, which is nice.
I spent 2 evenings picking it up and getting my dot files in order. I primarily wanted to use org mode and only use it for that at the moment, I’m still using vi for coding because of a vimrc that lets me navigate the code base at work really easily but org mode has made task tracking a joy and also it auto-prepares my agenda based on my org file. All in all, I’d say it’s a worth a shot and you also get to keep vi keybindings, which is nice.
Thanks, I might give that a shot. I just installed vim-orgmode to see if I could get a little emacs goodness in vimland. I usually use a custom markup language and vim syntax definitions to keep track of my notes, so this may get me to convert my notes to org mode.
The thing I'm most excited about is shell-mode. For years I've wanted to be able to drop to a shell in vim and visually cut/paste the window. From what I hear, emacs can handle that.
The thing I'm most excited about is shell-mode. For years I've wanted to be able to drop to a shell in vim and visually cut/paste the window. From what I hear, emacs can handle that.
> For years I've wanted to be able to drop to a shell in vim and visually cut/paste the window.
NeoVim is 100% compatible and has a pretty decent terminal buffer with full (read-only) Vim controls. Nowadays I prefer running it in a terminal multiplexer though.
Emacs' terminal mode doesn't have ncurses support which leads to pretty much all interactive terminal applications to break.
NeoVim is 100% compatible and has a pretty decent terminal buffer with full (read-only) Vim controls. Nowadays I prefer running it in a terminal multiplexer though.
Emacs' terminal mode doesn't have ncurses support which leads to pretty much all interactive terminal applications to break.
There are a few shell modes in Emacs. I think ansi-term might do what you want for a full screen interactive terminal application.
I tried all 3 terminals I could find and none works. Apparently they all use the same ancient base that was developed before interactive terminal UIs were a thing.
ncurses programs absolutely do work with ansi-term, which is a terminal emulator. They don't work with eshell, which is not a terminal emulator.
You might want to update your vim installation and check out `:help terminal`.
One thing I learned last year is to keep all my notes in markdown. I don't like it, I prefer my own markup, but many apps support it, which increases its usefulness a lot.
One thing I learned last year is to keep all my notes in markdown. I don't like it, I prefer my own markup, but many apps support it, which increases its usefulness a lot.
I spent two weeks around last christmas seriously trying out and configuring Emacs as a Vim user, from the ground up. It took me those full two weeks to actually get to where I wanted.
So it is possible to get Emacs to (mostly) behave like Vim, but it includes installing a couple plugins, spending time to set many additional keyboard shortcuts(especially when you have an extensive .vimrc already) and also completely ripping out and replacing Emacs' automatic indentation functionality because I find its behaviour actively counterproductive.
My two cents are that if you're really comfortable with Vim's or Emacs' approach you may not like the other one, simply because their main difference is that approach to doing the exact same things. And the improvements will certainly not be proportional to the time invested.
So it is possible to get Emacs to (mostly) behave like Vim, but it includes installing a couple plugins, spending time to set many additional keyboard shortcuts(especially when you have an extensive .vimrc already) and also completely ripping out and replacing Emacs' automatic indentation functionality because I find its behaviour actively counterproductive.
My two cents are that if you're really comfortable with Vim's or Emacs' approach you may not like the other one, simply because their main difference is that approach to doing the exact same things. And the improvements will certainly not be proportional to the time invested.
I keep on typing :wd or :wqa on finishing whatever prompt I'm typing into.
AEMACS would be the winner for me. Asynchronous Editor Macros.
I've used emacs for maybe 18 months solid. I never found it had a single feature that my other editors didn't have (not saying it doesn't, just staying I didn't run into them).
My other editors can be extended via scripts. My other editors (mostly) have keyboard macros, repeat, etc.. My other editors can be used efficiently keyboard only. My other editors debug various languages. My other editors open shells in the editor. I don't care about org mode, I care about editing code.
Conversely many other editors do their best to be dev env aware, reading/understanding/integrating various language environment project files, which was never something I found in emacs (maybe it's all been added since I my emacs times)
About the only thing I still would consider using emacs for is editing in a shell remotely but (a) usually it's not already installed and (b) usually I'm not editing anything serious remotely.
What's special about emacs? What am I missing that's not in other editors?
My other editors can be extended via scripts. My other editors (mostly) have keyboard macros, repeat, etc.. My other editors can be used efficiently keyboard only. My other editors debug various languages. My other editors open shells in the editor. I don't care about org mode, I care about editing code.
Conversely many other editors do their best to be dev env aware, reading/understanding/integrating various language environment project files, which was never something I found in emacs (maybe it's all been added since I my emacs times)
About the only thing I still would consider using emacs for is editing in a shell remotely but (a) usually it's not already installed and (b) usually I'm not editing anything serious remotely.
What's special about emacs? What am I missing that's not in other editors?
Emacs is not an editor, it is rapidly-programmable-at-runtime-evolvable software that is designed to:
+ Help you realize how _you_ best deal with information.
+ Help you manifest your realization through _rapidly_ molding Emacs into your conceived model.
It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today:
It is not easy today to come to terms with a tool that's simply designed to help you craft a computing experience, since we've been so conditioned to expect somebody else's model be there from the beginning:
https://xristos.sdf.org/why-emacs.txt
+ Help you realize how _you_ best deal with information.
+ Help you manifest your realization through _rapidly_ molding Emacs into your conceived model.
It is also the closest thing we have today to the Lisp Machine paradigm. I wrote this earlier today:
You'll get the most out of Emacs if you treat it as an
investment and put in the time to learn at least some Emacs
Lisp so that you can confidently explore and customize the
rest of the system. You don't need to become an expert
overnight, just learn enough to navigate the system (which
is self-documenting and geared towards helping you perform
that navigation).
It is not easy today to come to terms with a tool that's simply designed to help you craft a computing experience, since we've been so conditioned to expect somebody else's model be there from the beginning:
https://xristos.sdf.org/why-emacs.txt
At what point does this get in the way of your programming? If there's always more to learn about the tool, I think that would bother me.
I would like to like emacs, but the couple times I tried it it gets in the way because I don't know it well enough. Vim seems more appealing because there is less to know up-front, but it is still extensible
At the point where you find yourself dinking with Emacs and making excuses to yak shave instead of getting your work done -- which, given that it's Emacs and makes most other tools seem positively stone-knives-and-bearskins by comparison, is in practice a quite tempting trap to fall into.
The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.
Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.
Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.
Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.
The best way to approach things is incrementally. Find some pain point in your current workflow and write a little bit of Elisp to automate the painful bits. Let's say you're running manual UI tests and then eyeball-grepping the logs in your backend. "But nobody does that!" you say. "Why would anybody do that?" Heh. You'd be surprised. Anyhoo, thr crank has to be turned on a prod deploy by COB Friday and you've got no time to investigate Nightwatch or the other UI-testing libraries out there, let alone integrate them with a log watcher.
Thankfully you're an Emacs user! So you write a little Elisp to start the back end, capture its output in a buffer, and count the number of occurrences of the log cookie that represents a successful (or failed) row insert, etc. You haven't automated your whole process, but you've automated part of it, and that's saved you considerable pain. And it took maybe half a page of Lisp, if that.
Recently I was confronted with an ancient web service whose only integration test process was "manually hit the endpoints with Postman, then check to make sure the records hit the database". So I wrote Emacs Lisp code to send the requests, run the queries, and even manage the Docker container where the service lived. This let me run the whole process much faster with a few M-x commands. It was nothing fancy, either, I just wrote code to spin up curl, Docker, and SQL*Plus and capture and examine their output, sort of using Emacs as a powerful full-screen shell. Rather than get in my way, it became a versatile tool I could apply to the task to get things done much faster.
Again, this is the difference between an extensible editor and a completely malleable one. VSCode, JetBrains, or Eclipse cannot be extended as incrementally and on-the-fly as Emacs.
I can understand that. I just like to tinker too much :). Going at it with a goal in mind would be a good idea
I've been using and programming Emacs for ~12 years. After all this time, I am at the level where it really feels like an extension of myself, almost like a cybernetic extra sense that I can put to use as I see fit.
Practically, as I go about my daily programming, if I feel something is off and could be improved, I have a pretty accurate idea of how long it'll take for me to implement it. Usually it's not that long and frequent 10-15 minute diversions of this sort happen multiple times a day. It simply means that the process works as expected, I'm approximating an ideal -temporal- mind model.
A few times a month, I'll do more extensive work, focusing on a number of long-term projects or exploring various ideas I've had and put down in my notes. All this work is geared around helping me manage information more effectively. I'm an information junkie, hopelessly addicted to the Internet and that's by choice. I wouldn't give it up for nothing.
Emacs is the tool that makes the difference since this continuous feedback loop of me adapting Emacs to help me deal with more and more information, allows me to keep up. Being an information consumer is easy today, you simply sit back and absorb what's being blasted at you. Being plugged into numerous signal sources and managing that information _on your own terms_ is the tricky bit and where Emacs shines while most other tools fall flat, since they're either too constrained or lack the necessary programmability.
A few times a month, I'll do more extensive work, focusing on a number of long-term projects or exploring various ideas I've had and put down in my notes. All this work is geared around helping me manage information more effectively. I'm an information junkie, hopelessly addicted to the Internet and that's by choice. I wouldn't give it up for nothing.
Emacs is the tool that makes the difference since this continuous feedback loop of me adapting Emacs to help me deal with more and more information, allows me to keep up. Being an information consumer is easy today, you simply sit back and absorb what's being blasted at you. Being plugged into numerous signal sources and managing that information _on your own terms_ is the tricky bit and where Emacs shines while most other tools fall flat, since they're either too constrained or lack the necessary programmability.
> I've been using and programming Emacs for ~12 years. After all this time, I am at the level where it really feels like an extension of myself...
The problem is that these days, you could use vscode or atom for a month or two, and get that same feeling. Emacs from scratch is not a great use of time anymore.
The problem is that these days, you could use vscode or atom for a month or two, and get that same feeling. Emacs from scratch is not a great use of time anymore.
Maybe so, but the ceiling with those tools is very low. I simply can not do what I do every day with Emacs using vscode or atom. I know why you compared them, but I feel that these comparisons are meaningless. A category error.
Emacs is simply something else.
Emacs is simply something else.
What are some examples? I'd say the ceiling is marginally lower (maybe) than emacs, but the learning curve to extend is orders of magnitude more approachable.
And I'm not sure the ceiling is actually lower.
And I'm not sure the ceiling is actually lower.
Almost everything I do on the computer happens inside Emacs, using programs written in Emacs Lisp:
Writing code, reading/sending email across ~30 email accounts spread out over different services, reading newsgroups, mailing lists and RSS feeds, maintaining a presence in 7 different IRC servers with ~30 channels total, using a variety of connection methods, watching and filtering certain twitter feeds, controlling external applications through Apple Events [1], file management local and remote, remote system management, local virtual machine management, note taking, calendar, agenda, notifications, bookmarks for external applications (Chrome and Preview), password manager, version control, music playing.
I can keep going. The only programs besides the OS and Emacs I use on a regular basis are Google Chrome, Preview.app, VMWare, Calibre, mpv, bash/ssh, Unix command line tools (less and less) and my bittorrent client written in Common Lisp.
I've almost finished an Emacs Lisp controller for Chrome, allowing me to bring a lot of information (e.g. tabs) into Emacs in order to rapidly manage it on my terms. I've done the same for Preview.app. I treat it as a dumb vessel that does the rendering. The actual information (filename, metadata, current page, date etc) is extracted from it, stored and manipulated in Emacs. That way I don't rely on Apple to dictate how I'm allowed to use my computer. I can experiment with different paradigms and find the one that fits me best. Emacs is the magic that makes all of that happen.
[1] https://github.com/atomontage/osa
Writing code, reading/sending email across ~30 email accounts spread out over different services, reading newsgroups, mailing lists and RSS feeds, maintaining a presence in 7 different IRC servers with ~30 channels total, using a variety of connection methods, watching and filtering certain twitter feeds, controlling external applications through Apple Events [1], file management local and remote, remote system management, local virtual machine management, note taking, calendar, agenda, notifications, bookmarks for external applications (Chrome and Preview), password manager, version control, music playing.
I can keep going. The only programs besides the OS and Emacs I use on a regular basis are Google Chrome, Preview.app, VMWare, Calibre, mpv, bash/ssh, Unix command line tools (less and less) and my bittorrent client written in Common Lisp.
I've almost finished an Emacs Lisp controller for Chrome, allowing me to bring a lot of information (e.g. tabs) into Emacs in order to rapidly manage it on my terms. I've done the same for Preview.app. I treat it as a dumb vessel that does the rendering. The actual information (filename, metadata, current page, date etc) is extracted from it, stored and manipulated in Emacs. That way I don't rely on Apple to dictate how I'm allowed to use my computer. I can experiment with different paradigms and find the one that fits me best. Emacs is the magic that makes all of that happen.
[1] https://github.com/atomontage/osa
That speaks to the general breadth of the emacs extension/package ecosystem, which is impressive (but somehow not as impressive as you'd like), but how many of these things did you engineer yourself? And how many these things could not be implemented in modern editors? I'm not sure any couldn't be. Most already are.
Extensibility was emacs' killer feature when its main competition was vim and vimscript - that's just not the situation anymore.
Extensibility was emacs' killer feature when its main competition was vim and vimscript - that's just not the situation anymore.
Emacs main competition in the noumenal realm of ideas wasn't vim, but the commercial Lisp Machines mainly Symbolics. They were superior but technical superiority doesn't mean much in the domain of "Worse is Better" [1].
I didn't write all of the Emacs Lisp programs I mentioned, but I did go through most of them, changing the way they work to fit how I wanted to use them. This was an iterative process that is still ongoing.
What should impress you is not the breadth, but the paradigm itself as expressed in Lisp. You can probably write an IRC client in JavaScript and have it in VSCode. But that's not what I'm talking about. We're not ticking boxes down a feature list here to say "JavaScript can do that!". We're talking about a paradigm, and specifically about interactive development with a short feedback loop through Lisp which is "a difference that makes a difference" [2]. But in order to truly understand this, you have to go through the process. Philosophical truths can not be transmitted like pieces of eight.
[1] https://www.dreamsongs.com/WorseIsBetter.html
[2] http://www.informationphilosopher.com/solutions/scientists/b...
I didn't write all of the Emacs Lisp programs I mentioned, but I did go through most of them, changing the way they work to fit how I wanted to use them. This was an iterative process that is still ongoing.
What should impress you is not the breadth, but the paradigm itself as expressed in Lisp. You can probably write an IRC client in JavaScript and have it in VSCode. But that's not what I'm talking about. We're not ticking boxes down a feature list here to say "JavaScript can do that!". We're talking about a paradigm, and specifically about interactive development with a short feedback loop through Lisp which is "a difference that makes a difference" [2]. But in order to truly understand this, you have to go through the process. Philosophical truths can not be transmitted like pieces of eight.
[1] https://www.dreamsongs.com/WorseIsBetter.html
[2] http://www.informationphilosopher.com/solutions/scientists/b...
VSCode is quite restrictive in how it can be extended actually.
Atom is much better, and feels closer to Emacs in terms of allowing you to extend and modify almost every part of it.
That said, Emacs is just the king. Not only can you really just change absolutely everything, it is really easy to modify it all at run-time on the fly, which even in Atoms isn't quite so.
I had settled on Atom for a while, but the slow performance and high memory use made me switch to Emacs.
Atom is much better, and feels closer to Emacs in terms of allowing you to extend and modify almost every part of it.
That said, Emacs is just the king. Not only can you really just change absolutely everything, it is really easy to modify it all at run-time on the fly, which even in Atoms isn't quite so.
I had settled on Atom for a while, but the slow performance and high memory use made me switch to Emacs.
It doesn't get in the way at all. Once you understand what's going on, it is a huge productivity boost.
It gets in the way of your programming immediately - the friction involved in bootstrapping a viable emacs environment that unlocks all the potential everyone is always going on about, is very high.
Deep diving into emacs is not a productivity booster - its a hobby that one does for its own sake, if that's the kind of thing that floats your boat.
Deep diving into emacs is not a productivity booster - its a hobby that one does for its own sake, if that's the kind of thing that floats your boat.
Wow, and here I was using Emacs to edit (usually) text files.
"I don't care about org mode"
Thanks for specifying this and confirming my observations. My experience has been that Emacs users are much more likely than users of other text editors to be researchers and other avid note-takers who do care about tools like Org mode. For example, I have a personal knowledge base that includes several thousand Org files containing my notes.
It's not a coincidence that the creator of Org mode is an astronomy professor[1]; whereas, the majority of the most popular VS Code extensions[2] that aren't from Microsoft seem to have been created by web developers whose portfolios include no research or non-web code repos.
My point isn't to disparage the users of VS Code, but to point out that a tool like Org mode is unlikely to be developed for editors like VS Code or appreciated by the users of such editors.
When TextMate was the flavor of the month editor that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for TextMate". It never happened.
Afterwards, when Sublime Text was the flavor of the month that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for Sublime Text". It never happened.
Now that VS Code is the flavor of month, I'm waiting for an "Org mode for VS Code". But all I've seen is an unmaintained extension[3] that provides roughly 1-2% of the features of Org mode[4].
[1] https://staff.fnwi.uva.nl/c.dominik/
[2] https://marketplace.visualstudio.com/search?target=VSCode&ca...
[3] https://marketplace.visualstudio.com/items?itemName=tootone....
[4] https://orgmode.org/org.html
Thanks for specifying this and confirming my observations. My experience has been that Emacs users are much more likely than users of other text editors to be researchers and other avid note-takers who do care about tools like Org mode. For example, I have a personal knowledge base that includes several thousand Org files containing my notes.
It's not a coincidence that the creator of Org mode is an astronomy professor[1]; whereas, the majority of the most popular VS Code extensions[2] that aren't from Microsoft seem to have been created by web developers whose portfolios include no research or non-web code repos.
My point isn't to disparage the users of VS Code, but to point out that a tool like Org mode is unlikely to be developed for editors like VS Code or appreciated by the users of such editors.
When TextMate was the flavor of the month editor that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for TextMate". It never happened.
Afterwards, when Sublime Text was the flavor of the month that its users (web developers?) claimed was the best editor ever, I waited for an "Org mode for Sublime Text". It never happened.
Now that VS Code is the flavor of month, I'm waiting for an "Org mode for VS Code". But all I've seen is an unmaintained extension[3] that provides roughly 1-2% of the features of Org mode[4].
[1] https://staff.fnwi.uva.nl/c.dominik/
[2] https://marketplace.visualstudio.com/search?target=VSCode&ca...
[3] https://marketplace.visualstudio.com/items?itemName=tootone....
[4] https://orgmode.org/org.html
I'm a researcher, and I have a git repository for my notes, which I edit using markdown. It supports latex math, tables, cross links, labels, and html if I need to do anything fancy, like inserting images, videos, etc. (youtube embedded video? no problem). I can edit them from any device, and they get sync'ed everywhere via git.
I can also read them from everywhere, and markdown renders super nicely.
I take markdown over org-mode everyday. I used to use org-mode 15 years ago, but today that's pointless for me.
I can also read them from everywhere, and markdown renders super nicely.
I take markdown over org-mode everyday. I used to use org-mode 15 years ago, but today that's pointless for me.
Can you elaborate, please? How do you use latex, images and cross-links in markdown?
As others have mentioned:
* $$2^n$$ for latex, renders fine on all browsers
* ![]() for images
* []() for links, including cross-links
* $$2^n$$ for latex, renders fine on all browsers
* ![]() for images
* []() for links, including cross-links
** The link syntax is [<text to link>](<link path>), so for example [this is a link](http://google.com)
** Markdown ## Headers have an anchor with their name (e.g. `#Headers`), so you can cross-reference any other
section of any other note in the git repo by just using [see this section](./path/to/other/note.md#that-section)
cross-links is supported by some editing tools. (For example I use MacDown it does that.) It is not part of the MD spec. I do not use org-mode, but I know it well enough to admit it is unbeatable.
$$ for latex
![]() for images
[]() for links
![]() for images
[]() for links
One of Emacs' strongest points is its ability to nicely integrate things other than "just editing code" into your workflow. As the half-joke goes, it already has a mode for everything. So in that sense, your question kind of comes off as "I only care about basic features that every editor has. What am I missing?"
With that said, even if we ignore Magit and Org, and just look at dumb code/text editing, Emacs has some pretty rare niceties. I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo". The interactive insertion and inspection of unicode characters is also nifty.
With that said, even if we ignore Magit and Org, and just look at dumb code/text editing, Emacs has some pretty rare niceties. I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo". The interactive insertion and inspection of unicode characters is also nifty.
> I've gotten used to undo-tree, and now I find it sorely lacking in literally any software that can "undo".
This feature is built in to all JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.), most popular web wikis (Confluence, Notion, etc.), Google's web Office suite, and Microsoft's web office suite. It's available as a plugin for VS Code.
It's also built in to MacOS (Time Machine), Windows (File History), Dropbox, SpiderOak, and Sync, though some of those require it to be enabled and it doesn't work with keyboard shortcuts.
> The interactive insertion and inspection of unicode characters is also nifty.
When does this come in handy?
This feature is built in to all JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.), most popular web wikis (Confluence, Notion, etc.), Google's web Office suite, and Microsoft's web office suite. It's available as a plugin for VS Code.
It's also built in to MacOS (Time Machine), Windows (File History), Dropbox, SpiderOak, and Sync, though some of those require it to be enabled and it doesn't work with keyboard shortcuts.
> The interactive insertion and inspection of unicode characters is also nifty.
When does this come in handy?
Emacs will always be there for you.
Personally, I can't move because of the rich set of text editing commands. Some of it seems silly, like word transposition, or jumping over sexps. But with Emacs, it feels like it's just an extension of my mind, most of the time. I had the same feeling some time after I learned touch typing.
Personally, I can't move because of the rich set of text editing commands. Some of it seems silly, like word transposition, or jumping over sexps. But with Emacs, it feels like it's just an extension of my mind, most of the time. I had the same feeling some time after I learned touch typing.
I think it really comes down to having the patience to learn how to extend your personal Emacs setup with the built in programming language: Emacs Lisp. From personal experience I can say that learning the basics of Emacs Lisp turned my relationship with Emacs from "preferred" to "nothing else measures up"
Ever other editor has a programming language for modifying it. What makes emacs special? couldn't you script all those other editors to do the same things?
I'd certainly feel my editor was amazing if I scripting 50 custom features but I wouldn't consider my editor better if I can script those same 50 features in any editor. I'd just consider the cost of switching high and not confuse that with whether one editor is better than another.
I'd certainly feel my editor was amazing if I scripting 50 custom features but I wouldn't consider my editor better if I can script those same 50 features in any editor. I'd just consider the cost of switching high and not confuse that with whether one editor is better than another.
Have you used magit? How about slime? Org mode? Other editors don’t have those
> magit
Lots of editors have git plugins. The question is, what can you do with magit that you can't do with those?
> slime
This is a pretty niche need, but sure. I would agree that people writing most Lisps (excluding Clojure) are better off using something like Emacs.
> Org mode
The fact that my editor doesn't have this is a feature for me. I want something with a clickable GUI that syncs to my phone, gives me reminders, and can be shared with coworkers when necessary.
I've recently been using ClickUp, and it's been fantastic. I can run it in a window next to my editor. I'm not sure what the setup is missing that Org mode doesn't deliver, but I do know that Org mode is missing a lot that ClickUp gives me.
Lots of editors have git plugins. The question is, what can you do with magit that you can't do with those?
> slime
This is a pretty niche need, but sure. I would agree that people writing most Lisps (excluding Clojure) are better off using something like Emacs.
> Org mode
The fact that my editor doesn't have this is a feature for me. I want something with a clickable GUI that syncs to my phone, gives me reminders, and can be shared with coworkers when necessary.
I've recently been using ClickUp, and it's been fantastic. I can run it in a window next to my editor. I'm not sure what the setup is missing that Org mode doesn't deliver, but I do know that Org mode is missing a lot that ClickUp gives me.
> what can you do with magit that you can't do with those?
It's not the "what", it's the "how". Magit enables extremely fancy workflows with great simplicity, and its UI is self-discoverable and well laid-out. Magit has the best UX of any git tool.
It's not the "what", it's the "how". Magit enables extremely fancy workflows with great simplicity, and its UI is self-discoverable and well laid-out. Magit has the best UX of any git tool.
> its UI is self-discoverable and well laid-out. Magit has the best UX of any git tool.
Which others have you tried?
The way you described Magit is exactly how I would describe SmartGit and also the built-in git features of several IDEs, including the Jetbrains family and Visual Studio (although I dislike Visual Studio because it's slow).
Which others have you tried?
The way you described Magit is exactly how I would describe SmartGit and also the built-in git features of several IDEs, including the Jetbrains family and Visual Studio (although I dislike Visual Studio because it's slow).
The main ones I've used for some time are the git CLI (which should be counted as a git toolset too), Sourcetree, the GUI inside IntelliJ, and Magit. I currently use Magit + the git CLI for some quick commands.
For me, Magit code staging is the best I've tried: staging whole files is as easy as staging single lines, which means my commits are more meaningful. Magit also allows me to use some fancy features without having to remember they exist, thanks to the well-thought command popups. Last, it's integrated with Emacs: this means I can move through code and write my commit messages in a familiar, coherent way.
The final advantage for me is that Emacs and Magit are forever. They will live longer than any other tool out there.
For me, Magit code staging is the best I've tried: staging whole files is as easy as staging single lines, which means my commits are more meaningful. Magit also allows me to use some fancy features without having to remember they exist, thanks to the well-thought command popups. Last, it's integrated with Emacs: this means I can move through code and write my commit messages in a familiar, coherent way.
The final advantage for me is that Emacs and Magit are forever. They will live longer than any other tool out there.
> The fact that my editor doesn't have this is a feature for me. I want something with a clickable GUI that syncs to my phone, gives me reminders, and can be shared with coworkers when necessary.
Check out Orgzly from F-droid repos.
Check out Orgzly from F-droid repos.
OK, I checked it out. I'm still not seeing reminders integrated with the notifications on my phone, nor am I seeing anything that the people on my marketing team would touch with a 10-ft pole.
There are lots of tools I'd use if I weren't programming for work and didn't have a team of mixed technical skills, and perhaps Emacs fits into that category.
There are lots of tools I'd use if I weren't programming for work and didn't have a team of mixed technical skills, and perhaps Emacs fits into that category.
A shame Stallman put the kibosh on QT quickly. Is he planning on there being a GPLv4? Not in the "leaving that option open for the future" kind of planning, but more, "A need has been identified that can't be met by v3, it's time to start working on v4." Because if they truly want a cross platform visual interface, AFAICT, QT is the closest you're going to get, and IMO, is the best means of doing so. Every QT app I've seen has looked and acted a lot closer to a native app on Windows and Mac than anything that ever came out of GTK or other GUI toolkits. And I don't understand why GTK doesn't have the same issues. It's not a GNU project AFAIK. It can't be a GPL vs LGPL thing, because QT is also available under LGPL. Is Stallman perhaps just stuck on the fact that QT was once not available under a free license?
Qt is licensed under GPLv2 or GPLv3, while GTK is LGPLv2.1+. If the FSF makes a GPLv4, GTK will automatically be available under that license, while Qt will not.
> If the FSF makes a GPLv4, GTK will automatically be available under that license, while Qt will not.
If that were the case, then why was GTK not updated to GPL or LGPLv3 when the FSF came up with that group of licenses?
When I looked it up, I found that QT is available under LGPLv3[1], so unless there is already plans to ensure that a GPLv4 is not license compatible with LGPLv3, I don't buy it.
1. https://doc.qt.io/qt-5/lgpl.html
If that were the case, then why was GTK not updated to GPL or LGPLv3 when the FSF came up with that group of licenses?
When I looked it up, I found that QT is available under LGPLv3[1], so unless there is already plans to ensure that a GPLv4 is not license compatible with LGPLv3, I don't buy it.
1. https://doc.qt.io/qt-5/lgpl.html
> A need has been identified that can't be met by v3, it's time to start working on v4.
Software-as-a-service under GPLv3 isn't required to provide source code to remote users (AGPL acommplishes exactly nothing in this regard), so there definitely is such a need, but I don't know if RMS is actually working on that.
Software-as-a-service under GPLv3 isn't required to provide source code to remote users (AGPL acommplishes exactly nothing in this regard), so there definitely is such a need, but I don't know if RMS is actually working on that.
I thought that's exactly what AGPL was for. Is there something flawed about it?
Well, the biggest problem is that the AGPL isn't the GPL, so the existence of the AGPL doesn't actually help with the large number of existing GPL projects, even if they're licenced as "GPL version N or later" (which v4 would help with).
However, the problem I was actually thinking of ("exactly nothing"), was that last time I looked into it, the consensus appeared to be that you could copy code between a AGPL project and a GPL one, which obviously makes the AGPL useless. But, on checking, I can't actually find a citation for this, and the licence text doesn't seem to support that interpretation.
So I have to retract my previous statement and amend it to: the AGPL does very little to help with SaaS attacks on open source software, primarily because almost noone uses it, and because the FSF continues to recommend the known-broken non-affero GPL as its default copyleft licence.
However, the problem I was actually thinking of ("exactly nothing"), was that last time I looked into it, the consensus appeared to be that you could copy code between a AGPL project and a GPL one, which obviously makes the AGPL useless. But, on checking, I can't actually find a citation for this, and the licence text doesn't seem to support that interpretation.
So I have to retract my previous statement and amend it to: the AGPL does very little to help with SaaS attacks on open source software, primarily because almost noone uses it, and because the FSF continues to recommend the known-broken non-affero GPL as its default copyleft licence.
I think they dont use QT because they already have native windows, mac, X11 and GTK ports, why would they use qt?
> And I don't understand why GTK doesn't have the same issues. It's not a GNU project AFAIK.
Iirc GTK was born out Gnome, and Gnome was born as a FSF-project.
Iirc GTK was born out Gnome, and Gnome was born as a FSF-project.
GTK is the Gimp ToolKit originally, predating GNOME as far as I know.
GTK came from the Gimp, not Gnome.
Okay, but even if GTK is a GNU project or a FSF project, why does that mean it qualifies for being part of a future GPLv4 licensed EMACS, and QT does not? Both are available under the LGPL. I wonder if Stallman expects that a GPLv4 would likely or definitely be incompatible with LGPL3. I don't think it's because the LGPL version would be bumped if a v4 came out; GTK is still on LGPLv2.1
It is because of the license. GTK's license is LGPLv2.1 or later[0]. The important part is later, It means you can update it automatically to any later version, especially if the new license is not compatible with the previous version. Qt does not offer their software with a similar license.
[0]: https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-t...
[0]: https://gitlab.gnome.org/GNOME/gtk/-/tree/master#licensing-t...
Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim.
I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."
The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.
If I were working on Emacs, my #1 goal would be to beat Vim on startup time--to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.
Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! https://lwn.net/ml/emacs-devel/[email protected]...
EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.
I think it comes down to performance, especially startup time. Emacs developers have never cared much about it, and I think that's connected to its reputation for "bloat."
The death knell rang when Linux distros stopped distributing Emacs by default; Emacs isn't installed by default on Ubuntu or Fedora, say nothing of macOS or the Windows Subsystem for Linux.
If I were working on Emacs, my #1 goal would be to beat Vim on startup time--to get the first page of text to show up faster than Vim--and my #2 goal would be to convince the major distros to include Emacs by default.
Sadly, I don't think any of this will happen. Stallman is too far out of touch, not just with newbies, but even with active users of Emacs. As the article points out, he's never even used Org mode! https://lwn.net/ml/emacs-devel/[email protected]...
EDIT: I know you can do some non-default techniques to make Emacs start faster. But that won't get Emacs to be installed by default on popular distros. Installing more plugins won't make Emacs the quickest and easiest way to edit a file.
As a regular emacs user, I can tell you that start-up time is one of the lowest things on my priority list of things that I wish would be improved.
Emacs is not vim. Emacs is not designed to be a program you open for every file. Emacs is and IDE. You open it every time your computer starts, and then you go to Emacs and find files from there. Occasionally, you'll have a file and want to look at it, and then you'll use client mode to have it open in a new buffer in your already opened Emacs window/terminal.
I do agree that this is not the way anyone starting out would use a text editor. But if this way of using it is not comfortable to you, you'll be fighting so much of emacs that you really will have a miserable experience, regardless of startup time.
Just to hammer the point home, normally if I connect to a Linux system and want to edit a config file, I would do the following: either `sudo vim /etc/hosts` or `emacs` and `C-x C-f /sudo::/etc/hosts`. I don't think too many people would run `sudo emacs /etc/hosts`.
Emacs is not vim. Emacs is not designed to be a program you open for every file. Emacs is and IDE. You open it every time your computer starts, and then you go to Emacs and find files from there. Occasionally, you'll have a file and want to look at it, and then you'll use client mode to have it open in a new buffer in your already opened Emacs window/terminal.
I do agree that this is not the way anyone starting out would use a text editor. But if this way of using it is not comfortable to you, you'll be fighting so much of emacs that you really will have a miserable experience, regardless of startup time.
Just to hammer the point home, normally if I connect to a Linux system and want to edit a config file, I would do the following: either `sudo vim /etc/hosts` or `emacs` and `C-x C-f /sudo::/etc/hosts`. I don't think too many people would run `sudo emacs /etc/hosts`.
We agree completely. Neither Emacs users nor developers care about start-up time or size on disk.
And that's why Vim is installed by default on Linux distros (and macOS and WSL) and Emacs isn't. And that's partly why people learn Vim before they learn Emacs.
And that's why Vim is installed by default on Linux distros (and macOS and WSL) and Emacs isn't. And that's partly why people learn Vim before they learn Emacs.
Not quite. vim is installed because vi is required by the POSIX standard and vim is the GNU version of vi. For the same reason, ed is still installed by default. It has nothing to do with popularity.
Yes, we are probably in agreement on that point. We probably disagree on whether we should care about start-up time.
We probably also disagree on what exactly it means to learn Vim before learning Emacs. I've been using Vim as a console editor far before I knew Emacs existed, but I have no idea how to use Vim for anything more than basic editing. Choosing an editor to learn as your development environment (which is what I would consider 'learning Emacs/vim/etc' actually means) is unlikely to be a decision you take based on system defaults. You are far more likely to learn the editor/IDE that your mentors use, whether that is Vim or Emacs or, as was my case originally, Borland Turbo C. Alternatively, when you are experienced enough to make a conscious choice of editor to invest in learning and customizing, your criteria will be more varied, but still likely not depend that much on system defaults.
We probably also disagree on what exactly it means to learn Vim before learning Emacs. I've been using Vim as a console editor far before I knew Emacs existed, but I have no idea how to use Vim for anything more than basic editing. Choosing an editor to learn as your development environment (which is what I would consider 'learning Emacs/vim/etc' actually means) is unlikely to be a decision you take based on system defaults. You are far more likely to learn the editor/IDE that your mentors use, whether that is Vim or Emacs or, as was my case originally, Borland Turbo C. Alternatively, when you are experienced enough to make a conscious choice of editor to invest in learning and customizing, your criteria will be more varied, but still likely not depend that much on system defaults.
If you use the Emacs server/client, then it is very fast to open a file from the command line. But I prefer to just open files from within Emacs. With ido-find-file, I get fuzzy path matching, which makes it fast to find whatever.
Rather than worrying about startup times, I'd have them work on including a lean set of quality of life extensions by default, like ido.
Rather than worrying about startup times, I'd have them work on including a lean set of quality of life extensions by default, like ido.
1) I bet Stallman's never used ido.
2) You already use Emacs. What would it take to get a new user to use it? It would have to be installed by default, and be the quickest and easiest way to edit a file. That means startup performance.
2) You already use Emacs. What would it take to get a new user to use it? It would have to be installed by default, and be the quickest and easiest way to edit a file. That means startup performance.
Stallman hasn't been in charge of Emacs for over a decade.
> That means startup performance.
Or the server/client setup could just be the default and the server starts at system boot.
Or the server/client setup could just be the default and the server starts at system boot.
Can you do that for all users? The server is a per-user server, isn't it?
Startup performance problems can be sidestepped with emacs daemon mode, at least in some cases.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Em...
https://www.emacswiki.org/emacs/EmacsAsDaemon
https://www.gnu.org/software/emacs/manual/html_node/emacs/Em...
https://www.emacswiki.org/emacs/EmacsAsDaemon
Vim might be hard, but besides jokes about "how to quit it", it makes much more sense than Emacs.
Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it.
Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much.
The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
Emacs key combinations are weird. Discoverability is low. Even Vim will now tell you how to quit if you Ctrl-C it.
Meanwhile I have opened Emacs and I'm trying to quit it (spoiler: Ctrl-x Ctrl-c). Some things are actually interesting and it tries to help at first but then it goes back quickly into emacs-babble that doesn't help much.
The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
> Vim might be hard, but [...] it makes much more sense than Emacs.
Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default?
Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions.
Within programming languages I think auto-completion is a must-have for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it?
To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.
Counter-point: I think emacs makes much more sense. If you start it, you can navigate a file by clicking in places. It is a GUI application, whereas I think vim is just a terminal program by default?
Emacs has a little built in tutorial (Ctrl+h t) and is quite discoverable (type Ctrl+h ? and it shows you a lot of commands you can use to find out about what functions a chord invokes or how to invoke a function with a key cord). With helm you just type a part of a function and it gives you a list of suggestions.
Within programming languages I think auto-completion is a must-have for discoverability. Otherwise I have to constantly look up stuff in the documentation. And for that company-mode is really nice, I don't know about the vim side of it but I think something like that goes against the philosophy of vim as I understand it?
To me, modal editing didn't make much sense in the beginning and for emacs the learning curve seemed less steep, so that's what I went with in the end. But clearly it must be good somehow, because so many people use and love vim! It's just not for me I guess.
Yes, in the XEmacs case it is the case, not necessarily when you're using it like VIM
(There are gui versions of VIM as well but it feels weird)
(There are gui versions of VIM as well but it feels weird)
> The case for vim is simple: a quick editing of a file when you might not have a window manager up or on a terminal.
That, and the power of its keybindings.
> I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
I think evil-mode, org-mode, dired, and magit, make a pretty compelling case for Emacs to fit into many programmer's workflows, even if it doesn't displace their code editor or IDE outright.
Though even setting up just those packages requires quite a bit of configuration.
That, and the power of its keybindings.
> I don't see many reasons to learn Emacs when VSC, Atom or other editors exist.
I think evil-mode, org-mode, dired, and magit, make a pretty compelling case for Emacs to fit into many programmer's workflows, even if it doesn't displace their code editor or IDE outright.
Though even setting up just those packages requires quite a bit of configuration.
Discoverability shoots up really higher than Vim or any tool when you use helm's M-x.
Also there is documentaion for literally all the key bindings and all the functions. You can access the code for all the functions. Emacs is much more user friendly than Vim.
Also there is documentaion for literally all the key bindings and all the functions. You can access the code for all the functions. Emacs is much more user friendly than Vim.
vim sucks too but its ubiquitous from smallest container build to IoT device.
You're confusing vim with vi. On an IoT device I'd expect to find busybox's vi implementation. Definitely not vim. Ditto for containers, either a vi implementation instead of vim, or "vim-minimal" at the most. Not a full vim install.
I currently use Emacs (with Vim keybindings) as my main editor, after oscillating between Emacs and Vim for quite a while. I think the biggest disadvantage Emacs has compared to Vim is its out-of-the-box experience. For me at least, I would say that learning to love Emacs takes a lot of effort, far more than it should. I think folks tend to mentally categorize Vim in the same basket, but I think Emacs is far, far worse at onboarding its users.
The Vim out-of-the-box experience is not exactly great (crucial features like vim-surround have to be installed as a plugin, for instance, in the terminal version there's a lot of delay on some commands, etc). But while learning the unfamiliar keybindings initially takes effort, the huge speed advantage of modal editing becomes apparent after just a few days of sticking with it, and it becomes second nature surprisingly fast, to the point where you just stop considering editors which don't have decent Vim emulation. So while I wouldn't exactly describe Vim as accessible, it gets its core idea across fairly quickly.
By comparison (and also in absolute terms), the Emacs out-of-the-box experience is horribly bad, it seems to make no effort to wow its first time users. It stubbornly sticks to a keybindings scheme that is unfamiliar to a modern audience and which, crucially, unlike Vim's keybindings offers no substantial productivity boost. All the documentation even still calls the Alt key "Meta". So you spend multiple days getting used to Emacs' keybindings scheme, only to end up roughly where you started (not much faster than before). At this point it's easy to start feeling like learning Emacs is not worth it: you've just spent days learning without your productivity increasing, and you just have to take people's word for it that, no, really, it'll get better. The main selling point of Emacs is its extendability. But this point is lost on users who aren't already convinced that they love and want to use your editor. You have to provide a good out-of-the-box experience still.
The Vim out-of-the-box experience is not exactly great (crucial features like vim-surround have to be installed as a plugin, for instance, in the terminal version there's a lot of delay on some commands, etc). But while learning the unfamiliar keybindings initially takes effort, the huge speed advantage of modal editing becomes apparent after just a few days of sticking with it, and it becomes second nature surprisingly fast, to the point where you just stop considering editors which don't have decent Vim emulation. So while I wouldn't exactly describe Vim as accessible, it gets its core idea across fairly quickly.
By comparison (and also in absolute terms), the Emacs out-of-the-box experience is horribly bad, it seems to make no effort to wow its first time users. It stubbornly sticks to a keybindings scheme that is unfamiliar to a modern audience and which, crucially, unlike Vim's keybindings offers no substantial productivity boost. All the documentation even still calls the Alt key "Meta". So you spend multiple days getting used to Emacs' keybindings scheme, only to end up roughly where you started (not much faster than before). At this point it's easy to start feeling like learning Emacs is not worth it: you've just spent days learning without your productivity increasing, and you just have to take people's word for it that, no, really, it'll get better. The main selling point of Emacs is its extendability. But this point is lost on users who aren't already convinced that they love and want to use your editor. You have to provide a good out-of-the-box experience still.
Emacs itself starts fast. Most people who use emacs have a lot of packages that load on startup or autoload files that need to be read and this makes startup slow. Maybe if saving an image were easier then things would be faster but I think most serious users don’t care because they start emacs once a week
Out of the box, Emacs is slower than vim, and this is part of the reason why Emacs isn't installed by default on distros. Serious users don't care about startup performance, but that helps to explain why Emacs isn't gaining new users. Emacs isn't the quickest and easiest way to edit a file.
You're repeating this in several places, and it's not true. See my comment about POSIX above.
Is a second vs. a half second much of a difference? I think users start noticing at about 5 seconds.
Users start noticing ~200 ms. A full second is huge.
I use vim for quick tasks because of the difference in startup time
If my emacs is a slow start, it is because I have a lot of previously opened files that it reads at startup. Otherwise, it is as quick as anything.
Interesting. How did you get it to store the list of previously opened files?
In the Emacs manual, read the "Saving Emacs Sessions" chapter (or get there from the 'desktop-save-mode' function documentation). Emacs can save and restore your current session, with opened files and windows layout, and as usual it's highly configurable.
By default it uses a global session context, but for example I configure mine to save the session locally in the directory where emacs is started. Then I can have several projects in parallel, and when I start emacs in the project top level directory it restores the session for this specific project. I also make the session saving file name machine specific, and ignored by unison for file synchronization. So the layout is specific for each machines with possible different screen setup leading to different window organizations. Just an example, you can tune it to fit your own needs --- that's the whole point of Emacs to me.
By default it uses a global session context, but for example I configure mine to save the session locally in the directory where emacs is started. Then I can have several projects in parallel, and when I start emacs in the project top level directory it restores the session for this specific project. I also make the session saving file name machine specific, and ignored by unison for file synchronization. So the layout is specific for each machines with possible different screen setup leading to different window organizations. Just an example, you can tune it to fit your own needs --- that's the whole point of Emacs to me.
What 'yaantc and 'rataata_jr said in this thread.
Not only does the desktop session remember and re-open the files, but it also remembers what frames you had open, what position on the screen and which screen the windows are on.
It is a huge convenience.
Not only does the desktop session remember and re-open the files, but it also remembers what frames you had open, what position on the screen and which screen the windows are on.
It is a huge convenience.
Startup time can actually be really good if you configure it right. Stock Emacs is about 150ms for me. There is also a portable dumper that will save your Emacs boot Image to memory for faster loading. Also check this out.
https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_e...
https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_e...
Sure, or you could use "emacs -Q," but all of those performance improvements are off by default, and it seems like they always will be. As long as that's true Vim will always be the quicker and easier way to modify a file.
-Q shouldn’t give you any better startup time than vanilla emacs.
Some distros have significant Emacs start-up configurations, which have an impact on start-up time. Using "-Q" skips this too. It's the case for Debian, so Ubuntu too I guess.
I used to use "jed" as a close to Emacs, light text editor to use for a quick edit from the shell. Nowadays I aliased jed to "emacs -nw -Q" (-nw: text mode, -Q: skip all configs), which subjectively starts instantaneously. And even a bare Emacs skipping the system an my configurations is very powerful. It also supports millions of colors with Konsole, so it's nice when reading code.
I used to use "jed" as a close to Emacs, light text editor to use for a quick edit from the shell. Nowadays I aliased jed to "emacs -nw -Q" (-nw: text mode, -Q: skip all configs), which subjectively starts instantaneously. And even a bare Emacs skipping the system an my configurations is very powerful. It also supports millions of colors with Konsole, so it's nice when reading code.
nah, just wait for the next version of systemd, I hear everything will be fixed with systemd-weyland-kitchensink-emacsd
edit: am emacs (and nvi) user. just chiming in on .1ms vs 1ms startup time arguments as a basis for anything important
edit: am emacs (and nvi) user. just chiming in on .1ms vs 1ms startup time arguments as a basis for anything important
honestly, with lsp-mode, it's pretty dang close to vscode, at least for the languages I care about. and the benefits of evil + a fully configurable editor are too much to pass up. a drop-in replacement for newcomers? no way. but if a powerful environment is valuable for you, like say if you spend a lot of time in an IDE and the shell, emacs's ability to integrate those things and a lot more is too good to pass up.
I found lsp-mode to be quite cool (recently reformatted my machine, and so decided to modernize). lsp-ui + company mode kills the input latency on any 4k display on Ubuntu tho. Input latency is now VS-Code/Atom level slow. Unbearable. Even with delay set to 0
This is much, much better on Emacs 27 with native json parsing. Once the language server is fully loaded (which can take a little while sometimes), input lag becomes insignificant again. Strongly recommend upgrading.
Mine's GNU Emacs 27.0.91 (build 1).
Thinking of switching to gccemacs for the native elisp goodness. But way too much yak shaving has been done already. I just disabled lsp-ui and lsp-company and all good.
Thinking of switching to gccemacs for the native elisp goodness. But way too much yak shaving has been done already. I just disabled lsp-ui and lsp-company and all good.
Switching from vim to emacs was a virtually seamless experience and a complete no-brainer... yet I put it off for years. Years before I finally took the plunge, I knew I eventually would. Vimscript is awful and although elisp isn't a great lisp dialect, it doesn't have to be great to be better than vimscript (which is abominable.) I shouldn't have put off the switch for so long. In retrospect I'm not even sure why I put it off for so long.
> If I were working on Emacs, my #1 goal would be to beat Vim on startup time-
With emacsclient, I don't think this is relevant. Concern about startup time certainly wasn't part of the reason why I put off switching for so long.
> If I were working on Emacs, my #1 goal would be to beat Vim on startup time-
With emacsclient, I don't think this is relevant. Concern about startup time certainly wasn't part of the reason why I put off switching for so long.
You put off learning Emacs partly because you learned Vim first. But why did you learn Vim first? Because people around you were already using Vim. Because Vim came preinstalled. Because Vim was quicker and easier to just edit a file.
Startup performance isn't about persuading fence sitters. It's about becoming the default, the option people pick without even knowing why they picked it.
Startup performance isn't about persuading fence sitters. It's about becoming the default, the option people pick without even knowing why they picked it.
In truth when I was a teenager I sat down with vim and emacs one afternoon and tried both. At the end of that day I chose vim, because I preferred the default bindings of vim. Nobody around me used either, nobody around me programmed at all, but I had read online that the pros used or or the other.
so - your 1st point of reference is vscode which is an electron app, and then you diverge getting into emacs startup time and emacs reputation for 'bloat'
this reputation by the way was 'earned' when entire computers had less memory than a typical emacs or vscode instance, and similarly, emacs likely currently uses less RAM than vscode due to afformentioned electron. Also: vi vs emacs 'bloat' wars were in reference to actual vi, not vim, which basically has the same non-core functionality as emacs (e.g. GUI widgets, editor-hosted scripting language) that was the basis for the original 'bloat' argument.
this is not very coherent.
this reputation by the way was 'earned' when entire computers had less memory than a typical emacs or vscode instance, and similarly, emacs likely currently uses less RAM than vscode due to afformentioned electron. Also: vi vs emacs 'bloat' wars were in reference to actual vi, not vim, which basically has the same non-core functionality as emacs (e.g. GUI widgets, editor-hosted scripting language) that was the basis for the original 'bloat' argument.
this is not very coherent.
I agree that VS Code is even more "bloated" than Emacs, but it has a multi-billion dollar corporation funding it. If Emacs could get that, maybe Emacs would be as popular as VS Code!
But, short of that, Emacs can't beat VS Code. Emacs could beat Vim, but only by being so fast and small that it gets installed by default on Linux distros (and macOS and WSL).
But that'll never happen, because Emacs folks prioritize features over performance. (If they cared that much about performance, they wouldn't be Emacs users!)
But, short of that, Emacs can't beat VS Code. Emacs could beat Vim, but only by being so fast and small that it gets installed by default on Linux distros (and macOS and WSL).
But that'll never happen, because Emacs folks prioritize features over performance. (If they cared that much about performance, they wouldn't be Emacs users!)
[deleted]
> its reputation for "bloat."
Eight Megs And Constantly Swapping. ;-)
Eight Megs And Constantly Swapping. ;-)
It seems that if vim is so much more popular than emacs, old fashionedness doesn't necessarily make an editor less popular.
If one believes that emacs would be more popular if it were more like some other editor that is more popular then being more like vim would make emacs more popular. Evil has existed for a long time but vim is still more popular. As much as emacs can be like vim, people still feel vim is better at being vim.
If emacs was more like VS code, would people want to use it for that reason? It seems like VS Code would always be better at being like VS Code than emacs.
Emacs has a loyal following, conceivably of millions of users? It also attracts new users who like things about it. There are packages for most languages, even very obscure ones. Being less popular than vim doesn't seem to make emacs less useful or keep new people from picking it up. It seems like emacs is a good thing according to many people as is and if its developers want to make users happy, looking at what people use emacs for and making it do that better would probably be a good idea. Making it more like other things that already exist doesn't make as much sense to me really.
I guess I don't really understand why it is important to be most popular as long as something is useful with a strong user and developer base.
If one believes that emacs would be more popular if it were more like some other editor that is more popular then being more like vim would make emacs more popular. Evil has existed for a long time but vim is still more popular. As much as emacs can be like vim, people still feel vim is better at being vim.
If emacs was more like VS code, would people want to use it for that reason? It seems like VS Code would always be better at being like VS Code than emacs.
Emacs has a loyal following, conceivably of millions of users? It also attracts new users who like things about it. There are packages for most languages, even very obscure ones. Being less popular than vim doesn't seem to make emacs less useful or keep new people from picking it up. It seems like emacs is a good thing according to many people as is and if its developers want to make users happy, looking at what people use emacs for and making it do that better would probably be a good idea. Making it more like other things that already exist doesn't make as much sense to me really.
I guess I don't really understand why it is important to be most popular as long as something is useful with a strong user and developer base.
Agreed. Emacs and Vim basically try to do the same thing with two very different approaches, and both can fit well depending on the use-case. I also get why many prefer VS Code, because spending hours to learn and configure a program just for text editing is not universally appealing. But other people just want that configurability.
> Evil has existed for a long time but vim is still more popular.
Because the behaviour isn't identical(it even has default settings that intentionally deviate!), because it isn't complete(it doesn't affect any other mode), but most importantly for me because Emacs cannot fully match Vim's keybinding functionality. I broke my Emacs configuration a dozen times before realising that.
I am glad I tried out Emacs as a Vim user though, it led to a couple improvements of my Vim configuration and I learned a couple new things.
> Evil has existed for a long time but vim is still more popular.
Because the behaviour isn't identical(it even has default settings that intentionally deviate!), because it isn't complete(it doesn't affect any other mode), but most importantly for me because Emacs cannot fully match Vim's keybinding functionality. I broke my Emacs configuration a dozen times before realising that.
I am glad I tried out Emacs as a Vim user though, it led to a couple improvements of my Vim configuration and I learned a couple new things.
I'm not an Emacs user, but with all kinds of software like this, I find that the strengths lie not in what makes it popular but what makes it lasting. If too much is changed in Emacs, scores of users will cry havoc and switch to XEmacs (or something) and it will become even less popular.
Emacs has a stable core user base and as far as I can tell, it's recently getting some traction among a new generation who are exactly the kind of users that would likely jump ship as soon as a lot of "modernization" started happening. If they wanted something "modern", they wouldn't opt for Emacs in the first place. It's not like there's a lack of choice: IDE:s and editors adhering to current trends and concepts within UI/UX design are plentiful. They have sought out Emacs because it is uniquely Emacs and not yet another Sublime/VS Code/Atom.
Editors aren't exactly comparable to desktop environments, but when Gnome 3 was conceived for similar reasons of following design trends and thinking afresh, we suddenly also had Cinnamon, MATE and Budgie instead of just KDE and Gnome. Not that I mind diversity, but it's a fine example of alienating a user base. Now, consider how conservative an Emacs user of today probably is.
I find that one of the few things I still truly enjoy about computers is that there is stubborn software left for stubborn people to use. Slackware, Emacs, fvwm, xterm... Familiarity, not innovation. That's worth something, too.
Emacs has a stable core user base and as far as I can tell, it's recently getting some traction among a new generation who are exactly the kind of users that would likely jump ship as soon as a lot of "modernization" started happening. If they wanted something "modern", they wouldn't opt for Emacs in the first place. It's not like there's a lack of choice: IDE:s and editors adhering to current trends and concepts within UI/UX design are plentiful. They have sought out Emacs because it is uniquely Emacs and not yet another Sublime/VS Code/Atom.
Editors aren't exactly comparable to desktop environments, but when Gnome 3 was conceived for similar reasons of following design trends and thinking afresh, we suddenly also had Cinnamon, MATE and Budgie instead of just KDE and Gnome. Not that I mind diversity, but it's a fine example of alienating a user base. Now, consider how conservative an Emacs user of today probably is.
I find that one of the few things I still truly enjoy about computers is that there is stubborn software left for stubborn people to use. Slackware, Emacs, fvwm, xterm... Familiarity, not innovation. That's worth something, too.
> it's recently getting some traction among a new generation
Where can I learn more about this? If I teach my kids emacs will they not be the only ones among their peers who use it?
Where can I learn more about this? If I teach my kids emacs will they not be the only ones among their peers who use it?
As someone else pointed out elsewhere in this thread, check out /r/unixporn. Kids today with their tiling wm:s and esoteric editors, eh?
Outside of the text editor, I think native emacs keybindings like (C-n, C-p, C-a, C-e, C-k) on OSX are great and I hope they never get rid of them.
Please never get rid of this
As a user of these key binding in both Emacs and macOS, it’d be worse than cutting off an arm if this went away
As a user of these key binding in both Emacs and macOS, it’d be worse than cutting off an arm if this went away
Or next-paragraph/last-paragraph movement.
Or all movement combined with prefixes. I regularly do
Separately, macros, yea! Macros with regexes FTW! The counter you can use in macros - occasionally very useful! M-x occur! Dired which can search a whole directory tree of file contents for a regexp! So much more.
Only thing worse than emacs interface is not having emacs at all.
Or all movement combined with prefixes. I regularly do
C-u C-u C-p
Separately, macros, yea! Macros with regexes FTW! The counter you can use in macros - occasionally very useful! M-x occur! Dired which can search a whole directory tree of file contents for a regexp! So much more.
Only thing worse than emacs interface is not having emacs at all.
While it's nice that macOS has this out-of-the-box, you can make all the key-bindings to their macOS equivelants using Karabiner-Elements. If it did go away, we'd be fine.
easily 50% of my "loyalty" to Macs is these built in shortcuts alone.
I agree! You know what takes it to the next level? Sticky keys!
Accessibility feature in macos where modal / control keys will "stick" for the next keypress (non-modal / control) and then release.
Double tap will stick it for the duration until the next tap on the same key.
Essentialy, double tap control key and move around with n and p keys, kill with k, move more, yank somewhere else with y. All without touching control! But there's more, you can save the buffer with x followed by s press. It takes a while to get used to but saves you awkward wrist moves. I guess it's closer to modal editing in vi, just not as advanced.
Accessibility feature in macos where modal / control keys will "stick" for the next keypress (non-modal / control) and then release.
Double tap will stick it for the duration until the next tap on the same key.
Essentialy, double tap control key and move around with n and p keys, kill with k, move more, yank somewhere else with y. All without touching control! But there's more, you can save the buffer with x followed by s press. It takes a while to get used to but saves you awkward wrist moves. I guess it's closer to modal editing in vi, just not as advanced.
Your suggestion sounds a little bit like Emacs' god-mode:
https://github.com/emacsorphanage/god-mode
https://github.com/emacsorphanage/god-mode
Or evil mode.
FWIW, native emacs keybindings are there on iPadOS and with the ability to swap caps and control in 13.4, life is sweet.
So true. It's a major thing that stops me from migrating to Linux.
Every time I work with Linux or Windows, when I open a Chrome tab and I want to go down to a history completion, I hit C-n multiple times and it ends up with many new windows...
Every time I work with Linux or Windows, when I open a Chrome tab and I want to go down to a history completion, I hit C-n multiple times and it ends up with many new windows...
Emacs is not an editor, is a personal travel to find and build your ultimate editor through the years, a solution that will work forever but only for you.
Yes, is the most powerful tool that ever existed, a beautiful monstrosity, no other editor will let you cherry-picking git commits, handle your agenda, export to PDF, measure the time for a cup of tea and estimate the new project costs. In some point Emacs becomes a part of yourself. Yes it will be loved and tamed only for us, the weirdos, and that is ok.
In 1996 all my friends were asking me why I installed and struggled so many hours with that thing called Linux, when Windows was so easy. "Nobody uses Linux", they told me. Well, Linux made me very good with DevOps tasks, and I finally learned what software is about when I discovered eLisp.
As many other things in this world, Emacs is not for all people.
Yes, is the most powerful tool that ever existed, a beautiful monstrosity, no other editor will let you cherry-picking git commits, handle your agenda, export to PDF, measure the time for a cup of tea and estimate the new project costs. In some point Emacs becomes a part of yourself. Yes it will be loved and tamed only for us, the weirdos, and that is ok.
In 1996 all my friends were asking me why I installed and struggled so many hours with that thing called Linux, when Windows was so easy. "Nobody uses Linux", they told me. Well, Linux made me very good with DevOps tasks, and I finally learned what software is about when I discovered eLisp.
As many other things in this world, Emacs is not for all people.
Please. Emacs will never be popular. Emacs does not need to be popular. Making it popular will require dumbing it down to the level of VS Code. It's doing just fine as it is, please leave it alone.
Edit: I mean, it's a complex, sophisticated, hard-to-master instrument, kind of like Organ. If you feel that popularity of your instrument matters above all (which is perfectly fine) -- just get yourself a Kazoo.
Edit: I mean, it's a complex, sophisticated, hard-to-master instrument, kind of like Organ. If you feel that popularity of your instrument matters above all (which is perfectly fine) -- just get yourself a Kazoo.
Oddly, I think you will make Emacs appealing to users when you start asserting it is appealing to users. Few changes really needed. Just stop intimidating people before they get involved.
> I think you will make Emacs appealing to users when you start asserting it is appealing to users
I've worked with a lot of Emacs fans but everyone describes it as having a hefty learning curve. If you tell people it's appealing and the first experience is unpleasant, all you're going to do is convince them that you aren't a reliable source of advice. I think it would be much better to focus on easing that initial stage and explaining it a powerful tool which requires some up-front investment.
I've worked with a lot of Emacs fans but everyone describes it as having a hefty learning curve. If you tell people it's appealing and the first experience is unpleasant, all you're going to do is convince them that you aren't a reliable source of advice. I think it would be much better to focus on easing that initial stage and explaining it a powerful tool which requires some up-front investment.
Have you ever used some of the other popular choices? Pleasant is rarely an accurate term for computer use.
And I'm not saying lie. Just stop scaring people away. Emacs is by far one of the most empowering programs out there. Market that.
She realize that it is marketing. You want to build a market of users? You have to have some marketing.
And I'm not saying lie. Just stop scaring people away. Emacs is by far one of the most empowering programs out there. Market that.
She realize that it is marketing. You want to build a market of users? You have to have some marketing.
Remember that Emacs is competing with things like Visual Studio Code, Atom, Sublime Text, etc. If you tell people that it's easy they're going to try it, bounce off, and conclude you have no idea what you're talking about. If, instead, you tell them what you like about it more than those others they might find they agree with you.
Speaking as someone that has bounced off the likes of notepad... I think you are overstating the case.
I'm not saying to merely claim it and call it a day. I'm saying claim it while showing people how to use it. Make it a dialog that doesn't begin with, our way is harder. It isn't harder. Just different.
I'm not saying to merely claim it and call it a day. I'm saying claim it while showing people how to use it. Make it a dialog that doesn't begin with, our way is harder. It isn't harder. Just different.
Exactly. Whenever a new developer asks what editor I use, I emphasize that while I use emacs, it has a huge learning curve. It has different conventions than any other text editor, because it predates those conventions.
I would like to understand why vim does not seem to have this problem? I guess as stated below, it's just they way it is marketed. Because the way I see it, emacs is much easier to start out with than vim.
If I start emacs, I can navigate around the text with the arrow keys, the way I would expect from most other text entry systems. Then I can just type stuff. I can click at points in the text to navigate there, just like in notepad or anywhere else.
OTOH in vim it is nothing like that. Nothing is even remotely familiar. Yet there are much more vim users than emacs users. So I don't buy it that the learning curve is the problem.
If I start emacs, I can navigate around the text with the arrow keys, the way I would expect from most other text entry systems. Then I can just type stuff. I can click at points in the text to navigate there, just like in notepad or anywhere else.
OTOH in vim it is nothing like that. Nothing is even remotely familiar. Yet there are much more vim users than emacs users. So I don't buy it that the learning curve is the problem.
> I would like to understand why vim does not seem to have this problem?
That’s seriously begging the question — I mean, there’s a pretty popular running joke about quitting vim and it’s been many years since I’ve heard any recommend it as easy to get started with. In the 90s people suggested it due to Emacs hitting memory constraints but most CPUs now have more cache now than those computers had.
That’s seriously begging the question — I mean, there’s a pretty popular running joke about quitting vim and it’s been many years since I’ve heard any recommend it as easy to get started with. In the 90s people suggested it due to Emacs hitting memory constraints but most CPUs now have more cache now than those computers had.
I know, people are joking about how it's not usable. But still there are a lot of people using it! So maybe it's not actually an issue for adoption, so I wonder why this argument comes up with emacs then, which, in my opinion, is OOTB not as weird as vim for someone unfamiliar with either of them.
To some degree, I agree. I've been playing with Doom Emacs[1] recently and it has been pretty smooth, the configuration and such more so than my regular Vim setup.
1: https://github.com/hlissner/doom-emacs
1: https://github.com/hlissner/doom-emacs
My experience with Emacs has been a steady upward trajectory, gaining understanding and access to functionality. I now use CIDER and TRAMP every working day, and no true equivalent exists for any other editor (though many are catching up to CIDER, due to Clojure being the better lisp!).
The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.
The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.
† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.
The biggest problems with Emacs, to me, are the rendering performance, the lack of sufficient threading, the default keyboard-accessible windowing commands, and Elisp being unergonomic and sad.
The course I'd chart for an ideal Emacs would be rendering with something like Alacritty†, some default windowing commands similar to tmux, and phasing out Elisp in favour of a Clojure dialect; the last bit would help a lot with introducing some basic sources of concurrency.
† Plus smooth scrolling surfaces, since a text editor generally does not have enough surfaces that the memory overhead of tiled surfaces is a serious issue like it is for general-purpose renderers like web browsers.
Many years ago I implemented JEmacs (http://jemacs.sourceforge.net/) - a proof-of-concept (i.e. very incomplete) port of Emacs to the Kawa framework. Kawa is primarily an implementation of a nice if-I-say-it-myself dialect of Scheme compiling to the Java VM, but it can be used to compile other languages - specifically Emacs Lisp. JEmacs is long dead but Kawa (https://www.gnu.org/software/kawa/) is still actively used and maintained. It has a number of niceties and ideas worth checking out.
While elisp has lots of warts and weirdnesses stemming from ages long ago, I find it quite suited for its task as an editor scripting language.
For instance, the global namespace is great to play with and learn commands in the scratch buffer. Also the custom datastructures and generally the emacs lisp abstractions around editing are a joy to use.
I agree though that the rendering is too old fashioned. I'd love for Emacs to get smooth, animated scrolling instead of that tty-esque line-by-line movement of the text. That really makes it hard to keep track when scrolling throught large documents.
For instance, the global namespace is great to play with and learn commands in the scratch buffer. Also the custom datastructures and generally the emacs lisp abstractions around editing are a joy to use.
I agree though that the rendering is too old fashioned. I'd love for Emacs to get smooth, animated scrolling instead of that tty-esque line-by-line movement of the text. That really makes it hard to keep track when scrolling throught large documents.
Likely a polar opposite of Clojure, but there is an attempt to add Guile (a Scheme dialect) to Emacs[1] which aims to provides a faster Elisp backend, and support for using Scheme to program Emacs.
[1]: https://www.emacswiki.org/emacs/GuileEmacs
[1]: https://www.emacswiki.org/emacs/GuileEmacs
As someone who claims to be using "the better lisp" what is it about elisp that you find "unergonimic and sad"? Genuinely curious.
At least when I've written elisp, the default datastructures have involved a lot of work to construct and manipulate, and when you do it right, the ones you've chosen for convenience may perform so poorly that you have to go back and change them to get your program to complete in time.
Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.
In Clojure, it's many little things:
Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".
The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.
Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.
I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.
Namespaces for vars and functions being not a language feature is inconvenient. Unless you are using fakespace or intern-symbol (it seems hardly anyone does), every symbol in your program needs to include its namespace information in order to avoid it being accidentally invoked by somebody else, or accidentally convincing somebody that it's part of the base distribution.
In Clojure, it's many little things:
Keywords are callable, allowing you to evaluate a keyword on an associative collection like hash-map, or traverse, in an obvious and intuitive way, into a nested associative structure with the threading macros "->" and "->>".
The default data structures are fast (for what they are) and hard to misuse: unless you ask politely, you are not going to mutate something your function was passed passed without noticing. seq, the interface for sequences (vectors, lists, pairs from an associative structure), pairs well with destructuring in let and macros/syntax that does binding.
Things like 'let' don't use more parentheses than necessary, which has a greater impact on readability than you'd think. The use of vector syntax for bindings rather than list syntax adds a little bit of syntactic texture that makes reading programs more ergonomic.
I think Clojure may not be as unfamiliar as it seems at first to a person who's written other lisps before, but I have yet to meet somebody who prefers the experience of writing Scheme or Common Lisp to Clojure; nor anyone who prefers Elisp to Common Lisp.
You should check dash[1]. It adds a lot of those "many little things" from Clojure (such as ->, and ->>, and let) to elisp.
[1]https://github.com/magnars/dash.el
[1]https://github.com/magnars/dash.el
;;; -*- lexical-binding: t -*-I like to tell the story of how secretaries in the 70s learned how to use and customize Multics Emacs with Emacs Lisp; they were told they were simply customizing their editor, not programming it.
Maybe gendered on-ramps are important for getting women into programming:
http://www.smashcompany.com/philosophy/gendered-on-ramps-are...
http://www.smashcompany.com/philosophy/gendered-on-ramps-are...
I have doubts about this. Maybe they did some simple variable settings, but I doubt they wrote proper lisp programs.
That's the really cool thing about Emacs. The only difference between "simple variable settings" and "proper lisp programs" is a difference of scale, not a difference of kind. Variable settings are just as much code as anything else in Emacs.
Indeed. (+ 1 2) is a "proper Lisp program". By having all that power available from the start, users can use as much or as little as they need and shape the tool on the fly as they work with it. It's the difference between an extensible text editor and a completely malleable one.
I tend to agree, too. It is really no worse than any other complex application, and far better documented than most.
An an occasional user of both Excel and Emacs (mainly a vi guy), I waste at least as much time figuring out where "that tool" in Excel went or how to get in to one of the weird graph editing modes as I do with the more obscure Emacs features I use sometimes.
An an occasional user of both Excel and Emacs (mainly a vi guy), I waste at least as much time figuring out where "that tool" in Excel went or how to get in to one of the weird graph editing modes as I do with the more obscure Emacs features I use sometimes.
Getting started with Emacs and having basic skills (load, save, cut, copy, paste, search) is WAY faster than with vi. I don't use more than a tiny fraction of emacs's capabilities and likely never will, but the initial part of the learning curve is way easier than it is with something like vi.
But emacs is not against vi. When I taught a class where I started by introducing emacs, the first question I got was how to make it have this color text and that hentai page background.
I generally use aquamacs when I need emacs these days (especially since Catalina no longer includes the terminal-based emacs by default). It offers a lot of customizations through menus for the appearance, not to mention that it supports standard cmd-whatever shortcuts for the basic functionality.
I wish Vim users and Emacs users would unite to improve Spacemacs. It's really a great idea IMO, have the editing power of Vim with the flexibility and elegance of the Emacs environment.
Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was right to finally make the switch to modal editing, vim feels like a clunky and hacky environment compared to the power of Emacs.
Unfortunately when I tried Spacemacs (coming from Emacs) I kept bumping on rough edges with vim command emulation which ended up with me switching directly to the real vim. It's been about a year now and while I still think I was right to finally make the switch to modal editing, vim feels like a clunky and hacky environment compared to the power of Emacs.
Vim and Emacs have too many philosophical differences for this to work. For example, emacs doesn't have a fixed concept of what a paragraph should be. Instead, it leaves that up to the major mode. This is fundamentally incompatible with vim's paragraph motions which are determined by empty lines and remain the same regardless of file type.
As a very long-time Vim user, I prefer that my editing commands be predictable since I type them with muscle memory (faster than ordinary conscious thought). Having them vary from file to file based on file type (the Emacs way) throws me off completely and makes the editor feel untrustworthy, like a horse that's liable to kick or throw its rider. Vim feels like a complete set of high quality, manual woodworking tools.
As a very long-time Vim user, I prefer that my editing commands be predictable since I type them with muscle memory (faster than ordinary conscious thought). Having them vary from file to file based on file type (the Emacs way) throws me off completely and makes the editor feel untrustworthy, like a horse that's liable to kick or throw its rider. Vim feels like a complete set of high quality, manual woodworking tools.
VIM has a text object called block that IIRC differs from filetype to filetype. I never tried but I guess you could also overwrite the ip and ap text objects for certain filetypes if you really wanted to.
Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly?
Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.
>Vim feels like a complete set of high quality, manual woodworking tools.
They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").
They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?
You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.
The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.
Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.
I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.
Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make a lot of sense to me. I think about code in lines or blocks, not paragraphs that is a rather weird concept when it comes to code. The fact that you can't easily add new motions to vim is a big limitation for me.
>Vim feels like a complete set of high quality, manual woodworking tools.
They're mostly reliable and predictable, I agree with that. High quality I'm not sure. The fact that the undo tree is effectively unusable without 3rd party plugin is weird. Tabs are at the same time over-engineered and under-featured. Nobody seems to really knows what they're for or how to use them (just make a quick search online for "vim tabs").
They're like Emacs frames except that you can't actually use them like a separate frame on a different screen. And you can't have them use a different working directories easily so they're useless to open two projects side-by-side. Some people coming from editors that open files in individual tab (an anti-pattern IMO, but that's a different discussion) expect them to work that way, but it turns out that they can't really do that either. Why even bother?
You also need plugins to do very basic coding stuff like run "make" in the background without being locked out of editing. Which wouldn't be too bad if Vim's internal API made it easy to make Vim plugins work seamlessly like native code, but in practice all the plugins have tested needed to be super intrusive to offer basic functionality (like remapping literally half the keyboard to slightly tweak the kill/yank behavior) and it ends up breaking left and right in weird and unexpected ways.
The visual feedback for commands is atrocious. Spacemacs' genius is that when you start typing commands it shows you what you can press next and what it does. You effectively navigate the bindings like menus, and you have this positive feedback loop where you memorize the bindings by using them. Sometimes I start typing a command in vim and I think I made a typo but I can't know because I have zero feedback on the current state of vim. Emacs almost always tells you what it's waiting for in the mode-line.
Why does ":bdelete" also kill the window it's in, except when there's only one window left? Since elsewhere there's no 1:1 relation between windows and buffers, you'd expect to get the next buffer in the stack (that's what Emacs does in this situation, and that's what Vim does when you have one window left). Window and buffer handling is hard but Emacs is vastly more configurable and works better out of the box in my experience.
I also often get performance issues that I don't remember ever getting in Emacs which is fairly ironic given that Vim is supposed to be the "lean" one.
Clearly my Emacs origins show here
I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.
I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.
Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.
I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.
I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.
Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.
I always find it interesting that the thing people really want from vim is the keybindings. Almost no one uses vim for the software.
Also, The vim emulation has gotten much better due to evil-collection[1]. You might want to give Spacemacs or doom-emacs[2] another try.
[1]https://github.com/emacs-evil/evil-collection [2]https://github.com/hlissner/doom-emacs
Also, The vim emulation has gotten much better due to evil-collection[1]. You might want to give Spacemacs or doom-emacs[2] another try.
[1]https://github.com/emacs-evil/evil-collection [2]https://github.com/hlissner/doom-emacs
Thanks for the evil-collection link! I hadn’t seen this before, but the sudden switch out of having vim bindings in various buffers has been one of the pain points in starting to learn emacs.
I don't think spacemacs and the vim emulation, evil, have anything to do with each other. I switched from vim to emacs a while back and haven't had any issues with evil mode.
As far as spacemacs goes it seems neat. I tried it once but it was too confusing and I've been using emacs for so long now that it's very finely tuned to what I need it to do.
As far as spacemacs goes it seems neat. I tried it once but it was too confusing and I've been using emacs for so long now that it's very finely tuned to what I need it to do.
As someone who really doesn’t “get” or care for Vim, why should I contribute to an alternate Emacs-“distro” entirely focused on an existing Vi user-base, using non-standard conventions and keybindings?
I mean good for them having that option, but what’s in that thing for me?
I mean good for them having that option, but what’s in that thing for me?
You don't have to use vim keys in Spacemacs or Doom. You can just use the regular ones if you want.
But then what does Spacemacs offer me over plain Emacs?
And I’ll also have to learn all the things it does differently. All in all, sounds like a net negative to me.
And I’ll also have to learn all the things it does differently. All in all, sounds like a net negative to me.
If you ever start to develop Emacs Pinkie as I did you may come around
Then I can enable evil-mode, instead of fully changing my setup to a unconventional Emacs-distro which does everything differently.
Again: what’s in it for me supporting this alternate Emacs universe?
Again: what’s in it for me supporting this alternate Emacs universe?
This is one of the main reasons why I stuck with Vim. The strain on my hands was very noticeable, even as I was just starting to learn the standard Emacs keybindings..
As a vim user, I use Spacemacs for Lisp. Otherwise, I don't like mode inconsistencies (e.g. vim keys don't work inside SLIME debugger), the lack of tabs and the startup/running footprint. It doesn't feel right or convenient to have many Emacs instances scattered throughout tmux or terminal windows, created and killed as needed. Now that I'm thinking about it, this and tabs help me map my work space mentally in a way that hidden buffers (or directory trees) don't.
Although there have been several tab addons for emacs for a while emacs now has native tabs that work the same as vim tabs.
You can run emacs --daemon at login and run either emacsclient to start a new window connected to an existing instance. In my measurements starting vim in a new xterm takes about 250 ms. Starting a new gui emacslient requires only 500 ms. Perhaps numerously running a new default emacs instance with emacs -Q is actually faster at 400ms.
You can run emacs --daemon at login and run either emacsclient to start a new window connected to an existing instance. In my measurements starting vim in a new xterm takes about 250 ms. Starting a new gui emacslient requires only 500 ms. Perhaps numerously running a new default emacs instance with emacs -Q is actually faster at 400ms.
i'm a major vim users (10+ years now), and honestly? i don't care about spacemacs. emacs and vim are philosophically too different to be together.
i tried spacemacs and it was like trying to fit a square peg on a round hole -- it just doesn't work properly.
i tried spacemacs and it was like trying to fit a square peg on a round hole -- it just doesn't work properly.
Speak for yourself, I used vim for a decade and have since switched full-time to spacemacs in mixed mode! :)
spacemacs layers system is clunky and yet another layer of configuration abstraction ontop of an already versatile configuration system.
Am surprised that a starting point has not been highlighted earlier: the onboarding.
To get news users using your product, you have to lower the friction. By making great docs and the environment easy to setup to get started, you can make this process easier.
Why not start with that?
I have always felt that the initial config of emacs has been painful.
Why not start with that?
I have always felt that the initial config of emacs has been painful.
I see this "Emacs is terrible, my (insert currently hyped IDE/editor) is much better" mantra every few years. These days, it is VSCode, few years ago it was atom/pycharm/intellij, before that was anything on Eclipse platform... Yet, I need to see status of any these after 40 years.
Emacs is like a turtle - it isn't flashy and trendy, looks weird and old, but is still going steadily and strongly. And I bet you'll be able to run your configuration 10 years ago, for the next 20 years without any problems.
I'd say, if you don't like Emacs, use something else. Usually everyone returns back to either Emacs, Vi(m) or Sam at some point. True hackers will go to ed - ed is the standard text editor after all :)
Emacs is like a turtle - it isn't flashy and trendy, looks weird and old, but is still going steadily and strongly. And I bet you'll be able to run your configuration 10 years ago, for the next 20 years without any problems.
I'd say, if you don't like Emacs, use something else. Usually everyone returns back to either Emacs, Vi(m) or Sam at some point. True hackers will go to ed - ed is the standard text editor after all :)
I think a large part of the issue is the default keybindings (the GUI is also bad, but I think it's bad in a way that's not going to be impossible to fix without screaming from people who like what's already there). It's truly only lacking a decent text editor.
This isn't to say that the keybindings never made sense; in the stage of computing before X, where Space Cadet-like keyboards were common, it was more than fine.
Currently, though? Entirely different era of computing.
Imagine you're walking in with no clue. You haven't heard of any of the memes, someone just recommended you a text editor. "It's really good! You'll be more productive!" You have no idea what in the world evil is, or why you would ever want it.
You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
Off to a good start, breaking the most universal keybinding across modern operating systems in the strangest way possible, and not only that, but also breaking one of the biggest implicit rules of keybindings.
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! Not only that, but it's not even consistently unintuitive!
And that's not even getting into the obvious problems that come with the placement of M and C on modern keyboards.
There are a few solutions to this, obviously, but good luck trying to find a solution that isn't universally-hated.
You could make evil the default. Controversial and only slightly helps the barrier to entry.
You could make it like the Web's model of text-editing but with quality-of-life enhancements. I think this one is probably the winner. It's definitely why Sublime/VSC/Atom won, past everything else.
The Turbo C/Wordstar approach was cool, but has no mind-share today.
You could try something new, I guess? This is dangerous territory, though.
I have no idea what the solution is, but the problem(s) seem obvious. I say this all as a person who really likes Emacs. I even still have most commands memorized despite not having touched it for years now!
This isn't to say that the keybindings never made sense; in the stage of computing before X, where Space Cadet-like keyboards were common, it was more than fine.
Currently, though? Entirely different era of computing.
Imagine you're walking in with no clue. You haven't heard of any of the memes, someone just recommended you a text editor. "It's really good! You'll be more productive!" You have no idea what in the world evil is, or why you would ever want it.
You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
Off to a good start, breaking the most universal keybinding across modern operating systems in the strangest way possible, and not only that, but also breaking one of the biggest implicit rules of keybindings.
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'! Not only that, but it's not even consistently unintuitive!
And that's not even getting into the obvious problems that come with the placement of M and C on modern keyboards.
There are a few solutions to this, obviously, but good luck trying to find a solution that isn't universally-hated.
You could make evil the default. Controversial and only slightly helps the barrier to entry.
You could make it like the Web's model of text-editing but with quality-of-life enhancements. I think this one is probably the winner. It's definitely why Sublime/VSC/Atom won, past everything else.
The Turbo C/Wordstar approach was cool, but has no mind-share today.
You could try something new, I guess? This is dangerous territory, though.
I have no idea what the solution is, but the problem(s) seem obvious. I say this all as a person who really likes Emacs. I even still have most commands memorized despite not having touched it for years now!
> You launch the tutorial/tour/whatever it's called and immediately it yells at you to use C-v to jump to the next page. And then M-v to go backwards! If you're a normal user, your response is probably something along the lines of, "Like, why?"
The hardcore emacs users think these keys are better. And don't want to change them, because then they had to rewrite the whole manual which uses these keys.
The user don't have to use these keys, though, so there is no point in the tutorial starting with them.
The hardcore emacs users think these keys are better. And don't want to change them, because then they had to rewrite the whole manual which uses these keys.
The user don't have to use these keys, though, so there is no point in the tutorial starting with them.
Right? And yet I just typed 'emacs tutorial' into DDG, and the first three results all hit you right away with descriptions of keys that don't physically exist on a modern keyboard.
https://www.gnu.org/software/emacs/tour/
http://www.jesshamrick.com/2012/09/10/absolute-beginners-gui...
https://www2.lib.uchicago.edu/keith/tcl-course/emacs-tutoria...
I've never tried emacs in large part because I've been convinced over the years that the various combinations of keys I would need to memorize are too complicated. I just did that search thinking that maybe I'd been mis-remembering, but no, that's still the impression that I have.
https://www.gnu.org/software/emacs/tour/
http://www.jesshamrick.com/2012/09/10/absolute-beginners-gui...
https://www2.lib.uchicago.edu/keith/tcl-course/emacs-tutoria...
I've never tried emacs in large part because I've been convinced over the years that the various combinations of keys I would need to memorize are too complicated. I just did that search thinking that maybe I'd been mis-remembering, but no, that's still the impression that I have.
I'm curious, how do you remember key combinations in other IDEs? I learned Vim, it was tough, but I remember a handful of commands I use all the time. And used Vim mode when available in IDEs when available. Spent a few years with VS Code, but I could never remember certain keys to navigate between panels for example. But the F1 key is great though. For w/e reason, I tried Emacs with evil-mode. I don't have to remember that many new keys I think, but a few of course. 'which-key' and M-x enables me to search for all commands, and I can also see the key combinations if I need to learn it later. In VS Code I try the F1 key, but if I could not find it there, I would grab the mouse and click around in menus looking for key combinations. Or go into settings and try to find w/e I was looking for. Of course, in Emacs I have spent hours setting things up, searching on the internet for clues on how to get something working as expected.
Perhaps I am doing something non-optimal in my process. Curious how others learn/get productive in their respective IDEs.
Perhaps I am doing something non-optimal in my process. Curious how others learn/get productive in their respective IDEs.
In most IDEs, they're the same key combos I use in non-IDE products. I'm on a Mac, so Cmd-X, Cmd-C, and Cmd-V work pretty much everywhere. They even work at a terminal prompt, and the latter two work in vi.
I did learn vi years ago, but I'm sure I still don't tap but 10% of its power, despite using it daily, precisely because the key combinations seem arcane to me.
I did learn vi years ago, but I'm sure I still don't tap but 10% of its power, despite using it daily, precisely because the key combinations seem arcane to me.
I pointed out that these would see a great deal of uproar were they to be changed; I'm aware.
If that were the case, vim would not be as popular as it is.
vi is less unintuitive, as I noted above. There's also much less, which is really helpful.
vi is less unintuitive, as I noted above.
I am having trouble finding that in your long comment. The initial experience of using vi and emacs are hardly different in some fundamental way so either being unintuitive seems like a poor way to explain their respective popularity (or lack thereof).
I am having trouble finding that in your long comment. The initial experience of using vi and emacs are hardly different in some fundamental way so either being unintuitive seems like a poor way to explain their respective popularity (or lack thereof).
You read a little bit more and eventually get to cursor control. Wow, somehow they managed to pick the only possible thing less intuitive than 'hjkl'!
The initial experience of vi is that you learn six keys to press to make it do things, and go from there. Emacs is significantly more complex than that, starting out.
It's definitely not intuitive, but it's an order of magnitude of difference from Emacs, which could be described as anti-intuitive.
The initial experience of vi is that you learn six keys to press to make it do things, and go from there. Emacs is significantly more complex than that, starting out.
It's definitely not intuitive, but it's an order of magnitude of difference from Emacs, which could be described as anti-intuitive.
Vi has text input modality, unlike essentially, well, anything. It's an entirely different model of operation which it shares with no current software and hasn't for a quarter century.
It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains emacs.
It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains emacs.
'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you?
The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all that much dysfunction, in my opinion.
The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all that much dysfunction, in my opinion.
'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you?
It's not. Maybe we're talking about completely different things because I'm not following this at all, just like the other responder downthread. For decades, GUI text entry has been modeless. Larry Tessler one of the GUI's pioneers and prophets (PBUH) had a 'NO MODES' license plate and the idea remains a central theme in UI design. Vi doesn't do that. It does this:
https://en.wikipedia.org/wiki/Vim_(text_editor)#Modes
I don't mean to debate the merits of this design but in terms of 'breaking core assumptions, vi 'breaks the core assumption' of typing text into a computer. It's not, per Winnfield, the same ball park, same league or even the same sport.
It's not. Maybe we're talking about completely different things because I'm not following this at all, just like the other responder downthread. For decades, GUI text entry has been modeless. Larry Tessler one of the GUI's pioneers and prophets (PBUH) had a 'NO MODES' license plate and the idea remains a central theme in UI design. Vi doesn't do that. It does this:
https://en.wikipedia.org/wiki/Vim_(text_editor)#Modes
I don't mean to debate the merits of this design but in terms of 'breaking core assumptions, vi 'breaks the core assumption' of typing text into a computer. It's not, per Winnfield, the same ball park, same league or even the same sport.
> 'press i and then basically everything works as you'd expect' is pretty simple
If that means that you can press letters in they keyboard and see them appear in the screen that’s also true in Emacs... and you don’t even have to press ‘i’ for things to start working as expected.
If that means that you can press letters in they keyboard and see them appear in the screen that’s also true in Emacs... and you don’t even have to press ‘i’ for things to start working as expected.
Emacs breaks assumptions of the operating system; vi does not.
What does that mean?
In vi if I press "i" I can't use the arrow keys to navigate the text as normal. In emacs I can. I'd say using the arrow keys for navigation in text fields is a very widely accepted functionality. So isn't it vi breaking the expected behavior here?
In vi if I press "i" I can't use the arrow keys to navigate the text as normal. In emacs I can. I'd say using the arrow keys for navigation in text fields is a very widely accepted functionality. So isn't it vi breaking the expected behavior here?
Who cares about popularity? It often brings more trouble than anything. Emacs is a gem and will probably stay like that for decades to come.
The only thing I wonder about is how it is possible that Stallman seems to have never heard about org-mode which is one of the main reasons I use Emacs and I don't think there exists anything that even comes close.
I manage my todos with org-mode, generate chord sheets of my songs and even produce my website from org files.
The only thing I wonder about is how it is possible that Stallman seems to have never heard about org-mode which is one of the main reasons I use Emacs and I don't think there exists anything that even comes close.
I manage my todos with org-mode, generate chord sheets of my songs and even produce my website from org files.
I don't think Stallman writes code anymore. It's surprising that he doesn't use org-mode for other, life organization issues, though.
This is a super dumb example, but I hate that scrolling is tied to cursor. Like if I'm gasp using the mouse to scroll through a file in emacs, the cursor has to stay in the viewport. If I scroll past the viewport, the cursor moves to the viewport. In IntelliJ (which has such good emacs keybindings I can use it for a lot of my work), the opposite is true: when I scroll away from my cursor, it stays there and when I start typing again, my viewport moves to my cursor not vice versa.
It's a small thing but it shows emacs' age. When emacs was written, GUI cursors weren't a thing. Scrolling wasn't a thing. Of course the cursor and the viewport would be connected. There wasn't any other way to move the viewport. Basically emacs needs to be somewhat GUI native.
Emacs should also be more discoverable. It's hard to incrementally learn key commands. I hate that the default for M-x is just a blank line. It's really intimidating. Having some sort of fuzzy search/history like Helm makes M-x so much easier to use.
Basically emacs needs to get UI and UX people to give it a refresh. Nothing outlandish, just get it into the 21st century.
It's a small thing but it shows emacs' age. When emacs was written, GUI cursors weren't a thing. Scrolling wasn't a thing. Of course the cursor and the viewport would be connected. There wasn't any other way to move the viewport. Basically emacs needs to be somewhat GUI native.
Emacs should also be more discoverable. It's hard to incrementally learn key commands. I hate that the default for M-x is just a blank line. It's really intimidating. Having some sort of fuzzy search/history like Helm makes M-x so much easier to use.
Basically emacs needs to get UI and UX people to give it a refresh. Nothing outlandish, just get it into the 21st century.
I think it's possible to implement this as an extension on top of evil? trigger a bookmark when the user starts scrolling, jump back to the bookmark on keystroke in insert mode.
but yeah, there's generally a problem with the UI/UX -- like as a consequence of the problem you're describing, you have to clear your current selection before scrolling to paste from the kill buffer. it's all foibles you learn about and adjust to but it makes the environment feel unpolished on a first impression.
spacemacs and doom have a better impression out of the box but there are just some core problems that they can't fix with a clever configuration. one that frustrates me regularly is auto-complete (company) triggering a network call that's bound to time out (because of user error) and the whole editor hanging for the duration because the completion call happened in the same thread as the UI. actually, the single threaded nature of most of emacs is probably my biggest complaint...
but yeah, there's generally a problem with the UI/UX -- like as a consequence of the problem you're describing, you have to clear your current selection before scrolling to paste from the kill buffer. it's all foibles you learn about and adjust to but it makes the environment feel unpolished on a first impression.
spacemacs and doom have a better impression out of the box but there are just some core problems that they can't fix with a clever configuration. one that frustrates me regularly is auto-complete (company) triggering a network call that's bound to time out (because of user error) and the whole editor hanging for the duration because the completion call happened in the same thread as the UI. actually, the single threaded nature of most of emacs is probably my biggest complaint...
Oh yeah you could definitely implement this with some nice config. But that's the problem: only insane people like fiddling with configuration that much.
I know my gateway to emacs was spacemacs. Except spacemacs, when I used it, was slow as heck. When VSCode feels snappier than emacs, something's wrong.
People talk about rewrites far too often but I wouldn't mind a significant rearchitecture/rewrite of emacs. Stuff like this^[1] makes me think it's long overdue.
[1]: https://www.facebook.com/notes/daniel-colascione/buttery-smo...
I know my gateway to emacs was spacemacs. Except spacemacs, when I used it, was slow as heck. When VSCode feels snappier than emacs, something's wrong.
People talk about rewrites far too often but I wouldn't mind a significant rearchitecture/rewrite of emacs. Stuff like this^[1] makes me think it's long overdue.
[1]: https://www.facebook.com/notes/daniel-colascione/buttery-smo...
definitely. i agree with all of that. i have high hopes for remacs.
Whenever I want to keep my place but look at another part of the file, I do C-x 2, mess around in the other window, then C-x 0 when I want to go back to my place.
I hate that in other editors if I'm keeping the cursor in one place and scrolling to look at another, that if I want to change something in that other place I have to lose the cursor position I'm trying to hold onto.
I hate that in other editors if I'm keeping the cursor in one place and scrolling to look at another, that if I want to change something in that other place I have to lose the cursor position I'm trying to hold onto.
It's because scrolling doesn't actually make sense in emacs or vim, if you've put some time into learning how to use them.
In vim, for example, you would be much better off navigating with the keyboard than the mouse. You can leave bookmarks all over the file and jump between them with 2 keystrokes. There are also a multitude of navigation controls ({, }, gg, G, etc.) that save you the time of moving your hand in between your mouse and keyboard.
If you want to use your mouse, maybe vim/emacs aren't for you -- sublime or vs code will probably serve you better.
In vim, for example, you would be much better off navigating with the keyboard than the mouse. You can leave bookmarks all over the file and jump between them with 2 keystrokes. There are also a multitude of navigation controls ({, }, gg, G, etc.) that save you the time of moving your hand in between your mouse and keyboard.
If you want to use your mouse, maybe vim/emacs aren't for you -- sublime or vs code will probably serve you better.
I'm genuinely curious: do you not read through code from top to bottom? That's a very common thing that I do, and using the mouse is a comfortable way of accomplishing it.
If you want to go to the next page (screen) of code, isn’t the keyboard just as comfortable? If you want to go down until you find the thing you’re looking for, wouldn’t a search using the keyboard be potentially more comfortable?
I like how I can control the rate at which I scroll with the mouse more easily than with the keyboard. It's a more intuitive movement that I can adjust to match the speed of my reading.
The point is that reading code from top to bottom is not a reason to need or prefer a mouse. Other people prefer using a keyboard and find moving through pages more intuitive than scrolling.
Different people have different preferences, so clearly it is a reason to prefer a mouse.
I don’t use my mouse with Emacs, but I’m not going to tell someone else they’re wrong for wanting to. I’m beginning to see why people feel the Emacs community is less-than-welcoming.
I don’t use my mouse with Emacs, but I’m not going to tell someone else they’re wrong for wanting to. I’m beginning to see why people feel the Emacs community is less-than-welcoming.
Of course different people have different preferences. I don’t tell anybody that the way they prefer is wrong! I don’t say there is a reason to prefer the keyboard either. But being what it is doesn’t make Emacs broken. You can definitely read code from top to bottom on it.
> It's because scrolling doesn't actually make sense in emacs or vim, if you've put some time into learning how to use them. In vim, for example, you would be much better off navigating with the keyboard than the mouse.
Is this coming from a workstation-oriented mindset? On laptops with touchpads, scrolling with your "mouse" makes a ton of sense even for seasoned touch typists. I don't always use it for scrolling, but I frequently do. However when I'm sitting in front of a workstation with a traditional keyboard and mouse arrangement, I do avoid the mouse.
Is this coming from a workstation-oriented mindset? On laptops with touchpads, scrolling with your "mouse" makes a ton of sense even for seasoned touch typists. I don't always use it for scrolling, but I frequently do. However when I'm sitting in front of a workstation with a traditional keyboard and mouse arrangement, I do avoid the mouse.
Eh, Vim and Kakoune user here for the last ~15 years, I love scrolling with my mouse and keyboard. Keyboard for when I'm navigating. Mouse wheel for when I'm just skimming code, idly looking for something.
The fact is scrolling with a mouse moves much faster while still seeing what I'm doing. You can't scroll line by line quickly with a keyboard. There's no variable speed (that I've ever seen, at least). However with a mouse I can alternate between fast and slow. Really nice for scanning large piles of text where you don't know exactly what you're looking for.
Sure I could jump a screen length at a time if I wanted, but then my eyes have to jump bottom to top to bottom to top every time I jump. I find it difficult to track where I am. Page jumping tends to ruin context, even with a handful of lines as context.
With that said though, I have seen some really nice Terminal renderers that will smear the cursor when you jump. It looks like it would help a lot to keep the visual context.
The fact is scrolling with a mouse moves much faster while still seeing what I'm doing. You can't scroll line by line quickly with a keyboard. There's no variable speed (that I've ever seen, at least). However with a mouse I can alternate between fast and slow. Really nice for scanning large piles of text where you don't know exactly what you're looking for.
Sure I could jump a screen length at a time if I wanted, but then my eyes have to jump bottom to top to bottom to top every time I jump. I find it difficult to track where I am. Page jumping tends to ruin context, even with a handful of lines as context.
With that said though, I have seen some really nice Terminal renderers that will smear the cursor when you jump. It looks like it would help a lot to keep the visual context.
I use Emacs all day, every day, and I use the mouse to scroll.
I've done the "look ma no mouse" thing where you just use your keyboard. Heck, I used to have an emacs config where scrolling would scroll through my undo/redo tree^[1], which lemme tell you, confuses the hell out of other people using your computer.
But ultimately sometimes executing some annoying combo of C-v/C-s/M-f/M-b is less ergonomic than using the wonderful invention that is scrolling. Especially if you want to aimlessly scan through code instead of purposefully navigate.
I suspect part of the reason for emacs being a hard sell is the reputation of emacs being an all or nothing platform. You're supposed to not use the mouse, do everything in emacs, write elisp to make everything super automated and awesome. And sure, you can do that! But it's okay to be a bad emacs user. It's okay to use the mouse. It's okay to not write elisp. It's okay to use other apps. VSCode doesn't come with a religion. I don't think emacs should either.
[1]: Inspired by this XKCD: https://xkcd.com/1806/
But ultimately sometimes executing some annoying combo of C-v/C-s/M-f/M-b is less ergonomic than using the wonderful invention that is scrolling. Especially if you want to aimlessly scan through code instead of purposefully navigate.
I suspect part of the reason for emacs being a hard sell is the reputation of emacs being an all or nothing platform. You're supposed to not use the mouse, do everything in emacs, write elisp to make everything super automated and awesome. And sure, you can do that! But it's okay to be a bad emacs user. It's okay to use the mouse. It's okay to not write elisp. It's okay to use other apps. VSCode doesn't come with a religion. I don't think emacs should either.
[1]: Inspired by this XKCD: https://xkcd.com/1806/
> This is a super dumb example, but I hate that scrolling is tied to cursor. Like if I'm gasp using the mouse to scroll through a file in emacs, the cursor has to stay in the viewport.
I don't quite see an easy way of fixing that without making it a user-controlled option, though. For example, in text-mode editors it is still common to not have the text cursor scroll past the viewport.
I don't quite see an easy way of fixing that without making it a user-controlled option, though. For example, in text-mode editors it is still common to not have the text cursor scroll past the viewport.
I've been fortunate to be able to use Emacs for the last 35 years or so. If memory serves (and more and more, it doesn't) I started with Gosmacs and moved to GNU Emacs sometime around 1986 or so.
At 60 years old, I don't have the enthusiasm or the time to learn a new editor. And I'm having too much fun programming in Lisp.
At 60 years old, I don't have the enthusiasm or the time to learn a new editor. And I'm having too much fun programming in Lisp.
I love emacs because it's fully programmable. This flexibility comes at a cost though, i.e. the time invested making the environment mine; exactly how I want it to be. It's like a sandbox for text based work on a computer.
Not everyone is willing to invest this time and therefore IMO it won't be a very popular environment for most users. I don't blame them, everyone's needs and priorities in life are different.
Not everyone is willing to invest this time and therefore IMO it won't be a very popular environment for most users. I don't blame them, everyone's needs and priorities in life are different.
It's the ultimate yak shaver ;-)
Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few things, and tell yourself "I don't need to modify yet another key binding" a hundred times.
Or you could start with a popular .emacs.d (I use Doom Emacs), tweak a few things, and tell yourself "I don't need to modify yet another key binding" a hundred times.
Popularity is more of a marketing problem than an editor problem.
At the same time, if we compare emacs to vscode, vscode simply requires less configuration to get going. Given how much tooling exists in the javascript ecosystem, I think having a few plugins "just work" goes a long way.
Asking users to configure emacs from scratch to have a reasonable editing experience in their programming language of their choice is a lot. I think configurations like doom or spacemacs do a lot for this problem, but it really comes down to marketing.
At the same time, if we compare emacs to vscode, vscode simply requires less configuration to get going. Given how much tooling exists in the javascript ecosystem, I think having a few plugins "just work" goes a long way.
Asking users to configure emacs from scratch to have a reasonable editing experience in their programming language of their choice is a lot. I think configurations like doom or spacemacs do a lot for this problem, but it really comes down to marketing.
At work, I moved from Emacs to VS Code about a year ago. I’d used Emacs for years but I was spending a large amount of time fixing package upgrade problems. I guess I’d got into some kind of dependency hell. Maybe I wasn’t experienced enough with Emacs to use it professionally. But that’s the kicker, I haven’t had that problem switching to VS Code.
Having all of Elisp and all of Emacs available, including packages, is powerful. But it comes with a complexity cost if your config/dependency graph grows to large. Like any in-house software project really - of which a small business cannot afford to invest in.
There is one area, though, I’d use it again for: Lisp. Clojure with CIDER, CL with SLIME. As far as IDEs go, the level of language support for Lisp is phenomenal and without equal (but not surprising given Elisp).
Having all of Elisp and all of Emacs available, including packages, is powerful. But it comes with a complexity cost if your config/dependency graph grows to large. Like any in-house software project really - of which a small business cannot afford to invest in.
There is one area, though, I’d use it again for: Lisp. Clojure with CIDER, CL with SLIME. As far as IDEs go, the level of language support for Lisp is phenomenal and without equal (but not surprising given Elisp).
What did you do about key bindings? The default vscode ones rely heavily on arrow keys, but those things are just so far away from the home key. I can't seem to find a move up/down paragraph shortcut to map either. I've tried some of the emacs plugins but they all introduce weird behavior; I keep ending up in some random menu vs just moving my cursor around.
In effect, gritted my teeth and got used to it. I mean, the basic movement commands still work (or you can configure it so) so that helps.
But the benefits out weigh the sluggishness I feel at the keyboard. It was easier to get the rest of the team on VS Code and then I could start looking at extensions that bring things as close to what’s in Emacs as possible. That’s improved team productivity as whole (and my own when they do the same).
But there are somethings I long for. Magit was hands down the best thing for projects versioned in Git. I’ve not seen anything like it in VS Code. The other thing is macros and Elisp but as above that’s a double edged sword. I’ve actually thought about bringing some of those ideas over to VS Code at least for my own team.
But the benefits out weigh the sluggishness I feel at the keyboard. It was easier to get the rest of the team on VS Code and then I could start looking at extensions that bring things as close to what’s in Emacs as possible. That’s improved team productivity as whole (and my own when they do the same).
But there are somethings I long for. Magit was hands down the best thing for projects versioned in Git. I’ve not seen anything like it in VS Code. The other thing is macros and Elisp but as above that’s a double edged sword. I’ve actually thought about bringing some of those ideas over to VS Code at least for my own team.
In what keyboard layout is home far from the arrows? I never noticed a problem with a 101/104 key layout
> if we compare emacs to vscode, vscode simply requires less configuration to get going
True, but then why do more people uses Vim than Emacs? Is it becase it's installed on servers and stuff?
I wonder what percent of desktop programmers use vim or emacs who don't need to do devops.
True, but then why do more people uses Vim than Emacs? Is it becase it's installed on servers and stuff?
I wonder what percent of desktop programmers use vim or emacs who don't need to do devops.
Where I work nearly everyone uses Vim. We work in less popular languages that new kids on the block (VSC, Atom) don't really support. It really either Vim or Emacs. I think most people choose Vim because it is the default "Terminal based Editor" in most peoples minds.
I use it because it's installed by default on Linux desktops. That's not important to me now—I'm currently using Neovim compiled from source—but it was important when I was first learning to code.
I could probably switch to Emacs using Evil, but I don't see a compelling reason to.
I could probably switch to Emacs using Evil, but I don't see a compelling reason to.
i tried using both emacs and vim at the beginning. the problem with emacs, for me, is that the keybinds were basically to harsh on my wrists while vim was quite good, because i could keep my hands on the home row.
for simple edits vim works great and is fast. for serious development , something like vscode with vim keybindings is the best of both worlds
Well, spacemacs is an awesome intro for new users, which makes it cool, useful and quickly configurable.
Tried to use Emacs for data analysis in Python, because I write lots of docs in org and client project status/tasks report page is also generated from my org file. But the problem is proper support of repl in python. We got number of packages but none really solves my problem to have a proper analytics workflow.
P.S. I also write Clojure and Emacs it surely the go-to environment! Actually, I got into Emacs due to Clojure back in 2014.
- Spacemacs for all the bells and whistles
- Emacs Prelude for simple base
- Doom Emacs is another beast, though.
P.S. What might make it much more accessible I think is builtin project structure view such as Treemacs. Also, let's not forget that Most of the world do use Windows and Emacs has a poor support for this platform.
- The problem with VSCode, Atom and alikes are just absolutely inconsistent keybindings, half-baked packages and honestly I don't really want to write code in a browser. It's like a flashy smartphone - does everything but few things well. Hence my favourite tools for coding are produced by JetBrains - PyCharm and IntelliJ. These tools do also have their keyboard inconsistency issues, but it is what it is.
Happy Hacking!
Tried to use Emacs for data analysis in Python, because I write lots of docs in org and client project status/tasks report page is also generated from my org file. But the problem is proper support of repl in python. We got number of packages but none really solves my problem to have a proper analytics workflow.
P.S. I also write Clojure and Emacs it surely the go-to environment! Actually, I got into Emacs due to Clojure back in 2014.
- Spacemacs for all the bells and whistles
- Emacs Prelude for simple base
- Doom Emacs is another beast, though.
P.S. What might make it much more accessible I think is builtin project structure view such as Treemacs. Also, let's not forget that Most of the world do use Windows and Emacs has a poor support for this platform.
- The problem with VSCode, Atom and alikes are just absolutely inconsistent keybindings, half-baked packages and honestly I don't really want to write code in a browser. It's like a flashy smartphone - does everything but few things well. Hence my favourite tools for coding are produced by JetBrains - PyCharm and IntelliJ. These tools do also have their keyboard inconsistency issues, but it is what it is.
Happy Hacking!
For me, I’ve recently started using Emacs solely due to wanting to try out rust-analyzer¹ (not touching Visual Studio Code since it uses Electron), and I’m really enjoying how insanely customizable Emacs is! The ecosystem around Emacs looks great too, with quite a few packages I´m interested in trying (like Magit²).
――――――
¹ — https://rust-analyzer.github.io/blog/2020/04/20/first-releas...
² — https://magit.vc/
――――――
¹ — https://rust-analyzer.github.io/blog/2020/04/20/first-releas...
² — https://magit.vc/
I cannot possibly encourage you more to check out magit. It is unbelievably good. I always share this demo with people to show off just a tiny portion of what it's capable of doing
https://www.youtube.com/watch?v=rzQEIRRJ2T0
My skills with git have gotten better after using magit, too, because it brings the power of git to the surface. It's a really fantastic git porcelain and the fact that it is deeply integrated into Emacs just makes it absolutely second to none.
Magit is easily one of my favorite pieces of software and I will leap at the chance to sing its praises.
https://www.youtube.com/watch?v=rzQEIRRJ2T0
My skills with git have gotten better after using magit, too, because it brings the power of git to the surface. It's a really fantastic git porcelain and the fact that it is deeply integrated into Emacs just makes it absolutely second to none.
Magit is easily one of my favorite pieces of software and I will leap at the chance to sing its praises.
magit is just superb. You are bound to love it! And the developer is extremely responsive too!
I think licensing is not the problem, why nobody installs emacs anymore. It is initial setup. Where can I get a good code highlighter for all my code. Integration into obscure ide's compilers like iar. A workflow showing me easily what I changed, which files to check into git. A nice git overview of file history thanks to extensions. where can I get all this easily. One click and have a dark theme. Also easily customizable shortcuts. Manpower behind the editor for many changes and improvements. I mean who pumps out new versions every month.
I would say vs code does all that and while using an easy to overcome entry bar. And I am much more productive even than in native ide's for embedded development. Like iar eclipse or Segger.
The only thing I would want to try is using the org mode in emacs for nice todo handling. But else I see no appeal in emacs. It is just ugly, more concerned about it's license instead of just saying, this is free software just contribute and we will improve by using everything we can.
I would say vs code does all that and while using an easy to overcome entry bar. And I am much more productive even than in native ide's for embedded development. Like iar eclipse or Segger.
The only thing I would want to try is using the org mode in emacs for nice todo handling. But else I see no appeal in emacs. It is just ugly, more concerned about it's license instead of just saying, this is free software just contribute and we will improve by using everything we can.
I was about to jump ship to VSCode, but lsp-mode (despite minor hiccups) has extended my Emacs' expiration date.
So if I almost gave up, after having lived in Emacs for the last 12 years, can we really expect much popularity with those that are new to computing?
In 2020, Emacs is mostly just for people that love to build or customize their tools, or for folks that want a better Vim (i.e. Doom Emacs). And to customize Emacs you have to have a basic understanding of modes, hooks, keymaps, etc -- as well as at least rudimentary knowledge of elisp. Getting good at that stuff is a multi-year-long process. Emacs will never be "popular" for the same reason that if you want to have a fun night with friends, (statistically) chances are you'll choose to play Rock Band as opposed to learning real instruments. But as is the case with many niche and challenging things, it's hella fun and rewarding once you've spent a few years doing it.
So if I almost gave up, after having lived in Emacs for the last 12 years, can we really expect much popularity with those that are new to computing?
In 2020, Emacs is mostly just for people that love to build or customize their tools, or for folks that want a better Vim (i.e. Doom Emacs). And to customize Emacs you have to have a basic understanding of modes, hooks, keymaps, etc -- as well as at least rudimentary knowledge of elisp. Getting good at that stuff is a multi-year-long process. Emacs will never be "popular" for the same reason that if you want to have a fun night with friends, (statistically) chances are you'll choose to play Rock Band as opposed to learning real instruments. But as is the case with many niche and challenging things, it's hella fun and rewarding once you've spent a few years doing it.
If rms doesn't understand org-mode, that seems to be pretty indicative of what the real problems underlying emacs' lack of popularity are.
I suspect that org-mode is responsible for more people using emacs than any other package by a large margin. Not understanding org mode suggests to me that rms is no longer on the same page as most of the users.
I know there's a lot of other good stuff in emacs, but org-mode seems to be particularly key.
I suspect that org-mode is responsible for more people using emacs than any other package by a large margin. Not understanding org mode suggests to me that rms is no longer on the same page as most of the users.
I know there's a lot of other good stuff in emacs, but org-mode seems to be particularly key.
I feel like I’ve noticed an increase in the popularity of emacs online in the last 10 years or so. Or perhaps just a waning of vim zealotry. I’m pretty sure I used to see quite vim-related posts on hn but I don’t really see them anymore, whereas I do see emacs/elisp related posts from time to time (with particularly strong mentions for org-mode or magit), and I don’t have much memory of them.
Perhaps vim is so widely used now that no one bothers to vote up articles about it. I find the shift particularly strange because it comes with a shift of the site away from lots of articles about languages like lisp for which emacs is basically the only sane choice of editor.
Perhaps the real reason is just that I’ve noticed emacs more because I’ve used it more.
Perhaps vim is so widely used now that no one bothers to vote up articles about it. I find the shift particularly strange because it comes with a shift of the site away from lots of articles about languages like lisp for which emacs is basically the only sane choice of editor.
Perhaps the real reason is just that I’ve noticed emacs more because I’ve used it more.
Honestly the hardest part about emacs for me has always been documentation. Like how do I build a plugin. What function do I call to set a custom key binding? This stuff has always been so hard to find despite it being so important to the underlying experience. Now that I've used it for a while I know these things, but they didn't come easily.
These days you can just google to get answers quickly, just like for any other tool. Stackoverflow, etc. has tons of content for emacs too.
It's ridiculous that end users should rely on third parties for reliable documentation. For any other tool, if you wanted to know this kind of builtin functionality it'd be readily accessible in --help, the man page, or first-party online docs. Why should Emacs be an exception?
What tool do you go to the official docs for first and only Google second? I Google everything first. Am I missing out?
From: [email protected]
In general, the way for a problem to be fixed is for someone who knows how to fix it right simply to do so. Any solution that involves discussion should be avoided except as a last resort, because it is inefficient.
In general, the way for a problem to be fixed is for someone who knows how to fix it right simply to do so. Any solution that involves discussion should be avoided except as a last resort, because it is inefficient.
Is this a real email? Do you have a reference? Google didn't turn anything up.
Dale Worley posted it to a mailing list in '89, and I asked him where it came from:
https://groups.google.com/forum/#!search/%22In$20general$2C$...
http://www.art.net/studios/hackers/hopkins/Don/text/rms-vs-d...
I love Lile's response, who has the grace and composure of dang:
>Please send your "fucks" via personal mail and refrain from using Kabuki-west for such messages. -Lile Elam
Date: Mon, 18 Sep 89 21:55:13 EDT
From: [email protected]
To: [email protected]
Subject: An interesting bit of philosophy from RMS
From: Don Hopkins <[email protected]>
From: [email protected]
In general, the way for a problem to be fixed is for someone
who knows how to fix it right simply to do so. Any solution
that involves discussion should be avoided except as a last
resort, because it is inefficient.
Interesting all right! When/where and in what context did he say
this?
It was on one of the Emacs newsgroups, where lots of reasonably
uninformed discussion had broken out on how to resolve the fact that
VM and Gnus (I think) interfered with each other, because they both
used the overlay-arrow mechanism.
Dale
https://groups.google.com/forum/#!search/%22In$20general$2C$...
Date: 9/11/89
From: [email protected]
Newsgroup: gnu.emacs
Subject: No more on overlay-arrow-position
I don't think most Emacs users want to participate in a discussion
about how to solve a fairly obscure problem in how Emacs is implemented.
This kind of discussion doesn't help me solve the problem. I know you
mean well, but you aren't experts. Most of this discussion consists
of proposals that are completely wrong, or won't work, followed by
refutations and counterproposals. When I decide to fix this for
version 19, I won't read the discussion; I'll just fix it--it will
take less time.
In general, the way for a problem to be fixed is for someone who knows
how to fix it right simply to do so. Any solution that involves
discussion should be avoided except as a last resort, because it is
inefficient.
Remember, the purpose of info-gnu-emacs (and its repeater newsgroup,
gnu.emacs) is to carry the information that *every Emacs user will
want to know*. There's nothing wrong with non-experts discussing how
Emacs bugs might be fixed, but please don't do it here.
http://www.art.net/studios/hackers/hopkins/Don/text/rms-vs-d...
I love Lile's response, who has the grace and composure of dang:
>Please send your "fucks" via personal mail and refrain from using Kabuki-west for such messages. -Lile Elam
Very interesting. Thanks!
I use Emacs and love it, but the problem as a newcomer is that basic questions never have basic answers. The answer is either in the form of a complex incantation, or requires one to come to grips with new abstractions.
Emacs is eternal. It was here before most other editors and will outlive the majority.
> It was here before most other editors and will outlive the majority.
While your first statement is true, taking the second one for granted is dangerous and may lead to the exact opposite.
Every long-term FOSS project needs to continuously ensure it maintains a healthy level of contributors, or it will die.
While your first statement is true, taking the second one for granted is dangerous and may lead to the exact opposite.
Every long-term FOSS project needs to continuously ensure it maintains a healthy level of contributors, or it will die.
I think that the Emacs concept is really good, but it clearly has a lot of problems that make it altogether unattractive to new potential users.
- The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non-default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are.
- There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
- Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
- The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for.
At the same time, it does do plenty of things right:
- From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
- Unicode works OOTB, which is impressive for a project of that age.
- Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems.
- Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package.
A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"---packages just run the same kind of Elisp that the editor itself is (mostly) written in.
Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
- The keybindings are not the standard CUA ones. Even with Cua Mode, every page on the internet still suggests using the regular old Emacs keybindings. There's weird conflicts between some packages, especially if you use non-default keybinds like Evil. The defaults are not even ergonomic (Emacs pinkie is a thing...) or mnemonic, so there's really nothing but historical interest that makes them the way they are.
- There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
- Lots of other defaults are super user-hostile. To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
- The base is minimal in a way (it's missing a ton of what is needed to be considered useful today) and also very bloated (it has things like mail readers and web browsers and IRC clients included). The set of default utilities needs to better match what people actually use a text editor for.
At the same time, it does do plenty of things right:
- From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
- Unicode works OOTB, which is impressive for a project of that age.
- Some of the "killer apps" like Magit and Org-mode are really good and have spawned their own ecosystems.
- Emacs is oftentimes the first editor to get support for super-obscure programming languages through a package.
A lot of what makes Emacs so cool and so difficult comes from the fact that it doesn't have an "extension API"---packages just run the same kind of Elisp that the editor itself is (mostly) written in.
Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
How do you fix your con,
> - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
without sacrificing your pro?:
> - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level.
You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention.
What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned?
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things.
"modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?
> - There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
without sacrificing your pro?:
> - From anywhere in the editor, you can run code---you don't need to make a new package to be able to execute a snippet of Elisp.
The fact that you can go to any package source file, modify a function and reload it on the currently running emacs instance (with C-M-x/eval-defun) kind of depends on definitions being standalone and at the top-level.
You can have namespacing in the form of prefixing identifiers with the package name. If there's name-clashing between packages, it's because they didn't follow that convention.
What more would you want out of namespacing that you can get without sacrificing or limiting that pro you mentioned?
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
There are many reasons to hate pretty much anything. I'm not sure how you expect one to respond, if you don't give some idea of what it is that you find terrible about it. It's always pros and cons with most things.
"modern" also doesn't mean anything. Are you talking about languages that were invented recently or that are still maintained, evolving, and/or used despite being invented in "non-modern" times? Where does "modern" even start?
Agreed. I personally had never any problems with packages overwriting each other. Everybody knows that you have to namespace all the functions and it works, just like it works in C.
And the upside that everything is accessible in the scratch buffer is really worth it.
And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.
And the upside that everything is accessible in the scratch buffer is really worth it.
And for me, Elisp has been a kind of constant during my career. I wouldn't bet that in ten years, I'm still doing Typescript or Javascript. But if I'm still into programming computers via keyboards I will definitively use Emacs for that.
> There's no namespacing between packages. They can run right over each other and cause weird bugs. This isn't theoretical; it's what happens when you have a bunch of packages installed. Sorting out performance issues caused by the interactions between packages is very challenging.
The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound.
I don't know what system would be good/better, but I know I hate it as it stands today.
The worst aspect of this is keybindings. As "free-form" as Emacs is, I think it would benefit greatly from having a centralized "database" of all (custom?) keybindings. I am sick of defining my own super-cool keybinding and then either having it get overridden by a package or unknowingly overriding a package's keybindings. I kind of wish a warning would be thrown or something if you try to bind a set of keys that's already bound.
I don't know what system would be good/better, but I know I hate it as it stands today.
> To get anything approaching the productivity of an editor like Sublime or VS Code, you have to spend hours installing packages, learning their unique keybindings, and sorting out conflicts.
Isn't it the same with VIM or other free editors?
Isn't it the same with VIM or other free editors?
To be fair these days you come far by just installing ’lsp-mode’.
To an extent, yes, but I would say that the Vim philosophy involves utilizing external tools much more than in Emacs. Vim packages like the one for Go (https://github.com/fatih/vim-go) feel better-integrated into Vim than the equivalents do into Emacs. This is mostly subjective, so I can see where you're coming from.
> I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there?
I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.
This is a commonly seen complaint, and I do not completely disagree with you. But really, if there were better options to create an editor on top of some sort of lisp-machine equivalent, why are there such few equivalent editors out there?
I would be happy to move to a new mature ecosystem that allows the sort of flexibility offered by emacs, on which tools like magit and org-mode may become popular, but I am yet to find anything in the same ballpark.
> Edit: I should also add that Elisp is an absolutely terrible programming language when compared to more modern alternatives.
I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …
I think it's arguably the second-best language out there, losing out only to Common Lisp. Maybe third, after TCL. I certainly wouldn't want to use JavaScript, Go or Rust to extend my editor …
I like emacs' aesthetics. It looks like something developers would use in a movie, especially with the colors set dark and the scrollbar on the left where all scrollbars ought to be.
I agree that aesthetics have importance, but they should complement what emacs is and how its used, not make it pretend to be something else. Emacs is a powerful tool, that isn't going to change-- so it should look like one.
There are already many editors with a "sleek look"! So users that want that are already using one. They won't switch to emacs if emacs adopts a sleek look, especially because emacs' internals won't match the drapery.
Emacs epitomizes the Hole Hawg in Stephenson's excellent "In The Beginning Was The Command Line" (https://steve-parker.org/articles/others/stephenson/holehawg...). It should lean into that. The users it loses from being overly industrial are ones mostly wouldn't stay, but the ones it gathers will stay because there are few alternatives. There is always a role in the world for serious tools.
I agree that aesthetics have importance, but they should complement what emacs is and how its used, not make it pretend to be something else. Emacs is a powerful tool, that isn't going to change-- so it should look like one.
There are already many editors with a "sleek look"! So users that want that are already using one. They won't switch to emacs if emacs adopts a sleek look, especially because emacs' internals won't match the drapery.
Emacs epitomizes the Hole Hawg in Stephenson's excellent "In The Beginning Was The Command Line" (https://steve-parker.org/articles/others/stephenson/holehawg...). It should lean into that. The users it loses from being overly industrial are ones mostly wouldn't stay, but the ones it gathers will stay because there are few alternatives. There is always a role in the world for serious tools.
> Terminal-based Vim is not like a modern application, yet is more popular than Emacs.
As someone who has started out with vim, spent a couple years using emacs (with evil-mode) and ended up with vim (more accurately neovim) again, here's my take on why this is.
First of all, I ssh into a lot of systems that have vi(m) installed, but not emacs. So, if I am using vi bindings for my main editor, I don't have to switch to using completely different editor bindings on remote systems. For other's that are in a similar situation, that's also an incentive to learn vi over emacs.
Secondly, while vi(m)'s modal editing is difficult to master , once mastered, it is, IMO, amazing. Emacs otoh just has unfamiliar, and sometimes unergonomic key bindings. While many editors do have "vim modes", I have ultimately been unhapy with most of the one's I've tried (evil mode for emacs is ironically one of the best).
Finally, there is the configuration. Both emacs and vim are extremely customizable. While VimL is certainly not the greatest language, it is at least fairly familiar to programmers with experience with ALGOL-family languages. It's also somewhat straightforward to write plugins for vim in other languages, such as python and lua. Emacs otoh, uses Emacs Lisp. And while I admire lisp, it is certainly very unfamiliar to many potential emacs users, and can often be much more verbose, especially for setting custom key bindings.
With all that said, there are things I miss about emacs. Probably the biggest is that several modes let me customize how auto-indentation worked. In vim, the ability to customize that easily is not very common, and when it does exist is not well documented.
As someone who has started out with vim, spent a couple years using emacs (with evil-mode) and ended up with vim (more accurately neovim) again, here's my take on why this is.
First of all, I ssh into a lot of systems that have vi(m) installed, but not emacs. So, if I am using vi bindings for my main editor, I don't have to switch to using completely different editor bindings on remote systems. For other's that are in a similar situation, that's also an incentive to learn vi over emacs.
Secondly, while vi(m)'s modal editing is difficult to master , once mastered, it is, IMO, amazing. Emacs otoh just has unfamiliar, and sometimes unergonomic key bindings. While many editors do have "vim modes", I have ultimately been unhapy with most of the one's I've tried (evil mode for emacs is ironically one of the best).
Finally, there is the configuration. Both emacs and vim are extremely customizable. While VimL is certainly not the greatest language, it is at least fairly familiar to programmers with experience with ALGOL-family languages. It's also somewhat straightforward to write plugins for vim in other languages, such as python and lua. Emacs otoh, uses Emacs Lisp. And while I admire lisp, it is certainly very unfamiliar to many potential emacs users, and can often be much more verbose, especially for setting custom key bindings.
With all that said, there are things I miss about emacs. Probably the biggest is that several modes let me customize how auto-indentation worked. In vim, the ability to customize that easily is not very common, and when it does exist is not well documented.
How on earth was RMS unfamiliar with the existence of Org Mode, and how on earth was RMS unfamiliar with the concept of outliners, and why on earth, when he finally figured out what Org Mode did, was his immediate response to be super dismissive because it wasn't something that he's interested in using personally?
He sounds like some random person spewing random subjective opinions about things, rather than the original author of GNU Emacs making an honest effort to provide leadership and guidance that means something (anything) to anyone other than himself. He sounds helpless and oblivious to everything and everyone except his own personal proclivities, which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community. Like he's not even making a token effort to do those things, and to say he's metaphorically lifting a finger here to provide leadership and guidance would be very generous.
This is akin to Linus rejecting a driver because he doesn't own the hardware, or because he doesn't like the colors of logo of the company that makes it. It really doesn't get more incurious and intellectually/emotionally immature than that.
This is in 2020, after a couple decades of Emacs being one of the only actual software projects he involves himself in anymore. To be clear, I've had a really low opinion of RMS for going on 20 years now (after a few years in college where I thought he was cool because I didn't know any better and people seemed to revere him because they thought everyone else revered him). But reading these mailing list exchanges are still kind of shocking to me. It's really hard to believe that anyone on the GNU mailing lists pay any attention to him at all, or values his opinion on anything. For those that do, surely that's nothing more than a cult of personality, it just seems as plain as day to me. This is exactly the sort of thing that drives people away from GNU and the FSF, and it sucks because they could be so much more impactful and meaningful and helpful and positive and constructive otherwise.
Sometimes I think if more people had simply stopped making excuses for RMS like 20 years ago, we might currently be living in some sort of GNU utopia dreamworld where everyone everywhere uses Emacs for everything, and GCC is the preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to pay, when the only thing they get in return for keeping this guy around is helping a damaged narcissist continue to feel good about himself and continue alienating everyone else, just like he's been doing for decades. He absolutely got GNU and the FSF off the ground and helped create a large community that has produced tons of great software, but in the past 25 years it seems like all of his efforts have been counterproductive to his own goals.
He sounds like some random person spewing random subjective opinions about things, rather than the original author of GNU Emacs making an honest effort to provide leadership and guidance that means something (anything) to anyone other than himself. He sounds helpless and oblivious to everything and everyone except his own personal proclivities, which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community. Like he's not even making a token effort to do those things, and to say he's metaphorically lifting a finger here to provide leadership and guidance would be very generous.
This is akin to Linus rejecting a driver because he doesn't own the hardware, or because he doesn't like the colors of logo of the company that makes it. It really doesn't get more incurious and intellectually/emotionally immature than that.
This is in 2020, after a couple decades of Emacs being one of the only actual software projects he involves himself in anymore. To be clear, I've had a really low opinion of RMS for going on 20 years now (after a few years in college where I thought he was cool because I didn't know any better and people seemed to revere him because they thought everyone else revered him). But reading these mailing list exchanges are still kind of shocking to me. It's really hard to believe that anyone on the GNU mailing lists pay any attention to him at all, or values his opinion on anything. For those that do, surely that's nothing more than a cult of personality, it just seems as plain as day to me. This is exactly the sort of thing that drives people away from GNU and the FSF, and it sucks because they could be so much more impactful and meaningful and helpful and positive and constructive otherwise.
Sometimes I think if more people had simply stopped making excuses for RMS like 20 years ago, we might currently be living in some sort of GNU utopia dreamworld where everyone everywhere uses Emacs for everything, and GCC is the preeminent compiler suite, etc. etc. etc. It's quite a high cost for people to pay, when the only thing they get in return for keeping this guy around is helping a damaged narcissist continue to feel good about himself and continue alienating everyone else, just like he's been doing for decades. He absolutely got GNU and the FSF off the ground and helped create a large community that has produced tons of great software, but in the past 25 years it seems like all of his efforts have been counterproductive to his own goals.
> How on earth was RMS unfamiliar with the existence of Org Mode, and how on earth was RMS unfamiliar with the concept of outliners, and why on earth, when he finally figured out what Org Mode did, was his immediate response to be super dismissive because it wasn't something that he's interested in using personally?
He seems out of touch even with modern emacs packages. He doesn't use any of them, doesn't even know what they do, I guess he uses the same config since the 90s, doesn't try new packages, he's more interested in preaching the GNU message.
He seems out of touch even with modern emacs packages. He doesn't use any of them, doesn't even know what they do, I guess he uses the same config since the 90s, doesn't try new packages, he's more interested in preaching the GNU message.
> He seems out of touch even with modern emacs packages. He doesn't use any of them
And he believes the right thing for the core Emacs-developers to do is to spend their time trying get everyone in MELPA (a modern package repo, with a modern GUI, based on modern tools and workflows) to instead move their packages to ELPA, with all the change in tools, modernism’s and workflows that entails.
He seriously believes this is important because MELPA isn’t GNU, and that’s all he cares about. It’s not enough to be open-source and free. You must be GNU, or it doesn’t matter.
He may add things of value still, but I refuse to believe it’s not overshadowed by all the backwardisms he constantly tries to impose on the core developers actually doing the dirty work.
And he believes the right thing for the core Emacs-developers to do is to spend their time trying get everyone in MELPA (a modern package repo, with a modern GUI, based on modern tools and workflows) to instead move their packages to ELPA, with all the change in tools, modernism’s and workflows that entails.
He seriously believes this is important because MELPA isn’t GNU, and that’s all he cares about. It’s not enough to be open-source and free. You must be GNU, or it doesn’t matter.
He may add things of value still, but I refuse to believe it’s not overshadowed by all the backwardisms he constantly tries to impose on the core developers actually doing the dirty work.
> which is the opposite of leadership and the opposite of an experienced person providing valuable guidance to the community.
Following the discussion on Emacs-devel it does seem quite the opposite: you often see people with progressive ideas moderating themselves to not get too out of line with RMS. People (unconsciously?) try beating around the bush, to avoid touching GNU dogma, rather than going straight to the point, communicating efficiently.
While I really appreciate what FSF and GNU has done for computing, I believe the limitations Emacs-developers are putting on themselves by religiously denying to integrate with anything non-GPL (another Stallmanism) is going to hurt Emacs long-term, rather than benefitting GPLed software.
I guess time will tell.
Following the discussion on Emacs-devel it does seem quite the opposite: you often see people with progressive ideas moderating themselves to not get too out of line with RMS. People (unconsciously?) try beating around the bush, to avoid touching GNU dogma, rather than going straight to the point, communicating efficiently.
While I really appreciate what FSF and GNU has done for computing, I believe the limitations Emacs-developers are putting on themselves by religiously denying to integrate with anything non-GPL (another Stallmanism) is going to hurt Emacs long-term, rather than benefitting GPLed software.
I guess time will tell.
> How on earth was RMS unfamiliar with the existence of Org Mode [?]
It's not like he's been doing anything else for the last 30 years.
It's not like he's been doing anything else for the last 30 years.
It really depends on your needs. For modern development of projects with bloated file structures, having a hand-holding GUI like VSC that tames the file structure of the project really is nice.
If you're just occassionally dropping into headless filesystems to do some text editing, you're not going to invest in learning a new paradigm and you will likely use whatever default editor is presented to you. That is typically vim. For those who mindfully choose to set out and learn a new paradigm because they've decided to invest in a long-term time-saving skill, I doubt the vim/emacs divide is quite as stark as the numbers mentioned in the article.
If you're just occassionally dropping into headless filesystems to do some text editing, you're not going to invest in learning a new paradigm and you will likely use whatever default editor is presented to you. That is typically vim. For those who mindfully choose to set out and learn a new paradigm because they've decided to invest in a long-term time-saving skill, I doubt the vim/emacs divide is quite as stark as the numbers mentioned in the article.
The most unfixable UI problem for Emacs is that its rendering model works upon "character cells and cursor positions, not pixels."[1] No amount of effort would steer Emacs's UI away from an ortholinear matrix of characters. Whenever you install an LSP plugin on Emacs, you'll realize how badly it hurts readability and your eyes.
[1]https://m.facebook.com/notes/daniel-colascione/buttery-smoot...
When I started programming on ruby my laptop couldn’t handle IntelliSense and tests which required too much cpu and ram. So I’ve switched to vim on server through ssh. Later I’ve switched to emacs as it seemed to me more powerful than him back then.
After I got MacBook I’ve switched to TextMate utilizing powerful macOS keyboard shortcuts for text navigation. MacBook was pretty fast to handle ruby-related tasks.
Later I found myself in IntelliJ idea working on my Scala projects with emacs keybindings. I intuitively used emacs keybindings everywhere - from terminal to text fields in browser (without changing defaults!). Pretty comfortable until...
I started programming in Rust. It’s compiler and lsp servers use very much cpu, ram, compilation is really slow heating laptop like a frying pan. Here comes VSCode with vscode-remote which allows to write code on desktop gui while compiling, executing IntelliSense commands (lsp server to be exact), etc on a powerful cloud server. As I understand it executes everything remotely except GUI rendering and interaction. On network interruptions it restores connection seamlessly, I barely noticed. It was a salvation. VSCode has a bunch of predefined hotkeys which can be customized to fit my emacs-like navigation habits but there are always conflicts with some already existing bindings, also extension tend to add their own defaults. Too messy. Vim/emacs emulators are incomplete and buggy. This led me to weird trackpad&keybindings experience for navigating, building, debugging... Remembering how productive I was in vim/emacs I couldn’t handle this despite perfect state of the art vscode-remote.
So I decided to give vim/emacs a try, discover how ecosystem changed during 10+ years. After some investigation I’ve landed on neovim and tried to work on a rented server as I used to in my first programming years. Experience was far away from VSCode-remote. Due to network lags and ssh overhead I can’t be productive with all the benefits neovim offers. So I ended up buying a powerful home server, connecting to it from my MacBook and work in neovim over ssh. It’s ok but I really miss the “true” remote mode which offers local almost zero-latency editing with remote everything else. Renting powerful servers which has access to the whole dev infrastructure. Paying for them hourly. There are so many discussions about/plugins implementing VSCode and its extensions features in (neo)vim/emacs but in my opinion the really missing piece which don’t turn (neo)vim/emacs to VSCode but instead makes them as powerful as VSCode in cloud-powered code development. Am I the only one who miss this feature?
After I got MacBook I’ve switched to TextMate utilizing powerful macOS keyboard shortcuts for text navigation. MacBook was pretty fast to handle ruby-related tasks.
Later I found myself in IntelliJ idea working on my Scala projects with emacs keybindings. I intuitively used emacs keybindings everywhere - from terminal to text fields in browser (without changing defaults!). Pretty comfortable until...
I started programming in Rust. It’s compiler and lsp servers use very much cpu, ram, compilation is really slow heating laptop like a frying pan. Here comes VSCode with vscode-remote which allows to write code on desktop gui while compiling, executing IntelliSense commands (lsp server to be exact), etc on a powerful cloud server. As I understand it executes everything remotely except GUI rendering and interaction. On network interruptions it restores connection seamlessly, I barely noticed. It was a salvation. VSCode has a bunch of predefined hotkeys which can be customized to fit my emacs-like navigation habits but there are always conflicts with some already existing bindings, also extension tend to add their own defaults. Too messy. Vim/emacs emulators are incomplete and buggy. This led me to weird trackpad&keybindings experience for navigating, building, debugging... Remembering how productive I was in vim/emacs I couldn’t handle this despite perfect state of the art vscode-remote.
So I decided to give vim/emacs a try, discover how ecosystem changed during 10+ years. After some investigation I’ve landed on neovim and tried to work on a rented server as I used to in my first programming years. Experience was far away from VSCode-remote. Due to network lags and ssh overhead I can’t be productive with all the benefits neovim offers. So I ended up buying a powerful home server, connecting to it from my MacBook and work in neovim over ssh. It’s ok but I really miss the “true” remote mode which offers local almost zero-latency editing with remote everything else. Renting powerful servers which has access to the whole dev infrastructure. Paying for them hourly. There are so many discussions about/plugins implementing VSCode and its extensions features in (neo)vim/emacs but in my opinion the really missing piece which don’t turn (neo)vim/emacs to VSCode but instead makes them as powerful as VSCode in cloud-powered code development. Am I the only one who miss this feature?
I think what you're looking for is TRAMP [0,1]. After resisting it and continuing to ssh into remote hosts in a shell, I finally started to switch my workflows over, and the improvement is substantial. Async remote compiling might work out of the box in some cases, or it might require some additional configuration.
0. https://www.gnu.org/software/tramp/ 1. https://www.emacswiki.org/emacs/TrampMode
0. https://www.gnu.org/software/tramp/ 1. https://www.emacswiki.org/emacs/TrampMode
I have always used emacs inside tmux over ssh with <50ms latency to remote servers, I can barely perceive the difference in typing. As good as vscode remote capabilities are, it can't really beat having your editor local to your dev environment (in my case, emacs inside the server).
However, if you truly want your code editor to be local, vscode has truly become king for working with remote environments, nothing else comes close to it, it's really good. They have achieved this by installing a component on on the server that syncs with your local editor, which they won't open source of course.
However, if you truly want your code editor to be local, vscode has truly become king for working with remote environments, nothing else comes close to it, it's really good. They have achieved this by installing a component on on the server that syncs with your local editor, which they won't open source of course.
Making it more popular is going to make it worse. Already in this thread people want javascript shoved into it. Emacs can be improved in many ways, but if it strives to be popular the opposite will happen.
There is a human aspect to software, and when you forget that, and try to force people to adapt to software instead of adapting software to people, you come up with software that naturally is difficult and unpleasant for people to use.
Emacs is built on a philosophy of human nature that deemphasizes the subjective personal experience in favor of (a limited group of people’s theory of) the objective ideal experience.
In a short amount of time, VSCode and it’s ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.
Emacs is built on a philosophy of human nature that deemphasizes the subjective personal experience in favor of (a limited group of people’s theory of) the objective ideal experience.
In a short amount of time, VSCode and it’s ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.
> In a short amount of time, VSCode and it’s ecosystem has almost equally matched what Emacs and its ecosystem took 30+ years to create.
I'm not $o $ure that'$ actually a$ impre$$ive a$ it $ound$ ;)
I'm not $o $ure that'$ actually a$ impre$$ive a$ it $ound$ ;)
I think you're making the point that a majority of VS Code was funded by Microsoft, and therefore it can't be compared to Emacs which was either mostly or entirely coded by volunteers?
The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones have been made in a very small amount of time, but none have caught on because they lack the ecosystem and community. So it's only really fair to compare VS Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created by unpaid volunteers too.
The vast majority of Emacs's usefulness is its ecosystem. Several Emacs clones have been made in a very small amount of time, but none have caught on because they lack the ecosystem and community. So it's only really fair to compare VS Code's ecosystem with Emacs's ecosystem. And VS Code's ecosystem was created by unpaid volunteers too.
It has taken much more than 30+ years to create, mostly by people on their free time. Isn't it amazing? I think it says a lot about perseverance and good engineering. How many editors have you already seen to rise and fall?
Emacs tries very hard to be helpful. It's software by the people, for the people. It's the very core ideal of free software. But yes, it doesn't resonate with most people because it takes time to learn.
Emacs tries very hard to be helpful. It's software by the people, for the people. It's the very core ideal of free software. But yes, it doesn't resonate with most people because it takes time to learn.
Indeed, emphasizing the human aspect is the right thing to do.
Unless we do, emacs will slowly die.
No one wants that, neither RMS nor any passionate emacs user including me.
Unless we do, emacs will slowly die.
No one wants that, neither RMS nor any passionate emacs user including me.
VSCode doesn't do much of what I need to do, and what it does do, it doesn't do as well as Emacs can.
I've had Emacs open in my screen while I'm working for twenty mutter mutter years, and my keybindings have diverged enough where I can't use stock Emacs without stopping and carefully thinking about what I'm doing.
But that's sunk cost. I discourage young programmers from diving into it, for a couple of reasons. First, early in their career there are places where they will get a lot more leverage. Spend some time learning your text editor, sure, but at the five to ten hour mark that rabbit hole starts yielding swiftly diminishing returns. And second, everyone talks about shaping it to your workflow, but, in the end, Emacs is a terrible environment for writing UIs. Not everything is best interacted with as text in a terminal. In fact, most data is not. Compare org-mode with the best of breed todo apps like OmniFocus and Tasks. I use org-mode for my technical diary, and I use OmniFocus for my tasks. OmniFocus is simply better. GUIs with a mouse are a more efficient way to navigate most tasks on a computer that aren't programming.
Stallman mentioned preparing text for publishing. I'm probably unusual in that I have both typeset professionally (back in Quark XPress days) and gone really deep in to LaTeX (in my physics days). I've written and typeset two books. The technical text I did in LaTeX. Actually, I wrote the text in a mix of Scrivener and LyX, and then used Emacs for the final document. For what lies nicely in LaTeX, that's great. The other one I did in Adobe InDesign, and doing it in LaTeX in a text editor instead sounds like masochism. If you're willing to accept what LaTeX gives you, it's fabulous. If not, typesetting with Emacs and LaTeX is a simply inferior experience to using a proper typesetting program.
But that's sunk cost. I discourage young programmers from diving into it, for a couple of reasons. First, early in their career there are places where they will get a lot more leverage. Spend some time learning your text editor, sure, but at the five to ten hour mark that rabbit hole starts yielding swiftly diminishing returns. And second, everyone talks about shaping it to your workflow, but, in the end, Emacs is a terrible environment for writing UIs. Not everything is best interacted with as text in a terminal. In fact, most data is not. Compare org-mode with the best of breed todo apps like OmniFocus and Tasks. I use org-mode for my technical diary, and I use OmniFocus for my tasks. OmniFocus is simply better. GUIs with a mouse are a more efficient way to navigate most tasks on a computer that aren't programming.
Stallman mentioned preparing text for publishing. I'm probably unusual in that I have both typeset professionally (back in Quark XPress days) and gone really deep in to LaTeX (in my physics days). I've written and typeset two books. The technical text I did in LaTeX. Actually, I wrote the text in a mix of Scrivener and LyX, and then used Emacs for the final document. For what lies nicely in LaTeX, that's great. The other one I did in Adobe InDesign, and doing it in LaTeX in a text editor instead sounds like masochism. If you're willing to accept what LaTeX gives you, it's fabulous. If not, typesetting with Emacs and LaTeX is a simply inferior experience to using a proper typesetting program.
I'be been using Emacs for 17 years mostly for programming-related tasks. My opinions are:
- Emacs is an editor for people who think that learning some Lisp sounds fun if they don't know some already.
- Emacs should not bother trying to appeal to a more general audience; it's not an editor for most people when new to programming, and it's an editor for a very small minority of non-programmers.
- Emacs should focus on its strengths: it is the most powerful and extensible editor ever created. As long as it looks after that identity, it will always be highly respected.
- The infinite customizability via emacs lisp and the ecosystem of libraries is the only thing that can make Emacs more attractive than other editors.
- Emacs should be sleek, minimal, fast, and visually beautiful, by default.
- The customize interface is ugly and not a priority; it should be expected that Emacs users will configure things in Emacs Lisp.
- The clunky default icons and splash screen should be got rid of: present a blank screen with minimal tooling if a beautiful first impression cannot be created.
- Many of the elisp packages that ship with Emacs should be removed from the core, with users installing them as packages (Org-mode, Gnus, etc), leaving a more easily maintainable core.
- Emacs is an editor for people who think that learning some Lisp sounds fun if they don't know some already.
- Emacs should not bother trying to appeal to a more general audience; it's not an editor for most people when new to programming, and it's an editor for a very small minority of non-programmers.
- Emacs should focus on its strengths: it is the most powerful and extensible editor ever created. As long as it looks after that identity, it will always be highly respected.
- The infinite customizability via emacs lisp and the ecosystem of libraries is the only thing that can make Emacs more attractive than other editors.
- Emacs should be sleek, minimal, fast, and visually beautiful, by default.
- The customize interface is ugly and not a priority; it should be expected that Emacs users will configure things in Emacs Lisp.
- The clunky default icons and splash screen should be got rid of: present a blank screen with minimal tooling if a beautiful first impression cannot be created.
- Many of the elisp packages that ship with Emacs should be removed from the core, with users installing them as packages (Org-mode, Gnus, etc), leaving a more easily maintainable core.
I agree that a leaner core seems intuitively right. However, the discussion on emacs-devel has been in the other direction as of late https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01....
Thanks I skimmed that thread and the one this HN thread is about. There are so many depressing things. In particular this arrogant and utterly ignorant condemnation of Pull Request-based workflows infuriates me:
> A lot of people have not been contaminated by the entitlement that comes with the "I'm sending a PR, please check it in" generated by the Github culture.
I don't think the person who wrote that has even looked at the pull request review that goes on in high quality emacs packages on GitHub, let alone participated in it. This sort of thing really makes it clear that some of the people on emacs-devel are hopelessly out of alignment with the majority of the people would would willingly contribute to the emacs and emacs lisp package ecosystem.
There are many good reasons not to included packages in core Emacs. A big one is that package authors are working in their own free time and don't want or need to have to prepare an especially bug-free release to coincide with Emacs release cycles. Also they don't want to support users using the old version that is in Emacs.
> A lot of people have not been contaminated by the entitlement that comes with the "I'm sending a PR, please check it in" generated by the Github culture.
I don't think the person who wrote that has even looked at the pull request review that goes on in high quality emacs packages on GitHub, let alone participated in it. This sort of thing really makes it clear that some of the people on emacs-devel are hopelessly out of alignment with the majority of the people would would willingly contribute to the emacs and emacs lisp package ecosystem.
There are many good reasons not to included packages in core Emacs. A big one is that package authors are working in their own free time and don't want or need to have to prepare an especially bug-free release to coincide with Emacs release cycles. Also they don't want to support users using the old version that is in Emacs.
The Emacs community has held itself back by continuing the line of thought of resisting anything that fundamentally changes what they already have spent years learning and know. It's their power tool, and using tools is important for humans to do their craft. So I understand why they don't want anything to change.
Meanwhile new generations of people have different tools and aren't held onto these past ones because they didn't start with it (and they weren't coding in the 80s). The world of computing generally has moved on with new ideas, new experiences, and new form factors. So their new tooling has won them over, and outcompeted a dying generation.
This is a good thing! It's called progress. Unless Emacs is willing to have fresh blood decide a new direction for it, it will be relegated to history. If Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either you are willing to fundamentally change with the times, or you aren't. Emacs has shown they aren't, and they've had over three decades to do so. Fortunately others will in their place!
Meanwhile new generations of people have different tools and aren't held onto these past ones because they didn't start with it (and they weren't coding in the 80s). The world of computing generally has moved on with new ideas, new experiences, and new form factors. So their new tooling has won them over, and outcompeted a dying generation.
This is a good thing! It's called progress. Unless Emacs is willing to have fresh blood decide a new direction for it, it will be relegated to history. If Apple held onto its Apple II vision, we wouldn't have the iPhone today. Either you are willing to fundamentally change with the times, or you aren't. Emacs has shown they aren't, and they've had over three decades to do so. Fortunately others will in their place!
I can imagine a few ways emacs could be improved, but "a new direction for it," I can't.
xemacs, microemacs, memacs, etc have tried new directions in different ways.
ultimately, emacs improved because of them.
ultimately, emacs improved because of them.
And that's why it'll slowly go extinct.
Newness contradicts creativity, because the creative process needs to result in objects that last. In fact, because new designs create a future need for more new designs, it cannot last by definition!
Think of shops that sell novelty items. Newness at an object level looks like novelty items. What is the quality of novelty items? How long do novelty items last?
Think of shops that sell novelty items. Newness at an object level looks like novelty items. What is the quality of novelty items? How long do novelty items last?
I don't understand your point. We're not talking about physical things, we're talking about software. Software is always changing, morphing, adopting, and growing user bases. It's what's amazing about it compared to hardware. My 2012 MBP runs the latest OS from approximately 8 years later, and with it a whole new slew of features and additions that both Apple and the rest of the world have brought it. Why be stuck in the past?
> Why be stuck in the past?
I surely would want to go back to the pre-corona days.
I surely would want to go back to the pre-corona days.
There's truth to that - we do not feel the need to 'upgrade' Mozart's or Titian's works, they feel just as interesting as they did when they were created (if not even more; and I am not talking about a "purely historical interest").
emacs is Lindy. VS Code will go extinct before Emacs.
(https://en.wikipedia.org/wiki/Lindy_Effect)
(https://en.wikipedia.org/wiki/Lindy_Effect)
We don’t know when vscode will or won’t go extinct. It’s less distinct than other similar editors in comparison to emacs, so the switching cost is a lot lower. But my point being isn’t that vscode will somehow be “the great winner,” but rather that new things will come and continue to replace the old.
Emacs has/had the option of changing with the times. They’ve opted out of that. So most newcomers will opt out of emacs, and thus it’ll slowly die out.
Emacs has/had the option of changing with the times. They’ve opted out of that. So most newcomers will opt out of emacs, and thus it’ll slowly die out.
[deleted]
How much can Emacs change while still being Emacs? Is it worthwhile to start building a new editor on the core Emacs "idea"? Because I think minor changes will not move the needle. Someone compared it with the birth of Firefox, scrapping Netscape Mozilla Communicator or whatever it was called. I think that is what it would take but even that would be uncertain.
I have used emacs for decades so I do not see the need for a big restart, but your question does remind me of something RMS said years ago. I cannot find the exact quote, but the essence of it was that any editor that offered the programmability of emacs was worthy of the name regardless of its keybindings, etc. In that sense I do not believe there would be any problem with emacs following the model of Fortran; it can look and behave quite different, but at its core it has to be open and accessible for the user to extend and adapt.
It's still popular with me :)
In fact instead of being in either the vi or emacs camp, I use both. I also use Eclipse.
Each of them for the task at hand.
In fact instead of being in either the vi or emacs camp, I use both. I also use Eclipse.
Each of them for the task at hand.
Eclipse was designed and named to piss Sun off, and it worked.
Fun fact about the Eclipse name, thanks.
> 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.
> Terminal-based Vim is not like a modern application, yet is more popular than Emacs.
I think what happens here is that when someone decides they want to invest the time to learn an advanced editor, most of that subset of people end up choosing vi. Emacs is not approachable enough to appeal to people who don't fall in that group, and vi has more obvious productivity wins for someone who does enter that group, since its focus is on velocity-of-editing rather than extensibility, the latter of which is not even that unique any more (see VSCode/Atom).
> Terminal-based Vim is not like a modern application, yet is more popular than Emacs.
I think what happens here is that when someone decides they want to invest the time to learn an advanced editor, most of that subset of people end up choosing vi. Emacs is not approachable enough to appeal to people who don't fall in that group, and vi has more obvious productivity wins for someone who does enter that group, since its focus is on velocity-of-editing rather than extensibility, the latter of which is not even that unique any more (see VSCode/Atom).
I've spend 4 years mastering vim and I can definitely say I could have spent that time better elsewhere. I'm pretty sure Emacs would be the same waste of my time. These editors have a very steep learning curves and require a lot of effort to master.
Don't buy into the meme, at the end of the day they are just text editors.
Don't buy into the meme, at the end of the day they are just text editors.
It took me maybe a few hours to learn vim and I could be decently productive in it. After that I just learnt through exploration.
For me it was definitely worthwhile. Vim is almost everywhere so I can easily edit text wherever I go.
For me it was definitely worthwhile. Vim is almost everywhere so I can easily edit text wherever I go.
Not to be divisive but I see a parallel here with what happened in the gaming industry. As it became more popular and socially acceptable, the quality of games went down, from the perspective of people who played games when they were unpopular. Eg. baldurs gate vs fortnite. Development is now fueled by an insatiable industry demand and fairly high salaries, and a lot of offshoring to desperate countries where it’s a way out. The taste of people who only write software in the context of cultural cache and a salary is always going to be different from that of people attracted to something for its own sake.
This conversation even reflects that- Too comment how many days before I can be productive for X company in JavaScript from scratch? That’s not a question I’m interested in but it’s been accepted as the most interesting question here.
This conversation even reflects that- Too comment how many days before I can be productive for X company in JavaScript from scratch? That’s not a question I’m interested in but it’s been accepted as the most interesting question here.
How do you make scrolling to work not line-by-line but pixel-by-pixel in... MacOS and Ubuntu? There’s some arcane installs that are each incrementally better than the next one but none match the native scrolling experience you’d usually see in a modern/graphical text editor
What makes Emacs attractive to me is that it's a programming environment which you can modify on the fly. At least, that's what I have read, I've never actually done it myself.
Visual Studio Code, the editor that I use daily, is based on Javascript (Typescript) but I have yet to see a page by Microsoft explaining to me that I can quickly whip up a script and execute it in my editor. From what I understand you need to create an extension and I think that takes a bit of setup.
A spiritual successor to Emacs could be an extensible editor based on a language which you can interpret on the fly, modifying your environment as you go along. That's what would make Emacs more attractive to me, along with modern keybindings like arrow keys...
Visual Studio Code, the editor that I use daily, is based on Javascript (Typescript) but I have yet to see a page by Microsoft explaining to me that I can quickly whip up a script and execute it in my editor. From what I understand you need to create an extension and I think that takes a bit of setup.
A spiritual successor to Emacs could be an extensible editor based on a language which you can interpret on the fly, modifying your environment as you go along. That's what would make Emacs more attractive to me, along with modern keybindings like arrow keys...
FWIW, Emacs does support navigation via arrow keys by default, unless I am misunderstanding what you mean.
Ten minutes after I posted my message I just realized that the concept of a Macro has been around since the dawn of computing and is in large part responsible for the meteoric rise of Microsoft (along with a lot of viruses)
What I mean is I'm looking for a editor with macro capabilities that can be programmed in, say, Javascript, Python or Lua.
What I mean is I'm looking for a editor with macro capabilities that can be programmed in, say, Javascript, Python or Lua.
Neovim is an editor with macro capabilities, which can be programmed in LuaJIT.
It's my terminal editor of choice, and yes, arrow keys work. But why would you want to use them?
It's my terminal editor of choice, and yes, arrow keys work. But why would you want to use them?
I've been using vim for 15 years so I know neovim.
But ... can you make changes in neovim while it's running?
Let me take it a step further. Imagine a text editor in which you can, while it's running, literally go into its source code and make changes and that those changes immediately take effect. If I'm not mistaken you can do that in emacs. That's what I find intriguing about it, not the text editor.
But ... can you make changes in neovim while it's running?
Let me take it a step further. Imagine a text editor in which you can, while it's running, literally go into its source code and make changes and that those changes immediately take effect. If I'm not mistaken you can do that in emacs. That's what I find intriguing about it, not the text editor.
I believe so, yes.
Neovim is less programmable than Emacs insofar as more of it is written in C, it's substantially less documented, and Emacs has a substantial head start.
But yeah, still fundamentally a programmable text editor. If you wanted to set up a file watcher over source code that automatically reloads it when files change, there's nothing stopping you.
It's true that nothing other than Emacs is quite like Emacs. Neovim is evolving in the right direction though.
Neovim is less programmable than Emacs insofar as more of it is written in C, it's substantially less documented, and Emacs has a substantial head start.
But yeah, still fundamentally a programmable text editor. If you wanted to set up a file watcher over source code that automatically reloads it when files change, there's nothing stopping you.
It's true that nothing other than Emacs is quite like Emacs. Neovim is evolving in the right direction though.
Emacs 100% lacks a reasonable sidebar strategy. I use Visual Studio Code's sidebar for 3 things, navigation via search, navigation via changed files, navigation via directory tree. It is very fast to use all of those, even though they are mouse oriented.
The only comparably fast and useful ripgrep that works out of the box in Emacs is swiper, but it uses a temporary buffer. Deadgreap is great but you have to harangue it behave in a similar way to the sidebar in vs code and even then it's just not the same.
The other thing is emacs regexps suck and PCRE is the standard of every well used regexp implementation in the world at this point and emacs ought to find a way to transition to it.
The only comparably fast and useful ripgrep that works out of the box in Emacs is swiper, but it uses a temporary buffer. Deadgreap is great but you have to harangue it behave in a similar way to the sidebar in vs code and even then it's just not the same.
The other thing is emacs regexps suck and PCRE is the standard of every well used regexp implementation in the world at this point and emacs ought to find a way to transition to it.
You can use keyboard for all of those things in VS Code, just by the way :)
(On the team)
(On the team)
Awesome. Y'all do great work. I have a couple of questions if you are checking this thread:
1. Do y'all do security analysis on extensions? Static analysis etc? Specifically, I am talking about detecting potential source exfiltration type stuff.
2. Any chance you'll develop the ability to customize the editor via some personal scripts vs a plugin? I'd like to implement a command to do a specific thing (toggle between test and implementation in a rails project) but I don't want to go through the process of creating a plugin... I just want to map a shortcut to a TypeScript function. I know there is a couple of extensions that try to enable this but it would be nice to have an official path to doing these kinds of personal customizations.
1. Do y'all do security analysis on extensions? Static analysis etc? Specifically, I am talking about detecting potential source exfiltration type stuff.
2. Any chance you'll develop the ability to customize the editor via some personal scripts vs a plugin? I'd like to implement a command to do a specific thing (toggle between test and implementation in a rails project) but I don't want to go through the process of creating a plugin... I just want to map a shortcut to a TypeScript function. I know there is a couple of extensions that try to enable this but it would be nice to have an official path to doing these kinds of personal customizations.
1) see info here: https://code.visualstudio.com/docs/editor/extension-gallery#... I’m not going to say more here, but if you post an issue someone will get back to you. :)
2. I’d recommend just finding an extension that does this. It wouldn’t be hard for an extension to implement, and supporting multiple extensibility classes in core when we don’t need to probably won’t happen. What exactly are you looking for in an “official path“?
2. I’d recommend just finding an extension that does this. It wouldn’t be hard for an extension to implement, and supporting multiple extensibility classes in core when we don’t need to probably won’t happen. What exactly are you looking for in an “official path“?
In Emacs land, ~/.emacs is executed as an arbitrary code. I would like to be able to have a ~/.vscode.ts that contain a function and I would like to map that function to command+t. It doesn't seem like a stretch to offer that feature. Right now I have to use something like this:
https://marketplace.visualstudio.com/items?itemName=ego-digi...
https://marketplace.visualstudio.com/items?itemName=ego-digi...
I encourage you to look into writing extensions, an extension which simply registers a command that executes some script at a fixed location would be a good starting point for learning.
I still consider myself an emacs user even though I haven't used it for over a decade (or 2?).
For me emacs is from a time where text was king - the productivity to use Emacs for my entire work process - latex docs, coding and debug in multiple languages, reading email, accessing remote systems (gdbserver, scp, ftp, even gopher and the web) from within emacs without using the mouse was astounding.
But as things become more graphical - rich text email was the first, then the web, UML, word/excel etc it became less useful.
Emacs feels like a long lost lover - sweet memories from a distant past, but you can't go back.
For me emacs is from a time where text was king - the productivity to use Emacs for my entire work process - latex docs, coding and debug in multiple languages, reading email, accessing remote systems (gdbserver, scp, ftp, even gopher and the web) from within emacs without using the mouse was astounding.
But as things become more graphical - rich text email was the first, then the web, UML, word/excel etc it became less useful.
Emacs feels like a long lost lover - sweet memories from a distant past, but you can't go back.
First of all I really like the value of Emacs as a modern lisp machine. And it is the best environment to write in any lisp language.
But for anything else it is not good enough. Emacs Lisp is better then vimscript but only if you are extending it. For just configuration I prefer vimscript because it is so terse.
But IMO just better then vimscript is setting the bar too low. Imagine if it had something like Neovim's msgpack and you could extend it in any language you like. I am still hopeful something like that will happen.
But for anything else it is not good enough. Emacs Lisp is better then vimscript but only if you are extending it. For just configuration I prefer vimscript because it is so terse.
But IMO just better then vimscript is setting the bar too low. Imagine if it had something like Neovim's msgpack and you could extend it in any language you like. I am still hopeful something like that will happen.
It would be cool to have package statistics to know which packages are more popular/used. The community is too fragmented at this moment, and there are too many competing packages. While it's good to have diversity, having package statistics will make it easier to choose the best packages for end-users and package developers will focus on improving the most used packages. It will also improve compatibility between packages.
Or is this already implemented? VS Code does it and it's a good feature.
Or is this already implemented? VS Code does it and it's a good feature.
I love Emacs. I don't use it beyond dabbling. The contradiction? I'm not a full-time computer professional. Keeping Emacs stable and running just takes too much bandwidth. It's a tool for dedicated professionals who get a massive return on their investment spent optimizing and maintaining their Emacs setup. Sadly as much as I love the idea of Emacs, I don't personally get enough productivity return to justify the investment. It's not a flaw with Emacs.
> I'm not a full-time computer professional.
Emacs is used by non-computer professionals as well. If your profession relies on the manipulation of text, emacs is the tool to use.
>their investment spent optimizing and maintaining their Emacs setup.
It's really not that bad. Say you're a fiction writer: you only need to figure out your preferred workflow once, but then you can use it for decades with only minimal changes.
Of course, once you get the hang of it, you might think it convenient to be able to write short mails directly, or do a bit of your own typesetting all from the comfort of your, by now, favourite editor, but .emacs files usually see very little churn. What's in a .emacs has usually just accumulated slowly over the years as one's usage of the program increases.
Emacs is used by non-computer professionals as well. If your profession relies on the manipulation of text, emacs is the tool to use.
>their investment spent optimizing and maintaining their Emacs setup.
It's really not that bad. Say you're a fiction writer: you only need to figure out your preferred workflow once, but then you can use it for decades with only minimal changes.
Of course, once you get the hang of it, you might think it convenient to be able to write short mails directly, or do a bit of your own typesetting all from the comfort of your, by now, favourite editor, but .emacs files usually see very little churn. What's in a .emacs has usually just accumulated slowly over the years as one's usage of the program increases.
You only have to setup Emacs once, there's no maintenance involved.
IDEs come and go, Emacs stays.
Turbo Pascal (wayyy back) was quite impressive (then), Visual Age for Java much more so some fifteen years later. IntelliJ is alright (prefer it over Eclipse, which somehow managed to lose the smart features of its predecessor). Haven't tried VS Code yet, but from the videos I've seen, it seems quite handy.
I stick with Emacs for two reasons: familiarity and SLIME (the next best thing to a LISP Machine ;-}
Turbo Pascal (wayyy back) was quite impressive (then), Visual Age for Java much more so some fifteen years later. IntelliJ is alright (prefer it over Eclipse, which somehow managed to lose the smart features of its predecessor). Haven't tried VS Code yet, but from the videos I've seen, it seems quite handy.
I stick with Emacs for two reasons: familiarity and SLIME (the next best thing to a LISP Machine ;-}
It seems to me that productivity is the assumed goal. But that is not the whole story. I also enjoy using Emacs. I appreciate and support its commitment to free software. I like that everything is customisable.
Also, I wonder if it would be possible to do a study on productivity between IDEs. It seems to me much of the data would be measurable. One idea would be to allow github users to state their IDE.
Also, I wonder if it would be possible to do a study on productivity between IDEs. It seems to me much of the data would be measurable. One idea would be to allow github users to state their IDE.
I still use enacts for all my coding (with cua mode on), mostly because I have yet to find another tool that does context sensitive indentation quite right. And I suppose I’m just used to it. But I don’t actually use most of the power features. I mean code is just text; all i really need is normal editing, and the occasional search and replace. I also use org mode for all my notes.
Maybe not the appropriate forum but does anyone have a sane setup for the insane javascript setup of modern times?
I love emacs and am willing to put the time into tooling and configuration. But despite several hopeful attempts, I’ve been unable to manage anything comparable to vscode for this environment.
That is, support for all versions of ecmascript, but also jsx, typescript, et al.
I love emacs and am willing to put the time into tooling and configuration. But despite several hopeful attempts, I’ve been unable to manage anything comparable to vscode for this environment.
That is, support for all versions of ecmascript, but also jsx, typescript, et al.
Sorry I don't use emacs, but Vim/Neovim is pretty easy to setup with coc and all it's subextensions for stuff like eslint, tailwind, vue and whatever. It's essentially just the VSCode language server running in Vim and it's awesome.
I appreciate the input and will look into the VSCode language server.
I’ve found tide-mode + rjsx-mode was mostly sufficient to bring me back to emacs after a short time with vscode
Here’s the relevant lines of my config. https://github.com/fiddlerwoaroof/dotfiles/blob/master/emacs...
I thought it was a bit laggy at first, but when I went back to VSCode, I noticed that all the issues I thought were emacs problems were present in vscode as well.
I thought it was a bit laggy at first, but when I went back to VSCode, I noticed that all the issues I thought were emacs problems were present in vscode as well.
Thank you, I’ll be giving it a try!
One thing I've noticed is that I'm using not only Emacs but other editors, I really like Org-mode for notes and cider-mode for Clojure but I find myself switching to other editors including vim and VS Code when doing other tasks.
Perhaps something like Spacemacs but built around CUA-mode with a nice default theme and menus will win people to the platform.
Perhaps something like Spacemacs but built around CUA-mode with a nice default theme and menus will win people to the platform.
I've been a vi user for about 30 years. Once, a few years back, I decided to force myself to use emacs for a year to see if I could understand what people saw in it. Once I realized, 10 months in, that I was counting the days before I would "let" myself use vi again, I finally threw in the towel and bailed on emacs.
If they could make some kind of a visual layer that makes it look like Word and Photoshop (not in the same time, I'm being realistic here), their name would be remembered in eternity.
Of course, emulating the shortcuts & functionality of Word and Photoshop shouldn't be considered a problem, we are talking Emacs here after all...
Of course, emulating the shortcuts & functionality of Word and Photoshop shouldn't be considered a problem, we are talking Emacs here after all...
Oh, if Emacs ever implement that visual layer, I don't think it’s unrealistic to expect it to looks like Photoshop _and_ Word at the same time.
Emacs already have a concept of frame, and you can already configure each frame independently (e.g. for term and X), all connecting to a single Emacs process, and can share buffers/yank ring/etc. across multiple frames.
Emacs already have a concept of frame, and you can already configure each frame independently (e.g. for term and X), all connecting to a single Emacs process, and can share buffers/yank ring/etc. across multiple frames.
A closer example might be autocad (at least older versions). You could do everything with a mouse, but a true expert could type the plans for a building faster than you can imagine.
Yes, that's why it's fishy that GIMP doesn't emulate the Photoshop shortcuts/menu structure.
But any arguments regarding word editing in latex markup I won't accept.
But any arguments regarding word editing in latex markup I won't accept.
I used to use emacs daily, but nowadays sticking to "mg" and "vscode"...
Org mode is really good for note taking, so emacs has uses even if one does not use it for programming.
I gave it an honest try for 6 months and even as good as Org-mode is (I used it to track project tasks, notes, timelogs, even had a go at custom templates), the 80s design choices and trying to find information that didn't expect a full working knowledge pushed me away from Emacs, might have been made worse trying to do this on "the devil's OS".
I'd have loved to have been able to give magit a go.
I do still have Orgzly on my phone though.
I'd have loved to have been able to give magit a go.
I do still have Orgzly on my phone though.
Used emacs for years, switched to VSC as it's just more compatible with the present time in terms of plugins, languages, and even simply working with other people. Emacs is a thing of the past. I do really miss the kill-ring though.
I like Vim better because it's easier for me to press one key to do an action or write :command. I can also use Vim on the mobile (Termux and other terminals). Having to press CTRL+A CTRL+whatever doesn't make sense IMO.
I attempted to learn Emacs first, then settled into VSCode+Vim.
I even tried recently, but failed again.
So, please share some good resource for learning emacs. That is the biggest issue with trying emacs to see if it suits.
As it cannot be tried, its not considered.
Please suggest.
I even tried recently, but failed again.
So, please share some good resource for learning emacs. That is the biggest issue with trying emacs to see if it suits.
As it cannot be tried, its not considered.
Please suggest.
Just got a new Mac computer with Catalina pre-installed, and was surprised to see
zsh: command not found: emacs
I imagine that Apple is trying to remove GPL-licensed software from macOS. Similar to the replacement of Bash (GPL) in favour of Zsh (MIT).
It used to be. But on a lot of default linux installs its not installed by default either.
then you have to pick a emacs...
https://askubuntu.com/questions/297170/how-to-install-emacs-...
For some reason I now have 2 versions installed on my pop-os, (I know to pick the first one when I launch from a gui..)
I love the editor, I really like the macros, and can move around and do my editing quick.
but I've been using it 10+ years and have NO idea if I'm using it correctly.
Certain modes aren't installed depending on and its just kinda obtuse. "Space emacs"? How do install a plug-in again.. where is my .emacs config file? is it init.el? ...
sigh..
then you have to pick a emacs...
https://askubuntu.com/questions/297170/how-to-install-emacs-...
For some reason I now have 2 versions installed on my pop-os, (I know to pick the first one when I launch from a gui..)
I love the editor, I really like the macros, and can move around and do my editing quick.
but I've been using it 10+ years and have NO idea if I'm using it correctly.
Certain modes aren't installed depending on and its just kinda obtuse. "Space emacs"? How do install a plug-in again.. where is my .emacs config file? is it init.el? ...
sigh..
[deleted]
The which-key feature (whos you key bindings by pressing the first key) of doom and spacemacs is great for discoverability but would be infinitely better if they also had a key binding instant search.
I'm not programmer, but I'm interested in emacs because someone say it can be devonthink alternative, tried spacemacs, for a weeks, still don't understand how its behave
If it was a tool to be mastered, there should be a way to learn it. Unfortunately, due to the many, many ways to customize it, I struggle to see a clear path to emacs mastery.
First we need to make Common Lisp popular. Since it's nigh impossible to write Common Lisp in any other editor, Emacs will certainly experience a surge of popularity.
Awesome! I haven't seen a good "Emacs vs. x" thread in years!! People are coming out swinging as well! Woohoo! Where's the popcorn??
I will repeat what others said but here we go.
On my work pc, on windows, VSCodium works much better when it comes to graphics.
Firefox mode for Emacs would make me never leave emacs for anything else.
Multi threaded Emacs would be very nice as well.
Multi threaded Emacs would be very nice as well.
[deleted]
one reason i did not use EMACS is it is a bit slow in my Mac air, maybe i should buy a better machine.
Emacs works poorly on Windows, that is the only reason I don't use it.
I tried to learn emacs but after the week of struggling through arcane keybindings and the bizzare quirks I just noped. Emacs is cool but it did not age well in a way that any software with three decade+ history would.
[deleted]
They need to restore the foot pedal options.
Better defaults on the vanilla installation would be a nice.
Apart from that: How dare you criticize a god?
Apart from that: How dare you criticize a god?
Emacs is awesome. The default setup is near useless. Elisp is really not exciting.
Folks, I want to disabuse you of the notion that in order for Emacs to be any good in 2020, it needs to be "modern". It needs a modern UI. Emacs Lisp should be replaced with a modern language like JavaScript. Its display backend should be replaced with something modern like embedding a browser engine and rendering to HTML5. (I have literally seen this suggested on /r/emacs). At any rate it should be accessible via a browser in the cloud, because in the future everybody will develop in the cloud. If somehow the maintainers do all of these, then it would only serve to effectively transform Emacs into Visual Studio Code, and it would make a shitty clone of Visual Studio Code at that. So ｍｏｄｅｒｎ. There are parallels with the efforts, started in the late 90s, to make Linux into an inferior clone of Microsoft Windows to increase its popularity.
The problem is, much of what today's twentysomething webdevs consider modern is mere fad. It is not objectively better (and is sometimes objectively worse) in terms of user affordance than what we had in the 90s. The current trends in UI design obscure distinctions which were bloody obvious in the days of bevelled gray buttons. Browser engines run like pigs, especially when compared with simple bit-mapped windows, and developing in the cloud hits a brick wall when your network connection goes down.
I want you to try something. Try to imagine Emacs not as an ancient editor in need of modernization, but as a programmers' tool from the future. It may be a grim future indeed, one in which programmers learned some harsh lessons -- that not all programming is webdev, and the dominance of webdev in the field today is likely to be short-lived; that CPU and RAM are cheap, but not free; that networks go down; that software the user can't examine and completely control is software that is potentially hostile to the user; that the job of a program's UI is to enable work and not to dazzle the user; and that programmers have a higher duty to expand their users' minds, making them capable of more than when they started, and not to simperingly cater to 1984's notions of what an absolute beginner should experience. (The implications of the fact that Stallman learned many of these in the 70s and 80s is left as an exercise.)
But a program from far enough in the future is just as incomprehensible to today's users (especially today's generation-Z webdevs) as a program from the distant past, the difference being that the future program is likely to be much, much more advanced -- and today's users can learn a lot by understanding it on its own terms as they try to unlock its secret power. So it is with Emacs -- an omni-tool designed to be shaped and sculpted by the user into just the thing for the task at hand as the user works with it. No kidding --hacking something together in Emacs Lisp is so easy, for many data munging tasks it compares favorably to regular Lisp. Such hacks may not be beautiful or elegant or even production-ready, but if they let you get a job done quickly, they're valid. When you combine Lisp's eldritch power with the ubiquitous buffer abstraction and all that enables, you have a juggernaut for information workflow optimization -- and by comparison, Visual Studio Code is explicitly designed not to be extensible in such an ad hoc fashion.
Try this in your editor: Emacs has a command M-. If you are working on some Emacs Lisp and you type M-. on a symbol with a function binding, Emacs will jump to the function definition, opening the file it's compiled in if necessary. If you keep drilling down like this, eventually you will hit bedrock: the primitive functions of Emacs implemented in C. If you compiled your Emacs from source, and you say M-. on one of these, Emacs will remember where its own source lives and take you straight to the C file and line where the primitive is defined. This, my friends, is the quintessence of open source.
Plus, Emacs can talk to text terminals and bitmapped displays, and almost everything works the same either way. When I finally get my VT330 working, I'm going to hook it up to my sweet-ass Ryzen box, fire up Emacs, and take advantage of all its modern -- nay, futuristic -- power from my 1980s terminal. Why? Because I can. More practically, this means Emacs can communicate with its user over very low bandwidth channels -- making it ideal for working with remotely, cloud or otherwise.
And all this in an editor, several instances of which can be supported by a cheapass SBC like the Raspberry Pi. It's a bloody miracle of design, even as its hackishness is made manifest.
Emacs doesn't need to be changed to suit the whim and caprice of today's developers. Emacs is eternal, an emanation of the Tao; if it were to somehow disappear, somehow some way we would re-make it from scratch. It's not without faults, it can be improved, but the ideas behind it are transcendent and unmoving, and should not be compromised in favor of webdev fads. Let it shine forth like a beacon unto the void, and let its luminousness enlighten all those who are drawn to it.
The problem is, much of what today's twentysomething webdevs consider modern is mere fad. It is not objectively better (and is sometimes objectively worse) in terms of user affordance than what we had in the 90s. The current trends in UI design obscure distinctions which were bloody obvious in the days of bevelled gray buttons. Browser engines run like pigs, especially when compared with simple bit-mapped windows, and developing in the cloud hits a brick wall when your network connection goes down.
I want you to try something. Try to imagine Emacs not as an ancient editor in need of modernization, but as a programmers' tool from the future. It may be a grim future indeed, one in which programmers learned some harsh lessons -- that not all programming is webdev, and the dominance of webdev in the field today is likely to be short-lived; that CPU and RAM are cheap, but not free; that networks go down; that software the user can't examine and completely control is software that is potentially hostile to the user; that the job of a program's UI is to enable work and not to dazzle the user; and that programmers have a higher duty to expand their users' minds, making them capable of more than when they started, and not to simperingly cater to 1984's notions of what an absolute beginner should experience. (The implications of the fact that Stallman learned many of these in the 70s and 80s is left as an exercise.)
But a program from far enough in the future is just as incomprehensible to today's users (especially today's generation-Z webdevs) as a program from the distant past, the difference being that the future program is likely to be much, much more advanced -- and today's users can learn a lot by understanding it on its own terms as they try to unlock its secret power. So it is with Emacs -- an omni-tool designed to be shaped and sculpted by the user into just the thing for the task at hand as the user works with it. No kidding --hacking something together in Emacs Lisp is so easy, for many data munging tasks it compares favorably to regular Lisp. Such hacks may not be beautiful or elegant or even production-ready, but if they let you get a job done quickly, they're valid. When you combine Lisp's eldritch power with the ubiquitous buffer abstraction and all that enables, you have a juggernaut for information workflow optimization -- and by comparison, Visual Studio Code is explicitly designed not to be extensible in such an ad hoc fashion.
Try this in your editor: Emacs has a command M-. If you are working on some Emacs Lisp and you type M-. on a symbol with a function binding, Emacs will jump to the function definition, opening the file it's compiled in if necessary. If you keep drilling down like this, eventually you will hit bedrock: the primitive functions of Emacs implemented in C. If you compiled your Emacs from source, and you say M-. on one of these, Emacs will remember where its own source lives and take you straight to the C file and line where the primitive is defined. This, my friends, is the quintessence of open source.
Plus, Emacs can talk to text terminals and bitmapped displays, and almost everything works the same either way. When I finally get my VT330 working, I'm going to hook it up to my sweet-ass Ryzen box, fire up Emacs, and take advantage of all its modern -- nay, futuristic -- power from my 1980s terminal. Why? Because I can. More practically, this means Emacs can communicate with its user over very low bandwidth channels -- making it ideal for working with remotely, cloud or otherwise.
And all this in an editor, several instances of which can be supported by a cheapass SBC like the Raspberry Pi. It's a bloody miracle of design, even as its hackishness is made manifest.
Emacs doesn't need to be changed to suit the whim and caprice of today's developers. Emacs is eternal, an emanation of the Tao; if it were to somehow disappear, somehow some way we would re-make it from scratch. It's not without faults, it can be improved, but the ideas behind it are transcendent and unmoving, and should not be compromised in favor of webdev fads. Let it shine forth like a beacon unto the void, and let its luminousness enlighten all those who are drawn to it.
I heard it is called VS Code nowadays
One thing is to make the keyboard shortcuts better.
Get rid of the ancient and archaic method of Ctrl-C to start a command chord. Reserve that for basic commands like copy and paste.
Instead, use the slash, Ctrl-/ to start a command chord. This way, you can use all the nifty shortcuts you want, and still not interfere with common commands.
Another feature is to use Ctrl-Spacebar to allow a search of command aliases.
Like, highlight your words, then hit Ctrl-Spacebar, then type “upper”, and it’ll do a dynamic search for all matches, and one of those matches is to make the selection uppercase.
This can be useful for all types of commands and personalized macros.
But then, the other problem for Emacs, is that Visual Studio Code is pretty damn good. And it also works on Linux. Its memory footprint is really high, taking about 85 MBs of RAM, but Emacs takes like 30 MBs, so it’s less than 3x more, for much better features. But, it’s not like I’m using a 20 year old laptop anymore.
Get rid of the ancient and archaic method of Ctrl-C to start a command chord. Reserve that for basic commands like copy and paste.
Instead, use the slash, Ctrl-/ to start a command chord. This way, you can use all the nifty shortcuts you want, and still not interfere with common commands.
Another feature is to use Ctrl-Spacebar to allow a search of command aliases.
Like, highlight your words, then hit Ctrl-Spacebar, then type “upper”, and it’ll do a dynamic search for all matches, and one of those matches is to make the selection uppercase.
This can be useful for all types of commands and personalized macros.
But then, the other problem for Emacs, is that Visual Studio Code is pretty damn good. And it also works on Linux. Its memory footprint is really high, taking about 85 MBs of RAM, but Emacs takes like 30 MBs, so it’s less than 3x more, for much better features. But, it’s not like I’m using a 20 year old laptop anymore.
> Instead, use the slash, Ctrl-/ to start a command chord
This has an obscure problem, of which you were no doubt unaware.
In the terminal, Ctrl-/ sends backspace. Emacs isn't commonly used in the terminal anymore, but it can't become useless in the terminal, and this change would make it useless.
Unfortunately this is a non-starter.
This has an obscure problem, of which you were no doubt unaware.
In the terminal, Ctrl-/ sends backspace. Emacs isn't commonly used in the terminal anymore, but it can't become useless in the terminal, and this change would make it useless.
Unfortunately this is a non-starter.
Then use the dot: Ctrl-.
^. just sends .
The ASCII page on Wikipedia does a good job of explaining what all these limitations are about. There's CSI-u mode, and I believe terminal emacs understands it if you enable it, but, yeah. There's a lot of legacy to support when your program is older than Unix.
The ASCII page on Wikipedia does a good job of explaining what all these limitations are about. There's CSI-u mode, and I believe terminal emacs understands it if you enable it, but, yeah. There's a lot of legacy to support when your program is older than Unix.
The only way emacs get popular is if it changes its licensing.
Everything else is just window dressing.
Everything else is just window dressing.
The kindest thing we could do for future programmers is let Emacs and all tty-oriented editors die. There are much better options now. UI has improved a lot since the 1970s, let's embrace it.
(1) There is GUI Emacs (what you should probably use).
(2) There's no better environment available for dealing with text (including notes, papers, slides, email, &c.) than Emacs.
Why do you hate future programmers so much?
(2) There's no better environment available for dealing with text (including notes, papers, slides, email, &c.) than Emacs.
Why do you hate future programmers so much?
GUI Emacs is a very thin GUI skin on TTY Emacs. As an example someone brought up elsewhere in this thread, you can't scroll (with the mouse) in Emacs without bringing the cursor with you. Scrolling without moving the cursor doesn't make sense in a TUI environment, so it doesn't exist in the GUI version either.
Your second point is very subjective and most people are bound to disagree with it. You certainly can't argue that like it's an objective fact, because it's very much not objective.
Your second point is very subjective and most people are bound to disagree with it. You certainly can't argue that like it's an objective fact, because it's very much not objective.
> Scrolling without moving the cursor doesn't make sense in a TUI environment
It makes perfect sense as soon as you realize there is no reason the cursor has to be the cursor. In curses: curs_set(0); then draw your own 'cursor' wherever you like.
Anyway, GUI emacs is way better than terminal emacs. Image support (in terminal emulators this is always an awful hack) and support for different font sizes in the same frame at once is something I'd not give up.
It makes perfect sense as soon as you realize there is no reason the cursor has to be the cursor. In curses: curs_set(0); then draw your own 'cursor' wherever you like.
Anyway, GUI emacs is way better than terminal emacs. Image support (in terminal emulators this is always an awful hack) and support for different font sizes in the same frame at once is something I'd not give up.
It's not really so thin: there's plenty of graphics-related things that don't work in TTY Emacs.
Even by the standards of terminal-based applications, Emacs is far from intuitive or attractive - the text-based IDE's from Microsoft ("Quick" series) and Borland ("Turbo" series) were significantly easier to use.
(As another example where *nix systems could improve a lot, the Midnight Commander tty app is great, but still not quite as intuitive as the old 'DOS Shell'. Weirdly enough, I find that other TUI apps, such as dselect and aptitude, are quite outstanding but you do need to be on a Debian-based system - they aren't a thing on Fedora or CentOS.)
(As another example where *nix systems could improve a lot, the Midnight Commander tty app is great, but still not quite as intuitive as the old 'DOS Shell'. Weirdly enough, I find that other TUI apps, such as dselect and aptitude, are quite outstanding but you do need to be on a Debian-based system - they aren't a thing on Fedora or CentOS.)
> Even by the standards of terminal-based applications, Emacs is far from intuitive or attractive - the text-based IDE's from Microsoft ("Quick" series) and Borland ("Turbo" series) were significantly easier to use.
They may be easier to learn (since they have pretty minimal functionality compared to Emacs) or easier to discover when you are new to them but they are definitely not easier to use. I use Emacs not because I am some kind of masochist but because it is the easiest way to get my stuff done.
They may be easier to learn (since they have pretty minimal functionality compared to Emacs) or easier to discover when you are new to them but they are definitely not easier to use. I use Emacs not because I am some kind of masochist but because it is the easiest way to get my stuff done.
The issue isn't "intuitive or attractive". It's something more like "powerful, learnable, extensible". Nothing else scores as highly on that triad of qualities as Emacs.
I might agree, but the root post in the thread as linked by OP is literally someone complaining that Emacs doesn't have rounded buttons. (And no it was not posted on April 1, even though that's a sensible question to ask.) And there are other less trivial UX concerns about Emacs that are somewhat more legitimate, even for a tty app.
> UI has improved a lot since the 1970s
That's far from obvious. I recall terminal interfaces rather fondly. Modern interfaces are often more like a flock of multi-colored rabid weasels trying to get in the way of my work.
That's far from obvious. I recall terminal interfaces rather fondly. Modern interfaces are often more like a flock of multi-colored rabid weasels trying to get in the way of my work.
I’m sorry, what?
Which modern editor has tools like SLIME or CIDER?
Which modern editor has tools like SLIME or CIDER?
Genuine question: what's different about SLIME/CIDER than any IDE? Auto-completion, documentation lookup, REPL, code reloading, unit test integration... these are all in Xcode, IntelliJ, Eclipse, Visual Studio, etc depending on language support.
CIDER can just as easily be built as a plugin to VS Code. (Actually, more easily.) It's just that the people who built it chose Emacs, simply because they personally prefer Emacs.
[deleted]
1. Install VS Code
2. Click extensions and install language specific plugin
3. Work
New employee 2 workflow at company X:
1. Install emacs
2. Try to install some source code indexing tool
3. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies.
4. Spend another couple hours reading non-existent to terrible documentation (documentation so bad in places that even Stallman finds it useless) across 3 packages and editing .emacs to configure an otherwise unusable result. It looks like source code indexing is working! It isn’t...
5. Go home
6. The next morning, find the default color theme garish and spend another 4 hours installing themes and theme managers, reading more terrible documentation, and finding that obscure TTY settings must be tweaked for emacs to decide that it can use a theme (even though it has no problem displaying the colors in the first place)
7. Spend the rest of your tenure constantly hitting code indexing and highlighting bugs that need constant tweaking and workarounds. You often find yourself using find/grep because it’s often faster than debugging the latest indexing bug.
8. Discover that the vaunted ‘lightening fast editing’ with ‘multiple cursors!’ and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing.
Emacs is a terrible experience with defaults suitable for a 70s TTY. That you can change it misses the point. The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone.
In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years.