
Emacs: The most successful malleable system - signa11
https://malleable.systems/blog/2020/04/01/the-most-successful-malleable-system-in-history/
======
olivierestsage
Thanks for sharing this. My personal experience speaks to a lot of what the
author mentions: I'm an academic with little programming experience to speak
of (mainly some Java in high school), and it always seemed to my younger self
like there was this insurmountable hurdle between the language-learning phase
and the part when you can actually develop useful applications. Now, of
course, I know that this is not necessarily true of programming, and that this
discouraging feeling is something beginners experience in many fields--but
that's how it seemed back then.

Flash forward to now: I picked up Emacs a year or so ago because of Org-mode
and its promise of organizing my tasks. Gradually growing my init.el to fit
with my way of thinking was my first encounter with programming with any kind
of direct practical application, since (as the author mentions) a beginning
user frequently pastes simple Lisp functions off StackExchange, and you can
kind of puzzle out how they work with your own eyes, immediately, even if you
lack significant training. It soon gave me the goal of using code that I could
understand (at least somewhat) when I needed new Emacs functionality, rather
than just downloading a big package off MELPA that would be far beyond my
comprehension. And that was the point I started to learn Emacs Lisp.

Currently I've been working on a minor mode. Who knows how long it'll take me,
but it's been a fun ride, and I credit this personal development to the lack
of barriers in Emacs that the author describes.

~~~
asimilator
Ironically I think org-mode is a great example of a non-malleable system. When
I started using it I slowly tried to customize it to better suit my needs, but
everything was quite brittle.

