Visidata is a fast popular data tool in python https://www.visidata.org/ if you just want data entry.
If I may be permitted a small plug ...
Oleo is a GNU spreadsheet going back absolutely donkey years. I cloned the repo here: https://github.com/blippy/oleo and made minimalist fixes to get the thing to compile.
I wouldn't say that my project is particularly good, but it does have a number of features that I find useful. The next release will include Tcl bindings, so you can customise some of the workings of the app. There's also a module available where you can go to town programmatically.
It opens up a world of possibilities, including stuff like pivot tables.
package require oleo
load-oleo mysheet.oleo
set ws [toMat]
set subset [subRows $ws [mand [mstreq 2 foo] [mstreq 3 bar]]
It has what I think is a nice little query language, too. In the last line I select the rows from the spreadsheet sheet column 2 is equal to foo and column 3 is equal to bar.
I'm kinda dog-fooding it at the moment to put in place features that I need. It doesn't have the full equivalence of SQL-equivalent though.
Visidata does vastly more than data entry. It's one of the most powerful applications I've used in years, and basically functions as a cross between a spreadsheet and a relational database with an extremely configurable TUI interface. It's one of the best tools available for doing ad-hoc data analysis, transformations, and joining data from multiple sources in different formats.
There are few comparable tools that allow you to open a Postgres table, a local CSV, and JSON being returned from a REST API in real time, do a complex join, filter and normalize the results, all in a single terminal session.
Oleo is C, circa 50k of C code, Neo(-leo) is around 5k of C++ code. A 10th of the size, but not necessarily any less powerful. Oleo has some memory leaks in places, whereas Neo has no (known) leaks.
Oleo uses lex and yacc, whereas Neo has a hand-parser.
Oleo is in the style of emacs bindings, whereas Neo is more vim-like, but without the modality.
I think the Neo code is better-structured and more readable (but I would say that, wouldn't I? - although it is far from perfect). C++ generally makes code more readable and obvious, without all that pointer arithmetic.
The internals of Oleo are more complicated. It uses byte-code for cells, for example. Neo stores a parse tree for a cell. So you can see that a lot of programming effort is saved right there.
In terms of speed, I suspect that the original Oleo is faster, although it's difficult to benchmark.
Neo is also heading towards being a library that you can compile in with other C++ code. Plus there's an interface to Tcl, which Oleo never had. So you get a lot of extensibility there which Oleo doesn't have.
I also think Neo is more generally accessible. It's got something in the way of a menu (still early stages), which helps. Neo is just generally less fiddly with editing cells, IMO. The mouse works, too.
Oleo does have an interface using Motif. Very early-90s. There's even an interface to GTk, although I don't think that works properly. I decided to abandon all that and just stick to an ncurses interface. After all, if you want a fancy interface, there are proper options these days like LibreCalc, Caliigra and Gnumeric.
To add to the cool things you can do with Neoleo, I wrote a little TCL extension that loads current processes into the spreadsheet. I added custom bindings so that you could search for processes, go to its parent, and kill processes.
I'm also half-way to adding a little calendar extension, too.
I suppose that's fair, and I concede, though I think you can play with the definition enough to make anything spreadsheet (even GUIs and webapps) be "reinvention" of visicalc, so I think the term is actually pretty meaningless.
All spreadsheets used to run in your terminal, in the old days. You can still download one here and I wouldn't be surprised if it still works: https://winworldpc.com/product/quattro-pro/4x
Semi-related: I always wished there was something like the unholy combination of a spreadsheet and notebook rolled into one. I picture it notebook-like at the top level, then each cell is a widget that the host language can reference parts of in other cells (probably with a variable (eg: something like mathematicas Out[_]) or a built in construct (like the $ABC123 forms in spreadsheet formulas)). A notebook interface would also be good (I think) as a straight up terminal as well, as you (I) typically want to run commands in an order like in a notebook
Some time ago, I remember Microsoft having made a video for a "courier tablet" that was essentially an electronic notebook. Either side of the spine was, by default, just plain "paper" that could be drawn or written on. It had some kind of intelligence to recognize stuff, so if you started drawing out a grid it had basic capabilities that could be attached to that grid, like spreadsheets.
At least, these are things I think I remember. It's not quite what you're imagining, but it was cool and along the same lines.
If I’m remembering correctly, I had bought a Borland Turbo C++ compiler circa 1994 (for DOS) that came with a demo sheets application you could build and run.
Teapot is pretty great, it's too bad there is close to zero room for real innovation in the spreadsheet domain. For the most part if it's not spreadsheeting how prophet Dan Bricklin envisioned, people don't want it.
See also: lotus improv
Actually... on that note I realized have never tried lotus improv.
> Teapot is pretty great, it's too bad there is close to zero room for real innovation in the spreadsheet domain.
One issue is that this is hard to do while still retaining backwards compatibility. Lotus Improv basically gave you no other choice, something that Excel The Next Version can't do. And I doubt that we're getting a third MS app, no Multiplan -> Excel -> NewSpreadsheetThingProbablyCalledCopilotAnyway.
I know a lot of people that don't even use Excel's tables, introduced almost 20 years ago. But instead they painstakingly recreate most of its built-in features. It's just an easy shortcut away, and has plenty of GUI support hidden in the ribbon morass, but it's not the default state…
Oh man, I played with teapot once a long while ago, but couldn't figure out how to parse values from XDR files in $LANG, or export some given sheet into CSV or other format- which sadly put a stop to my experimentation. Super interesting otherwise, and wish it had more eyes.
To really be useful (to me at least and a handful of others I've talked to) it has to have xlsx support or at least open document format. If you're not sharing it with anyone then csv-only is fine, but still very limited. This project is early days though so shouldn't be judged for a while, but I would heavily suggest not overlooking compatiblity support even though it's a nasty boondoggle.
54 comments
If I may be permitted a small plug ...
Oleo is a GNU spreadsheet going back absolutely donkey years. I cloned the repo here: https://github.com/blippy/oleo and made minimalist fixes to get the thing to compile.
I also based my own terminal-based spreadsheet based off of it call neoleo: https://github.com/blippy/neoleo
I wouldn't say that my project is particularly good, but it does have a number of features that I find useful. The next release will include Tcl bindings, so you can customise some of the workings of the app. There's also a module available where you can go to town programmatically.
It opens up a world of possibilities, including stuff like pivot tables.
It has what I think is a nice little query language, too. In the last line I select the rows from the spreadsheet sheet column 2 is equal to foo and column 3 is equal to bar.I'm kinda dog-fooding it at the moment to put in place features that I need. It doesn't have the full equivalence of SQL-equivalent though.
¹ https://matthodges.com/posts/2025-09-30-visidata/
> Visidata is a fast popular data tool in python
https://www.visidata.org/ if you just want data entry.Visidata does vastly more than data entry. It's one of the most powerful applications I've used in years, and basically functions as a cross between a spreadsheet and a relational database with an extremely configurable TUI interface. It's one of the best tools available for doing ad-hoc data analysis, transformations, and joining data from multiple sources in different formats.
There are few comparable tools that allow you to open a Postgres table, a local CSV, and JSON being returned from a REST API in real time, do a complex join, filter and normalize the results, all in a single terminal session.
Oleo uses lex and yacc, whereas Neo has a hand-parser.
Oleo is in the style of emacs bindings, whereas Neo is more vim-like, but without the modality.
I think the Neo code is better-structured and more readable (but I would say that, wouldn't I? - although it is far from perfect). C++ generally makes code more readable and obvious, without all that pointer arithmetic.
The internals of Oleo are more complicated. It uses byte-code for cells, for example. Neo stores a parse tree for a cell. So you can see that a lot of programming effort is saved right there.
In terms of speed, I suspect that the original Oleo is faster, although it's difficult to benchmark.
Neo is also heading towards being a library that you can compile in with other C++ code. Plus there's an interface to Tcl, which Oleo never had. So you get a lot of extensibility there which Oleo doesn't have.
I also think Neo is more generally accessible. It's got something in the way of a menu (still early stages), which helps. Neo is just generally less fiddly with editing cells, IMO. The mouse works, too.
Oleo does have an interface using Motif. Very early-90s. There's even an interface to GTk, although I don't think that works properly. I decided to abandon all that and just stick to an ncurses interface. After all, if you want a fancy interface, there are proper options these days like LibreCalc, Caliigra and Gnumeric.
I'm also half-way to adding a little calendar extension, too.
> Oleo is a GNU spreadsheet going back absolutely donkey years.
Third line of README:
> As of this writing (February 1999)
Whoah, you weren't kidding!
And check this: version 1.2.2 is available on Aminet, for the Amiga. How's that for a blast from the past?
[1]: https://en.wikipedia.org/wiki/Lotus_1-2-3
[2]: https://en.wikipedia.org/wiki/As-Easy-As
What's old is new again.
the ratio of space / cpu / capabilities (beside the network part) is something that reaches deep in my brain
Out[_]) or a built in construct (like the$ABC123forms in spreadsheet formulas)). A notebook interface would also be good (I think) as a straight up terminal as well, as you (I) typically want to run commands in an order like in a notebookAt least, these are things I think I remember. It's not quite what you're imagining, but it was cool and along the same lines.
https://strlen.com/treesheets/
Does anyone remember this, I can’t find it now.
All the best,
0. https://github.com/andmarti1424/sc-im
1. https://www.syntax-k.de/projekte/teapot/
See also: lotus improv
Actually... on that note I realized have never tried lotus improv.
I found a copy of the win3.1 version here. https://archive.org/details/lotus-improv-2.0-for-windows-2.0...
But my plan is to go for the full nerd experiance and see if I can get the nextstep version to work. https://winworldpc.com/download/7c521434-e280-a0e2-82ac-11c3...
Which will require a NeXT machine emulator https://previous.nextcommunity.net/
Wish me luck.
I don’t know if they have Improv pre-installed, but it will let you mount disk images from your computer.
(Personally I find the easy way too easy, so I have NeXT^WOpenSTEP installed on bare metal on a 5x86 box. But that’s me)
> Teapot is pretty great, it's too bad there is close to zero room for real innovation in the spreadsheet domain.
One issue is that this is hard to do while still retaining backwards compatibility. Lotus Improv basically gave you no other choice, something that Excel The Next Version can't do. And I doubt that we're getting a third MS app, no Multiplan -> Excel -> NewSpreadsheetThingProbablyCalledCopilotAnyway.
I know a lot of people that don't even use Excel's tables, introduced almost 20 years ago. But instead they painstakingly recreate most of its built-in features. It's just an easy shortcut away, and has plenty of GUI support hidden in the ribbon morass, but it's not the default state…
Its rather neat.