Hacker News Reader

Comment by nickbarnwell | Hacker News Reader

If you're an emacs user, I can't recommend magit [1] enough. I was a diehard CLI user and had flags and aliases out the wazoo, and it was still a step change in usabilty and power for me. Staging hunks, rebasing, and stashing are all vastly easier. Amending or editing a commit is a breeze, and it's tied in to all of the other emacs tools you already use, e.g. org-mode to boot!

It's easier to see it in action than explain it. If you've two minutes to spare, check out this emacsrocks screencast [2], or Howard Abram's longer presentation from the PDX Emacs Hackers meetup [3].

[1]: https://magit.vc/

[2]: https://www.youtube.com/watch?v=rzQEIRRJ2T0

[3]: https://www.youtube.com/watch?v=vQO7F2Q9DwA

View on HN

What I like most about magit is browsing the history of a file via its git-blame mode. It shows you the file split into sections indicating what commit was responsible for that section's lines. Doing `C-x g b` on one of those sections visits the file at that commit and does git blame again without needing to `checkout` that commit. I wish I knew how to be as effective doing that with `git blame` on the shell. Is there a way to provide the commit to `git blame` without needing to `checkout`?

You can specify the commit to look back from on the command line for blame. See [1]

> Optionally, start annotating from the given revision.

[1] https://git-scm.com/docs/git-blame

