9 ms·

I've used Emacs for almost 5 years now and it has served me well. In the beginning it was frustrating and confusing, but now that I understand it, it's the way

I've used Emacs for almost 5 years now and it has served me well. In the beginning it was frustrating and confusing, but now that I understand it, it's the way I naturally interact with code on my computer. The fact that so many gnu tools have movement similar to Emacs means that I can quickly become more effective in them. The fact that my work Macbook allows me to do some rudimentary movement with C-a, C-e, C-f, C-n brings me joy. Emacs rewards me for learning it better, and when I think about what it does, and is capable of doing, I'm just in awe. I highly recommend reading Mastering Emacs if you would like to become a more effective Emacs user. After using it for years I can say my single biggest gripe with Emacs is its performance. Elisp is powerful but slow, and has many warts. The developments with GccEmacs excites me, and there is still GuileMacs. As a more experienced user Emacs frustrates me because at times I demand too much of it. And when that happens, I try to temper that frustration with the understanding that the program is 36 years and 5 days old to the day, and has outlived many other pieces of software. Computers looked different in 85 than they did today, and the fact that I have saved truly days of programming time due how effective it makes me cannot be overlooked. I want Emacs to continue to improve. I want it to get even better than it already is, but I am so grateful for the people who have made it what it is today.

tharne 6y ago
I prefer vim as an editor, but in terms of being a unique and fascinating piece of software, emacs wins hands down. There's something really cool about the fact that you can't easily answer the question, "What is emacs similar to?", because it's such a total sui generis.
- prewett 6y ago
  Viper mode could give you the best of both worlds, depending on what you like about vim. If it's the key navigation, viper has you covered.
  - NyxWulf 6y ago
    spacemacs has a very complete vim layer. By far it's the most complete implementation outside of actual vim I've seen.
    - dfinninger 6y ago
      Spacemacs uses “Evil mode”[1], which is available just as a regular (MELPA) package. I started with Vim and so I’ve always used evil. “Vanilla” emacs, spacemacs, now doom. [1] https://github.com/emacs-evil/evil https://github.com/emacs-evil/evil
      - iterati 6y ago
        I'm curious if you've already used evil with vanilla why you'd migrate to spacemacs or doom. I've never found either to add much that a custom config can't get to easily and with more control. Maybe that's changed in the past half-decade or so since I last tried Spacemacs, though.
        vvillena 6y ago
        The vim bindings are only one part of Spacemacs. The other (and I'd say most important) part is the SPC menu that exposes hundreds of keybindings in a discoverable, unobtrusive, and interactive interface.
        Klwohu 6y ago
        Isn't that also just an elpa / melpa package though?
        vvillena 6y ago
        I guess so? And if the aim is to make something completely custom, that's fine. But the Spacemacs keybindings are very well thought out, the configuration is just as important as the feature itself.
        NoThisIsMe 6y ago
  - monsieurbanana 6y ago
    Hearing about Viper reminds me about the times where I was just starting to use Emacs, about 10 years ago! Fond memories :) Since then, Evil-mode has effectively superseded it. I wish I had learnt vim-like editing a long time ago, as Vim-bindings seem to be mostly well-maintained in every editor. Emacs-bindings are also in most editors, but it's not as useful since people (most people? in any case, me) usually customize the default shortcuts quite a bit. And less manpower to maintain them.
- luismbo 6y ago
  It's similar to a Lisp Machine.
  - agumonkey 6y ago
    Based on a few old mailing list it's apparently only very slightly so, and i'm not dissing emacs, it's just that the people who made lisp os and it's graphical layer really did allow users to augment and interact with most of the system in a very fluid and capable manner. Some examples from that mailing list (thread from the 90s or maybe even 80s) were still not present on a daily basis for code edition / versionning in the 2000s. Makes you wonder
- ashton314 6y ago
  As mentioned under another reply, take a look at evil-mode. Near-perfect vim compatibility as far as I can tell. Best of both worlds in my opinion!