Posted a comment awhile back with some specific examples from my experience:
[https://news.ycombinator.com/item?id=20551598](https://news.ycombinator.com/item?id=20551598)

~~~
karlicoss
I'd say it's very customizable, but requires (sometimes significant) time
investements.

I'll respond here since can't reply to the original comment:

1\. "leading stars" \-- I think the solution is org-hide-leading-stars (and it
is basically the hack you are describing)

2\. "now it takes multiple seconds to refresh my agenda view" \-- org-super-
agenda is a pretty mature library handles groups well. As for performance, the
most significant speedup for me was setting org-agenda-span to a lower value

3\. "it's actually pretty hard to find good examples of a full org-mode
workflow." \-- agree. One reason is perhaps because it's quite hard to
communicate your workflow to other people becaue it's too specific to your
needs.

4\. "But problematically I now have a lot of files with similar names" \--
yep, refile-outline-path, but also uniquify helps a lot.

5\. "Apparently org-mode deliberately prevents the end user from adding their
own custom emphasis formats" \-- don't know whether that's the case; but you
can abuse org-add-link-type, then you could write [highlight:Some text to
highligtht], and do whatever styling you want during the export. Hacky, but
kinda does the job.

Finally, it's at least possible _in theory_ to override any org-mode function
and change the logic. Of course, you can do it with any other text editor, but
it would be way less effort to hack Emacs (even if it's dirty and adhoc).

I can however understand the frustration. It took me several attempts to pick
up Emacs and Org-mode specifically. And I'm still very often frustrated by it,
but I personally find being able to bend your editor into doing exactly what
you want worth the effort.

~~~
tra3
See [0] for for #5 (customized highlighting).

[0]:
[https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorg...](https://www.reddit.com/r/orgmode/comments/f7amq2/weekly_rorgmode_open_discussion_february_21_2020/fiacx88/)

------
corecoder
I've been a long time Emacs user since ~1997 until ~2011, when I started
developing mostly with ruby on rails on a mac, discovered TextMate and falled
in love with it, with its slick UI, freshness (at the time) of ideas, ease of
use, despite its obsession with mac based stuff, like the use of Finder for
project navigation.

After a few years I discovered Sublime Text, with its tons of extensions and
exceptional speed, bought a subscription and learned as much of it as
possible, ditching TextMate.

Then I switched to Atom, mostly for the discoverability and the speed (back
then) of development (and, frankly, for the hype). The only problem with
Sublime Text, at least at the time, was the slow development process: new
builds were few and far between.

I tried VS Code too soon, and wasn't impressed by how the navigation between
buffers used to work (it has changed since then, I think).

A few years ago I did a serious attempt at learning Vim for good, but in the
end I gave up, and I've come back to Emacs, this time to stay, unless
something radically new is introduced.

The good thing is that I can usually tell my coworkers about features of the
editors they use that they don't know, because I've used them a lot.

The only feature I miss from all other editors is the incredible speed of
Sublime Text: to this day, if I ever have to edit an SQL dump (which I hope I
will never ever have to do again), I'm surely reaching for Sublime Text, no
other editor can AFAIK open a 200+MB file without freezing and/or crashing.

The odd thing about Emacs is that its vastly superior customizability (or
malleabilty, as the article says) tend to be a trap, for one can spend hours,
and days, getting lost in its huge universe and falling into rabbit hole after
rabbit hole instead of actually getting stuff done, but I've not yet decided
if that's a bad thing or a good one.

~~~
fluffything
> I'm surely reaching for Sublime Text, no other editor can AFAIK open a
> 200+MB file without freezing and/or crashing.

For this I use the xi-editor. 20 Gb text file? No problem.

~~~
nerdponx
I didn't realize Xi was in a "usable" state now. What frontend do you use?

~~~
fluffything
It is usable for reading and editing files. Not something I'd use all day, but
if I need to edit a huge file, there aren't really great options for that.

------
svat
While I am a fan of Emacs (IMO any one of Org, AUCTeX, or Magit is in itself a
worthwhile reason to use Emacs, though of course the ease of customizing
nearly anything with just a few lines of elisp is the main comfort), I think
it's also worth looking at lessons from the _failures_ of Emacs — what
prevents or prevented Emacs from being even more successful? (As the post
says, Emacs's "success" is only when considered relative to other malleable
systems.)

~~~
afroisalreadyin
As a die-hard Emacs user, this is also something that has been occupying me
lately. There is too little thought going into the deficits of Emacs; many
people I convinced to give it a try went back to Sublime, VSCode etc. Emacs
has two main shortcomings, in my opinion. The first is that the visual aspect
of programming is completely left out. You can have nice outlines, pop-ups,
tree views etc. in most other editors; Emacs completely ignored these. The
main argument has always been "won't work in a tty", but there should come a
point where tty is deprecated or at least treated differently. The other is
evolving the language. Elisp was great for its time, but compared to modern
languages its age clearly shows. There are no namespaces, it can be dead slow,
support for networking is limited, regular expressions are weird etc. I think
there should be more work going into modernizing the language, which can also
be used to introduce facilities for GUI elements and networking code,
especially async.

~~~
zeveb
I strongly believe that TTY compatibility is a feature which should not be
discarded. But that doesn't, I think, prevent the kind of features you
mention: they just need to be first-class UI features like the minibar is.

Agreed that Elisp needs to be upgraded. I think that it should just be
replaced with Common Lisp, which has namespaces (packages), and is very fast,
and whose implementations support networking & threads just fine. Of note,
part of why Emacs regexps are so unusual is that they are pragmatic: since
they will be used to match Lisp source so often, () are not the metachars they
are in other regexp dialects.

~~~
kazinator
> Emacs regexps are so unusual

Parentheses are also not metachars in Vi (and Vim) regexps by default, and are
not metachars in POSIX BRE (basic regular expressions).

[https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03)

The grep utility, for instance, understands BREs by default; you must use grep
-E to get ERE (extended regex) in which ( and ) are grouping characters, or
else the deprecated egrep command (not in POSIX).

------
dmortin
The strength of emacs is that once you can program it it's extremely easy to
write extensions for it, even for one off tasks, because it's so quick and
easy.

Compared to this writing extensions for vscode, for example, is much more
convoluted. You wouldn't create a new vscode extension for a 1 hour task,
while with emacs it's trivial to write some small code which can help you with
your current task. I often do.

~~~
slightwinder
> The strength of emacs is that once you can program it it's extremely easy to
> write extensions for it

It's not easy by many miles. It's possible but learning the emacs-environment
to some aceptable level can take much time and toll.

> Compared to this writing extensions for vscode, for example, is much more
> convoluted.

Depends on your competence and tooling I would say. From what I've seen, it
isn't much harder than writing something midly complex for emacs, But very
simple stuff is easier done in emacs, something like single functions. But
those have the price that you need to learn emacs lisp on decent enough level
first.

But the question is, if you already can code, then why bother with creating
elisp-code or an vc code-extension? Today there is a good change that you
already known some useful tooling-language.

~~~
heinrichhartman
> It's not easy by many miles.

Depends on the perspective of-course. I mean, LISP is a real barrier, but once
you got over the parenthesis and suck-up some quirks [1], you can get
productive quite easily.

Here are two example extensions from my `init.el`.

    
    
        (defun hh-curl (url)
          "Create tmp buffer with curl output"
          (interactive "sURL: ")
          (let ((buffer url))
            (with-output-to-temp-buffer buffer
              (shell-command (format "curl -s %s" url) buffer)
              (pop-to-buffer buffer))))
    
        (defun hh-insert-date ()
          "Insert current date in ISO format"
          (interactive)
          (insert (format-time-string "%Y-%m-%d")))
    

It's really not all that much syntax. You can get interactive help by
navigating to a function call and press `C-h f`. Installation is trivial: Just
drop it to init.el.

Use this function my typing `M-x hh <tab>` to see all my extensions, if I
forgot the name. I have bound hh-insert-date to a key b/c I use it frequently.

[1] [https://www.heinrichhartmann.com/blog/problem-
lisp.html](https://www.heinrichhartmann.com/blog/problem-lisp.html)

~~~
slightwinder
I'm not talking about lisp or syntax. Learning that is fast. But this is
worthless. Learning syntax is fast in any language after a certain point of
knowledge.

The juice is in the batteries. The datatypes, the libraries, the environment.
Getting to know how to do the most simple things can be very cumbersome in any
language, and especially in something old and loaded like emacs.

There is a reason why popular external libs like s.el or f.el are so widely
used, and why emacs-projects itself has started modernizing on that front. But
those are things you don't know as a beginner.

~~~
robenkleene
After spending lots of time customizing various software from macOS to Emacs
to Vim to AppleScript to iOS with Workflow, I've come to the conclusion the
language and environment are practically irrelevant. There are simply two
kinds of people:

1\. People who complain about this or that problem in the environment (and say
that's why they don't customize it).

2\. People who learn and use the environment.

These two groups exist in every one of these communities. There just a fact of
life in the world of customization.

(PS: I'm trying to put this in the most neutral way possible, I'm trying not
to make any judgements here, personally I'm a customizer, but I'll be the
first to admit that I waste a lot of time customizing, and I won't make the
argument that customizing is inherently better, just that I prefer it. The
point is, the _very nature of customizing_ is what makes it hard, the quirks
of the individual environment just don't seem to make much a difference.)

------
agentultra
Emacs is more like an Elisp programming environment that happens to have a
text editor built in. And a window manager, process manager, shell, terminal
multiplexer, async event loop, cross-platform OS APIs, debugger, a bazillion
libraries for everything you could need.

Just to see how far one can go I cobbled together a few libraries one
afternoon and wrote a Dockerfile that enables one to write web applications in
Elisp:
[https://github.com/agentultra/Dockmacs](https://github.com/agentultra/Dockmacs)

I'm having trouble finding them but I've read stories of hackers developing
and deploying useful applications they built in emacs to end users. I don't
know that I'd go that far but... you do get cross-platform GUI controls so it
doesn't seem impossible for simple, straight forward tools.

~~~
NateEag
One you may be thinking of is that Amazon used an Emacs Lisp interface for
their customer service for a number of years.

[https://sites.google.com/site/steveyegge2/tour-de-
babel](https://sites.google.com/site/steveyegge2/tour-de-babel)

Search for "Mailman" to find the relevant bit.

------
Decabytes
One idea I've always wanted to try out if I had the knowledge and time is
creating a text editor in Racket that effectively worked like Emacs, but
instead of elisp you leveraged the language creation features of Racket. So
your init.el could be #lang Python and then you would configure it using
Python, or #lang Java or even #lang elisp. Of course all of those languages
are just being translated back into Racket but that's not the point. The idea
would be that you could customize the editor using the syntax you preferred.

There are definitely some cons to this approach. But the goals would be
accessibility and customizability for the end user especially people without a
programming background.

Oh and you could choose Emacs or Vim keybinding and all editor functionality
would be supported using either.

~~~
karlicoss
That's my dream! Do you know of any existing efforts towards it? I don't know
much about Racket, how would #lang Python thing work (i.e. in terms of calling
foreign functions etc)?

~~~
willghatch
As to `#lang python` interop with Racket, it's possible, but the farther a
language's semantics and object model differ from Racket, the harder and less
pleasant it is to build and use in practice. In other words, you need
converters between runtime values between Racket and Python when their
semantics differ. For example, Python strings are instances of Python's string
class, with a bunch of methods, and you can mutate the string class at
runtime. They are very different from Racket's strings. Then you have all the
differences in core reduction semantics, how concurrency and parallelism is
handled, etc, and there are a lot of differences to smooth over.

There is a project called PyonR
([https://github.com/pedropramos/PyonR](https://github.com/pedropramos/PyonR))
that implements Python 2.7 as a Racket #lang, but it hasn't been developed for
a while, and I'm not sure how interoperable it actually is. It certainly isn't
to the point where you could pull in your favorite Python package from PyPI to
use in Racket, but it does claim that you can use Racket functions in your
Python code at least. The hardest part just using PyPI packages is probably
that many of the most important Python packages lean on Python's C FFI, which
is a large extra hurdle, though there are many worthwhile packages that are
pure Python code.

The most successful Racket #langs are languages that fit a particular domain
or style of programming better than basic Racket, but that lean on Racket's
core semantics and object types as a building block rather than something to
be constantly slightly different from in ultimately unimportant ways. While
working with Racket, these languages may be very different from the core
Racket language, such as documentation languages (scribble), logic languages
(datalog), shells (rash), database query languages, etc. If you just wanted to
let people write new code for their editor in a language that looks and feels
like Python alongside Racket and its #langs, it would be a much easier project
to make a language with Pythonic syntax (syntax is shallow), easy constructors
for Python-like lists and such (just a few custom datatypes), and a Python-
like way of providing generic operators (eg. __magic_method__), etc, but
otherwise with semantics closer to Racket's. Frankly, you would end up with a
better language than Python anyway, with powerful features that most
Pythonistas haven't dreamt of. (Bias revealed!) But I do dream of having a
`#lang python` implementation good enough to just use Python packages in a
pinch when Racket doesn't have an equivalent package. It's possible, but it's
a big enough project and there is little enough manpower in the Racket world
that nobody is seriously working on it.

~~~
Decabytes
I agree with you. In a perfect world you would be able to drop in Python code
and only have to add a #lang Python at the top of it. But realistically I
think it would be closer to what you were saying about creating a pythonic
language.

So maybe the practical solution is to have a language that looks like Python,
Java, Ocaml, etc. I'm not sure how many #langs you would need to make the
majority of programmers feel comfortable but I think even implementing a few
would be a huge step up in accessibility than what we currently have.

------
haolez
Emacs is amazing. I stopped using it a few years ago because I became lazy to
keep my configuration and extensions up-to-date.

I was also extremely bothered by the fact that the cursor cannot live outside
the current viewport and scrolling the buffer would drag the cursor as well.
At the time, it seemed impossible to fix because of the way Emacs works, and
the solution was something like "you are using it wrong - you need to use
marks instead".

But I would love to go back to it, to be honest. VSCode is very good, but
Emacs is a whole other level of automation and convenience.

~~~
wtetzner
> I was also extremely bothered by the fact that the cursor cannot live
> outside the current viewport and scrolling the buffer would drag the cursor
> as well.

I can see how that would be annoying. I can also see why the developers might
not have noticed. When I'm in Emacs, I tend to navigate using the keyboard,
which means I scroll by moving the cursor and dragging the viewport with it.

So they probably added the ability to scroll without moving the cursor so
Emacs would have the feature. But if they never really used it, they wouldn't
have noticed the shortcomings in their implementation.

Sorry for the rambling, not sure if I really had a point to make ;)

~~~
haolez
If well configured, mouse support can be handful when navigating code. There
is a niche editor called Acme[1] that is almost "mouse-only", where even
Return won't put you in the next line :)

When using Emacs, my workflow was very keyboard-centric, but sometimes
navigation was a pain (even with tags and whatnot).

[1][https://www.youtube.com/watch?v=dP1xVpMPn8M](https://www.youtube.com/watch?v=dP1xVpMPn8M)

~~~
wtetzner
Oh sure, I'm not saying it's not a useful feature. Just an observation of how
different usage patterns can lead to blindspots.

------
nhojb
Author mentions web browsers and extensions in the context of barriers to
creating a successful malleable system.

Surely the web browser - considered in relation to web pages & technologies
(HTML, Javascript etc), rather than extensions - is perhaps the _most_
successful malleable system in history.

The core browser "functionality" has been and can be extended in an almost
infinite number of ways via web "pages". You could consider his dichotomy
between "foundational" features (unavailable to the user/tinkerer) and
extendable features to be comparable between Emacs (C vs elisp) and the
Browser (C++ [for example] vs HTML/Javascript/CSS).

I realise that to "extend" the browser by building a web page includes a great
deal more friction than playing with elisp in _scratch_. Does this rule out
the browser as a "malleable" system?

~~~
oefrha
Emacs includes a web browser out of box (just saying; I know its limitations).

~~~
henrikeh
Doesn’t that argument just indicate that web browsers are in fact more widely
used and “successful”?

------
miki123211
Emacs is malleable enough that someone implemented a whole screen reader in
it.

The basic idea is that you have a library that lets you stick your own code at
the beginning/end/around existing functions. So, someone did that for
functions responsible for moving to the next/previous line/word/character, and
they had a basic screen reader in place. In about 30 minutes.

Now, it's far more advanced, and, because of the malleability, you can "hack"
information out of someone else's code if they don't provide it to you
directly, which comes in very handy for such things.

As an aside, NVDA, the main screen reader for Windows at this point, is very
malleable too. It's written in Python, so extensions can modify anything they
wish. Amazing things have been built for it, including a whole remote access
package, team-viewer style.

------
timonoko

        (global-set-key (kbd "å")  'hippie-expand)
    
        ; Swedish "å" is useless in Finnish keyboard.
        ; After 40 years I finally understood I do not
        ; have suffer this injustice anymore. Quite logical
        ; because "ååå" pronounced in Gay Swedish way is an
        ; expression of frustation and indecisiveness.

------
Uhhrrr
For those who are intrigued by all of this, I will mention that the built-in
tutorial (Help->Read the Emacs Manual) and the intro lisp tutorial (Help->More
Manuals->Introduction to Emacs Lisp) are both interactive and very readable.

I've recently decided to start writing my miscellaneous scripts in Emacs Lisp,
both as a way to learn a lisp and a way to get more productive in a platform
which I expect to be around until I die. And it's pretty fun.

------
emit_time
I used emacs for a year and a quarter as a common lisp developer.

There was an integration into emacs from the compiler that provided support
for a lot of things like jumping definitions and seeing who calls, and it was
much better than the IDE IMO, in that syntax highlighting worked correctly for
one, along with the ability to use multiple buffers and windows.

I used it as my main place of development while I worked at that company, and
it was a pretty great pleasure minus a few issues.

I never tried using SLIME because our lisp didn't seem to automatically
support having project files being loaded into it, but I probably would have
had I stayed too much longer.

------
platz
I use emacs for two primary use cases:

\- Niche programming languages tend to have invested resources into building
an emacs mode for their language. Importantly, these emacs modes tend to be
maintained by core language contributors. In contrast, VSCode or other editors
tend to be community contributions which are discarded over a period of
months/years.

\- markdown editing

\- that's it (I've tried magit (too clunky/sensitive), org-mode (too much
lock-in), etc

On windows i find Emacs horribly slow to render text/buffer updates.

On linux it is blazing fast.

~~~
pvik
I find it weird that your point against org-mode is "too much lock-in".

It is a plain text format, which looks good even wherever it is viewed.

Pandoc even supports org-mode[1], which should let you convert an org-file to
say markdown if you want.

~~~
platz
sure, only if you stick to bare-bones org-mode. if you start using any of the
"power-features" unique to org-mode you're stuck. If you restrict yourself to
markdown-compatibilty, why not just write in markdown?

------
zestyping
Wouldn't there be a stronger argument for Excel?

Excel has probably put more programming power in the hands of more people than
any piece of software in history.

~~~
TeMPOraL
Malleability refers to the ability to make your tool fit your needs. Excel is
not as malleable a system as Emacs, but it's indeed one of the most powerful
tools out there.

------
UI_at_80x24
I've been curious about emacs, and tried it once without know what the hell I
was doing. But I've heard enough good things that I'm considering trying
again.

I run i3 and vim, so I already have my tiling WM dialed in, and I'm good
enough with vim that I don't struggle with using it. I have almost 0 interest
in learning Lisp, beyond what I'm willing to learn to make emacs fit my use-
case. I spend all day in terminal windows. I've heard about ORG-mode, and
wondered if it will help me become more organized.

I killer-feature of vim that I've edited into my work-flow is that I have it
auto-save a backup copy+time stamp of any file I save. It's a VCS-style hack,
that 'works for me' and I think it is a better fit then git would be under the
situation. (i.e. httpd.conf_2020-04-15_14:10:01)

Can a similar hack be incorporated into emacs?

~~~
hexmode
Yes.

Though, I would say, you should really look at something like
[https://github.com/ryuslash/git-auto-commit-
mode](https://github.com/ryuslash/git-auto-commit-mode) so your directories
don't get cluttered with save files.

------
rbanffy
> Note: Geoffrey Litt’s post on browser extensions takes a different point of
> view, considering browser extensions as a way to modify not browsers but Web
> applications.

This one rang a bell. When I was working for Canonical, I built an extension
to make Launchpad more comfortable for me. It still has some users (but
probably needs a lot of fixing):
[https://chrome.google.com/webstore/detail/launchpad-
tweaks/p...](https://chrome.google.com/webstore/detail/launchpad-
tweaks/pinhffhfibgmfgjjafafhiaegdmomhhk)

------
nickdrozd
> Lesson #1: Provide significant out-of-the-box utility

There has been a push to move certain modes out of the core Emacs distribution
and into package repos, I guess because it makes it makes them easier to
maintain. Emacs comes with a Python mode, for example, and that conceivably
could go to ELPA. But not everyone has access to package repos, and switching
from a kitchen-sink model to a framework-for-external-repos model would make
Emacs far less useful for such users.

~~~
dmortin
Only a tiny minority of users can't access package repos. They can download
the packages at home and mail themselves in a zip file.

It's trivial to create a zip file containing the necessary files, plus a
config elisp file which has the personal customizations.

~~~
nickdrozd
> Only a tiny minority of users can't access package repos.

That sounds like a verifiable claim. Do you have any proof?

~~~
dmortin
Only my personal experience. I never encountered a situation in my
professional life where I couldn't access the net.

How is it verifiable? Is there some statistics of this?

~~~
zeveb
You must never have worked on airgapped systems then. Or had to justify non-
standard software to gatekeepers.

~~~
catalogia
Surely workers in airgapped systems are (objectively) a minority, if not a
tiny minority ('tiny' is subjective..)

------
dan-robertson
Emacs is an excellent malleable system because elisp is an excellent
programming language.

A few important qualities that make it particularly good for this sort of
environment:

1\. Dynamic scope. Dynamic scope (aka special variables) means that if I
locally bind the variable foo to bar, that binding is available for the
dynamic extent of the let (ie a function deep in the call stack may access
that binding of foo even if it was not defined lexically inside the binding).
This allows passing state or options or configuration between different places
which are amenable to extension, or modifying the behaviour of existing
features by temporarily modifying their state. In other systems these problems
may be solved by using lots of arguments, special mechanisms for passing
custom parameters around, or well defined protocols to extensions with their
own state. In those alternatives the fallback is either to impossibility or to
storing state in poorly managed global variables. Elisp handles that “local
global” state better and eg makes sure it correctly deals with multiple
bindings or stack unwindings. One example usage would be for some custom
comment syntax. You can just (locally) bind custom values to the variables
which define the comment syntax and then call the usual comment function.

2\. Hooks are very natural data structures which extensions use to make
explicit extension points. Because books are lists, they may be conveniently
dynamically bound (e.g. (let ((foo-hook (cons blah foo-hook))) ...)).

3\. Buffer-local variables attach arbitrary state to each buffer and make it
available as global variable bindings when that buffer is current. The
alternative would be less begged local state, state attached to many more
different things, and doing lots of requests for current-buffer.state.foo.
Maybe these would make you think more about the current buffer changing but
I’m not sure thinking about the problems leads to less buggy code. Buffer
local variables makes writing modes easier and it makes it easy to not have to
care much about the existence of other buffers while still easily being able
to write code that spans multiple buffers.

4\. Advice. Advice is like complex hooks except you can put it almost
anywhere. You can “advise” any function with extra code to run in various
places (eg before, after, around, just modifying the arguments, before but the
advice is and’d with the function so if it returns nil the function isn’t
called, and so on). This lets you tweak just about anything. For example I was
using a build-managing mode which was not so extensible but by advising
process creation I could modify its behaviour to nice the compiler executable.

5\. Various save-restore macros. This could be done with first class functions
but programming against the macros makes common idioms so much easier. Maybe
an argument could be made that not having global state would make things a lot
more manageable but I think macros like save-excursion, with-temp-buffer, and
so on generally keep things under control

6\. Most state is globally accessible. By this I mean most variables are
special, and there is lots of important state which is global or buffer local
like the point, mark, window configuration, or current buffer. This means that
the current state is generally available to any extension code that runs and
not kept private to some other bit of code (prohibiting extensions from
getting at it). It allows most behaviour to be tweaked.

7\. Recursive editing. It’s just really nice that you can pause half way
through your program, have some editing done, then resume where you were: the
user may live inside as well as outside the elisp call stack. Though mostly
this is infrequently used.

8\. Simple data structures. Because most things are text in buffers, you
generally move around this data structure in a rough way (search forward for
this, edit that, and so on) which is resilient to that data structure being
changed/extended under you.

It’s curious that a lot of these qualities are generally considered terrible
features for writing maintainable code. This is because maintainable code
generally wants different things to not be able to affect one another much. If
you want an extensible, malleable system, it probably makes sense to have
things which are easy to modify the behaviour of from just about anywhere.

~~~
rgrau
Nicely written summary!

This paper was written by Richard Stallman in 1981 and delivered in the ACM
Conference on Text Processing which touches on all of your points and a few
more: [https://www.gnu.org/software/emacs/emacs-
paper.html](https://www.gnu.org/software/emacs/emacs-paper.html)

~~~
dan-robertson
It doesn’t mention some of the newer things like hooks.

I love how much emphasis there is on efficiently updating the display. That
mostly isn’t a problem these days (indeed it’s somewhat likely that emacs is
slowed down by trying to compute efficient updates instead of just sending out
the updates as soon as possible)

~~~
dan-robertson
By hooks I meant advice

------
rvr_
what about minecraft? seems way more successful and malleable

~~~
philote
Yep, with vanilla minecraft you can make a ton of interesting changes to the
game using command blocks, redstone, etc. And then you have to consider
modding, which opens up infinite possibilities.

~~~
gimboland
Plus redstone is much easier to read than elisp

~~~
catalogia
I find it to be riddled with limitations and oversights. For instance, why
can't I fill cauldrons with dispensers?

------
mgummelt
I think that title must go to Excel.

~~~
rini17
Excel is malleable? Not really. For example while it is possible to port org-
mode to excel, AFAIK nobody did it.

~~~
oblio
They built ray tracing engines and games and whole financial systems in Excel,
it's possible. Probably nobody cares to do it as "org-mode" for Office is
called Outlook ;-)

------
gdubs
Does anyone have a favorite example of the coolest thing done in Emacs /
coolest, most interesting configuration?

------
bullen
Sure, would be nice if there was an alternative to install that didn't need a
MySQL client though!

