screwlisp proposes kittens

Writing Experience - my eev & org comparison for emacs carnival

An emacs carnival contribution.

I haven’t used orgmode in a long time by now. So I have at least the idea of not doing that to offer this carnival! I got to know Eduardo’s eev instead and now orgmode doesn’t make much sense to me any more. You can tell by my particular handy orgmode link that I used to use it some amount or other before.

What I write when writing is a mixture of my memories, motivations and reasoning about whatever computer program I am working on in that moment interspersed with me doing what I am rhapsodising about.

Recently, I wrote an example of using sbcl’s sb-ext:save-lisp-and-die while in emacs’ slime-mode for example. Let us study that a bit.

«My own writing about saving lisp and dying» (to “.My own writing about saving lisp and dying”)

The broad point I was making is that on the historical lisp machines, your lisp universe was persistent between boots and that writing and loading additional text files by hand is not obviously an improvement over that persistence. Well, in that article I started a shell

‱ (eepitch-shell)

navigated to the home directory and started sbcl

cd

sbcl

built the expected slime-swank path

(merge-pathnames #P"~/.emacs.d/slime/" #P"start-swank.lisp")

(implicitly in that sbcl in that shell now) and loading said path, starting swank:

(load *)

(On the right half of the screen, I see this happening, not automatically put into this document I am writing:

$ sbcl
This is SBCL 2.2.9.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (merge-pathnames #P"~/.emacs.d/slime/" #P"start-swank.lisp")
#P"~/.emacs.d/slime/start-swank.lisp"
* (load *)
WARNING:
   redefining EMACS-INSPECT (#<SB-PCL:SYSTEM-CLASS COMMON-LISP:T>) in DEFMETHOD
;; Swank started at port: 4005.
T
*

)

then connecting to it explicitly in more emacs lisp (red star lines)

‱ (slime-connect "localhost" 4005)

and switching my eepitch to that

‱ (setq eepitch-buffer-name "*slime-repl sbcl*")

you will have to visit that article to learn the thrilling conclusion. It’s

(get-decoded-time)

/

* /
(11 48 22 26 7 2025 5 NIL -12)

This time right now and the 22 means it’s pretty late so let’s get to

«Doing that in org mode» (to “.Doing that in org mode”)

But what would this even mean? We can demarcate a source block and type in eshell for the type

#+begin_src eshell
#+end_src

after which C-c ' will enter that by opening an eshell, whence we can type in cd, sbcl, etc. closing the block with C-c ' helpfully volunteers to leave the active process in it running as we hypothetically need. But this wasn’t very literate programming because we left the document to write something important to the document. There might be some even more advanced orgmode eshell useage but I at least don’t think it would be very typical of the rest of orgmode.

Well, lets say I started sbcl in the C-c ' of that eshell source block and left it running to match my eepitching above after all. I could slime-connect (and enable lisp)

#+begin_src emacs-lisp
  (slime-connect "localhost" 4005)
#+end_src

and I suppose I’ve already customize-variabled org-babel-load-languages to include lisp for

#+begin_src lisp
  (multiple-value-list (get-decoded-time))
#+end_src

#+RESULTS:
| 53 | 6 | 23 | 26 | 7 | 2025 | 5 | NIL | -12 |

; since the repl isn’t being used, we don’t have / at hand like eev did.

«Differences observed between literate programming writing using eev and org» (to “.Differences observed between literate programming writing using eev and org”)

A main one is that eepitch doesn’t know anything about compilation itself. You point eepitch-buffer-name at another buffer, and then when you tap <F8> on a line, it pops to that buffer in the other half of your screen; literally enters the line there, and pops back (and goes down a line). Only emacs lisp (the red star lines) just put results in your minibuffer.

Whereas org-mode uses your writing buffer for results (or whatever your personal complex :output stipulation is), possibly as a beautiful org table as we saw. Orgmode also is the thing that organises tangling and compilation of your source, so that infrastructure goes in your orgmode markdown document as we saw with #+begin_src lisp. A three line eepitch would involve pressing F8 three times to send line by line to the right half of your screen, in contrast.

When I want to continue something I began above, in eev the repl where it’s happening is dominating the right half of my screen while I’m writing. Since it’s a lisp repl I can grab the second last multiple returns again as such

//

* /
(11 48 22 26 7 2025 5 NIL -12)
* //
(11 48 22 26 7 2025 5 NIL -12)
*

though I then have to copy over what I want from the buffer on the other half of the screen. In contrast in orgmode we name things

#+name: dateable
#+begin_src lisp :results drawer
  (multiple-value-list (get-decoded-time))
#+end_src

#+RESULTS: dateable
:results:
(46 37 9 27 7 2025 6 NIL -12)
:end:

after which

#+CALL: dateable()

#+RESULTS:
:results:
(18 38 9 27 7 2025 6 NIL -12)
:end:

to call it again later in the document. This is great but I feel like I have learned and am writing a language other than lisp!

Anchors in eev work like I’ve been using - an eev anchor, such as my headings, are an emacs lisp function that jump to the moveable other-end-of-the-anchor when evaluated (M-e in eev, C-c C-e in non-eev) which are duplicatable, but they only ever find the first-other-end to navigate the document:

(to "Differences observed between literate programming writing using eevandorg")

whereas in org-mode we fold org headings by mashing shift-tab, or navigate by C-c C-p/C-c C-n and so forth instead of using emacs’ C-u 1 C-x $.

«conclusions» (to “.conclusions”)

(Oh, it’s C-S-A on a line with prefix <anchor text> to generate anchor pairs in eev - I’m still working on my header/anchor idiom though)

both modes work extremely well as a webpage (or gopher text item) visited inside emacs for doing-things-in-that-emacs.

When dealing with code, eev sends the code somewhere else, whereas orgmode has orgbabel to deal with compilation, printing results, :noweb yes tangling and so forth which eev doesn’t involve itself with doing. This makes orgmode quite powerful but it’s a different language, and needs lots of syntactical support compared to eepitch. eepitch’s simplicity and directness also make it possible to use in novel and surprising ways.

I genuinely hope that the reader considers to try writing with eev homed in modes other than orgmode. It’s a bit shocking that this thirty year labor of love by the libre mathematician Eduardo Ochs exists and has existed for a long time. I just found out about it at emacsconf 2024 so I myself have only been a user for six months myself so far. Eduardo has lots of downloadable videos to help you get started.

«Fin.» (to “.Fin.”)

See everyone on the mastodon to talk about this! (and in the emacs carnival).

screwlisp proposes kittens