
Emacs Users Are Like Terry Pratchett’s Igors (2013) - signa11
https://chrisdone.com/posts/emacs-users-are-like-igor/
======
ludwigvan
Emacs is the ultimate example of free software. You really do feel free in
emacs, experimenting, tweaking.

Free as in breathing, free as in drinking water. Code is such an integral part
of life that it is unthinkable that we cannot have control over it. Emacs
gives you control, it gives you freedom.

I am amazed how Stallman got it right and invented on his principles. Thank
you Dr. Stallman, thank you.

~~~
bin0
> Dr. Stallman

rms has a doctorate? Or is this some sort of honorific I've never heard
before?

~~~
ludwigvan
Right, he has multiple honorary doctorates according to Wikipedia.

------
dmortin
People who don't know how to program emacs don't get how easy it is to write
some code in it to make your life easier.

Some say Atom and VSCode also have plugins. That's true, but can you write
code to extend some VSCode functionality in a minute?

You just go to the scratch buffer, write some code, evalute it and it
instantly becomes part of the editor. I don't know if there are other editors
which can replicate this experience.

~~~
atdt
Can you recommend a good starting-point for learning emacs internals?

~~~
dleslie
Not OP, but the Emacs manual is excellent[0] and there's Mastering Emacs[1]
and Sacha Chua's blog[2].

Because it's lisp you can inspect just about everything. See an unfamiliar
symbol? Put your cursor on it and press M-.

0: launch help from within Emacs

