The problem: implementing text editor operations as lines might wrap or scroll.
e.g. clicking with the mouse to reposition the cursor, or pressing the down arrow (which might cause a scroll)
The key new solution: an API of primitives that make such operations fairly self-evident to build.
- to_loc: (x, y) -> loc
Identify the location at pixel coordinates (x,y) on screen.
Returns nil if (x,y) is not on screen. - to_coord: loc -> x, y
Identify the top-left coordinate on screen of location loc.
Returns nil if loc is not on screen. - down: loc, dy -> loc
Find the location at the start of a screen line dy pixels down from loc.
Returns nil if dy is taller than the screen.
Returns bottom of file if we hit it. - up: loc, dy -> loc
Find the location at the start of a screen line dy pixels up from loc.
Returns nil if dy is taller than the screen.
Returns top of file if we hit it. - hor: loc, x -> loc
Find the location at x=x0 on the same screen line as loc.
I think they might be applicable to any pixel-based editors that use proportional fonts. They seem independent of the data structure used by the editor. I use an array of lines, and so locations are defined as (line_index, pos) tuples, where pos counts in utf-8 code-points.
There's probably a few bugs but hopefully it'll stabilize quickly. I'd appreciate people trying it out.
Lessons from this experience:
- There's a "hard part" to programming beyond the reach of tools or methods. Sometimes a problem needs the right "algebraic" abstraction, designed around an invariant and preserving it across any composition of operations.
- Not all programs get this hard.
- It's useful to notice when some part calls out for doing this hard, focused work.
I think I now better understand the "abyss".
This post is part of my Freewheeling Apps Devlog.
Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.