tui-journal puts a note taking app inside the terminal

A journal that never leaves the terminal

TUI-Journal is a terminal-based application written in Rust that allows you to write and manage your journal or notes from within the comfort of your terminal. The description in the README is direct: it provides a simple and efficient interface for creating and organizing your thoughts, ideas and reflections.

The implementation is a ratatui interface over crossterm, with a tui-textarea widget for the built-in editor and the arboard crate for clipboard access, including the wayland data control feature. The binary is called tjournal, and the library target is a separate crate named backend, with its own integration test at backend/tests/backend.rs.

The project is published on crates.io as tui-journal, with documentation on docs.rs, and the Cargo metadata gives it version 0.18.0, edition 2024 and a declared rust-version of 1.92.0. The licence is MIT, and the author is Ammar Abou Zor.

The audience is specific but not narrow: people who already live in a terminal, who keep notes in text files, and who want search, tags and bulk operations without opening a windowed editor. The README's own summary of the product is your journal app if you live in a terminal.

Three back-ends, and they are compile-time choices

TUI-Journal supports three local back-ends: plain-text JSON, SQLite, and an iCalendar VJOURNAL directory. The roadmap records all three as done, along with editing content with an external text editor from within the app, filter and search functionality, and custom themes.

The choice is made at build time rather than at run time, and the Cargo feature flags show it. The default feature set is json, sqlite and vjournal, and each one gates a dependency: sqlite pulls in sqlx with the runtime-tokio, sqlite and chrono features, and vjournal pulls in vobject and uuid. The JSON back-end needs no extra dependency, which is why the feature list is empty for it.

That has a practical consequence for installation. The README documents an install with only the JSON back-end:

cargo install tui-journal --locked --no-default-features --features json

so a user who wants a single plain-text file and nothing else can avoid compiling the database and iCalendar stacks at all.

The VJOURNAL back-end is the interesting one, and the roadmap explains its purpose: it is a VJOURNAL directory back-end for use with external CalDAV sync clients. The entries are written as iCalendar journal entries on disk, and a separate CalDAV client is what moves them between machines. The application does not sync anything itself; it produces a format another tool can sync.

The repository enforces the feature matrix in CI through the justfile, whose check target compiles the default set and then each single back-end on its own, so a back-end that stops building alone is caught before it ships.

An editor you can leave and come back to

The editing model is the part of the feature list that distinguishes this from a plain notepad in a terminal.

You can edit journal content with the built-in editor or use your favourite terminal text editor from within the app. That second option matters more than it sounds: for a long entry, or an entry you want to run through your own tooling, leaving the application for an external editor and coming back is often faster than fighting a modal editor.

The keybindings are a hybrid, and the README is upfront about it. They are a combination of VIM and Emacs motions, with VIM for navigation and Emacs for editing texts in edit mode, and the app also uses the Editor's Visual Mode for VIM-style text selection, copying and deletion. The dependency list backs that up: tui-textarea 0.7 provides the text widget, and the arboard crate handles the clipboard with the wayland data control feature enabled.

Clipboard work is bidirectional in two senses. You can transfer text between the built-in editor and the system clipboard using Cut, Copy and Paste, and you can optionally sync the clipboard between the built-in editor and the operating system, with vim and emacs keybindings.

Around that sit the conveniences that make a notes app usable day to day. Create, edit and delete entries, add custom colored tags and use them in the built-in filter, fuzzy find the entry you want with a smart-case search, search titles and content, sort by date, priority or title, control many entries at once with a multi-select mode, undo and redo changes, cycle through tags in the main view with a single command, and keep your sorting and full-screen preferences in the app state. There is also a keybindings reference available from inside the app.

Installing on six package managers plus cargo

The installation section is unusually thorough, and it covers the platforms that a Rust terminal application realistically lands on.

The package managers are Arch Linux with pacman, Alpine Linux with apk, FreeBSD with pkg, NetBSD with pkgin, Nix, and Homebrew for macOS and Linux:

pacman -S tui-journal

apk add tui-journal

pkg install -y tui-journal

pkgin install tui-journal

brew install AmmarAbouZor/homebrew-tui-journal/tui-journal