1: [https://www.masteringemacs.org/](https://www.masteringemacs.org/)

2: [https://sachachua.com/blog/emacs/](https://sachachua.com/blog/emacs/)

------
invalidOrTaken
To digress a bit, on the Lisp curse, and freedom more generally:

In the HyperCard thread on the front page right now
([https://news.ycombinator.com/item?id=20550189](https://news.ycombinator.com/item?id=20550189)),
someone linked a talk
([https://www.youtube.com/watch?v=9nd9DwCdQR0&feature=youtu.be...](https://www.youtube.com/watch?v=9nd9DwCdQR0&feature=youtu.be&t=998))
on the history of educational software, and one of the presenters said
something like, "Some technologies we are simply not mature enough for."

I think this is not a bad description of "the Lisp Curse." I _definitely_
wasn't mature enough for Lisp when I first learned it---high on my knowledge
of what was possible, surrounded by myopic fools, as I thought.

But that was years ago. I'm mature enough _now_. It is possible.

In my consulting work my partner and I have marveled at how managing
technology projects is a skill --- learnable, but only with some effort and
practice, and carrying relatively heavy requirements of being technically
competent _and_ having a context of the business.

That's the skill that's needed, IMO, to make Lisp "work." Lisp itself---and
Clojure---are really not complicated languages. My boss teaches them to
undergrads and they can be productive fairly quickly. They _are_ complicated
when someone has built a crappy, leaky tower of abstractions on them.
Recognizing when you're in danger of doing so, and when it's not worth it
given other factors (business value, maintainability, etc) is the key.

So I wonder, idly, if metaprogramming---no, _really_ , the _meta of
programming_ , like "Don't Call Yourself A Programmer"
([https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-
pr...](https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)
) and "Developer Hegemony" ([https://www.amazon.com/Developer-Hegemony-Erik-
Dietrich/dp/0...](https://www.amazon.com/Developer-Hegemony-Erik-
Dietrich/dp/0692866809) )---might develop some more, esp. among the Lisp
communities. When the language is no longer the barrier, you start to realize
that other things _are_.

------
melling
Emacs is 43 years old. When it was written, the kernel had to be written in C.
Elisp is slow.

It’s probably possible today to write an Emacs in a high-performance Lisp.

Elisp has no support for concurrency, for example.

“Some 359,000 lines of C code comprise its kernel, and 1,637,000 lines of
Emacs Lisp take the rest of it.1”

~~~
creato
Whenever I open a file of code that is ~2000 lines or more, emacs slows to a
crawl. It takes 5 seconds to redraw the visible text after hitting "page up"
or "page down".

I don't think emacs should be made any slower than it already is.

~~~
dmortin
> Whenever I open a file of code that is ~2000 lines or more, emacs slows to a
> crawl.

Then there is something wrong with your environment. Emacs has no problems
with big files. It can have problems with very long lines, but big files
shouldn't slow it down.

~~~
slightwinder
That's not true. Emacs has several problems with big files. Though, to be more
specifically, built-in minor-modes have them. So it depends on whether you run
a bleak vanilla emacs without anything, or a mildly comfortable emacs with at
least something like fontlock-mode and stuff.

But, 2000 lines are really not that much. Usually problems on my systems start
to show at >10k lines.

~~~
IronBacon
Syntax high-light pays its tool on not so huge files, but I remember opening
without slowdowns files with around 100K lines in text mode (mostly log
files).

Not exactly related but with Emacs 27 will be distributed the so-long mode
that could toggle minor modes that affect redrawing like "font-lock", "visual-
line", "whitespace" when files with long lines are opened:
[https://git.savannah.nongnu.org/cgit/so-long.git/plain/so-
lo...](https://git.savannah.nongnu.org/cgit/so-long.git/plain/so-long.el)

~~~
IronBacon
Clearly I meant "toll" not "tool" above...

------
agumonkey
Very nice last line.

Also, I disagree about the 'lisp makes people selfish'. It may be true at
first, but I dearly believe that every long time lisper on earth is totally
aware of that and knows where to draw the line. It's been discussed to death
early on and regularly since. We all enjoy the freedom to fool depth first
into every idiosyncratic itch we think of, but we know that they're most of
the time only that. And that others can give different views on a similar
problem, yielding a more generic notation/solution by blending all attempts.

It does cost a bit though, for instance scheme lack of standard module (until
recently IIUC) forces one to work a bit more, or maybe port by hand. But very
often, lisp libs are tiny. I still remember the article from early 2ks about a
guy searching for graph libraries in java. Found 3, none of them was good
enough, in the end he wrote his own in CL in a day. There's a cost of sharing
too.

------
maheart
In my opinion, Emacs is the only piece of software that I've ever used that is
truly self-documenting. Once you learn about Ctrl+h {c,f,v} you can "lookup"
what every key-combination, function and variable does. I don't think I've
ever used a piece of software that's close to it in this regard.

------
celeritascelery
using emacs was so revolutionary for me because I had never before thought
about building an editor that fit my workflow. Before it was always trying to
fit my workflow to fit my editor. The potential in emacs to be anything I
wanted it to be was mind blowing.

~~~
bdamm
How did it turn out?

~~~
celeritascelery
Great. I am still using it to this day. Even when I switch jobs or switch
products, I just change Emacs to match my new workflow.

------
blipblap
I lack even a reference for the sorts of things that can be done. How have
Emacs users here customized their workflow?

~~~
brians
A huge amount is taking preweitten plugins—someone upthread said you should
just learn your editor’s existing feature set, and this is true.

But I use Emacs as a mail client—message mode is awesome—and extended it with
a procedure to create text/html parts and all the necessary MIME headers. I
especially like using that for tables that are readable in monospaces
text/plain or as HTML tables. Compare that to a GUI mail editor, which surely
defaults to HTML but which probably isn’t going to offer you tabular support.

Let’s see. I have some fine control over white space in here, to meet
different collaborator’s guidelines. And that integrates with the magit git
front end.

I have a bunch of macros driven by the abbrev autocorrect scheme.

But in reflecting on this, the big important category is “Other”. I write 5-50
line programs, sometimes starting from a macro recording of one run of the
core loop, weekly.

Imagine a world where general spreadsheets didn’t exist; you had accounting
software but it was all like TurboTax or quickbooks, very hard wired for a
purpose. And imagine asking how users of Excel customized their workflows, as
they tried to explain that the point was the total flexibility. Emacs is like
that for text files.

------
robocat
I use VS Code and in theory I can modify the source code: it _should_ be as
simple as editing source code within the developer tools of Chrome.

However the tooling for VS Code is absolutely nothing like the Emacs REPL
(however disclaimer: I haven't used Emacs for a very long time)

------
asimilator
Every time one of these articles about Emacs is posted here I kind of shake my
head and wonder why my experience with it is so different.

So big caveat: my experience with Emacs is pretty much entirely limited to
org-mode (which is the only reason I picked up Emacs at all). I really liked a
lot of the ideas in org-mode, but the more I used it the more I really wanted
to make some minor tweaks. No problem, I thought. Emacs is famous for being
super customizable. But everything I touched was extremely brittle, and
essentially impossible to configure to work as I wanted it to.

1\. Wasn't a huge fan of "\star" "\star\star" "\star\star\star" as the
headlines. I would prefer "\t\star" "\t\t\star" "\t\t\t\star". Hmm, seems the
only way to do this is a hack that changes the leading stars to the same color
as my Emacs background. That's kind of hack-y. The rationale I could find for
this was to keep a consistent on disk format. I guess that makes sense, though
it's not something I care about ... I don't intend on sharing my TODO list
(and my understanding is there's no 100% compatible org-mode parser outside of
Emacs anyway). Not a big deal, I'll live with it.

2\. Agenda view. As I started using org-mode more and more for task management
I decided I needed a good task view. I set my own task and project states
(nice: simple, works) then I set to work on creating a nice view of all my
tasks organized in separate sections (REFILE tasks, active projects, active
tasks). Hmm, now it takes multiple seconds to refresh my agenda view. And I
have to manually refresh it any time I make a change to any file ... This
kinda sucks. Might be a solution for this, never got around to investigating.

3\. File structure for my org files. Despite the occasional org-mode article
on Hacker News, it's actually pretty hard to find good examples of a full org-
mode workflow. When I was actively working on this I found one or two. When
writing my org files I kept running in to the odd problem with certain
features because of how I was laying out my files. Should there be an empty
line after a headline? Are paragraphs separated by empty lines? If you don't
do this correctly (and since there's so few examples available, "correctly" is
something you have to figure out by trial and error) then certain exporters
(pdf, html) don't give correct output, or folding doesn't work.

4\. Directory structure of my org files repo. I like being aggressive about
breaking things up in to different files. And then organizing these files in
to different directories. New project? New directory, new project org file.
Let's make a separate file for research. So <PROJECT DIR>/Research.org.
Unfortunately this butts up with how org-mode assumes you have things
organized (which again, you can only really figure out by trial and error when
things don't work). Take REFILE for example. It tab completes by file name.
But problematically I now have a lot of files with similar names (e.g.
Research.org) in different directories. org-refile-use-outline-path sort of
fixes this but it's still clunky.

5\. Emphasis. The straw that broke the camel's back. All of the above were
minor and I kept with org-mode. It sorta worked. But I was annoyed. Eventually
I started doing some research that involved quotes where I really wanted to
basically highlight phrases or sentences that were important. I figured this
would either be built-in to org-mode or easily added in my Emacs conf. I never
did find a solution that actually worked. I can underline, italicize, bold,
etc, but no highlight (i.e. classic yellow background for text). Apparently
org-mode deliberately prevents the end user from adding their own custom
emphasis formats in order to have a consistent file format.

At this point I left org-mode and emacs all together and ended up writing my
own rich text editor so I could do whatever formatting I wanted. It doesn't do
1% of what org-mode can, but dammit I can highlight in 6 different colors.

I'm disappointed I never got to experience the Emacs nirvana that all these
articles describe. Maybe it's just org-mode, but everything I touched seemed
extremely brittle. Felt very much like I was forced to do it the org-mode way.
It was really disappointing.

~~~
brians
Yeah. Org-mode’s nature is pretty different from Emacs’. I don’t feel that way
about Gnus, weirdly. I wonder if I’m missing something there. Helm, like org-
mode, is from people getting something pretty different out of Emacs than I
am. That’s okay! I just wish we had better terms to describe it.

------
new_realist
Can anyone recommend an editor like Emacs that doesn’t use LISP? I find the
syntax to be an abomination.

~~~
dmortin
If you use it for a while you get used to it. It's just another programming
language.

~~~
celeritascelery
Second this. The parenthesis look abhorrent because they are foreign, But that
is where the real power of lisp resides.

------
otterley
(2013)

------
pac39
The big issue with elisp is how alien it is to read code in it with so many
parens and the tendency by elisp programmers to inline huge gobs of code in
function calls.

~~~
vemv
> the tendency by elisp programmers to inline huge gobs of code in function
> calls

Observation on point, and ironically it limits the ability for developers to
tweak third-party software (what if you want to change some aspect _in the
middle_ of the large code gob?)

~~~
celeritascelery
That's where I found this[0] packages so useful

[0][https://github.com/raxod502/el-patch](https://github.com/raxod502/el-
patch)

------
saagarjha
I wonder how “hackable” Electron editors fit in to this: might they be emacs
for the masses?

~~~
sachdevap
Someone else[0] has answered your question, I think.

[0]
[https://news.ycombinator.com/item?id=20551432](https://news.ycombinator.com/item?id=20551432)

------
andrewstuart
It sounds, from this description, like Lisp is similar to Perl - "There's more
than one way to do it". i.e. extremely flexible, and the outcome is a lack of
coherence, such that my Lisp code might look substantially different from
yours, making it a nightmare to maintain.

I'm pretty sure that if I found myself doing development on my editor then
this would be a form of procrastination because modifying the editor certainly
ain't developing product related functionality. For me it's more effective to
ignore or work around failings in my editor, or better yet, invest some time
in trying to learn in more depth the functionality that is already present in
my IDE that might approximately meet my need.

~~~
msla
The codebase is as coherent as the author wants it to be, without the language
imposing metaphors like objects or a pure functional style where they're not
needed. Lisp won't force you to write bad code, but that means it can't force
you to write good code, either: If your Lisp code is incoherent, that's on
you.

~~~
andrewstuart
>> If your Lisp code is incoherent, that's on you.

It's actually on anyone who comes after.

That might be just me, or if the code is public it could be anyone.

~~~
stan_rogers
The phrase "that's on you" means "it's _your_ fault".

