this post was submitted on 25 Nov 2023
1 points (100.0% liked)

Emacs

313 readers
2 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
 

I talked to someone about the extensibility of emacs, but the person I was speaking to assumed that any IDE is just as extensible by using Plug Ins.

Without turning the conversation into a university style lecture, what is one or two simple actions I can do in emacs to show someone what separates it from other IDES.

you are viewing a single comment's thread
view the rest of the comments
[–] emaxor@alien.top 1 points 1 year ago

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.