magit is lifechanging -- At this point I open emacs (assuming it isn't already open) just to use magit to manage things.

If you use it daily don't forget to donate to the developer at least once, sprinkle some of that full-time corporate cog money on them.

Seeing a former coworker use Magit in Emacs is what got me to look into the Vim version: https://github.com/jreybert/vimagit

From what I gather it's nowhere near as feature-complete, but it lets me create commits with immense ease and precision.

Fugitive is great:

https://github.com/tpope/vim-fugitive

You may want to try emacs just for magit. That is, using it as a Git GUI while using VIM for everything else (if you don't want to switch).

I was a die-hard vim+tmux user before switching to Spacemacs.

Now I have all the power of vim’s modal editing with Emacs’ vastly superior ecosystem of packages.

> Seeing a former coworker use Magit in Emacs is what got me to look into the Vim version

What you should have done is use magit and looked into the emacs version of vim: https://github.com/emacs-evil/evil

Magit has a PR problem: most people think they need to be already using Emacs to use Magit, but that's far from the case. Indeed most Magit keybindings are single-letter like vim. I wish I could get more people to try Magit without being turned off by the fact that it's an "Emacs plugin". Hmm.. what if there were a standalone version of Magit? Would more people use it?

Based on those videos, lazygit looks like it does the same things as magit, but with a little more "chrome" (boxes around lists). How do the two projects compare? Could they be merged, or do they have fundamentally different philosophies?

The videos touch upon a fraction of magit’s capabilities; if nothing else, it’s a far more mature project.

But the real power is integration with the rest of emacs/being written in elisp. If I want to change or script behaviour, I have easy access to all the internals, and I can integrate it with other parts of my emacs workflow. For example, I can use magit to view the diff of a coworker’s PR, easily capture snippets, including links to their location in our internal BitBucket instance, into an org buffer, and then write up and send an HTML formatted message with my comments, syntax highlighting, etc to my colleagues with my feedback.

Similarly, my TODO list is managed by org, and I can have links to commits or files at a certain commit directly in my agenda or notes and jump to them.

This is all within my editor, with all the text editing, code navigating, and linting capabilities it provides!

Whenever I read a comment or blog post about Emacs I'm like "I should definitely try it out, because that sounds awesome", then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it.

It's the same thing with vim for that matter. A basic-ish text editor setup is trivial in both editors but beyond that things start to fall apart. Plugins/modes rely on being run in *nix environments to work well, and the workarounds for Windows are never 100%. The startup times start to suffer a lot too in vim and Emacs when you pile on a lot of features.

I think that's why VSCode has gained so much traction. For coding it's got easily 90% of the same features as both vim and Emacs (if not more), but it's trivial to set up and with many users being on Windows pretty much everything has first-class Windows support.

So that's what happens every time. I stick to VSCode and keep a lightweight vim setup around for quick text edits since it opens instantly. Perfect for quickly changing a config file or jotting something down if I don't have VSCode open.

>then I do try it and it turns out it's a pain in the ass to make it work on Windows and I spend more time fiddling with it than I do working with it.

The first few times I did it on Windows it was a pain (almost a decade ago). You had to install some dependencies manually. But the last few times I did it it really was a straightforward install, with everything working out of the box (except any commands that rely on GNU tools like grep). I may have been using an unofficial port - sorry but I don't remember the link.

My Windows Emacs is almost identical to my Linux Emacs. You wouldn't know you're not in Linux. That, for me, is the joy of Emacs - it behaves the same on both OS's.

A plain vim or Emacs is trivial to set up and is indistinguishable, simple config changes are also trivial, but once you go deeper into plugins/layers for things like fuzzy file finders it starts to fall apart because they start relying on Linux-only tools or the Windows equivalent tools aren't as good.

Some of it you can get to work after copious amounts of fiddling, but I don't have that kind of time or willpower. While it might not be as powerful the total amount of time I've spent actually making config changes in VSCode is probably about 30 minutes. This is including time waiting for extensions to download! Not to mention that it ships with many features out of the box such as git integration.

How did you get magit to not be slow as hell on Windows?

It’s brutally slow on my windows box and lightning quick on my Mac.

Best setup I've found was to run everything within WSL when developing on Windows and exporting emacs display to Mobaxterm's x-server for a proper emacs experience. Everything is extremely fast and I find myself using my Mac less frequently now since WSL is working very well for me.

>How did you get magit to not be slow as hell on Windows?

By using mercurial :-)

Had no idea magit is slow on Windows. Any idea why?

It’s mainly due to the cost of spinning up subproccesses and certain FS operations on Windows. Magit spins up a bunch of git processes for certain operations and can be quite slow due to it. Look into fscache settings for a speedup

> I think that's why VSCode has gained so much traction. For coding it's got easily 90% of the same features as both vim and Emacs

Is that a joke? How can you possibly know this if you haven't used emacs for a start. Do you really think it has 90% of the features of a 35 year old project?

If emacs is difficult to set up on Windows you should stop using it. The awesome stuff you hear about is mostly the result of using emacs on an OS that is decent for development. But if you insist on staying in your prison then you'll have to put up with what Microsoft lets you have.

I have used vim for god knows who long, and I've tried Emacs several times for a few months at a time before giving up. So I do think that for coding VSCode absolutely has 90% of the features that both vim and emacs offer. Note how I said "for coding"? That's not an accidental or trivial part of my comment. For writing and managing code the feature-sets are on par in all three for sure and if you disagree then I am going to suggest to you that you actually give all three a try and focus only on coding and you'll see what I mean.

I should stop using Windows because a single application is difficult to set up? Throw out my entire OS with the plethora of other applications I use because a single application that has had 35 years to get its shit together simply won't work well? That's a reasonable position for sure!

Developing on Windows works absolutely fine, and if you wan't to talk about prisons and what "Microsoft lets me have" how about we talk about the WSL? They have no reason to include it in Windows but they do. A whole bunch of Linux software became available over night in a native Windows environment because of something Microsoft did. The ones who are digging their heels in at this point are all the *nix developers who refuse to support Windows as a first-class platform, so talk about being in a prison! Your software only works well on a subset of all operating systems.

> a single application that has had 35 years to get its shit together simply won't work well?

It's because the people that like emacs don't like Windows. You would see why if you would try something else. If you want emacs to work well on Windows, do it yourself. Nobody owes you anything.

Nobody owes me, and I'm not asking for anything. I'm just lamenting the fact that things are the way they are.

I use both Windows and Linux, which is precisely why I want to use an editor that's properly cross-platform instead of using separate editors or use one that's configured differently based on platform.

Maybe you should try Windows? It sounds like you could benefit from broadening your horizons a little bit.

I used Windows full time until ten years ago. Like many it was my first introduction to computers. I switched to Linux and never looked back even once. I've had to use Windows at work for the last 9 months and it's been an awful experience the whole time. Nothing has changed.

If there was no option for a free operating system I would stop using computers in an instant. I won't go back. Ever.

I've used emacs on windows in the past for quite a bit. I don't remember it being particularly hard to install, either the cygwin ir the native Windows emacs buid.

Just change your OS?

I think it kind of proves my point when the solution to not being able to set an editor up is to change your entire OS...

(Also: no)

He has a point. Why complain about Emacs when the problem is Windows?

To be fair, I am known to use all three OS's from time to time. I just have conditional guards to prevent loading packages that break on Windows. Mostly everything works the same. In fact, I originally learned Emacs on Windows back when I was a younger and noobier programmer.

The problem isn't Emacs, since the core program works fine on Windows (as does vim). Many packages for both also work just fine.

But then there's that subset of packages that don't work fine. Some can be fixed with fiddling, but then you lose that Emacs thing of installing a package and be on your way (usually a point in favour of Emacs over vim I might add!). And some just can't be fixed, which leaves me either using a different editor for those needs or just not using those packages by using conditional configs.

However then we run into a little peeve of mine: the reason I want to use a tool like vim or Emacs is to have the same tool working the same way everywhere. I don't want to learn and more importantly maintain two setups. I want to sync my one setup across any machine I use and have it work the same way. I also don't want to have the situation that my editor works one way on system A and another on system B.

Your OS becomes irrelevant when emacs itself is your OS!

Reply on news.ycombinator.com