Sci Cloj Clojure visual-tools group, 27 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Clojure visual-tools meeting 7

Description

In this meeting we had on May 27th, 2022, Maurício Szabo presented Saturn, an attempt to write a modular & extensible editor inspired by Atom.

Repo:
https://gitlab.com/clj-editors/saturn

Meeting summary:
https://clojureverse.org/t/visual-tools-meeting-7-summary-video/

Zulip topic thread:
https://clojurians.zulipchat.com/#narrow/stream/313390-visual-tools/topic/meeting.207

A

Hello, this is yet another meeting of the visual tools group, where we are looking into some of the of the emerging closure tools for data visualization and literate programming and such and today here we are jack and lucas and mauricio and danielle, and we'll hear a talk by mauricio about a new attempt to build a new editor, completely enclosure, extensible and and modular, and inspired by atom and probably we'll hear more about it in a moment. um So hello, maurizio.

B

Okay, hello, um okay, I'm sure I'm gonna share my screen right now, so uh this is I I like the way that you describe it as an attempt, because that's exactly what I'm doing and that's how I wanted to to phrase this it's for now an attempt only I'm not sure how far I can go into this project, especially alone, but um well. The idea is: make a hackable text editor using most of the atom that I can and see.

B

If it works, I mean um it's a big work, so I would like to start this presentation with some facts about the planet, not the project. Yet so the first thing that you have to know that saturn is huge. The planet is huge. Well, probably most people know that, but in the terms of the editor it means that I don't want to build it all at once.

B

I want we won't be able to build the whole editor from scratch in a single moment in the single step, because it's huge- and the second fact about saturn is that we don't know if there's a rocket car or not people say that's mostly bound by gravity and they that the planet transitions from gas to less gas to more dense to more dense, and we don't know if there's a rocket core or not.

B

So this translates to the plug-in that users that are using the the editor they should not be able to tell the difference be between if it's a core of it, it's a plugin. So that's one of the things that I meant when I said I don't want to build the whole editor at once. Maybe we can build plugins and then enrich the editor little by little with plugins and not really with the I don't know, making a car, that's really big and then build from there. So saturn floats on water.

B

That's an interesting fact: saturn is a huge planet, but it's less dense so translating to that. It means that I want this code base to be less dense than other editors. If you look at the vs code added, especially vs code or the atom code base, it's huge. It's like huge, complicated with lots of branches of okay. So I'm running in this in this situation.

B

What I do- and I want the code that we do to be less than so people can look at the code and understand what's happening and you don't need to, like, I don't know, do well the whole enterprise code, like we have a presenter and a provider and something something something to go to where you want. I want the code to be more and right to the point, and oh, of course, saturn can host life as we know it, and we will also not be able to host our life.

B

We just decide to create an editor from scratch, but maybe can host life on on at least one of its moons, and that means that maybe we can use the plugins and the idea of like hosting things outside of this saturn itself, so we can have a life while you we build the editor. So that's the core idea about the planet and the project again.

B

So, okay, why did I choose atom? That's one of the questions that I mostly get. Sometimes so people say: okay, we have code mirror. We have like vs code. That's the I think, probably today vs code, that's what most people use and we have also light table. That is already an editor. That's written enclosure script, so maybe we could reuse that, but atom is the only one that have reusable ish components. It's not 100 reusable as I wanted, but we can do something that it's reusable, and so we don't need to invent everything from scratch.

B

Light table is interesting, but they have a structure. That's called blt behavior objects and triggers, if I'm not mistaken- and it's not easily explained in anywhere. So the author decided to do this structure. Maybe it's a good idea. Maybe it's not, but he didn't document exactly what it means.

B

So you kind of have guess, work on how light table works. So it's hard to like understand how light table should be maintained.

B

Atom is also highly hackable, more than vs code and other vso visual editors, maybe less than vim, but it's almost the same level and less than e-max, because it makes us like a beast. It's basically a list machine all the way down, so we can never get to emax level unless we don't compile anything and allow everything to be changeable in some way. I'm not sure if you can do that, and I don't have a good plugin system that still works today.

B

It's a little dated, but it works, and I'm gonna show a little bit more in a minute and it's also possible to implement a vs code api over the atom api because it's way more flexible than the vs code. So in theory we could have vs code plugins running in atom. So why not atom? Because I mean, if I'm I'm only saying good things about adam, so why don't I reuse atom like 100, just keep maintaining it and I did try but there's a lots of not invented here things.

B

Maybe it's because they decided to start the editor in a moment that electron didn't exist and everything else. But there are lots of not invented here. It means like they didn't not use a package that already exists. They invented their own so to keep atom, also means keeping at least 17 packages that atom uses internally.

B

So it's a huge work to make it work and if you're familiar with npm, you know that npm is a pain to use because it breaks lots of things. So npm install right now, it's failing, so you have to keep trying, try and try until it works. Actually, I was not able to make npm work.

B

I used yarn and, after I think, five tries without changing a single line of code. It finally was able to install anything. So I do not want this experience in an editor like you want to hack the editor, I'm just okay, just install yarning like keep running yarn install until it works. It's like nonsense and upgrading node break things downgrade also breaks build instructions are not working. It's not now it's not working, so you have to kind of hike around your way and there's lots of branching in atom.

B

They decided to do what they call bootstrap gear and config directory and dev mode. So there are lots of if, if I am in config mode or in bootstrap mode or in development mode, do this thing differently. So I don't want to keep this level of interaction in my code and well, of course, binary packages. Electron, ionic, core plugins, use internal data from atom.

B

There are a lot of undocumented things that atom does that. I was not able to upgrade any package because lots of things simply do not exist anymore in electron 12 and we are at electron 18. So I can't version bump that far with all this internal data, so I decided to try and see if I can do the hackable text editor and I decided some principles.

B

So first is nothing is sacred. It means that everything should be plugged in not even the part that edits text, so I should be able to reuse some. I don't know code mirror or monaco or the atom editor itself to edit text, or I can just remove the edit text function completely. This will probably break the editor, but that's actually the point.

B

Nothing is sacred. You can break the editor. It's not like vs code, save it's like image, save you install a misbehaving plugin, you break your editor and well good luck. Well, not exactly good luck, then you'll disable the packaging should. The word should be back to work so also means that we should be able to extend it easily with plugins or scripts.

B

And the third point is my main point. I want people to just use, npm install watch things and then everything starts work. I do not want people to want to install python, 3 and then gcc and built tools, and they go claudically and lion boot, babashka and bb.

B

Well, that's the whole point. I mean it's less dense, you just install things and then start to hack and everything should work and well the idea we should always have a default component for most people to use.

B

