[smg]

The biggest difference between Emacs and any other editor is that instead of thinking about Emacs as an editor you need to think of Emacs as a programable workflow enabler. Using Emacs without learning Elisp is like carrying a bike on your shoulders instead of riding it. Once you get to the place where you can confidently write Elisp to solve your problems, you will miss Emacs deeply when you have to use any other application. You don't need to write extensions and open source them for other people. All you need is the ability to create Elisp code that does what you want exactly how you want it.

The best way of learning Elisp is reading the source code that is distributed with Emacs. Do a git checkout of Emacs and read Elisp code written by Stefan Monnier. Stay away from org-mode elisp - the quality of that code base is highly suspect.

[neilv]

Stock Emacs and off-the-shelf add-ons are pretty powerful, but I agree that one is really missing something by not writing their own little tweaks.

You can learn Emacs well just by starting with this manual and beginning to tweak Emacs to do things you want: https://www.gnu.org/software/emacs/manual/html_node/elisp/

Emacs Lisp is very low-friction to start hacking on. There's no SDKs to download, no IDE to install, no developer mode to enable, no project wizard to run, no source tree of template files to start from, no program to attach, no emulator to run, to separate build to run, no sandboxing, etc. You can just start Emacs, and start editing Emacs Lisp expressions and evaluating them, and you can change the code of your running Emacs in a very straightforward way.

I initially started by writing little fancy editing features for C and C++ coding (e.g., format my comments a certain way, do a expression transform, etc.), and then started writing to editing modes for my employer's proprietary languages. The public bits are at "https://www.neilvandyke.org/emacs/". That was my introduction to Lisp hacking, and eventually I gravitated to Scheme.

[alexbanks]

It's interesting to me that the top two comments (at the time of writing this) are fundamentally opposite advice. Yours, to customize Emacs, vs. the second, to basically not customize it at all.

[asdf123wtf]

My take on that is...

For those fundamentally interested in developing development environments, coding tools, or making your editor your hobby, diving deep into emacs customization is a reasonable thing to do. In other words, if creating things like evil-mode or spacemacs excites you, a dive deep into emacs is a good option.

For those who aren't interested in those things, try to actively avoid deep diving into emacs. It will be an unfulfilling waste of time. There's no magical developer productivity pot of gold at the end of that rainbow.

[alexbanks]

Definitely. I guess the interesting part specifically is that, if you aren't the type to care about making a development env a hobby, why would you ever even touch emacs?

[jrockway]

I think the advice here is to be able to write your own customizations, but be careful about installing EVERYTHING that you read about.

I occasionally try cool-and-new Emacs things that are mentioned on HN or elsewhere, but drop most of them. The reality is that a lot of these things are completely crazy and don't help; they are complicated, but don't reduce the overall complexity of the system. If you are new to Emacs, every one of these things is a potential stumbling block that leads to dropping Emacs. (The reason to use Emacs over the cleaner and newer editors is the raw text editing efficiency. The new editors are behind here, and munging text should be the editor's primary concern.)

But, I have also written many of my own extensions that have served me well for decades. I wrote "eproject" back when Emacs didn't have built-in project support. I have kind of ignored it as an open-source project (there are probably 8 million Github issues open that don't interest me), but I use it every day because it works perfectly... for me, the author. I have also written a couple of other neat extensions that have served me well; many years ago I was a fan of "takahashi method" presentations, and wrote an editor/viewer for these. It is unlikely that anyone else would ever use it, but it worked for me at the time. Having that flexibility in your toolkit is great... but it is not necessary for day-to-day editing. (I learned Elisp when I was converting a client's set of static HTML files [actually JSP] to a CMS. I needed to extract certain metadata from the filename and HTML tags into flat files, and then replace the static content with markers that would load that content from the CMS. Almost all of the pages followed a certain format, but there was enough variance that a good chunk of them required manual intervention. So I wrote a Lisp program that highlighted the relevant areas and let you edit them, then did the actual extraction and replacement. It took a couple days to write, but I did the actual extraction in half a day with no errors, so I think it was worth it. If you were using something less flexible, you wouldn't have written that, and would have had to clean up a bunch of mistakes from your non-interactive batch job, or just spend three days manually cutting and pasting thousands of chunks of HTML.)

As for extensions that have "stuck" for me; lsp-mode is the big one. A lot of languages have good language servers, and jumping to documentation and autocompleting symbols is pretty enjoyable. Depends on the language you use; I'm happy with gopls and the Typescript language server. I've never gotten clangd to work on an existing project, however. Minimalism is the name of the game; I use lsp, but nothing fancy. It underlines errors in the code, provides completion (with company-mode), and I setup keybinds to jump to definitions and documentation. I basically ignore lsp-ui-mode completely, because it's too much clutter.

Pre-LSP(+) code formatting hooks have also stuck. I cannot live without gofmt-on-save and don't use a programming language without an autoformatter (prettier is great for Javascript and friends, YAML, and JSON). Clang-format serves me well for C/C++/Protocol Buffers (but most open source projects don't follow their own style rules, so you have to turn it off if you're just making a small edit to their project). Emacs has good modes for all three of these things, go-mode and goimports, prettier-mode, and clang-format-mode. Could not live without them; formatting code is a silly thing to spend any mental energy on, and computers do a much better job than I could.

(+) I say pre-LSP here because the Language Server Protocol does do reformatting. I have not played with it. I'm happy with the static tools that existed before LSP, and haven't found a reason to try something new. YMMV.

[AnonC]

Thanks a lot for your detailed comment. The work you did with splitting the JSP files shows the power of the tool, and it’s things like these that are inspiring to know about (since I don’t know Emacs, normally I would’ve just reached out to awk or a combination of sed and awk for something like that).

[namelosw]

I'm fine to tweak some Elisp code but not fully enjoy it as Scheme or Common Lisp. It's really an awkward language despite the fact it's a Lisp, and I really like Lisp.

Oh, how I wish it would be completely re-written with other dialects... Although there are many attempts, they are far from polished compared to Emacs itself.

[augustk]

This is also the biggest problem I have with Emacs. When I used it I spent too much time configuring things, something which distracted me from solving real problems. Now I use a much simpler editor which is not so configurable so I can focus on other things.

[agumonkey]

linux (*nix) is also a workflow enabler, with a different ISA (Filesystem vs Buffers, processes and pipes vs functions).

I have yet to grok this mindset.. which is a shame.