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

Rebasing in Magit

entropicthoughts.com

Post reply on HN
Print view View original

41–50 of 144 posts

Re: Rebasing in Magit

#41

Post by 8s2ngy »

jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.

Re: Rebasing in Magit

#42

Post by dietr1ch »

jonpalmisc wrote: post #30
ishouldbework wrote: post #25

Earlier quoted context omitted.

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

> having a globally shared buffer state, etc. is an anti-feature

Yeah, it feels a bit weird to not have some isolation.

Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default).

[^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...

Re: Rebasing in Magit

#43

Post by chriswarbo »

jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

Emacs can certainly be sluggish, but I'm not sure how much that's e.g. inherent to ELisp, or due to synchronous/single-threaded code, or choosing slow algorithms for certain tasks, etc.

For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect.

Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!

Re: Rebasing in Magit

#44

Post by smitty1e »

jonpalmisc wrote: post #30
ishouldbework wrote: post #25

Earlier quoted context omitted.

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

> I think having a globally shared buffer state, etc. is an antifeature.

Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application.

Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?

Re: Rebasing in Magit

#45

Post by School-Cotton »

8s2ngy wrote: post #41
jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

I share your wish. Emacs, as wonderful as it is, has accumulated a lot of cruft over the decades and would benefit immensely from a rewrite. A "Neo-Emacs" could be multithreaded from the ground up and drop support for archaic platforms. The rewrite could even be in Rust to attract younger developers.

There would be no point to writing emacs in a language that can’t be developed interactively in a repl. Emacs being written in lisp is an essential quality.

Re: Rebasing in Magit

#46

Post by chriswarbo »

jonpalmisc wrote: post #30
ishouldbework wrote: post #25

Earlier quoted context omitted.

While faster Emacs would always be nice, I think the idea is you just keep it running. Hence emacsclient program. So startup time is not such a big deal.

Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow. Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

> I think having a globally shared buffer state, etc. is an antifeature.

As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of.

It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)

Re: Rebasing in Magit

#47

Post by BigTTYGothGF »

jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

I'm not sure I'm capable of noticing or caring about the difference between 0.18 and 0.02 seconds for something that doesn't happen on a rapid cadence.

Re: Rebasing in Magit

#48

Post by jwr »

Magit is absolutely wonderful. It is one of the main tools I use daily to get my work done, especially now that AI does a lot of the work for me. I spend a lot of my time in magit looking at diffs!

I would encourage anyone who relies on magit to sponsor tarsius to make his fantastic work sustainable.

Re: Rebasing in Magit

#49

Post by spudlyo »

jonpalmisc wrote: post #13

Tangential, but I really wish there would be a performance renaissance with Emacs. Native-comp was a good step forward, but Emacs is still so much slower than Neovim, even in the case of launching and immediately quitting, with no config: $ time emacs -Q -e kill-emacs /Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q -e kill-emacs 0.18s user 0.03s system 98% cpu 0.213 total $ time nvim -es --cmd 'vim.cmd("q")' nvim…

On my M1 Mac Pro I get 0.13s wall, so not much faster than your Mac. On my i9-9900K Linux box I get 0.04s. I would think my M1 single core performance would be on par, if not faster. Perhaps it has something to do with macOS and gatekeeper, as I notice I'm not getting as high of a CPU utilization.

    $ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))'
    30.2
    0.07user 0.03system 0:00.13elapsed 78%CPU (0avgtext+0avgdata 46064maxresident)k

    $ /usr/bin/time ~/bin/emacs --batch -eval '(princ (format "%s\n" emacs-version))'
    30.2
    0.02user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 57728maxresident)k

Re: Rebasing in Magit

#50

Post by jwr »

mschulze wrote: post #2

I use magit daily for over 8 years now. Over that time I have showed it to many other peers, out of excitement for a tool that made me more productive and helped me learn - but I never could convince even one to use it. Maybe it's my persuasion skills, maybe tool usage is too personal - I don't know, but it makes me kind of sad. The UX of magit is just out of this world. Especially for rebasing, subset rebases (using…

> I never could convince even one to use it

Most people think it's "just another interface on top of git" — without several in-depth examples it's difficult to realize that it actually allows you to complete really complex tasks quickly. I've seen this superficial take many times.

Post reply on HN