Hacker News Reader

Comment by hollerith | Hacker News Reader

Emacs has built-in scripting language. . . . All of the editor’s functionality is exposed via APIs written in the scripting language.

As a consequence, you can control everything emacs does programmatically. This makes emacs extensible in a way that is far deeper and more powerful than a plug-in architecture. A plug-in architecture must anticipate every desired extension to the system. Since it never can, it always disappoints in the end. Along the way it grows ever more complex and bloated in its futile attempt to foresee every possible need. With a language, you can code any extension you need.

Does anyone who has tried to modify both Emacs and an editor (or IDE) with a plug-in architecture agree or disagree with that?

View on HN

I use emacs several hours each day and have written quite a few customizations myself in elisp. Enough that I think I have a handle on the question.

The Emacs APIs for window management, buffers, and other various "chrome" so to speak are pretty good and easy enough to grasp, once you get over the Lisp hump. But the Emacs APIs for managing text in buffers is difficult to wrap one's brain around, because it takes a very different approach to text management than most Unix tools. Basically, you write out the editor commands necessary to do the manipulation you desire. That sounds straightforward enough, but it takes some getting used to.

What Emacs really excels at, though, and what makes it stand out from other customizable editors is the fact that you can literally change the beast from the inside. Since Emacs is basically a Lisp environment, with some large portion of the code written in Lisp, it's very easy to pop functionality in and out to test it out, or to make changes on the fly. In a Lisp buffer, you can just hit Ctrl-J to evaluate the expression immediately preceding the cursor and print the result into the buffer (or use Ctrl-X Ctrl-E to run it without printing the result). Or hit Meta-: from anywhere to run some Lisp interactively from the minibuffer, affecting your environment in real time. This ability to toy around with the running editor itself is a feature unmatched by pretty much any plugin editor. The built-in devtools with Javascript console in Chrome are a close analog in a web browser, but that is limited to the document you are viewing, and you can't control the entire browser experience from that console. With Emacs, you can.

So yes, I'd love to see Emacs add modes that move beyond text editing and allow rich buffers and embeddable videos, audio, and widgets of all sorts. There exists a very rudimentary capability for this sort of thing in Emacs now, but it is extremely limited.

>The built-in devtools with Javascript console in Chrome are a close analog in a web browser, but that is limited to the document you are viewing, and you can't control the entire browser experience from that console.

You cannot use those devtools to customize the devtools themselves; can you?

I'm asking to make sure I understand -- I'm not trying to be argumentative.

Actually, you can use DevTools to inspect DevTools. Hit option-command-J to bring up devtools, make sure it's in "window mode," i.e., in a separate window from the browser itself, and then hit option-command-J again to DevTools that DevTools.

You can actually just keep recursing and inspect the previous inspector ad nauseam...

Thanks. I appreciate being disabused of my misunderstanding.

Sort of depends on what is meant by a plug-in architecture. I think it's begging the question a bit.

I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps?

>depends on what is meant by a plug-in architecture.

I'll give examples.

I love how easy it is to change or customize Emacs. E.g., if I want to change what happens when I right click on some text, I can do so (and have done so) by writing some Emacs Lisp code (and only 27 lines of Emacs Lisp code at that) -- leaving the parts of Emacs written in C completely untouched.

In other words, in Emacs (and IIUC Light Table), with very few exceptions, all of the editor’s functionality is exposed via "APIs" (and in Emacs, it would be accurate to replace "APIs" with "variables and functions" since Emacs does not have classes and such) written in a high-level scripting language (Emacs Lisp or ClojureScript).

The same cannot be said of Textmate, Sublime Text or Lime Text. What one can say of those three, though, is that they all have a plug-in architecture.

So, my question, again, is whether the OP is correct in his assertion that -- at least for people who are in the habit of frequently changing many different aspects of their editor -- having a plug-in architecture is no substitute for having virtually all of the editor's functionality exposed via "APIs" written in a high-level language.

Interestingly, once you enable the developer tools, Komodo is very similar to what you're describing. Pretty much everything is exposed as an API to the JavaScript environment, you can change stuff on the fly and the like. It also has a Python API for certain features. I think that's a consequence of being based on XUL, a web browser is similar to emacs in terms of runtime extensibility, though not 100% of the way there.

>I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps?

Yes, that helps.

When I go to the Add-on Manager and select the tab labelled "Extensions", I see a list of things like Adblock Plus.

Are those things what you meant when you wrote "extensions to Firefox".

If not, then, well, an example would be great.

Yes, it is. But I think Staltek may be right in that Firefox essentially takes the same approach as emacs and lets extensions access the main application runtime directly (Although with some security constraints).

