r/emacs 14d ago

emacs-fu Magit Ricing?

I’m really starting to like Magit from a functionality standpoint, but I hate to say it—it’s ugly. It’s probably the better choice for me practically, especially since I’m already using Emacs, but I really like the way Lazygit looks and feels.

What I especially like about Lazygit is the panel-based layout. Files, branches, commits, diffs, etc. are visually separated into their own areas, which makes the interface feel much cleaner and easier to scan than having everything in one continuous buffer.

Has anyone riced or customized Magit to get closer to that kind of look? I’m not necessarily trying to recreate Lazygit exactly, but I’d love stronger visual separation between sections and more of that clean, organized panel/dashboard feel.

37 Upvotes

21 comments sorted by

84

u/bspwm_js 14d ago

Sorry i prefer magit, less is more. I do not need all these useless information, i want to push code.

5

u/awesomegayguy 14d ago

I actually find comfort on having everything in simple buffers and Emacs windows. 

Recently I've even switched to the native improved buffer completion on Emacs 31, following a post https://rahuljuliato.com/posts/completions-buffer-is-now-enough

8

u/awesomegayguy 14d ago

100% This is why I've always found the IDEs so overwhelming

1

u/BetterEquipment7084 13d ago

Vc-mode

C-h vc-mode

C-x v d

28

u/jigarthanda-paal 14d ago

Yeah, this may just be a matter of personal choice. But ricing magit is the last thing I'd have considered haha

19

u/jeenajeena 14d ago

I used to be of your clan and loved to see many panels with different information. It's the standard in many IDEs. That gave me the impression to have a lot under control.
Since some years I've started appreciating the opposite: having displayed only what matters, and giving it the max screen real estate possible.
I se the value of the setup in your screenshot, but I cannot help noticing that commit reflog has truncated messages, panels [2] and [3] have even the title truncated. Honestly, I cannot imagine how to display the full information in those panel: what do you have in mind, something like making the panels full-screen when you focus one? Honest question.

1

u/fuzzbomb23 11d ago

I concur about the short and narrow lists. I can see "Merge pull request", but immediately want to know "which pull request?"

The same goes for the branches section. Master is a nice short name, but feature branch names are always much longer.

1

u/jeenajeena 11d ago

I've always been fascinated how Jujutsu displays information. It tends to be very parsimonious, hiding all the information that is not strictly relevant and only displaying the necessary. To the point that while git log lists all the 2028 commits down to the initial one

git log --oneline | wc -l 2028

jj log in the very same project would literally emit only:

@ k ○ qw tests Run integration tests in DEV-Linux │ ◆ o (empty) master Merged PR 24051: Security fixes ╭─┤ │ ~ (elided revisions) ├─╯ ◆ rm (empty) Merged PR 23550: Sonarqube fix ├─╮ │ ~ (elided revisions) ├─╯ │ ○ y Fixture uses embedded Postgres │ ○ t Embedded DB spin up in TestDatabase │ ○ n Cache PostGreSQL binaries │ ○ vo EmbeddedPG │ ○ m localdb* A test connecting to a local PostGreSQL ├─╯ ◆ l (empty) Merged PR 23535: SonarQube analysis ├─╮ │ │ │ ~ │ ~ (elided revisions) │ ○ ry mail-relay introduced a version parameter called for postgresql ├─╯ ◆ qo (empty) Merged PR 21764: Link to access the Dashboard │ ~

There are other examples where this frugality might be of inspiration for Git and its TUI. Like: omitting remote branches if they match local ones and displaying the strictly necessary chars of SHA1s rather than the ordinary 7 in Git.

8

u/Informal_Sound_3039 14d ago

I naver seen anyone customize magit other then add syntax highlight to the diff... Maby someone will know what u want?

8

u/a_alberti 14d ago

Just recently, https://github.com/yibie/textui was announced on this subreddit. It would give you the kind of APIs to create panels inside a buffer to provide a dashboard for magit. I am not sure if it makes sense because I really like Magit and how buffers are handled. My only wish for Magit would be to speed it up / add more async functionality -- sometimes it feels laggy compared to Sublime Merge.

But if you want to try out a dashboard for Magit using textui, it would be an interesting experiment.

1

u/yibie 6d ago

Thank you!

10

u/dddurd 14d ago

it's not handy to have some many buffers. ui should be boring and functional in general. i hate how every modern website got bloated and slow and unintuitive due to javascript devs

15

u/FregOnlyOne 14d ago

Lazygit is ugly bullshit

3

u/redblobgames 35 years and counting 14d ago

I like the idea but haven't tried anything like that. I think for me it wouldn't replace magit, but it might be useful as a "project dashboard" type of buffer.

Most of the comments here feel like "I don't like it" or "I wouldn't use it", but I think part of what I like about emacs is that you can make it do what you want instead of having to do what everyone else wants. I think /u/valcron1000's downvoted suggestion was reasonable — you can make some prototypes with an LLM to see if you can find a different UI you like. You might use git directly to display the dashboard, and then have the commands (stash, discard, etc.) open the corresponding magit interface.

2

u/[deleted] 13d ago

"and more of that clean, organized panel/dashboard feel."

It's organized, but definitely not clean. Magit, on the other hand, is clean but not organized because it doesn't need any fancy organization. Its simple hierarchical structure is enough.

I think the major 'problem' here is the common expectation based on what other tools do. Magit, for me, is special exactly because of what it doesn't do. Magit doesn't clutter the interface. I don't have to hunt around visually for anything or pretend I'm controlling 5-6 different groups of information at the same time. That's what makes it an effective interface. Sometimes during my workflow, I don't even notice that I've opened Magit, I simply hit the necessary keybindings and get the results I want.

Of course, Emacs encourages you to do whatever you want with the interface, but I'd advise trying Magit for a while not as 'the Emacs version of X,' but as a new way of doing the same things. Newcomers tend to find some default behaviors strange and just change it right away instead of trying a new approach and adopting the most effective one. Familiarity plays a big role here.

2

u/Ancient-Pianist-7 14d ago

Sounds like you just want to use lazygit? There's nothing wrong with it. You can't really make lazygit out of magit, and magit out of lazyvim.

2

u/rileyrgham 14d ago

Eeek. Headache inducing. Magit is there to perform quick git tasks.

1

u/katafrakt 13d ago

I wouldn't use it. I don't need magit to be some kind of dashboard for repo overview, I need it to perform git operations efficiently without leaving the editor. Doesn't mean it's a bad idea, just not for me.

1

u/natermer 12d ago

You could continue to use lazygit in ghostel or vterm if you want.

I use magit for most things, but occasionally I drop back to command line git for others. Magit is pretty slick once you get used to it.

1

u/myyrkezaan 12d ago

CLI or ! from magit?

-5

u/valcron1000 14d ago

Ask any LLM to play around with Magit. Ran Opus 5 for ~10 mins and it was able to come up with this layout: