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.

> 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.

> eco

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.

> Again, good luck etc.

Hey, thanks for the feedback!

[1] https://tylr.fun/

Hey, thanks, I have recognized your nick, nyxt is a cool project : )

I am not sure I understand the question, but, for instance, Lem is an emacs-inspired CL editor. Not structural or even hierarchical though.

Update: I have updated the power-of-structure article with a section on accessibility.

Copypasting:

It's important to think about issues such as accessibility in advance.

I am basing my knowledge about this issue on this article about Emacspeak.

So, Rune will ask lenses to implement the surface-level text commands. Whatever text is shown or assumed to be on screen, the user will be able to copy that text programmatically. So, you could ask a spec-conformant lens stuff like "get the surface level text of the semantic unit at point". Such functions are of general utility.

Next, Runic functions will be required to return some information about the results of their semantic actions. So, if you issue a delete-semantic-unit command, it will return what it has removed (and that would include the info about the surface level text as well as the data-structural unit itself).

The list of such functions and their return-value properties will all be a part of the spec. So, it will be possible to automatically advice all these spec functions for any given lens to invoke the speech functionality.

Thanks for mentioning Sourcehut, somehow is just didn't come up when I was researching the mailing list options. So far, looks like it has a really streamlined interface and is meant to be integrated with the mailing list workflow, which I didn't quite see on Savannah.

Huh, interesting. I should try to learn more about STEPS in general some time...

My point isn't so much to reinvent Git's model (aka tree of blobs/commit/commit-graph), but rather to make it a part of a programmable interactive environment, and then just do the right thing from the user perspective.

That would include:

(1) Develop a UI for navigating the model,

(2) Develop a set of commands that act on the objects of that model.

I do want to append to the Git model by introducing the staging step for the whole tree (this, unlike with commits, won't have to have a history). I also think it could be possible to make it more flexible. So, you could say that there are blobs. But instead of blobs you could have some other kind of object too: for example the kind that would lazily compute itself from the definition of some other similar object. Or the kind of of object that would have knowledge about its contents, have an efficient way of storing it, maybe. So, I don't really want blobs (binary large objects), but rather a general kind of objects. Such objects would obviously need to conform to some API spec. Such objects could be written by the user (although, then he would have to supply the definitions to the others who want to use this). A tree could hold different kinds of such objects.

There's definititely some design that will have to go into commands. The commands would have to be taught to be context-sensitive (e.g. to selections or to the current state of the graph or commit).

A session-time undo graph for the repo-staging tree could be built as well. Easy implementation: copy the whole damn thing to memory on every change (only works for small repos, but that's a start). Harder implementation: define the inverses for the commands and build an undo graph.

I will admit: I am by no means an expert on version control systems. So, thanks for expressing the fact I didn't write about this, there's definitely some challenge to this, and I don't have any sort of final design in my head quite yet.

The thing about power-user software is that you can customize and package it to the point where it's indistinguishable from any other software, a polished end-user experience -- the user accepts the workflow of the given configuration and rolls with it, without ever touching the config. That's how some people use Emacs -- they just learn the bindings of the default distribution. But, for Emacs, there are also some distributions like Doom Emacs and such. They are just different user-friendly distros.

What's more, if you have good GUI capabilities (which Mage will have), you could build visual user interfaces for configuration (I don't plan to make such UIs btw, but someone with a good-enough UI sense and interest in this stuff could attempt it at some point, I guess).

If all you do is stick to some distro with some visual config tool, then you won't even have to know it's common lisp (unless some error is signalled and the interactive debugger pops up).

Oh, boy, how did I miss that one... heh.

You have a point there, I have thrown in a TLDR.

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.

Time is going to get by whether we like it or not.

Here it is, by the way: https://project-mage.org/elevator

Absolutely, it's image-based. I have considered Smalltalk, but I like macros a bit too much. I am pretty sure CL code will have better performance too, but don't quote me on this. A point worth making: if I were to do it in Smalltalk, I would choose the standardized one, as the most stable one. Stability is pretty important for a project like this, as you would imagine.

> Javas class and object system

I can't stress enough how important and helpful prototype OO has been to the current design. I couldn't imagine doing what I want to do without it. For example, some of the concepts such as configurations and contexts rely on dynamic inheritence.

> There may be insights there that can be mined as to possibly decisions that were made that you could apply (or not) to your work. Are the limitations of JFX done by design? Limited by Java? Limited by performance? Limited by "haven't got to it yet"? I don't know, but, anyway, just something you may want to study a little.

Sure, I will take a look. Thanks!

You know, I really haven't thought about that, but now that you mention it, I have heard before that in Emacs, the advice facility is very useful to the goal.

Well, all I can say is that I see no problem in adding speech output or in adding advice. The system is going to be very flexible to the end user.

Ha, maybe : )

Thanks : ) I will do my best to deliver.

I can't edit the top post, as it was posted a few days back, and the thread has resurfaced.

Currently, I am preparing an "elevator pitch" (as a few people have suggested me do), and I hope to publish it in a few hours. So, if the "Power of Structure" article is too long to consume and you just want to get the central idea, there will be such a summary soon.