It can also mean that this car component is less performant, but I want a trade-off like I can use a default component and a highly optimized component, but I want to keep work. I want to guarantee that the editor works, at least with the most easy to keep component.

B

So, for example, the a good example for this is firewatcher, modern editors. When you change files outside of the editor, they are able to update the editor. If you did not change anything so supposedly, I am editing a closure file and then I edit outside of it.

B

I can see that the editor will reflect, or at least inform me. Okay, you change this file outside of your editor. What do you want to do discard your data, use the new data and so on and so forth, and if we could use like some kind of file watcher that uses polling- and this is written in rust- that's compiled to webassembly?

B

It means that we don't have to build binary packages for a specific. I don't know linux and windows on mac, so it should be easier to maintain this version than the one that I should have: a mac, a windows and a linux and test if it's working on every version. So it's always the best to have something that we can work and can deliver fast and then be able to replace that with plugins, because well, that's how I want that's what I meant by less test than nothing and file.

B

The 50 point is like we should use libraries that already exist. It means do not invent something if did not exist. It also means do not use the javascript word. That's like okay! I want a leftpad, I'm gonna npm install leftpad. No, if you need something that it's like complicated, for example, file, watchers or I don't know encoding translator.

B

We should use libraries that exist if this did not. If this these libraries don't exist or if they are really small, we just copy paste our code inside the editor, it's better than like death by specificity. That happened without them. When you npm, install and like lots of packages simply then do not install because they are outdated or they don't exist anymore, so problems.

B

We should support plugins that already existing, not in vs code, especially in vs code, but as the vs code api can be implemented in the atom api. Maybe it's better to support the atom api first, but especially fbs code, because they are marked plugins for vs code and from atom. So that's one of the most important reasons again. Why? Because nobody will use your editor if you don't have like paren for paradidd and kalva or chlorine, or I don't know any other package working and that's one of the points I mean.

B

uh I don't want to invent everything from scratch, but I also want people to use the the editor that I'm doing, and the second point is that these plugins are javascript or typescript or anything. So there are lots of things that we can't reuse. We can't use enclosure, word molly, schemas, reframe, python eden. We can use this to develop our editor, but we can't expose this to plugins because they will not work.

B

I'm not sure if there are people that are not aware of that. But clojury is a plugin. It's a package or library for the java virtual machine. But clergy script is not cloud. Rescript is a compiler, so you can't like expose hidden for plugins, because this edens are compiled to javascript and they lose meaning.

B

When you compile them, so you could expose an sci version and that's maybe something that we can work on in the future, but as a ci is slower than compile javascript so and also if we decide only for sci, we lose all the plugins that already exist for atom and vs code, and that's something that I don't want to to work with, and even promesa there are promoters, the library there's something called deferred, that's a way to work with promises in a better way.

B

When you just create a promise and then you deliver the value somewhere else, it's kind of like a synchronous, a chorusing promise chain and promesa have this deferred, but it will not work on the on the javascript api. So there are code that you probably will see when I show you that, like you, I expose it from master ferret, but then I have to wrap around in a promise again, because otherwise this will not work in the interrupt.

B

Also saturn cannot invent things because well I want to support the api that already exists, so we can't invent a new api and start to use that. Well, we can, but not not before we support the ottoman vs code and got us almost as hackable as in max, but probably not at least all the way down. I would love to do that, but well javascript does not work like that.

B

It means that also, most things are actually comments. You don't like move the cursor, you can have a comment, move cursor down and it will move the cursor. This makes things more hackable because you can like trigger the api. Atom works like that. So it's like easier to translate.

B

Okay. So again, this is the atom editor. So this thing here is a plugin. Let me see if I can like yeah this. This works better. So this is uploading. The three viewers uploading we are able to reuse this.

B

This is uploading the tab view we can reuse that, but we are not going to I'm going to show you a little bit later why this is a plugin, it's chlorine and this is a common collet. Then it's also a plugin. That's one of the interesting things I can change the behavior of the command plate in the atom and that it's something that I already did in the past. So that's amazing that we can like have this level of flexibility by doing plugins.

B

So this is also a plugin. The status bar, that's on the bottom side of the atom, and if you see here, you see that there's a smart mode and clj working. These two are provided by different plugins. So atom does offer a way for plugins to communicate between them. Even when they don't. The the editor itself doesn't know that a plugin exists.

B

So that's something that I want to reuse and how it this works is with services.

B

So a plugin can say that provide us some services, so the service is like a pair of provided and consumed, so the status bar provides a service called provide status bar in the oh sorry. It provides a services, the services call status bar, and this service have two different versions: one it's provide status bar and the other is legacy provide status bar.

B

So it's amazing that we can like there's built-in in the atom, editor a way to aggregate new functionality without breaking existing code. So we don't need to just uh grow things by aggression. That's exactly how we work in claudia, but we can keep supporting older versions if we want by offering different entry points.

B

So that's this is something that I really want to reuse in the center and I'm kind of reusing right now, so saturn current implement services. Now we are finally going to the code, sorry for the delay, and I am using reframe.

B

So I'm registering two different events. One is called provider register and others consumer register. So when I trigger that, I want to register a provider. I'm saying: okay, I want this plugin to provide some kind of services to the editor and the consumer can say. Okay, I want to consume that service and use in any way that I want. This is not message passing this is api.

B

Actually so it's callbacks, you provide a service, you inform an entry point and the entry point will be called with like things that need to be to be done and when you consume a service, you provide an entry point and that entry point will be called with the contents, the the actual provider of that service. Let me show an example here, so this is, for example, I decided to make a test that registered and provide in a consumer pair.

B

So in this case I'm testing the provider before the consumer. Oh by the way, this events make frame and um that's something that I want to to share. Also, I'm not sure if people are familiar with with reframe here, but reframe works by registering events globally, and I am not using reframe, I'm using free range, it's a fork of refrain made by the folks of next journal and it's an amazing upgrade to refrain because you actually make the frame of the reframe local.

B

So I can create a frame and register events outside of the global scope.

A

And mauricio he's: okay, could you say just a couple of words about what it is because you know for the recording it could be useful, oh okay, sure so.

B

Okay, so let's, let's start with like the the idea of let's start to react, because that's how things started if people are familiar with react, you kind of have this state, that's it's local to every component, so people decided to make a global state and that didn't work because well, global state is always bad. It's hard to get right, so reframe is a way to make the global state more more easily consumable. So in this case with reframe, you trigger events and these events update the global state and you can subscribe to these changes.

B

