Just a few additional comments from our last exchange, based on https://project-mage.org/elevator. I prefer this elevator pitch because it gives some insight on how to proceed, beyond the stylistic choices.
(If not a rant, it's a mixed bag of all I could think about the subject, since I never really exchanged about these ideas, so I'm interested in your thoughts as well.)
The example of splitting "Hello world" into a list of words is a pretty bad example; structure as in list of words is something that text editors manage well (delete word, inner, etc).
It contrasts with syntactic information that gives you structure that expands the range of what your editor can do.
If you know something is a noun, you can give only a list of nouns to replace them, and any replace would be able to ignore any verb that is written the same way (I'm not sure what IDE that does scoped replace manages variables shadowing correctly, but this is something you should be able to do with structure).
The idea of recursive, specialized micro-editors sounds like a real good idea.
There should also probably be a way to specify that something is an encoding of a structure.
For example, escaped shell commands, or SQL written as strings (not everything has DSLs, and even then it would still be useful).
Ironically the delta diff program would correctly highlight syntax of SQL strings because it only analyzes the text, as opposed to most IDEs.
There is also some prior art in the field, which reminds me of [0].
I'm currently working on knowledge management, which I think you have to split in different subfields; there's a great deal of overlap with project and document management, yet these would be mainly distinct workflows.
I think logseq [1] and org-roam [2] tick all boxes for knowledge management, strictly speaking, but other tools are needed nonetheless.
(digression: If you split it into plenty of different subsystems with another query system on top of it, you might just call your knowledge management a computer and the shell that querying tool.
The issue you might have is that every program has its own API, so interfacing requires a custom facade, unless you directly write/eval shell commands.)
There was another idea between code editing and knowledge management, called literate programming, which had a fairly high profile advocate (Donald Knuth).
The idea would be to explain the code in the way that made sense for humans, and have the system (something in between the text and compiler, if not the compiler itself) assemble these blocks in 'computer order' for execution.
He explicitly said that literate programming is not 'documented code', which is what people usually understand by it, but does not represent any paradigm shift.
There's the Leo editor [3] that took some ideas from it, but I think it's also something that never really took off.
The eco article is quite interesting, it's a cool proof-of-concept. I don't know exactly how it compares, but there's also tylr, with an online demo you can check out [1].
> The example of splitting "Hello world" into a list of words is a pretty bad example;
I just wanted to set up some very quick easy-to grasp context with it for the discussion that follows. You are right, of course, the normal editors don't have much trouble with that level of detail. Maybe I will come up with something better later on, though not too complex...
> I'm currently working on knowledge management, which I think you have to split in different subfields;
My view on this is that you can't generally predict that, but what you can do instead is let the user compose the structure and features of custom documents, thus creating custom workflows suitable for the task at hand, whatever it may be. I will be generally taking that approach with Kraken.
> literate programming
I think computational notebooks take the core idea and make it practical, and I think it's fair to say those are literate programs, albeit without the web-tangle aspect.
The example of splitting "Hello world" into a list of words is a pretty bad example; structure as in list of words is something that text editors manage well (delete word, inner, etc). It contrasts with syntactic information that gives you structure that expands the range of what your editor can do. If you know something is a noun, you can give only a list of nouns to replace them, and any replace would be able to ignore any verb that is written the same way (I'm not sure what IDE that does scoped replace manages variables shadowing correctly, but this is something you should be able to do with structure).
The idea of recursive, specialized micro-editors sounds like a real good idea. There should also probably be a way to specify that something is an encoding of a structure. For example, escaped shell commands, or SQL written as strings (not everything has DSLs, and even then it would still be useful). Ironically the delta diff program would correctly highlight syntax of SQL strings because it only analyzes the text, as opposed to most IDEs. There is also some prior art in the field, which reminds me of [0].
I'm currently working on knowledge management, which I think you have to split in different subfields; there's a great deal of overlap with project and document management, yet these would be mainly distinct workflows. I think logseq [1] and org-roam [2] tick all boxes for knowledge management, strictly speaking, but other tools are needed nonetheless. (digression: If you split it into plenty of different subsystems with another query system on top of it, you might just call your knowledge management a computer and the shell that querying tool. The issue you might have is that every program has its own API, so interfacing requires a custom facade, unless you directly write/eval shell commands.)
There was another idea between code editing and knowledge management, called literate programming, which had a fairly high profile advocate (Donald Knuth). The idea would be to explain the code in the way that made sense for humans, and have the system (something in between the text and compiler, if not the compiler itself) assemble these blocks in 'computer order' for execution. He explicitly said that literate programming is not 'documented code', which is what people usually understand by it, but does not represent any paradigm shift. There's the Leo editor [3] that took some ideas from it, but I think it's also something that never really took off.
Again, good luck etc.
[0] https://tratt.net/laurie/blog/2014/an_editor_for_composed_pr...
[1] https://github.com/logseq/logseq
[2] https://github.com/org-roam/org-roam-ui
[3] https://leo-editor.github.io/leo-editor/