In case anyone is curious:
But because Git was initially a toolkit for a version control system rather than a full user-friendly VCS, it has a number of subcommands that do low-level work and were designed to be chained together UNIX-style or called from scripts. These commands are generally referred to as Git’s “plumbing” commands, while the more user-friendly commands are called “porcelain” commands.
One of my daily drivers for development, and a real killer extension to emacs
- magit-blame: show the commits for each line
- magit-find-file: allows you to open a file from any branch. So you can easily have the same file from two different branches opened side by side.
- magit-log-buffer-file: shows the git tree with all commits that modified the file in the current buffer (which you can then navigate just like you would when doing M-x magit-status l l)
And this package is pretty sweet as well: https://melpa.org/#/git-timemachine , it allows you to navigate the git tree for a given file easily.
Here’s a tweet with a quick video with me using it (https://twitter.com/robenkleene/status/1299415895262081024).
It works particularly well with Vim (I prefer it to fugitive, mainly because it’s more accessible directly from the command line, so it makes a nice complement to CLI git).
Besides that it looks so good that I want to try out emacs.
Currently I'm using vscode, but many (supposedly very good/main/major) plugins where not so good.
Sometimes fancy looks where favored over usability. Sometimes discoverable of features was just bad and sometimes they where just buggy (like the typescript language server).
Edit: just to be clear, Atom was way worse when I did use it before.
I can think of a few other utilities that would really benefit from a similar interface. Certain use cases of org-mode come to mind. There's nearly always a way to do what I want in org, but sometimes it's a pain to figure out even simple use cases without going to the docs or a forum. It's just something that seems to go hand in hand with all really powerful tools.
I may play around with writing a custom mode for my particular workflow of using org for literate programming. There are a bunch of commands I find useful, but don't use often enough to have committed to memory. I'd also love to be able to pull up a pop-up buffer, like magit's commit messages, whenever I want to edit a source block in more detail.
Why don't these two brilliant programmers team up and make one package twice as good, instead of working on two separate packages and mostly duplicating effort?
 - https://magit.vc/manual/transient/Comparison-With-Other-Pack...
Emacs ecosystem is getting really good. Org, Notmuch and Magit are fantastic for personal management.
I replaced all my custom keybindings into transient under just one C-j keybinding. Now I have a meaningful popup window with my custom keybindings, so I don't have to remember the less-frequently used bindings.
Also, transient has this one cool feature, where you can configure a timeout to delay the popup window, which is also nice.
I have vim mainly customised with language servers and the like, which seems counter to vim's philisophy and closer to emacs.
So I'd love to experiment with emacs properly. But it's so painful; I'm just so much faster at everything with vim. I understand there are things like evil and spacemacs to ease the transition, but every time I try them, I just come straight back to what I'm comfortable with.
Is there anyone else who jumped from vim to emacs. Do you have any tips apart from perserverance?
The mnemonics of the emacs keybindings are part of what makes it so special, so it didn't make much sense to me to use evil-mode. Spacemacs is another layer of abstraction which makes it easier to get started, but ultimately hinders your customizability and understanding of the text editor you are using.
I know you specifically asked for tips that apart from perseverance, but I believe this is the reason I stuck with it for the past 2 years. But beware: mastering emacs is a lifelong hobby, where you sometimes sacrifice short-term productivity for long-term happiness.
[Citation Needed] Spacemacs is just elisp. It is documented and you can explore its source the same as anything else in emacs. `SPC h d` + `which-key` is a godsend for learning and understanding what emacs offers.
I have customized my vim now with shortcuts very similar to Doom/spacemacs and many plugins. I am very happy with my setup at the moment. I don't care if it is against the vim philosophy as long as I get stuff done with it :)
My tip: if you want to try out emacs with evil, try the doom distribution. If you become a convert you still can configure your own if you want/need to later on.
I haven't found anything that comes close to vim's performance as a text editor. In terms of plugins, there are some great ones for Neovim like tpope's rails plugins, coc.nvim, fzf, etc.
Doom is so much better on the performance end, I don't feel the need to keep an emacs server running all the time just for occasional editing in the terminal. I'm interested to see how well it performs with emacs-native-comp. The Doom ui also feels a lot more cohesive. I've never been a vim user, so I use the default emacs bindings but still have a leader key; Doom's setup with the leader key is really well thought out and I'm glad that vim concept has made its way to emacs.
Well Magit was clearly the slowest. Used in big repos with a big list of changes it grinded for minutes before showing the "status" screen e.g.
Also various code completion plugins via LSPs were significantly slower than even VSCode and of course vim. While typing I often encountered lag even on fast systems. Not sure if the lag actually came from the LSP plugin or from something like Flycheck ui.
TBH the one thing I "reimplemented" was the keyboard shortcut system which extensively relies on leader(s). In the beginning I just mirrored doom shortcuts but after a while I customized, more suitable to my own needs.
Not really related to emacs but the vim plugins I would not like to miss are especially: coc.nvim, fzf.vim, ranger, vim-fugitive, vim-mergetool, vim-bookmarks
Thanks to the amazing use-package macro (which Spacemacs/Doom also uses) most configurations are self-contained to a certain extent. Searching for use-package in GitHub will yields plenty of results which can be mostly be taken as a reference for your own liking. It should be relatively easy to port part of Spacemacs/Doom to vanilla use-package, e.g. starting with this (which sets up use-package alongside with evil):
(setq package-enable-at-startup nil)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(unless (package-installed-p 'use-package)
:after (magit evil))
(evil-leader/set-key ("gs" #'magit-status))
Finally, use-package is highly extensible. There is straight.el which adds extension to use-package to fetch from Git and pin a version in a lockfile, which adds reproducibility to Emacs configuration. There's also el-patch from the same author that allows patching package on the fly without the need to maintain separate forks.
My main motivator was similar to yours. Most functionality I used came from plugins, but the language used to write plugins or other modifications felt crippled. When I came across orgmode, during my years on the university, I tried it in vim, through some Plugin. I liked how the format allowed me to dump most of my brain in plain text, but it still felt unnatural to edit it with vim.
During a history course on computer science, I learned more about lisp and its integration in emacs. At that point I decided to try it out. I wanted the full experience, to be able to form an honest opinion. So, I forced myself to do an entire course using emacs instead vim. No evil, just plain emacs. During this time, I fell in love and never looked back.
I still like vim, I just don't find any use for it anymore, except quick editing on servers. Knowing vi key bindings is useful, as vi is almost always present. However, I think that known/understanding emacs key bindings is underrated. Understanding the logic of emacs key bindings will not only makes you more proficient at handling emacs, it also makes moving around most shells more efficient. I know you can configure shells (or more specific: readline) to use vi key bindings, but the default is emacs!
My advise in learning emacs would be: dedicate some time on using it for something real. I'd say, don't get too tempted by the vimify plugins, as they will hide some of the logic of how emacs works. This might slow down or dumb down the learning process. But I'm not discouraging the use of vim plugins all together, just make sure you understand the core product, before modifying it beyond recognition.
That’s not even a joke. The ability to write elisp and bind it to keys is much more useful than the “text editing as programming language” paradigm of vi. Vi is the better text editor, hands down. But enacts is the better text and software environment.
So you can avoid the heavy slam of new-editor-awkwardness in your important work.
I do recommend spacemacs, it (looks like, I'm vanilla emacs myself out of habit) has many packages and customizations atop of a vim-ish keybinding.
2. Consider using Doom Emacs as a starting point. It's fast and works like you would expect out of the box. You can use it like Vim and discover aditional features as you need them. And most importantly, it's (almost) as easy to configure as vanilla.
I’ve been learning Vim and Emacs concurrently with Doom Emacs. I find that if I don’t use the tools for actual work, where speed/familiarity is necessary, I become acclimated to the new environment and start transitioning to its use full-time. Just editing configs is enough to get familiar and it’s low-stakes as far as fucking things up goes.
Took me a couple of weeks to acclimatise, but overall the switch was worth it. If you haven't tried it yet, I'd suggest Doom over Spacemacs (details in the article).
It took a really long time and a lot of effort to get Emacs to do everything that I could do with vim, but I finally did it, and now Emacs does not only pretty much everything vim ever did for me, but does a lot more.
I don't regret the switch or the time and effort it took in the slightest. However, there are a couple of things I do miss about vim and occasionally even fire up vim for.
One is the inferiority of Emacs' regex engine, in certain important respects, like \zs and \ze in vim, which have no Emacs regex equivalent. Those patterns let one match on the beginning or ending of a regex pattern while leaving the position of the cursor/point somewhere else and highlighting a subset of the entire match. That can be pretty useful in certain situations, but it's not enough to leave Emacs and go back to vim.
Another aspect where I find vim superior is in handling large files and files with very long lines. It's just way more performant than Emacs in those situations. Emacs does have long-lines-mode, but it's a hack, and doesn't work in dynamic buffers (like shell buffers) anyway. For handling such files I sometimes temporarily switch back to vim, and back to Emacs after I'm done with that file.
Other than that, there's really nothing about vim that I miss. Though, since I've left vim I have heard that neovim has achieved integration in to various IDEs and other apps that I wish Emacs had.
Anyway, back to the original question about tips for someone else making the transition from vim to Emacs: Apart from perseverance and the use of evil, I'd suggest making hydras for every major mode that you use. That's made Emacs way more useful for me.
Oh, and learn eLisp! If I hadn't known and loved Lisp, I would not have switched from vim to Emacs. There's just no way I could have ever configured Emacs to have all that vim-like functionality (and more besides) if I hadn't known eLisp and actually enjoyed using it.
That Emacs itself and the entire Emacs ecosystem was written in a Lisp was actually a major draw for me to make the switch from vim to Emacs, and in fact it is what's made writing that mountain of configuration not only bearable but actually fun and interesting.
If you hate Lisp, stay far away from Emacs. If you like Lisp, run to Emacs! :) If you don't care one way or the other, give Lisp and Emacs a try.. you might learn to love them, like I do.
It's not bad to stick with vim either anyway, it's a great tool itself.
I use vim every now and then, and I have the exact same experience of "well, if only I could just do X like in emacs, this would go way faster". In the end they're different cultures.
Since then, I'm back to using Vim. I'm planning to write about that, too...
Magit is the only one that I've found preferable to just using the CLI tools.
Viewing diffs has a great, keyboard-driven UI. If your cursor is on a commit (for example when you're viewing logs, but it also works in most other places where you can see commits), you can press space to view the diff, and then use space and backspace to scroll up and down in the diff. Meanwhile you can still use n and p to navigate to different diffs. It's very slick.
Rebasing is really fun with magit. I actually look forward to doing a nontrivial rebase.
I'm constantly doing things like reverting single hunks, applying and saving stashes, looking at a stash and applying a single hunk from there, staging hunks into multiple commits — all of this is much quicker with Magit. It changed the way I use git.
If all you do is simple commits, branch checkouts and cherry-picks, you might not need it. But there is so much more to Git, and Magit makes it nice and quick.
It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.
Rebasing in Magit is very straightforward, far easier than faffing about with the git CLI. Even more so if you’re re-ordering commits, or editing things mid-rebase.
Those are just two obvious things off the top of my head. Magit is pretty great.
Another thing that is convenient is that you can add files to index by selecting lines in a hunk. Doing that in bash is perhaps not as easy (or if it is, do say how).
These are just a few examples. But in summary, magit is just a "tree of keyboard shortcuts" where you just click a few keys in sequence to get what you want.
That said, I also use the cli a lot, i.e depends on if you're in emacs already, or not.
I use both magit and git cli now. Magit is great to get an overview of the changes, the main view is very interactive which is great (e.g. chunk or even line by line staging/discarding/etc. is great)
But to each their own of course.
It’s also just silly to view a multi-file diff, which is hierarchal (File > Changes) just as a flat terminal dump. It's fine for quick diffs that follow a simple pattern, but I wouldn't want to review a complex diff that way.
Also because "c c" is faster to type than "git commit" and "s" is faster than "git add filename.foo".
Granted I don't use Emacs but I haven't found any plugin in any editor that gives the same confidence and flexibility as git add -p.
For hunk-level staging, you put your cursor on the hunk you want to add and press "s". If you want to split that and only stage a few lines, you just select those lines and press "s".
This demo is pretty good I think: https://www.youtube.com/watch?v=rzQEIRRJ2T0
I get the feeling that people don't really know about the interactive git commands.
TBQH most people don't explore git beyond the pull-add-commit-push flow, the ones that do immediately feel like they need a GUI where a TUI would do just as well.
Oh, talking about TUI, I also use https://jonas.github.io/tig/ sometimes.
Hunk level commits is what git add -p [s/e] lets you do.
You can split hunks with s, and if you need even more fine grain control you can hit e which opens that specific hunk in your $EDITOR and then you can pick whatever you want to commit.
It's better than editing a patch file; it's much better than `git add -i`.
Sublime Text and Sublime Merge are works off art in terms of speed and usability.
Although I tend to use vscode more now for editing, I use Sublime Merge every day at work. Worth every penny.
You don't need to own this program for long, before it has saved you more than an hour or 2 of work. And the fee is not recurring.
Now, convincing management that this is a good investment, is of course a completely different story :)
The difference between a porcelain like magit and some other "front-end" is you are actually using git. Other front-ends hide git behind new abstractions (or rather, old abstractions, more like SVN or other centralised VCSs) and I find that users of these never really understand how git works. I've been using magit for almost my entire life with git, I don't really know how to use the CLI, but I consider myself a git expert.
I dropped it (and Emacs) because of performance issues and now I am happily using Vim and for Git I use the cli tools as well as lazygit and tig. I am very happy with these tools.
Not being an eMacs user, I'm not familiar with the feature differences, but the workflow of stage/commit is worth it alone.
That said, almost all of my git workflow now is simple stuff and I find that setting up git aliases/abbreviations is best for me, less ceremony.
- Magit. Best Git UI ever. The other comments in this thread discuss this, so it's probably sufficient to remark that it's the only serious Git tool competitive with Git's own CLI. Equal in power and superior in usability.
- Org-mode. Nothing comparable for structured text-editing.
- Slime. When you edit Emacs Lisp, you really want its near-perfect features around online documentation, jump-to-definition, code completion, etc. With this foundation you can understand the Emacs internals well enough to build whatever else you need. It gives you the best, most fully-featured REPL-ish workflow (C-x C-e to evaluate the current line of Emacs Lisp) within real source code files I have ever experienced.
However, performance issues have kept me from going all-in on my adoption. Mostly this takes the form of long load times upon opening a new file type. Sometimes it's simply a new file, since the whole UI will block on parsing/analyzing a new source file (depending on the major mode).
Guile Emacs seemed like the only real contender to making this workable. But it hasn't received enough love over the last 5 years. Guile proper now supports Emacs Lisp, but the Emacs side of the equation still requires custom builds, and doesn't support many important features. More importantly, Guile ELisp is still slower than Emacs at running ELisp. The whole project is a dead ringer for high-hopes abandonware.
I've moved back to Vim in the meantime, since it reliably opens quickly and never lags on key input. I use a shell for the rest. But I have tasted the fruit of what's possible with Emacs. I want it to work for me, and work for next generation of programmers now gravitating to big piles of Electron like VSCode or JetBrains IDEs with ridiculous barriers to extensibility.
None of the alternatives can replace the kind of tight edit/execute cycle possible in Emacs, nor the incredible discoverability afforded by a Lisp IDE.
Are there other Emacs performance projects, hacks for speed gains, etc. worth following?
So porcelain is supposed to be the opposite of the internal piping of the application, the user facing part. Fair enough. But then why does "git status" have a "--porcelain" option that's meant to generate an output for script consumption? Shouldn't that be --pipe?
And yes, I do know the history of why it's that way, but the point still stands, if you need to know arcane implementation details of some command and backward hacker logic to understand what the hell this "--porcelain" flag does, then it's a bad name.
Magit is a Git user interface inside Emacs.
I feel the same about the term "user stories". Why can't they just call them features?
There's some kind of urge people have to make up new names for old things that just reeks of sleazy marketing or hipsterism to me.
But, whatever.. I think we both know we're not going to change anybody's mind.