So, for example, supposing I am making uh an ui that have a login password and I click like login and it triggers a backend environment I could trigger um every input box could like when, when I am typing, it's triggering reframe, saying: okay, I am updating this value of this text box and reframe what you actually update the global state and then I'm subscribing back to these changes. So when I just I'm saying okay, if I tol, if I type, for example, my username mauricio, I will get back more reason.

B

I can also do this to make like masks, for example, okay. I want to down case every ladder, so I trigger with what I typed in my keyboard and the the handler will actually downcase my letters and when I subscribe back, I will get back lowercase chars, so I can actually type uppercase chars in my login page and it would, I would just see, lowercase because that's how reframe works, but this is global and free range makes this local.

B

So I can make a frame and then I can dispatch events locally to this frame and not to the global state, and I can also subscribe to this frame and not again to the global state and finally, reframe have the concept of code effects.

B

So, for example, if I am triggering I don't know, I click on the button login login. In my old example, um if I am triggering like by clicking login, I can update the state saying: okay, I am triggering the back end and then I have a call effect that says actually, since the update to the to the global state to the to the api, and that will work are someone else speaking something.

B

Oh okay! um Well, I hope it. I hope this explains things if not.

A

B

So much I just saw that vincent's here so maybe sometime, I would like scream something wake up, because it's really late for him: okay, uh wonderful and okay. So back to the test, uh I am using a library, that's called check, it's a library that I did for other plugins, so I'm not invented this library to the to the automatic to the saturn editor.

B

I actually did say that we don't want to reinvent things just for the editor and I am just using a library that I invented, but actually it was not for the editor. So anyway, that's like ignore that. But for now it's just to make a synchronous test more manageable in the clojurescript world, so yeah I'm actually testing by providing something before consuming it. So, as you can see the provider, it's a function, it's a function that returns what I want to provide.

B

So in this case I am just resolving. This promise called result that is here.

B

So I'm just checking if this function was called. This is a spy like it's the mock, whatever I'm just doing it by hand and the customer will receive the provider and we do something to it in this case, we'll just call the do function.

B

This actually can't be done like this in the real code, because well, these things are javascripts, so they will become main goal if you use clojure skipped in your plugin, but it is just for the test, so it works, but actually we should like expose js objects here. Otherwise this will break in the real code. Maybe I would change that just to reflect that this is how it actually should be called, and that's one of the points, that's kind of hard to get it right in this editor project because well it is javascript.

B

So sometimes I keep forgetting that. I can't do that, and this is one of was one of the examples. I can't really do that in a real code, but anyway, um the consumer will just call the provider with the with the keyword it works again. We can't use keywords in a real plugin, so I may change this later, so I'm actually dispatching that I want to register a provider called server c1, that's this provider in this case this function, and I want to register a consumer that is this consumer.

B

That's this function, and I want to check that the result is. It works, so check the library that I did it's just going to wait for the promise to be resolved and see if the result matches with it works and if it does, then this test will pass. It actually is passing right now.

B

So it's just to check if by registering a provider and a consumer, that consumer will be called with the provider and actually there's a there's, a different test that registers things in the opposite order like register the consumer first, the provider second- and it should work the same way because that's how services work they are asynchronous. So that's one of the pain points of it, but well they should work no matter. How is the order that you're called?

B

We can't really decide on the order when you start your editor, you start to load plugins, so they will provide and consume services in random orders. So everything should work, no matter how it's, how it's done.

B

So this is the editor right now, it's kind of beautiful, considering the time that I spent on it, but it actually kind of not works, because nobody here is really working. Just clicking here opens the the file in a new tab. If I click close tab, it does nothing.

B

If I try to reorder tabs, it does nothing, but I can type on the editor, but I can save so yeah we it's kind of working, but we have to like increment in small steps and I'm actually in a kind of hammock time, because I want to register comments right now, because I don't want to hardcode that when I click here, I close the editor. I want clicking here to trigger a command that will close the editor. So that's how I want to handle this.

B

So if you run the editor with an environment, variable tests set to anything, that's not zero or empty string. It will open this docking here that that should run all your tests. So that's one of the other things that I want. I showed the test here. This is the kind of level of abstraction that I want in my tests. I do not want to test that entire that are testing internal state and everything. Even the reframe dispatch is not really what I want to do.

B

I want to actually do something more higher level than this, because maybe we can replace reframe in the future, and I don't want to break tests just by replacing uh the way that I handle events. So that's one of the things that I that I want. I want this kind of experience when I am testing inside the editor, with a real working code base and not by mocking the ui mocking the things and everything else.

B

And oh actually, this is clickable. So if I click this, I can go to the line of test that it run and check it. So that's one of the good things to have tests built in in the editor, because in the future I really want to test the to develop saturn in itself. Like I run the test, if it fails, I click on it. I go to the file that failed. I changed inside saturn run again and see if it will keep failing or not, and this is the tree view from the atom editor.

B

So it's amazing that I could reuse almost 100 of it, and this is not the tab view from the atom and I'm going to explain a little bit. Why and this is the monaco editor from the vs code? So it's frank stein like this is atom.

B

The whole ui is regions, and this is like monaco editor, so it's frank stein that I'm doing but well it should be working. So, okay, the tech stock is free range for the for the event handling, I'm using regent for react, binding promesa to actually handle promises.

B

If you saw my latest post about clojurescript, I do not really like corey sync for for a synchronous handling in clojure script. They query: sync works really well in closure, but not really enclosed it in my experience, so promise is better for this specific situation electron from the ui, but that's one of the other things that happened.

B

I was talking with a friend and I we decided to do this. This proof of concept. That's react blessed.

B

I don't know if you are familiar with any curses library, but any curses is a library that makes uis or text uis. So you use text interface with like some better handling of how the terminal, resizes and everything there's a version of curses called blessed for node.js and there's something. That's called react blessed. It's a react layer over this curses fork, so we decided to try and it kind of works. So we can have the saturn editor in terminal mode.

B

Well, some plugins will not work because they would expect like uis happening, but maybe plugins that do not really need like ui elements will work, and that could be actually something really really good. Because remember, I want to support the vs code. Api, the vs code. Api is incredibly limiting on what you can do in your user interface.

B

So if it's limiting what I can do in the user interface, I can just implement these things that I can do in blessed in the text mode and then plugins in vs code should work on a text based editor that should be amazing and I'm using mali for schemas. I actually found some bugs with the way that they are instrumenting code with it.

B

But well it's a great library. It's fast and people are really really helpful in solving problems with this library, so I'm actually changing my ways of using just um prismatic schema to just use them only because it works better and I actually want to use mali because well it's a big project. So I want to instrument some functions to be sure that I'm not passing elements that I do not.

B

For example, notable elements or non-loadable elements should be handled by mali. If I could and well this is the ui. So, as you can see, it's really simple: there's support for theme or red butane, because I again cannibalized some parts of the atom.

