Post

Looks juicy. Have you ever found the layout to be unsatisfactory when you have graphic interfaces inline with the text? Or is it simply not a problem?

short answer, yes, but i'm exploring different options. right now there are two inline style for multiline affordance in the code; Tab (pictured) where the code resumes on the same line it stopped on and Block (where code resumes at the bottom). also an offside disp option (the players at bottom)

together these can be used for fun layouts. but sometimes they are overly constraining. other things i am actively investigating: (a) first class combinator UIs that are basically flexbox and grid, and which bottom out as editors, so you can use them to arrange whatever

(b) more canvas-style combinators where you can take an subtree of code, and 'punch holes' in it corresponding to sub-subtrees or sub-GUIs. this replaces the whole subtree with a canvas on which the punched holes can be freely positioned

so in short still an active investigation for me. one awkwardness is switching between text and mouse/touch driven modalities... i think to feel truly good, both the base editor and the embedded GUIs need thoughtful dedicated mouse/touch and keyboard controls

0 reposts3 likes

That’s an interesting concept: that containers bottom out as editors. So that at least you get to see something? Would the Combinator containers be analogous to union and sum types, so you get a default layout for some composite data?

Or that is usually bad because the structure of the types isn’t expressive enough for an info arch that can answer a user’s question. I guess I’m asking about how to get sane defaults for a layout.