6 ms·

I've pretty much forgotten how to use git on the command line because of magit :-)

npsimons 13y ago
Seconded, only my addiction of choice is egg, a fork of magit. It's blazingly fast, as well. Not sure what people have to put up with in other IDEs, and quite frankly, I don't care; that's why I use Emacs . . .
- dilap 13y ago
  Is egg faster than magit? I love (well, more like have strong affection for) magit, but blazingly fast it is not.
  - npsimons 13y ago
    Sorry, I should have clarified; AFAIK, egg is not faster than magit, but I haven't really played with magit. My comment on speed was aimed at the article complaining about slow IDEs as git interfaces. When I run emacs, "slow" isn't the word that comes to mind, especially when compared to other IDEs (and I'm talking about with all sorts of IDE-type features added on to emacs). Egg is pretty fast, though.
    - dilap 13y ago
      Ah, gotchya. (I'm also an emacs user/addict, but I would say "slow" is often a word I associate with it, alas...)
      - cbsmith 13y ago
        The only thing I find to be slow is auto-complete mode on our rather large Pythonic code base.
      - mheathr 13y ago
        Fortunately computing hardware is improving at a faster rate than emacs is getting slower, so we are not interacting with molasses.
        astrobe_ 13y ago
        That's not true for me. I'm forced to use older computers and/or virtual machines over overloaded networks. I had to recompile Emacs with -O3 and other optimization switches to get barely decent performance on the latest versions of Emacs. That's why I've switching a lot between Emacs and Vim recently.
        cbsmith 13y ago
        Honestly, I think you need to check your distro's emacs setup. Most of the time the crappy slowness comes from all kinds of badly written elisp modules that you really don't need (which is the wrong way to do it anyway). If you just load the pure emacs image, it's VERY zippy.
        dilap 13y ago
        I'm not so sure; people keep adding stuff to emacs, and performance doesn't really seem to be a priority. To give a couple examples off the top of my head: - A recent version of emacs changed the default shell history command to show live search results (like bash does), but the emacs implementation was ungodly slow if your bash history was longer than a few dozen items (waaay slower than a real terminal interactive bash search). Moreover, it completely locked up emacs while doing the search (since emacs is single-threaded and synchronous). After the suffering got high enough, I finally tracked down how to revert to the old behavior. - The latest emacs python mode for some unknown reason would freeze for like 10 seconds when opening certain python files. Rather than track it down, I went back to using the latest python-people python mode (for some reason, the emacs people insist on writing their own python mode, rather than using the one the python people wrote). The python-people python mode doesn't lock up, but narrow-to-defun takes maybe 300ms (not terrible, but clunky feeling; way worse than instant), for some reason. - Or check out this awesome, high-performance code from the function comint-exec: ;; Feed it the startfile. (cond (startfile ;;This is guaranteed to wait long enough ;;but has bad results if the comint does not prompt at all ;; (while (= size (buffer-size)) ;; (sleep-for 1)) ;;I hope 1 second is enough! (sleep-for 1) (goto-char (point-max)) (insert-file-contents startfile) See that sleep-for? That's an awesome built 1-second pause while waiting, for example, for an emacs shell to startup if you have a custom .emacs_bash defined. There's lots more stuff like this. Emacs is a giant ball of elisp mud that's perpetually half-broken, half-implemented, or slow...but it's still the best thing going, by more flexible and more useful than any other editor out there (AFAIK). But I'm not convinced it isn't possible to do something as flexible as emacs without all the random breakage and general lack of concern for performance. Think maybe replace elisp with LuaJIT, and take cultural inspiration from the make-it-fast ethos of git and the make-it-correct ethos of sqlite. Something like that. Oh, and also, unlike every modern day attempt at an editor, it should still support running in a terminal, because terminals are still damn useful. So yeah, could someone get on that please? Thanks :)
  - Myrmornis 13y ago
    Agree. I apply a commit that hacks magit-status to show only the essentials and thus be a bit faster (I believe; haven't timed it recently) https://github.com/dandavison/magit/commit/a969463ff30e5e2480a019c5274364470cdc7651 https://github.com/dandavison/magit/commit/a969463ff30e5e248...

Seconded, only my addiction of choice is egg, a fork of magit. It's blazingly fast, as well. Not sure what people have to put up with in other IDEs, and quite frankly, I don't care; that's why I use Emacs . . .

dilap 13y ago
Is egg faster than magit? I love (well, more like have strong affection for) magit, but blazingly fast it is not.
- npsimons 13y ago
  Sorry, I should have clarified; AFAIK, egg is not faster than magit, but I haven't really played with magit. My comment on speed was aimed at the article complaining about slow IDEs as git interfaces. When I run emacs, "slow" isn't the word that comes to mind, especially when compared to other IDEs (and I'm talking about with all sorts of IDE-type features added on to emacs). Egg is pretty fast, though.
  - dilap 13y ago
    Ah, gotchya. (I'm also an emacs user/addict, but I would say "slow" is often a word I associate with it, alas...)
    - cbsmith 13y ago
      The only thing I find to be slow is auto-complete mode on our rather large Pythonic code base.
    - mheathr 13y ago
      Fortunately computing hardware is improving at a faster rate than emacs is getting slower, so we are not interacting with molasses.
      - astrobe_ 13y ago
        That's not true for me. I'm forced to use older computers and/or virtual machines over overloaded networks. I had to recompile Emacs with -O3 and other optimization switches to get barely decent performance on the latest versions of Emacs. That's why I've switching a lot between Emacs and Vim recently.
        cbsmith 13y ago
        Honestly, I think you need to check your distro's emacs setup. Most of the time the crappy slowness comes from all kinds of badly written elisp modules that you really don't need (which is the wrong way to do it anyway). If you just load the pure emacs image, it's VERY zippy.
      - dilap 13y ago
        I'm not so sure; people keep adding stuff to emacs, and performance doesn't really seem to be a priority. To give a couple examples off the top of my head: - A recent version of emacs changed the default shell history command to show live search results (like bash does), but the emacs implementation was ungodly slow if your bash history was longer than a few dozen items (waaay slower than a real terminal interactive bash search). Moreover, it completely locked up emacs while doing the search (since emacs is single-threaded and synchronous). After the suffering got high enough, I finally tracked down how to revert to the old behavior. - The latest emacs python mode for some unknown reason would freeze for like 10 seconds when opening certain python files. Rather than track it down, I went back to using the latest python-people python mode (for some reason, the emacs people insist on writing their own python mode, rather than using the one the python people wrote). The python-people python mode doesn't lock up, but narrow-to-defun takes maybe 300ms (not terrible, but clunky feeling; way worse than instant), for some reason. - Or check out this awesome, high-performance code from the function comint-exec: ;; Feed it the startfile. (cond (startfile ;;This is guaranteed to wait long enough ;;but has bad results if the comint does not prompt at all ;; (while (= size (buffer-size)) ;; (sleep-for 1)) ;;I hope 1 second is enough! (sleep-for 1) (goto-char (point-max)) (insert-file-contents startfile) See that sleep-for? That's an awesome built 1-second pause while waiting, for example, for an emacs shell to startup if you have a custom .emacs_bash defined. There's lots more stuff like this. Emacs is a giant ball of elisp mud that's perpetually half-broken, half-implemented, or slow...but it's still the best thing going, by more flexible and more useful than any other editor out there (AFAIK). But I'm not convinced it isn't possible to do something as flexible as emacs without all the random breakage and general lack of concern for performance. Think maybe replace elisp with LuaJIT, and take cultural inspiration from the make-it-fast ethos of git and the make-it-correct ethos of sqlite. Something like that. Oh, and also, unlike every modern day attempt at an editor, it should still support running in a terminal, because terminals are still damn useful. So yeah, could someone get on that please? Thanks :)
- Myrmornis 13y ago
  Agree. I apply a commit that hacks magit-status to show only the essentials and thus be a bit faster (I believe; haven't timed it recently) https://github.com/dandavison/magit/commit/a969463ff30e5e2480a019c5274364470cdc7651 https://github.com/dandavison/magit/commit/a969463ff30e5e248...