B

So themes are working right now and I can't change themes, there's just not an api for that for that yet, but I can do by triggering reframe events and they will update the theme- and this is the if I can run tests just add the tests ui, otherwise just add the editor ui and the editor. It's actually incredibly simple, because I'm reusing monaco. So I am just like getting the element of the left docking and I am actually doing this atom panel container to do something else, but that's the trivial it's hard coded for now.

B

I do not want it to be, but I for now it is- and this is the layout react. It's a library, that's in that's a core library from the saturn editor that handles the layout, and this is the layout component.

B

This is something that I I was thinking. I could reuse the frame from the free range, that's on the saturn editor, but I cannot do that because this is a plugin. So supposedly you should not have access to the saturn state. You should have access only to his own local state. So that's where free range came really handy, because I can make a new frame just for the layout component and then everything here is specifically to the react to layout component.

B

Well, it's a car component. Supposedly, I could use the global state, but I do not want to because again I want this to be possible to be developed in parallel with the editor. So maybe, if I want to extract this to a real plugin some day later, I could do that and I'm gonna show this code later if you want, but it's a lot to to handle that I do not really want just to be four splits in the screen, but for now it is what it is. Otherwise I would not go anywhere.

B

I wanted to do like the the vim and e-max split when you can split anywhere in any way you can, but well it will just not happen at this time. It's just too much too much code for now and well.

B

I decided to call plugins rings because it sounded right for the saturn, so we have rings that provide um the layout and consume what I call the presentable and I'm gonna show it a little bit and what this is and yeah and the element is actually just a react or in this case a regent element is reusing.

B

The atom pane, not really it's just a diff that have the name racked on atom pain, but I just did that because I can reuse themes from the atom so anyway, and this will append the presentable into the ui, the presentable it's something that can be shown on the screen. That's all so the layout component does not know what is being presented on the screen. In this case it can be a text editor or it can be. I don't know some plugin or anything else.

B

So that's one of the things that I will also want to support is that yeah layout handles the layouting of anything in the screen, but it doesn't matter what it is it just will handle that correctly and the provider is just like open or get react as an element. It should also support get element, but that's proven for the future reference and well again, look at this rs element.

B

This is using the regent component to translate regions into a react element. I cannot use, cannot really really use regions because again this is a plugin, so it will become javascript and then the concept of vectors and lists and keywords will become meaningless when you convert between back and forth okay, so what I was able to reuse, I was able to reuse the doc element. That's something that layouts things on the screen, the trivial, the style component, to make the the themes and the editor elements.

B

That's from monaco, in this case it's from the vs code, not from the atom I'm you're implementing tabs, because the atom tabs plugin expect too much internal state it. It actually expects a little bit more. It also wants to install binary packages, so we can listen to when a file changes outside of the editor. So we can change the color of the tab by hand.

B

So I do not want to support that for now or maybe ever I want to support something. That's more like clean when you uploading can just be like more clean, and why is that? Because I can port this editor in the future for the web page.

B

If I just implement the plugins that people that the, if I can just implement things that the core components expect in the the web page yeah. Maybe it would not work that well, because it's a synchronous but well reframe is already sync. So it's not really redoing anything and, of course, inspiring works in max november table called bubbles and lots of others call. The mirror is here: monaco is also here, but especially max. It's something that really inspiring on how they were able to go so far with a code base that was written.

B

I don't know 50 years ago almost and we actually want saturn to be as hackable as in max, if possible. Maybe not that hackable, but the most that we can go to and emacs can break. If you do wrong things and the idea of a hackable text, editor is exactly the same. I can break if I do uh weird things, there's something that I also want to support in atom in saturn. That is reloadable configs!

B

No editor actually do that when you like change your config or change your init script and it just reloads everything this. This does not work in any in any editor that I want that. I know of. I know that emacs have some limited support that you can like manually, disable and enable things.

B

I think autumn also do that, but you have to be aware that you are disabling and enabling, because by default everything is global, and I really wanted, if possible, the saturn learn from this. The steps and like kind of exposes a public api that you can just reload everything by scratch. Like okay, I saved this initial file. It would just destroy everything that I did in the old init file and start a new one, and everything should work correctly.

B

So, that's something that I want to experiment in the future and for now that's it.

B

If you want to see more, I do have the the atom package, the the saturn package here, let me stop the sharing. If I can't find where I do it, stop the sharing.

B

B

Well, actually, I don't know what happened with my zoom, but I cannot stop sharing things.

A

I'll try to do it. Oh okay, amazing beautiful! Thank you! So much for this maurizio and hello, isabella, hello, vincent wonderful! You have joined us and on this very late hour on vincent's side um yeah.

A

So uh should we think I guess we will keep recording for a while and uh and afterwards we'll stop recording at some point. um Let us think how we could dive in further right. Are there any.

C

A

B

Okay, please one.

D

What do you think the changes actually are that this is gonna evolve into something? That's really usable and not just well an interesting experiment because, like it seems like there's a lot of work to get into more than a prototype.

B

Yeah there is a lot of work, and actually I don't know how to answer your question I wanted to. I want to redo the experience that autumn left with me like. Well, let me I think it's better. If I, if I try to explain it with more than feelings, then like concrete examples, because well that's how it happened.

B

When I first learned about light table, I thought oh, this is amazing, but then I saw that light table was really limited, not because the editor itself was limited, but because there was no plugin for a light table. So, for example, when I try to reuse closure with it, there was not a single implementation of pairing for that worked. So I did try to make one and failed, but it works for 80 percent of the the the cases some cases the inferior from my table just think.

B

Do things weirdly and there's a specific case that it locks the editor. So I don't recommend anyone to use and I try to migrate to autumn and when I saw autumn the first time I was okay. This sounds interesting, it's a slow as hell. It's consumes a lot of memory, but I tried to do a plugin. It was a simple plugin that if I had a tmux opened, I could send comments to it and it was incredibly easy to do that.

B

It was like surprisingly easy and I was like okay well, we may have something here, because I did try to make plugins for the vim editor in the past and it's hard really really hard and still is with even with new now.

B

So I got into this. Like feeling of the editor is mine I can do. I can make it work. The way that I want to do so. Actually today, for example, my atom editor is incredibly customizable.

B

I have legitories turned on, but I do not like to type when they're ligators in the code, because they kind of mess up the spacing on everything, so my atom editor. Currently, when I have ligatures turn on- and I am at the same line, for example, when the cursor is at a specific line, it will just disable legators, but only for that line. Everything else keeps letters on. So this is a kind of flexibility that I don't have in any other editor.

B