taeric 6y ago
I'm curious what sort of performance you are hit by. For me, it is mainly org source buffers that I did not flag as async. That and tramp not working too well over crappy internet. :(
- throwanem 6y ago
  Tramp works a lot more reliably if you customize where Emacs puts your backups and autosaves, such that they're stored locally instead of remotely. The Emacs wiki has details on how to do that: https://www.emacswiki.org/emacs/BackupDirectory https://www.emacswiki.org/emacs/BackupDirectory
  - taeric 6y ago
    I can't and don't blame tramp, per se. My internet has regular hiccups of being completely disconnected. Pretty sure that is not fixable. :(
    - throwanem 6y ago
      Not by Emacs, but locally storing backups and autosaves means it only matters when you're actively reading or writing a file via Tramp.
      - taeric 6y ago
        Absolutely. It just sucks, as my build are so much faster on the remote machine. :) That is, a lot of my remote editing is not just idle edits, but edit, run build, burn down compile output of tests and other items I'm working. If I really want hell, I'll try and run lsp remotely. None of this would matter, if I hadn't built up so much muscle memory from when I did have good internet and it did just transparently work.
  - tsimionescu 6y ago
    The biggest problem I have with Tramp performance is much deeper, the need to open a new connection for every request - it makes integrating other modes with Tramp much more difficult than I would hope for (e.g. I tried to make kubernetes-mode work over tramp, and it mostly did, but each refresh had to reconnect, which would freeze the whole Emacs GUI for a second or so; thankfully kubel-mode has a more complete implementation that handles this gracefully).
anaerobicover 6y ago
On the performance/stability of Elisp front, I just heard about remacs, which is a fork that's starting by porting all the C to Rust: https://github.com/remacs/remacs https://github.com/remacs/remacs Still in early stages, but I think that's one to keep an eye on.
- jsilence 6y ago
  Most recent change is 7 months ago. I would not hold my breath.
  - deleted 6y ago
    [deleted]
- tsimionescu 6y ago
  I'd be much more interested in one of the CL rewrites, which could (1) run all of the elisp as efficient compiled Common Lisp, and (2) extend the customizability ot the deepest layers of Emacs. Unfortunately, most seem to be relatively dead from what I've seen.
- foobarbaz33 6y ago
  The rust re-write is not intended to bring performance benefits. Currently the Rust version is a massive downgrade in performance relative to the C nativecomp branch.
TeMPOraL 6y ago
Definitely go for GccEmacs (feature/native-comp) branch if you haven't yet. Despite being experimental, it's pretty much stable. I've been running it for over half a year as a daily driver, and seen zero issues (but much performance improvements!). Similar stories abound on-line. Wish something be done about proper threading support, but I understand it's a herculean task at this point. (For those unfamiliar, GccEmacs is a parallel branch of Emacs that uses libgccjit to compile ELisp straight to native code. It does it transparently - compiling in the background and then substituting bytecode-compiled functions for native-compiled.)
- chriswarbo 6y ago
  > Wish something be done about proper threading support, but I understand it's a herculean task at this point. I would agree about adding concurrency and parallelism; but threading is very much a WorseIsBetter approach, which I certainly wouldn't like to use directly. Co-routines or futures would seem a better fit for Lispy semantics. Actors seem too different and heavyweight, but I'd still prefer them to threading!
  - taeric 6y ago
    I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible. What is the aim?
    - TeMPOraL 6y ago
      Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.
      - taeric 6y ago
        I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good benchmarks for emacs to look at and play with?
Smithalicious 6y ago
I use pre-release Emacs with the nativecomp branch ("gccemacs") and Doom. Starts in 2.1 seconds and it's blazing fast. Definitely the best thing to come to Emacs for me in a long time, very exciting. I can't wait for it to hit release so everybody can play with it!
- wiz21c 6y ago
  I have built gccemacs a week ago. I didn't see much difference in speed and it breaks wanderlust... Are there things to know to get the speed (and yes, I've checked it was enabled during ./configure :-)) ?
