[some-mthfka]

> If I'm understanding this correctly, with your Lisp IDE you could have an image sub-editor which may expose functions for image modification (eg. cropping), which could be called from the parent-editor. Is this accurate?

Yep, and, presumably, you could then interact with it with your mouse, like draw something in it.

(One correction though: it doesn't have to be a Lisp IDE, but just any Runic document.)

There are a few facts at play: 1. Lenses are cells, which means they are just graphical objects responsible for their own graphical output and input handling (among many other things). 2. An image editor would be a cell as well. 3. A lens could, at runtime, dynamically, inherit from the image editor via an :is-a relationship, and, thus, become an image editor too.

Of course this would require some UI programming to get right, but that's the idea.

> Also, what is it about Lisp specifically that makes it suitable for this undertaking?

Please, see: https://project-mage.org/why-common-lisp

TLDR: It's an image-based language, and interactivity is a top-priority for power use. For instance, if something goes wrong, you don't want the application to crash. Incremental development for GUIs in general is pretty crucial. So, the only other candidate could be Smalltalk, but I like Lisp better.

[aleks224]

Very interesting! My understanding is that you're thinking about this more in terms of an 'application environment for power-users' than in terms of a 'multi-faceted IDE with lensing'.

To clarify, the specificity of Emacs is that it fully exposes it's internal function sets to the world. This could be done by other applications in an organized way. For example, in the picture-editing app example, it would amount to allowing scripting over the features that the app exposes. The scripting feature would come from the environment, not from anything specific the app itself does (apart from being built in that environment). The previously mentioned IDE could then be thought of simply the multi-tasking environment in which such generic applications are running.

Does this roughly correspond to what the project is about?

[some-mthfka]

You are absolutely on point, yes. The building blocks themselves are what the users will extend upon and use. That plays a very big role in composition and reuse. There will also be configurations and contexts (which are really quite simple mechanisms, really) that will factor into this, too (for the purposes of customization so that the users don't have to modify the original code to change some behavior or slot). Of course, prototype OO itself has a key agency here.

I also like to think about this in terms of "building blocks", not just an exposition of API. So, Emacs has the notion of a buffer for its building block (the only one, I believe). Cells and lenses will be building blocks.