Rust

tl;dr Notes: 0.2.0 at github.com/syndbg/onetui/releases. Link back to the 0.1.0 post. What’s new, at a glance Notes: Every data source can now write, from the same query editor: PostgreSQL, Kafka, NATS, DynamoDB, RabbitMQ, Qdrant. New data source: ScyllaDB and Cassandra, through one cql connection kind. Syntax highlighting in the editor, per data source language. Multi-line editor (Shift+Enter), query history (Ctrl-P / Ctrl-N, Shift+H), optional persistent history. Confirmation before a query runs, on by default (ask_for_query_confirm). Connection errors in a popup. Inline username= / password= credentials in connection config (#41). The 0.1.0 post named four sources. 0.1.0 already shipped DynamoDB and RabbitMQ as read-only too. 0.2.0 makes seven. PostgreSQL: SQL with highlighting and a confirmation step ...

tl;dr Code is at github.com/syndbg/onetui. If the idea of one consistent TUI across your databases and queues sounds useful to you too, I’d like to hear about it. Over the years I’ve used DBeaver, DataGrip, psql, and whatever Kafka CLI happened to be the flavor of the month. Each one does its job, more or less. None of them feel like the same tool. Keybinds differ. Panels differ. Some support the data source I need that day, some don’t. Some barely work. ...

I’ve used z for over a decade. Not zoxide, not jump, not fasd, the original rupa/z, a few hundred lines of POSIX shell that tracks the directories you cd into and lets you jump back with a fuzzy pattern instead of a full path. At some point I tried the newer alternatives. Each one changed something I didn’t ask it to change: a different ranking algorithm, a different database format, a new set of flags to relearn. None of them were bad tools. They just weren’t z. I wanted the exact behavior I already had muscle memory for, just without a shell interpreter parsing a database file on every invocation. ...