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.
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.