Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Magit 3.0

emacsair.me

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Magit 3.0

#61

Post by taeric »

darthrupert wrote: post #53
taeric wrote: post #41

Earlier quoted context omitted.

Fwiw, I'm not seeing lag on my end doing the same. Can turn on magit blame and it still scrolls fine. :( Opening a very large file? Edit: I have found that if I don't reboot my Mac, the environment that a launcher emacs finds is sometimes off. Is it the same slow if you launch from a terminal versus the dock?

No, not very large. I'm using Doom with pretty much default settings. Perhaps there's something heavy there.

I don't think anyone really wants to profile their editor. That said, if you have the cycles to spare, M-x profiler-start, scroll, M-x profiler-stop may have some obvious culprit.

Re: Magit 3.0

#63

Post by nvarsj »

darthrupert wrote: post #38
TacticalCoder wrote: post #20

Earlier quoted context omitted.

I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit). It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To…

Perhaps this is about MacOS vs Linux. I'm also suffering from slow emacs on mac, and no combination of flags seems to help. Use case: open a yaml file with syntax highlightning, scroll it with the mouse. The latency should be as low as possible.

It's most likely a Mac thing. And is probably the main reason I gave up on OS X as a serious work OS, since I'm so dependent on Emacs (org-mode in particular). I hope it gets sorted one day. Apparently it has to do with certain system calls on OS X just being very slow.

Re: Magit 3.0

#64

Post by nvarsj »

olau wrote: post #54
aidenn0 wrote: post #5

I haven't tried very hard yet, but magic has been fairly unintuitive for me. Perhaps it's just that I've been using git for so long. There have been several times that I tried something with magit, and messed things up enough that I just dropped into a shell and did everything with the git command line

Magit is not terribly intuitive. It looks a bit like a menu-based GUI, so you'd expect to navigate around and use a standard set of keys, but most of it is actually powered by special key combinations. Now, in some circumstances, that works fine, but honestly the interface could be simplified a bit and probably made faster to use. And less prone to the "oh shit, I thought I was typing something but now I actually hit…

There's definitely some aspects of it which I struggle with. Like cherry picking a commit always feels somewhat painful, and I can never remember offhand the exact menus and keys to press to do it. But for day to day development, it's fast and great. I love having the separation between the push branch and merge branches for example, which feels very natural in a PR workflow. And the forge integration is brilliant.

Re: Magit 3.0

#65

Post by lambdaba »

Steltek wrote: post #37
zelphirkalt wrote: post #33

Looking forward to using the new release. "git at the speed of thought" describes magit quite well. Actually sometimes magit nudged me into the direction of looking up some more special git commands, to learn about them and then making use of magit's interface to them, often simply pressing one button more. Magit has not made me forget how command line git works, because it often shows me right there, what the argume…

Magit has a great mix of direct manipulation of git primitives and good visualization. I think I've learned how git works faster through Magit than I would have from using the CLI. It's really hit a sweet spot for me.

This is what I'd want from any GUI, ability to "view source" and then use in scripting etc.

Re: Magit 3.0

#66

Post by chriswarbo »

aidenn0 wrote: post #5

I haven't tried very hard yet, but magic has been fairly unintuitive for me. Perhaps it's just that I've been using git for so long. There have been several times that I tried something with magit, and messed things up enough that I just dropped into a shell and did everything with the git command line

> I just dropped into a shell and did everything with the git command line

Note that you can run raw git commands by pressing : in any magit buffer. It opens a commandline prepopulated with `git `, so you can type whatever you want afterwards. The output will appear in the relevant `magit-process` buffer.

(The choice of : is analogous to M-: which will execute an Emacs Lisp expression)

Re: Magit 3.0

#67

Post by aidenn0 »

pmoriarty wrote: post #9
aidenn0 wrote: post #5

I haven't tried very hard yet, but magic has been fairly unintuitive for me. Perhaps it's just that I've been using git for so long. There have been several times that I tried something with magit, and messed things up enough that I just dropped into a shell and did everything with the git command line

Do you remember what you tried? Yours has been literally the first negative comment out of hundreds of comments I've read about magit. It'd be interesting to learn what didn't work for you and why.

The first odd thing is that magit runs in emacs' working directory, rather than the directory of the buffer you launch it in (my experience with most emacs commands is that they will take the cwd from the buffer). I'm going to have multiple git repos, and I usually only start emacs once, so this gets me almost every single time.

The submenus are also a bit overwhelming. I just wanted to stash my working tree, not be given dozens of options for how to stash! Emacs already has a way to signal that you want to give an option to a command, so this interface feels very un-emacsy. "M-x magit-stash" should just do the common thing imo. C-u M-- prefix if I want something fancy.

Another time, I fat-fingered a branching operation, and I spent a good five minutes trying to figure out how to fix it within magit, and then gave up and solved it in 30s from the cli

Re: Magit 3.0

#68

Post by aidenn0 »

CJefferson wrote: post #21
pmoriarty wrote: post #9

Earlier quoted context omitted.

Do you remember what you tried? Yours has been literally the first negative comment out of hundreds of comments I've read about magit. It'd be interesting to learn what didn't work for you and why.

I didn't like it, I have several friends who tried it and didn't like it. The main problem (for us) was that people said "Hey, this is so great you should use it even if you don't use emacs". This is (in my opinion) terrible advice, as you need to be a fairly competent emacs users to use magit, else you will keep hitting weird situations you can unable to escape (as you don't know the emacs thing to do).

I use emacs and still struggled with it. The interface is not particularly emacsy.

Re: Magit 3.0

#69

Post by aryamaan »

I never fail to see so many high things about Magit and I believe they are rightly placed.

I am a non Emac user and wonder why no one tries to bring something similar client for non Emac population.

Re: Magit 3.0

#70

Post by spamizbad »

TacticalCoder wrote: post #20
the_duke wrote: post #6

Emacs is too laggy for me as my main editor. But Magit is so good that I start emacs up just to use it as my Git interface if I can't get by just with the CLI. Sadly there is no Vim plugin that is competitive. There is vimagit [1], but it's not on par. [1] https://github.com/jreybert/vimagit

I upvoted you but... How comes Emacs is laggy for you? I'm running a beefy Emacs setup and it is really responsive. If anything Emacs in the nineties was "Eight Megabytes And Constantly Swapping" but... We're in 2021 now and now it's still 8 MB, so it's a rounding error (I'm only exaggerating a bit). It's one my lightest app: starting Emacs, eval'ing some elisp, and exiting takes... 81 ms. Eighty-one milliseconds. To…

Likely an OSX user. Emacs on my 2018 MBP is noticeably slower than my 2016 Dell XPS running Linux - despite the MBP having more ram, more clocks, and more cores.
Post reply on HN