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
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 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.
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.
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.
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.
:) 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).
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.
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.
> 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!
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.
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”.
I think confluence.el is no longer maintained, sadly. Maybe an interesting new side project :)
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.
- Edit Code - Debug Said Code - Run Said Code - Manage your repo via Git, SVN, or Perforce - Has GitHub integration built in - Has PlantUML integration for creating UML diagrams via their markdown editor (its pretty nifty and I believe now bundled by default) - Connect multiple SSH sessions - Connect multiple SFTP sessions (semantics right)
and so on and son on..I can even do remote editing as if its there, righ tin front of me. you can't even tell if the filesystem is remote because of how it populates in the IDE.
So please, what doe sit not actually do again?
and via plugins, (and a plugin ecosystem that tends to be well manicured/maintained, at that), you can add an LSP or many other languages that are supported. I've tried many many editors, and JetBrain IDE plugins are some of the highest quality i've ever worked with.
So please, tell me, what do they not do again?
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.
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.
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).
But to be honest I only use Emacs because 28 years of using it has made it feel like home, I don't usually recommend it to new people.
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?
As far as I know on the Vim side you can get feature parity.
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.
-Remote file editing with Tramp: This is much better even than using vi/pick over a terminal.
-Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history.
-Easy macro recording and playback.
-Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolling of required.
-Rectangular/column edits.
-Built in file manager.
-Built in shell, can run shell programs and capture their output.
I'd also add:
- incredibly ergonomic file-system navigation (helm+projectile)
First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?
I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.
You're probably aware, but VSCode has great support for editing over SSH.
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.
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.
https://www.youtube.com/watch?v=RfasCCuCEgM
IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.
> 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).
Like I said earlier, that's just for symbols, so no, it's not the same.
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?
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 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 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?