That's a flawed comparison. Firefox takes the Emacs approach. All of Firefox is built of XUL, Javascript, and the gang.

Lots of apps expose a C plugin API, many apps expose some scripting. I don't think the population of apps exposing a comprehensive scripting API that mirrors the internal C structure is that large. Chrome might be better.You can't do whatever you want with Chrome, it has to be published to the scripting interface first. Early versions of Chrome had trouble supporting a lot of common Firefox extensions for this reason.

I tried to extend Komodo IDE back when I used it heavily. I had no knowledge of Firefox internals then.

The biggest problem I had with this was the lack of documentation and a sane development environment. Working in an embedded environment makes debugging (and exploratory programming) much harder: you can't just `print` your way through APIs and things. You can't use `pdb`, much less graphical debuggers. This makes developing such extensions painful: you need to learn a whole lot of APIs at once and memorize them before writing even one line of code.

Emacs is better on both accounts. The "self-documenting" part means that there are rich docstrings for every single function you'd want to invoke and that you have many supporting tools for discovering APIs (like apropos). There's a Messages buffer which functions as a stdout, where you can dump whatever you need to see at any point. You can also immediately see the source of any function, even if it's implemented in C. And you have a graphical debugger for Elisp if you need it.

Emacs is a really nice development platform for Elisp and accidentally for other languages. Things like Komodo are great for normal development, but much harder to develop for. That's my impression, anyway.

That is helpful, thanks, but I cannot guess what you mean by "working in an embedded environment".

I mean "embedded" as in a "scripting environment hosted by a bigger app" (nothing to do with embedded systems in hardware sense, obviously). I thought the term is widely used for this, for example there's a guide to "embedding python"[1] and they use the same term in Lua[2].

For me, such an environment is defined - in practical terms - by the lack of some features you expect from "general" programming environment. No stdout/stdin, no fork, no exec, no file and file system access, no threads, no sockets - and if you get some of this it's via an embedding app, not standard means. It's hard to work in such an environment because it's very rare for app developers to provide you with all the standard tools you have when developing standalone program. One of the most painful experiences I had with such env was with Google Refine - now Open Refine - which allowed scripting in Python (via Jython) and Clojure, but only really supported executing single statements in a tiny textbox, without any real error reporting and without access to anything external (like to files). It was a nightmare, and it's generally how this looks like: MS Office, Web browsers, Emacs are the exceptions here, definitely not the norm.

[1] https://docs.python.org/2/extending/embedding.html

[2] http://www.lua.org/pil/24.html

Emacs should be compared to Eclipse, which seems flexible enough that it is frequently used when big company X writes an new IDE targetting a new platform or language.

My take would be that because Emacs lets you modify it deeply, you can do much more and also make a big mess.

Complex and bloated, eh. Thank God emacs has managed to avoid that fate...

As far as extensibility goes, the openness is the most important part, I think. No need for a scripting language necessarily - though it makes many things more convenient.

Having picked up Emacs recently, it feels sort of the opposite of bloated, though there is definitely complexity. I think its reputation for being large dates to a different era of minimalist Unix tools, when Emacs using MEGABYTES of memory ("eight megs and constantly swapping") looked big compared to vi. But if you're comparing emacs to Eclipse, it's a resource-stingy speed demon.

Emacs is not complex and bloated by the standards of recent decades. To address the "complex" point, yes, there are a lot of lines of source code in the Emacs tarball -- not nearly as many as in Firefox's source-code tarball or Chrome/Chromium's, but certainly at least an order of magnitude more than, e.g., Bash's tarball -- but the vast majority of those lines of code will never run on your machine unless you make a conscious decision to do so. E.g., the tarball contains at least 9000 lines of Emacs Lisp specific to the Ada programming language (code that indents code written in Ada, code that applies Ada-specific syntax coloring / highlighting, etc), but unless you explicitly load the files containing the 9000 lines or you open a file with the extension ".ada", those 9000 lines will (unless I'm really missing something) never run.

Emacs does have a steep learning curve.

E.g., what Emacs calls a frame, everyone else calls a window; what Emacs calls a window, everyone on Windows, Mac, etc, calls a pane (and the decorations around Emacs's panes, er, windows, look nothing like those around most of the panes on the OS on which the Emacs is running.)

E.g., Control-U in Emacs does not mean what it means in most Unix programs (delete to start of the line).

There's a lot of those kinds of differences, and it is understandable that a lot of people don't want to learn those differences.

But please don't just say "complex" (or "bloated") when you mean that it has a steep learning curve or that it has its own set of conventions that differ from most modern software.

Reply on news.ycombinator.com