Project Mage is an effort to build a power-user environment in Common Lisp

What I was getting at is that IMO you failed to boil down the essence of the proposal to a length that could be called 'elevator pitch'. By the time you start preaching the essence, everybody's arrived at their floor already.

It makes me sad to see these kinds of efforts in 2023. It just seems very likely that we will have various advancements in AI (for example Hey GitHub) for input methods/ text-editing before this reaches to an MVP stage. While even 5 years ago I would choose Emacs and split ergonomic keyboards over any other cool new solution, I feel like recent developments in AI are just too good.

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.

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/

Good question. (Incidentally, it provides a good example for my words in the comment you have replied to.)

Words could be objects. But I will tell you more: you can start breaking words into characters and making them objects too, if you needed to. The key to performance here is to do the necessary stuff on the fly, on demand, dynamically. In other words, the word may become an object only when it needs to become a seperate entity. Suppose you use some data structure for storing sentences or paragraphs. Let's assume it's just a list. So, before a word needs to become an object that stores some information about itself, it can just be a string:

    '("This" " " "is" " " "a" "sentence" ".")

Now, if you wanted to tag the word "This" with some info (like stylization), you could turn that word into a more complex object:

    '(("This" :style bold) " " "is" " " "a" "sentence" ".")

In fact, if your application requires such an optimization, you could even store it as a simple string

    "This is a sentence."

You can choose whatever storage unit you like, as long as you can make your editor work with it. Structural approach allows specialization on the fly, you can just adapt to the granularity when you need it, since there's just full programmatic access.

I think he meant Common Lisp macros, a powerful feature of the language (and missing from Smalltalk) that allows one to easily write code that writes code.