Also: the project needs funding. I will work on it regardless, but it will be an awful lot easier for me to get this done with some help from the community. Please, see https://www.patreon.com/projectmage for the details.

Thank you.

STEPS is a very interesting project, indeed. I don't think it was quite a failure, after all, they did Nile and Gezira, which was pretty cool (powerful vector graphics rendering in a few hundred lines of code). Someone might reuse those in the future, I don't see why not.

But from the limited things that I saw, I got the feeling there was no overarching system. And there was no thinking about flexibility in general (which I consider to be essential to computing). I could be wrong about that, though, I didn't study it very thoroughly, only watched a presentation or two and skimmed the paper. Not that it wasn't ambitious enough already.

> I wish you more success!

Thank you!

> Flexibility interacts poorly with composability.

> Flexibility usually interacts poorly with performance as well.

I disagree fundamentally. I believe there's such a thing as the flexibility of specialization.

In fact: the reason why everything is so slow is because we don't have /enough/ flexibility in our systems.

https://project-mage.org/on-flexibility

> It's interesting that you're starting with the user interface instead of the sufficiently smart compiler.

I think it's because I care more about the applications than anything else. Yes, they require the platform, but my motivation is to get something I can use, not just to build a tool.

> That would be a lot to build in five years. Good luck and happy hacking.

Thanks : )

The linear-algebra provides a usability layer to April (an APL compiler). The geometry is just geometry with intersections (Its pretty cool in that it has planes, infinite sections, etc). Then there's KR with formulas thrown out and the constraint solver right from multi-garnet. Some utils. It's a start.

You are right, I will update that page with more explanations on the particular subsystems.

Haha, alright. I have a github profile

https://github.com/some-mthfka

I am not particularly proud of most of those projects. Many of them were strictly done for fun. Some of them I did because I didn't know any better.

The most sophisticated project I did was a game. You can grab it here for free:

https://ottrta.itch.io/ottrta

I don't promise it will bring you any joy, though. It was written in C++ and there's no code and there's only Windows binaries. Sorry, it was a few years back that I have published it. But, easily, that was the most interesting project I did, and the only usable one I have ever delivered.

Otherwise, I am just some motherfucker (you guessed it).

But you know what I believe? If you can think it, you can make it... That's all I want to say.

Yep. I will have to add it to the article (and why it's insufficient as well).

Alright : )

Thank you : )

What kind of system was that, if I may ask?

Man, I love these old demos. And I haven't seen this one before. I now understand much better what Alan Kay meant when he said: I felt like sticking my hands right through the display and actually touching the information structures directly. This is the first system I have used, and practically the only one since that I would call truly intimate. [1] Thanks for this link.

Well, in terms of UI, I see no problem whatsoever in building such a workflow. The way it will work is: lenses (aka editors) are cells (aka widgets). So you will be able to position things freely, anywhere. You could even connect and see actual symbols get imported and such.

As for the CL side, unimporting a symbol (aka removing a connection) is possible, so I see no problem there either : )

[1] https://www.youtube.com/watch?v=QQhVQ1UG6aM

Yeah, right : D

In any case: there are quite obvious limitations, and, to me, they weren't very apparent when I started out in Emacs.

> It seems that the syntax highlighting is the culprit.

In that case, it was the fact that adding a bullet point to a list would rescan the whole list (so it could simply update a bullet count in the header). You would need to implement incremental parsing for that, and that's not very easy. And certainly not natural.

> If I understood the author correctly, he's saying that structured editors are superior to a syntax highlighting system that's based on regexps, when you use them for programming.

Absolutely, that's one of the points.

I must add something, though. It's not just about speed. And, in fact, it's not even just about editing.

Most exciting possibilities of the structural approach stem from the fact that you can start thinking in terms of objects: then you write textual interfaces for those objects, for the purposes of textual (or even graphical) interaction.

The bare-bones example is that if you had a table, or a tree in a note-taking application, then you could query that tree, but you would still retain the textual interface. Even better: you could embed any editor within any other editor, which would directly correspond to a compound structure at hand.

To give you an idea of a note in a KR (knowledge-representation, prototype OO) system:

    (create-schema power-of-structure
      (:is-a kr-note)
      (:title "The Power of Structure")
      (:tags '("seamlessly-structural editing" "power"))
      (:introduction '("Welcome to Project Mage!"
                       "The purpose of this article is [...]"))
      (:table-of-contents nil)
      (:sections (create-schema))
      (:related-links nil)
      (:footnotes nil))

This note [1] could have any other structure, any other slots, of course. But it's just an object in memory.

Now, all you would have to do is lens that object, aka, construct a tree of embedded editors for it (which Rune will also do via KR, just like the object above).

Another example: code. A large comment block? View and edit it via a note-take application, or a markdown application, or what have you.

Another example (leaving some details aside): attach comments to any piece of code (up to a character). That comment doesn't even have to be a part of the editing workflow. I think that's pretty powerful (and there are more use cases, see Alchemy in [1]).

[1] This example is directly from https://project-mage.org/the-power-of-structure