A couple things about the content of this post, that people aren't talking about. Mastering Emacs by Mickey Petersen is a solid book on Emacs and a good companion to the official manual. Mickey usually has an update to Mastering Emacs not long after a new version is released, which is great. I'm thankful for his many contributions to the Emacs community, and I really enjoyed reading his thoughts on the new features and additions to Emacs 28.
Secondly, the breadth of the changes in Emacs 28.1 is staggering, especially considering that Emacs 27.1 was released some 19 months ago. I think it's safe to say that despite all the hand-wringing about the antiquated email-centric way that Emacs is developed, an impressive amount of work is getting done. Emacs development is alive and well.
This collection page of Emacs packages: https://emacs.zeef.com contains only packages which are last updated at least 2 years ago, and it's already an impressive amount to me, which indicates that Emacs community is also very active, despite having - in IT terms- a very ancient editor.
Ancient, stable platforms enable long-termism, which encourages scratching your itches - whatever you write, it will likely keep working until after you're dead.
Wayland support didn't make it... Oh well it is in version 29.
I've been using the wayland version with libgccjit many months now from their git repo and it is extremely snappy and stable editor.
My strategy to keep all of this together is a nix derivation that compiles the latest master branch with all the plugins. Oh and my config is an org file with clear comments...
Btw. I recommend SystemCrafters video series Emacs from scratch. It teaches how to make a vanilla emacs to work like doom emacs does. It was helpful for me to understand the magic behind doom...
I have been testing Emacs 28 for a few weeks now, as it was reported to improve performance on LSP integration (which was sometimes sluggish for me with rust).
I have to say I wasn't disappointed. It's now comparatively blazingly fast. I hugely recommend to give it a try if you work in emacs with LSP.
Since my distro had not packaged it yet, I installed it from guix instead (package `emacs-next`). It worked like a charm.
I tried installing a lsp package at some point, but I couldn't figure out if it was actually doing anything over and above the language major modes. Not sure if it was actually doing anything at all actually.
Sorry, to clarify: I used the package `emacs-next` from guix to install emacs 28. You still need to install and configure emacs-lsp along with the LSP backend(s) you want to use.
Thank you for that. I haven't really checked out any of these distros (doom, prelude, etc.), but maybe I should.
One of the issues I have is that I work on multiple disconnected servers, and so I usually end up installing emacs on all of them. Using tramp is an option, but often times I just want a local editor because I find myself needing one in the context I'm working in. But all the servers run slightly different OS versions, etc.
Maybe a mangaged-for-me distribution that does most everything I want without me fiddling with it is the way to go.
I track my config in a git repo, and doom-emacs is rather helpful on what external tools must be installed for various configuration "layers" (like when working with such and such language). When using LSP, it can even proposes to install an appropriate language server in some cases.
I was an Emacs user back in my software writing days, but I thought I had left it behind when I became a lawyer. Over the past month or two however I’ve moved more and more of my workflow over to Emacs.
I started with using Org Mode and PDF tools for note taking and reviewing PDFs and task management: https://news.ycombinator.com/item?id=30492373. More recently I switched my email over to mu4e: https://www.emacswiki.org/emacs/mu4e. Unfortunately I can’t get it to interface properly with Office 365, which has heavily locked down POP/SMTP. So I used a couple of Power Automate flows to store incoming emails into a maildir format directory in OneDrive, which I then read from mu4e:
https://en.wikipedia.org/wiki/Maildir. I also use Power Automate flows to grab my calendar and store it to Org files, and watch for queued emails and send send them. Power Automate is just about the worst programming environment ever devised, but because UNIX systems like RFC 2822 (email) and maildir are so simple it didn’t take much fiddling at all!
Ironically, writing a bit of glue to get everything into Emacs offers better integration between email, calendar, todos, and notes, than just using Office 365’s own tools. After trying a ton of web/electron based tools for these purposes, going back to Emacs makes me think of this scene from Star Wars: https://m.youtube.com/watch?v=7hb8AYnRb-4
I’m using the Emacs 28.1 test release on Windows and the Emacs-Mac Port on Mac: https://bitbucket.org/mituharu/emacs-mac/src/master/. The latter has nice features like double buffering that make Emacs, while not modern feeling, quite presentable.
For such a huge change, the elisp native compilation works extremely nicely with every package I’ve thrown at it. Totally stable and ready for prime time.
Funny, just dealt with the whole O365 authentication just this week. With moving to 2 factor authentication you need to use OAuth 2 to do anything with it. I have my (work) O365 email forwarded, so I do have normal IMAP access. I use isync/mbsync [1] to receive email, goimapnotify [2] to get pushed new email, read/reply/etc with mu4e [3] and org-msg [4] and org-mode, and until recently just plain SMTP to send mail. This last part will break with 2 factor, but found oauth2ms [5] to set up the OAuth to work with O365 SMTP. The trick was to find the "tenet ID" from the Azure page of your organization and to use Thunderbird's credentials [6] (or another mail program, since I can't make new app registrations on Azure to have my own "application"). That should also allow you to use IMAP with OAuth 2 as well, but haven't done that since I still have the forwarding. (As usual, I think the Arch Wiki [7] covers most of this too.)
You may want to try using DavMail [1] for interfacing with Outlook. It is a reverse-proxy for email, so it talks to Outlook, and then mu4e can talk to DavMail directly.
Office 365 requires SMTP/POP/IMAP to use an "xoauth" authentication scheme which relies on getting an authentication token from a web browser. The process of getting that token involves sending a request that includes an application ID.
Are you using viper or evil-mode often (or some other thing which gives emacs vi bindings, I think there are a couple)? Because navigating text with emacs gives me the emacs pinky, I'm wondering how folks deal with that. Transposed cpslck with ctrl?
> Because navigating text with emacs gives me the emacs pinky,
I had RSI issues early in my career (not Emacs related), and learned some tricks that come handy with Emacs.
Your keyboard has two control keys. Use both of them. In particular, use the "opposite" one. If you want to press C-c, use the right Control key with your right hand. If you want to press C-l, use the left control key with your left hand. This way you're distributing the work with both hands and are not twisting your hands into weird shapes trying to get both buttons with one hand.
And also: Once you do this, no reason to insist on using your pinky to hit Control. I often use my thumb as well.
I curl my little finger and press Ctrl with the first knuckle. No hand movement required in my case.
(There’s a picture of my hand doing this on Xah’s site somewhere, to which he’s added a warning about potential long term effects; but I’ve been doing this for over ten years now, with no ill effects noted.)
Although it's the canonical solution, that would be a degradation for me. It's more ergonomic to use two hands to enter any modifier sequence. Mapping Capslock to Control doesn't provide extra benefits to my solution.
The other problem people have with the pinky is that they're twisting their wrist while typing, which is also against more ergonomic guidelines. The recommendation is to move the whole arm. Once you get used to that, there's no good reason to use the pinky to hit Ctrl (even when rebound to Caps lock). I would guess over half the times, I'm using some finger other than the pinky to hit Ctrl.
No it's not a degradation. It puts Ctrl in a sane place much easier to reach with your pinky. And if you really were going to use your thumb on the left control, then it's about the same distance to the Caps Lock key. I'm replying to the original asker with my advice, if you want to read more about what I think :)
The emacs keybindings evolved on keyboard with two control keys on both sides, later augmented to have replicated (starting from space bar) control meta super Hyper keys. A PC104 keyboard's main sin for emacs akt where control should be - but not requiring pinky for bucky bits
I set the key left to the spacebar (usually Alt or Cmd) to act as Ctrl in Emacs, so I can press it with my left thumb. This can be done in the Emacs config like this
Note that these variables are specific to the Mac Port (https://bitbucket.org/mituharu/emacs-mac/src/master/). They use an `ns` prefix instead of `mac` in a build based on the GNU mainline. And presumably something else entirely on another OS.
The trick is to hit ctrl with the part of your hand where your pinky attaches to it. Now all you do is rotate your wrist slightly, and you hit ctrl. Doesn't work very well on flat/low-profile keyboards, doable with thinkpads, not at all possible on macbooks.
This trick gave me some pretty bad pain in my left hand after a month or so. Remapping control to CAPS LOCK worked for me for years, but what really helped was when I switched to a keyboard that had six keys on each thumb cluster, which allowed me to map control and meta to the thumbs.
I mapped Control to a key under my thumb instead of Caps Lock. That's where it was originally when they chose the binding anyway. It's very comfortable now.
Yeah the caps lock switch is critical I think, since then you can press that key without curling or twisting the finger. Look at technique for musical instruments that require applying pressure with that finger, eg cello, they go through a lot of trouble sometimes to avoid that particular contortion bc of its lack of control and the long-term stress it puts on the hand.
If that doesn't work I know people who have used a usb foot pedal and it seems to work well for them.
Or, if vi bindings work for you, just use vi bindings. There's no nobility in the emacs bindings. I like them but if something else works better just use it.
How did you learn that keyboard exists? It is not on their keyboard page. Kinesis needs a better organized site.
I got the Freestyle2 a few weeks ago, enjoying it, still have some issues finding the navigation keys, home, end etc. I really like having my arms pointed straight rather than angled in like with a normal keyboard. Keys are a bit mushy, went from cherry blues.
my .02$: get an ergonomic keyboard (I use the MS Sculpt keyboard nowadays), and learn to type like a pianist (use both hands, don't be afraid to move them to minimise strain).
Sculpt is an amazing keyboard for programmers who need to press a lot of hotkeys. It has short spacebars and huge modifiers, very comfortable for your thumb. Not to mention it is split, negative tilted, tented and has a built-in wrist rest.
I remapped control to the bottom row, whichever key my thumb naturally rests on. Usually alt. Also moved \, [, ], enter, and backspace to avoid reaching for them with my right pinky. I think if your fingers start feeling even a little bit weird, you should keep remapping keys until they feel good all the time. Doesn't make sense to wait for it to get worse before taking action.
I gave up the fight to get Emacs to read Outlook emails. Instead, I figured out how to set up Org mode links to Outlook emails, as well as a VBA macro to create an Org mode TODO item based off of an email.
I also save org files on shared folders to sync among different machines. I use GnuPG via the epg package to encrypt all files before saving to the shared folders. GnuPG has relatively good cross platform support that I can move the encrypted files between different platforms.
The native compilation part is the highlight. Could someone who knows about these things explain the difficulty Debian has in getting emacs 28 in -unstable ? (currently on 27 according to https://packages.debian.org/unstable/emacs)
I'm not a Debian developer, but did email Rob Browning some years ago, asking if he would perhaps consider trying to make it a team effort. I don't think I ever got a reply. I appreciate the work he's done to maintain Emacs in Debian for decades (!), but it would be nice if someone could give him a hand. For instance, it looks like 27.2 wasn't packaged despite being released a year ago.
It amazes me that developers pick closed source Jetbrains and Microsoft spyware for the program they rely on to make a living when Emacs and Vim/Neovim get better by leaps and bounds every year. Emacs has packages that VSCode can only dream of having and with Emacs distributions or really just lsp-mode you can have a full fledged IDE with 0 fiddling. I recently did some digging into the editor usage of noteworthy programmers by going through interviews (usesthis.com was a great resource) and found that 99% of programmers whose names are recognizable are still using Vim/Emacs. Clearly these tools are not holding anyone back from doing great things.
Edit:
Just yesterday HN was overtly critical of Warp for being a proprietary, closed source, telemetry laden terminal, but they’ll suddenly lose their morals when it comes to text editing over perceived conveniences of an IDE vs. a “text editor” with LSP.
The point of Vim/Emacs isn’t just that they are good editors. It is also you voting with your installs and money for free and open source tools. You already reap the benefits of the Linux ecosystem, the least you can do is help out by picking a FOSS editor.
I'm going to assume this isn't trolling and if it is, you fooled me.
I've use Vim professionally, as well as VSCode and Jetbrains IDEs and dabbled in Emacs - the idea that one can replicate what IntelliJ does for Java for instance in any other IDE or text editor is to me, nonsensical. The amount of configuration it would require in vim/neovim/vscode to replicate the refactoring ability of IntelliJ alone would take you longer to setup than it would to code whatever project you're working on.
Saying that Vim or Emacs have "zero fiddling" compared to Jetbrains IDEs is a statement that is so vastly different to my experience (doing plenty of fiddling in both) that I would love to hear the backstory of how IDEs hurt you.
To be fair Java is an outlier here (there are few others I guess, C# comes to mind) and I would consider it a weakness of a language to require a complex IDE to do anything nontrivial comfortably.
I agree with you tho, I was looking for my options to develop in Java with Emacs and decided to not even try.
I've written C# professionally for many years, though it's far from my favorite language. I write 90% of it in Emacs, reserving Visual Studio for managing .csproj and .sln files and unit testing with the Visual Studio test framework. Once my workplace switches over to .NET Core, I hope to be able to get rid of those uses. Actually writing C# in Emacs has been fine for years, with Omnisharp, and now with LSP is about on par with VSCode, except you have the rest of Emacs available at a keystroke.
I've tried Java with LSP, and I think it's on par with Eclipse rather than JetBrains these days. The language server is fine, but I've never gotten it to understand, e.g., an Android Studio project.
Emacs distributions are built for people who want zero fiddling. Fiddling in of itself is not bad. Fiddling is how you learn, and this is a profession that requires constant learning and tinkering.
Most of features of a modern IDE are unnecessary or are actively harmful to developing good code. Thinking, taking your time, writing as little code as possible, and organizing a project so it can be easily understood and modified with nothing other than a text editor are positives that an IDE actively inhibits by trying to be helpful.
You're going back and forth. On your first post, you talk about all the things Emacs/Vim have that VSCode/Jetbrains can't possibly have. On this one, you talk about how less features is a good thing. Regardless of where you actually stand on that particular point, you're still comparing apples to oranges.
It is also worth noting that I have never had an issue jumping from vim to VSCode (or vice-versa) on the same project. Neither of the two need any extra metadata or configuration. They just work, and I'll choose whichever tool makes sense for whatever I'm doing at the moment. As, frankly, I think everyone should. This fixation over one specific type of tool over another is unnecessary: go with whatever you are most productive with.
What I mean is that the notion that Emacs/Vim require endless fiddling is unfounded. It caters to both the people that want something easy to use, and those that want endless customization. For those that want something easy to use, Emacs distributions are built and maintained by very experienced Emacs users who curate and put together an Emacs with everything you need. All you have to do is use it, which doesn't even require much learning thanks to `which-key` integration.
Productivity is a bad word. Productivity can mean low value busy work, or it can mean high value thinking. High value thinking leads to longer term success, because it is not easily bought or replaced. It requires an individual who has invested in a breadth and depth of knowledge by not choosing the path of least resistance. We should choose tools that optimize for this type of long term success. Choosing free and open source software is a choice for long term sustainability of our industry. Choosing a tool like Vim/Emacs is a long term choice towards individual success.
This is the philosophy I follow, and I have been very successful with it both financially and in terms of making an impact on the industry. It isn't novel either, I simply emulate the many, many expert programmers who universally choose to still use Emacs/Vim despite the existence of "smarter" IDEs.
I'm not saying that yours is necessarily the case, of course I don't know, but I feel like lots of people that hold opinions like yours greatly underestimate the amount of functionality that comes with something like a Jetbrains IDE.
It's not even about the editor itself, nor the graphical or UX stuff. It's the crazy level of introspection and of understanding your code those IDEs bring. My daily experience is just insanely better than with anything else I've tried.
In something pretty weakly typed like PHP you can happily rename methods and classes, refactor and extract code, move around namespaces, and the IDE keeps track of everything for you. You also get very smart autocomplete, snippets, integrated debugger with REPL, the whole thing.
I've played around with all sorts of vim and emacs distributions and settings and nothing ever came close.
Maybe it's just I don't have the time to set it up propert
ly. But if that's the case, it's still a point in my favor here.
I have used Jetbrains IDEA and Clion extensively to understand the other side. An IDEs heavy introspection isn’t necessary, and perhaps actively harmful towards writing and reading code. It’s rigid policy over tools like git is certainly actively harmful. If it takes an IDE to write your code, then it will likely take an IDE to read your code. They are tools that allow you to take shortcuts were you shouldn’t, and rob you of valuable knowledge. Programming is about thinking and continual learning and IDEs sell you the complete opposite. They help you build unsustainable projects where only a computer can understand the binary AND the source code.
The other point here is that the gap between IDE and text editor has only gotten smaller over the years and was closed considerably by LSPs. It may not be a perfect match in features, but small niceties are not an excuse for using closed source spyware for your text editor. They also do not make the difference between the success or failure of one’s work.
You can write shitty code in Emacs as well. I'm certainly guilty of that.
Steve Jobs once said that a computer is like a bicycle for your mind. It's an amplifier of sorts and an IDE fits into that metaphor. It will amplify the good and the bad. It's up to you, as a professional, to develop the skills necessary to use the tools in ways that make sense for whatever it is you are working on.
> If it takes an IDE to write your code, then it will likely take an IDE to read your code
I can agree with that. However, the real world is filled with random legacy projects, massive enterprise applications where a dozen developers came and went over a decade, quick-and-dirty MVPs and everything in between.
If you are paid to write well-crafted code that fits nicely within the limitations of your editor, that's great. But for the rest of us who have to deal with the realities of this industry, a helpful IDE makes it so much bearable.
As with every tool you should of course have the knowledge to do things properly without the tool, but not using a good tool is like saying we should use old style shovels instead of a modern excavator because the excavator shields us from understanding the back breaking process of the shovel. Now it is true that we programmers could need a good workout but doing things more infectively because of some immeasurable consideration of what is "harmful" is probably the reason we are still stuck in the 70s of tooling in many languages.
However what I do think is important is that every project should not actively discriminate against any of the alternative tools, in every project I manage I encourage every programmer to use the editor/IDE, shell or operating system they are most conformable with (but they need of course to manage their environment themselves and deliver the code in time).
I can write the same code significantly faster with an IDE because of all the autocompletion and code navigation. I don't use the version control features other than the occasional blame, preferring to stick to a command line for that.
The speed at which you write code is meaningless. Write speed is not the bottleneck for software development. What's far more important is that you take your time, pick names that a human can read and understand, write code that a human can read and understand, and write documentation. An IDE simply does not help with any of the things that lead to good software. If it did, the push to turn software engineering into cheap labor would have been successful, which it wasn't. Software engineering is still part art, part math, and 90% a mental activity and not a physical one.
> The speed at which you write code is meaningless.
That's not true. The working memory is finite, you can't keep things in it indefinitely. You can imagine your working memory as a queue[1] - you put things into it through one end, and you take things out of the other end to put them into code. If you can't write fast enough, the queue will overflow and loose a portion of the information you fetched from long-term memory to solve a problem. If that happens, you will have to restart the solving of the problem and re-fetch the required information. This takes time, but more importantly, it disrupts your focus and has a chance of getting you out of the zone.
There's a speed of writing that, depending on the size and volatility of your short-term and working memory, is optimal for you: you don't need to work to improve the speed above that threshold. But if your writing speed is significantly below that threshold, it will slow you down and decrease your productivity. You probably naturally achieved the speed optimal for you long ago, and forgot how you felt before you got to that point.
[1] For the sake of argument only. Obviously, in reality it's more of a graph than linear queue, but it still has limited capacity.
This is simply not my experience. For example, an IDE lets you rename a variable or type in a semantic fashion, making it easier for me to iterate on names and land on something that people understand.
There's a huge mental component to coding (I doubt it's 90% though). In any case, an IDE makes that easier by getting the boring physical stuff out of the way quicker.
And the speed at which you write code is quite meaningful. I can easily write 1000 lines of high-quality Rust code on a good day with just the LSP (rust-analyzer) for support. More recently, I started a project that hit some bugs in rust-analyzer -- working on it was a comparatively miserable experience.
Edit: Never mind, I see above that you're comparing a full-fledged IDE to just using an LSP. I consider LSP to be in the IDE category; I agree that LSP is just about where I want to be and that a full JetBrains-like IDE is overkill. What I don't like is not having any sort of code completion or rename support.
> For example, an IDE lets you rename a variable or type in a semantic fashion, making it easier for me to iterate on names and land on something that people understand.
The rename functionality is helpful, mainly for names that are referenced throughout the codebase. For locals it's not hard to replace this functionality - narrow the buffer to the scope you want (expand-region helps), then use iedit or multiple-cursors to perform the change. For public names referenced in multiple places you can use grep-find, then wgrep with iedit or multiple-cursors to do the rename. It's more work, and you risk renaming things you didn't intend to rename (ie. it's not semantic), but it works also with languages that have no IDEs or LSP implementation, so it's worth knowing.
It's not "old text editors". There are current tools for viewing source (pull requests/diffs a prime example) that are extremely good at what they do but are language agnostic. As is so often said, code is read more than it's written. If I can't understand the source without pulling it into my IDE, that adds a lot of friction to these reading tasks.
Those other tools you work with can become more advanced to in order to keep up with the improvements your IDE offers. You want to inline a diagram to your code? That image should show up both in your editor and in the diff.
Expecting your teammates to use an IDE does not get it the way of working in a team. In my experience as a team we have a default IDE for everyone to use and a configuration file for it so everyone's is using the same settings. Usually you could use a different IDE if you could configure it to act similar, but making sure everyone uses the same tools doesn't prevent you from working as a team.
For a long time I would have agreed, but LSP has democratized the space quite a bit. If an editor has a good LSP story, it’ll be able to do all of the renaming, extracting, finding references, etc.
Eventually, maybe.
But Java, Python, and Go are just so good in the IntelliJ suite. Switching between VSCode at home and IntelliJ at work make it readily apparent that there’s still a gap.
I'm frequently very impressed with Pycharm's autocomplete suggestions. It is very context sensitive, and frequently seems to guess what I'm trying to do next.
As someone who uses Emacs for (almost) all my editing needs and has done for about 17 years I just don’t understand how you can have these beliefs. LSP-mode is great and now with things like Spacemacs and Doom Emacs getting setup and getting things reasonably configured is a lot easier. But still!
VSCode is pretty cool and is easy to use right out of the box. It does some things with ease that would be very hard with Emacs. And JetBrains looks like it does some amazing stuff.
I still end up sticking with Emacs myself, but the idea that that it’s perfect and simple and for everyone and that there’s no sensible reasons to use the other options is just insane.
It amazes me there are Emacs users that don’t understand the importance of free software. You’re using the editor devised by the free software foundation, but you only want to talk about convenience. Convenience is not an excuse to switch to corporate made closed source spyware.
How many of us do you think work on "free" software? I write proprietary software and i use proprietary software to do it because it pays my mortgage. I drank the fsf Kool aid as a kid, then i grew up and had to put a roof over my head and my children's. It's great that some people get to make a living producing free as in speech software, but that's kind of like getting into the NBA. The rest of us have to contend with reality
You're presenting a false dichotomy: most software is neither proprietary or FOSS; it's in-house, custom-developed functionality, that's never released/available outside of the business that created it.
Its only "user" is the business that made it; they have full access to the source (unless they deleted it; whoops!), are not bound by its copyright (since they're the owners), etc. The FSF has no problem with that.
Although my first job was working on FOSS, all the ones since have been working on such bespoke, in-house software. To be honest, I don't think I've ever seen a job ad for proprietary software (as in, closed-source software that runs on end-user machines).
A few subtleties:
- Javascript is probably a glaring exception. Opinions differ on whether it should count as shipping proprietary software (the FSF think it is, many HNers probably consider it less clear-cut). For what it's worth, the little JS I've written professionally has always been of a progressive, site-still-works-without-it form.
- Some of that never-released software may be accessible to others, e.g. Google's search software can be accessed via google.com. The AGPL has an interesting take on that particular niche.
- Sometimes the human end-users of this software have very limited access/control over it, e.g. if Walmart maintains its own checkout software, those operating the checkouts probably can't access the source, etc. However, that's nothing to do with copyright, FOSS, etc. it's just a business decision, presumably covered by employment contracts (e.g. "in the course of your work you may be given access to computer systems; these are confidential, and you must not hack/compromise/etc.").
I just can't think why you might have trouble convincing people to try it :p
But you yourself bought up convenience in your original comment. If your argument is a purely moral one then no need to specify how little fiddling is required to get LSP working. But I do think if your only argument is yelling at people about it being immoral to use VSCode you ain't going to get far. Why not talk about the cool things Emacs has while acknowledging the things it still has that could be improved?
VSCode is open source by the way, MIT not GPL but you can go compile it yourself (or use VSCodium).
The extensions marketplace requires you to use the closed source version. Quite a few of VS Code's best extensions are also completely closed source. VS Code is already on the same path that Google took with "Open Source" Android.
I've been using vi since 1985, built a suite of development tools based on a custom fork of Elvis in the 90's and have been using vim professionally since the mid 90's. I've dabbled with emacs on and off for most of the 80's and 90's, including supporting a subset of the Elvis tools on emacs. I still fire up emacs now and then to see what's up.
The idea that either emacs or vim are a "0 fiddling" drop in replacement for Goland or Pycharm is ludicrous. I probably could get vim up to the point where I was as productive as I am with Goland/PyCharm but it would definitely NOT be a "0 fiddling" process.
I can't believe debugging and learning a new code base would be ANYWHERE as easy with vim as with Goland/PyCharm.
Also, both Goland and PyCharm have pretty good vim plugins so my day to day editing IS vim. Sometimes I hit stuff that I can do faster in actual vim and I switch over.
Honest question from someone who never used any product from JetBrains: what those IDEs gives you in order to learn/debug a new codebase in such easy way?
Not OP but having used both PyCharm and Emacs, I really like PyCharm's visual debugging - when at a breakpoint you can see all variables in memory, their types, dictionaries and objects are nested. A lot easier than vanilla pdb.
"you can have a full fledged IDE with 0 fiddling" - that is 100% not a thing that has ever happened to me whenever I go and look at emacs/vim!
Modal editing is not really something that is needed anymore, and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
I agree that neither vim nor emacs are "0 fiddling" [0]. However,
> Modal editing is not really something that is needed anymore
Honestly, I'm not sure it was ever "needed", but that's not really the point IMO.
It's hard for me to think about editing text in any way other than how Vim handles it. Part of that is admittedly just familiarity, but I think there's also something to the idea of treating strings as more than just arrays of characters. Once you start thinking about your text and code as nouns of various sizes and granularity [0], losing those feels cumbersome.
In order to achieve the latter, you either need modality or a huge number of control hotkeys. Vim takes the former approach while Emacs (and IDEs) takes the latter.
So yes, you can achieve the "crowning feature" of Vim (IMO) without modality, but I don't see modality itself as being a pro or a con as much as a design choice. If you don't prefer it, more power to you.
> and a lot of people don't have time to learn a new language just to move about in their IDE - just click the mouse button ...
This also works the other way. I don't want to have to learn where all the buttons are in $IDE just to move my text about. Thankfully, many IDEs include a Vim mode or plugin for it, but those are never quite the same.
Every tool has some level of learning curve. If you want it to be more flexible, powerful, and to get the most out of it, that learning curve is gonna be steeper. That goes for both IDEs with their buttons and Vim with its modal commands.
For something that you might use for hours on end every single day for professional work, putting in some time to learn it pays dividends. For both Vim and IDEs.
[0]: In vim parlance, this is effectively what "movements" operate on. They sort of define these objects via implication.
As long as your input device is optimized for inserting text (and your keyboard certainly is) modal editing is surely something desirable for programming.
Even the TypeScript LSP is extremely featureful in Emacs. I thought about using VS Code for that stuff, but decided to see how the experience was in Emacs first, and now I'm no longer considering VS Code.
How do I go about learning emacs when my job requires me to work in a M$ environment, and I have limited free time? I tried learning and felt overwhelmed, and I would like to make strides to make vim or emacs my primary editors for home use, but Visual Studio / Jetbrains just make development incredibly easier to not let the tools prevent me from just writing the code.
With 0 fiddling? not my experience at all. has something changed?
I use Emacs for lots of things, but I've long since changed to Pycharm for Python programming. That's been close to 0 fiddling for real. Its been pretty good for JS programming too.
I remember when one of my first professional mentors jokingly said that all those years spent in university was to write your own .emacs file so you had one when your career started. He was a bit shocked that mine was almost empty.
Does Emacs ship with LSP support out of the box? They've had a habit in the past of ignoring similar features that were arbitrarily perceived as "proprietary" or not open enough.
Don't think out of the box, but https://github.com/emacs-lsp/lsp-mode works rather well with emacs 28 from my experience. Emacs "distros" such as Spacemacs and Doomemacs both make using it a nearly "out of the box" experience.
(not supporting the editor/ide war troll, just trying to contribute some useful info here)
I use neovim within vscode. All the power of vim but with intellisense and debugging working with minimal configuration.
As for telemetry, all my work lives in Azure so I assume Microsoft are already collecting what they want about our codebase (which is publicly visible) already.
I used Emacs for 20 years, contributed to popular open source emacs projects, and am the maintainer of a couple of emacs packages with small numbers of users.
It's wonderful and extremely powerful having everything in lisp; don't bother with emacs if you're not interested in writing lisp.
One silly thing that I could never get to grips with is the way the minibuffer always seems to get stuck asking me a question, but the cursor isn't in the minibuffer. Or it's in some sort of recursive minibuffer mode. So many times I've just mashed C-g repeatedly in irritation!
I stopped using Emacs last year in order to access the high quality LSP experiences that are available for Typescript and Rust and other languages in VSCode. I'm firly happy with the configurability of VSCode and generally fairly happy with the move. VSCode needs Emacs' window-configuration registers though.
> don't bother with emacs if you're not interested in writing lisp.
Strong disagree. I used Emacs as a power user heavily for about a decade with virtually no elisp knowledge (beyond simple conditionals and setting variables - I couldn't write a loop for example).
Once I learned elisp ... it hasn't been a game changer. Sure, occasionally I tweak things the way I like it with custom elisp code, but there are enough config options and packages out there to do what I need without my having to write elisp code.
FWIW lsp-mode does a great job of integrating with language servers in emacs. I and two of my coworkers use emacs with rust-analyzer, and it’s generally been a very positive experience.
> One silly thing that I could never get to grips with is the way the minibuffer always seems to get stuck asking me a question, but the cursor isn't in the minibuffer. Or it's in some sort of recursive minibuffer mode. So many times I've just mashed C-g repeatedly in irritation!
This happens to me all the time too! Anyone have a fix?
Thanks, that's perfect. I still have a running emacs instance for magit, and editing elisp at least, so I can still make use of your suggestion. (I made it so that C-g with prefix arg calls top-level; not sure if you'll think that UI makes sense).
The post yesterday about Pharo 10, and the Lisp Curse repost has me thinking about text editors again. I think that some fusion of the introspection abilities of Smalltalk with the good parts of Emacs might allow us to create the text editor of the future™. One that take everything good about Lisps and everything good about programming in Smalltalk. I'd need to actually explore how Smalltalk does its IDE environment to be able to comment more, but I was initially very impressed with the programmability of it during the video I watched about it.
I aspired to learn Emacs but gave up a number of times.
It's in that category of things that I believe would be Good For Me but that have such high activation energy that it never becomes a high enough priority. It's like the documentary I keep skipping over in my streaming queue, the free weights gathering dust in the basement, or the guitar I finally gave away after having only learned a few chords.
There's got to be a word to describe the realization that something is probably never going to be high enough priority to me to be worth the investment.
The best reason to use Emacs is that it’s fun. Would you learn the guitar because it’s “good for you” to learn it or because you enjoy playing music? I think the only sustainable motivation is the latter. If learning Emacs is simply a chore with an abstract promise of “productivity” as a reward you’re not missing out on anything.
By "Good For Me" I don't just mean productivity-wise, I mean a positive and rewarding experience. And frankly I do not know whether I would enjoy using Emacs. (I similarly don't know whether I would enjoy playing music.)
But I know that learning Emacs is a chore. I did not enjoy having to relearn common interaction concepts like windows, frames, yank, kill. I did not enjoy retraining muscle-memory (or modifying bindings) because editing and navigation shortcuts don't match the standards that have been codified in every other desktop text area. I did not enjoy the endless search for the right distribution/mode/extension to solve a particular problem. I did not enjoy that none of these are generalizable skills that transfer beyond the esoteric priesthood of Emacs use.
I liked the core concepts in principle and I enjoyed the new perspective it provided, like peeking into an alternate universe with a parallel evolutionary path.
Eventually life intervened and I had to retreat back to editors that take minutes to learn rather than hours or days. I suspect I'll give it another go someday when I can afford to devote the better part of a weekend to it, perhaps when the kids are older.
> Adding right-click context menus is a natural extension to Emacs’s already-extensive support for the mouse (even if a lot of people don’t use it.)
If emacs could support plan9 acme-style chords with custom commands then I'd probably use the mouse a lot more in it - acme convinced me that mousing around can be just as fast as being on the keyboard if the UX is well designed.
Acme was my daily driver for a couple of years (mainly writing). Went back to Emacs because of org-mode; it's just _that_ powerful.
I mostly miss chording and Acmes way of finding and opening files. It was intuitive and nothing felt hidden; like the commands and dired feels in emacs.
But I guess Acmes functionality could be added to emacs by elisp, no?
Combining the approach from the first and the wand package could potentially surpass the acme experience by making it easier to customize and extend.
My friend joked about how I'm religious about the keyboard, but really it's about the right tool for the job, and if I had an acme-like mouse experience with emacs I'd def be mousing around more often. Funny that compared to normal people I'm a keyboard fanatic but compared to majority of emacs users I'm on the mouse way more often :)
I only had limited experience with acme in p9 during some experiments with distributed audio, but once it clicked with me it made a huge impact on me - similar to when I first grokked emacs.
Can the insertion point be moved by clicking in a particular location?
As of recent versions of macOS, emacs isn't included by default. Last I tried, in terminal-mode emacs, the answer to the above questions seems to be no - with no reasonable explanation why this is the case.
I'm more than willing to do everything else from the keyboard, but these are basic oversights that have yet to be corrected.
EDIT: Is mouse-tracking actually the feature that enables this behavior?
On Debian with the distro package, I never even thought about mouse integration. (On the Xorg interface. So much basic stuff - not emacs stuff, but really basic stuff - has been moving into DEs that I don't think the bare console is usable anymore.)
The insertion point is moved by clicking and by using the scroll wheel (now that I've thought about it, maybe I should change that second one), clicking and dragging and double click change the selection.
I normally don't use the mouse, but for moving text between windows it's nice.
M-x xterm-mouse-mode gives an experience in the console that's pretty darn faithful to the full GUI when it comes to mouse interaction. Clicking, selection, and scroll wheel all work pretty much as expected. Even menus and pop-menus work; the new TTY menu in 28.1 is pretty slick!
Confession: I'm a BBEdit user most of the time, so take my questions here with a grain of salt. Although I don't need it often, I still felt the impulse to take a side w.r.t emacs and vi.
I'll see if I can dig out my old init.el from backups and try to get it up and running with 28.1. I actually hadn't heard about the scroll wheel stuff before, so that might be one way to solve this for me.
Is there a setting in Customize to control whether to use init.el or .emacs for configuration? Trying to set symlinks from $HOME to another directory and it's fighting me...
I do know that ~/.emacs takes precedence over ~/.emacs.d/init.el. I've taken advantage of that in the past to keep all the public configuration that I share between machines in ~/.emacs.d/init.el, and then on my work machine I had a ~/.emacs that wraps a (load "~/.emacs.d/init") with some company-specific configuration.
The stink of it is, I had this working: mouse-mode, correct symlinks, all of it...for like 10 mins. before I realized, 'oh crud, I forgot to disable something' and in my haste of mucking w/ settings, tossed the good init I had trying to ID what was missing.
Self: You're dumb
I think I can recreate it, but I've got other stuff to do too, so this may get paused for a while - Monterey beckons as I have yet to take that plunge, although I really should soon.
Hard disagree. Sometimes the terminal is the most efficient way to run Emacs on a machine in a remote data center that has a mountain of CPUs, GPUs, memory, and disk. TRAMP can be slow and inefficient. A LSP server process on a huge monorepo can chew up a large amount of memory and CPU on startup. Running all of this stuff locally on the actual hardware your code needs to run on is great.
TRAMP is great, but to me it never feels the same as running locally. OTOH ssh -X (i.e. X forwarding) works for me for exactly this specific case (large and powerful remote dev box).
Incidentally my current setup is that I'm WFH and RDP'ing into my windows desktop, where I run VNC to our xvnc server where I ssh -X to the dev box where I run GUI emacs. It is surprisingly usable (I can also skip the RDP and run VNC directly if needed).
Given all the emacs ninjas here - what’s the best way to do JSX/TSX formatting while playing nice with js2-mode, tide and web-mode? I’ve been stuck for months on finding a good config and almost wanted to move to VS Code to try it out. Then, while using it I just couldn’t do without emacs buffers and panels flexibility — so moved back :))
I gave up on getting these modes to consistently format. It seems really fragile and never quite right. So now I just have prettierjs set up and I don’t have to think about it.
I’m interested in emacs / org-mode / org-roam. My goal is to have a local notes solution (replacing Obsidian, Apple Notes), and have the notes automatically published on the web as a crosslinked personal knowledge base. I have somewhat achieved this with Obsidian/markdown files + git + Hugo + Render. I write stuff. Check it into git. Push, and it deploys as a website. Feel pretty good about cobbling that together. But Obsidian/markdown is tough to replicate the cross-link nature & ease or use of a wiki, and it still doesn’t help out with Task, calendar, etc.
I’ve taken a couple swings at setting up Emacs… oof, but as a newbie to the ecosystem, but frankly its just been tough to plow through. Each guide/tutorial seems to have a whole different set of packages, settings, etc; then we get into Doom emacs, etc. I’ve got keyboard shortcuts printed out - but I still end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them.
Truly, it reminds me of when I jumped head first in the Java ecosystem, trying to figure out (1) java, (2) intelliJ, (3) Spring boot. Too many simultaneous brain battles…
What I’m hoping to find is a “Zero to Functioning personal information system (notes, todo, contacts, calendar, kb)” guide. I suppose, written for a willing & motivated newb?
From reddit, online tutorials, walkthru videos - it SEEMS the pieces are out there. But I’m hoping to find the guy who figured this all out a year ago, documented a functional-but-opinionated stack / workflow, and I could follow that for awhile (as training wheels).
Can anyone suggest something like this? I’d be even be willing to pair up with someone and document/publish this, if it doesn’t exist.
I mentioned it on another Emacs HN thread: I’m convinced of the power of this stack, but I’m hoping someone does the “Unix —> NeXT -> MacOS”, and puts together the Easy Button of this.
For example, my brother is writing a book - he’s not super technical but can get around. I can tell that he would benefit from this system - but I can’t fairly recommend it, because hell - I haven’t been able to coherently get it to work, and doubting he would want to be modifying init files and all that.
Hoping this plea for Emacs help reaches a previously frustrated newbie who figured it out, who can help me out (and others). Thanks!
Personally, I wouldn't recommend setting up org-roam at first. It's excellent, but it's just going to be too daunting for a beginner when combined with all the other things. I'd start by just learning emacs and org-mode. Core org-mode has enough functionality built-in to start building knowledgebases, and the org-mode manual is excellent. You can add-in org-roam later. (And you might find that org-roam is overkill and something like howm mode to get backlinks is enough.) The beauty of emacs is that you can move your notes from one system to another easily.
>but I still end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them.
<meta>-x close-buffer will do the job.
Actually, using <meta>-x allows you to execute any emacs function, whether it has a key binding or not.
Even better, emacs will suggest completions (and once you are down to a single potential completion, tab completion works nicely) as you type the function name.
And if you don't know the name of the function you want/need, <meta>-x apropos will allow you to search for what you want -- with regexp support.
All that said, depending on your use case, it mightn't even be necessary to modify your init file at all.
I'm not a previously frustrated newbie (I started with Lugaru's epsilon[0] back in the early 1980s, moved to straight-up emacs in the late 1980s and never looked back), but I'd be happy to help.
That said, using emacs' built in help/info/apropos tools, not to mention just using <meta>-x <start typing function names> would almost certainly be a better way to figure out how things work than asking me (but don't let that stop you from doing so). And definitely better than googling/ddging/whatevering what you're looking for. '<meta>-x info' and/or <meta>-x help are good places to start.
It works quite well, and might be exactly what you want as far as publishing goes.
> end up in weird jams where Emacs has opened up 3+ panes (buffers), and I can’t figure how to even close/quit them
Typically 'q' will close Doom's popup windows (+popup/quit-window), otherwise you should be able use plain ol' Emacs 'C-x k' or Doom's '<leader> b k' (also 'b d') to kill a buffer.
If you actually want to keep the buffers, and you just want the windows out of the way, you can use winner-undo / winner-redo to cycle through past window configurations.
> bottom-up guide for personal information systems
AFAIK, this does not exist. But there is, I'm sure you've seen, a variety of independent users continually working out interesting new ways to process and link information using Emacs. For example, outside of bloggers in the Roam/Zettelkasten camp, you can always glean insights from John Kitchen's work [0][1], although it leans more towards research/academic use than PIM/PKM.
> my brother is writing a book - he’s not super technical but can get around
If it's technical/academic writing, you can honestly get astonishingly far just using org-mode's LaTeX export.
Craft.do is a good solution to your problem if you don’t mind closed source.
I personally have started using logseq.com though, it is a good fully open source file system based approach. It supports markdown and org mode, and I store the files in an iCloud Drive folder so I can access stuff on my phone (though it’s not quite as slick as craft, and setting up an auto deployed website would have to be done manually whereas craft does it for you)
Org roam is pretty cool but with less features than actual roam. I had to force myself to use it but after that it's fine. The big disadvantage of all things Org is that unless you're doing very simple and using only defaults, there are no reasonable mobile workflows. You pretty much need a PC, or termux+keyboard for it to make any sense.
e.g. I compiled Emacs to run on Redhat Linux. Since I wanted to compile it with --with-native-compilation flag, I had to install Redhat's developer tools to get libgccjit. These tools are installed in /opt/rh/devtoolset-10/root. An enable script is provided which modifies the LD_LIBRARY_PATH and PKG_CONFIG_PATH.
After compilation, I was able to launch Emacs from my bash terminal, but only after running the enable script (i.e. sets LD_LIBRARY_PATH to the correct directory). In a fresh terminal or after logging out and logging back in, launching Emacs gives the error:
emacs: error while loading shared libraries: libgccjit.so.0: cannot open shared object file: No such file or directory
Moreover, launching from application menu fails. I was able to get it to launch by modifying the binaries rpath, but then emacs gave lots of libgccjit.so errors afterword, when trying to lazy compile different internal applications: error invoking gcc driver.
I also tried compiling on Mac, but found myself experiencing a variety of issues that I didn't want to spend time thinking about. So I went with someone else's pre-built binaries.
I use macports, and refuse to use brew (for a variety of philosophical reasons) so that option wasn't available to me. I often use the binary from https://emacsformacos.com/ but afaik it hadn't supported native compilation as yet. So I found some prebuilt binaries on github.
I almost wish I never tried Emacs. Ignorance is bliss, and Emacs ruined all other text editors for me.
There are absolutely areas that others do better, but the self-documenting “living program” nature is too much to give up; everything you ever need to know or do is a few keystrokes away.
I’ve been using emacs on and off for about 20 years and I don’t really get the fanaticism. Org mode and magit and all these things are cool. I like that you can hack it. But — to me it never stops feeling like an ongoing project when you try to live your entire life in it.
I like it obviously otherwise I wouldn’t still be using it, but it will never exactly feel elegant to me. More like a good text editor and a hundred other tools all duct taped together.
> to me it never stops feeling like an ongoing project when you try to live your entire life in it.
and that's the fascinating thing about it. What the OP called a 'living program' Smalltalk people called 'human-computer symbiosis'. Software as a fully transparent, introspective, organic thing you can directly interact with and change even as it runs.
There's actually very few software like it, and if anything philosophically more and more software tends towards the static unix "one tool one job" mantra.
I like to tinker and hack on things, so I enjoy maintaining my Emacs config to an extent.
However, I draw the line at "text editor" with Emacs. I have no desire to read my email, paint pictures, or compose music inside Emacs—there are better tools for that.
For email I disagree. notmuch and mu4e are very good and being able to apply your normal text editing tools in a text oriented context like email is very useful. If there are better tools out there I haven't found them yet.
I like having my email in Emacs, so i can reference it from org. I also like to write mails in Emacs. Triaging mails in notmuch-emacs is also quick and painless. Reading HTML mails, though — not so much.
I avoided email in emacs for a decade, using exactly this reasoning.
A few years ago I got fed up with not being able to configure Mail.app to notify me of responses to "watched" threads but nothing else and thought "...I bet the CLI tools would make this achievable."
So, I moved to mbsync for fetching email, not much for indexing the local email directory, and notmuch-mode / Emacs for reading and writing email.
It's head and shoulders above any other email setup I've ever used.
I don't have the fanaticism either but I always fall back to emacs because it can quite easily assimilate the advances made in other editors without requiring too major changes to emacs itself.
In fact, my config these days is basically vanilla emacs with some of the UI stripped away, the modus theme, and a few language-specific modes for syntax highlighting. I don't use evil or hydra or any such thing any more. The only thing I have a sticking point with is exec-path-from-shell messing with $PATH in my env because of how it works.
I guess the reason it works well for me is because I try not to write code, so I don't need a massive toolkit that helps me write code as efficiently as possible. No-code is bug-free code, maximise the work not done, etc.
I used Emacs almost exclusively for half a decade and got pretty good at it. But I feel like VS Code is the natural evolution of all the great ideas of Emacs. So I use VS Code almost exclusively now.
For me it doesnt even come close to it. Maybe if you wtite your own plugins but even then there are many limitations. The one-window problem for example.
In emacs I can overwrite ANY function wherever it is from my config and change for example how shr (an html renderer) handles/styles headings. Its crazy!
One MAJOR thing that emacs does better is making things work together. I have orderless installed for matching strings in ANY completion. It works everywhere while in VSCode you cant even get close to that.
VSCode is great if you like the default and dont want to „build your text editor“ cause thats what emacs basically is. Its a toolbox with which you can build the editor to fit your exact needs with almost no limitations
The cohesion and interoperability of Emacs packages is hard to find elsewhere. When I tried Neovim recently, it was blatantly obvious and I was quickly turned off by how each plugin creates psuedo-TUI elements and prompts for input slightly differently.
Sure you can. Open up your VS Code extension in a VS Code window and live-debug it. I'd bet the process is probably very similar when editing VS Code yourself, but the point of the extension system is that you usually shouldn't have to.
That's cool. The one thing I missed in VS Code when I last used it a few years ago was a link to the implementation in the documentation of each function. Maybe I will give it a try again someday. But honestly giving up Magit, org-mode, slime, and elpy will be hard.
One pretty decent Magit alternative I found was lazygit. For a long time after quitting Magit/Emacs I just used git's CLI, but lazygit is pretty great.
Yeah the LSP ecosystem is so much nicer than the machinations hacked into text editors over the last 20 years. When you get down to it a modern editor is just a process manager for language servers, a global event bus/RPC layer across them all, and a UI layer. Instead of reinventing bespoke versions of those things, just solidify it using standard protocols like JSON RPC, HTML for UI, etc.
I forced myself to use emacs for about 6 months coming from IDEs and vi(m) to get past the "this is unfamiliar" stage.
At the end of the day, it was a very nice text editor with a development environment embedded in it and the ability to tweak things to my work flows was certainly interesting. However, I never enjoyed the seemingly unintuitive default key bindings and I often found myself disappearing into rabbit holes and tweaking stuff just to make everything work more smoothly. Ultimately, I decided that was time I should have been spending on more productive pursuits.
To this day though, I don't regret giving emacs a spin and I still swap caps lock and ctrl on all my systems. Remapping that key binding is helpful for so many things outside of emacs.
Agree, but for me, there also are simply some features no other editors have, especially when it comes to navigation.
Some examples are all the ivy autocompletion, command autocompletion, dired, adjust-parens, windmove, smart parents, expand and contract region, agressive-indent, avy, swiper, hydra, and so on.
And it seems whatever I think about exists. Every time I go: How do I? There's a solution, and if not, I can just quickly add a function for it myself.
That's what keeps me in Emacs. Some other editors are more polished, and have better UX, might be more responsive, but there's always something they don't have and I miss from Emacs, or something that I don't like how they do it and I can't customize to my liking.
I've discovered aggressive-indent recently and I got immediately addicted. Now I wish it worked reliably with lsp-format-region and clangd (lack of reliability doesn't stop me from using it, even if explicitly unsupported).
How did you approach Emacs to make it such a valuable tool? I have tried to get started with Emacs a few times but the initial resistance has been too large
Ironically, part of the problem for the newbie is the enthusiasm of the heavy users, which can make getting started feel overwhelming.
Just bare emacs is a great editor. You only need a few commands, and then can incrementally learn more as you go. Often, when you learn some new command or new package you'll wonder "how did I manage to use emacs for all this time without knowing this?" But the answer is: you were able to get a lot done with what you already knew.
I've been using Emacs for over 40 years and have a very short init file with only a small amount of customization. And I still learn a new command or package every couple of weeks.
When I first started, I found the keybindings odd, but now I love them since the core set of shortcuts—C-a, C-e, C-f, etc.—work "everywhere" from the terminal, to GNU readline-based programs, to even native macOS text boxes. If you don't like the default keybindings, you can change them or use the Evil package [0] for Vim bindings.
If you want to get up and running quickly, I'd check out Doom Emacs [1] which is easier to configure and takes care of a lot of configuration for you. I personally use a reasonably-minimal config I wrote myself [2]. If you like to tinker, I'd recommend writing your own config, as it will also teach you a lot about Emacs.
If you have any questions feel free to reach out—contact info in my profile.
Do you use it as an IDE? That's the part I had trouble with (react/typescript and python). I could get it almost there, but essentially what I would need is a VS Code mode. A side panel with the collapsible directories, double click into them, global search, linting, syntax, etc.
As a heavy Emacs user for over a decade: I still use IDEs instead of Emacs for programming. Emacs has plenty of uses outside of SW development. Only recently did I manage to set up my Emacs to have IDE-like capabilities for my Python work. But if I switched to a C++ job, I'll use an IDE. And maybe, over the course of a year or two, I'll bother setting up LSP for Emacs.
It's totally fine to use IDEs if they make your life easier. In my last C++ job, I would edit code with Emacs, but keep Visual Studio open for the IDE conveniences.
You may have investigated this already (or discovered it setting Emacs up for python), but lsp-mode just about works out of the box (for most languages). Extremely minimal setup required. Maybe a few configs for lsp-ui to suit your own taste.
I use it at my current job in which I work in a large C++ codebase. I formerly used CLion.
Whether Emacs is an IDE or not depends how you define IDE. I use Eglot [0] for LSP integration; this gives me IDE-like features like "jump-to-definition", syntax error highlights, warnings, etc. and integrates with company-mode [1] for code completion. This handles most of my needs for writing code.
As for other things like a file tree, I've found that the built in `project-find-file` command combined with `vertico` [2] and `orderless` [3] makes finding files and navigating around projects easier; that pair behaves similarly to CMD+P in Sublime Text or VS Code. There are file tree packages out there, but I've found that I don't really need a file tree in practice and that I prefer navigating around projects with fuzzy file search and grep.
I use emacs as an IDE with a large C++ (and python) codebase. I use emacs-lsp + clangd for completion/jump to definition/syntax error highlighting etc, but for whole tree searches, I find clangd unreliable, so sometimes I fall back to emacs-ag (I assume that emacs-ripgrep would be even better) for brute force searches.
I never found a side panel of any use (many are available), but I use projectile for quick jump to file all the time.
My python setup is less refined than C++ (I haven't bothered yet to enable LSP), but I use elpy which is works fine for lisp-style programming with a persistent REPL.
This interesting to me. The sidebar in IDEs is one of the features I dislike most about them. I vastly prefer the C-x C-f helm menu with it's fuzzy search to IDE approach of aimlessly clicking around a directory tree like a philistine. For the rest (linting, syntax, autocomplete), lsp and a language mode make me pretty happy.
I (try to) use spacemacs. I heard they're similar. Is Doom Emacs better for an IDE type experience compared to spacemacs? I'm mostly on Ubuntu if that matters
Thanks for sharing your experience! I guess my problem was to remember all the shortcuts and keybindings and how to do things, and having to look them up all the time was tiresome - but I guess the steep learning curve has some fruits in the end
At my new job a colleague mentioned he used emacs and I basically took it as inspiration and started trying emacs myself, I'm very accustomed to vim after 4-5 years of heavy usage so I started with the evil package (evil-mode) and went from there.
It boils down to using the already known vim keys for basic actions like splitting the window, save a file etc. and creating keybinds for anything else I needed. So I customized any keybind to my liking, I didn't really adopt the emacs binds since I find many of them to be quite unintuitive.
It took me like 2-3 weeks of constant configuration to get to a productive config that covers all my needs (from autocompletion, to colorscheme) and I still edit my config every 1-2 days since I discover new small "itches" and then fix those.
For example: I always want my compilation output to be on one monitor -> always open the compilation buffer ("output") in its own window. Perfect!
To me emacs is like a platform that I can use to build my "own" perfect text editor that does exactly what I want it to do without really any compromises. This is where emacs shines, the endless possibilities and nothing that holds you back and says "no the editor is not meant to do X".
I speak with a heavy VIM accent, so Emacs never clicked for me until I tried SpaceMacs. I mostly use Emacs only for org-mode, though.
The truth is, I think that I've outgrown SpaceMacs and ready to try vanilla Emacs with Evil sometime. But SpaceMacs was definitely the gateway to getting me into org-mode, and that really is revolution in being able to organize my life.
It's a bit of an extreme instance but when I toyed with good old turbo pascal 7.0 ide (dos era) I was shocked by the quality of it (turbo pascal), brilliant on every aspect, mind blowing for the size and era. Yet the minute I tried to edit code I felt straightjacketed by the editor, you can only do what's built in. It was a stupid need for region aware edition.. nothing fancy but I was still stuck.
Ability to extend your system with a quick `eval` and adjust keybindings when needed is a very hard drug to me. And I'm not in the fanatic period anymore but still.
For me things started to get interesting once I set up CUA mode to have the same key shortcuts as in the usual Windows world (ctrl-C for copy, ctrl-V for paste and so on). Once I got that I was able to work on text file, programs etc. Then I slowly added packages (took months) as I was needing/discovering them. And now, what I like is that I can use the same configuration on Linxu and windows (I switch often between my work PC in my home PC). Org mode is really usefull although I just get the bare minimum. LSP makes a difference too. And the community is great: so much things happen all the time. The openness really makes a big difference. So in the end, I love it :-)
I think the only way is to bite the bullet and accept the somewhat steep learning curve. Unlike the other suggestions I think it's best to start off with a vanilla Emacs setup (rather than one of the fancy distributions), because it's better to start with a very simple setup and then build on that.
The initial Emacs setup is very basic and quite ugly, but good for learning. Follow the built-in tutorial.
After learning the basics, create an init.el file, learn to use the use-package package, and start off trying out interesting packages to make your life better. I would suggest finding a good theme and giving helm a go to begin with.
Indeed, I started with VIM when I was in uni and things were kinda slow. After a few weeks/months I was very happy with it and it truly felt as a productivty booster. (I switched between VSCode with vim keybindings and Neovim). Then, for last year's AoC I wanted to explore Lisp, so after weeks of trying out sbcl and running it thru the terminal I finally tried Doom Emacs. And for me too, its been a journey, its a "text editor" that truly exemplifies what a good 40yo+ piece of software should be.
OT for this particular release, but I'd like to point out that one of the best features of emacs and its ecosystem is that plugins, libraries and software are almost always self-documenting.
You want to read the documentation or delve into the implementation of a feature of your programs it is literally right there in your editor instead of having to jump to some, potentially outdated, website documentation or having to figure out where to look at things from a sterile github page.
I wish that the idea of self documenation was more widespread in other ecosystems.
E.g. the ecosystem I know most, JavaScript, would have this potential, but very often dependencies are compiled and there is no such self-documenting culture so best case scenario you get types you can _almost_ trust and some jsdoc that you can _almost_ trust.
I guess the fact that the lisp and elisp community in particular has always cultivated this practice is the deciding factor rather than the languages itself.
It is actually amazing, emacs is probably the best example of a "living" program you can modify interact and debug directly while you are coding it.
Obviously lisp has been designed around its REPL and debugging experience and the concept of "living programmable programs", but emacs reaches an insanely high level of business complexity, far higher than any software any of us probably writes at work and yet modifying and learning the very program you are using with the program itself is a 30+ years old solved problem that apparently ecosystems outside lisp dialects seem not to pick up.
Not only that but jumping to the source code for whatever command you are looking at is just a key press away. Edit the source, hit another key or two and you've just live patched your editor.
I miss Emacs, but I moved to Visual Studio Code. I used Emacs for over 8 years so releases like this use to make me so happy.
On the bright side, I still use Emacs bindings in Visual Studio Code. Maybe I should spin up Emacs again and give it another shot on my new M1 (maybe it can do the auto complete stuff faster now.)
The reason I'll never leave Emacs is that if I want to change something, I can. It doesn't really matter what it is. This might be technically true in something like VS Code (although Atom was much easier in this regard), but it takes a lot more effort and scaffolding to do something like write a single function and bind it to a keymap in VS Code.
One of the best parts is the bindings! They are present in most shells/terminals, GNU readline-based programs, and even native macOS text field. If you're in a terminal or using a terminal-based program, there's a good chance pressing any of the core Emacs keybindings does what you expect it to.
It's probably largely just habit at this point, but the keybindings are a big part of what keep me with emacs. I honestly have no idea how people navigate text/code with default windows keybindings. That they work by default in many other contexts is a really nice bonus. Most emacs binding emulation modes I've seen for other editors don't support even basic things like "C-<space> C-n C-w", which is basically a non-starter for me.
`brew install d12frosted/emacs-plus/emacs-plus@29 --with-native-comp --with-no-frame-refocus` is easy as pie and gets you the latest build with native comp and smooth trackpad scrolling.
I've been using Emacs for 2/3 years now, especially to take notes. It's been a bit difficult at the beginning but I really enjoy it now, it's provided many features I needed to organize my thoughts.
Knowledgeable Emacs folks in this thread: Does anyone know the status of Wayland-native Emacs? It's my last X/XWayland application, and it looks terrible on high-DPI displays.
The pure GTK branch has been merged into master and I use right now with KDE (and Wayland). I had to adjust the font size but other than that, I didn't meet any issue.
Using it on fedora and ubuntu fine with the pgtk branch for several months, and this is stable IMHO.
global line number mode wasn't stable, and resizing fails to repaint the new parts. killing openened processes (ediff-buffers) can still crash emacs.
29.0.50 is better though.
The latest pgtk cleanups just came in the last days from Po Lu.
> If you’re using projectile or something else, start switching over; this is the new default target for all other integrations
It is pretty sweet something like this is getting built in, but I have not found a replacement for 'with-project-root from the (now seemingly missing) project-root package.
edit: Oh, they also add a new 'with-existing-directory' macro that should be easy to compile to do the same thing. sweet.
An aside, but can someone explain to me the use or utility of ligatures? To be frank people who use them seem like those who change their i3 layout every few months, they seem/feel like a gimmick to me. I hope that isn't too harsh, perhaps I can be convinced they have use.
Ligatures remind me of the symbols in APL. There, I can see sort of a use if your language requires it but generally in the terminal? I don't get it.
I started using Emacs as my primary editor about a year ago with doom. Emacs 28 has good changes, but it's missing pixel scrolling which at this point almost every other editor has. I believe Emacs 29 is going to finally include the feature. There's a pretty good plugin called good-scroll.el that does exactly this on older versions, but it can be buggy sometimes.
In addition to the native pixel-scroll-precision-mode in Emacs 29,
there's also a MELPA package called good-scroll which implements pixel-wise scrolling for other emacs versions also.
I remember seeing vim as a complex solution for text editing, and I didn't touched it for that same reason. A couple of years later I spent sometime learning it and now it's my day-to-day tool for writing code.
I feel the same with Emacs, I've been reading (very little) about it and I wonder if I dedicate the same time I did for learning vim I'd be in the Emacs bandwagon, but at the same time I don't feel that curious about it, because I feel happy with vim.
I've tried some versions with vim bindings but the problem remains the same, the energy to explore the rest just wasn't there.
I was avoiding Emacs for years because I heard that it's a huge timesink, so I kept using Vim and later NeoVim. Last month I started learning Clojure(great language btw) and after some consideration I decided to give Emacs a try.
It's my new favorite thing, it was a pleasure to learn. It took about 4 sessions to get productive with it, a couple of days. Really not that much of an effort. After a bit of tinkering, I feel like Emacs is what I was always looking in other IDEs. (Neo)Vim is a great text editor, but I was never able to customize it to a point where I was 100% satisfied with it. With Emacs it took a couple of weeks.
If you end up giving Emacs a try, I would advise using the native keys, at least until you're comfortable with the editor. When in Rome... Also, masteringemacs.com has a great beginner article, I highly recommend it.
True, vim at the end of the day as you said -- is just a text editor. I usually use vim + tmux to handle a couple of panels with compiler + debugger. Maybe I should try Emacs since it sounds like it can do everything without ever leaving it.
One thing I remember though, startup time of emacs was a bit painful, but I could be misremembering things.
For me, the big feature in editors is mouseless editing. With emacs my fingers never have to leave the keyboard. When I started out in the Dark Ages, vi offered the same benefit, but multiple buffers were easier in emacs, so I ended up with emacs. I use some emacs extensions (e.g. ctags recently), but that's a secondary benefit.
So from my perspective, you've already gotten most of the benefit just with vi. YMMV. If emacs were to disappear today, I'd probably switch to vi and be perfectly happy.
Vim still has some short comings when it comes to developing, since at the end of the day, is a text-editing tools. I usually use tmux + vim over SSH and it's very comfy, maybe Emacs can do all of that in Emacs itself.
I hope I can gather enough energy some day to give it a try. I'm really not into fighting for which ecosystem is better, I just want to enjoy editing code, and so far vim is making it fun, but exploration can be fun too :D
Only thing I'm missing from Emacs is the ability to completely freeze all packages and configs.
As soon as I feel like everything is stable and great, it decides to update 180 packages while I'm trying to edit a file and destroys something in my setup.
If anyone knows a way to prevent all updates and "freeze" a version that would be excellent.
You might want to check out straight.el [0] in replacement of package.el; it can pin package versions, etc. It is used by the very popular Doom Emacs [1] to lock package versions for reproducible config reasons.
Haven't yet needed to freeze a package, but I can confirm that setting up your packages is stupid simple in Doom (Straight), and freezing them equally so.
I use Emacs with Nix, which parses my config for use-package declarations and installs them for me. Emacs packages are pinned the same way as anything else in Nix and, as a bonus, it can also manage non-Emacs dependencies.
I wouldn't recommend Nix just for a reproducible Emacs config, but if you end up considering Nix for broader reasons, being able to use it for Emacs could be a nice bonus :)
Secondly, the breadth of the changes in Emacs 28.1 is staggering, especially considering that Emacs 27.1 was released some 19 months ago. I think it's safe to say that despite all the hand-wringing about the antiquated email-centric way that Emacs is developed, an impressive amount of work is getting done. Emacs development is alive and well.