Malleable computing, Emacs, and you

I've gone much deeper into type checking since then, but I still like simple, dynamic scripting.

I've heard "functional core, imperative edges" and I feel like that kind of applies to static vs dynamic. I think there's a lot of cases where exposing a scripting language is a perfectly sane and good design pattern.

I'm not sure Emacs fits that category, hah, but it's just so dang useful.

I had not heard of control theory, I appreciate this

For others like me who hadn't heard the word "fahrvergnügen", it translates to "pleasure of driving". From German fahren ("to drive") + Vergnügen ("pleasure/enjoyment"). The term was popular in advertisements for Volkswagen vehicles, which seem to have certain affinity to Apple products (past and now, good and bad sides).

Dave Winer's personal site is still up and running on UserLand Frontier! http://davewiner.userland.com/default

> ..how I got involved in outlining while I was learning about programming on my way to doing an BBS which turned out to be an outliner which turned out to be part of a scripting system.

> the idea came from LISP programming systems that had hierarchic program editors. I wanted to see if the same thing could be done for Pascal. The result was a development system that ran on PDP-11s under Unix that viewed and edited source code as a tree. This embryonic outliner could dive and surface, displaying one level of the hierarchy at a time. Programmers could edit the structure of their programs directly.

Fascinating stuff, this is like a structural/projectional editor for oulines and documents, extensible with scripting. Well, I have a dozen tabs open now, I'll enjoy reading through them. The Frontier manual with little screenshots of classic Macintosh interface is sweet, nostalgic and inspires me to imagine what a new take on the idea might look like, with modern web tech and benefit of hindsight.

That's not something I ever thought I needed, though there is some support for syntax highlighting for JavaScript and Python, I think. I don't think GT is supposed to be a general-purpose, polyglot IDE: it's a bit more specialized than that, IIUC.

I'm leaving the off-topic rant below; it's a bit too long to just delete :(

> Please correct me if I'm wrong and things changed in the meantime.

Sadly, you're not wrong, and as an Emacs user (since 2012) myself, I share your reservations. The text editing widgets in GToolkit are usable, but nowhere near what you get in Emacs. Multiple cursors, iedit, re-builder/visual-regex, editable occur, AST-based editing (paredit/combobulate) are just some of the features I use regularly in Emacs which are (and will be, for a long time) missing in GT. On the flip side, rich formatting, inline images, and interactive widgets are way easier to implement in GT than in Emacs, and Lepiter is a good alternative to Org.

The conventional answer to that is that you shouldn't need those more advanced editing features when working with Smalltalk: the method bodies should be short, you should be using refactoring commands instead of hand-editing code in many places at once, and you should just auto-format after each edit. Even if it's not technically incorrect, I don't like that answer. Because this is the Smalltalkers' mindset (on average), things like LSP implementation (or other support) for external editors[1] never gained traction.

Without writing an $EDITOR-GT wiring yourself, the best you can currently do is some level of external integration. You can add a context menu option like "Edit in Emacs" in GT that will run emacsclient on a temporary file with the method body dumped. It's obviously underwhelming: you have either a powerful editor (Emacs), or a smart editor (GT), and you have to deal with two completely different UIs. Yes, it's bad. It's still better than trying to use just GT for all editing, though.

I ended up structuring my GT project a bit like a Web app. The sources on disk are a source of truth, and coding agents work with them. I have scripts that load the Git repo into a fresh image and either run the tests, run a one-time eval, or open the GT GUI (equivalent of loading a page and opening DevTools in the browser). In GT, I have an Emacs escape hatch for editing, and I use the Git tool to export any changes back to disk. So far, it works OK, though it's closer to how you work with Common Lisp images than traditional Smalltalk "100% in-image" development. It's not ideal, but it allows me to leverage GT while still integrating other tools into the project.

[1] There were attempts in the past; for Emacs, somebody wrote a frontend to Smalltalks called `shampoo`. It's been 14 years since the last commit.

Yes - I think this all comes from the insistence on using a single rendering tree for everything displayed on screen. It allows mixing all kinds of UI elements everywhere, including nesting of arbitrary widgets inside a text field (and arbitrary text inside any other widget). It's a genuinely powerful model for UI composition :)

> I can't summon spell-checking willy-nilly like I can in Emacs

Yes, that's why I mentioned "features I use regularly in Emacs which are (and will be, for a long time) missing in GT" - it's not that you can't build them; they just need to be built, and with how few developers work on GT, it'll take ages before GT Coder gets those features.

It doesn't help that GT editors seem a bit less ad hoc scriptable than Emacs. I'm not sure why this seems to be the case for me - I suspect the need to structure everything as classes and methods adds non-trivial cognitive overhead for simple scripting. At least compared to the pretty flat, procedural shape of typical Elisp code. Then again, I did not invest enough time into learning how to customize GT's editors, so it might be a shallow impression that would go away with time.

> Also there seem to be official examples

Oh, nice, thanks, I missed that. I mean, it's obviously possible to implement an LSP client for GT, but I didn't know one existed. I'm especially interested in how that is integrated into Coder, since it should be able to provide a lot of functionality that I'd also want to script in my custom Coder instances.