Sheets: Terminal based spreadsheet tool(github.com) |
Sheets: Terminal based spreadsheet tool(github.com) |
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.
package require oleo
load-oleo mysheet.oleo
set ws [toMat]
set subset [subRows $ws [mand [mstreq 2 foo] [mstreq 3 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 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.
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
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.
Does anyone remember this, I can’t find it now.
All the best,
Its rather neat.
I have a spreadsheet with 186 rows and want to select a specific cell's value from rows 6 and 127 and immediately know the sum if it happens to be 2 digits. Most of the time it's from the same column but not always.
With a GUI, this is really easy. CTRL + left click each cell and get the answer in a second. Throw SHIFT into the mix if you want a range of cells.
Obviously this is just a proof of concept, but these tools need to be packaged into deb/rpm/winget compatible forms, with signatures, not random executables from a GitHub page. At least it isn't asking me to curl | sudo bash.
Two-Way synchronizing of a text file version of Google sheets is another way to think of it. Aside from that, there would also be the need to implement the spreadsheets user interface of highlighting and all that stuff, in the TUI side.
Sc-im: Spreadsheets in your terminal - https://news.ycombinator.com/item?id=47662658 - April 2026 (25 comments)
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)
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…
I'm also half-way to adding a little calendar extension, too.