this post was submitted on 25 Nov 2023
1 points (100.0% liked)
Emacs
313 readers
3 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The lisp environment of Emacs makes it unique. Also it's support for dynamic modules gives you a TON of extra power for certain cases where lisp is not appropriate; integrating 3rd party software like web browsers in a performant way.
If your goal is to simply use the editor then the lisp environment doesn't give you an advantage. But if you want to treat the editor as a tool you mold like clay to your tiniest yak shaving need then it gives you a LOT.
For comparison, let's look at Netbeans. A stereotypical traditional IDE. . If you try to write a plugin Netbeans you are first met with boilerplate. Menus, a bunch of strange plugin related code generated. You have to learn the plugin boilerplate system to get started. Now you wrote a little code and are ready to test/observe it's behavior! how do you do that? you build/run and spawn YET-ANOTHER-NETBEANS which may take a few minutes. The write/observe feedback loop is painfully slow. (FYI I love and use Netbeans. I'm dunking on it but it has some advantages even over modern IDEs like Jetbrains).
Now let's look at Emacs. We start by writing a function. Then immediately observing/testing their behavior. There is no boiler plate. We are not cordoned off to a special "plugins" area. We just straight to the good stuff, the functionality. Instead of waiting 5 minutes to build/observe what we wrote, it happens IMMEDIATELY as we write it using lisp's EVAL-loop. It affects our running Emacs instance, no need to spawn another.
I lied a little bit. Emacs packages DO have boiler plate that you should conform to before publishing. But it's not required, and not where you start. For your personal stuff, it may simply be a collection of functions. Then bind appropriate functions to keys.
An anecdote. Just yesterday I was writing some Go (lang) code and running the linter. Most of the time I like to run the linter at the project root folder. But at that moment I only care about the package I'm working on in the current folder or maybe 1 level up. I whipped up a little helper function where I can select 1 of 3 options: current folder, project-root folder, Custom folder. The project root folder is detected by heuristics using Emacs project library. If I choose Custom, then i input a folder via completing read. This little fn scratches MY itch. A tiny little inconvenience solved in 5 minutes. If i tried to solve that in Netbeans..... it would take 5 minutes just to build it and spawn another Netbeans instance.