I have been using GNU Emacs since the late 1980s. It has been my life's editor, so to speak. At 59 1/2, it seems unlikely that I will ever switch to another editor. It's served me well. I am grateful to the hackers that created it.
I only just understood Emacs about a year ago, despite being a nerd for at least 30 years. I like to think I don't have too many regrets in life - but I'm kicking myself for not realizing what Emacs was way back then - or at any of the times I've tried it out in the past (writing it off as "a text editor")!
Never too late though, and on the plus side I've now got decades of hidden Emacs goodies still to discover!
I am excited for you but that "journey of discovery" is way, way too addictive for me. I find myself chasing edge case requirements in my config rather than getting work done.
To each thier own, of course!
I still use Emacs when I ssh into my vps and, if I want primarily on Windows doing dev if Visual Studio, would likely use it for everything (as I did back when I was primarily on UNIX systems). Just writing this makes me think "maybe I'll install it on Windows on more time".
The core issue for me is context switching between Emacs and VS. Even with various keybinding tricks it is always awkward.
Best of luck on your journey with Emacs. Do it for me! :)
I setup the VS Emacs bindings and then always bind C-X C-E to open current file/line in Emacs from VS. With that I get along pretty well combining VS and Emacs.
Are you using one of the VS Emacs bindings available in the library or a custom one? I've found all of the most popular ones to not be good enough to use VS like Emacs in Windows.
The MS provided Emacs Emulation. You have to jump through some hoops to update it for 2017. It's not perfect, but it gets me close enough until I need to open in Emacs.
+1. I recall thinking it was a text editor with inferior key bindings to vim, and with a bunch of unnecessary weirdness.
I'm glad I took the time to investigate this discoverable interactive programmatic keyboard-oriented UI platform, that also happens to have a great editor (evil).
I've gone all in, I'm in for life. Emacs has already deprecated at least a dozen apps, web apps, and websites I used to frequent. I'm starting to despise any other software...
...so when does someone teach me the secret handshake?
Not OP, but: e-mail client, calculator, calendar app, TODO list app, terminal app, file browsing app, invoicing app, Jupyer notebooks (org mode can do you better), Git client and - obviously - text editor with syntax highlighting.
Some people even replace their window manager with Emacs (see: EXWM), but I'm not ready for this just yet (I run stumpwm now, which is a tiling WM written in Common Lisp, so it's just another lispy environment with similar levels of live interop).
I'll bite. Name some things you believe are impossible. You may very well be right, but myself I yet haven't found a thing for which I wouldn't prefer Org Mode (except maybe that Github renders .ipynb files nicer than .org).
Org Mode can execute blocks of code in any language you can hook up to Emacs, correctly handling sessions if language supports them. Org Mode document itself can serve as a glue for exchanging data between different runtimes if you're using multiple different languages in a single document. Literate programming capabilities let you include other source blocks or even their results as code. Emacs can display images inline, and has some capability for UI widgets (though I haven't use it in org-mode context). The kind of Jupyter notebooks I've seen in the wild, I can reproduce in Org Mode with ease.
Well, according to my understanding, here are some things I do with Jupyter notebooks that org mode can't match: Dozens of inline interactive plots, including animations, 3d displays, generated SVG, embedded Javascript animations with widgets controlling them, proper formula formatting in code output and prose, etc. Things I have begun work towards include inline display of generated PDFs, and inline drawing widgets (including stylus pressure) that provide data for further computation and 3d display.
Simply not being browser-based means org mode has an incredibly steep uphill battle to even get close - the ecosystems Jupyter can tap into are vast (browser and native, language agnostic), and anything interactive is almost certain to trail behind.
I'm happy to be corrected, but I spent a while researching org mode's capabilities in this area earlier, and everything I found looked more primitive and clunky than what Python and Sage could do as long as 10 years ago.
I concede the point. I'm not aware how one could embed a webview in Emacs buffer, and without this you won't get animated/interactive plots.
My experience with Jupyter was limited to static plots so far (I did plenty of interactive work in ObservableHQ though), and Emacs can handle those well.
What would happen if you embedded say 100 of them in the same document? I think doing it the other way around, Emacs in webkit/browsers, is the only feasible way to do it. I'm sure someone has tried that, but it doesn't seem to be adopted yet.
I moved from Vim work roughly 6 years ago. I think Magit was the most mindblowing discovery I made after the switch. It is much more common now, and there is even a Vim equivalent I hear. I can't imagine using Emacs (or any editor) without Magit.
`org-mode` and `org-agenda` is pretty cool and I wish I could use it, but I just gave up trying to configure and integrate it with my calendar, multiple devices and what not.
`shell-pop` is incredibly basic and useful to pop up terminal at bottom. Trying to get my popup windows to show up where I want them using `popwin` and `shackle` (still WIP, as it's far from perfect).
There is `lsp-mode` for Language Server, which makes the auto-completion and code-browsing far better. I was super surprised by how well `dumb-jump` worked in most cases (I mainly used that for C++).
I usually discover things by looking at random Emacs configuration. IIRC there is a repo on Github which keeps track of popular configuration out there.
When I worked managing a machine learning team I really relied on org-mode to keep myself organized. I didn't have a multiple device problem because I just had org setup on my work laptop.
When I 'retired' a few weeks ago I tried org-mode in a dropbox folder. Works great from my Linux and macOS laptops but iOS is a nuisance: I can read notes from the dropbox app and edit them with Textastic, but this is not 'ready at hand' tooling.
Since I 'retired' I am doing much more of my personal coding in Common Lisp and Haskell which means more Emacs use (although I also have VSCode set up for fantastic Haskell and Python dev experiences).
I need to take another look at Magit. I replaced org-mode with all-in use of G Suite (really enjoying functionality, high productivity, and security, cringing a little on privacy issues).
1. Swap your control and caps lock keys, or if you never use caps lock set it to an additional control key. I think this is useful regardless of whether you use Emacs or not.
It's also a good idea to use opposing hands when using modifier keys. To press control-H, you would use the left control with your left hand, and the H with your right hand. Again, this is true regardless of using Emacs (it applies just the same to typing capital letters with the shift keys).
2. Load Emacs.
3. Press Control-H, then press T. This loads the Emacs tutorial. It should take about 10-15 minutes to run though.
If you use Bash/Zsh or Mac OS, the basic cursor movement in the very first section of the tutorial can also be used in the Bash/Zsh shell, and in many Mac OS textboxes as alternatives to the Home/End/PgUp keys etc.
4. Read the manual section on macros [1]. I don't know so many emacs-level-10-wizard level commands, but making a macro saves me a lot of time and thought at least once a week.
Thank you for the macro suggestion, I just gave it a try and I was surprised that it was so simple and practical as define: F3 keys/text F4 then run: F4
I'm not really crazy about Spacemacs because there's so much happening and I like to slowly build my config over time so I know what each piece does, so I can quickly make changes if there's something causing friction.
I have used Spacemacs for a while (ex vi/vim user). It is a good gateway drug, but it is also buggy and slow.
After a few months, I started to build up my configuration bit by bit with use-package, evil, and general.el. I largely use the same keybindings as Spacemacs, but it's much leaner and faster.
Had the same experience, spacemacs has nice defaults and it's gorgeous, but the lag bothered me so much that I was using vim a lot of time to get things to work.
Changed to a clean configuration and built it slowly, everytime I hit an annoyance I fixed and learned something new, now it works better than spacemacs for my workflow and still is way snappier.
I installed spacemacs a couple of weeks ago. I’m enjoying it but I have to keep switching back to sublime to get things done quickly then switching back when I can afford to take time doing things.
I always think of Emacs (never used it tho) as a Smalltalk system without images and with Lisp instead of Smalltalk as the underlying language.
Every visible and invisible think is inspectable and changable at runtime, yup - pretty cool and I loved it for programming! Not sure whether I want to get on the emacs train tho. I have problems mantaining efficiency either way already... And I favor tools that work without set-up. Then again I am still young enough that learning investments pay off by a huge margin... tough.
Same here. For me it's org-mode that made me commit to it, but I might end up using it for many other things eventually (git, coding, etc.).
I'm mostly okay with code editors coming and going, but the one constant in my life has been project/task management, journalling, and personal information management in the broadest sense.
I just got tired of my tools either turning to shit, being deprecated, or not quite doing what I need them to do. Org Mode has been exactly what I've been looking for, and once I started using it seriously it became the thing I didn't know I wanted.
It's really comforting to me to know that I'll probably be able to use the same tool for the rest of my life, and that I can (and often already do) use it for many other things (Tramp, magit, coding in general).
Emacs has served me well over the years. I have a consistent editing platform throughout the changes of languages and document formats. Saved me lots of time to jump right into new languages or new projects.
Same here. 54 years old. I've used Emacs since James Gosling was still hacking at CMU in the early '80s. Took me some time to finally stop using the Gosmacs key bindings :) 35 years of Emacs use and still going strong and learning new things!
I haven't been using it quite that long, but still... It has served me well for decades, and I expect it to outlive me. How many coders can say they contributed to something like that?
Just bash, the command-line tools one uses from bash, LaTeX, and emacs/vim. I think git will stick around for decades even though its predecessors didn't.
My machines pretty much run Emacs, LaTeX, and Firefox, and everything else is largely window-dressing[0]. (I end up doing most of my command-line stuff from eshell inside of Emacs these days.)
[0] Well, a WM/DE of course, either Stumpwm or Plasma. And pdfpc[1] is really pretty fantastic for showing "Beamer" (pdf) slides. And syncthing for sync'ing between machines.
On Windows, some file managers are in this category. E.g. Far has been around for about 25 years now, and still has a cult-like following, especially in Eastern Europe / ex-USSR.
ImageMagick is another one that has been around for almost 30 years, and is the Swiss army knife of batch image processing on any platform.
Well, you won't really see anybody using the original NC outside of DOS emulation. Midnight Commander and Far are spiritual successors, hence why I'm counting from mid-90s for them, not from mid-80s.
For me, the only software that I have used consistently since that era (~1981 or so) would be UNIX and the C programming language. And to be honest, I don't write that much straight C anymore.
It's a mix of C++, Python and Perl, plus writing documents in LaTeX, Org-Mode, etc. I enjoy programming in Common Lisp, too, but that's something I do mostly for pleasure. GNU Emacs has good support for programming in Common Lisp via SLIME.
My visual acuity varies, so I benefit a lot from software that lets me change the size of the elements on the screen. The typical Mac app allows the user to change the size of the text in the main pane, but everything else is a fixed size. In contrast, all the Electron apps I've tested give the user an easy way to change the size of everything, e.g., all the icons in all the panes.
If I had found a way to change the size of everything on one of the Lua-based editors on the Mac, I probably would've switched years ago to one them. (I don't recall their names.)
If I stay with Emacs it will be because learning how to modify vscode, e.g., by writing my own extension, proved too difficult. (I want my editor to be a general interface to information that is easy for me to modify by writing code.)
You can change size of elements in Emacs too. Hint: 99% of what you're looking at is text, so it boils down to changing font sizes. Emacs already has commands for zooming content in a frame, which work like +/-/0 in a web browser.
Thanks for clarifying something I failed to explain. The relative ease with which I can change the size of most of the elements in Emacs is the reason I didn't switch to, for example, Textmate or to Sublime Text when those editors appeared on my radar.
Emacs, terminal emulators, Plan 9 port, Chrome and apps based on Electron are the only apps on the Mac I have been able to figure out how to change the size of most of the elements of.
"most of": The size of the menu-bar and pop-up menus is fixed in all of those apps when they are running on a Mac, but Apple made the text in them large and legible enough to suit me.
Setting the scaling to a fractional value in System Preferences doesn't count because the result is too blurry. I never obtained a monitor with a horizontal resolution of at least 2560, which is the minimum needed to set the scaling to 2 in System Preferences.
I’ve seen this pop up a lot lately—someone who’s been using Emacs or Vim for years and then sees the “new cool” editor and says they’ll be switching to it.
I have the same question, since someone who’s used Emacs for that long would surely have “seen the light” already. Maybe they’re yak shaving with the config instead of getting work done? That’s one of the few valid complaints I can think of.
I used Emacs for a couple of decades but switched over to VS Code after a couple of days of playing with it. I love Emacs and the concept of infinite configurability. But as it turns out, I don't actually use most of that flexibility. It's more common that I'll install a package, tweak a couple of knobs, and get on with work.
Well, VS Code offers the equivalents of all the Emacs packages that I actually use, and they come with sane defaults. Once I've tweaked the Python module a little bit, I tend to ignore its other options and get back to editing code. And in that code editing environment, I honestly prefer VS Code. The key bindings feel like other modern apps (yay for using the same Mac shortcuts for moving around that every thing else uses). Menus (and their shortcuts) work as expected. I don't have Emacs's beautiful macros, but I do have multi-cursor editing which is beautiful in a different way. It's fast. It looks pretty, with nice easier-to-install themes and icon packages. Basically, VS Code does everything that I ask of Emacs, but in a modern package.
I still love Emacs. I had switched to Sublime Text at one point but came back to the 'Macs because ST wasn't good enough to win me over permanently. And I definitely still love the idea that I can rewrite all of Emacs to make it my own personal slice of editing heaven that is optimized for me and me alone. That's wonderful! But now that there's an excellent, MIT-licensed, well supported alternative that doesn't everything that I want in practice, I'm sold.
But if MS ever loses the plot and ruins VS Code, I'll be back on Emacs in a heartbeat.
VS Code does not come with magit... and that in and of itself is a great reason to use Emacs. (This is coming from a daily Vim user) There really is nothing like Magit even as a plugin for VSC. VSC's scm mode is what I'd consider "barely passible". You can do stuff with it, but it's tiny/ugly/not very friendly. And that GitLens plugin doesn't really help with staging files/hunks etc... it's more meta info about past commits.
That said, I've realized that I don't do that much SCM stuff inside my editor. It's nice to have a beautiful client, but I'm comfortable with the git commandline itself and found myself using it for the tricky stuff, even when I had Magit at my fingertips.
My main editor-integrated workflow involves switching branches, committing, pulling, and other routing stuff that VSC handles just fine. It's definitely no Magit, but it covers 95% of the stuff I do.
I used VSCode for a few years, but never found a way to work with code in semantic units vs. as text. And I like that no matter what language I'm working in, the experience is the same. VSCode plugin editors may or may not (read: wouldn't have) agreed on a set of conventions for working with code independent of the programming language.
I tried that, but it never worked as well for me as it did in Sublime Text, or more recently VS Code.
I get what you mean about Emacs's nearly universal code conventions, but that's an example of something I personally found to be more useful in theory than in practice. While I love the concept, 95% of the time I'm hacking around in Python. The rest of the time is a hodge-podge of shell scripts and the rare C snippet. Maybe a little SQL now and then, or perhaps some JavaScript. When I'm working in something that isn't my usual, I find myself spending much more time reading code than writing it, and in that context I don't get as much benefit from those conventions.
Of course this is all incredibly subjective. If you get a lot of benefit from that, awesome! I can definitely see the appeal. I just don't feel like it makes a whole lot of difference for me.
I admit that I have spent a lot of time adjusting Emacs to my preferences (by writing Emacs Lisp code that gets loaded automatically every time my Emacs starts). I am not particularly unhappy about that fact however and will probably spend a lot of time writing code that runs inside vscode if it becomes my daily driver.
Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.
Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.
I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.
Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.
> f there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI
Emacs does that in X11 because that is (or at least was) the standard behavior for text selection in X11. Emacs is simply conforming to the environment it is running within.
Emacs's Mac (graphical) interface does that, too, which is not conforming to the environment it is running in.
And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)
Emacs was taught to run graphically with X11 first, and presumably operates that way across platforms for a consistent interface irrespective of platform.
Even iTerm supports middle-click paste. Unix people are used to it.
I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa, and Emacs is simply using macOS’ X11 compatibility system.
If you could fix that behavior so that Emacs behaves more like a native Cocoa application, I see no reason that the Emacs maintainers should reject a patch. Emacs has, as far as I can tell, always strived to use as much of a native system’s interface and conventions as possible. Emacs is very big, so it might seem to be a self-contained world of its own, but it’s trying not to be too idiosyncratic.
>I would guess that’s because IIRC, there’s no official support for Emacs to display native windows in Cocoa
You would guess wrong.
(If you install an X server, you can run Emacs on X11 on a Mac, but if you do, the text looks radically different from the text in other Mac apps. ADDED. whereas if you run Emacs directly on Cocoa, the way most Emacs users on Mac do it excepting the ones running Emacs inside a terminal environment, the text looks exactly the same as the text in, e.g., Textmate or Terminal.app.)
Hmm. I would then assume that Emacs has rudimentary rendering support in Cocoa, but is otherwise treating it as a variant of X11, and not the fully different graphical system it presumably is. Emacs still has no full-fledged Cocoa integration. That is still only available in the Aquamacs fork, as far as I know: http://aquamacs.org/
This is true. I hope I did not give a contrary impression? I was, somewhat briefly, aware of some of the complexities of Emacs running under NeXTSTEP (not the text-only Emacs 18 included with NeXTSTEP, but proper Emacs 19 with NeXTSTEP windowing support), but that was (obviously) many years ago, and I don’t claim to remember any of it. And I was certainly not involved in implementing any of it.
It's on a different computer than the one I am using now, so it is going to take me at least a few hours to share it. I will make another reply to your comment when I have it.
Ultimately, VS Code just works. I have bounced between Emacs and VS Code as a long time (many years) Emacs user. Things break less often, the extensions are nice, the extension model of the editor is much more coherent, and JavaScript is just a language I find easier to work with. It is much easier to find JavaScript that already solves some problem I have if I am extending the editor. The Python support is good enough. The extensions are all fine. The integrated terminal is actually quite decent, whereas Emacs integrated terminals have never actually been very good in my opinion. Lots of little things. I still use emacs for some things, but generally... VS Code is also open source so I am not too worried about the longevity of the editor at this point. Those are some things off the top of my head.
Oddly I left vscode for emacs for Tramp. Tramp makes it possible for me to have autocomplete, remote repl, remote debugging out of the box (with the python layer plugins in spacemacs). sshfs + terminal never felt integrated and autocomplete doesn't work from the python environment in the remote machine. That was the moment I thought that the flexibility of emacs is hard to match with text editors having a plugin system. I wonder if something like tramp will ever be written into vscode.
I use emacs `-nw` within tmux, on iterm2/3 on mac. There are several terrible problems with this setup which I've never bothered to lose a weekend to trying to sort out (don't misunderstand me: I have lost weekends to some of these problems, and I'm running out of spare weekends).
mac pbcopy/paste into emacs does strange and horrible things. Mouse and scroll-wheel integration roughly doesn't work at all. The list is long.
I also use terminal tools a lot (data engineering), so the terminal itself (and hence tmux) is an important part of my toolset. Meaning, I can't abandon the terminal. Nor do I want to -- as others have said, I have RSI issues with touchpads and mouse-clicking. Spectacle on Mac (or any actual tiling window manager on linux desktops) helps with that, but if I never had to touch a mouse/trackball again in my life, that would be awesome.
As others have said, I mostly want to use an integrated editor and get on with my job, rather than go down a half-century old rabbit hole of reading SICP just to tweak some editor defaults. Again, don't misunderstand me: learning LISP changed my life, man. But that's not the same as "can I enable rainbow delimiters for protobuf" (As an aside, Little Schemer is a much gentler intro to LISP, and also awesome.)
And since I know we're a community of people who get distracted by the next shiny problem to solve: please don't focus on trying to fix the list of issues I'm describing. That's not the point (and I have no spare weekends).
>Mouse and scroll-wheel integration roughly doesn't work at all.
emacs, when started with the -nw flag, has nothing to do with mouse gestures. The terminal emulator (iterm in your case) sits between you and emacs and does not pass mouse gestures to emacs.
Actually, to be painfully precise, there is a convention, which iterm and emacs might or might not use, by which iterm could conceivably pass the location of single left clicks to the emacs process, but, e.g., mouse drag events and scroll-wheel events never get passed.
So for example when the users drags the mouse, then presses Command-C, `emacs -nw` has no way of knowing the user did that, and if anything got into the system clipboard, that is iterm's doing, not emacs's.
Might I suggest `open Emacs.app` rather than `emacs -nw`?
Except for a GNU or Emacs logo that can be suppressed by setting the variable inhibit-startup-screen to non-nil and except for a tool bar that can be suppressed by evalling `(tool-bar-mode -1)`, the result is indistinguishable from a terminal window to most Mac users, but has mouse and scroll-wheel integration.
To be precise, after `(server-start)` is evalled inside the Emacs.app process, whenever the command line `emacsclient <file name>` runs anywhere, inside or outside the Emacs.app process, the Emacs.app "visits" (opens) <file name>.
I am one of those people who talked about switching from emacs to VS Code. I ended up learning just enough to teach it to my daughter, then stuck with emacs for everything I do myself.
Now that I read about all these younger people switching to emacs I feel even less inclined to "modernize" even though VS Code does look like a nice programmable editor.
I've been using the default keybindings for decades and never had RSI issues. The only time my wrist has started to bother me is when I use some other program that involves a lot of mouse motion.
The first time I ever had wrist issues, they were triggered by emacs and a crappy keyboard. I switched to a split keyboard, and they went away. Unfortunately it was a split keyboard with membrane keys, so the going away was only temporary.
I've since switched to a proper mechanical keyboard and all is fine with the world.
I learned Emacs[0] on a Symbolics "space cadet" keyboard which has all the modifier keys in the lower left corner. Maybe that's why I've never felt any need to move the control key from its lower left location on my Mac keyboard.
[0] Technically Zmacs, but most of the key bindings were the same.
I got painful wrists and hands when using Emacs intensively for coding. Viper mode helped but then I transitioned from development to sysadmin and did far less coding. So switched to vi because it was everywhere when Emacs wasn't.[0]
Now that Emacs is everywhere, I'm looking to going back and using evil-mode. We'll see how it goes. I find the customisation on Emacs far less hacky than vim.
[0] I used to grab tapes(!) from Uni to work and compile from source, on a fairly new / obscure architecture at the time.
For some sysadmin type things, one can use tramp to edit files/open shells on remote machines. One trick is that sshx often works better than ssh. On the other hand it doesn’t work completely flawlessly and can be slightly painful, more so in the transition between using separate terminals and ssh and vi, and using emacs with other things in separate buffers.
I use emacs all the time with all the half bad wrist positions and all and have no RSI. Not even CAPS LOCK -> CTRL trick.
For a MOOC I had to suff.. use Eclipse IDE. I don't like it but I didn't mind its keybindings. The morning after I had very nasty pain in my left hand. So I quickly got back into emacs to heal that rapid onset RSI.
For a long time I was unaffected, until I started using emacs more. This was resolved by switching to an ergonomic keyboard where I put all the modifier keys on the thumbs which resolved this issue (but made single handed typing of eg C-V or single words a bit annoying)
I've done exactly this with similar results. Modifiers on the thumb cluster made a huge difference for me (and I've set up my emacs keybindings to be comfortable on my keyboard as well).
It's helped (but not completely alleviated) my RSI. Absolutely worth the price for me though given that.
*I use a macbook pro, and my thumb is used to hitting CMD-X, CMD-C, CMD-V, s what has happened is that I hit control with my thumb instead of pinky - I curl the thumb in and below my palm.
But I still love default keybindings, and what is lovely, is that many of the navigation keys are system wide on MacOS: ctrl-a, ctrl-e, etc.
Then CMD-C and CMD-V actually also work on emacs, so I sometimes use those too (I use https://emacsformacosx.com)
I have seen a video about someone who hacked up a means to use Emacs via voice control. I may play with something like that myself. I doubt that using Emacs via a keyboard is really my bottleneck, though. So any hacks in that direction may be just for fun.
You could try the Microsoft Comfort Curve 3000 keyboards. They are almost like ordinary keyboards, but the extra curving really helps with Emacs. And they're cheap.
I also have a Kinesis one that I used for some years. Those require some training.
In my opinion, there is no comparison in productivity. Emacs and Vim both beat IntelliJ and VS Code hands down. Anytime you have to reach for the mouse for something you’re wasting time.
Kudos to you. I have tried and failed miserably to learn emacs many times. The switch from vi seems to be really hard but I really like emacs and hope to become a pro user someday.
Emacs has multiple vi emulation modes. I've been using emacs for going on 20 years, using the VIPER package, and I've never bothered to learn the emacs native key binding. Best of both worlds.
For me personally:
- I started out just learning navigation.
How to move around within buffers, how to open multiple buffers and move around between buffers.
Then I learned several built in commands.
Years later I learned clojure, a lisp dialect. After learning it, and then looking back at emacs lisp (elisp), and a light bulb went on for me. You can write any elisp function you want, which has functions to manipulate text within buffers and much more. Using it you can create any kind of specialized editor function you can dream of, and you can call that function with "M-x function-name". If use use the function lots, then you can bind that function to a keystroke. (For example, if you wanted a completely custom function... to delete the current block of code, you could write an elisp function to go to move the point to the blocks beginning brace, set the mark, move to the matching brace, and then delete the region.)
There are several "modes" that define how buffers behave. A clojure mode will know how to highlight code and navigate around parenthesis. Magit-mode knows all kinds of commands for operating a git project, and org-mode knows commands to help facilitate note-taking.
If you can find someone who's mastered emacs to show you around, I think that would be a good start. I was fortunate in the mid-90's that such a person sat with me in a computer lab and showed me how much more powerful emacs was than I'd understood till that point.
For me it's been helpful to sometimes take some time, look at the key bindings for a particular mode, and practice them. With some periodic investment in committing them to memory, I think your Emacs productivity will improve.
For me, I knew touch typing (not a master but enough to not see the keyboard while typing), that combined with little experience in vim bindings (basic navigation hjkl, v) etc was enough to become really comfortable with spacemacs. Spacemacs's mnemonic bindings will make it easy for you to start having a muscle memory of bindings to do stuff like opening file tree, moving between windows, switching layouts, killing buffers (all essential for a good workflow in emacs).
Fellow n00b here, but maybe a little further along in my emacs journey.
I started with Emacs as my first editor when I first was learning how to code a few years ago. I played with it for about a year, then left it for VSCode when I got a job as the projects at the time were heavily JS/TypeScript based, then slowly went back to Emacs as I started to feel frustrated at how painful it was to do certain things on VSCode that I knew would be lower-friction on an editor like Emacs or Vim.
This second time around it has helped me a lot to not feel like I need to rush to master it, taking time instead to focus on committing one or two commands to muscle memory every 10 days or so, and looking at other people's configuration files for inspiration. Studying these configs in particular [0], [1] helped me quite a bit, as they're nicely commented, big enough to have some useful stuff in them and get real work done, but small enough to understand fairly quickly. I also make it a point to not add stuff to my config that I don't understand and try to follow good practices around commenting and code organization
Being OK with navigating inefficiently but making a conscious effort to learn one or two commands to handle stuff that feels painful (kill line, jump to beginning of file, jump to end of file, jump to end of line, back-to-indentation) then modifying anything that doesn't feel natural.
Learning to find help inside emacs: C-h b to list all bindings in the current buffer, or discover-my-major [2] for a friendlier interface, or [3] (highly recommended) for displaying and filtering available bindings as you type them. Cheatsheet [4] for creating your own cheatsheets to note and recall commands you're working on learning.
Finally, taking advantage of the fact that you don't need to leave Emacs for certain things. For example, at work we use Trello, and I love being able to check Trello from inside Emacs via org-trello-mode. It's very nice to not have to context switch when coding. Not to mention Magit (super powerful git gui inside emacs) and Tramp mode (for editing files over ssh from the comfort of emacs).
Also, I've generally found people to be extremely helpful on #emacs on freenode IRC. I've learned a lot thru osmosis just observing conversation there :)
Nice! It's been the best constant in my life for the past 6 years (well configs, plugins, and emacs evolved, but very smooth and usually with my pace).
I would, however, love to hear a bit more on how you felt about the future of Emacs in those 30 years. I dunno much history, but is there any contrast to the present where Atom/VSCode is kinda shipping shiny (and useful) stuff way faster meanwhile being very configurable.
Give it a chance and try spacemacs (and then after using it for sometime maybe start building something from scratch if you think its too big). The eVil (vim) mode works out of the box and mnemonic bindings are easy to memorize.
I'm really happy to see Emacs move faster, and especially the integration of package management since version 25. The old beast is still kicking!
For what it's worth, I've actually been using on macOS the Mituharu branch [1], available in MacPorts as "emacs-mac-app". This version adds the [s]essential[/s] smooth-scrolling feature, and just in general seems to be slightly better integrated into macOS (except that it doesn't define the standard macOS keybindings, which I had to create manually. Ironic)
If you use Spacemacs, it can define a similar set of keybindings for you with its ‘osx’ layer (https://github.com/syl20bnr/spacemacs/tree/master/layers/%2B...). To enable that layer, open your Spacemacs dotfile with ‘SPC f e d’, then add ‘osx’ to the list within the ‘dotspacemacs-configuration-layers’ variable.
Emacs is the one environment that I've been a fan of from afar. I recognize the brilliance and power of it, but a few things have always kept me away from using it on the Mac. And I've put in serious attempts, including going emacs-only, then a custom evil mode, then spacemacs -
- The server mode compatibility with the way Mac applications are set up. I'd ideally want an emacs server running in the background, and a client app open/close seamlessly whenever I'd like. What actually ends up happening is that I close the client windows but the app never "quits". So it's a zombie icon always hanging around my cmd+tab list.
- "Windows" (or Frames?) have generally not worked seamlessly for me. I've to always put in hacks in my config to ensure the emacs windows work like other apps do for mac. They're either too small and then size up when config is applied (which has some latency so it's noticeable when it happens), or they don't work at all.
- Font rendering. There is some minute rendering difference in the way the same fonts that renders on Vim/iTerm/Macvim/Sublime/VSCode/IntelliJ, but it's the worse by far on my emacs. :(
- All of these complaints are for the GUI mode tbh, which I prefer to use since I like to keep my terminal separate from my editor. Terminal-only emacs is something I tried a few years ago and I remember getting annoyed by keybinding issues etc.
Maybe all of the above are old issues that are no longer present, or maybe I was doing things the wrong way. It just never felt like it was a seamlessly integrated application on the Mac. I hope that has changed or will change. :)
Worth double-checking, but I think that's one area Mituharu's is better than standard Emacs. I definitely recall some font rendering issues with some past version.
As for your other points, they aren't resolved. FWIW, I work around them:
> The server mode compatibility
I just have one long-running Emacs session. I have some colleagues who have experimented with using a launchd LaunchAgent to start emacs server in the background when they login. I haven't kept up with their results and I don't know if there are any side-effects.
> "Windows" (or Frames?) have generally not worked seamlessly for me
Since I have a long-running session, this isn't much of a problem for me. That said, when I do start up Emacs on first login, it indeed takes upwards of 5 seconds to startup, including a window re-themeing and resizing. It's not great, but like I said, it's only once at startup for me. Furthermore, because I came from a tiling window manager on Linux (AwesomeWM), I required similar behavior on macOS. I use SizeUp [1] with shortcuts configured to move my windows to side/corners of the screen. It's far from being as good as a true tiling window manager, but I've had to be satisfied with what I can get.
If you haven't seen it before, you might be interested in something like chunkwm[1], a tiling window manager for MacOS. I've been using it for a couple of years now and its been fantastic and works almost exactly like a linux-based tiling wm.
Thanks! I've eyed chunkwm, but was put off by its externalized keyboard-shortcut system. skhd scares me a bit, and I figure that since chunkwm is macOS only, it should be handling its shortcuts itself rather than abstract it out.
Totally fair objection, but I believe the author made that decision primarily because skhd can do arbitrary keybindings. I have skhd set up to open up iTerm by pressing cmd-RET for example.
Issue #1 was annoying for me, so I hacked together the following solution: write an emacs function that detects situations where you feel emacs should quit (e.g., no windows left) and have it kill itself and the server when this happens. Then, write a launch agent to poll if the server is running and start it if not (pgrep is cheap enough that you can do this every few seconds). Finally, write an Automator app that will be your launch point for emacs, which receives files and opens them using the server.
It’s an annoying fix but when done right it feels exactly like emacs is a native app.
If you could package it up nicely, maybe one of the Emacs distributions would consider upstreaming your solution. I doubt that the pure-GNU Emacs maintainers would be too happy about it considering RMS’s choice to remove Mac- and Windows- specific API usages since they gave the nonfree OSs an “advantage”.
I have written a "pseudo-daemon" mode for Mac that solves the server mode issue[1]. All it does is create a new frame and hide the application when you close the last frame, so next time you activate Emacs, the frame is un-hidden and it looks like it was just created. It works surprisingly well at emulating a daemon for such a simple hack.
I used Mitsuharu Yamamoto's emacs-mac distribution for some time (due to a suggestion I saw here on HN a while ago), but the upstream nextstep build (from the main GNU Emacs repository) actually feels a bit smoother/snappier to me, so I switched back a couple of months ago.
To install that “emacs-mac” branch of Emacs with the Homebrew package manager, see the instructions on https://github.com/railwaycat/homebrew-emacsmacport. Homebrew’s built-in formula directory doesn’t include that version of Emacs, so that linked repo is a “tap” that defines a formula for it. From the README of that repo, these were the only commands I needed to run:
brew tap railwaycat/emacsmacport
brew cask install emacs-mac
You can define custom touch bar buttons with BetterTouchTool (https://folivora.ai/), and configure them to run a custom shell script. There is probably some way to call Emacs functions via shell script.
However, be warned, BTT’s interface is messy and the buttons it creates don’t look right unless you manually adjust the styling yourself. Also, macOS won’t show BTT’s buttons unless you either allow BTT to take over your whole Touch Bar, hiding Apple’s global buttons, or you expand the BTT toolbar beforehand, which must be closed before you next try to press the Esc key.
As someone who recently saw the light, and converted to Emacs (spacemacs), I am absolutely delighted that its going strong.
Emacs is the most delightful software I have ever used. I could evolve a flexible todo management productivity workflow, start writing a journal and start writing new posts in a distraction free environment all using Org Mode in just two days. A complete win for someone who went back to paper (rather unsuccessfully) to organize to-dos after finding digital tools inflexible.
And for python development on remote machine, I get editing and autocomplete on remote systems out of the box (spacemacs) due to Tramp. I was like wtf, why didn't I start using this beautiful piece of software years back.
The way Emacs is a programmable platform really changes how I view what a good software should be.
For instance, I was documenting a machine learning experiment in org mode file. I wanted to mention a metrics result generated as json by my machine learning code. I could just embed sh into the org file, execute it (on the remote machine without friction) and print result directly into the org file. I can trivially compare results in two files and record it back into org mode easily, even on a remote system.
It has made me think that we need more software which erases distinction of programming as something distinct from using software.
Emacs is really nice because it's essentially a text-mode Lisp machine with lots of small packages that integrate really well with each other.
This contrasts with ncurses based CLI tools, which are little silos. And of course, most GUI applications.
In particular, I'm really fond of Org, Magit, Notmuch and PDF-Tools. I feel they are really nice additions to classic Emacs. Some old packages are really nice too. E.g. AucTeX, Gnus, Calc, Dired, Eshell... Although I feel Eshell and Gnus would really benefit from some refactorings.
And of course the myriad of programming modes.
I feel I don't need much more than Emacs, Firefox and a tiling window manager on top of some underlying OS (preferably Unix).
This is a reasonably small release, I don’t have anything to say about it so I will instead do what most other people in this thread have done and make a general comment about emacs:
I think emacs has a few simple advantages:
1. It’s based on a high quality extensible programming language which supports writing extensible programs. This makes implementing new features, new language features, or just modifying/fixing existing ones possible and usually easy.
2. The primitives/idioms (hooks,buffers,buffer-local-variables,markers,interactive functions,advice,keymaps,text properties) tended to be good choices that allow separate modes/programs within the editor to interact well with one another. They also allow easy extension/modification/fixing of the system. I think modules (although useful and maybe necessary) do not typically fit into this category.
3. Emacs realises the idea of a programming environment built into a user interface (ie one where it is easy to interact with the user in a way that is not stdin/out). I feel like this is often touted as an advantage of html/JavaScript but in emacs one already has all the other useful programs/libraries to base one’s own creations on. On the web one always has to start from scratch. On the other hand elisp does not have any GL/canvas interface (although you can write an svg (or worse) and display it).
4. The documentation tends to be pretty good and when the documentation fails
Emacs certainly has disadvantages too. One is setting it up, another is that it often breaks and it can be hard to get used to emacs. I personally am not bothered by these because I already know enough to not mind/struggle much fixing things. Another issue is ide features but I don’t really use languages with separate ides (unless you count languages where emacs is the ide) so I don’t mind this. Indeed I mostly don’t use any of the ide attempt features like projectile or the static code parsing/analysis
Another huge advantage: low resource use. I'm often running resource-hungry machine learning and dataprocessing jobs on my laptop (and Slack), and when ram usage gets high often VSCode or Jetbeans IDEs will just freeze up, often requiring a restart (especially C++ Intelllisense). I've switched to Emacs exclusively now for coding (C++, Python and Julia), and the productivity gains from having a rock-solid editor that never freezes or crashes more than outweight the reduced featureset. To be fair though this seems not entirely the IDEs' problem, as I used to encounter this problem less on Windows; Linux just seems particularly bad at providing a smooth desktop experience when RAM usage is high.
My hope is that some enterprising developer will write an implementation of vscode's extensions API in Rust without the Chromium dependency and that that will lead to something with most of the functionality of vscode, but much less bloat.
Was the problem not that no free OS supported color fonts properly? Emacs does not belong to the Monochrome Font Foundation, after all. Disabling a feature because it causes crashes is not ideological.
Ah, Emacs -- the king of editors. IDEs come and go, but I've found nothing that has yet convinced me to leave the editor that got me started in Linux development during the 90s, in which I've done all of my best work ever since. Yes, I've tried VSCode -- several times. The difference between Emacs and VSCode is that one is an extensible editor, the other was built from the ground up to be shaped and morphed to match your workflow, no matter what that may be. Emacs Lisp is an always-on, instantaneous-feedback, comprehensive extension language -- and it's a Lisp, even if a flawed one. Emacs is also self-documenting and self-debugging, making extending it an easy part of using it. If you type M-. on any Elisp identifier, you will be taken straight to its definition -- even for C-implemented primitives of the Lisp VM (provided you have the Emacs sources and Emacs knows where they live). Emacs is thus open source in a more concretely real way than most open source software -- it makes examinjng its own source easy and even inviting.
The way things are going, I figure either Emacs will die or I will before I stop using it. I guess I'm a set-in-my-ways old-timer. So be it.
I had been away from emacs for almost 10 years since I stopped being a pro programmer. And even back then I wasn't really an emacs power-user. I just knew enough to be productive and slightly dangerous.
Recently, I reached my last nerve with MS Word and buckled down to ditch Word for emacs.
Today I do just about all my writing in emacs (markdown) and then generate word docx using pandoc at the end. Now, I use emacs all day everyday -- blessed. And I am more productive especially since I am actively pushing to keep increasing my power-user level.
Writing markdown with emacs is a huge step up. Now you get to take another big step up when you use org-mode instead of markdown. I'm actually pretty envious.
I use org-mode for note taking and some task tracking. My main doc writing setup is more like an ide setup.
markdown<->docx with pandoc lets me use a ref-doc.docx file that ensures all the styling I need for legal docs gets into the word doc. So you make a markdown file from the ref-doc.docx then edit the markdown file and convert to docx using the same ref-doc and everything in docx has the correct style, and stuff like line numbers and headers are preserved. Pretty sweet.
Yeah, I've done that with pandoc too, but I use org-mode. It's much more pleasurable to write than markdown. I don't use a great deal of org-mode features when writing, I suppose, but just being able to fold up sections and knowing the keys to quickly jump between them and rearrange them is great.
For one example that I like to cite, install Org-Babel and play around with a Jupyter-notebook-esque interface within your document. When you’re done, GitHub will render it statically like they do Markdown.
I wish I spent time learning how to use Emacs in the past to a degree where customizing my installation was faster than learning something else.
As I stand now, it seems really hard to justify to invest time into it when the benefits over using something very easy to work with (like JetBrains IDEs for Java or VS Code for Python) sound marginal.
I know experts can fly around in it and it looks amazing. Having a single point of entry for all kinds of things (ssh to VM, git, text editing, org mode, email...) sounds great, but it is so much work and it seems like I could always be spending time doing something immediately beneficial with the tools I already use. Not to mention that the end result might not even better for the given application (can I really hope to have easier time developing a Go app with Emacs and couple not-so-actively developed plugins than GoLand/VS Code?).
I think you’re best of sticking with Jetbrains IMO; if you’re using a highly structured language like java you may as well get the beenifits of a specialised environment.
For nearly everything else though emacs shines.
I see VS Code touted as an emacs alternative and while your muscle memory might suit it better can it truly give you the uniform fluid experience across pretty much any development enviromnwnt you might use?
That's exactly what I say about switching away from Emacs -- the new tools available aren't compelling enough to make me leave what I've been working easily in for 24 years now.
It sounds like you've found something that works. But if you find yourself with a hankering to take a long weekend, lock yourself in a hotel room like John Carmack, and devote that time to really learning Emacs, I encourage you to do so. It should prove quite rewarding.
I'm in the exact same boat. Every few months I spend some time learning Emacs. I'll hit a road block and go back to VSCode or PyCharm. Then I'll feel silly b/c I'm already super productive in those and just wasted time, but want Emacs to work. Few months later... repeat! Why emacs!?!?
The thing you use daily will always be the most familiar. I’ve gone from your position, to the opposite; now the switching-costs of moving away from Emacs to an IDE put me off.
There do have to be real benefits to make it work. For me it was some very specific things I wanted to do for data analysis that weren’t possible in an IDE at the time, and the other benefits (org-mode, tramp etc.) just sort of compounded.
It’s certainly been a process though. And I wouldn’t have got here if I didn’t find fiddling with editors an enjoyable thing to do, while waiting for a database-query/drinking-buddy-to-leave-work/partner’s-Netflix-binge-to-conclude etc.
At this point honestly it's an objectively worse decision to not use modern IDEs. (It's not a matter of taste anymore.) IDEs have gotten really good. If you only use Emacs or vim, you're literally putting yourself at a competitive disadvantage.
All the avante garde language extensions (Rust, D, etc.) support VS Code better than Emacs now. VS Code is where all the new ideas are tried first.
I've used both Visual Studio (not Code) and Vim and I have to say, the improvements over my Vim setup are pretty marginal for C++ code. Every time people come out saying you can't possibly be productive with Vim in <current year> it always feels a bit like they're projecting their own insecurities. All I really miss in Vim is good debugger integration, but so far I make do ok with plain gdb in a terminal. And this is a big enterprise codebase with ~150 developers working on it. It's perfectly ok to use whatever you like, I just don't see why you need to accuse perfectly good tools of inadequacy - you might end up turning away someone who would be most productive in vim/emacs vs IntelliJ or VS.
That said, VSCode has a lot of good ideas around tooling and I've been toying with the idea of looking into making a fork that replaces the editor component with an embedded NeoVim. I feel that would be the best of both worlds, but obviously a huge undertaking. There is already NyaoVim that implements a NeoVim gui as a web component.
I agree with your point about Vim being more than adequate for development in a large codebase.
I only learned Vim recently and I have hit no issues so far working on a large enough codebase such that navigation and autocompletion wouldn’t work effectively for any IDE.
I instead use cscope and ctags which allow me to selectively setup navigation and autocomplete from within Vim.
However, Atom has always had issues. Snippets are very limited due to design issues. Now a days I keep getting random js errors and the syntax highlighting stops working below a line I was working on.
Microsoft's acquisition of GitHub likely will hurt future community development of plugins since new programmers will assume the worst and develop for VSCode or move on.
Atom showed me how useful/important having an editor I could easily customize is. And the two above shows me how important having an editor with a strong independent community is. I am trying Emacs, but it is a struggle and Spacemacs keeps having random issues (and feels slower than Atom). So right now I am learning Vim with Vundle.
I am so glad that I took the time to learn emacs during my uni days more than ten years ago. I would see everyone else using absolutely awful IDEs that they never actually understood while I was learning how everything really worked and setting up emacs to make my life easier. Nowadays I see people struggling with slightly less bad tools like VSCode and they often ask me about emacs but they just don't have the time to learn it like I did. I probably wouldn't have the time now either.
And before the VSCode fanboys downvote me, the other day my colleague's VSCode instance was using more than 200GB of virtual memory. When I typed on his editor it was noticeably laggy. He told me it was normal. He had five files open. My emacs had been running for two weeks at that point and had about 200 files, 5 shells, 2 ssh sessions and 1 IRC client going on.
Seriously, guys. The reason why you like VSCode is the same reason we like emacs. Come and use the real thing.
Picked up emacs in 1993 in a unix lab because it was the only thing that remotely made sense on these weird X-Windows systems. Was a good choice because I haven't had to learn anything new since. When I met RMS I thanked him for it.
I'm so thankful that I stumbled upon emacs in my first year of undergrad. That discovery led me to the wonderful world of Lisp, and really impacted how I view software design and the development process. As a C/C++, Clojure, Verilog/VHDL, and org-mode tool, I can't imagine using anything else. Python is the only use case that I haven't been 100% satisfied with, although I don't think Pycharm or VS code offer anything more compelling to me (could be wrong).
The world is so different now. In my first year of undergrad, you didn't "stumble" on emacs. It was the tool of the demigods that worked on the software you could only read about on usenet. Everyone knew emacs was best, if you could get your admin to install it. It's what we all dreamed of using some day.
So needless to say it was the first thing I tried when I got my shell account. I got stuck in it, couldn't figure anything out, and had to power cycle the terminal before sneaking away sheepishly.
But yeah, emacs is best, and I'm still using it now that I know how to exit.
Congratulations and a huge thank you to all those involved! Emacs is a truly remarkable piece of software. I started using it for text editing over 20 years ago, now I use it pretty much as an operating system!
spacemacs! I was a long-time vim+tmux diehard and now i'm all about spacemacs. Org-mode and Magit are just too good to live without. There were a few hurdles when switching, mainly around auto-indent differences that were harder to configure with emacs. (dtrt-indent ftw, thank god for that). Also the regexes are different and not as good (i don't think emacs regexes do negative lookahead etc...) so some of the advanced substitution wizardry i used to do isn't quite as good.
But overall i prefer Spacemacs to vim for general development.
I recommend using the develop branch of spacemacs. It sometimes breaks but if there is something broken it gets fixed really fast, whereas if something is broken on master then it sometimes stays broken for a really long time.
spacemacs is for vim users. No one who doesn’t use evil mode uses it. Also most people who use evil-mode probably use spacemacs.
Emacs keybindings are burned into my brain at this point, but if I had to do it again, I would probably go with spacemacs. I think modal editing is probably superior.
I don't use evil-mode (anymore), but I still use Spacemacs. I'm too lazy to configure everything myself (language modes, Helm, Projectile, Magit, etc) so I use Spacemacs as a starting point and load a bunch of extra ELisp on top.
I'd recommend Spacemacs (even if you're not using evil) if you're new to Emacs and want to see how different and powerful a fully customized Emacs is when compared to the bare-bones experience of stock Emacs.
Best bet is to just start from the beginning. My journey began with the emacs tour you get directed to the first time you start it up. With regards to muscle memory etc its a completely different animal to everything bar maybe the command line ...
A bit of advice: Emacs can do so many things (there’s a web browser included out of the box), but that doesn’t mean you should use it for everything. Despite the fact that “applications” within Emacs are usually better integrated than those outside of it, they are oftentimes fairly buggy. Emacs has a horrible case of featureitis, so I try to limit my usage of the bundled features that aren’t well-maintained, of which there are many.
As many others have suggested, take a look at Evil, the best Vim emulation for any platform. Just ease your way into it by replacing Vim, then some other CLI programs, then figure out when to stop when the Emacs version is no better than what you were using before.
Be sure to check Doom [1] as well. It's Emacs for « a stubborn vimmer ». One of its goals is to be fast and hacker friendly. It's a smaller community than Spacemacs.
Also, the default theme is fantastic along with great defaults for key bindings.
http://emacs.sexy/ points to a bunch of useful resources,
including an Awesome Emacs which points to a bunch more.
Tuhdo's tutorials feature a bunch of animated gifs about his use/setup, which is quite nice.
I haven't tried distributions like spacemacs or doom-emacs (which is lighter-weight than spacemacs, with fewer abstractions above emacs). I think emacs is software which benefits from being well understood by the user, to the extent of "if something breaks I can fix it".
My guess is that someone that has used vim for more than 20 years will never feel truly comfortable with emacs. I say this having started with emacs for a few years, and since switched to vim, now for almost 20 years.
Vi(m) is not just a set of key bindings. It is also a philosophy of text editing that is much more integrated with the command line. You cannot replicate it entirely in other editors.
I don't know what the state of vi(m) emulation was the last time you used emacs, but evil-mode is very comprehensive. About the only thing I missed when I made the switch was tabs; everything else either just worked as in vim or had a near-identical equivalent. I'm curious what you expect would be missing.
I've been using vim for many years now, with stints of using emacs here and there. I cannot stand evil-mode. If I'm using emacs it has to be with default key bindings. Why? Because evil-mode violates my expectations as to how vim operates.
It may be fine for a very casual vim user who wants to switch to emacs but it's too confusing for a vim power user. There are subtle differences that disrupt the flow of my muscle memory. One such example is the }{ forward and reverse paragraph motion. In vim, this is perfectly predictable and delineated by empty lines. In evil-mode, however, it's hooked into the major mode, so it's always changing behaviour as you switch between different file types.
I'm not saying this is bad advice, but as a vim expert I have a hard time with emulations messing up my flow. IMO if you want to use emacs it is worth taking the hit and switching to a whole new set of keybindings.
I 'switched' to evil mode about 2ish years ago and ported my entire .vimrc and all its quirks with no problem. There are some rough edges with some other modes not supporting evil by default where hjkl muscle memory can trigger functionality unexpectedly, but that is usually easy to fix. The only other thing you have to watch for is that emacs is overly strick about C-a b vs C-a C-b and this manifests painfully when using C-w l and friends to switch buffers. The easiest fix is just to bind C-w C-l as well so that you don't have to slow down your typing.
I have actually found it hard to go back to vim because emacs has been much easier to customize and many of the features I use routinely are no longer in my vim config.
Would you mind elaborating more about which particular emulations mess up your flow?
I use Emacs very casually, mainly just for writing in org mode with Evil, and have toyed with the idea of switching to it completely. But, if you could talk about the figurative holes you fell into as a vim expert that could help inform my decision down the road.
It has been a while since I honestly tried evil-mode, but there were a few categories of issues I remember:
1. Search/replace behavior - Not that it is better or worse, just that it is different.
2. Misc. ex commands. I don't remember specifics.
3. Plugin specific commands. Not really fair to bring up, but still part of my muscle memory.
Using vim keybindings with emacs has been way better then any other vim keybindings thing I've tried for other programs. And if there's anything missing you can customize it.
Is the multi threaded implementation, being talked about for some time part of this release? Sometimes the single threaded nature of emacs causes problems while running complex setups like cider, nrepl etc.
I sometimes wish that Xi editor adopted an elisp port as one of the scripting engines. Not very likely, though; a suitable port does not exist in the first place so far.
OTOH, being an in-place rewrite, it likely cannot afford to change some of the more important architectural decisions, very likely including the ones that prevent multithreading.
Emacs-26 has threads yes. How many packages use them at the current time I do not know. With nrepl, though, most of the problems are likely to get from the interaction with an external process which has been able to happen asynchronously for a long time. So, threading (or its lack) might not be the problem.
Not from this release, but this is the most recent thing I've been able to find about concurrency:
> This is also only the first step in bringing threading to Emacs Lisp. Right now there’s effectively a global interpreter lock (GIL), and threads only run one at a time cooperatively. Like with generators, the Python influence is obvious. In theory, sometime in the future this interpreter lock will be removed, making way for actual concurrency.
Cooperative threads serialized with a global lock didn't originate with Python. In fact, the traditional Unix kernel was that way and so was Linux initially.
> - In Dired, the 'Z' command on a directory name compresses all of its files.
Dired is so handy, but it does so much. Unless I were to use this feature often enough I fear I would never remember it was there and just break out to a terminal and `tar -zcf` manually.
I feel like something already exists for this, but it would be cool if there was a "Random Mode Tip of The Day" that one could invoke for discovery and practice of things like this.
Typing `?` helps.
Anyway, M-x describe-mode (normally M-x desc-mo <Tab> is enough) will print a complete, if intimidatingly long, description of key bindings for the current buffer.
Use menus. The menus are really handy for discovery. Many I see disable them (the menu-bar-mode), but it doesn't take up more than about a line, and I go to it to discover what interesting bits a mode has or to find some functionality I use less often and forgot the keybinding to it. I do also use which-key-mode, and there is always M-x apropos & the completion, but menu is a nice companion to these stuff.
I'm one who turns them off. When disabled, you can just hit C-down-mouse-3 (i.e., ctrl-right click) anywhere in a buffer to get the global menu in the form of a pop-up. That works well enough for me for the rare occasions when I want to go spelunking through the menu (mostly to find some obscure Calc op).
I first used Emacs on a Prime minicomputer in the late 70's. It was ported to Prime by Dan Bricklan's Software Arts, Inc, of Visicalc fame. Still using it 41 years later.
For anyone curious, the Prime version of Emacs is running on a Prime emulator I set up. Telnet to em.prirun.org port 8002
I'm a heavy user for a vim for the last few years. Is emacs worth checking out to potentially switch to? Or should I just stick with what I'm already productive with?
Depends what you're looking for. If you want blazing fast text-editing, you're better off learning advanced vim features like jumps, macros, registers ...
If you care about integration with other text-based tools (like email, instant messaging, source control, code review, IRC, ...) then switching to emacs will transform your workflow.
There are a couple of emacs modes that stand out, and in my opinion make emacs worth it:
The best emacs mode I’ve ever used is org-mode. Inline LaTeX rendering, inline images, outlines, TODOs, it’s amazing. And when you add yasnippet in to the mix, it gets even better. I can write up math notes faster than someone could write it on a blackboard!
Emacs is probably the best piece of software I’ve ever used, and will use. I bet in 100 years, emacs will still be going strong. There’s really nothing it can’t do.
