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.
Never too late though, and on the plus side I've now got decades of hidden Emacs goodies still to discover!
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! :)
Emacs is often confused as being an editor, but it's not.
It certainly houses a few different editors, including Vim (as people will often point out eVil is Vim inside Emacs)
Emacs is basically a text centric computing platform, built with a flavor of Lisp.
At this point there's several thousand apps / packages.
It used to be a joke that Emacs is an Operating System that lacks a decent text editor. These days it has several.
The joke now should be that it lacks a decent logo and marketing department.
Or perhaps the joke should be that Vim users are terrified they're missing out on something they don't get so they use snark as a defense mechanism.
That’s actually the best explanation of Emacs I’ve heard. Thank you.
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.
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).
A uniquely empowering tool for programmers.
...so when does someone teach me the secret handshake?
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).
That seems pretty far-fetched. Very few of the things I use Jupyter notebooks for seem possible in org mode.
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.
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.
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.
Thanks for clearing that up for me!
M-x secret-handshake (use-package flyspell
:config
(setq ispell-program-name "/usr/sbin/aspell")
(setq flyspell-consider-dash-as-word-delimiter-flag t)
(define-key flyspell-mode-map (kbd "C-:") 'flyspell-correct-wrapper)
)
(use-package flyspell-correct)
(use-package flyspell-correct-ivy)
(defun my-save-word ()
(interactive)
(let ((current-location (point))
(word (flyspell-get-word)))
(when (consp word)
(flyspell-do-correct 'save nil (car word) current-location (cadr word) (caddr word) current-location))))A nice happy medium is Prelude -- https://github.com/bbatsov/prelude
It's big, but probably not too big to understand and jump in and tweak.
I still prefer my own hand-rolled config though.
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.
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.
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.
[1] https://www.gnu.org/software/emacs/manual/html_node/emacs/Ke...
Best resources you’ve used to discover things?
`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 '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).
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).
It's strange, but I feel extremely excited about this coincidence. :D
(1) Well, technically, that includes several years of XEmacs in the middle, when GNU Emacs didn't look as good under X11.
[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.
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.
And in a way.. MS Office has been forever, even though it changed a lot in the recent years .. Excel is still Excel.
I suppose it could be seen as vi to Vim, though.
vscode however will probably take over that role some time during the next 12 months.
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.
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.
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 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.
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.
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.
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.
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.)
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.
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.)
I do know that Emacs did adapt a lot when coming to Unix/X11 from its initial roots on other systems, but maybe it has ossified since then.
For more info see the first answer here: https://emacs.stackexchange.com/questions/28840/os-x-emacs-d...
Even iTerm supports middle-click paste. Unix people are used to it.
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.
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).
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>.
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.)
"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 use a 4k monitor and with a C-x +++ everything is bigger by 3x. I can set it permanently too.
What is vscode doing different?
I've tried it a few times but the default keybindings seem unnatural to me. Not that it's Emacs fault, considering the keyboards they used back then.
I've since switched to a proper mechanical keyboard and all is fine with the world.
[0] Technically Zmacs, but most of the key bindings were the same.
*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.
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.
It's helped (but not completely alleviated) my RSI. Absolutely worth the price for me though given that.
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.
I also have a Kinesis one that I used for some years. Those require some training.
The older Curve 2000 series might be a better choice if you actually want to use those keys with any frequency
(And to bring it back to emacs, I find myself using ESC-ESC-ESC quite a lot when I (or it) get confused about what state things should be in)
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.
Learn the various built-in help features, and use them. C-h C-h describes all the various help features.
Beyond that - force yourself to navigate via the keyboard only (no mouse, no arrow keys). You'll get more efficient and pick up shortcuts as you go.
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 :)
[0] https://github.com/jsks/dotfiles/tree/master/emacs/.emacs.d
[1] https://github.com/flyingmachine/emacs-for-clojure/
[2] https://framagit.org/steckerhalter/discover-my-major
Here's all the actual commands (very few) I use day to day --> https://gist.github.com/franee/5d188ce36f6c24181707907614d2c...
I use mainly the emacs starter kit and build from there.
I swapped Ctrl & Caps Lock two years ago due to wrist pain when doing development in a laptop.
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.