6 ms·
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 compar
by sbjs 8y ago
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?
- nickbarnwell 8y agoThe 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!
- kungtotte 8y agoWhenever 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.
- mateuszf 8y agoJust change your OS?
- kungtotte 8y agoI 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)
- earenndil 8y agoYour OS becomes irrelevant when emacs itself is your OS!
- Pimpus 8y agoHe 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.
- kungtotte 8y agoThe 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.
- 8y ago