Was going to make a joke about toilets but after some research realized porcelain does refer to a toilet in this case. Learn something new every day.
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.
Magit is magic: coupled with customization via elisp, it feels smooth as butter to navigate hairy rebases, commit individual lines in changed files, or jump to open a PR in a browser.
One of my daily drivers for development, and a real killer extension to emacs
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).
I really love the discoverability provided by the popups.
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'll have to take a look at that, I love magit's UI for its ease of discovery. Before magit I didn't know that 'git bisect' existed, nor how useful it was.
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.
While I absolutely adore Magit, I wonder why it doesn't just use hydra, a well established package to which Transient is very very similar.[1]
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?
Yes, Magit's UI is fantastic. I also love Notmuch, which has a similar interface design and a really elegant architecture. Incidentally, Magit's developer is also a Notmuch contributor.
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.
docker.el also uses transient. I rate transient over hydra for the specific purpose of making porcelains. I think it's very well suited to the task. docker.el is magit for docker. It's just as life changing. I think docker needed this even more than git.
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?
I made the jump from vim to emacs without relying on evil or spacemacs, working my way through the built-in tutorial (C-h t) and doing my own customization from the bottom up. Surprisingly, you don't need that much customization to get productive in emacs, so it's better to find out for yourself what you need.
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.
I went from vim to emacs with evil mode (i used the doom distribution, which I think is great). However I went back after some months of usage. The main reason is performance. Many plugins are just not very performant with elisp but without them emacs is pointless for me. Also vim has better support for more languages in terms of LSP. In emacs I ran into a lot of outdated plugin issues.
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've used vim for about 5 years and switched directly to "vanilla" emacs (no evil or doom).
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.
You just have to recognize that Lisp is the only true path, and let that guide you to salvation.
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.
One of the easiest ways is to start using emacs for something you didn't use vim for before, like org-mode. Or just for magit, but not text editing yet. Either way, you can stay in your fast, happy path in vim as long as you like, and trickle in small edits in emacs until it becomes more comfortable.
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.
1. You have to get comfortable editing your own config, as much or even more than editing your own .vimrc. I don't think you have to become a lisp master, just understand what is going on like you probably do with vimscript.
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.
Perseverance is the name of the game, much like it is in everything else we do.
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).
I used vim and vi for about 25 years before switching to Emacs. I had many thousands of lines of configuration in my .vimrc that I needed to port over, because I didn't want to lose any functionality over vim.
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.
I've always been an emacs user, so no help from me I'm afraid. But I've read from other vimmers that doom emacs is a very good transition when migrating from vim to emacs, better than spacemacs. I've tried both, and I feel like doom is easier to use overall, so take that as you will.
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.
For me the thing is that emacs can be overwhelming. So focus on doing one task at a time. I still don't know the whole spacemacs interface. I know where my major mode keybinds are. I know how to deal with my .spacemacs. I know where to find documentation. I deal with everything else on a case by case basis.
People who chose it over the default CLI, please give a few examples of why and how. I forced myself to only use magit for a week and it did not work for me, CLI is still faster and more flexible. Maybe a week is not enough time, maybe I'm missing something.
The first thing that drew me in was how easy it is to build commits. You can stage individual files, individual hunks and even individual lines really easily.
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 would never want to go back to the original CLI.
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 has saner defaults for a lot of workflows. Two small examples: stashing prompts you for a name (instead of defaulting to a useless name), and commiting will show the diff of what you're committing on the side (similar to commit -v).
It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.
Picking hunks for resolving merge conflicts is far easier in Magit than using the CLI. Obviously you’d normally do the latter in an editor anyway, but since you’re already /in/ your editor it’s then seamless to continue the merge from within the same environment, instead of bouncing back and forth between the CLI and your editor.
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.
Magit is faster, as in pressing r i in magit's buffer does you an interactive rebase where you can choose the commit to start from. After picking that you can c(= pick)/w(= reword)/m(= edit)/k(= remove) commits from the list.
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.
Are you in windows by any chance? Magit is crazy slow on windows because of it's interaction with git, which is very quick on linux. I started trying it on windows and couldn't see why people would use it, and now that I'm on linux I have no problem with it.
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)
Not sure about other editors, but Magit's hunk- and line-level staging/unstaging is hard to beat, IMO.
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".
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.
Advanced committing (hunk level) is the one thing I use a GUI for. Sublime merge is pretty ideal for this as it opens instantly, and you can open it from the command line with the `smerge` command.
Magit is by far the best git porcelain, although the only other option is the CLI, of course.
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 always was fascinated by the power and usability of magit. However for big repositories it always was way too slow for me. At work I literally waited minutes for some screens to load.
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.
I truly love Emacs. Magit is part of what I see as its three "killer apps":
- 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[0]. Nothing comparable for structured text-editing.
- Slime[1]. 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[2] 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[3].
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?
Slightly off-topic rant: I want this "porcelain" terminology to die, not only is it redundant (what's wrong with "user interface"?) it's not even coherently used within git.
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.
I have to agree. I find the term "porcelain" annoying. But this may be due to me being older than a lot of people for whom the term was already established by the time they heard it, while for me it's a neologism.
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.
[+] [-] cityzen|5 years ago|reply
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.
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
[+] [-] michaericalribo|5 years ago|reply
One of my daily drivers for development, and a real killer extension to emacs
[+] [-] robenkleene|5 years ago|reply
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).
[+] [-] dathinab|5 years ago|reply
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.
[+] [-] mullikine|5 years ago|reply
[+] [-] narwally|5 years ago|reply
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.
[+] [-] pmoriarty|5 years ago|reply
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?
[1] - https://magit.vc/manual/transient/Comparison-With-Other-Pack...
[+] [-] nextos|5 years ago|reply
Emacs ecosystem is getting really good. Org, Notmuch and Magit are fantastic for personal management.
[+] [-] iambvk|5 years ago|reply
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.
[+] [-] mullikine|5 years ago|reply
[+] [-] phonebucket|5 years ago|reply
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?
[+] [-] rpod|5 years ago|reply
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.
[+] [-] fileeditview|5 years ago|reply
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.
[+] [-] p4l4g4|5 years ago|reply
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.
[+] [-] amw-zero|5 years ago|reply
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.
[+] [-] lallysingh|5 years ago|reply
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.
[+] [-] rthomas6|5 years ago|reply
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.
[+] [-] selftest|5 years ago|reply
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.
[+] [-] rohitpaulk|5 years ago|reply
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).
[+] [-] pmoriarty|5 years ago|reply
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.
[+] [-] OrderlyTiamat|5 years ago|reply
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.
[+] [-] brainlessdev|5 years ago|reply
https://fnune.com/2017/12/27/making-emacs-work-like-my-vim-s...
Since then, I'm back to using Vim. I'm planning to write about that, too...
[+] [-] WesternStar|5 years ago|reply
[+] [-] mgalgs|5 years ago|reply
[+] [-] duncan_bayne|5 years ago|reply
Magit is the only one that I've found preferable to just using the CLI tools.
[+] [-] gumby|5 years ago|reply
[+] [-] trabant00|5 years ago|reply
[+] [-] globular-toast|5 years ago|reply
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.
[+] [-] jwr|5 years ago|reply
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.
[+] [-] roblabla|5 years ago|reply
It also gives a rather nice in-editor workflow for adding a single hunk to the git index, which makes crafting sensible commits easier.
[+] [-] pja|5 years ago|reply
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.
[+] [-] kreetx|5 years ago|reply
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.
[+] [-] OrderlyTiamat|5 years ago|reply
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.
[+] [-] nickjj|5 years ago|reply
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.
[+] [-] ryukafalz|5 years ago|reply
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
[+] [-] reegnz|5 years ago|reply
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.
[+] [-] nicoburns|5 years ago|reply
[+] [-] globular-toast|5 years ago|reply
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.
[+] [-] Myrmornis|5 years ago|reply
[+] [-] fileeditview|5 years ago|reply
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.
[+] [-] rpod|5 years ago|reply
[+] [-] steeef|5 years ago|reply
Not being an eMacs user, I'm not familiar with the feature differences, but the workflow of stage/commit is worth it alone.
[+] [-] mark_l_watson|5 years ago|reply
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.
[+] [-] lbj|5 years ago|reply
[+] [-] vngzs|5 years ago|reply
- 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[0]. Nothing comparable for structured text-editing.
- Slime[1]. 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[2] 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[3].
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?
[0]: https://orgmode.org/
[1]: https://common-lisp.net/project/slime/
[2]: https://emacsninja.com/posts/state-of-emacs-lisp-on-guile.ht...
[3]: https://www.baeldung.com/intellij-new-custom-plugin
[+] [-] blablablerg|5 years ago|reply
[+] [-] chj|5 years ago|reply
[+] [-] simias|5 years ago|reply
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.
[+] [-] pmoriarty|5 years ago|reply
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.
[+] [-] bondolo|5 years ago|reply