As of now maybe emacs have but well atom does have this kind of flexibility and it's all like css html javascript. It's not like. uh I don't know, vim theme script or something that only works in a specific editor like, for example, the e-lisp that it's on e-max, not there's a not that there is a problem with ellipse.

B

Actually it doesn't have a problem, but uh there are more packages for node for javascript for better for worse than there are for other languages, and so it would should be useful to just use something: that's more mainstream and not something. That's only used for that specific editor, for example, veeam, script or e-lisp, and that was the experience that I had with autumn.

B

And then I tried to migrate vs code and one of the things that vs code forbids me is to change the ui in any way. So that's kind of a bummer, because I changed the ui in lots of different ways in autumn and fiesta. Do that to protect me from breaking my editor and I kind of understand, because it's a product they want to be viable, but I it sound that the editor is not mine.

B

The editor is from someone else and I can use that the way that they want me to use- and I want an editor that I can use the way that I want to use and that's one of the reasons why I understand why people choose mx, because it makes us the like the top most. In my opinion of I use the editor. The way that I want to use.

B

If you had two power, imax users with different trying to use the max from one of the other they would not be able to use because, like this person have an image, that's completely configurable for him, and this other has a completely different image with other configs and that's despair. The experience, if possible, that I want to do in in the saturn editor so yeah. It is a lot of work, but I think it's doable if I can keep like scrapping fragments of other editors.

B

For example. Let me just get some students. Actually, I'm gonna share my screen.

B

If something is.

B

I am screen sharing.

B

Let me just see if I am screen sharing the right screen. um Do you see the autumn editor here? No.

A

We see the background with this.

B

A

B

Yeah, okay, I'm sharing the different tests. Oh yeah,.

D

We saw the browser history, I'm.

B

D

B

Yeah, no, it's actually on the.

B

I have three different desktops and.

B

Maybe now you see the thumb editor right? Yes, okay, I'm gonna change the font size here a little bit because it's okay. So currently, this is how atom works. For me, like I have this ligature turned on and I turn off.

B

If I am a specific line, if I am in vim insert mode all the editors are disabled by default.

B

So this is what I meant with like the the id of the the editor- and this is the saturn editor. It's actually a little cold.

B

Yeah, this is not needed anymore, so this is the themes plugin, so it's literally 23 lines of code because I'm reusing most of the atom parts, and let me see the um let me see the the car package. I think it's the view yeah. This is the car package. It's like again little code, not really that much to be seen here, but I am reusing like the dock from the atom editor.

B

B

Wait: what is this yeah? It's done. The widget's name, space yeah, that's from the javascript dependencies docs, so I am reusing the doc component from the atom and again it's just a thin layer over what doc does it's actually most like wrap inside the react render, and not really that that much code and some like triggerings and settings of internal state from the docking, because well, we don't have the full api of atom implemented.

B

Yet so I kind of need to do that and yeah temps also is really really small, but this will grow because it's not done yet the tests, it's how to how I render tests inside the atom inside the saturn editor. So again, it's way less code than I I see in other editors.

B

So that's one of the things I want this experience to be like less dense than other enters. So let me see if I can count lines here.

B

Okay, so this is the total number of lines that I have in the atom in the saturn editor, including tests to make this kind of ui.

B

You can see the the saturn ui right, okay, so let let me see here.

B

Yeah, so this is like the user interface that's um on center. This docking here is reusable reuse. It from auto.

B

So it actually have something some interesting things like resizable elements and so on and so forth. The tab is working and I can click here, but nothing happens because again, as I told I did not implement this yet, but I can edit code and you kind of have a beauty not complete from the from the monaco editor.

B

So the project is way more code that I would like to be, but it's doable because I am like trying to reuse most of the code that I that I could there are parts of code that I would not be able to exploit. For example, I think in source yeah source, there's saturn and the javascript dependencies is basically something that I copy pasted from the atom editor. This editor here will not be used, so I can just remove that in the future, because well I tried to reuse the atom editor itself inside the saturn project.

B

It did not work well and I'm actually, I think, at the electron 17 here. Let me just see.

B

Yeah electron 17, so I am in a fairly new electro version. So again it's doable because again, I'm reusing most of the things that I can so I'm not like. I don't have the problem of upgrading electrum. Probably if I bump electron to the latest version, it will just work.

D

Yeah, what I I think, like the hard part, is going to be to get the plug-in system running right, because the the the left side is well, I mean it's just a file browser thing, the rest. The right side is just letting monaco show the contents of the file. You don't really need to do anything for that. um You get that kind of for free and, like the interesting part, is getting atom or vs code plugins to work, and probably even more interesting, is to be able to have the vs code. Api.

D

Be more extensible than this currently because, like I don't know, I think, like most of us are kind of okay-ish happy with vs code. The way it is and we wouldn't need a big new project, whatever a vs code would just let us do the things that it actually can do and didn't just put walls in front of us that are kind of artificial, sometimes where it's like yeah you're allowed to put some markdown element in here, but you're not allowed to show a picture or something sometimes um so like the vs code.

D

Apis like is that artificially blocking you from it destroying things? Even if you actually know what you're doing, which is like very strange.

B

Yeah, but actually this this treeview here it calls autumn comments, so I am already implementing parts of the atom api to make the trivial work.

B

So that's one of the things that I would like also to share there's here. I think it's on adapter.

B

Well, it's a proxy thing here that, like just spies on every specific part of the atom editor because well, I do not want to implement this all at once and all of this code here most of these is a stop as you can see.

B

But if you look at this, I just implemented what it was needed from the trivia to work and actually the only need that was really really needed. Is this workspace and workspace needs this one?

B

That's the open element so right now it is already dispatching to a new reframe component that opens the editor and it uses all the machinery that I did explain and that's one of the amazing things, because the machinery is different from what what autumn expects what I am currently doing in autumn. Actually, what it will happen is, I would open the trigger and open it will open a text editor and you to put into the the center panel by default and what is actually doing right now.

B

I am asking for the layout component to lay out this uri, and this is in this case is a file.

B

It's a file component, but it could be anything and when the layout component receives that he will search into its tail into its tabs and see if that component, that presentable, uri already exists, and if it does, it will just focus that element. So, for example, I do have here git ignore it's already open, so we just focus at it. If I try that see, then it's just focusing it: it's not opening a new one but index.html.

B

It opens a new one because it did not exist in the stack yet so this is plugging only the plugin decided to do that. It's not something that well! I decided because I made a plugin, but if I don't know there was another plugin here that would just I don't know, decide that.

B

