Skye Im
Skye Im
 Here's cell support.  Can also have both rows and columns. Even cell-based, if you want. It took me a lot of trial and error and fiddling to get...
> I think the API and implementation could be made a lot simpler if we change the per-column and per-row coloring to just be a single lambda, like so: Sounds...
One concern about having a single ColorPickerFn (`fn(usize) -> Option`), respectively for row & col, is that it's harder to compose different color picking methods. For example, specifying both `striped`...
Turns out that for any practical colorpicker, we really want to be able to capture variables in closures, so I changed ColorPickerFn to be a boxed Fn. I wonder if...
Seems this PR has fallen off the bus.
It's definitely an oversight that it only works for `convert` when it should also work for `scml`.
Sounds good to me!
I've tried a different approach, lifting all the update logic into its own fn and `return`ing whenever an error is encountered. It's certainly much less nested, but I'm not sure...
I have pushed a change that makes non-JSON responses from the features endpoint be more obvious, a la #37