I tried this out when it was mentioned a few weeks ago[1].

It's pretty neat but does have a number of bugs. The packaged version also doesn't have xls support compiled in (at least on Fedora) which is unfortunate, though building is fairly easy[2].

I love the idea of it though, so I'm really hoping these issues get ironed out! I'm happy to help contribute if maintainers are willing.

[1] https://news.ycombinator.com/item?id=47457009

[2] https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80...

I think spreadsheets are a greater example of something that require the subtleties of an actual GUI. This is most obvious with the various plots which are hilariously imprecise. But the advantages of GUI are also present when just using the spreadsheet itself, it's ability to convey the skeuomorphic two dimensional space is much greater.

And it's not like the terminal can't be a greater data processing tool, but you have to use different paradigms.

Still from an esthetical perspective I love those simple TUI interfaces. They invoke a weird sense of comfort in me that I can't fully explain.

This could just be a skill or wrong use case thing, but do you only use spreadsheets for pure number-crunching? I've played terminal spreadsheets, mostly sc-im, but I often have some longform text field (like 'Notes') that becomes more fiddly to deal with than a GUI.

Visidata is the only terminal program I've found that handles large text fields in tabular data nicely the way you can drill down into a table row, then Ctrl+O to edit a field in your editor, but it's not a spreadsheet.

I love this but with all the advances of TUI frameworks, using C + ncurses feels like such a hard path.

Cool which newer TUI frameworks do you prefer?

The ones nobody's finished yet.

But why?

This feels like the kind of domain in particular where the advantages of a GUI provide a superior experience, and once it gets sophisticated enough you'll have basically built one anyway just in the terminal.

I used blocky spreadsheets a few decades ago... Tell me why I want to use them again today?

Legit question - I want to understand the needs I'm overlooking which this thing meets. (Please don't just reply "lack of ribbon/ads/bloat etc", none of that nonsense is required in either flavor).

The blocky spreadsheets of yesteryear could run in a few kilobytes of RAM. Today, that's microcontroller territory. From there, I can contrive a few answers:

- A spreadsheet that runs in a RISC-V+Core-V device is less susceptible to supply-chain issues and geopolitical stresses.

- Price. The hardware needed to run a text-only spreadsheet is worth about 10 bucks or less.

- Energy consumption. Now the server with your business data can run deep within energy-starved communist Cuba...probably.

- Better security. Plenty of people and armies get nervous about keeping tallies of dangerous toys in computers with lots of ICs and closed-source blobs made in enemy territory. Just enumerating all those ICs and blobs in a conventional laptop or tablet is difficult.

- Size. A smaller, cooler chip is easier to hide, which matters if you spent your trip to the motherland working on something you don't want customs to find out. In that case, you can use your laptop as a terminal to the sensitive data in your server running inside a button of your jacket...

I'd love if this had support for saving as xlsx. Being able to open them is nice, but it would be great if I could collaborate with MS Office users without them ever knowing.

It does. It's not compiled in to the package repos though, so you might have to build it yourself[1]. It's also a bit buggy currently.

[1]: https://github.com/andmarti1424/sc-im/wiki/Building-sc%E2%80...

Same story with gnumeric-xlsx back in the day. The "requires build from source" and "a bit buggy" combo usually means it works 80% of the time until it quietly corrupts a formula. Test before trusting it with anything real.

Related ongoing thread:

Sheets: Terminal based spreadsheet tool - https://news.ycombinator.com/item?id=47636456 - April 2026 (46 comments)

A modern launch of a similar tool: https://github.com/maaslalani/sheets

That one is being discussed at https://news.ycombinator.com/item?id=47636456 - OP looks to have been a follow-up (which is great in principle but we downweight them for reasons described at https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...)

Love vim stye editing

See also visidata for an alternative https://www.visidata.org/

lots of bugs and crashes last time I tried it. Should see if it improved

Insane what people make these days, but its really cool!

These days? There was a time before graphical user interfaces existed/were possible.

1979: https://en.wikipedia.org/wiki/VisiCalc

Been using it for months for quick CSV work over SSH. The vim keybindings are complete enough that muscle memory transfers. One gotcha: column width adjustments are per-column with > and <, took me an embarrassingly long time to discover.

So Lotus 1-2-3

But originating on Unix in '81, and thus predating Lotus 1-2-3 by ~2 years.

Lotus was more than sc with a GUI -- it introduced the macro language, named ranges, and the @functions that spreadsheets still use today. Calling it "so Lotus" flattens a lot of genuine innovation.

So... Visicalc?

Minor pedant note: sc-im is "SC IMproved", where sc is Spreadsheet Calculator, an 80s-era program. Same naming pattern as vim. I keep seeing people treat it like a new project, but the underlying sc is ancient.

> Very shitty software.

To be even remotely constructive, you're going to need to be a little more specific.