I actually created one for some time ago. It's nothing special but it has Vi keybindings.

https://github.com/RauliL/levite

Emacs with org-mode and evil-mode seems to be up your alley.

There is SC and now sc-im: https://github.com/andmarti1424/sc-im

You can also literally run Lotus 123 if you want. Someone has binaries to make it work on linux. or under dosemu

sc has been around for quite a while: https://github.com/robrohan/sc there are several versions floating around.

Oh man, a TUI spreadsheet application that can edit ODF or XLSX format would be absolutely killer. Would love to hear if anyone knows of such a tool

Visidata[0] is a killer data swiss army knife. It's even inspired off Visicalc

[0] https://www.visidata.org/

According to Bob Frankston, Bricklin's co-founder[1]:

> The basic approach was to allocate memory into fixed chunks so that we wouldn't have a problem with the kind of breakage that occurs with irregular allocation. Deallocating a cell freed up 100% of its storage. Thus a given spreadsheet would take up the same amount of space no matter how it was created. I presumed that the spreadsheet would normally be compact and in the upper left (low number rows and cells) so used a vector of rows vectors. The chunks were also called cells so I had to be careful about terminology to avoid confusion. Internally the term "cell" always meant storage cell. These cells were allocated from one direction and the vectors from the other. When they collided the program reorganized the storage. It had to do this in place since there was no room left at that point -- after all that's why we had to do the reorganization.

> The actual representation was variable length with each element prefixed by a varying length type indicator. In order to avoid having most code parse the formula the last by was marked $ff (or 0xff in today's representation). It turned out that valid cell references at the edges of the sheet looked like this and created some interesting bugs.

It leaves out a lot of details - if you're skimping enough you could allocate variable length row vectors, but it seems they wanted to avoid variable length allocations, in which case you could start with a 255 byte array pointing to which subsequent equal-sized chunk represents each in-use row. You'd need at most 126 bytes per row in actual use to point into the chunks representing the cell contents. But this is just guesses.

[1] https://www.landley.net/history/mirror/apple2/implementingvi... and https://news.ycombinator.com/item?id=34303825

Isn’t the existence & success of visicalc a direct counter to this?

All kinds of operational departments. I'm sure it was used for accounting, payroll and commissions, inventory tracking, I know that teachers used it for gradebooks as I helped set them up when I was in high school (early 1980s).

Pretty much anything that you used to do on paper with a columnar notebook or anything that could be represented in tabular form could probably be implemented in VisiCalc, Lotus 123, and others. Spreadsheets are probably the most successful software application that was ever invented. Certainly one of the most.

Accountants, and individuals within all kinds of businesses (what we today would call shadow IT). Imagine something like this:

* Person who deals with numbers all day goes to a computer store to browse.

* He sees VisiCalc, and immediately understands what it can do. It *blows his mind*.

* He wants to buy it right away. Pays for $2000 Apple II computer with disk drives to run $100 software; price is no object.

* Shows friends and colleagues.

* They rush to computer store. Repeat.