- whobar 6y ago
  Any warts when using it with Doom? I only recently switched from vim to Doom, and I love it, but it can be a bit laggy when using it with some of the C/C++ IDE features turned on.
  - Smithalicious 6y ago
    It works very well with Doom, Doom has support for it and detects it's available and does everything for you. Just compile Emacs and run doom upgrade as usual.
- newusertoday 6y ago
  are binaries available somewhere, i tried compiling it about year ago but quit after struggling with few dependencies.
agumonkey 6y ago
gccemacs works remarkably fine for such a big change, it does bite my poor x201 hard on the compiling phase (we're now as modern as lein clojure bootstrap :cough:) but it does bring speed improvements already.
davidw 6y ago
Going on 25 years with Emacs. Lots of other things I've changed over the years, but still happy with Emacs and Postgres.
- lovelyviking 6y ago
  I wish to use Emacs, but those keyboard shortcuts do not make any sense for me. Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest. I do not mind keyboard shortcuts in gneeral and use them all the time, it's just those in Emacs are hard to learn/remember knowing that I wish to change them anyway . I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it and thus it blocks me from moving forward with exploring Emacs deeper.
  - TacticalCoder 6y ago
    > Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest. I've got a very custom Emacs keybindings/shortcuts setup but... Sadly it requires some hackery: basically there's the whole major/minor modes shenanigan where one mode's shortcut can take precedence over the other(s). And if you want to define your own shortcuts which take precedence, all the time, over everything else, you need to dig a bit deep. And then even deeper because invariably there's this or that minor mode you'll want to use where after all you won't want your own shortcut but that one of the mode. > I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it Sadly this is true. I've got I'd say about 100 lines of code related only to keybindings. Now, once set up, it's pure bliss. For example I've got mod+{i,j,k,l} to move the cursor around, anywhere (text, menus, anything). It makes even more sense than vim's hjkl (ijkl mimics the cursor arrow keys layout, which is more natural and ijkl is easier to type than hjkl too). > ... and thus it blocks me from moving forward with exploring Emacs deeper. I can understand that. I'd say the easiest would be to define your own minor mode as explained here: https://stackoverflow.com/questions/683425/globally-override-key-binding-in-emacs https://stackoverflow.com/questions/683425/globally-override... This should get you started: if you do it like in the answer and make sure they always take precedence you should be good to go and can deal with the gory details later on.

tharne 6y ago

I prefer vim as an editor, but in terms of being a unique and fascinating piece of software, emacs wins hands down. There's something really cool about the fact that you can't easily answer the question, "What is emacs similar to?", because it's such a total sui generis.

prewett 6y ago
Viper mode could give you the best of both worlds, depending on what you like about vim. If it's the key navigation, viper has you covered.
- NyxWulf 6y ago
  spacemacs has a very complete vim layer. By far it's the most complete implementation outside of actual vim I've seen.
  - dfinninger 6y ago
    Spacemacs uses “Evil mode”[1], which is available just as a regular (MELPA) package. I started with Vim and so I’ve always used evil. “Vanilla” emacs, spacemacs, now doom. [1] https://github.com/emacs-evil/evil https://github.com/emacs-evil/evil
    - iterati 6y ago
      I'm curious if you've already used evil with vanilla why you'd migrate to spacemacs or doom. I've never found either to add much that a custom config can't get to easily and with more control. Maybe that's changed in the past half-decade or so since I last tried Spacemacs, though.
      - vvillena 6y ago
        The vim bindings are only one part of Spacemacs. The other (and I'd say most important) part is the SPC menu that exposes hundreds of keybindings in a discoverable, unobtrusive, and interactive interface.
        Klwohu 6y ago
        Isn't that also just an elpa / melpa package though?
        vvillena 6y ago
        I guess so? And if the aim is to make something completely custom, that's fine. But the Spacemacs keybindings are very well thought out, the configuration is just as important as the feature itself.
        NoThisIsMe 6y ago
- monsieurbanana 6y ago
  Hearing about Viper reminds me about the times where I was just starting to use Emacs, about 10 years ago! Fond memories :) Since then, Evil-mode has effectively superseded it. I wish I had learnt vim-like editing a long time ago, as Vim-bindings seem to be mostly well-maintained in every editor. Emacs-bindings are also in most editors, but it's not as useful since people (most people? in any case, me) usually customize the default shortcuts quite a bit. And less manpower to maintain them.
luismbo 6y ago
It's similar to a Lisp Machine.
- agumonkey 6y ago
  Based on a few old mailing list it's apparently only very slightly so, and i'm not dissing emacs, it's just that the people who made lisp os and it's graphical layer really did allow users to augment and interact with most of the system in a very fluid and capable manner. Some examples from that mailing list (thread from the 90s or maybe even 80s) were still not present on a daily basis for code edition / versionning in the 2000s. Makes you wonder
ashton314 6y ago
As mentioned under another reply, take a look at evil-mode. Near-perfect vim compatibility as far as I can tell. Best of both worlds in my opinion!

taeric 6y ago

I'm curious what sort of performance you are hit by. For me, it is mainly org source buffers that I did not flag as async. That and tramp not working too well over crappy internet. :(

throwanem 6y ago
Tramp works a lot more reliably if you customize where Emacs puts your backups and autosaves, such that they're stored locally instead of remotely. The Emacs wiki has details on how to do that: https://www.emacswiki.org/emacs/BackupDirectory https://www.emacswiki.org/emacs/BackupDirectory
- taeric 6y ago
  I can't and don't blame tramp, per se. My internet has regular hiccups of being completely disconnected. Pretty sure that is not fixable. :(
  - throwanem 6y ago
    Not by Emacs, but locally storing backups and autosaves means it only matters when you're actively reading or writing a file via Tramp.
    - taeric 6y ago
      Absolutely. It just sucks, as my build are so much faster on the remote machine. :) That is, a lot of my remote editing is not just idle edits, but edit, run build, burn down compile output of tests and other items I'm working. If I really want hell, I'll try and run lsp remotely. None of this would matter, if I hadn't built up so much muscle memory from when I did have good internet and it did just transparently work.
- tsimionescu 6y ago
  The biggest problem I have with Tramp performance is much deeper, the need to open a new connection for every request - it makes integrating other modes with Tramp much more difficult than I would hope for (e.g. I tried to make kubernetes-mode work over tramp, and it mostly did, but each refresh had to reconnect, which would freeze the whole Emacs GUI for a second or so; thankfully kubel-mode has a more complete implementation that handles this gracefully).

anaerobicover 6y ago

On the performance/stability of Elisp front, I just heard about remacs, which is a fork that's starting by porting all the C to Rust: https://github.com/remacs/remacs https://github.com/remacs/remacs Still in early stages, but I think that's one to keep an eye on.

jsilence 6y ago
Most recent change is 7 months ago. I would not hold my breath.
- deleted 6y ago
  [deleted]
tsimionescu 6y ago
I'd be much more interested in one of the CL rewrites, which could (1) run all of the elisp as efficient compiled Common Lisp, and (2) extend the customizability ot the deepest layers of Emacs. Unfortunately, most seem to be relatively dead from what I've seen.
foobarbaz33 6y ago
The rust re-write is not intended to bring performance benefits. Currently the Rust version is a massive downgrade in performance relative to the C nativecomp branch.

TeMPOraL 6y ago

Definitely go for GccEmacs (feature/native-comp) branch if you haven't yet. Despite being experimental, it's pretty much stable. I've been running it for over half a year as a daily driver, and seen zero issues (but much performance improvements!). Similar stories abound on-line. Wish something be done about proper threading support, but I understand it's a herculean task at this point. (For those unfamiliar, GccEmacs is a parallel branch of Emacs that uses libgccjit to compile ELisp straight to native code. It does it transparently - compiling in the background and then substituting bytecode-compiled functions for native-compiled.)

chriswarbo 6y ago
> Wish something be done about proper threading support, but I understand it's a herculean task at this point. I would agree about adding concurrency and parallelism; but threading is very much a WorseIsBetter approach, which I certainly wouldn't like to use directly. Co-routines or futures would seem a better fit for Lispy semantics. Actors seem too different and heavyweight, but I'd still prefer them to threading!
- taeric 6y ago
  I'm actually somewhat unclear in what the goals of threading are, at times. Pushing a process out and having a sentinel on a buffer has long been possible. What is the aim?
  - TeMPOraL 6y ago
    Make it more light-weight and do it without needing a foreign binary. If your elisp program needs to offload some computations to a background thread, you don't want to make a binary specifically for it - it would destroy the flexibility and portability of otherwise perfectly fine elisp code.
    - taeric 6y ago
      I mean, I get this in principal. I'm curious in practice. How many things aren't already waiting on another foreign process that take time? Edit: I could see some things like syntax highlighting being a benefit. Though, I somewhat expect those to already be moving to lsp tricks. Layout, in general, makes sense to be a bit more responsive. But I'm not clear how general threading helps with that. Edit2: are there good benchmarks for emacs to look at and play with?

Smithalicious 6y ago

I use pre-release Emacs with the nativecomp branch ("gccemacs") and Doom. Starts in 2.1 seconds and it's blazing fast. Definitely the best thing to come to Emacs for me in a long time, very exciting. I can't wait for it to hit release so everybody can play with it!

wiz21c 6y ago
I have built gccemacs a week ago. I didn't see much difference in speed and it breaks wanderlust... Are there things to know to get the speed (and yes, I've checked it was enabled during ./configure :-)) ?
whobar 6y ago
Any warts when using it with Doom? I only recently switched from vim to Doom, and I love it, but it can be a bit laggy when using it with some of the C/C++ IDE features turned on.
- Smithalicious 6y ago
  It works very well with Doom, Doom has support for it and detects it's available and does everything for you. Just compile Emacs and run doom upgrade as usual.
