[hasmanean]

You would need live routing of messages. And the ability to reroute, filter, inject messages dynamically into code.

Why must everything be done as a function call? You can’t change anything without recompiling the code.

Today everything is implemented as a function call. Need to send a message? Call a function named “snd_msg” or something.

[wtetzner]

> Why must everything be done as a function call? You can’t change anything without recompiling the code.

Emacs Lisp supports dynamic binding, so you can dynamically rebind function definitions at runtime.

[cben]

It's curious how the original 1981 paper [1] on TECO Emacs, written before I was born, describes many qualities I recognize in the ELisp Emacs I grew up on.

Emacs "happens" to be open source ;-), but the paper stresses how the system & language were designed to allow users to mold it at run time without the barrier of recompiling from source, and how empowering users led to better features than "careful design" could have achieved. Selected points I found notable:

- awareness that "An EMACS system actually implements two different languages, the editing language and the programming language". - Editing Language is tweakable (again at run time) by re-binding keys to macros / existing commands / custom commands. This gives agency to users with less programming skill! - Language separation being necessary so that tweaking Editing Language can't break Programming code. - Key bindings are shallow "keyboard sugar" over the concepts of Programming Language. Commands are (almost) regular functions. User can invoke any command by name, bypassing the sugar. - Buffer-local & mode-local bindings. - Commands (and generally as much of the system as possible) implemented in Programming Language which was chosen to be interpreted not compiled, so that users can redefine at run-time and experiment. - "The only way to implement an extensible system using an unsuitable language, is to write an interpreter for a suitable language and then use that one" :-D - "variable [and function] names are retained at run time; they are not lost in compilation"

- Commands are extensively parametrized by variables. User can achieve quite a lot by simply setting [global] variables. - Dynamic not lexical scoping deliberately choosen to make code less encapsulated and more reusable with tweaks. See paper why lexical is worse for dynamic - Unique concept of File/buffer-local variables! Again, if programmer went to the trouble of parametrizing code, maximize the payoff. - Commands and especially compiled code extensively parameterized by calling "Hooks" at interesting points. "These hooks can be thought of as compensating for the fact that some parts of the system are written in assembler language and cannot simply be redefined by the user." <<-- I found this especially thoughtful

- Social dynamics like "library system" for loading extensions written by others. Well, ater Emacs actually lagged behind for decades in ease of obtaining 3rd-party libraries. "too cathedral, not enough bazaar..." Much better now with MELPA, still not as smooth as say VSCode extensions. But I feel a trade-off — VSCode extensions are more "opaque".

[1] https://www.gnu.org/software/emacs/emacs-paper.html