 Yeah, we still have a lot of pieces at this platform. So I'm going, last time that I have hacked on the new thing, and this time it's at the other editor that is easy to be programmable. So what I've done, that's start from the demo. So that's what I've done is like the markdown preview. That's what you have tied in the left-hand side will be displayed on the right-hand side as a web view. So suppose that Google, then right-hand side should be a link to Google. Et voilà. So what's the atom atom that is the GitHub editor? And it has been released. And we built on the framework election, which is also based on the web kit, which is pretty easy to hack on it. Because it's built on the web, you can use JavaScript, HTML. And unlike new things, it's all binary. And you'll have to watch on its API. And it's also very easy to act in an environment like Emax. You basically can do anything with JavaScript. Yeah, an atom API that is like you can do whatever in the repo loop that it comes with a developer console. Yeah, it's basically like Chrome console that here's some debug message that you can bring in anything you want. And suppose that editor that you can do anything was specifying API in the repo loop. But the what's different is that I want some of you that might know that GSC.js, which compiled Haskell code into JavaScript. And so the most critical part in the Markdown previewer is that I delegated to Haskell, which comes with a Markdown package that transforms all of the Markdown syntax into HTML. Then after that, I basically just need to write it to a file and load that file into one view. But so it turns out that the code is pretty short, that I just need to render Markdown and call the render HTML from the Markdown syntax. The only tricky part is that how to make JavaScript world talk to the GSC.js world, which is also compiled JavaScript, but it comes with its own runtime. And you have to pass argument to it, which is the Markdown string from the editor, which I can get editor and get string from the atom API. And then pass it back to the JavaScript world, which is the compiled HTML. So the good thing is that the JavaScripts have global variable. Whenever it doesn't preface with bar, it goes to the window, which is top level. So GSCs just have import, which is FFI. Then you can do any unsafe thing for it. Then what I have basically done is to set the function you have implement in the Haskell world into a global variable. Then in the JavaScript side, you have the global variable, which you can like get its property that is property to pass it to the Haskell world. Then set another property by convention, then pass it back to JavaScript world. So I've been using is like get property markdown string, which is like explain itself, which is just a global variable's property, like having the markdown string. And set it by convention a return value to the same object with the return attribute. So the main function, because it has to be made. So then when you compile with GSCs, you just specify the problem so that it doesn't come to some node JS runtime overhead or something like that. So yeah, that's all. So that's what I've been explaining. Then compile to JS, which I've also described. I compiled it with a stack execute. Somebody had done with some snapshots, so you don't have to follow the instruction from the GSC JS, which is also easy instruction. But I'd like to be isolated like that has its own snapshot locally. Then this one is important that you have to specify GSC JS browser. Otherwise, when you run it, it will bump into some arrow. Then you just compile that into render.js, which at this moment I don't like it is that which is pretty large. That the render.js, which is 6 megabytes, it doesn't come with closure compiler to minimize it, so it's like full symbol. But still pretty large that if you like. When you look at the code, is it something that would be all OK and fine? Yeah. So meaning fire should stop? Yeah, it would definitely help. Because I don't want to minimize it since I want to know how to make two sides of world communicate each other. Yeah, so actually you can also search for the render markdown, but render markdown. That it comes with that the foreign function call. So somehow that is just set there as a global variable. You can see that there is no var before it. So it will come with a global variable. Yeah. So then in the item side, I still need some gluing code for that. But I just like basically what I have described it. First having an option object with a markdown string field name which is agreed on convention, then pass it, then calling back with the return attribute. Then I just write it into a file, then load the value with its source as the file. Yeah, that's all. There's typo. But that's how you develop an item. So that's the whole life. You can quickly hack on like plug-in with JSON. I feel like I said, so who added this JavaScript editor that you grew up plotting for in JavaScript which caused the hashed function to reach the compile file? Who reaches the target file, the compile Haskell file? Yeah, yeah, yeah, yeah. At items still need to, like first, here's some like minimum gluing code. So here, the show it will be called when I like start the plug-in. So here's the some deval message. First, I call its API all under Atoms, Atom.workspace.activeEditor, which has the focus. Then I get editor as long as it's not now. Then I start adding an observer function. Once whenever I start typing and the event like have like stop for a few milliseconds, then this listener will be called. Then I can get its text. Then use that to render the contents. What is the plug-in code? Yeah, this is plug-in code. I still need the gluing part to get editor's text, which is a whole editor's content for Markdown. What does the plug-in look like and what does it look like? Do you have a folder where you have to do it? The whole like plug-in layout that you can generate with Atoms, that common line. Maybe we generally hold the whole layer. In this directory, the lib, manuals, spec style, key maps all are generated by Atom. So this star-platium view and star-platium is also generated by Atom common line. Only the render.js is what I compile and copy here. Then for the generated code, which is very minimal, but runable that you just like loading something and having a learning window. So the gluing code is basically just like you would do whatever GUI, usually when you develop cross-platform, you have a core part that's serving the core functionality you want, then having the gluing code in your whatever is editor or display interface that calling the backend and get result backend drawing. So they follow the same logic. But for sure you can still use having some message passing by convention to GSC.js in some of minimal GUI functionality. But that would introduce too much overhead. So I prefer to still write a little bit JavaScript to make it work. This looks more lightweight to me. Yeah. This is another file. Most of them are generated. So yeah. And WebView is pretty useful because WebView basically you can do anything without Atom workspace has some limitation. Yeah, that's all. You mentioned the file size of the generated JavaScript. But the biggest problem with the file size of GSC usually is that it takes so much time to download the file which is a problem in this case. Yeah, because it's part of the plotting, right? That's when you install it in your local system. So is the size of the practice like do you think it's a problem in the practice or would you just set it with 6 megabytes? Initially, I was worried about it. But it seems like for Atom's fee is good enough to afford GSC.js runtime. Well, maybe for larger plotting might introduce some issue. But for this one, it seems fine. But when you open it, is it? For communication, yeah. It's just one concept, it's property. So even like OK, if you want to see what we're having to hear me, does it mean that if you edit the model down and you save the file and it takes long time for the WebView to refresh itself? Or what exactly is the user visible? I think it's what Zonka is asking about the GSC.js What compiling to the JavaScript file is overhead. And of course that my implementation that is pretty straightforward. That just went right however into the file and loaded into WebView. I'm sure that there's some better way to do it. So that's for Zonka's problem. My question is, suppose you edit your model down and then as I understand, when you save it, it runs this GSC.js that generate the JavaScript, generate the HTML, which is on display. As long as the time between saving the file and seeing the object is HTML, as long as that's short enough, it doesn't really matter if it's 6 megabytes or 60. Yeah, it depends on the size of the JavaScript file. Yeah, it must be slowly exploding. Yeah, in the memory. Because it would be that if you would link in lots and lots of libraries there, it would not be a matter of... Yeah, I guess that's today.