use-package VS magit

One example is the ~use-package~ macro (Emacs plugin) [0]. Using packages in emacs is mostly the same code over and over. They've already been abstracted in functions, but you still find yourself juggling with so many utilities. You could write a bigger functions, but it will then have a lot of conditional branches. This macro selectively select the code it needs and transforming it if needs be and then the result will be evaluated.

It's a bit hard to explain for me (English is not my native language). But it's the difference between coding a solution will all the edge cases baked in and coding an archetype that let you add your own cases. With functions, you abstract common algorithms, with macros you abstract common architecture.

[0] https://github.com/jwiegley/use-package/blob/a6e856418d2ebd0...

Another way would be to redefine parts of the bind-key macro or its use-package support functions

The package-install call installs use-package that provides a utility of the same name to make it easier to manage packages. It's admittedly a little overkill for this specific config, but it's a cheap investment that sets you up for later success.

Granted, the Doom macro makes your code looks nice and compact. But you can get very close to that just by using do-list and define-key together. Or by using the bind-key.el package, which is included with Use-package.

> Deps is well documented.

> The issue I personally found is that I needed to look at a bunch of OS project's deps.edn to see how people commonly structure things. Other than that it is a simple tool.

This strikes me as a contradiction, because if it was well documented you wouldn’t need to look at other people’s configs to see how to use it.

My experience with deps.edn is that every time I start a project and make a deps.edn file, I immediately draw a blank and don’t know how to structure it, so I open ones from other projects to start lifting stuff out of them.

I still don’t know how to reliably configure a project to use nrepl or socket repl without just using an editor plugin. I definitely have no idea how to use those in conjunction with a tool like reveal.

To me, none of that is simple. Simple would be like Emacs’ use-package. With that I know how to add dependencies, specify keybinds, and do initialization and configuration off the top of my head. And it has really nice documentation with tons of examples.

https://github.com/jwiegley/use-package

Since you are doing code development, the first things to go for would be setting up your emacs packaging (installing use-package and melpa (use-package's documentation covers this) so you have more packages to choose from (do be careful to not just pick things willy nilly but research them a bit first)) and then setting up lsp-mode. lsp-mode lets you use LSP servers for the specific programming languages you work with in a somewhat unified fashion. You then need to install and setup the LSP servers for the languages you use, and possibly install language specific Emacs packages as support (note, Emacs has builtin functionality for many).

I'm using use-package as my package manager and the package ligature for the ligatures.

I have been crafting my emacs config for about 10 years. I started with vanilla and intentionally stayed away from frameworks. About two years ago I declared config bankruptcy and went down for a rewrite using use-package and straight.

ref: https://github.com/radian-software/straight.el https://github.com/jwiegley/use-package

I've collected a list of projects that are inspired by Magit at https://github.com/magit/magit/wiki/Inspired-by-Magit.

(And a list of other Git related tools at https://github.com/magit/magit/wiki/Other-Tools.)

Magit for using Git - I would be lost without this.

There're multiple solutions like this and I've used some of them over the past years.

- There's obviously the fantastic Magit (https://github.com/magit/magit) which is an Emacs Plugin but you can configure your Emacs start up just with Magic and nothing else so that Emacs is only used as a TUI Git client. I did this for a while.

- There's GitUI written in Rust (https://github.com/extrawurst/gitui) I did use this for a long time but recently switched over to LazyGit for the better Vim bindings and having more features

- LazyGit (https://github.com/jesseduffield/lazygit) is what I'm using right now and I'm mostly happy

I actually wrote my own in C some years ago called Gitsi (https://github.com/terhechte/gitsi).

One thing that I added that (as far as I know) none of the others have and I sorely miss is VIM number based movements. So you can say 4j and jump 4 selections down. This makes it much faster (for me) to jump to the one file I'd like to commit. I ultimately stopped developing Gitsi because I didn't have the time to implement all the features others had readily available.

I do prefer TUI based Git clients to full blown GUI apps because of the keyboard movement. So I can quickly enter do something and exit, while staying in the terminal

Not exactly what you asked for but if you are an emacs user, magit will make using git so much more pleasant. https://magit.vc/

Generally most IDEs will help you out with basic git tasks without even needing to know commands. There also dedicated GUIs for git.

Though for full time devs just learning how to use plain git isn't that hard. I very rarely have to look up git commands these days. You can limit yourself to the basic commands first.

For the TUI inclined, lazygit [1] and magit (emacs) [2] both have quick and intuitive ways of handling this. They're also both wonderful companions to the git cli for day to day version control.

[1]: https://github.com/jesseduffield/lazygit

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

Then the slowness that you're seeing is probably Windows-specific, and that's why everyone else is telling you that Magit is actually fast.

WSL might make things faster.[1] IIUC, the problem is that starting new processes is much slower on Windows than on Linux/Unix and Magit relies heavily on that. This seems to have plagued Git tooling more generally but maybe this got fixed since then.[2]

[1] https://emacs.stackexchange.com/a/58444

[2] https://github.com/magit/magit/issues/2395#issuecomment-1710...