Okay, every every moment that you click on something it will not focus it will just open and open and open over again or it will open in the split or whatever the plugin decides how it opens and if it opens so, this is already using the the saturn machinery it's sending to those to the layout. The layout is a consumer of the presentable, so it asks. Okay, do I have this lin, this presentable already in the ui.

B

If I do just focus, if I do not, then call the presentable component and asks to open a new presentable for this url and then it presents on the on the ui so yeah.

B

I still need to work on lots of api components. As you can see, most of the themes are stubs.

D

Own large is the the surface area of the atom api. Like I know the vs code, one is huge, but it's mostly huge because well, you've got calls for every little bit just so they can like differentiate, calls and put different walls in front of you. um I don't know how large the view is called the atom. One is.

B

Atom is also huge, but I actually don't think I should be able to. I don't think I will be able to implement all the api. What I really wanted, if possible, was to implement most of the api that makes, I don't know 80 of the plugins work atom. Api have lots of things like okay, so get this tab and get the component that's inside of the step and get the html that's inside this component and so on and so forth.

B

I don't think we do need all of this kind of of um specific thing, because first, this apis are hard to use. I tried to use them in the past and it's actually better to register what tom calls. I think it's uh open label or something like this, so you register something that has been able to open something in the editor and also will open it for you and decide where to put it, it's faster and it's easier to do that.

B

So what I want mostly is implement that api, and I think I don't know 50 of the plugins- that open things in the ui will work with that.

B

So maybe other the other 50 will not be able to do anything. But honestly, the atom api is not that that usable, because it's lots of internal things and internal states and everything, and also there are specific apis that are only used for syntax highlighting and they will probably not be implemented because we are using monaco right now.

B

In fact, atom does have an api for semantic, highlighting kinda. They never did document that anywhere. So I would not implement this one and most plugins that I tried to use semantic highlighting do not work today because they changed the api.

B

That was internal and everything broke, so yeah, probably not a problem, but that's something that I that's why. I also call this presentation an attempt to make the editor, because I want to be able to run chlorine, maybe calva parrying firm paradidd on saturn.

B

If I could do that, I would like consider a small success and then I can see if I can run, I don't know javascript, plugins or lanterns and everything else.

B

I think this covers if, if I can run lsp- and I think I can because monaco already have all of these things built in- I think I don't know- maybe six to seventy percent of the cases are covered.

B

D

Getting uh the lsp to run a monocle, isn't that hard? Just basically I've run it yes or something you don't get like the full power of it, because, like there's stuff missing inside monaco, that's built into vs code and not into monaco, but you get a lot of it.

B

Yeah, so that's actually one of the things that I really want to explore. How far can we go with little code and if the answer is quite far, I would be happy, but again, if I don't know, have to implement almost all the phantom for scratch, then this pro this project will probably be doomed to fail. So I'm not yet sure how far it will go. But that's also one of the reasons that I am making this this presentation right now to see if people are interested.

D

Have you already tried to run it as a web page thing.

B

D

It from just like running it right now.

B

No there's nothing killing it. I think I have no. Let me just let me just check, but I think I don't have any.

D

Note libraries.

B

No, the libraries that are, I don't know.

B

Yeah, probably not I mean.

D

Plus, maybe if that's like a file system.

B

Thing but who knows yeah, but that is, I think, user only for the treeview, so we can just I don't know, reimplement not have a trio exactly also there's something that I want to show that I forgot to show atom does have this kind of path watcher here and oh yeah this? These are.

D

The not gonna work yeah.

B

Yeah so path watcher, it's currently implemented as a shim, so it's here, let me show.

B

So it currently does nothing, but the thing is we can one of the things one of the ideas of the saturn editor is the core will implement all the binary packages.

B

So supposedly, if you want to run in a web page, we can have a car saturn, that's basically something that runs locally and then it talks with the web page with websockets, and that should work.

D

Yeah plus a path watcher doesn't really make any sense in a browser anyway, yeah.

C

D

Where the file change would come from, if it's not from you inside the version well, there's.

B

All there's always the I think, index of db and this bizarre things that happen in browser land right.

D

That's true if something else changed the index db, where the files are that you're.

C

D

Yeah sure, while watching on index tv, I don't know if that works yeah, I have to check the api, but, like those are like, like, I said, those are small things that are not that important to the whole thing. If we didn't ever have any file watchers or something it wouldn't be, a bad.

B

Experience, I think this fss admin- it's I don't. I am not even sure if it's to use it. I think this three were used by the atom text. Editor, I'm not sure. If I remove them, if it will keep working, but anyway, the trivial is using them. So if you want, we can just like get rid of the trivia when everything will work or we can implement a new trivia that did not use this. These elements, that's the beauty of it. Right I mean we can just.

C

D

B

Yeah, let me see here there's a tree view.

D

It's not good, we don't have to do it right now. It's just, uh and I was wondering if there was anything major that that would prevent it from uh running in a browser right now um that would have to be solved or if it's just like yeah. Of course, we have to touch the file system at some point. um If we are not in a browser and in the browser we don't need it.

B

Yeah, it's uh yeah, it's on the trivia, that's using fs plus, but we can do a chin. We can do a shin here. Just look from the fs.

B

It's mostly exist, sync is directory sync. Well, the problem is the sync right. Sync is not good. If it was a synchronous, then everything will work beautifully.

B

B

That's one of the things that I don't like of the ottoman. That's why I try to. I tried like more time than I wanted to make atom work with like current code.

B

It's that atom does implement lots of things in lots of different places like the file system, this library, it's used in the treeview, it's used on the tab view and it's used on the text editor itself.

B

So you don't really have in the atom a service that just streams between plugins. You have this called duplicated everywhere, so it gets hard when you want to run in a browser or in a specific environment.

B

Yeah make sense.

B

Yeah, but I mean we can just do a shim for this 26 specific things here and just remove all falls from all of them and shouldn't work.

B

That's a good experiment, lucas. I would try that.

A

B

A

We have about 10 minutes to the official time and maybe at some point we like to stop the recording and maybe keep chatting if you wish and um and so mauricio. Maybe you would like to think if you wish to say something to conclude about how people could help with the project about where you would like people to discuss this and so on.

B

Yeah, I actually I'm thinking about opening a slack channel in a setup channel called saturn, so we can discuss there if people are interested, as I thought this project is doing like hammock time. I want this to be usable, but I also do not want to rush things I mean in the first version. I decided that layouts should be completely flexible and I tried to implement that and it didn't work because I thought okay, I am spending too much time thinking on how this should work instead of just doing a first version.

B

So in the end I decided okay, why I don't create a plugin, that's called layout, and then I delegate this to the future mauricio okay, or is it from the future right now you can decide. How do you want to split things? My reason from the present you just have fixed elements and that's all, and that worked and actually I think it was a more elegant solution than what I was initially thought that would just like, allow to lay out anything in any place.

