I’m deep in the middle of implementing the design discussed in the earlier post. The ‘navigation’ mode stuff we’ve seen before, it’ mostly done and shown here. The other mode is the ‘explorer’ mode. You navigate around, select a subexpression for editing, and up pops a crazy advanced autocomplete box with a ton of functionality, which is what I’ve been building (have just finished v1, actually), learning a lot about Reflex in the process. It’s a complex component, with a lot of requirements:
I was thinking a little bit more about how to nicely layout expressions. In Unison, the user doesn’t explicitly determine how expressions are laid out down to the level of individual line breaks and spacing. The layout engine handles most of this and the user only controls how particular functions render when applied to arguments.
I’m at the point where I have all the machinery needed to start adding the ability to edit as well as view Unison expressions in the editor. However, rather than diving right into implementation (which I did before with the Elm-based version), I decided to take a step back and try to figure out a better story for fluent semantic editing.
I did some refactoring to allow the Unison editor to run “headless”, using a local, in-memory node rather than a remote Haskell server. This opens the door to a few things.
Here’s a question, what happens if there’s a collision with the hashing scheme used by Unison. What would happen, and is this something we should worry about?