|
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. |