B

So I do not want to rush things. So that's why the product is going slowly. The the next big step is add comments and they are the atom commands. I do not really want to tie that atom commands are the authoritative way of doing things, but I also don't want to expose reframe, not only I don't want, but also I can't expose reframe to plugins because well it will not work. It's simply like that.

B

It will be wonderful if I could, but I cannot, because it's not it's not how clojurescript works when you compile with javascript.

B

So that's that's the next big step to see how will I handle comments and when I decide to do that, I want to like generate some comments like the save file and the close file to at least be able to edit files in the editor and have it been saved.

B

And then I want to start to think on other things like watching files, system, changes and everything so yeah, it's a lot of work yet to be done, but I want to like make a call for arms if people want to discuss or have any ideas or anything, especially focusing on simplicity, on how I can make this with less code possible and like have something faster than possible.

B

I would love to like discuss ideas and then implement. I am accepting pull requests. Maybe I do not have time to review all of them as of now, but if we don't know make a growth, maybe people can help on that and yeah. That's that's it. I think nothing really.

B

I know that I do not have. I would love it if I could like show here. Oh this is the centrum editor. Let's connect your socket repo, let's connect kalva to it. I would love to do that, but it's not there yet, and I really hope one day it could be there, even if it like works with less performance than vs code, but I think we can make use of a better and more hackable text editor.

B

I do not want to see vs code like getting all the the the the love from the developers and then we'll have like this kind of very weird division of well. I am a me max user, I am a vim user or I am a vs code user. I think this division is like quite bad. I mean I do not familiarize myself with emax.

B

I would love to because it seems that it's a wonderful piece of tooling that everyone likes to use all the time, but I I don't feel myself comfortable working with imax and, while do feel comfortable working with adam. We have to be realistic.

B

It's not it's not going to continue in the most following years. Probably I mean they shut down all the forums and there's an issue. That's already been solved like for months, maybe years that people are just not reviewing pull requests anymore, so yeah. I do not want to see the idea of a modern hackable text, editor dying so fast, and also I do not like that. Only we in clothing land have are going to get these benefits.

B

I mean there is like people in the small talk where that are doing wonderful things and we in the closure world are trying to like put editors and put visualizers inside our code bases, so we can inspect things and it's wonderful, but it only works for closure. I would like to like I don't know, do that, but also sometimes edit an html file and have the same experience if possible.

B

So yeah. That's that's all that. I really want to do the discover, arms and, let's discuss it more.

B

A

Thank you. So much is it okay to ask more.

A

Yeah yeah, so you you mentioned emacs and, and you know, I'm I'm thinking about the experience of extensibility. What a user who doesn't know so much can do to extend the editor and then in emacs.

A

You can do little things. You can add a function, you can add a variable, a key binding a hook and you just write a little bit of code and you can add those things and whenever you do that it is all discoverable right. So you can ask for documentation of a key, binding, a function and so on, and so you have those little things that can all be added and can affect the runtime in a mutable risky way, and that is how it is and they don't need to know so.

A

Much about um you know web development or and such just a little bit of imax list. So yeah I'm wondering how it compares to your vision of of the user experience.

D

A

Extending saturn.

B

I think that atom does almost the same thing. You can open a needed script and just add variables and key bindings. It's not as describe discoverable and not as introspective, because again it makes it it's kind of a list machine right. It's list all the way down, like the core mx knows what's happening in the lisp, because the corey max is kind of interpreter of elisp. So it knows what's happening in the outcome. Editor, it's not as discover discoverable, because the atom is not implementing javascript.

B

The electron run time is in is interpreting the javascript and precompiled with jet and everything, and then the atom is just like running in the same vm.

B

Maybe on saturn we can expose an sci, that's one of the things that I really want to try. I do not think that init scripts should be portable between atom vs code and well init scripts. Don't existing vs code except for joyride, so maybe use your right as an expiration for for the saturn editor, but maybe we can have a close experience in this saturn by using a ci.

B

So you write a fragment of clojure script in the sci name, it this sci, flavored clojure script and it's discoverable, it's hot reloadable and people can know like okay. This is failing because there's some beautiful stack trace that sei offers. You, let's say: okay. This is fading because of this and this and that so this is possible.

B

It's not the focus of the editor right now, because I want it to be usable, then I want to be friendly.

B

I want actually to be more friendly to be hackable, like clone the the saturn repository and starts hacking right away. If you want something on you, because it's a few person actually right now, it's a one person project, maybe two, because there's a friend that did the pull request for the react blasted version.

B

So it's a really big product to handle alone. So I want. I do not want to put a barrier for people that say: okay, I want to add something: there's an api on atom that I want to support. How can I do that? I want to be able to say: okay clone the repo run, the script and you're you're good to go just start talking. Nothing else.

B

That's one of the things that uh one of the experience that I'm focusing as of now, but in the future I want to be able to also be user friendly. Like have a tree view, people can click, people can use as a maybe slower vs code, but as friendly as vs code is and may they want. The extra power then can jump right in and start hacking again.

B

Maybe we can't have the same experience on dmx, because max is amazing for that it's, I think, one of the most hackable pieces of software that we have, but I do got a huge experience on autumn. I mean I can't do lots of things in the autumn editor.

B

I remember once I put the notifications of linux inside the atom editor, because I was missing like meetings and everything. So I was typing and then I would get an auto notification like okay, you have a meeting three minutes that was listening to leave, notify from linux, so it's doable with a needed script. It was not a plugin, it's just a native script that I did and again it's doable. We can extend it's discoverable, so this experience it's exactly the same as mx, but in a visual way, like graphical user interfaceable way.

B

Let's say something like this, and not only a text and text based with some graphical elements that emacs have today.

B

I think that's one of the the the things that are the the experience that I want people to you to have to not only have the hackable editor that you can change, but a hackable and also friendly editor for newcomers, and usually people say that emacs is not that user unfriendly and I cannot disagree more.

B

I never got the hang of vmax and I really really think that. Maybe I don't know if there were better tutorials for mx. This could be doable. This could be solvent in some way, but it's good to have to have like an alternative right. Currently, we have a max and vim. They outcompete in the same manner of the heck of a text editor.

B

I'm not sure if I'm making sense here.

A

Yeah, thank you.

B

It's kind of like having chrome and having firefox like firefox is a buggier version than chrome, but it's good to have concurrent a concurrent version of of like a browser, otherwise chrono just eats what the web. Well, it's already eating the web deciding on new new ways of how javascript should work and everything, but it was from firefox if I'm not mistaken, from mozilla labs. That was came to be so maybe if we didn't not have firefox, we would not have like web assembly right now. Website is kind of amazing.

