Summer UI Refresh

[disconcision]

closes #144, #891, #968, #994, #1009, #1078, #1107, #1167, #1190, #1314, #1361, #1363.

Update to the Hazel top-level UI and general UI/deco cleanup.

Breaking changes:

• Linebreak refactor: Linebreaks in Hazel were previously internally represented using the ⏎ character because of reasons. They are now represented using \n, unwinding several long-standing hacks. This change requires regenerating any extant serialized hazel zippers. This can be done automatically by find-replacing \226\143\142 with \n.

Interaction Refresh:

• Make double-click select token (across the board)
• Make triple-click select term, or parent term if token==term. This no longer rounds up to parent in the convex atomic case, which could be confusing. However, it does now handle the special cases of list literals and case rules, as well as several other edges, including tile selection behavior for lets/typedefs
• Always break existing selection on any move action, even if the action doesn't actually move the caret
• Suppress suggesting != operator as a completion as it distracts when entering the ! operator

Style Refresh:

• Rewrite piece and caret decoration drawing code to keep them in sync and eliminate pixel-level discrepancies
• Redesign top bar chrome for future breadcrumb bar integration (see Vibe notes below)
• Consistently style menus (context display and nut submenus)
• Restyle nut menu submenus to more effectively support large numbers of entries
• Make top-level UI hover effects more consistent
• Make top bar size consistent with bottom bar, and make all text on both bars use the same font size
• Design a consistent color palette
• Derive secondary colors using OKLCH and the CSS relative color calculations
• Make whitespace in Typ pretty-printer consistent with Editor representation
• Shorten longer documentation slide names
• Make the X to close sidebar consistent with the stepper settings panel X
• Make select menus consistently styled

Fixes (See also tagged issues):

• Fix context inspector drop-shadow z-index
• Group test checkmark/Xs and make appear overtop selections
• Don't render the context inspector when it's not visible
• Always save editors before all export actions

Cleanup:

• Factor out all color and z-index constants to variables.css
• Split CSS monofile into component-specific files
• Cleanup old TODOs that are no longer relevant
• Dead code pass on syntax subsystems
• Global dead module pass

Docs:

• Add Hazel architectural diagram and it's tldraw source
• Add Hazel Syntax Types Table
• Add Hazel Color Palette diagram

Notes on vibe:

In general what I feel we're maybe moving towards is interpreting both bars as part of a linear progression between general and specific. The nut menu governs global settings (although some entries are contextual), and along with the 'hazel' title represents the root of the application. To the right, the mode selector (docs/scratch/exercises) represents a selection between different top-level application modes, and the following selector represent top-level-mode-specific sub-modes. The intention is that the upcoming breadcrumb inspector should immediately follow this, representing the levels hierarchy between the root editor level and the indicated (caret) term. Aspirationally, the mode selectors will become part of this breadcrumb view, and the 'hazel' element will become a representation of the actual root level of conjoined hazel program subsuming extant modes. The bottom bar is a continuation of the top bar, now at the the semantically most-local level. It might be worth considering re-ordering the elements to represent a flow from more general to more specific, in terms of the context-sensitivity of the semantics. The sort is likely the most general, being purely syntactic, followed by the typing context, which is context-sensitive but is generically applicable across all sorts. Then the term class. Perhaps this should be followed by the projectors UI, as projectors are applicable based on (to a first approximation) syntax class, with error status following as most specific.

[cyrus-]

looks good, and the proposed sequence for the bottom bar seems logical if you can make it look good. we should figure out what longer error messages look like as well (see #1127)

[disconcision]

@cyrus- agreed in principle but finding it hard to think of what exactly the general case for multiline errors should look like without bringing some higher-level markdown-type considerations and a pretty printer into it

[disconcision]

@cyrus- how do you feel about getting rid of show context inspector on hover and make it click-only? i want to make it so that it doesn't render when it's not visible for perf reasons, and its slightly complex to have two different visibility modes (pin and hover), so I want to make sure there's actually a reason to so do so. From my perspective, pin works fine.

(i've removed the zen mode collapse option from both top and bottom bar, will revisit in the fuure)

[cyrus-]

@cyrus- how do you feel about getting rid of show context inspector on hover and make it click-only? i want to make it so that it doesn't render when it's not visible for perf reasons, and its slightly complex to have two different visibility modes (pin and hover), so I want to make sure there's actually a reason to so do so. From my perspective, pin works fine.

(i've removed the zen mode collapse option from both top and bottom bar, will revisit in the fuure)

seems fine to me

[cyrus-]

this is a bit odd looking

[disconcision]

@cyrus- agreed, although a principled fix given the current model is not immediately apparent to me. or i guess to be specific, what aspect are you refering to? the coincidence of the ellipses with the concave grout or something with the error holes?

[disconcision]

if it's the ellipses, i could move them back to directly adjacent to the let. this feels slightly sub-optimal to me from a consistency standpoint but would definitely look better in this specific situation

[cyrus-]

yeah moving the ellipses would be fine

[disconcision]

@cyrus- how do you feel about the ellipsis in general? the reason for this regression is that i removed a somewhat awkward and brittle hack in the completion system, not realizing how it would effect this case. I mildly prefer the ellipsis to nothing, but i never really thought of it as a long-term solution. in retrospect though I prefer nothing over having this hack in the system, and doing it properly involves too major a rewrite. as such i'm inclined to simply remove it

[cyrus-]

removing the ellipses seems fine too

[cyrus-]

[cyrus-]

When I triple click on 5 here, it selects the preceding let line

[disconcision]

@cyrus- all of those bugs and a few others (see newly-tagged issues) are fixed.

[cyrus-]

the triple click issue is still there for me?

[disconcision]

@cyrus- forgot to push, should be there when it builds