Lisp Editing in the 80s - Interlisp SEdit
Why Hacker News recommends it
Linked as the clearest view of the legendary structural editor in threads about Lisp environments and structure editing.
What it is
A short demo of SEdit, the structure editor for Interlisp-D on Xerox Lisp machines in the 1980s, which edits code as trees rather than text.
Recommended by 2 HN commenters across 2 different months, 2019 to 2021.
What Hacker News said
Recommends undershirt · 2020-08 · on “Interlisp project: Restore Interlisp-D to usability on modern OSes”
I missed the golden age of lisp, but i know this project for its legendary structural editor, SEdit[1], released the year I was born. i found it mentioned in an old paredit readme, something poignant like “paredit is only a shadow of what interlisp was: true structural editing”. [1]: [this video]
Recommends mikelevins · 2021-01 · on “On Repl-Driven Programming”
That's a good suggestion. Walking through a set of interactions is a solid idea. For what it's worth, there are some videos around of people actually doing it with Lisp and Smalltalk systems, and pjmlp already posted a pile of them elsewhere in this thread. I can add a few more: Kalman Reti walking through some interactions with a Symbolics LispM repl: [LINK] Brian Mastenbrook demonstrating Interlisp's SEDIT structure editor in the Xerox Lisp environment: [this video] Rainer Joswig (lispm here on HN) showing us a little bit of repl and Zmacs interaction on a Symbolics Lisp Machine: [LINK] Rainer again, showing some simple interactions with Macintosh Common Lisp, which was my daily driver for year
Cites lispm · 2019-10 · on “Show HN: Bel”
> I-Expressions That's not an EXPLICIT list representation, where the nesting is notated by explicit characters. It's also harder to use in interactive interfaces like REPLs, debuggers, etc., where Lisp lists don't need to have vertical layout. > you do have syntax errors--unbalanced parens. if you use a structure editor for Lisp you don't have unbalanced parentheses. In editors with support for s-expressions, unbalanced parentheses are basically not an issue. > cat hakon.grammar Yeah, Lisp works very differently. It does not use grammars like that. Lisp uses procedures in readtables to read s-expressions. Parsing the code is then done by the evaluator traversing the source or by the compile