newusertoday 6y ago
are binaries available somewhere, i tried compiling it about year ago but quit after struggling with few dependencies.

agumonkey 6y ago

gccemacs works remarkably fine for such a big change, it does bite my poor x201 hard on the compiling phase (we're now as modern as lein clojure bootstrap :cough:) but it does bring speed improvements already.

davidw 6y ago

Going on 25 years with Emacs. Lots of other things I've changed over the years, but still happy with Emacs and Postgres.

lovelyviking 6y ago
I wish to use Emacs, but those keyboard shortcuts do not make any sense for me. Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest. I do not mind keyboard shortcuts in gneeral and use them all the time, it's just those in Emacs are hard to learn/remember knowing that I wish to change them anyway . I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it and thus it blocks me from moving forward with exploring Emacs deeper.
- TacticalCoder 6y ago
  > Is there a way to have emacs with custom shortcuts as a ready package where I can modify those shortcuts before digging in with all the rest. I've got a very custom Emacs keybindings/shortcuts setup but... Sadly it requires some hackery: basically there's the whole major/minor modes shenanigan where one mode's shortcut can take precedence over the other(s). And if you want to define your own shortcuts which take precedence, all the time, over everything else, you need to dig a bit deep. And then even deeper because invariably there's this or that minor mode you'll want to use where after all you won't want your own shortcut but that one of the mode. > I am looking for the way to set those by myself but it seems I need to learn a lot before I can do it Sadly this is true. I've got I'd say about 100 lines of code related only to keybindings. Now, once set up, it's pure bliss. For example I've got mod+{i,j,k,l} to move the cursor around, anywhere (text, menus, anything). It makes even more sense than vim's hjkl (ijkl mimics the cursor arrow keys layout, which is more natural and ijkl is easier to type than hjkl too). > ... and thus it blocks me from moving forward with exploring Emacs deeper. I can understand that. I'd say the easiest would be to define your own minor mode as explained here: https://stackoverflow.com/questions/683425/globally-override-key-binding-in-emacs https://stackoverflow.com/questions/683425/globally-override... This should get you started: if you do it like in the answer and make sure they always take precedence you should be good to go and can deal with the gory details later on.