Revisiting Emacs
----------------
date: 2022-11-15 14:09:59 EST

## In the Beginning

As a Vim nerd, Emacs has been on my radar for as long
as I've been nerding over text editor productivity
(probably ~5yrs ago towards the end of college).

In fact, my journey with Emacs starts much earlier.  My
second semester of college, we had a systems
programming course where the first couple labs were on
a VM. I remember SSHing in, sitting in my dorm hallway,
and thinking to myself "now what"? That moment of
hopelessness when you realize that all the files aren't
on your local filesystem and you can't use whatever
editor you are accustomed to (I must have been using
Eclipse at the time, since Java was the intro
language).

A friendly neighbor said "oh just type 'emacs FILE' to
get an editor". And so it was that I used emacs years
before touching Vim.

The subsequent labs ended up adding a graphical desktop
to the VM with Sublime Text installed, so I didn't end
up diving deep into Emacs, but it was there first.


## Over the Years

I vaguely recall trying out Emacs around the same time
I was getting very into Vim. It's sad to say that I
very much fell for the tribal nature of the argument
and swore affiliation to Vim before giving it an honest
try.  There were all sorts of politics involved
too. Who was this RMS guy? Do I agree with his beliefs?
(this predated the scandals, which are out of scope of
this piece).

At the time, and for the years to follow, I was sold on
the fact that Vim was _efficient_. I bought into the
"Emacs is the whole toolshed and Vim is a paring knife,
much more efficient for surgical edits" saying.

When I made it into industry, I was surprised to find
that the majority of my team were Emacs enthusiasts. I
resisted and became the Vim holdout (this has been the
only team I've worked on with this situation--now it's
much more a Vim holdout vs VSCode). Vim was already in
my fingertips, and I knew all the power features
(:tags, :jumps, etc).. why learn something new? I gave
evil-mode a spin, but it felt a bit "off". All too
often I'd pop into a buffer in another mode (like
Magit) and find myself completely unable to switch back
with vim-like window motions (and at a loss of how to
proceed).

To top it all off, I was convinced Emacs was very much
against the UNIX philosophy--it didn't do one thing
well! Who needs tetris in a text editor? I became
interested in minimalist computing (suckless, cat-v,
etc) where Emacs was the butt of many jokes.


## Coming Back

Over the past few months (but really dating back
years), I've become more and more interested in LISP,
specifically Scheme, and it led me back to Emacs.

Now, I think it's totally possible to write LISP in
Vim. But there is a natural tendency for LISP lovers to
find themselves using Emacs (and therefore the support
is much better). I chalk this up to the fact that LISP
isn't used much in industry, so Emacs is maybe one of
the few chances these developers have to use the
language in earnest. Maybe that's an over
simplification.

Mind you, it wasn't _really_ the promise of
extensibility or customizeability *in the editor*. I
had achieved "config equilibrium" with Vim; I had a
small core set of plugins to be effective and knew the
editor inside and out--my vimrc remained untouched for
months at a time. The thought of _having_ to write
hundreds of lines of elisp to customize an editor
seemed wasteful.

BUT, what I came to realize is that Emacs isn't about
customizing *an editor*. It's about customizing a LISP
platform for everyday productivity (beyond the scope of
editing). Things like Email, IRC, gopher clients, web
browsers, directory managers, and more are all written
on Emacs *not* for the benefit of the editor, but
because it's fundamentally a platform for applications
(just like the browser has become a platform for web
apps).

The thought of a LISP platform, with a whole suite of
discoverable, self-documenting, FOSS LISP apps is
definitely appealing. Although I am still relatively
partial to the "write one tool to do the job well"
approach, I suppose you could argue that the elisp
packages do one thing well on top of Emacs.

I thus set out to give Emacs a fair shot.


## An Example Productivity Flow

If we move beyond productivity during text editing,
what does productivity look like? For me, the answer
was usually shell scripts to automate redundant
processes.


A great example of this is my 'phlog' script described
in [1] to start a new phlog entry:

```
die() {
    echo "$*"
    exit 1
}

[ -z "$1" ] && die "usage: phlog TITLE"

PHLOG=$(dirname "$(dirname "$(readlink -f "$0")")")/phlog

i=1
nextfile() {
    file=$(printf "%03d.txt" $i)
    : $((i+=1))
}

title="$*"
underline="$(echo "$title" | sed 's/./-/g')"

nextfile
while [ -e "$PHLOG/$file" ]; do
    nextfile
done

echo "$title" >"$PHLOG/$file"
echo "$underline" >>"$PHLOG/$file"
date >>"$PHLOG/$file"

ed  "$PHLOG/index.gph" <<EOM
/^\[0|Atom Feed/+a
[0|[$(date +%F)] $title|/phlog/$file|server|port]
.
wq
EOM

exec "${EDITOR:-vi}" "$PHLOG/$file"
```

