cell

ww.nu42.com/2015/03/how-you-average-numbers.html [3]: https://en.wikipedia.org/wiki/Algorithms_for_calculating_var... [4]: https://github.com/garritfra/cell/releases/tag/v0.2.0

ll is whether BAR returns a CellValue::Visual { … } that the renderer dispatches on (correct under column resizes, but ripples into CSV export, copy/paste, and how SUM treats a visual cell), or whether it just returns a string of block-drawing chars at eval time (trivial to add, but width gets baked in at compute time which is wrong). The first is the right answer; the second is a tempting MVP. SPARKLINE(range) is the natural follow-up once the abstraction settles. #17 — https://github.com/garritfra/cell/issues/17 #18 — https://github.com/garritfra/cell/issues/18

e topo sort is the hotspot before optimizing. AST caching on Cell is the obvious next step once #7 confirms parsing dominates. https://github.com/garritfra/cell/issues/8 https://github.com/garritfra/cell/issues/7 Dependency tracking. The bigger smell is in extract_deps — a range like SUM(A1:A1000) literally enumerates 1000 cell positions into the dep graph, with a HashSet per cell on each side. Fine at hundreds of cells, a disaster at hundreds of thousands. Range expansion is one of the bench cases in #7; the proper fix (interval-keyed deps so ranges stay first-class instead of fanning out) doesn't have its own issue yet — I should open one, since #7 only measures the problem. Undo/redo. This is the worst offender right now. UndoEntry only had a single-cell variant until very recently; #12 added MultiCellEdit, but #13 tracks two destructive paths I missed — visual-mode d and p/P paste — that still don't push undo entries at all. #9 is the broader coalescing story (one dd = one undo, CSV import = one undo, etc.), tied to the batch mechanism from #8 so a single transaction produces a single undo entry. sort_by_column is also non-undoable today and belongs in that bucket. https://github.com/garritfra/cell/issues/13 https://github.com/garritfra/cell/issues/9 Larger CSVs. Storage is HashMap<CellPos, Cell> — fine sparse but with overhead per cell; for very wide imports a column-oriented or arena layout would pay off. I haven't profiled it though, so this is speculative; the dependency-graph blowup will hurt before raw storage does. #7 includes a 100k-row CSV load case to put numbers on it. And #10 is the meta-issue to lift all of this out of source comments and into actual architecture docs, which I probably should have done before posting. https://github.com/garritfra/cell/issues/10 So: nothing here scales today, but the architecture splits cleanly enough that none of it needs a rewrite — AST caching, dirty-set recalc, range-aware deps, and grouped undo are the four threads, and most have issues attached.