B

So yeah, that's that's the idea. I think.

A

um By the way, are you thinking about about the use case of a remote file system and remote runtime for for closure, for example?

A

Well, when you're building it? Are you having this in mind, because I guess those things are the things that could matter when you're trying to build a modular system.

B

Yeah, I'm actually trying to think on this for the remote file system. I think it's mostly a matter of registering a different provider for the presentable, so, for example, instead of like I want to provide this file on this local machine, I could register provider that says. Okay, I want to provide this file from the local from the global file system and then it will just do the same thing but pipe through something else.

B

Maybe- and I almost sure I will have to do some kind of reordering of the plugin system, because currently I have what I call the presentable provider, that's something that presents something, and I don't know what the something is. I'm thinking about, changing that to be a presentable provider from a text editor and then I have another thing that that's a file provider that provides a file, so the editor can be completely independent of where the file is so it's doable.

B

If I reorder the the elements- but I mean it's one of the things I'm one of the hard parts is: how do I watch for changes in this remote file systems and, if possible, I'm going to support that too.

B

I do not know if there's an answer for that, maybe with polling or anything else, but the fire watcher is already thought about being a plugin, that's separated from everything exactly because, exceptionally because currently in the atom implementation, if three four different plugins ask to watch the same file, I'm going to create a notifier multiple times for this file, and I do not want that. I actually want the saturn to concentrate all the the watchers, because this can lead to bugs and it actually does little bugs like too much files opened.

B

You know or too much sockets open in linux and mac, so you have to like keep changing the global thing. That's on the linux kernel and people get scared. By doing that, I actually remember that. I got scared the first time that I saw the er in the solution to that so yeah. I kind of want to concentrate all of this in the center, so when someone asks I want to know to watch a file, saturn itself will capture that that request and say. Okay, do I have a watcher for this file already done?

B

If I do, I just add a callback. So when something happens instead of notifying this one person or this one plugin, I will notify this three plugins and that's some.

B

So this should work to alleviate the problems and also will work with remote files, because it's a plugin I can just put a new plugin that watches from remote files and things hopefully will work correctly so yeah. I am thinking about that. Also because it's one of the pain points of atom.

B

You can't work really well with remote fires and I believe it's one of the main frustration points for people that are moving away from it, because vs code actually does this really well and people like the flexibility of doing that in vs code.

B

I'm not sure, because I am not and I'm not a vs code user, actually, I'm still using atom, as you can see,.

A

Yeah personally, I sometimes use vs code just for this reason.

B

Yeah, actually using atom is kind of like when you have a friend that was bitten by a zombie and you're kind of like trying to keep it away from you, but you still like your friends so sometimes he's like. Oh guy. I'm sorry that I'm like this and say: okay, no worries you're still my friend and from time to time he's like brains, you know! No, no! Now you stay away from me. It's like that. I still like the editor. I still use it, but I can.

B

I need to be aware that it's slowing dying and rotting and I'm kind of like okay, this will probably not work. This buggy always happens when I try to copy this file, and I still am in vim mode, for example, so yeah, that's also one of the reasons. It's also personal gain that see if I can reuse parts of the editor that I love, but to do something that it actually will not die.

B

If I don't know, microsoft decides to stop the project altogether, which probably they will.

A

It is a perfect way to end the recording, okay, wonderful.

A

Any comment vincent.

C

um I am thinking uh I would imagine that in a modular program, people would use or tend to use a way of declaratively say here is an action here is something: uh is there some places in saturn where you are using some form of declaration.

B

Well autumn does have the the concept of comments that you can register, so you can say: okay, here's a comment that I want to register to the to the project and you can like use from the inside of the editor and plugins can call comments from other plugins and everything or you can use this provider consumer thing that it sounds again also a way to do the intercommunication of programs.

B

I am thinking about exposing reframe or whatever I use in future to the plugin authors, so they can like register new events or subscribe to changes in the ui or subscribe to other events that happen on the saturn side on the saturn core. So, for example, if I open a file, I could have like some kind of subscriber that says: okay, how many files do I have open right now and show it in the I don't know a pop-up or something it actually.

B

It's not that simple, because it's complicated to keep an editor like that, because everything starts to become public api right.

B

It's like there's a, I think, there's a comic in the skcd site that says the people that that are in the emacs user group saying: okay, the computer will not overheat anymore. If you press and hold uh white space and one of the persons say this breaks, my workflow, I do have a sensor just to see that my cpu is is overheating and it's something like that. I mean I do not want to expose everything, because I also want to be less dense to develop.

B

If I want to keep all the design decisions that we did in the first, I don't know three months of the project.

B

Then it will be really hard to keep the project and actually, I think it's one of the things that the kill autumn, because they do use lots of internal states in most plugins that they they have as car plugins.

B

So they can't really remove that element from the from the text editor for example, and do a better design system. Otherwise they will break like five packages and that's horrible honestly, because I try to create a facade.

B

My first try to implement this editor was put monaco in place of the atom editor and make a facade for all the apis to atom to be redirected to monaco, and that did not work because well, there are lots of internal state that plugins expect. So everything was like. Okay, I can't call this. I can't call that I can't call that- and I was like okay what's happening, I'm not doing anything and it was actually an external plugin that supposedly rendered the editor in some place of the.

B

What the ui that wanted a static element defined in the editor and monaco does not have that because that's synchronous, so it simply did not work, and I decided okay, it. It's not worth trying to do that, and I probably think that emax can have this problem also because it's listed all the way down, you can change anything anywhere in any place, but it again it's better for debugging, but I I mean the idea of autumn is to be less dense than other editors, less more easily hackable or developed, not hackable more easily.

B

I don't know if there's a word for that, but it it should be like easy to develop. You just clone the repo starts coding and everything should work and you can change things if the tests don't break, you can ship it as a fine as a final product, and I do not want to like pull the 100 most used plugins into the ci to see if the saturn is still working with them.

B

I want the test to guarantee that and if there's a misbehaved plugin well, I'm sorry the mystic behavior plug is at fault, not my editor.

C

Okay, thank you.

B

But yeah that I don't know if that answers the question I mean I do like the idea of being hackable up to this point, but I also want to be realistic that it's a few personal product, it's not really feasible to work with that level of of I don't know of detail on the core of the the plugin emacs can't do that because they have people working actively on the actually. That's that's one of the points that I have to give for emacs users.

B

If there's something that's troubling in mx, they kind of try to debug down to the editor level. Nobody tries to do that in any other editors, not even vim,.

C

Thank you for the presentation.

B

Okay, thank you for staying here.