Been making slow, but steady progress on my editor. I can properly zoom in and out on the canvas. I can have some panes that represent sub-file things. The power usage when idle is basically non-existent (down from 100% cpu usage always). I finally feel like things are starting to come together and that I can finish up some parts and then really start focusing on actually making the flow and features fit how I code. Hopefully soon I can start using it for a project that isn't coding itself so I am forced to add all the features I've been ignoring.

I love it! Though I hate the proliferation of scrollbars 😇

I don’t know what you are talking about. No scroll bars here ;)

Oh interesting. How were you scrolling, just keyboard?

I use the Mac trackpad for everything. So pinch and zoom and two finger scroll. Current controls are just convenience for implementation. Panning on canvas is ctrl plus two finger movement. So far has actually been decently nice

Nice. Yeah the thing that frustrates me sometimes is when small changes in where my mouse pointer happens to be on screen change what is scrolling. Something to watch out for.. Your approach does have an advantage over mine of just laying each buffer out without cropping. The cursors of key buffers can be close together even if the buffers themselves are large.

Ultimately I want to work with small enough subfile snippets of code that don’t need scroll. So hopefully won’t be much of a problem in practice.

You mean like much more clever UI for extracting methods? 🙌🏼 I want that as well, my functions keep getting longer over time.

Ooo, watcha using for graphics? SDL or smth fancier?

@Arcade Wise I'm using skia. But the last version I did used SDL. (https://jimmyhmiller.github.io/editor-experience) So far, I haven't really done anything I couldn't have done with sdl. In fact, (almost) everything you see is a wasm plugin drawing with very few draw commands.

#[derive(Debug, Clone, PartialEq)]
pub enum DrawCommands {
    DrawRect(f32, f32, f32, f32),
    DrawString(String, f32, f32),
    ClipRect(f32, f32, f32, f32),
    DrawRRect(f32, f32, f32, f32, f32),
    Translate(f32, f32),
    SetColor(f32, f32, f32, f32),
    Restore,
    Save,
}

Oh interesting! Thanks jimmy :3

Ultimately I want to work with small enough subfile snippets of code that don’t need scroll.

Easy: use Smalltalk ;-)

Interesting to consider such a UI for a Smalltalk project 🤔

Yeah, Smalltalk is definitely an influence here. But I don't want the walled garden. I will also say that one of my requirements is that nothing can lock the UI. When, for example, I'm using glamorous toolkit and I do a long operation, the whole application hangs. With my setup, you can make an extension that goes into an infinite loop and the UI is still completely responsive. All of that happens, even though I am currently still single threaded. I do think this project has given me an appreciation for why Smalltalk would have an object system like it had for the gui it had. I can definitely feel how OO might have co-evolved with that kind of setup.

How do you pull that off?! Preemption on a single thread?!

This is one of the reasons I went with wasm (despite its downsides). Wasmtime has was of doing interruption. I happen to use epoch based interruption. So now that I give the details, I do happen to spin up another thread, but it literally just increments a number and sleeps. (I could have done the exact some though with the fuel based interruption and not used the extra thread). The great thing about this, is because this is all handled by compilation, my code knows nothing about it. I even take advantage of this separation for other interesting things. I can have code that blocks waiting for a value, but that blocking call in my extension is turned into async code for the editor. So I get an async/await style setup with no-syntactic distinction. I consider this editor a 10 year project. So hopefully at some point, I'll replace the wasm with my own setup. But this interruption based setup has been super nice. https://docs.wasmtime.dev/api/wasmtime/struct.Config.html#method.epoch_interruption.

Ooh, nice feature for a VM to have.

@Jimmy Miller

I do think this project has given me an appreciation for why Smalltalk would have an object system like it had for the gui it had.

I remember seeing advice to a newcomer about how to choose between a generic data structure (list, dictionary...) and a new class: "If it makes sense to add specialized inspector views, use a new class." That's UI-driven code architecture.