This post is mostly just notes to future Jason.
The idea is a SwyftWare text interface which is mostly just human language text, but with a way to "execute" blocks of text which are executable code. SwyftWare does this for BASIC code by simply writing the code, selecting it and then hitting the "CALC" key. The output of the code flows directly into the text. This lets you do things that would normally belong in a spreadsheet like inline calculations, draw charts, etc.
The integrated graphics aspect is clever, it simply swaps the entire text display for the graphics display. Simple and effective and probably the only thing that could work on an Apple II.
I did something kind of like this in Jedi, the editor I wrote in/for JSFS. You could type GraphViz-style code inline, highlight it and select from a menu to render it as a graphics file with an embed link in the text.
Project Oberon, another text user interface does something like this as well, and it's basically how creating new tools/commands works. I suppose even shells like BASH kind of do this, but I feel like we're getting off-course.
What I'm imagining for my own version of this is a single text containing a mixture of human and computer languages. The computer languages are initial rendered as text just like the human language, but if highlighted and "run", result in different forms out output that flow into the text depending on what each particular language does.
For languages or code that output text, the output flows into the text just like BASIC code in Swyft.
For languages or code that output graphics, the graphic is rendered inline like an HTML image. This image can be "flipped" to reveal the code that created it, and it is the code, not the image that is stored when the text is persisted. This allows the text to be light and portable, readable on anything capable of reading text, and richer on devices capable of running the code.
Some languages like OpenSCAD take this further and instead of rendering a static image render an interactive viewer. Selecting and running a block of OpenSCAD code renders a 3D object inline like any other graphic, but this graphic is interactive and can be manipulated just like the 3D view of rendered OpenSCAD code in the OpenSCAD application.
This is a little bit like how Jupyter Notebooks work, but Jupyter still segregates the different types of text and their rendered results into blocks that are not really integrated together. What is like Jupyter is the modularity of these languages, they should be something that can be added and removed depending on the capabilities of the machine and the desires of the person using it. This allows the text to always be accessible regardless of the capability of either.
To use a system like this to do the work I use a "normal" computer for, I'd need languages for the following activities:
* 3D modelling
* Flowcharting
* 2D drawing
* Music
* Electronic schematics
* 3D printing (could be part of 3D modelling)
* Video editing (this is an interesting one to translate to/from text)
* Math (could be a simple interpreted language like how Swyft uses BASIC)
* Programming (imagine a literate programming style approach where the program code is embedded in the text documentation instead of the other way around)
That's probably enough for now because I have to think really hard to come-up with things that I use a computer for that don't fit into that list already, and of course having access to general-purpose programming language(s) provides an escape hatch for unanticipated applications.
Jason J. Gullickson, 2026