> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows.
I've been writing software for ~24 years, and I can understand the need for this in the past.
Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar.
The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?
> Can you talk about a few use cases where emacs is just better than an IDE could be?
I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues.
Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though.
Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive)
I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim
You can do one thing in JetBrains: edit code. That's it.
In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface. I edit remote files, I edit files via sudo on my machine. I control git. Yes, JetBrains can do git, too. My colleagues sometimes use it. Actually, they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows. Not different people. Everybody individually! Why? Because they know how to do different things in different tools. Meanwhile, I just use magit. Magit is absolutely fantastic, there is no better git interface, and I've tried many. Even for our backend Kotlin code, which I have to use IntelliJ for, I jump back to Emacs to use git, and edit yaml/graphql/etc files.
I've probably forgotten a couple of things here. And the cool part is that Emacs now supports LSP very well, and LSP is starting to support a lot of languages very well. So I don't even miss IDE features, such as refactoring. Add to that block selection, the best undo mode, actually robust modal editing (evil!) fantastic documentation, great flexibility, keyboard macros (I use them ~2-3 a week, and they're great every time)
… the list goes on. I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
> You can do one thing in JetBrains: edit code. That's it.
You can also takes notes in markdown docs and/or code comments (it has a built-in TODO detector and organizer).
> they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows
I just use SmartGit for git. It's configurable with workflows (or custom commands), navigable with a keyboard, visual, clickable, and actually "smart" -- it warns you if it thinks you're about to do something stupid, like overwrite a repository's history.
> In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface.
This is good info. These are all things I really, really don't want to do in my IDE. I want my IDE to be a good IDE, and I want my other tools to be purpose-built as well.
Switching apps is not painful to me at all. I often have a screen with a git GUI, IDE, browser, and DB GUI all open at the same time.
I get it, not everybody has the mindset of living in one tool — I didn't either, before I converted to Emacs, which is a relatively recent development. Maybe 3-4 years, though I did use it ~7 years ago once, and then even further back, probably around 12 or so years ago. I don't quite remember.
But I came back to it, and stayed for good, because Emacs is really an OS with a nice editor. So you can have the same approach of do one thing and do it well, but you have different packages instead of different programs. And they synergize nicely. So it's not only an IDE. Everything I use is purpose-built for that one task, including ledger (accounting), mu4e (mail), lsp (IDE-features), org (agenda, research, documentation) magit (git) etc. None of these things are "plugins". They're programs in their own right, just like ls and mutt, and git themselves.
> This is good info. These are all things I really, really don't want to do in my IDE
The point of Emacs is that it's a text-editor, and as someone editing text all day (code, documentation, etc) I want the best, most consistent text-editing and text-process possible, without having to jump from tool to tool.
With Emacs, you can mold everything you do to be consistent across all dimensions you can imagine. Once you get used to it, it is very weird (unthinkable?) to go back to other tools.
What are your favourite features about magit? I switch between Pycharm and Vs code and terminal for my git usage. I find Pycharm has a really great git blame ui that makes it easy to walk back in time and investigate changes. It lets you toggle "Annotations" next to the line number, that display the SHA. From there, you can right click > show diff, from which you can _also_ show annotations, and continue jumping back ad infinitum. Vs code has a plugin which does something similar, but I find the UX to be not as elegant (the annotations are way too wide; every option is hidden behind cryptic icons like "<<"; diffs open in new tabs, which makes things cluttered; and instead of right click menus they have really large hover menus which I find are super finicky to use). VS Code's conflict resolution is a little easier to use for me. Pycharm's approach is a little overly UI'd, whereas Vs code treats everything as text with helpful little overlays for quickly selecting one vs the other. Also when viewing local changes as a diff, Vs code's highlight change > right click > "stage selected lines" is more flexible then Pycharm which only shows a little checkmark near "chunks" of the diff for staging. Both editors also have a lovely feature that lets you highlight text and copy the GitHub link to the chunk or the entire file. Makes sharing really easy.
I use the git terminal for everything else; branching, checkouts, rebasing, pulling, pushing. Actually I use vim for interactive rebasing because it's fast/quick there.
For a similarly complex task, there is no program with a better UI.
Magit manages to optimize for both, speed and discoverability: 99% of all actions are 2-3 keystrokes away, and at each stage of that process, magit will tell you your options. For example, invoke magit, press 'b' brings up the branching menu, basically a keymap for letter -> action. Pressing 'c' for checkout then starts a new branch creation. The default branchpoint is your current branch. If that is fine, press enter, otherwise type out the branch name (tab completion for all possibilities, local and remote). Finally, you name your branch. So in 99% of the cases, it is b>c>enter>my_cool_new_feature>enter, done.
Before magit, using version control was a necessary evil (for me). Nowadays, it is so effortless, so natural, that it hardly registers in my attention -- similar to the way that you automatically save the file that you are working on after a couple of lines of writing without noticing that you are doing it.
All cli tools should have a magit interface. World peace and happiness would ensue.
> All cli tools should have a magit interface. World peace and happiness would ensue.
:) Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli. That does sound great! There are some git commands which would be super annoying to do via a UI (not to mention if you add _all_ of git's features to a UI, good luck making anything discoverable :P), but in the CLI they're kind of awkward cause unless it's something I use very frequently, I forget the syntax (looking at you git bisect). This sounds like it would make those significantly easier to use, _and_ help the developer discover new git commands they might not be aware of (looking at you, git bisect :P).
> Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli
It's a complete git "porcelain", in that it provides more or less full access to all git offers.
I daily rewrite git history in my feature-branches, cleaning up my commits, to provide fully atomic and clean merges back into dev.
Using magit, it's just seamless and feels immensly rewarding wrt doing a good job. Without magit? I wouldn't even bother.
Magit is not "just" a wrapper around the git CLI. It's a complete replacement, enabling you to fully exploit all of Git's power without ever leaving your editor of choice, nor exposing you to complex internals.
It's an amazing product, and I've seen people ask for a Magit-only Emacs-distro, just to replace their existing Git client.
I think incremental commits are among my favorites in magit. It's so quick and easy to stage and commit selectively.
The other thing I love about it is discoverability of git features. Did you know that you can stash index and working tree separately? I only know because of magit. Now that I know, I have actually used it to great success.
Also, I've become my team's go-to rebase monkey. What takes my colleagues minutes of thinking what to rebase where, and how, and how to deal with the conflicts, I'm usually done in seconds. Also, conflict resolution with magit is really very streamlined. Conflicts still suck, but less so.
Pushing/pulling to/from different remotes is quick and easy (happens often with github forks and PRs), merging and branching is a breeze, and you've got splendid auto-completion on branch and tag names (I use ivy.)
The blame mode you described exists in magit, too. You can annotate a file and drill back into a certain commit's history. Actually, the default way magit does it is dissimilar from what you might be used to from other GUI tools. Magit doesn't annotate the left or right, but instead inserts header lines for a commit. That way it's easier to see coherent commits. I find this way of displaying history nicer if your code's commit history actually contains chunks of lines for the files, and it's not so fragmented that practically every line is from a different commit/author. It's possible to do the margin-annotation you're used to from other blame tools, too, though.
Thanks for the examples! The magit page is a little hard for me to grok why it might be worth switching to something else.
> Did you know that you can stash index and working tree separately?
What does this mean? Can you give an example?
> Also, I've become my team's go-to rebase monkey.
Haha, hello friend. I love rebasing; it always breaks my heart a little when I see "Merged master into branch X" commits :P My main git rebase flow is `git checkout master; git pull upstream master; git checkout X; git rebase -i master` + vim. Having multiple branches that depend on a shared branch does get a little messy though. How does magit make this flow better?
> Conflicts still suck, but less so.
Hahaha, that's all you can hope for with merge conflicts!
`git status` always shows you some of three things: files not tracked by git, tracked files with modifications that are not staged, and tracked files with modifications that are staged.
You can stash tracked files with modifications, or tracked files without modifications separately! Scenario: I've staged a couple files for a commit I'm preparing, but I see that there's an unrelated change in the unstaged files that I want to do in a commit that should come first. So I stash everything I've staged. I do not stash what I haven't staged! Now I can create that new commit, and pop the stash later to come back to the commit I wanted to originally write.
I agree with all of this, especially discoverability of git features. I think using magit really helped me build a mental model of what git’s doing and what it can do vs. just using the git CLI on it’s own.
And yeah, incremental committing, the rebase workflow, working with multiple remotes... they’re all a breeze. With the GitHub style PR workflow, I typically set the main repo for a project as the “upstream” remote and my fork as “origin.” With the settings I’m used to for a project, pulling down the latest changes from upstream is two keystrokes: “F u”, and pushing back up to my fork is two more: “P p”.
Actually, I just use ox-confluence, which means I can export (narrowed) org-mode trees to confluence. It exports it to a buffer that I cut-and-paste into the web page.
I think confluence.el is no longer maintained, sadly. Maybe an interesting new side project :)
> You can do one thing in JetBrains: edit code. That's it.
No, you can do more, it's just usually people don't have the mindset to do more. And to be fair, JetBrains software is not meant to do that, so it's harder to do it, preventing the people from developing the mindset. It's a loop.
Thats just plan incorrect. JetBrains lets you do the following, out of the box:
- Edit Code
- Debug Said Code
- Run Said Code
- Manage your repo via Git, SVN, or Perforce
- Has GitHub integration built in
- Has PlantUML integration for creating UML diagrams via their markdown editor (its pretty nifty and I believe now bundled by default)
- Connect multiple SSH sessions
- Connect multiple SFTP sessions (semantics right)
and so on and son on..I can even do remote editing as if its there, righ tin front of me. you can't even tell if the filesystem is remote because of how it populates in the IDE.
So please, what doe sit not actually do again?
and via plugins, (and a plugin ecosystem that tends to be well manicured/maintained, at that), you can add an LSP or many other languages that are supported. I've tried many many editors, and JetBrain IDE plugins are some of the highest quality i've ever worked with.
>In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs.
No one cares (other than Emacs users). There are better tools designed for those purposes. There's a reason the UNIX philosophy of doing one thing well is still so popular and widely used. Rather than configuring and spending hours on buggy, poorly developed and indecipherable systems like Gnus, org-mode (it's like an Emacs with an Emacs, just ridiculous) etc people instead choose tools that are far better, more intuitive and works out of the box and everywhere.
> I edit remote files, I edit files via sudo on my machine.
Any decent editor or IDE can do that.
>I control git.
VSCode support for Git (and Github) blows everything else out there. And so also for languages like Python. Emacs support for any language which is not a Lisp dialect or C is horrible.
> I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.
I very much doubt you actually tried to use anything else.
Which tool would you suggest for Org-mode?
I have been reading up on it and it almost made me want to use emacs. But if there is a better tool designed for it's purpose..
And that's already not a decent concurrent for org-mode. Not that I have a grudge against web tech, but no self-hosting of my most personal data and no offline abilities is a deal-breaker for me.
Emacs user here. I've been thinking about this lately since I switched to VSCode because Emacs doesn't have a good TypeScript React mode and to be honest, you're right.
The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just nothing else like it, and boy is Magit slow when I have to merge big changes (probably exacerbated by Emacs Mac port's slow vfork).
Tide + https://github.com/jscheid/prettier.el + projectile + helm work wonders. Been using this for +3 years now and its one of the bigger productivity improvements in my recent years of emacs and programming practice.
At work, I actually try to get ppl away from Jetbrains IDEs because they are slow and their typescript and prettier support seems pretty buggy to me.
Unfortunately, most developers I meet these times are not the kind of hacker types that want to understand and optimize their tools but rather just to get stuff done on the surface (which is totally fine). So emacs isn't just a good fit for them.
I use emacs/tide/prettier-js, but the prettier formatting only happens on save. Do you have settings that make emacs adhere to prettier formatting as it goes along?
1. Nothing I've found comes anywhere close to Emacs support for keyboard macros. Zero latency to record. Records every keystroke. Very very consistent behavior. Infinite undo. Kill Ring. Register support.
Despite being an expert Emacs user, I'm mostly in VS Code these days because it has syntax highlighting, git support, and linting out of the the box. But I always go back to Emacs when I need to transform a bit of text.
2. Comparing two text snippets, as opposed to files.
There are a small set of use cases where you want to look at every position where something has changed. You can open two buffers in Emacs and use compare-windows to walk through them. Since the IDEs are all file-oriented, they don't work for this case well.
What are some examples of keyboard macros you use? I read a lot about people loving keyboard macros, but I can honestly say I've never thought of a use-case for them. There's already a built-in IDE automation for everything I could think to do with a macro.
If you have, say, a list on consecutive lines with a blank line in between them, and you want to delete a character after the second word, add some text at the end, and delete the blank line - with keyboard macros you record these transformations once and then apply them to the rest of the items.
First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?
I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.
Remote file-editing is also available with other editors and IDEs. Everything KDE has it out if the box for example. Vim has IIRC some protocols. VS Code got some a bit ago as I heard.
> Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I thing it's a bit between exploring the possibilities of your tools, expressing yourself in some "divine art" and procrastinating under the guise of being productive. There is definitly a high amount of good customizing possible with emacs, but from my observation many end also in the trap of over-custimizing, to the point where it becomes harmful. Not to forgotten all the worthless oversmart solutions build in emacs, beacuse emacs gives them the means to do it.
> The level of customization that emacs supports seems unnecessary to me.
Emacs is a platform for textual and programatic interfaces. Similar to web-technologie. As such you can tweak little things, but also build whole apps dedicated to specific usecases with it.
> Can you talk about a few use cases where emacs is just better than an IDE could be?
It's not better than IDE, but similar level as IDE. Just that you are able to do it yourself. With an IDE, if you have a specific demand like integrating some new tool, or handling some specific filetype, you depend on the producer to build it into the IDE. Just recently IDEs have also learned to use plugins, to allow you build some stuff yourself. Ok, recently was 15-20 years ago, but emacs is 40 years old, predating them all.
I think VSCode is a very mouse-centric experience. Using Emacs I don't touch my mouse. It's a far more efficient and comfortable (less straining) experience, for me anyway. I use both Emacs and VSCode but vastly prefer the Emacs experience. I also use Emacs for much more than simply writing code.
Emacs is also more pleasant to use because it's simply faster. VSCode is slow compared. I'm not talking about application startup time, but just about every operation you do. VSCode stutters and hitches all over the place. Input latency might also be worse, but I don't know, that's just what it feels like. It also lacks many of Emacs' powerful features like helm swooping, which is of course customized just the way I like it. VSCode's "search in all files" just doesn't cut it. And symbol fuzzy search is just for symbols, not all text. Code navigation in Emacs is lightning fast, with the right setup. My Emacs config makes a distribution tailored for me.
A great advantage Emacs used to have over other IDEs and some editors was that you would use it for all/any language. Now with editors like VSCode, which has great support for many languages, it has lost this advantage.
Although the mouse centric experience thing makes sense when _writing_ code, I don't think it makes as much sense for reading/refactoring code. I'm not an Emacs user, but watching some of my colleagues navigating a codebase with Emacs looks not only slow, but also very mentally taxing. They often switch to grep searching, then select the results in order to iterate over them in Emacs. Or they have to remember full paths to files (with autocompletion, but still). Ctrl-shift-f in Vs code looks significantly faster since it displays the results in real time and let's you see the snippet and simply click on the one you want. Also ctrl-p for finding a file quickly by searching for any part of the path. Ctrl-clicking on a method name to jump to its definition. Right click > rename to rename a symbol across files. Or a feature I love in Pycharm, alt-enter to auto import a function--without having to try to remember where it's coming from (it gives a drop-down for multiple definitions). These things speed up flows enough that I think it outweighs the cost of having to remove your hands from the keyboard. And I think reading/refactoring code is as important as writing code in development.
These are exactly the things I find better and faster in Emacs. Watch video below and imagine searching that way but for all files in your project. Results in real-time, instantly taken to content when you highlight and browse results with arrow keys or further narrow down by typing.
Oh nice! That's pretty similar to the VS Code's search experience; I didn't know emacs had that built in! I have a colleague who uses emacs and he always uses grep for stuff like this and it makes my eyes bleed :P
> I think VSCode is a very mouse-centric experience
I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen"
> VSCode is slow compared
Yeah, probably true. Never felt like it slowed me down though
> And symbol fuzzy search is just for symbols, not all text
cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).
So, I write a niche language server along with an adapter for VS Code. What are you frequently jumping to that isn't a symbol?
I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references.
The only thing that wouldn't work is trying to jump to syntax, but why would you do that?
I was going to say pong. Or fireplace. Or maybe the same experience on macos or linux or editing files on an embedded router remotely with tramp.
But really the customization is the use case.
just some examples:
I have written a few specialized diff functions. diff two directories, diff 20 files, diff what I have vs checked in. many different comment-out-a-region functions. remote compile. local compile, but build this part of a project or build it this way. every language I code in has customizations, for indent, for tabs, for colors, several "insert a debug printf".
They are all silly and redundant of no consequence. I frequently rewrite them or throw them away depending on the project I'm working on.
they are meta-silly even: f2 will rotate through editing my 3 startup files.
However - when the time gets tight and I have to do something on a schedule, I'm not grinding through some other person's decision of what is best, I'm just doing it. I also get better at it with time.
I just wrote a small function to convert Unix epoch timestamps to date-time strings. Just to be able to make sense of timestamps in some log files I was looking at.
I find this kind repetitive thing frequently comes up in the course of one's work. Not a big deal to copy and paste in a web site to convert the first few (or few hundred) times, or firing up the python interpreter. But once it becomes apparent that I will have to do this again and again it is great that Emacs gives me a way to add that small function to it.
I use an IDE for java development because the refactoring is just too useful. But Emacs macros are very useful and I haven’t found something like this in my IDE.
I wonder whether it’s possible to set up lsp-mode for my Java project.
I've been writing software for ~24 years, and I can understand the need for this in the past.
Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?
I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar.
The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?