This simply makes it so that no matter what I'm doing,
I can open a new phlog entry (without having to keep
track of what number I'm on, or update the index, etc).

The script is definitely hacky though. It uses some
obscure shell syntax for incrementing variables, sed(1)
for string substitution, ed(1) for editing the index
and local-looking global variables (`file`).

Even with just ~1hr of elisp experience, I was able
to put together the same flow that (IMHO) reads much
cleaner:

```
(defun phlog (title)
  ;; Allows M-x phlog and prompts for title (passed as an argument)
  (interactive "sTitle: ")
  ;; Parse the directory for TXT files (sorted) to get new filename
  ;; (corresponds to nextfile loop in shell script)
  (let* ((files (directory-files phlog-root nil "\.txt$" nil))
	 (most-recent (car (last files)))
	 (new-name (format "%03d.txt" (+ 1 (string-to-number
					    (car (split-string most-recent "\\.")))))))
    ;; First update the index (corresponds to ed(1) script above)
    (with-current-buffer (find-file-noselect (concat phlog-root "/index.gph"))
      (goto-char (point-min))  		      ; go to beginning, if already open
      (search-forward "Atom Feed")
      (next-line)
      (insert (format "\n[0|[%s] %s|/phlog/%s|server|port]"
		      (format-time-string "%F" (current-time))
		      title
		      new-name))
      (save-buffer))
    ;; Now open it in a new file (corresponds to echo/date/exec vi)
    (find-file (concat phlog-root "/" new-name))
    (insert (concat title "\n"))
    (insert (replace-regexp-in-string "." "-" title))
    (insert (format "\ndate: %s\n" (format-time-string "%F %H:%M:%S %Z" (current-time))))))
```

When you factor in the ability to exec parts of these
as I developed the function (or in the scratch buffer),
the development experience for the function was much
better too.

To top it all off, while this function doesn't
highlight it too well, it's clear that the interaction
capabilities of Emacs (with the minibuffer,
completions, etc) are way beyond that of a shell script
(reading args or from /dev/tty, etc).

All in all, I think if I'm going to keep using Emacs, I
could see myself having dozens of these small custom
commands to allow me to quickly phlog, blog, or keep
todo lists up to date (etc).

[1]: gopher://alexkarle.com/0/phlog/011.txt


## The Catch

This is all great for customizing my personal
environment, but the reality is that Emacs users are
very much in the minority.  Shell scripts have "won"
because all devs are comfortable running them in a
terminal. They're the lowest common denominator.

So when it comes to _shared_ productivity, Emacs feels
like a nonstarter. Any team productivity tools will
need to be first written in shell scripts for the team
and then duplicated into Emacs, not built primarily
for Emacs.


## Conclusion

Only time will tell if I continue to use Emacs. I think
I'll play around a bit more. I definitely "get" it more
than I did before, but I'm skeptical of the investment
required to customize my own environment (vs investing
that time into shell scripts that can be shared).

This all said, it's worth mentioning that I'm no longer
a big believer in customizing the Vim environment
either (for largely the same reasons). If anything,
part of what drew me to Emacs was the feeling that the
(Neo)Vim family was becoming just as "bloated" but with
a lesser ecosystem:

* The addition of the Vim9 language (instead of using,
  say, Lua) felt like a misstep for Vim proper

* NeoVim (and now Vim) having a Terminal feels like a
  violation of the editor boundary (more like Emacs)

* With the above two--why not just use Emacs? I checked
  and the core of NeoVim is ~300k LOC of C and the core
  of Emacs is ~400k LOC of C--Emacs then has >1M LOC of
  LISP, but if the core is solid and makes a hackable
  platform, isn't that a properly designed
  platform/system? (note: didn't try to weed out test
  code, used David Wheeler's SLOCCount)

In other words, Vim and NeoVim feel like they're
gravitating towards Emacs, but with a fragmented
community and a less capable extension language (even
if they have a better core editor).

I wonder if Emacs will have a revival? (but such a
discussion needs to discuss the elephant in the room:
VSCode, and that requires a whole other post!).