For Nix there are two forms, one for NixOS and one for a non-NixOS system:

# On NixOS:
nix-env -iA nixos.tui-journal

# On Non NixOS:
nix-env -iA nixpkgs.tui-journal

Alpine is the one with a caveat: the package is available for Alpine Edge and is installed with apk after enabling the testing repository.

For everyone else, there are pre-built binaries on the Releases page and the cargo routes. The default install, with the JSON, SQLite and VJOURNAL back-ends, is:

cargo install tui-journal --locked

and the nightly build is installed straight from the repository:

cargo install --git https://github.com/AmmarAbouZor/tui-journal

The justfile carries the same idea for local development, with an install target that forwards extra arguments to cargo install, and the comment gives the example of installing with only the sqlite back-end.

Roadmap items that tell you what is missing

The roadmap is small, and the three open items are more informative than a feature list.

The first is a preview mode for journals supporting Markdown highlighting and word wrapping. The second is mouse support. The third is an improvement to the app input and rendering cycle using app events, to support real concurrency within the app.

Each of those is a real limit on how the application can be used. Without the preview mode, a long entry is read as raw text in the editor rather than as formatted Markdown, which matters if you write in Markdown. Without mouse support, the application is keyboard only, which is a deliberate choice for a terminal app but does rule out pointing at an entry. And the third item describes the current architecture accurately enough to be useful: the application runs its input and rendering cycle in a way that does not yet support real concurrency inside the app, which is the sort of detail that decides whether a tool feels responsive during a long operation.

The repository layout is consistent with a small, well-organised project. There is a src directory for the application, a separate backend directory for the storage layer and its tests, an assets directory with the demo recordings including the fuzzy finder animation, a THEMES.md for the theming support that the roadmap marks as done, a CITATION.cff, a CHANGELOG.md, a justfile for the development commands, an AGENTS.md, and an .ai directory. The README asks contributors to read the Contribution and AI Policy section before opening a pull request, which is worth doing given that the project explicitly asks for it.

The release record is steady: v0.16.1 on 2025-07-28, v0.17.0 on 2026-07-10 and v0.18.0 on 2026-09-06, with the last push on 2026-10-16.

Where tui-journal is the wrong tool

The boundaries are clear and they come from the terminal-first design.

First, there is no sync. The VJOURNAL back-end writes files that an external CalDAV client can sync, which is a deliberate separation of concerns, but it means the application alone will not move your journal between a laptop and a phone. If you need your notes on several devices, you are either bringing your own CalDAV client or choosing a tool that syncs for you.

Second, it is keyboard only for now, and it renders in a loop that the roadmap describes as not yet supporting real concurrency inside the app. Both are on the open list, so a team that expects a mouse-driven note tool or expects the app to stay responsive during a long operation will be disappointed today.

Third, there is no Markdown rendering in the entry view, which for someone who writes notes in Markdown means the preview you get in your editor is not what you get in the app.

Fourth, the platform floor is recent. The declared rust-version is 1.92.0 with edition 2024, so building from source needs a current toolchain, and the crate depends on a fairly large set of crates including tokio with the full feature set, sqlx, ratatui and git2. The binary is a single file, but the dependency tree behind it is not small.

The counterpoint is that for the intended user, none of that matters much. The entries are plain files you can read with any tool, the back-end choice is explicit, and the app does the few things a note taker needs to do well.

Editorial conclusion

Terminal users who keep notes in files and want search, tags and multi-select without leaving the keyboard should try tui-journal, because it keeps the entries in plain local storage and adds the editing conveniences a note tool needs. It is the wrong choice if you need sync between devices, since the VJOURNAL back-end is a directory that an external CalDAV client handles rather than a sync client of its own, and it is the wrong choice if you need mouse support or Markdown preview, both of which are still unchecked items on the roadmap. Before adopting, pick the back-end that matches your setup, note that the build requires Rust 1.92 with edition 2024, and read the keybinding documentation, because the hybrid VIM and Emacs scheme takes a day to get used to.

Frequently asked questions

Official sources

1. AmmarAbouZor/tui-journal on GitHub
2. License: MIT
3. Project website
4. README
5. Releases