Why Emacs: Redux(batsov.com)
batsov.com
Why Emacs: Redux
https://batsov.com/articles/2021/11/16/why-emacs-redux/
206 comments
Before I learned lisp, I remember seeing this sentiment expressed a lot and thinking people were underselling the difficulty and overselling the usefulness of "programming your text editor" as opposed to just configuring it via standard options.
After I learned enough Common Lisp to build a few small projects, I realized how powerful it is to write small, bespoke functions for odd text editing jobs. You can write and save functions that do something very specific but powerful to any project you're working on, regardless of the language or tooling used, because everything uses text. I'm so glad I learned it.
After I learned enough Common Lisp to build a few small projects, I realized how powerful it is to write small, bespoke functions for odd text editing jobs. You can write and save functions that do something very specific but powerful to any project you're working on, regardless of the language or tooling used, because everything uses text. I'm so glad I learned it.
I'm glad to hear that because so far my impression agrees with yours (before you learned Lisp) and this comment[0]. Do you happen to know a good tutorial to learn Emacs Lisp?
[0]: https://news.ycombinator.com/item?id=29256103
[0]: https://news.ycombinator.com/item?id=29256103
I learned it from the manual built into Emacs itself, which you can access by entering "C-x r" and then following the link to "Emacs Lisp" near the top. I had literally never heard of Lisp at the time I stumbled on it.
But the way that I actually got competent enough to do anything interesting with it was to learn Common Lisp, because they are similar in that learning to solve problems in Common Lisp lets you do the same in Elisp. I learned Common Lisp by reading Practical Common Lisp by Peter Seibel and writing small programs.
I would really recommend spending a little time learning both dialects because it's easy to learn "just enough" elisp to configure your setup but not enough to appreciate what you can do with it.
But the way that I actually got competent enough to do anything interesting with it was to learn Common Lisp, because they are similar in that learning to solve problems in Common Lisp lets you do the same in Elisp. I learned Common Lisp by reading Practical Common Lisp by Peter Seibel and writing small programs.
I would really recommend spending a little time learning both dialects because it's easy to learn "just enough" elisp to configure your setup but not enough to appreciate what you can do with it.
I really wish emacs had evolved a model for dealing with simple vector graphics. I know part of that falls on the market for not choosing a common model..but
I agree completely. I made a big push to switch from vim to spacemacs so that I could use org-mode for note taking and reduce my dependence on paper notebooks, but the lack of ability to easily sketch really killed it. I'm a geologist so I need to sketch out maps and other kinds of figures that aren't just scatterplots and flowcharts or whatever (which can be done programmatically). If I could have something even quite crude it would be revolutionary, especially if the org clients were improved for iOS with better editing/syncing capabilities and less of a focus on agenda and calendar capabilities (todoist and native calendar apps work better for my job situation, personally). The rest of org is so easy and powerful... I still dream my little dreams but am not willing to learn how to implement something like that myself I guess.
> I made a big push to switch from vim to spacemacs so that I could use
> org-mode for note taking and reduce my dependence on paper notebooks
If anybody is looking for a good notes platform, seriously, learn org-mode. I only wish that I started earlier.
Signed, a two-decades VIM user.
also... i can't stress this enough... use and learn magit. so amazing for git
it was spc-g-g for me on spacemacs but i am not sure what they moved to in spacemacs. on doom it is that.
it was spc-g-g for me on spacemacs but i am not sure what they moved to in spacemacs. on doom it is that.
> if I could have something even quite crude it would be revolutionary
How crude are you willing to go? Check out M-x artist-mode, which comes with emacs. https://www.emacswiki.org/emacs/ArtistMode
(this is mostly a joke, I don't think anyone uses that)
How crude are you willing to go? Check out M-x artist-mode, which comes with emacs. https://www.emacswiki.org/emacs/ArtistMode
(this is mostly a joke, I don't think anyone uses that)
Artist mode is reasonable in combination with ditaa which converts ascii art box diagrams into images.
Would this help? https://elpa.gnu.org/packages/sketch-mode.html
There's also canvas-mode, which is newer but will hopefully pick up: https://lifeofpenguin.blogspot.com/2021/08/scribble-notes-in...
This also looks great, thanks a ton!
Thanks! This looks awesome.
Would this help? https://elpa.gnu.org/packages/sketch-mode.html
AFAIK it supports SVG rendering. Is that not enough or what did you have in mind?
Learning Lisp is on my "bucket list", I know where to go to learn it but I need the time :)
Emacs lisp is something you can figure out a bit at a time: mostly you're writing 'snippets', rather than organizing some huge codebase where you have to know all the ins and outs.
I second this. At my first Real Job after university, I was challenged by a teammate to learn to use Emacs. He laughed at how primitive my (non-Vim!) vi editor was. In hindsight, it was absolutely true. I bought the O'Reilly book for Emacs and spent many weekends teaching myself the basics.
You are right: Bit by bit you write tiny macros that do things you need or want. After 1/2/5/10/30 years, your personal macros compound to create real efficiency. I don't use Emacs today, but I do appreciate that the ecosystem is enormous and well-developed.
You are right: Bit by bit you write tiny macros that do things you need or want. After 1/2/5/10/30 years, your personal macros compound to create real efficiency. I don't use Emacs today, but I do appreciate that the ecosystem is enormous and well-developed.
I agree that elisp, itself, is quite easy to learn. I wish I could say the same about the emacs API. M-x apropos is somewhat useful, but quite a lot of my editor customizations come down to either 1) reading the source of the functionality that I'm trying to customize and reading what variables it accesses or 2) random Googling to see what others have customized.
That said, to emacs' credit, it makes (1) extraordinarily easy. C-h k to see which function is being called by a given key-combination and C-h f to get to the source of that function makes it very easy to look at the internals of the editor and figure what I should setq in order to make the editor behave in the way I want.
That said, to emacs' credit, it makes (1) extraordinarily easy. C-h k to see which function is being called by a given key-combination and C-h f to get to the source of that function makes it very easy to look at the internals of the editor and figure what I should setq in order to make the editor behave in the way I want.
> Learning Lisp is on my "bucket list", I know where to go to learn it but I need the time :)
For Common Lisp: Practical Common Lisp is a good introductory text. ANSI Common Lisp is older, but still relevant (the standard is from 1994, it hasn't changed, though the community and tooling has the language is stable). On Lisp and Let over Lambda are good follow-on texts if you want to learn about macros, in particular. Common Lisp Recipes is another good one for after PCL.
For Emacs Lisp: I just looked at the info pages for emacs. There are some books, never touched them so can't comment. But if you know CL, Emacs Lisp is not a stretch to learn as it's about 90% the same (especially since they made some changes in the past decade or so to better support lexical scope by default).
For Scheme: Check out The Little Schemer and the rest of that book series. Unique presentation style, but very approachable if you get past it (some people don't, I liked them).
For Emacs Lisp: I just looked at the info pages for emacs. There are some books, never touched them so can't comment. But if you know CL, Emacs Lisp is not a stretch to learn as it's about 90% the same (especially since they made some changes in the past decade or so to better support lexical scope by default).
For Scheme: Check out The Little Schemer and the rest of that book series. Unique presentation style, but very approachable if you get past it (some people don't, I liked them).
Also, The Scheme Programming Language, 4th Ed. is on the web (https://www.scheme.com/tspl4/) if one is learning Chez Scheme in particular.
There are lots of options out there. The canonical text everyone will give you is "Structure and interpretation of computer programs".
I am a big fan of the little family of books by Friedman et al.
There is also Practical common lisp which and land of lisp which are usually recommended by people.
Hope that helps somewhat.
I am a big fan of the little family of books by Friedman et al.
- Little schemer
- Seasoned schemer
There is also Practical common lisp which and land of lisp which are usually recommended by people.
Hope that helps somewhat.
Back in the day I started out with the "Emacs Lisp Intro" also known as "An Introduction to Programming in Emacs Lisp" that comes with Emacs. I remember printing it out and devouring it before going to sleep.
It looks like it's been kept up to date and you could do worse than starting there, especially in an Emacs context.
Here is the online version in case you don't know how to navigate info manuals yet:
https://www.gnu.org/software/emacs/manual/eintr.html
It looks like it's been kept up to date and you could do worse than starting there, especially in an Emacs context.
Here is the online version in case you don't know how to navigate info manuals yet:
https://www.gnu.org/software/emacs/manual/eintr.html
I find it doesn't really matter what I'm interested in (computer-wise)---Emacs has me covered. It saves a huge amount of time to not have to relearn a new IDE each time I need to switch programming language. There is always more about Emacs to explore, but it is well invested time, as I know that Emacs is going to be around most likely for the rest of my life-time. The killer features for me are:
+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.
+ Org-mode + SLIME (Common Lisp IDE) + A Lisp as "extension" language (it isn't really extension---Emacs is fundamentally reprogrammable). + Really smooth integration of LaTeX, Dot and Tikz. + Rock, rock, rock solid no matter what I through at it.
Also, I find that for me, Emacs has ergonomically good key-bindings once I accepted that they are different, learned them properly and did the CAPS-Ctrl switch.
> Rock, rock, rock solid no matter what I through at it.
The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.
The main reason why I don't like Emacs is that it feels very fragile to me. The first time I tried to use Emacs seriously - granted, that was many years ago and probably things have improved - I wanted to change the font because it was using an old X11 pixel font. So I went to the settings, and accidentially deleted the combobox that allows you to choose the font. I tried to configure it with the command line or REPL or what it is called and managed to mess it up even further. Later, as I got more familiar, I regularly managed to get it into a state that required restarting. It seems in Emacs, everything is a mode and everything is an editor, and there is no separation between content and UI (except for things like the menu bar, which uses a different toolkit and is bolted on). I've learned to appriciate less configurable editors because there is less to screw up, and you have the same good experience on any PC without your special config.
I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing. I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did :). There is a market for restricting choice, so you are clearly not alone!
But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.
But I don't think that the Emacs learning curve should be exaggerated, either. If you start it up and follow the instructions, you very quickly become productive. What gets people into trouble is usually when they expect Emacs to be like software X which they already know, so they don't read what's on the screen and kind of skip the introduction. And then they get frustrated when they find out that Emacs is Emacs. I'm not saying that's you, or that it is stupid, impatient etc. or whatever. I'm just saying that I've seen it quite a few times.
>I wouldn't call what you describe fragile. It sounds more like a typical learning experience. You did something, Emacs obeyed and then you who didn't like what you just did
That's the definition of fragile.
The famous "You're holding it wrong", even sounds benign compared to "it's just a learning experience".
That's the definition of fragile.
The famous "You're holding it wrong", even sounds benign compared to "it's just a learning experience".
No, the definition of fragile is that if you use something in a wrong way, it breaks. But Emacs doesn't break. It obeys and keeps running.
With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved. In other words, it is a circular definition.
Anyway, I didn't mean learning experience in a condescending way. The user I answered indicated himself that he was learning---and we all are, when it comes to Emacs.
With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved. In other words, it is a circular definition.
Anyway, I didn't mean learning experience in a condescending way. The user I answered indicated himself that he was learning---and we all are, when it comes to Emacs.
I just tried changing the font through the menubar (Options -> Set Default Font) and wound up with a font which was unreadable, due to being only a couple of pixels high. I never use the menubar, so I'm insulated from that kind of issue (and I'm running bleeding-edge emacs, so it could be a transient bug), but I could see it being a showstopper for new users.
emacs users just live in another world entirely, this whole interaction I find typical of users who evangelize for emacs, and for some reason those users can never see the error of their thinking.
You sound like a zealot for thinking a settings menu breaking when trying to change a setting is acceptable.
You sound like a zealot for thinking a settings menu breaking when trying to change a setting is acceptable.
Don't mean to come off like a zealot. To me, it sounds like the user accessed a show/hide-function in the graphical interface while using the mouse, and then didn't know how to bring it back (Control-Right Click or menu-bar-mode). The mistake and the ability to hide the menu-bar are both super common in any application and don't make Emacs fragile. Instructions for how to hide/un-hide stuff are in the manual.
I think people are just kidding themselves when they arrive at the conclusion that a program like Emacs---which is super mature, has a huge user base amongst very picky programmers and has survived in fierce competition for 45 years---is somehow fundamentally flawed, fragile etc. Of course it isn't. But it might not be your thing, and that's fine.
I think people are just kidding themselves when they arrive at the conclusion that a program like Emacs---which is super mature, has a huge user base amongst very picky programmers and has survived in fierce competition for 45 years---is somehow fundamentally flawed, fragile etc. Of course it isn't. But it might not be your thing, and that's fine.
I use emacs daily and have done for 5+ years now. Even with that, It's undeniable that it makes some tragic choices that keep it from being popular in the modern day.
You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I have more faith in VSCode sticking around for the next 10 years than I do Emacs.
You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I have more faith in VSCode sticking around for the next 10 years than I do Emacs.
I am sure emacs will be alive and well in 20 years. (8MB and constantly swapping and all…)
[deleted]
> I have more faith in VSCode sticking around for the next 10 years than I do Emacs.
I mean, almost everyone is confident about that too. And rightfully so because, VSCode actually has real corporate backing. People are being actually paid to develop it and sometimes plugins for it, so it would be a surprise if it didn't pan out. Nobody is getting paid to work on Emacs, or third party elisp libraries. It has always been individual hackers doing the bits that interests them. I don't want to come across like anybody owes Emacs anything. But I think in forums people sometimes take the reverse for granted, like Emacs owes anyone anything. Or that the people who actually bother to do voluntary work share the same vision of modernity as them, so it's a failure of some sort when that isn't exactly delivered.
> You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I think this is a mischaracterisation. Because, firstly you don't actually need the approval of the "stalwarts" to modernise it. Doom Emacs is making a name of its own just fine. The other thing is, Emacs is old. Most of the old vanguards aren't actively involved in Emacs development any more. Most of the "stalwarts" now weren't even around for most of the mistakes, why would you attribute things to vanity when it was not current stalwarts personally who were responsible for most of the design goals?
Browsing emacs-devel, it's clear that the real problem is acute lack of manpower. Only a fraction of Emacs users do bug reports, and then only a tiny fraction of them do actually get involved in fixing things. Which means the maintainers are always facing an uphill battle, who by the way don't have domain expertise or historical understanding of why things are the way they are, any more than you or I do, in many of the situations. Compared to that, VSCode is only a few years old, there are probably engineers who are familiar with the entire codebase, from conception to now.
That said, it has always been more or less like this. Emacs will be fine in its own way, because it will always attract certain sort of hackers. So sure, in terms of "mindshare" and "percentage of users", Emacs will keep free falling, specially now that software development itself has become way more pervasive. It might continue to get more out of touch with "modernity". However, as someone who has been in Emacs community for 7 years now, I believe the ecosystem is only getting more and more vibrant each year than the one before, in absolute terms (more mailing list or other forum activities, more landmark features, more new and high quality third party libraries etc.).
I mean, almost everyone is confident about that too. And rightfully so because, VSCode actually has real corporate backing. People are being actually paid to develop it and sometimes plugins for it, so it would be a surprise if it didn't pan out. Nobody is getting paid to work on Emacs, or third party elisp libraries. It has always been individual hackers doing the bits that interests them. I don't want to come across like anybody owes Emacs anything. But I think in forums people sometimes take the reverse for granted, like Emacs owes anyone anything. Or that the people who actually bother to do voluntary work share the same vision of modernity as them, so it's a failure of some sort when that isn't exactly delivered.
> You see every few years a project to modernize emacs and get wider mindshare among developer community, and they always fail due to some stubborn choices due to stalwarts not admitting when they are wrong.
I think this is a mischaracterisation. Because, firstly you don't actually need the approval of the "stalwarts" to modernise it. Doom Emacs is making a name of its own just fine. The other thing is, Emacs is old. Most of the old vanguards aren't actively involved in Emacs development any more. Most of the "stalwarts" now weren't even around for most of the mistakes, why would you attribute things to vanity when it was not current stalwarts personally who were responsible for most of the design goals?
Browsing emacs-devel, it's clear that the real problem is acute lack of manpower. Only a fraction of Emacs users do bug reports, and then only a tiny fraction of them do actually get involved in fixing things. Which means the maintainers are always facing an uphill battle, who by the way don't have domain expertise or historical understanding of why things are the way they are, any more than you or I do, in many of the situations. Compared to that, VSCode is only a few years old, there are probably engineers who are familiar with the entire codebase, from conception to now.
That said, it has always been more or less like this. Emacs will be fine in its own way, because it will always attract certain sort of hackers. So sure, in terms of "mindshare" and "percentage of users", Emacs will keep free falling, specially now that software development itself has become way more pervasive. It might continue to get more out of touch with "modernity". However, as someone who has been in Emacs community for 7 years now, I believe the ecosystem is only getting more and more vibrant each year than the one before, in absolute terms (more mailing list or other forum activities, more landmark features, more new and high quality third party libraries etc.).
> like Emacs owes anyone anything.
The vast majority of users get their emacs from the Linux distributions, who in turn get it from the GNU people. To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.
The vast majority of users get their emacs from the Linux distributions, who in turn get it from the GNU people. To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.
> To the extent they've monopolized that distribution channel, the maintainers owe us something. They alone can revive emacs's fortunes, or squander its good name by failing to keep with the times.
I don't even know how that makes any logical sense. The maintainers aren't what they are by virtue of nepotism. Rather they are only one who shows up, voluntarily. That doesn't mean they owe anyone shit, nor does it mean they are preventing others like you to show up and do what needs to be done. So no, if there is anyone who can "revive" Emacs' fortunes, it's people like you, that is if they bother to show up instead of complaining which is always easy.
I also don't get your obsession with "name". XEmacs was a fork, and for a while it was wildly popular. So if you have fundamental difference with emacs-devel, then go fork it? If your fork becomes worthy and solves many people's problems, then all linux distributions will package yours too.
The entire Guile Emacs thing was a product of a GSoC project, the moment it ended so did the project. None volunteered to take up the mantle, even though to this day people lament in forums about how it never became a thing. Turns out that solutions don't magically manifest without people putting the work, what a surprise. But I suppose this is to be expected, when people become too spoiled by other people's labour.
I don't even know how that makes any logical sense. The maintainers aren't what they are by virtue of nepotism. Rather they are only one who shows up, voluntarily. That doesn't mean they owe anyone shit, nor does it mean they are preventing others like you to show up and do what needs to be done. So no, if there is anyone who can "revive" Emacs' fortunes, it's people like you, that is if they bother to show up instead of complaining which is always easy.
I also don't get your obsession with "name". XEmacs was a fork, and for a while it was wildly popular. So if you have fundamental difference with emacs-devel, then go fork it? If your fork becomes worthy and solves many people's problems, then all linux distributions will package yours too.
The entire Guile Emacs thing was a product of a GSoC project, the moment it ended so did the project. None volunteered to take up the mantle, even though to this day people lament in forums about how it never became a thing. Turns out that solutions don't magically manifest without people putting the work, what a surprise. But I suppose this is to be expected, when people become too spoiled by other people's labour.
It's OSS, people can and have forked it before, if the present (primary) maintainers aren't doing what people want then they can do it themselves. In the meantime, quite a few people are using emacs as it is and it is getting updates that people seem to care about (like native compilation of elisp).
Okay, you obviously missed my point about owning the distribution channel.
> emacs users just live in another world entirely, this whole interaction I find typical of users who evangelize for emacs
It's not that emacs users "live in another world entirely", it's that some things a very difficult to explain to folks who don't have first-hand experience of those things. Try describing what minus 20 degrees Celsius feels like to someone who's spent their entire life in Florida, or Brazil. You can't really, it has to be experienced to be understood.
It's no different with emacs. Emacs doesn't really make any sense until you use it for a while, then all of sudden you "get it" and don't want to use anything else.
It's not that emacs users "live in another world entirely", it's that some things a very difficult to explain to folks who don't have first-hand experience of those things. Try describing what minus 20 degrees Celsius feels like to someone who's spent their entire life in Florida, or Brazil. You can't really, it has to be experienced to be understood.
It's no different with emacs. Emacs doesn't really make any sense until you use it for a while, then all of sudden you "get it" and don't want to use anything else.
> You can't really, it has to be experienced to be understood.
No, I'm pretty sure everyone knows what fragile software feels like. Disclaimer: I've been using fragile emacs as long as most HN users have been alive.
No, I'm pretty sure everyone knows what fragile software feels like. Disclaimer: I've been using fragile emacs as long as most HN users have been alive.
It's surprising to me why people think the "you just don't get it, man" defense or marketing point will ever work.
It wasn't a "defense", so much as a statement of fact. I enjoy using emacs, but I don't go around trying to get the whole world to use it. I know that emacs occupies a very specific niche and is not for everyone. I don't spend a lot of time worrying about how much market share emacs has, it has enough to keep marching on, and that's about the extent of my concern.
But the point remains. You can't really understand emacs (or a lot of other things for that matter) in the abstract, you have to use it. So use it or don't, but you can't really offer meaningful criticism without have it used it a fair amount. There are plenty of warts on emacs, any emacs veteran (which I'm certainly not) will freely acknowledge that. But it does seem that most criticisms of emacs come from folks who haven't used it much.
But the point remains. You can't really understand emacs (or a lot of other things for that matter) in the abstract, you have to use it. So use it or don't, but you can't really offer meaningful criticism without have it used it a fair amount. There are plenty of warts on emacs, any emacs veteran (which I'm certainly not) will freely acknowledge that. But it does seem that most criticisms of emacs come from folks who haven't used it much.
> With your reasoning, all software that gives you a choice, anything that can be configured, all programming languages etc. etc., become fragile, because as soon as someone says "I did this but I didn't like the result," your case has been proved
That's not at all true. It's called "validation" and "error handling". What kind of farce are you getting at? You unironically think a text editor that lets you break its settings panel by trying to use the settings panel normally isn't fragile?
Edited to remove cheapshot at parent comment
That's not at all true. It's called "validation" and "error handling". What kind of farce are you getting at? You unironically think a text editor that lets you break its settings panel by trying to use the settings panel normally isn't fragile?
Edited to remove cheapshot at parent comment
I am quite annoyed at downvotes that don't challenge my assertion. Any UI which allows you to directly compromise the environment to the point of requiring a fresh install is the very definition of fragile. I understand that HN is strongly biased against UI development and undervalues the domain, believing instead that tools only accessible to experts are fine, but I think this is an extremely user-hostile POV and to advocate for tools to have this level of footgun built into A FONT MENU is comically sloppy. I can only imagine the comments if someone did this in JS, yet because it's emacs? No comments, only downvotes
I'm on the fence about this one, because tools for consumers are a bit different than tools for technologists. Yes UX matters for us as well, but there's a commonly accepted belief that initial-difficulty-of-use is worth the eventual efficiency gains that the tool offers. I've never gotten into Emacs but I believe devs when they say it makes them hyper-productive.
> I mean rock solid as in being able to edit buffers with very different contents of half a million characters, every day for decades without crashing.
There's nothing you can say to make me believe that.
Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.
> What gets people into trouble is usually when they expect Emacs to be like software X
This is the problem with Emacs. By default and by itself, it's nothing more than a glorified text editor. You have to update and configure it to get things to work as they should, but that's where the fragility comes in.
I've gone through this multiple times. Every time I try Emacs for some new language, I end up in configuration hell. The moment I switch to VSCode, while not perfect things just work, and I get to coding. Maybe I'll eventually bunker down in a hole and get Emacs to work as I'd expect, but that has not been accomplishable yet.
And I generally actually prefer using dedicated IDEs for languages. Otherwise, you're reliant on someone having implemented a usable Emacs mode.
There's nothing you can say to make me believe that.
Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.
> What gets people into trouble is usually when they expect Emacs to be like software X
This is the problem with Emacs. By default and by itself, it's nothing more than a glorified text editor. You have to update and configure it to get things to work as they should, but that's where the fragility comes in.
I've gone through this multiple times. Every time I try Emacs for some new language, I end up in configuration hell. The moment I switch to VSCode, while not perfect things just work, and I get to coding. Maybe I'll eventually bunker down in a hole and get Emacs to work as I'd expect, but that has not been accomplishable yet.
And I generally actually prefer using dedicated IDEs for languages. Otherwise, you're reliant on someone having implemented a usable Emacs mode.
> Emacs is fragile. Any change, even the most simple change, to one's .emacs file can cause unexpected behavior. From fonts, to shell changes, etc. I have really wanted to like Emacs and get into it, but it's fragile from the very start.
In Emacs you have control over absolutely everything so, of course, you can mess it up. The solution however is very simple, trivial even: just version your entire Emacs config in Git. Screw up something? Checkout the last known working version. There are people even going as far as versioning their entire user directory under Git (not just Emacs but everthing). At the OS level there are people using NixOS: where everything is reproducible.
You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy (any dev should know how to use Git to revert back to a working Emacs config).
> And I generally actually prefer using dedicated IDEs for languages.
Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
In Emacs you have control over absolutely everything so, of course, you can mess it up. The solution however is very simple, trivial even: just version your entire Emacs config in Git. Screw up something? Checkout the last known working version. There are people even going as far as versioning their entire user directory under Git (not just Emacs but everthing). At the OS level there are people using NixOS: where everything is reproducible.
You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy (any dev should know how to use Git to revert back to a working Emacs config).
> And I generally actually prefer using dedicated IDEs for languages.
Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
[deleted]
> The solution however is very simple, trivial even: just version your entire Emacs config in Git.
And all installed packages.
> You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy
If you never update a package or install a new one. The more packages you have installed and use and the more (major and minor) modes you use (simultaneously), the higher the possibility.
And all installed packages.
> You make it sound like it's not possible to have a deterministic system. It's not just possible: it's very easy
If you never update a package or install a new one. The more packages you have installed and use and the more (major and minor) modes you use (simultaneously), the higher the possibility.
> In Emacs you have control over absolutely everything so, of course, you can mess it up.
That's not necessarily a feature in my opinion, and I don't like the framing that's it's me messing things up and not Emacs or packages. Look, Emacs is super powerful, but people always respond to things being difficult in Emacs with something along the lines of "just do this and then you get rainbows and the pot of gold". In reality, you're spending hours reading documentation and random forum posts on how to do the simple thing you want. Next thing you know you're having to basically write your own features into Emacs.
The thing I balk at is people acting like Emacs is just some under appreciated tool that just has a learning curve. No, it has a learning curve plus the difficulty of understanding its ad hoc design and the multitudes of packages, the way they're written and interact with Emacs, and the millions of ways various people like to do things. I just wish people were more honest regarding its complexity and the vast multitudes of ways that people use it in very individualized manners.
And yes, I have previously managed my .emacs file in GitHub. Not sure why you commented on a bunch of that. It's still not as easy as VSCode automatically syncing via my GitHub account or working automatically through SSH.
> Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
That's actually what I was referring to. I use Dr. Racket for Racket, Visual Studio for F#, VSCode right now for Elixir, but I've considered trying out the Jetbrains stuff for Elixir, and if I was using Clojure, I'd definitely use IntelliJ with Cursive.
That's not necessarily a feature in my opinion, and I don't like the framing that's it's me messing things up and not Emacs or packages. Look, Emacs is super powerful, but people always respond to things being difficult in Emacs with something along the lines of "just do this and then you get rainbows and the pot of gold". In reality, you're spending hours reading documentation and random forum posts on how to do the simple thing you want. Next thing you know you're having to basically write your own features into Emacs.
The thing I balk at is people acting like Emacs is just some under appreciated tool that just has a learning curve. No, it has a learning curve plus the difficulty of understanding its ad hoc design and the multitudes of packages, the way they're written and interact with Emacs, and the millions of ways various people like to do things. I just wish people were more honest regarding its complexity and the vast multitudes of ways that people use it in very individualized manners.
And yes, I have previously managed my .emacs file in GitHub. Not sure why you commented on a bunch of that. It's still not as easy as VSCode automatically syncing via my GitHub account or working automatically through SSH.
> Then try the JetBrains tools. It's leaps and bounds above anything MS has to offer.
That's actually what I was referring to. I use Dr. Racket for Racket, Visual Studio for F#, VSCode right now for Elixir, but I've considered trying out the Jetbrains stuff for Elixir, and if I was using Clojure, I'd definitely use IntelliJ with Cursive.
Making changes to my .emacs never causes unexpected behavior. It does what I tell it to do.
Looking through my .emacs I really can't think of anything that would cause the chaotic behavior you describe. And the only revert I see in the last 10 years of git history is a key binding change that I decided I didn't like after all.
The only way I can see this happening is if you copy and paste random stuff from the internet without understanding it. But then what else could you expect.
Looking through my .emacs I really can't think of anything that would cause the chaotic behavior you describe. And the only revert I see in the last 10 years of git history is a key binding change that I decided I didn't like after all.
The only way I can see this happening is if you copy and paste random stuff from the internet without understanding it. But then what else could you expect.
> Emacs is fragile.
Correct. As an undergraduate in the 90s when OOP got in vogue, I puzzled at the bureacratic notion of data hiding and private variables. Emacs set me straight on why those things are important.
Correct. As an undergraduate in the 90s when OOP got in vogue, I puzzled at the bureacratic notion of data hiding and private variables. Emacs set me straight on why those things are important.
I'm going to get downvoted to hell for this, but it's true.
Emacs is like dating a redhead. You're right: it is more fragile. It takes effort and dedication to figure out what you can do with it (more than you initially thought) and how to not upset it (more easily than you initially thought). But like the redhead, it's worth the effort.
Emacs is like dating a redhead. You're right: it is more fragile. It takes effort and dedication to figure out what you can do with it (more than you initially thought) and how to not upset it (more easily than you initially thought). But like the redhead, it's worth the effort.
> So I went to the settings, and accidentially deleted the combobox that allows you to choose the font.
I'm genuinely curious how you did this, and how you did it in a way that was permanent. The customization screens are read-only by default (except for those boxes you type text in to specify the customization) and they're programmatically generated, not fixed.
I'm genuinely curious how you did this, and how you did it in a way that was permanent. The customization screens are read-only by default (except for those boxes you type text in to specify the customization) and they're programmatically generated, not fixed.
It seems a bit disingenuous to say "emacs can do everything" citing org, slime, and auctex, which are probably the three highest-quality extensions out there (maybe throw in magit too). In my experience this level of polish is not consistent, e.g. python or java support is much less robust. Emacs is indeed great for many things, but not everything.
Java support is, unfortunately, iffy in every editor that isn't made by JetBrains.
I've recently got Python working well. It can be done. The deeper problem - and this is admittedly ubiquitous in emacs - is that the defaults are awful, and there is not even good discoverable official documentation about what configuration you should use because everyone's just a wee bit too content to allow, "We have a very welcoming community on IRC!" to stand in for a proper new user experience.
I've recently got Python working well. It can be done. The deeper problem - and this is admittedly ubiquitous in emacs - is that the defaults are awful, and there is not even good discoverable official documentation about what configuration you should use because everyone's just a wee bit too content to allow, "We have a very welcoming community on IRC!" to stand in for a proper new user experience.
> I've recently got Python working well
I can't complain about Python except I didn't succeed in using the projects local pipenv automatically.
I can't complain about Python except I didn't succeed in using the projects local pipenv automatically.
Have you considered a .dir-locals.el file?
That's actually how I ended up doing it. But not dynamically running `pipenv --venv` but hard-coding the path to the virtualenv, which I don't like :(
In case it helps:
I have struggled with a similar thing (poetry not pipenv, but should be applicable) and came to this working solution: https://github.com/bananaoomarang/dotfiles/blob/master/emacs...
Basically: if poetry project file exists in project root, get the path for the active venv with poetry and activate with the emacs pyvenv package. This adds a little jank when switching projects I haven't looked into ironing out yet but it is functional.
I have struggled with a similar thing (poetry not pipenv, but should be applicable) and came to this working solution: https://github.com/bananaoomarang/dotfiles/blob/master/emacs...
Basically: if poetry project file exists in project root, get the path for the active venv with poetry and activate with the emacs pyvenv package. This adds a little jank when switching projects I haven't looked into ironing out yet but it is functional.
Hi. I am absolutely a dyed-in-the-wool JetBrains "fanboi", but I need to counter this statement: <<Java support is, unfortunately, iffy in every editor that isn't made by JetBrains.>>
Both Eclipse and NetBeans are outstanding (and free) Java IDEs. To be clear: I write this as someone who does not make extensive use of plug-ins with IntelliJ. I am almost exclusively using the default plug-ins provided by JetBrains. For many, many years, NetBeans was (enviably) considered the Gold Standard for Java Swing GUI design that was drag-and-drop. I knew developers who used NetBeans only for GUI design, then IntelliJ or Eclipse for other work!
Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.
I am interested to hear from other people if this agree or disagree with me.
Both Eclipse and NetBeans are outstanding (and free) Java IDEs. To be clear: I write this as someone who does not make extensive use of plug-ins with IntelliJ. I am almost exclusively using the default plug-ins provided by JetBrains. For many, many years, NetBeans was (enviably) considered the Gold Standard for Java Swing GUI design that was drag-and-drop. I knew developers who used NetBeans only for GUI design, then IntelliJ or Eclipse for other work!
Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.
I am interested to hear from other people if this agree or disagree with me.
>Finallly, I have never used Visual Studio Code, but I also assume -- at this point -- that it is very good with Java. The speed at which their community has grown is simply breathtaking.
Unfortunately, that's not the case. I tried using VSCode with its Java development extension pack last week and I found that it was nowhere near as polished as, for example, its Python or Typescript extensions, both of which are gold standard. I ended up switching back to IntelliJ.
Unfortunately, that's not the case. I tried using VSCode with its Java development extension pack last week and I found that it was nowhere near as polished as, for example, its Python or Typescript extensions, both of which are gold standard. I ended up switching back to IntelliJ.
This is my experience as well, VSCode has been excellent for TypeScript, but it is lacking a lot when it comes to Java. I'm much happier with Eclipse. I'm sure IntelliJ is great too but Eclipse works fine for me and I've never felt the need to drop it.
I use elpy regularly for python development. Handles virtualenvs really well, makes it super easy to run one or all test cases. Good support for linting and reformatting (black).
I should note that I don't work on large codebases. My codebases have ~20 files and <20,000 lines of code total. I know some folks prefer LSP and that might be the reason.
I should note that I don't work on large codebases. My codebases have ~20 files and <20,000 lines of code total. I know some folks prefer LSP and that might be the reason.
It's been a few years since I developed in python. What kinds of limitations does emacs have for it?
I spend most of my time in Emacs (Clojure/Script), but if I'm writing JavaScript then VS Code works so much better. Maybe I haven't spent enough time tweaking Emacs for JS?
> Rock, rock, rock solid no matter what I through at it.
That's actually not how I would describe Emacs. Not for Common Lisp either, Sly (and before that Slime) always had some glitches where I had to restart them or Emacs.
That's actually not how I would describe Emacs. Not for Common Lisp either, Sly (and before that Slime) always had some glitches where I had to restart them or Emacs.
Well, to each their own. I never have to restart Emacs. The only time I restart SLIME is when I do something I shouldn't, like redefine a struct or something. I'm sure I could avoid restarting SLIME, too---I just never bothered to learn if there is a way.
BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).
BTW, all software that changes will have a bug from time to time, but Emacs and things related to Common Lisp are like at the very bottom of the trouble-frequency charts. I can't think of any software that I use regularly that gives me fewer problems. For the record I never encountered a bug in either (which doesn't mean they don't exist).
The problem with Emacs' configuration file is that it's processed in an additive way. Removing options and reloading the config does absolutely nothing. So in certain situations a restart is just inevitable.
But aside from that Emacs, like most programs, has a UX philosophy that I can't stand. And while Emacs lets me change that I don't want to manually redefine things for every single filetype and mode I'm using. Vim just does it right unless I make the mistake of writing JS in HTML files.
But aside from that Emacs, like most programs, has a UX philosophy that I can't stand. And while Emacs lets me change that I don't want to manually redefine things for every single filetype and mode I'm using. Vim just does it right unless I make the mistake of writing JS in HTML files.
Vim is a fantastic editor---no argument there!
But you can always revert a configuration choice you made without restarting Emacs. Either use the built in configuration interface, or evaluate a form with the change. For example, if you set something to t you can reset it to nil and just C-x-e that form.
But you can always revert a configuration choice you made without restarting Emacs. Either use the built in configuration interface, or evaluate a form with the change. For example, if you set something to t you can reset it to nil and just C-x-e that form.
>The only time I restart SLIME is when I do something I shouldn't, like redefine a struct or something.
That's not something you shouldn't do and you also shouldn't need to restart Slime. Just break using `C-c C-c` and do a 'retry'.
That's not something you shouldn't do and you also shouldn't need to restart Slime. Just break using `C-c C-c` and do a 'retry'.
> Rock, rock, rock solid no matter what I through [sic] at it.
Try opening a large file. Or a small one. With emacs it's always a wait-and-see.
Try opening a large file. Or a small one. With emacs it's always a wait-and-see.
You should probably tell Emacs users about it---they may not have noticed.
> Rock, rock, rock solid no matter what I through at it.
This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).
There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.
Note: mostly used it in console mode on Linux (Ubuntu WSL 2).
This is definitely not my experience. I regularly see emacs lock up indefinitely when asked to handle large buffers, especially when also using TRAMP. Even when it doesn't lock up indefinitely, it can easily stall for minutes(!) when doing something like moving point to the end of a large minified JS file (C-E).
There are many reasons to love Emacs, and I use it as my main development OS almost, but stability and performance are not among those reasons.
Note: mostly used it in console mode on Linux (Ubuntu WSL 2).
Well, I guess we have different experiences then. That kind of thing hasn't happened to me in 25 years. Not once.
The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.
The OS could matter, I guess. I didn't even think about that. I used Debian Stable and have been since the last century. Always a version or two behind, at least, so I guess bugs could be resolved before I get a chance to encounter them.
I have experienced the same things but even so I would classify it as fairly rock solid overall. Under certain circumstances a rock can split. I see far more fragile, and unpredictable behaviour in other environments.
It must be said that large file handling is an area that could do with some improvement - vlf-mode is okay as a workaround but it would be nice if I could deal with a large file in much the same way as a regular sized files. Few environments will provide this either though.
It must be said that large file handling is an area that could do with some improvement - vlf-mode is okay as a workaround but it would be nice if I could deal with a large file in much the same way as a regular sized files. Few environments will provide this either though.
> Few environments will provide this either though.
I used vim for ~12 years and then emacs for ~12 years, and this emacs has never been able to handle large files well. vim meanwhile has zero trouble with files of any size that I've ever tried.
"Vim can do it" doesn't counter you saying "few environments" though. I haven't needed to look much farther than vim/emacs.
I used vim for ~12 years and then emacs for ~12 years, and this emacs has never been able to handle large files well. vim meanwhile has zero trouble with files of any size that I've ever tried.
"Vim can do it" doesn't counter you saying "few environments" though. I haven't needed to look much farther than vim/emacs.
I was thinking more along the lines of eclipse or IntelliJ … yes of course vi/m can do it and that would be my go to for quick edits on the console, the kind of thing that typically lends itself to large files funnily enough.
Now that I’m talking about it I do remember a couple of times where vi (rather than vim) choked on some very very large files but she always got there.
Now that I’m talking about it I do remember a couple of times where vi (rather than vim) choked on some very very large files but she always got there.
> I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc. Emacs and vim are the only editors that stood the test of time
This is the main reason I keep using Emacs for my everyday use. I never thought it was simply the best editor you could imagine. But it’s an editor I could always rely on.
There have been so many editors and IDEs in the past with their shiny features, great UIs and everybody screaming of excitement — until they were replaced by the next new shiny editor after a couple of years.
VSCode is surely a nice editor. (Although I don’t think its pixel dust UI is particularly great. And don’t get me started on its memory consumption.) Microsoft’s LSP, however, is a great idea. Emacs absorbed this feature already and will make it available even long after everybody stopped using VSCode within a couple of years.
Editors fall out of fashion. People die. Emacs remains Emacs.
This is the main reason I keep using Emacs for my everyday use. I never thought it was simply the best editor you could imagine. But it’s an editor I could always rely on.
There have been so many editors and IDEs in the past with their shiny features, great UIs and everybody screaming of excitement — until they were replaced by the next new shiny editor after a couple of years.
VSCode is surely a nice editor. (Although I don’t think its pixel dust UI is particularly great. And don’t get me started on its memory consumption.) Microsoft’s LSP, however, is a great idea. Emacs absorbed this feature already and will make it available even long after everybody stopped using VSCode within a couple of years.
Editors fall out of fashion. People die. Emacs remains Emacs.
VS code has been my standby for years but the number of times it wants to restart for updates drives me up a wall, and what do I get for allowing constant updates? A giant modal popup [0] asking if I trust a folder enough to let VSC run automated scripts. Yes it’s configurable but i value default setups so I can more easily wipe my OS without reconfiguring everything.
I watched a video on JetBrains [1] and the keyboard shortcuts and navigation look genuinely well thought out, so I’ll be giving that a try (with a vim emulation plugin, naturally)
[0] https://github.com/microsoft/vscode/issues/126310
[1] https://youtu.be/x8y_6Gg28GI
I watched a video on JetBrains [1] and the keyboard shortcuts and navigation look genuinely well thought out, so I’ll be giving that a try (with a vim emulation plugin, naturally)
[0] https://github.com/microsoft/vscode/issues/126310
[1] https://youtu.be/x8y_6Gg28GI
I live in Intellij, it has it's own minor warts but it's a superpower compared to anything else I've used.
It covers everything (code, inspections, docker, database layer, seamless multilanguage support).
It covers everything (code, inspections, docker, database layer, seamless multilanguage support).
Except for -really- big projects, like the linux kernel. Its indexing is.. not fun.
> This is the main reason I keep using Emacs for my everyday use.
This might be my number two reason. I learned Emacs in 2000. Meanwhile, I've not had to learn, over and over again, all those other editors and IDE's. To be sure, I've honed my Emacs skills, installed and learned new tools in it (hello flycheck, elpy, SLIME, org-mode, TRAMP, CEDET), and just generally get on with whatever I'm working on ATM.
My number one reason has been the power though, especially after reading things like this: https://blog.vivekhaldar.com/post/3996068979/the-levels-of-e...
This might be my number two reason. I learned Emacs in 2000. Meanwhile, I've not had to learn, over and over again, all those other editors and IDE's. To be sure, I've honed my Emacs skills, installed and learned new tools in it (hello flycheck, elpy, SLIME, org-mode, TRAMP, CEDET), and just generally get on with whatever I'm working on ATM.
My number one reason has been the power though, especially after reading things like this: https://blog.vivekhaldar.com/post/3996068979/the-levels-of-e...
Not all old, unfashionable editors are dead, though. See WordStar, for example. And people definitely still use all of the editors in your "fallen" list to get work done.
I use a mix of editors on a day-to-day basis because they each solve a particular problem in a way I like. I imagine everyone else has a similar thought process. If you like the way it works, then it's the editor for you.
I use a mix of editors on a day-to-day basis because they each solve a particular problem in a way I like. I imagine everyone else has a similar thought process. If you like the way it works, then it's the editor for you.
Are we talking the 1980s word processor WordStar??
George R. R. Martin apparently still uses WordStar 4.0 for DOS to write his novels.
Yes. But no worries, Emacs got you covered, too:
http://web.mit.edu/Emacs/source/emacs/lisp/emulation/ws-mode...
http://web.mit.edu/Emacs/source/emacs/lisp/emulation/ws-mode...
As a devoted Emacs user I think the following is really the most important part of the article:
> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs. … For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim. There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.
For me, this is really the key attraction of Emacs. It’s not an editor; it’s a library for me to build my own ideal editor. And, in the long term, there are very few editors which can compete with this.
> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material. The out-of-the-box experience is kind of basic and somewhat weird, but I don’t think that anyone should be using Emacs like this. You take this simple foundation, you shape and mold it to your taste and preferences and you end up with the best possible editor for you and you alone. That’s the reason why you should consider using Emacs. … For me, personally, the ability to extend Emacs easily with Emacs Lisp remains its number one advantage over vim. There’s also the fact that you can re-create much of the vim experience with Emacs, but you’ll be hard pressed to re-create the Emacs experience in vim.
For me, this is really the key attraction of Emacs. It’s not an editor; it’s a library for me to build my own ideal editor. And, in the long term, there are very few editors which can compete with this.
I'm currently in the process of moving from vim to emacs, and I've noticed that the only things from vim I really need are the modal editing and the basic keybindings - everything else, like the plugins I've come to love, are more or less interchangable, and from what I've seen, more than plentiful in emacs-land. I think comparing emacs to vim as "editors" creates a false dichotomy, one that has kept me from trying emacs for too long.
Modal editing is what made me go back to vim after 2 months of wanting to like emacs. Even with EVIL mode it didn't feel just as smooth.
Are there other ways to get modal editing in emacs?
Are there other ways to get modal editing in emacs?
> Even with EVIL mode it didn't feel just as smooth.
I’m surprised to hear this. I’d personally assess Evil highly — in some areas, it’s even better than Vim. What problem(s) did you have with it?
I’m surprised to hear this. I’d personally assess Evil highly — in some areas, it’s even better than Vim. What problem(s) did you have with it?
If you haven't done so already I'd also recommend looking at evil-collection (https://github.com/emacs-evil/evil-collection). This enables Evil keybindings throughout Emacs which can certainly help.
Checkout God Mode, which is inspired by Vim but is designed with emacs bindings in mind, not vim bindings. I used it for years (before moving to VS Code).
If you're a big user of vim macros, take a look at some of the quality of life enhancements that emacs macros have: https://www.gnu.org/software/emacs/manual/html_node/emacs/Ed... specifically kmacro-edit-macro and kmacro-edit-lossage
You can edit vim macros but it's not nearly as seamless
You can edit vim macros but it's not nearly as seamless
For me, this is a bit similar to how Linux is not really an OS, it's a set of tools with which you can build your own ideal OS. This means everyone who likes "Linux" likes a different configuration.
if you're a machinist long enough, you end up making your own tools that iron out the minor but ubiquitous quirks that drive you to the brink of madness.
I'm happy faffing around with Sublime, VSC, even Nano, but when I'm doing anything substantial over an extended period of time I'll always use Emacs, not only that but in the world of Atom Emacs has to be one of the fastest loading/running editors.
I'm happy faffing around with Sublime, VSC, even Nano, but when I'm doing anything substantial over an extended period of time I'll always use Emacs, not only that but in the world of Atom Emacs has to be one of the fastest loading/running editors.
> Emacs is not really an editor either! I believe that Emacs is the ultimate editor building material.
That quote reminds me of this quote:
> Lisp isn't a language, it's a building material. -- Alan Kay
Funny, Emacs seems to be written in Lisp . . .
That quote reminds me of this quote:
> Lisp isn't a language, it's a building material. -- Alan Kay
Funny, Emacs seems to be written in Lisp . . .
So how to learn this? I used Emacs for a couple of years long time ago, but while the experience was ok, it didn't last. Is there a book/or blog about the magic you mention?
The Emacs From Scratch series on Youtube is actually quite good. He does have all his config in a Github repository if you need to copy/paste.
This is the first video:
https://www.youtube.com/watch?v=74zOY-vgkyw
This is the first video:
https://www.youtube.com/watch?v=74zOY-vgkyw
There isn’t one in particular I can recommend (or remember). Just look up how to install packages, look at other people’s configs, explore what packages are available, and so on. That’s basically what I did.
Where do I get other ppls configs? Maybe my problem is I do not know any Emacs power users.
Emacs Prelude [1] is an excellent starting point for creating your own emacs experience, without being too heavy-weight or opinionated (as in does not deviate too much from the emacs way of doing things).
If you are a fan of vim style modal editing, Spacemacs [2] and Doom [3] are two popular emacs "distributions".
[1] https://github.com/bbatsov/prelude
[2] https://github.com/syl20bnr/spacemacs
[3] https://github.com/hlissner/doom-emacs
If you are a fan of vim style modal editing, Spacemacs [2] and Doom [3] are two popular emacs "distributions".
[1] https://github.com/bbatsov/prelude
[2] https://github.com/syl20bnr/spacemacs
[3] https://github.com/hlissner/doom-emacs
Look around at GitHub, for example.
There is, for example, mine:
https://github.com/Release-Candidate/Emacs
There is, for example, mine:
https://github.com/Release-Candidate/Emacs
What made me switch to VS Code (after using Emacs for 30+ years) was that I got tired of just how much of an easter egg hunt Emacs is for me now.
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)
Yeah so I was thinking about this...
Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.
Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..
Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.
Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.
Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.
Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..
Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.
Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.
Its worth remembering that Visual Studio also used to be regarded as really good right up until it... wasn't, and then with VS code is sort of was again. Except right now it kind of isn't.
The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?
The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.
The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?
The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.
>The fate of VS code seems to be really closely tied to TypeScript at the moment.
That's like saying the the fate of Emacs would be closely tied to Common Lisp (or Coq with Proof General). That's some languages Emacs where still beats anything else.
That's like saying the the fate of Emacs would be closely tied to Common Lisp (or Coq with Proof General). That's some languages Emacs where still beats anything else.
Since TypeScript is developed by Microsoft, its fair to say that support for TypeScript will always be best in Microsoft's Visual Studio.
> support for TypeScript will always be best in Microsoft's Visual Studio.
That typo is actually the problem. If they don't decide to make TypeScript a Visual Studio feature.
But my point is that VS Code would not be an alternative to Emacs if you could only use it for TS and Emacs wouldn't exist any more, if all that you could do with it was programming (Common) Lisp.
That typo is actually the problem. If they don't decide to make TypeScript a Visual Studio feature.
But my point is that VS Code would not be an alternative to Emacs if you could only use it for TS and Emacs wouldn't exist any more, if all that you could do with it was programming (Common) Lisp.
Hmm, what if VS Code was done in WASM with the ability to write extensions in any language with compilers that can produce WASM?
Any obvious reasons this would be a good/bad idea?
Any obvious reasons this would be a good/bad idea?
That wouldn't work, because WASM can't (directly, you need some JS bridge) interact with the DOM.
Btw. you can transpile many languages to JS.
Webassembly is the same as being able to call C libs (which don't have to be written in C) from Python. It's there to speed up bottlenecks.
Webassembly is the same as being able to call C libs (which don't have to be written in C) from Python. It's there to speed up bottlenecks.
Wouldn't it make more sense to design browsers where a WASM runtime interacts with the DOM (and architecturally make it look more like a device driver)? And you could just compile JS to WASM on demand (and possibly keep a cache).
> If it turns out that Types really are the way forward, then these will eventually be included in the JS core.
Not necessarily? TypeScript could easily continue being its own thing as it is now, and ECMAScript have shown absolutely 0 interest in adding types to the core language a-la TypeScript. Infact, the amount of work needed to enable types (supporting new syntax) would result in so much backwards compatibility breaking that it wouldn't even be feasible.
TypeScript is way more likely to remain its own thing.
Not necessarily? TypeScript could easily continue being its own thing as it is now, and ECMAScript have shown absolutely 0 interest in adding types to the core language a-la TypeScript. Infact, the amount of work needed to enable types (supporting new syntax) would result in so much backwards compatibility breaking that it wouldn't even be feasible.
TypeScript is way more likely to remain its own thing.
That might not be a bad thing.
It shouldn't be a controversial position to say that perhaps something cobbled together by an inexperienced language designer in a matter of weeks, five or six internet lifetimes ago may not be a good long term bet.
I wish browsers would set an EOL for JS support and just get on with WASM. Of course, that's never going to happen.
It shouldn't be a controversial position to say that perhaps something cobbled together by an inexperienced language designer in a matter of weeks, five or six internet lifetimes ago may not be a good long term bet.
I wish browsers would set an EOL for JS support and just get on with WASM. Of course, that's never going to happen.
> I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.
That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.
What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.
Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.
That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.
What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.
Spacemacs seems to be dead. 0.300 has been promised for years but still hasn't gone stable.
It's no problem (relatively) to live on `develop`
If you don't mind diffing your .spacemacs and re-customising your <theme>.el every time you update.
Very different experience for me, working with Go using Emacs has been pretty smooth sailing from day one (which for me was around the Go 1.0 release).
go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.
The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.
Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.
Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.
go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.
The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.
Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.
Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.
This is unbelievable to me who has been emacs user for this long. What i have seen so far is people whos customize heavily and use as a way of life or people who don't like after trying for some time and move away to other editors. There is another category of people who use for a specific purpose regularly(like org mode users) without making any customization or learning elisp. But your case is special. What is your level of mastery in emacs and elisp?
I used to have a decent working knowledge of Emacs Lisp, but I wouldn't use words like "mastery". I could get stuff done. However, I haven't done any development in elisp for at least 15 years. Think of it has car ownership: I might have been interested in repairing my own car in the past, now I just want a car that does what it says on the tin and not have to futz around with it.
I used to have a highly customized Emacs setup with a lot of code that would automate lots of tasks for different programming languages and environments. I essentially ended up using an email reader that I found somewhere and then rewrote to include a lot of automation of the way I did my email.
Of course, things changed over time. My customizations started breaking - more and faster each year. I went from having my email delivered on a traditional mailbox file, to using IMAP. Along the way I had to use POP (because I could emulate having a mailbox file) the client needed a major rewrite to deal with IMAP and in the middle of the rewrite I gave up because something else broke. I have always worked on multiple machines, so I had to synchronize setups - sometimes between machines with different emacs versions.
I used Emacs for fewer and fewer things until it was only used for writing code and markdown files.
Heavily customizing anything is risky because at some point you become the sole maintainer of a lot of code. At one point I'd spend perhaps 2-3 days per month programming Emacs Lisp - which, at the time, was not all that great.
I don't customize software I depend on that much anymore. Including keybindings. It is cheaper to try to learn defaults, and if you put your ego aside, usually not that big of a deal. This doesn't mean you can't add functionality or customize it - it just means you shouldn't have to rewire the innards to accomplish it.
Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride. And more so the more you customize. Things are a bit too "freeform". You end up saying no to a lot of things you could have had for free because things start to clash with your customizations. "You broke it, now you own it".
I have a very clear benchmark for what might bring me back to Emacs: be able to set up Emacs from scratch in 10 minutes so that I can program in Go, have good language server support, easy access to documentation, and a lot of the things I used to have before, but which simply rotted away over the past few years.
....and then not have it break in a way that requires more than a couple of minutes of my attention for a year.
I used to have a highly customized Emacs setup with a lot of code that would automate lots of tasks for different programming languages and environments. I essentially ended up using an email reader that I found somewhere and then rewrote to include a lot of automation of the way I did my email.
Of course, things changed over time. My customizations started breaking - more and faster each year. I went from having my email delivered on a traditional mailbox file, to using IMAP. Along the way I had to use POP (because I could emulate having a mailbox file) the client needed a major rewrite to deal with IMAP and in the middle of the rewrite I gave up because something else broke. I have always worked on multiple machines, so I had to synchronize setups - sometimes between machines with different emacs versions.
I used Emacs for fewer and fewer things until it was only used for writing code and markdown files.
Heavily customizing anything is risky because at some point you become the sole maintainer of a lot of code. At one point I'd spend perhaps 2-3 days per month programming Emacs Lisp - which, at the time, was not all that great.
I don't customize software I depend on that much anymore. Including keybindings. It is cheaper to try to learn defaults, and if you put your ego aside, usually not that big of a deal. This doesn't mean you can't add functionality or customize it - it just means you shouldn't have to rewire the innards to accomplish it.
Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride. And more so the more you customize. Things are a bit too "freeform". You end up saying no to a lot of things you could have had for free because things start to clash with your customizations. "You broke it, now you own it".
I have a very clear benchmark for what might bring me back to Emacs: be able to set up Emacs from scratch in 10 minutes so that I can program in Go, have good language server support, easy access to documentation, and a lot of the things I used to have before, but which simply rotted away over the past few years.
....and then not have it break in a way that requires more than a couple of minutes of my attention for a year.
> Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride.
That's because you (and each extension) has access to 'the' editor itself, whereas with for example Code, the plugin API is limited. Yes, you cannot change everything, but you also cannot break everything.
That's because you (and each extension) has access to 'the' editor itself, whereas with for example Code, the plugin API is limited. Yes, you cannot change everything, but you also cannot break everything.
If we are to believe that the states of the two editing environments are the products of this distinction (yes, wild oversimplification, but bear with me), I would say that we kind of know which way produces the greatest good for the most users?
I presently use VS code at work as well, but not because it so nice, but rather that I can setup it from scratch to the tolerable state within 20 minutes including extension installation time and it works very similar on Linux/Mac/Windows (I need to work on all platforms and cross-platform functionality is a must). Plus it works on huge source tree like Chromium with fast file opening and whole tree search with almost no setup (VS Code hits some default limits on amount og Git modules, but that can be adjusted).
I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.
And for hobby projects I am happy with Geany on Linux.
I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.
And for hobby projects I am happy with Geany on Linux.
This is why I've been using Spacemacs as my primary editor for years now: cross-platform support, automatic language detection, package installation, well-designed key bindings, great documentation, etc. Not to mention significant productivity gains from packages such as magit (it's always fun when people see Git time machine in action--using the n/p keys to move backwards and forwards in time to see every change to a file, along with the commit message).
And it works across all major OSes. Just copy your .spacemacs file to a new laptop, and wait for everything to install itself.
To be fair, I use VS Code pretty regularly as well. But more of a nicer alternative to TextEdit/Gedit/etc. to capture notes as I work in Spacemacs (of course, there's also the helpful scratch buffer).
[0] https://www.spacemacs.org
And it works across all major OSes. Just copy your .spacemacs file to a new laptop, and wait for everything to install itself.
To be fair, I use VS Code pretty regularly as well. But more of a nicer alternative to TextEdit/Gedit/etc. to capture notes as I work in Spacemacs (of course, there's also the helpful scratch buffer).
[0] https://www.spacemacs.org
To each their own, but it doesn't take long to setup Emacs from scratch to the exact state I want.
git clone myemacs
mv myemacs ~/.emacs.d
emacsThe point is not to spend time writing init.el in the first place. I only need to setup few times per year and the time I spent writing my init file for Emacs is way bigger than I can save even in 100 years of using VS code.
Some people enjoy hacking their configs, but for me the changes were due to Emacs defaults not to my taste. So I got no pleasure in writing the thing.
Some people enjoy hacking their configs, but for me the changes were due to Emacs defaults not to my taste. So I got no pleasure in writing the thing.
Do you use the syncing features? I sync to Github, so if I install VS Code on a new machine it takes a lot less than 20 minutes. That bit works great.
I have not bothered to use sync as I can setup VS code fast enough without it. Plus there are settings that require platform-specific adjustments. Maybe there are some ifs in the config that covers it, but I just see no point to spend time figure out it when I know I can spent 20 minutes max few times a year and do the setup from scratch.
It takes a couple minutes, at most, if you sync settings.
I’ve been using Emacs for Go dev for years and have barely touched my Go-related config. It’s vanilla lsp-mode with some hooks like format-on-save.
It was more fiddly when I started because gopls was new, but now it’s just rock solid (and fast).
It was more fiddly when I started because gopls was new, but now it’s just rock solid (and fast).
>Emacs continually being changed, any setup that works will eventually stop working
Any specific example of Emacs being changed to break your workflow?
Any specific example of Emacs being changed to break your workflow?
Go support is one example. If you set up Emacs to provide decent support for Go at different times between 2015 (when I started using Go) and today, the setup would probably last an average of 18 months or so before you lose something significant and had to sit down and bodge something together to get some replacement for functionality that just died.
I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.
I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.
Could that have to do something with changes in go tooling (something that you alluded to in your original comment) rather than emacs itself? I am sorry I am not familiar with the go ecosystem at all.
In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs.
Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.
In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs.
Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.
Most certainly. Go tooling and some of the usage has evolved quite a bit since 2015.
If you pick a language designed by someone who explicitly hates tooling, then you are bound to suffer from the lack of good tooling.
Assuming that you are talking about Go, I don't know where you are getting that from.
Go has had excellent tooling from early on. Standard code formatting with gofmt from day 1 was HUGE. godoc, godef, goimports and oracle were also available from early on. And then when LSP came along we got multiple LSP server implementations fairly quickly.
I don't have a link around but I am fairly certain that getting the basic tooling into shape was one of the priorities before the 1.0 release.
Go has had excellent tooling from early on. Standard code formatting with gofmt from day 1 was HUGE. godoc, godef, goimports and oracle were also available from early on. And then when LSP came along we got multiple LSP server implementations fairly quickly.
I don't have a link around but I am fairly certain that getting the basic tooling into shape was one of the priorities before the 1.0 release.
What makes Emacs unique to me doesn't have anything to do editing code. All the tools for doing that are incredibly similar, specially after LSP became a thing. Writing code in Emacs or VSC is practically the same for me, though I happen to prefer the former.
It's mainly about how powerful plaintext is and how Emacs and it's community acknowledged that. Org and org-roam are extensions of my brain by now, I've even installed Emacs in my smartphone because of that. Ledger-mode is the most ideal finance management I could conceive, and I've set-up Emacs (CUA-mode with just a ledger hydra) for two family members so they could use it too. I have absolutely no idea how I could make Ledger tolerable to non-technical people without Emacs. I also create beautiful presentations in a couple of minutes using org-reveal.
Besides, it's hack-ability certainly inspires inumerable beautiful creations. Some packages like Magit, Hydra, Helm and avy are just that, beautiful. When I don't feel like programming, I change some config and write programs as an excuse to test it, because Emacs is fun. It's no wonder people who act like understanding your editor is a chore have a bad experience, they're missing the point.
It's mainly about how powerful plaintext is and how Emacs and it's community acknowledged that. Org and org-roam are extensions of my brain by now, I've even installed Emacs in my smartphone because of that. Ledger-mode is the most ideal finance management I could conceive, and I've set-up Emacs (CUA-mode with just a ledger hydra) for two family members so they could use it too. I have absolutely no idea how I could make Ledger tolerable to non-technical people without Emacs. I also create beautiful presentations in a couple of minutes using org-reveal.
Besides, it's hack-ability certainly inspires inumerable beautiful creations. Some packages like Magit, Hydra, Helm and avy are just that, beautiful. When I don't feel like programming, I change some config and write programs as an excuse to test it, because Emacs is fun. It's no wonder people who act like understanding your editor is a chore have a bad experience, they're missing the point.
Very nice, after your original article I started using Emacs more and more on my Linux Systems (I dabbled with it before). And in 99% of the time I prefer Emacs.
On OpenBSD there is one nit, and googling only suggested 1 fix. I am a heavy RCS user, but Emacs RCS package fails on OpenBSD due to its Base RCS. The only fix I can find is to install GNU RCS and disable OpenBSD Base RCS. I tried to find and fix the Lisp package, but it is way beyond my skill level.
OpenBSD people seems unconcerned about correcting their RCS to work with Emacs (maybe a security thing). I believe the same seems to be the case Emacs RCS people, I think they would prefer the use of GNU RCS (understandable).
I would prefer to use OpenBSD Base RCS but I am caught between two projects. So on OpenBSD I stick with vim until I can find a workable solution.
On OpenBSD there is one nit, and googling only suggested 1 fix. I am a heavy RCS user, but Emacs RCS package fails on OpenBSD due to its Base RCS. The only fix I can find is to install GNU RCS and disable OpenBSD Base RCS. I tried to find and fix the Lisp package, but it is way beyond my skill level.
OpenBSD people seems unconcerned about correcting their RCS to work with Emacs (maybe a security thing). I believe the same seems to be the case Emacs RCS people, I think they would prefer the use of GNU RCS (understandable).
I would prefer to use OpenBSD Base RCS but I am caught between two projects. So on OpenBSD I stick with vim until I can find a workable solution.
> Beware - Emacs is highly addictive and it might easily consume years of your life!
I agree with that wholeheartedly. Don’t get me wrong—I love emacs and I’ll be the first to talk your ear off about it.
But it’s a hobby, and not necessarily worth the time investment compared with other editors, if you’re looking for something that “just works” and has all the modern features.
I agree with that wholeheartedly. Don’t get me wrong—I love emacs and I’ll be the first to talk your ear off about it.
But it’s a hobby, and not necessarily worth the time investment compared with other editors, if you’re looking for something that “just works” and has all the modern features.
Now that you've gotten the ritual disclaimers out of the way, though, Emacs time investment pays off big time. Survivorship bias, sure, but you certainly don't need to go full Colonel Kurtz into the Emacs rabbit-hole like Bohzidar, before you can reap benefits- it really is a gift that keeps on giving.
I just spent a couple days getting my corporate e-mail to work in emacs(settled on gnus+offlineimap+notmuch).
I even got syntax highlighting for patches and wrote some lisp to link up notmuch search results to gnus- so I can search for an e-mail and find the whole thread easily.
Of course, I could have just started evolution and been done, but this stuff is fun!
I even got syntax highlighting for patches and wrote some lisp to link up notmuch search results to gnus- so I can search for an e-mail and find the whole thread easily.
Of course, I could have just started evolution and been done, but this stuff is fun!
Agreed. I find myself struggling to recommend it to newcomers - it is just so esoteric to anyone used to ctrl+C for copy. But I can't imagine life without it.
At my last job, I was forced to use PyCharm. Fine an IDE it probably is, I hated every second of it. Within 3 days I ditched it for Emacs.
At my last job, I was forced to use PyCharm. Fine an IDE it probably is, I hated every second of it. Within 3 days I ditched it for Emacs.
> it is just so esoteric to anyone used to ctrl+C for copy
Come on. „CUA mode“ exists since the 90s. ;)
Come on. „CUA mode“ exists since the 90s. ;)
I assume you're being sarcastic, but an Emacs beginner has no idea what 'CUA mode' is.
Jokes aside, Emacs UX is just completely different to anything modern. Computer users not enlightened by Emacsen try to press Esc to get out of trouble, assume scrolling doesn't move the cursor, etc. Chorded keybindings are a mind-blow, and they have their own further pitfalls too.
I either got used to Emacs behaviours, or find them superior (can't tell which one) but frankly I think they might be a big deterrent. For new users, it must be like getting into a car where all the controls are different. Brake and accelerator swapped, clutch is hand-operated (and woe to you if you've only driven automatic), stems are swapped, and some vital controls are operated by pressing buttons with the top of your head. Computer programs of the past 20 years have some basic common behaviours that are almost synonymous with basic IT skills, and Emacs diverges in many of them.
I adopted Emacs in the relative modernity of 2012, when I joined a mostly-airgapped Linux environment and needed a power editor. I persevered and grew to love Emacs, but frankly if I could have downloaded VS Code or Pycharm, I probably would have done.
Jokes aside, Emacs UX is just completely different to anything modern. Computer users not enlightened by Emacsen try to press Esc to get out of trouble, assume scrolling doesn't move the cursor, etc. Chorded keybindings are a mind-blow, and they have their own further pitfalls too.
I either got used to Emacs behaviours, or find them superior (can't tell which one) but frankly I think they might be a big deterrent. For new users, it must be like getting into a car where all the controls are different. Brake and accelerator swapped, clutch is hand-operated (and woe to you if you've only driven automatic), stems are swapped, and some vital controls are operated by pressing buttons with the top of your head. Computer programs of the past 20 years have some basic common behaviours that are almost synonymous with basic IT skills, and Emacs diverges in many of them.
I adopted Emacs in the relative modernity of 2012, when I joined a mostly-airgapped Linux environment and needed a power editor. I persevered and grew to love Emacs, but frankly if I could have downloaded VS Code or Pycharm, I probably would have done.
> an Emacs beginner has no idea what 'CUA mode' is.
It’s in the menu bar, under “Options” → “Use CUA Keys (Cut/Paste with C-x/C-c/C-v)”, beside an on/off checkbox. How could it possibly be made to be any easier to find and understand (except to make it enabled by default)?
It’s in the menu bar, under “Options” → “Use CUA Keys (Cut/Paste with C-x/C-c/C-v)”, beside an on/off checkbox. How could it possibly be made to be any easier to find and understand (except to make it enabled by default)?
There have been some discussions on the mailing list about prompting users when emacs first runs to figure out whether they want CUA, evil, or normal bindings. I think that would go a long way to easing the initial “I can’t even write text” experience that is often emacs out of the box for new users.
Make it enabled by default.
There shouldn't be any goddamn high places!
There shouldn't be any goddamn high places!
But it breaks others’ preferred behavior. It also does not play nice with keyboard macros. Emacs is software way older than most Junior developers and needs to cater so many very different use cases and extension libraries.
The others who prefer Emacs's default behavior are a dwindling constituency of the user base. Eventually they will all be dead, and the only people becoming users of Emacs (if any) will be people used to the Windows/Mac way of doing things.
You have to meet your users where they are, otherwise you won't have users. For desktop applications, that means using the standard interface conventions and shortcuts for common operations.
You have to meet your users where they are, otherwise you won't have users. For desktop applications, that means using the standard interface conventions and shortcuts for common operations.
The way this was proposed was, only prompt for the modern-user-friendly options like CUA mode if the user doesn't have an ~/.emacs.d/init.el or .emacs file, which makes some sense to me. Emacs isn't the kind of thing you run on remote machines and expect it to be at all like the one you have locally (like you can mostly do with vi).
> Computer users not enlightened by Emacsen try to press Esc to get out of trouble
That actually does work, if you press ESC three times. It’s a special case in Emacs, added just to make it easier for people who hammer the ESC key to abort.
That actually does work, if you press ESC three times. It’s a special case in Emacs, added just to make it easier for people who hammer the ESC key to abort.
For me it closes all but 1 window, hardly what I'd hope for.
True, though, that it gets me out of the mini-buffer, same as C-g. I didn't know that works - nice.
Btw, here's another thing. How many times as a beginner was I stuck in the mini-buffer and had no idea what's going on? The new editors have some kind of command palette, which is vaguely similar, but I don't think you can get stuck in it.
True, though, that it gets me out of the mini-buffer, same as C-g. I didn't know that works - nice.
Btw, here's another thing. How many times as a beginner was I stuck in the mini-buffer and had no idea what's going on? The new editors have some kind of command palette, which is vaguely similar, but I don't think you can get stuck in it.
You know what CUA mode is if you're older than 50. CUA mode was introduced in our 20's :-) If younger, you just can't now. It's like saying let's do it the "CORBA" way. Only the old guard will know...
The earlier article, discussed at the time:
Why Emacs? - https://news.ycombinator.com/item?id=3256721 - Nov 2011 (128 comments)
Why Emacs? - https://news.ycombinator.com/item?id=3256721 - Nov 2011 (128 comments)
Thanks for sharing!
I like that the author hit on the curious and fun aspect of emacs. Whenever people talk about IDEs and editors, there's so much focus on things like efficiency, practicality, and return on investment.
I don't use emacs because I did some cost-benefit analysis on my editor. I tried emacs and found that it's a whole lot of fun, which of course is why I got into programming in the first place - I found it, and still find it, fun.
If you view programming as a job in the same way something like being a tax account is a job, then learning emacs is probably not for you, you're better off with something like VS Code that asks very little of its users and gives you a nice working environment right out of the box.
Emacs is great if, as the author notes, you're an intellectually curious person who genuinely enjoys tinkering. If that's the case, you'll most likely have a lot of fun with emacs. It's very hard to describe how much fun it is to edit and modify your development environment in real time while you're working in that very same development environment.
I don't use emacs because I did some cost-benefit analysis on my editor. I tried emacs and found that it's a whole lot of fun, which of course is why I got into programming in the first place - I found it, and still find it, fun.
If you view programming as a job in the same way something like being a tax account is a job, then learning emacs is probably not for you, you're better off with something like VS Code that asks very little of its users and gives you a nice working environment right out of the box.
Emacs is great if, as the author notes, you're an intellectually curious person who genuinely enjoys tinkering. If that's the case, you'll most likely have a lot of fun with emacs. It's very hard to describe how much fun it is to edit and modify your development environment in real time while you're working in that very same development environment.
Author is none other than @bbatsov, who created Rubocop, Cider, Emacs Projectile, etc. I have huge respect and his work/contribution in open source definitely lends credibility for his writing, even if you may not agree with some of his opinion. As a side note, I've always wanted to get into emacs, even though I'm ok as a vimmer/vscode user.
I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc.
Two of those editors are Mac-only, and only one editor is open source. I suspect if Sublime had become open (and cross-platform), it would be significant "player" in the editor wars. Atom has mostly died on the vine, thanks to VS Code. That doesn't negate any of the author's points about Emacs, but, aside from VS Code (and, I guess, Atom), there have been few efforts to create a performant[0] cross-platform, IDE-like editor.
[0] Insert comments about VS Code's performance here.
Two of those editors are Mac-only, and only one editor is open source. I suspect if Sublime had become open (and cross-platform), it would be significant "player" in the editor wars. Atom has mostly died on the vine, thanks to VS Code. That doesn't negate any of the author's points about Emacs, but, aside from VS Code (and, I guess, Atom), there have been few efforts to create a performant[0] cross-platform, IDE-like editor.
[0] Insert comments about VS Code's performance here.
That's a fair point, although I can think of examples in the IDE reals as well - e.g. in the world of Java Eclipse and NetBeans were popular (and open-source), but gradually IntelliJ IDEA dominated them for various reasons. I also remember all the Borland tools (super popular in the 90s) that have mostly disappeared by now. I definitely think that open-source projects are more likely to survive long-term, but it's not like they don't fail.
Btw, I think TextMate is open-source these days as well.
Btw, I think TextMate is open-source these days as well.
My take on some of these comments as someone who has used Emacs almost exclusively for my day job for around 4 years:
Emacs is not rock solid.
It's easy to bring Emacs to a standstill with something as simple as a long string. This is especially apparent outside Linux, e.g. on Mac OS (Windows is a whole other story). It's a fundamental flaw in the text editor, and I don't know if there is any solution on the horizon.
Text editing can also become noticeably slower once many of the must-have Emacs packages are in use.
At the same time, becoming somewhat proficient at Emacs and knowing a thing or two about Emacs Lisp has made me a better programmer, and certainly more productive in the use of my editor.
If Emacs can solve some of its performance issues, and perhaps make things like the Debug Adapter Protocol easier to set up, it will continue to be in a league of its own and an essential editor to many for the foreseeable future.
Emacs is not rock solid.
It's easy to bring Emacs to a standstill with something as simple as a long string. This is especially apparent outside Linux, e.g. on Mac OS (Windows is a whole other story). It's a fundamental flaw in the text editor, and I don't know if there is any solution on the horizon.
Text editing can also become noticeably slower once many of the must-have Emacs packages are in use.
At the same time, becoming somewhat proficient at Emacs and knowing a thing or two about Emacs Lisp has made me a better programmer, and certainly more productive in the use of my editor.
If Emacs can solve some of its performance issues, and perhaps make things like the Debug Adapter Protocol easier to set up, it will continue to be in a league of its own and an essential editor to many for the foreseeable future.
Emacs is my personal little starship that helps me cruise the vast universe of computers :)
Org-mode is Emacs's "killer library" for me.
Also magit !
Absolutely. git at the command line works fine but I have always found it very dense, and prefer to use it only for very basic or very specific tasks. Magit makes all the usual things I do with git so easy.
I have been using Emacs on Windows for a couple of years, but I have been transitioning to using Linux full-time at work, and by the end of the year I won't have to deal with the slowness of Magit (and git in general) under Windows.
I have been using Emacs on Windows for a couple of years, but I have been transitioning to using Linux full-time at work, and by the end of the year I won't have to deal with the slowness of Magit (and git in general) under Windows.
Magit is what got me hooked. I just find it the best way to interface with git other than via the terminal.
>One thing hasn’t changed though - I still love Emacs and I’m quite passionate about it.
As passionate in your love for Emacs as Kyle Machulis is? ;)
https://news.ycombinator.com/item?id=29207607
https://github.com/qdot/deldo
https://www.youtube.com/watch?v=D1sXuHnf_lo
As passionate in your love for Emacs as Kyle Machulis is? ;)
https://news.ycombinator.com/item?id=29207607
https://github.com/qdot/deldo
https://www.youtube.com/watch?v=D1sXuHnf_lo
My experience with Emacs is bittersweet. On the one hand, org-mode in Emacs is extremely powerful. I use it to schedule TODO items, organize my thoughts, write notes, publish websites, and lots of other things. On the other hand, Emacs drives me crazy from time to time. It's slow, hard to maintain, the environment I set up is fragile, and most of all, it lacks a modern UI. Scrolling pixel by pixel is still impossible in Emacs.
Sometimes I do use VSCode as an alternative, but VSCode only has a rudimentary implementation of org-mode, and the so-called org-mode alternative - markdown - is not nearly as powerful as org-mode.
Sometimes I do use VSCode as an alternative, but VSCode only has a rudimentary implementation of org-mode, and the so-called org-mode alternative - markdown - is not nearly as powerful as org-mode.
Does pixel-scroll-mode[1] not do what you want? It’s a built-in feature.
[1] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/pixel-s...
[1] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/pixel-s...
> pixel-scroll-mode was introduced at or before Emacs version 26.1.
The third-party package "good-scroll" improves on pixel-scroll-mode by adding variable speed. IME, it's necessary in order to prevent flickering from pixel-scroll-mode. The defaults are somewhat conservative, and might not look like "scrolling pixel by pixel" to you, but you can definitely customize it to get what you want.
The third-party package "good-scroll" improves on pixel-scroll-mode by adding variable speed. IME, it's necessary in order to prevent flickering from pixel-scroll-mode. The defaults are somewhat conservative, and might not look like "scrolling pixel by pixel" to you, but you can definitely customize it to get what you want.
Thanks. Actually I've tried both the built-in pixel-scroll-mode and good-scroll. None of them gives me the experience of a modern text-editor (e.g. VSCode).
Hmm. I honestly can't tell the difference between the behavior of good-scroll and VS Code (have them both open right now, on Windows). But there must be something that you notice that bugs you that I don't.
Related: My biggest complaint with Emacs is that when you scroll, the cursor moves to keep itself visible on-screen at all times. Modern text editors don't behave this way--it's easy to scroll to a different location to look at something without losing your insertion point.
Has anybody written a patch for Emacs to implement this behavior?
Has anybody written a patch for Emacs to implement this behavior?
I don't think so, and I think it might involve unreasonable changes to core.
The "Emacs Way" here is to use a command that takes you back to where you were before. If you used tags navigation to get to what you wanted to look at, you could use `pop-tag-mark`, which is on M-, (other modes for getting around, like xref and LSP use the same binding). Or failing that, if you know you're staying in the same buffer, you can `set-mark-command`, scroll to where you want to look, and `exchange-point-and-mark` (and then deactivate the mark with C-g if you were in transient-mark-mode, which most people are these days).
There's also a package `dogears' (https://github.com/alphapapa/dogears.el) for saving your place to go back to automatically even if you're just scrolling.
I recognize that all these solutions are not intuitive to someone who expects the cursor position to stay in the same place even if it scrolls offscreen.
The "Emacs Way" here is to use a command that takes you back to where you were before. If you used tags navigation to get to what you wanted to look at, you could use `pop-tag-mark`, which is on M-, (other modes for getting around, like xref and LSP use the same binding). Or failing that, if you know you're staying in the same buffer, you can `set-mark-command`, scroll to where you want to look, and `exchange-point-and-mark` (and then deactivate the mark with C-g if you were in transient-mark-mode, which most people are these days).
There's also a package `dogears' (https://github.com/alphapapa/dogears.el) for saving your place to go back to automatically even if you're just scrolling.
I recognize that all these solutions are not intuitive to someone who expects the cursor position to stay in the same place even if it scrolls offscreen.
Thanks. I was used to doing things 'the Emacs way' many years ago before GUI editors were common but now I go back and forth between Emacs and GUI editors a lot and Emacs seems like the odd duck. Guess I just need to relearn this stuff because the other features Emacs brings to the table (e.g. Magit) are too handy to do without.
One of the things I've found as I grow older is that I spend less and less time customising my environment, and learn to enjoy the defaults. I've never managed to get a proper dotfiles setup, despite trying, so moving between machines -- especially when they're not my machines -- means reestablishing all the settings I want to keep.
I used to live inside Emacs -- not just for coding but for mail and news too. But nowadays I use Jetbrains IDEs for development and a reasonably clean vim for editing random files.
I used to live inside Emacs -- not just for coding but for mail and news too. But nowadays I use Jetbrains IDEs for development and a reasonably clean vim for editing random files.
Every time I use a editor, I miss elisp freedom. Now other ones are programmable but a capable lisp in a dynamic env is still such a comfy spot to live in.
When I meet quite practical devs that are into PHP or Java, they always recommend IntelliJ. Can anyone of that crowd that also have a solid understanding of Emacs do a short comparison between the two?
I'd really appreciate it.
Currently, I've only mustered enough courage and time to understand enough of vim to not feel scared of it anymore (vimtutor was the silver bullet for me there, learning enough vim in an hour to feel fine with it).
I'd really appreciate it.
Currently, I've only mustered enough courage and time to understand enough of vim to not feel scared of it anymore (vimtutor was the silver bullet for me there, learning enough vim in an hour to feel fine with it).
I think it's as simple as: Emacs is like VS Code, IntelliJ is like Visual Studio.
JetBrains makes great IDEs, and you should use them if you're working on a large project that one of those IDEs is geared towards. It'd take a lot of work to get any other editor to have the same feature-set and organization of workspace.
Emacs is a general-purpose environment for writing, and you should use it if you want a specific flow for writing code, or anything else. You can setup plugins so that it's like a mini IDE for most of the languages you write in, and you can setup plugins to modify the organization of your workspace. You want tabs? Add them. You want a tree view of your current project folder? Add one. You want Vim-style editing? Enable it. Etc.
Right now it seems everyone is looking for a code editor that is extensible and fast - Emacs fits that bill better than VS Code (also Neovim might end up being even better!), but it's more difficult to get it right. That's why there are projects like Spacemacs and Doom Emacs to make adding/removing plugins easier, and also have a good setup out of the box.
JetBrains makes great IDEs, and you should use them if you're working on a large project that one of those IDEs is geared towards. It'd take a lot of work to get any other editor to have the same feature-set and organization of workspace.
Emacs is a general-purpose environment for writing, and you should use it if you want a specific flow for writing code, or anything else. You can setup plugins so that it's like a mini IDE for most of the languages you write in, and you can setup plugins to modify the organization of your workspace. You want tabs? Add them. You want a tree view of your current project folder? Add one. You want Vim-style editing? Enable it. Etc.
Right now it seems everyone is looking for a code editor that is extensible and fast - Emacs fits that bill better than VS Code (also Neovim might end up being even better!), but it's more difficult to get it right. That's why there are projects like Spacemacs and Doom Emacs to make adding/removing plugins easier, and also have a good setup out of the box.
I use both for almost 10 years, here are my experiences:
The main advantage of IntelliJ or any other IDE by JetBrains over Emacs, is that the out of box experience IDE provided, especially from a new programmer's perspective. All they need to do to click a button, check few checkbox, then IDE will resolve it for you and tell you what happened.
But to make Emacs do any complex behaviors, you usually have to write additional codes or configurations to glue different features together. Not to mention you need to read documents and debug it when there is an error. In JetBrains IDEs those are integrated already. A context-aware error detection and code inspection is available the second you open the IDE first time. That is something default Emacs can never do.
The main advantage on Emacs over IDEs, is that you can ask Emacs to do whatever you want as long as you know how to implement it. Practically speaking, you most likely will accumulate many little functions over time that is specific designed for your workflows. That kind of customizability is something IDEs cannot provide. I do not consider myself an Emacs power user, but I still benefit form it.
Emacs is also have better text editing features in general. You can use the same features no matter what text file you are editing. That's why people want to use Emacs for everything.
In short, they are different tools, use it where it is suitable for you.
For me, I whine about how bad the editor is when I use IDE, then I complain about how bad the integration my Emacs has between multiple tools (mainly my inability to make it work).
Hope this give you some ideas.
The main advantage of IntelliJ or any other IDE by JetBrains over Emacs, is that the out of box experience IDE provided, especially from a new programmer's perspective. All they need to do to click a button, check few checkbox, then IDE will resolve it for you and tell you what happened.
But to make Emacs do any complex behaviors, you usually have to write additional codes or configurations to glue different features together. Not to mention you need to read documents and debug it when there is an error. In JetBrains IDEs those are integrated already. A context-aware error detection and code inspection is available the second you open the IDE first time. That is something default Emacs can never do.
The main advantage on Emacs over IDEs, is that you can ask Emacs to do whatever you want as long as you know how to implement it. Practically speaking, you most likely will accumulate many little functions over time that is specific designed for your workflows. That kind of customizability is something IDEs cannot provide. I do not consider myself an Emacs power user, but I still benefit form it.
Emacs is also have better text editing features in general. You can use the same features no matter what text file you are editing. That's why people want to use Emacs for everything.
In short, they are different tools, use it where it is suitable for you.
For me, I whine about how bad the editor is when I use IDE, then I complain about how bad the integration my Emacs has between multiple tools (mainly my inability to make it work).
Hope this give you some ideas.
Why would I need emacs for "complex behaviours" if I have <insert any programming language> installed on my computer?
For example, I made a lot of scripts in Python to refactor codebases by automatically splitting files (including imports). Could I do that with emacs? Probably yes. But why?
For most intents and purposes it doesn't matter if your "automated editing" environment is integrated in your editor.
For example, I made a lot of scripts in Python to refactor codebases by automatically splitting files (including imports). Could I do that with emacs? Probably yes. But why?
For most intents and purposes it doesn't matter if your "automated editing" environment is integrated in your editor.
Is it still true that saving a file you are working on is Ctrl-x Ctrl-s?
I am sorry but I will take vim's :w normal/insert/visual mode hell over this simplistic but cumbersome ergonomics issue any day.
(disclaimer: happy vim user but always looking :) )
(disclaimer: happy vim user but always looking :) )
You'd rather hit 4 keys over 3? And use 2 hands instead of 1 (US keyboards)?
shift semicolon w enter
ctrl x s
(Flaming in jest and good heartedness)
shift semicolon w enter
ctrl x s
(Flaming in jest and good heartedness)
Well, it's been years (like 15 or so) since I gave it a go, really, so maybe I should try again. But, yes, holding Ctrl and then pressing X and then S seemed too cumbersome for an ordinary operation like saving your buffer (or frame?).
Back then I was also using vim in mswin mode where Ctrl-S would save the file, just like in Windows.
Interestingly, though, I still find :w<Enter> easier. Maybe it's muscle memory now, maybe because I don't need to hold a second key for two key strokes, maybe colon is easier for me, maybe...
I guess I need to check my habits more closely :)
Back then I was also using vim in mswin mode where Ctrl-S would save the file, just like in Windows.
Interestingly, though, I still find :w<Enter> easier. Maybe it's muscle memory now, maybe because I don't need to hold a second key for two key strokes, maybe colon is easier for me, maybe...
I guess I need to check my habits more closely :)
I know this is (partially) a joke, but it does raise an interesting point to me (as a vi heathen), why does :w seem easier to remember than C-x C-s?
I guess it's the modality, I know ':' indicates the start of an ex command, and "w"rite saves the file, while I only see C-x C-c as a "single token".
I supposed it's just C-x for "execute command" and ... I'm not sure why it's control c, instead of just c, or s, or w...
I guess it's the modality, I know ':' indicates the start of an ex command, and "w"rite saves the file, while I only see C-x C-c as a "single token".
I supposed it's just C-x for "execute command" and ... I'm not sure why it's control c, instead of just c, or s, or w...
Just a nitpick, emacs is every bit as "modal" as vim. If you configured vim to start up in insertion mode and had to ^O to do every normal mode command, it would be somewhat close to Emacs's fundamental-mode.
C-x enters a keymap called the `ctl-x-map`, lots of file-related commands live in there but also half a million other things. It's very similar to `:` to enter an ex command or, more accurately, `g` as a prefix to a million different vim commands.
If you ever find yourself in emacs again, try typing C-x (to enter the `ctl-x-map`) and then hit C-h. This shows the help for the Ctrl-x keymap, and you'll see it's somewhat well-organized, if completely arbitrary. For instance, if you hit `C-x 5` you'll be in a sub-keymap (the ctl-x-5-map) which has a lot of frame-specific management mappings. Why is it under `5`? Historical reasons, no doubt, but it's inscrutable to normies like me.
C-x enters a keymap called the `ctl-x-map`, lots of file-related commands live in there but also half a million other things. It's very similar to `:` to enter an ex command or, more accurately, `g` as a prefix to a million different vim commands.
If you ever find yourself in emacs again, try typing C-x (to enter the `ctl-x-map`) and then hit C-h. This shows the help for the Ctrl-x keymap, and you'll see it's somewhat well-organized, if completely arbitrary. For instance, if you hit `C-x 5` you'll be in a sub-keymap (the ctl-x-5-map) which has a lot of frame-specific management mappings. Why is it under `5`? Historical reasons, no doubt, but it's inscrutable to normies like me.
Thanks for the explanation. As I wrote in another reply, maybe I should try again :)
Magit is the thing that keeps my tied to emacs. No other tool gives me such a good experience interfacing with git.
[deleted]
i'm one of them traitors that switched to vscode from emacs. over time i just realized that i'm spending too much time coding the code editor, just can't stop, there's always something that isn't perfect, always some new approach or new extension, always a better way somebody else solves the same problem. got tired of playing catch-up.
with emacs i have this mindset, that emacs can do literally anything and be perfect for my brain with enough tuning. with vscode i know it's limited and don't bother fixing it, just muscle-memory the workarounds.
i do miss magit.
with emacs i have this mindset, that emacs can do literally anything and be perfect for my brain with enough tuning. with vscode i know it's limited and don't bother fixing it, just muscle-memory the workarounds.
i do miss magit.
Would you have a little time to describe how you made that switch? I've worried multiple times that I'm too deeply immersed in the emacs ecosystem and have wanted to try branching out into a different editor to see what I might be missing. However, when I spent a month using vscode, it was just a month of lost productivity. I found the interface completely inscrutable and couldn't find any good explanations of how to think about vscode.
As a concrete example, for the main project I work on, we usually configure via CMake and then build through Ninja. A simple `cmake` command followed by a `ninja -j4` was all I needed to get everything built. However, I could never get vscode to just do that. I saw that it had its own internal version of CMake (that could never find my shared libaries) and it had its own build system, but they usually failed to build (despite the code still building just fine on the command line). Every guide I found on vscode was about starting a new project from scratch and didn't touch on working with existing code.
I know that the issue has to be how I'm thinking about vscode. That I'm not understanding its philosophy on how to work with code. What that philosophy is, though, I can't seem to find a good understanding of.
As a concrete example, for the main project I work on, we usually configure via CMake and then build through Ninja. A simple `cmake` command followed by a `ninja -j4` was all I needed to get everything built. However, I could never get vscode to just do that. I saw that it had its own internal version of CMake (that could never find my shared libaries) and it had its own build system, but they usually failed to build (despite the code still building just fine on the command line). Every guide I found on vscode was about starting a new project from scratch and didn't touch on working with existing code.
I know that the issue has to be how I'm thinking about vscode. That I'm not understanding its philosophy on how to work with code. What that philosophy is, though, I can't seem to find a good understanding of.
I’ll let somebody more experienced to chime in on cmake and organizing c++ project builds, but vscode has decent built in shell where you could just run the commands you need without leaving the ide.
There’s way less philosophy to vscode than to emacs, i would suggest using it as dumb editor for a while and explore how various extensions make your life easier. If they don’t - maybe you just got your eMacs config right and should stick to it :)
There’s way less philosophy to vscode than to emacs, i would suggest using it as dumb editor for a while and explore how various extensions make your life easier. If they don’t - maybe you just got your eMacs config right and should stick to it :)
I had the same experience with window managers. I used to spend a lot of time customizing my perfect tiling wm setup. It was fun, but every time I saw a little issue or inefficiency I'd have an impulse to fix it. Now I just use default gnome for everything. I find I'm much more productive and happy when I just accept the defaults.
> I’ve also seen plenty of new editors rise and fall in the past 20 years - Komodo, TextMate, Sublime Text, Atom, etc. Emacs and vim are the only editors that stood the test of time, and I have a feeling they will be with us for decades to come. This means that an investment in them will be likely paying you dividends much longer than an investment in a newer editor or IDE.
The thing the author seems to forget is that you don't need to "invest" anything to learn VSCode. I also wouldn't call it an investment, as you can't really "forget" your Emacs skills and get part of your money back. It's more like buying a tool. VSCode was free, or almost free. Emacs seems to cost way more.
The thing the author seems to forget is that you don't need to "invest" anything to learn VSCode. I also wouldn't call it an investment, as you can't really "forget" your Emacs skills and get part of your money back. It's more like buying a tool. VSCode was free, or almost free. Emacs seems to cost way more.
You can do practically anything to text or other objects. If you can think of it, I'm pretty sure that Emacs can accomplish that for you. Any transform, file action, font changes, etc etc.
Example, this auto-saves a given file. In this case, whenever I archive an org-mode subtree, the archive file is auto-saved: