DEV Community: Tobias weissmann

Fresh: The Terminal Editor that Opens 2GB Logs in ~600ms with <40MB RAM

Tobias weissmann — Wed, 11 Mar 2026 21:59:08 +0000

If you’ve ever cracked open a multi-gigabyte log only to watch your editor choke, this’ll feel like cheating.

Fresh is a new terminal-based editor written in Rust that behaves like a modern GUI editor — command palette, mouse support, LSP, multi-cursor — yet stays tiny and fast enough to open a 2GB ANSI-colored log in about 600ms while sipping ~36MB RAM (author’s benchmark). It’s open-source and solo-built.

Rust Production Cheatsheet: https://tobiweissmann.gumroad.com/l/pvaqvy

Why Fresh exists (and why it’s interesting)
Most terminal editors trade power for a steep learning curve or for plugin sprawl. Fresh aims for a different triangle: discoverable UX, modern extensibility, and zero-latency feel — inside the terminal.

Discoverable UX. Menus, a Command Palette (Ctrl+P), familiar keybindings, mouse & scrollbars. If you can use VS Code, you can use Fresh.
Batteries included. Built-in LSP client, multi-cursor, and syntax highlighting out of the box.
Extensible with TypeScript. Write plugins in TS; they run in a sandboxed Deno environment. Today there are examples like Git Log navigation and a Git Blame inspector.
Built for huge files. Fresh was engineered to lazy-load and display even multi-GB files quickly — including rendering ANSI colors properly so your log retains meaning.
The headline number: 2GB in ~600ms
In an early comparison on a 2GB ANSI-heavy log:

Fresh: ~600ms load, ~36MB RAM, ANSI colors shown
Neovim: ~6.5s, ~2GB RAM, ANSI as raw control codes
Emacs: ~10s, ~2GB RAM, ANSI as raw control codes
VS Code: ~20s, OOM-killed on a ~4.3GB-RAM machine
These are author-run, early benchmarks (configs and plugins can change results; e.g., specialized Emacs packages for large files may alter the picture). Still: Fresh’s lazy approach to big files is the point. Try reproducing locally (recipe below).

Quickstart (pick one)
macOS (Homebrew)

brew tap sinelaw/fresh
brew install fresh-editor
Debian/Ubuntu (.deb)

download from Releases

sudo dpkg -i fresh-editor_*.deb
Fedora/RHEL/openSUSE (.rpm)

download from Releases

sudo rpm -i fresh-editor-*.rpm
Arch (AUR)

yay -S fresh-editor
Rust users (crates.io)

cargo install fresh-editor
Just try it (Node)

npx @fresh-editor/fresh-editor
Releases & instructions are on the project’s README.

60-second tour
Ctrl+P: Command Palette for everything.
Mouse + Scrollbars: Select, resize splits, navigate — no modal gymnastics.
Multi-cursor: Hold your breath and edit 30 lines at once.
LSP: Go to definition, references, rename, code actions, diagnostics — works with the language servers you already use.
Extensibility that feels modern
Fresh’s plugin API uses TypeScript running in Deno. That means up-to-date tooling, a rich JS ecosystem, and a sandbox designed for stability. If you’ve ever wanted to script a terminal editor without learning a niche DSL, this is your on-ramp.

Ideas to build next:

“Triage Log” plugin: colorize severity, jump between error frames, extract request IDs.
“Git Time Machine”: blame + inline history slider.
“Code Navigation++”: cross-file symbol search powered by ripgrep + LSP.
Reproduce the big-file demo yourself
Create a synthetic 2GB log with ANSI colors, then time your editor:

# make a 2GB file with colored lines
python - <<'PY'
import os, sys
line = "\x1b[32mINFO\x1b[0m something happened id=1234\n"
target = 2 * 1024 * 1024 * 1024
written = 0
with open("huge.log","w") as f:
    while written < target:
        f.write(line)
        written += len(line)

try Fresh

/usr/bin/time -v fresh huge.log

try your usual editor for comparison

/usr/bin/time -v nvim huge.log
(Performance will vary by disk, cache warmth, and terminal.)

Where Fresh fits today
Log triage & prod incidents. Open gargantuan logs instantly with colors intact, jump via Command Palette, and keep memory overhead tiny.
SSH & containers. A capable editor that doesn’t need a windowing system; npx makes it trivial to try in throwaway environments.
Roadmap vibes (my take)
Fresh already ships with documentation (User Guide, Plugin Development, Architecture) and regular releases under GPL-2.0. It’s early, but momentum looks real.

The bottom line
Fresh treats the terminal like a first-class editing surface: discoverable UI, modern language smarts, real extensibility, and the kind of big-file performance you usually get from bespoke viewers — not editors. If your week involves tailing logs, wrangling monorepos over SSH, or just craving snappy tools, give it a try.

Optimal setup for massive-log workflows (practical recipe)
If your goal is “open, search, annotate, and keep following a huge changing log” with minimal RAM:

Install Fresh using your platform’s method (above).

Enable auto-revert/auto-reload in Fresh so the file view updates as logs append (feature is listed in the README).

Combine with ripgrep for jumps:

rg -n "ERROR|WARN" huge.log > hits.txt && fresh hits.txt huge.log
Use the Command Palette to hop between matches.

Add a tiny TS plugin that:

Highlights \b(ERROR|WARN|FATAL)\b
Adds a “Next Error (Alt+E)” command
Extracts fields like request_id= into a side panel
(Plugin scaffolding is documented under “Plugin Development”.)
Keep memory flat. Avoid piping stdin to editors that buffer; work on the file directly so Fresh can lazily map/scan it.

This combo gives you instant open, colored log semantics, jump-to-signal navigation, and low memory.

Quick adoption playbook (for you, the author)
Ship reproducible benchmarks. Add a repo script that creates the synthetic 2GB ANSI log and records /usr/bin/time -v for Fresh and a few editors (with configs disclosed). Publish a “Benchmarks” page and version it with each release.

One-minute demo video + GIFs. Show (1) 2GB open, (2) Command Palette, (3) multi-cursor, (4) LSP. Link from README & website.
Extension gallery. Curate 5–8 “killer” plugins (Log Triage, Blame, TODOs, Color Highlighter, Merge Conflicts) and a template repo for new plugins.
Package everywhere. You already have Homebrew, AUR, .deb, .rpm, crates, and npx — great coverage. Add Scoop/winget for Windows terminals and a static MUSL build for Alpine.

Keymap packs. Offer VS Code / Sublime / Emacs-like keymaps so switching is painless. (Your README already lists keymap support — double down.)
Try Fresh, file an issue, or star the repo to nudge development forward. The project site and README have everything you need to get started.

Note: I would like to express my sincere gratitude to Noam Lewis, the maintainer of the Fresh Git repository, for his valuable work.

GithubLink : https://sinelaw.github.io/fresh/

Rust Production Cheatsheet: https://tobiweissmann.gumroad.com/l/pvaqvy

A Rust To-Do List CLI App - Part 2: Storage, Stability, and "Please Don't Corrupt My Tasks"

Tobias weissmann — Wed, 11 Mar 2026 21:54:23 +0000

Part 1 was the fun part: clap a couple commands together, print some output, feel productive.

Part 2 is where your CLI stops being a demo and starts acting like a real tool you'd actually trust with your future self's sanity.

We're going to add:
a default storage file (plus a --file option)
load on startup, save on updates
a stable on-disk format (JSON or TOML) that won't randomly break later
actionable error handling (no more "something went wrong lol")
(optional) integration tests for the CLI surface (the kind that catch regressions before users do)

One important note before we start: the code snippets below are a reference implementation used for explanation (i.e., example code I'm walking through - not code I'm claiming I wrote). You can copy ideas, adapt patterns, or rewrite it to match your style.
Production Grade Rust CLI: https://tobiweissmann.gumroad.com/l/vxlefy

1) Storage defaults that "just work" (and don't surprise power users)
A CLI should be usable in 2 seconds:
todo add "Buy milk"
todo list
No setup. No config file ceremony. No "please pass --db every time".
At the same time, power users want control:
different file per project
sync folder location
ephemeral file for scripts
testing with temp files

That's where a --file option shines.
Clap setup (global --file)

use clap::{Parser, Subcommand};
use std::path::PathBuf;

#[derive(Parser, Debug)]
#[command(name = "todo", version, about = "A tiny Rust to-do CLI")]
struct Cli {
    /// Path to the storage file (overrides default)
    #[arg(long, global = true)]
    file: Option<PathBuf>,
    #[command(subcommand)]
    command: Commands,
}
#[derive(Subcommand, Debug)]
enum Commands {
    Add { text: String },
    List,
    Done { id: u64 },
    Rm { id: u64 },
    Clear,
}

Now every command can share the same --file without repeating it.
Choosing a default path
On Linux/macOS/Windows, users expect you to put app data in the platform-appropriate place.
Use dirs or directories crate.
Example default:
Linux: ~/.local/share/todo/tasks.json
macOS: ~/Library/Application Support/todo/tasks.json
Windows: %APPDATA%\todo\tasks.json

use std::path::PathBuf;

fn default_store_path() -> PathBuf {
    let proj_dirs = directories::ProjectDirs::from("com", "example", "todo")
        .expect("Could not determine data directory");
    proj_dirs.data_dir().join("tasks.json")
}

And then:
let store_path = cli.file.unwrap_or_else(default_store_path);
That's the whole UX win: zero-config default, override when needed.

2) Load on startup, save on updates (the "don't lose my stuff" contract)
A to-do app that forgets your tasks is not a to-do app. It's a motivational quote generator.
A clean mental model:
Startup: read file → parse tasks → keep in memory
Mutating commands: apply change → write file atomically
Read-only commands (list): no write

Data model + stable IDs
Keep it boring and stable:

use serde::{Deserialize, Serialize};

#[derive(Debug, Clone, Serialize, Deserialize)]
struct Task {
    id: u64,
    text: String,
    done: bool,
}
#[derive(Debug, Default, Serialize, Deserialize)]
struct TaskDb {
    next_id: u64,
    tasks: Vec<Task>,
}

Why next_id? Because "ID is index in a Vec" is how you create sadness.

3) Pick a format: JSON vs TOML (and keep it stable)
JSON is a great default for CLIs
Pros:
ubiquitous tooling
easy debugging
stable schema evolution
faster to parse than you think for small files

TOML looks nicer to humans, but JSON is the "least surprising" for programs and scripts.
My practical advice:
choose JSON unless your audience strongly prefers editing by hand
version your schema early (even if you don't need it yet)

Add a file format version (future-proofing)

#[derive(Debug, Serialize, Deserialize)]
struct StoredDb {
    version: u32,
    db: TaskDb,
}

Write version: 1 now. In 6 months, you'll thank yourself.

4) Atomic writes: the difference between "reliable" and "one crash = data loss"
If you write directly to tasks.json and the process dies mid-write (power loss, Ctrl+C, OS update, you name it), you can end up with a half-written file.
The classic fix:
write to tasks.json.tmp
flush
rename to tasks.json (atomic on most filesystems)

use std::{fs, io};
use std::path::Path;

fn atomic_write(path: &Path, bytes: &[u8]) -> io::Result<()> {
    if let Some(parent) = path.parent() {
        fs::create_dir_all(parent)?;
    }
    let tmp = path.with_extension("tmp");
    fs::write(&tmp, bytes)?;
    fs::rename(tmp, path)?;
    Ok(())
}

For extra safety, you can sync_all() file/dir handles-but for most personal CLI use cases, this is already a huge step up.

5) Tighten error handling so failures are actionable
"Error: failed" is not an error message. It's a shrug.
Actionable means:
what happened
where it happened (which file)
what to do next (permissions? corrupted file? wrong flag?)

Use thiserror for domain errors

use thiserror::Error;
use std::path::PathBuf;

#[derive(Debug, Error)]
enum TodoError {
    #[error("Could not read storage file: {path}\nReason: {source}")]
    ReadFailed { path: PathBuf, source: std::io::Error },
    #[error("Storage file is not valid JSON: {path}\nReason: {source}\nTip: fix the file or move it aside to start fresh.")]
    JsonInvalid { path: PathBuf, source: serde_json::Error },
    #[error("Could not write storage file: {path}\nReason: {source}\nTip: check permissions or choose a different path with --file.")]
    WriteFailed { path: PathBuf, source: std::io::Error },
}

Load function with good errors

use std::{fs, path::PathBuf};

fn load_db(path: PathBuf) -> Result<TaskDb, TodoError> {
    match fs::read_to_string(&path) {
        Ok(s) => {
            if s.trim().is_empty() {
                return Ok(TaskDb::default());
            }
            let stored: StoredDb = serde_json::from_str(&s)
                .map_err(|e| TodoError::JsonInvalid { path: path.clone(), source: e })?;
            Ok(stored.db)
        }
        Err(e) if e.kind() == std::io::ErrorKind::NotFound => Ok(TaskDb::default()),
        Err(e) => Err(TodoError::ReadFailed { path, source: e }),
    }
}

That NotFound → empty DB behavior is crucial: first run should feel effortless.
Save function

fn save_db(path: PathBuf, db: &TaskDb) -> Result<(), TodoError> {
    let stored = StoredDb { version: 1, db: db.clone() };
    let bytes = serde_json::to_vec_pretty(&stored)
        .expect("Serialization should not fail for valid types");
         atomic_write(&path, &bytes)
        .map_err(|e| TodoError::WriteFailed { path, source: e })
}

Now when something breaks, the user gets a message they can actually act on.

6) Wire it into commands: mutate → save
The flow in main() becomes simple and predictable:

fn main() -> Result<(), TodoError> {
    let cli = Cli::parse();
    let path = cli.file.unwrap_or_else(default_store_path);
    let mut db = load_db(path.clone())?;
    match cli.command {
        Commands::Add { text } => {
            let id = db.next_id + 1;
            db.next_id = id;
            db.tasks.push(Task { id, text, done: false });
            save_db(path, &db)?;
            println!("Added task #{id}");
        }
        Commands::List => {
            for t in &db.tasks {
                let mark = if t.done { "✅" } else { "⬜" };
                println!("{mark} {}: {}", t.id, t.text);
            }
        }
        Commands::Done { id } => {
            if let Some(t) = db.tasks.iter_mut().find(|t| t.id == id) {
                t.done = true;
                save_db(path, &db)?;
                println!("Marked #{id} as done");
            } else {
                eprintln!("No task with id {id}");
            }
        }
        Commands::Rm { id } => {
            let before = db.tasks.len();
            db.tasks.retain(|t| t.id != id);
            if db.tasks.len() != before {
                save_db(path, &db)?;
                println!("Removed #{id}");
            } else {
                eprintln!("No task with id {id}");
            }
        }
        Commands::Clear => {
            db.tasks.clear();
            save_db(path, &db)?;
            println!("Cleared all tasks");
        }
    }
    Ok(())
}

This is the "adult" CLI pattern:
state in memory
deterministic saves
minimal surprises

7) Optional: CLI integration tests (the easiest tests that catch the most bugs)
Unit tests won't catch:
clap parsing changes
output formatting regressions
"it works locally but fails when executed like a real binary"

Integration tests will.
Use:
assert_cmd to run the binary
tempfile to isolate storage
predicates to check output

Cargo.toml (dev-deps)
[dev-dependencies]
assert_cmd = "2"
predicates = "3"
tempfile = "3"
Example test: add + list
use assert_cmd::Command;
use predicates::str::contains;

use tempfile::tempdir;

#[test]
fn add_then_list_shows_task() {
    let dir = tempdir().unwrap();
    let file = dir.path().join("tasks.json");
    Command::cargo_bin("todo").unwrap()
        .args(["--file", file.to_str().unwrap(), "add", "hello"])
        .assert()
        .success();
    Command::cargo_bin("todo").unwrap()
        .args(["--file", file.to_str().unwrap(), "list"])
        .assert()
        .success()
        .stdout(contains("hello"));
}

This test doesn't care how you implement storage internally - only that the CLI behaves correctly. That's what you want.

The real takeaway: you're building trust, not features
Part 2 isn't about fancy commands.
It's about trust.
default file location that behaves like a real app
stable storage format that doesn't self-destruct
error messages that tell users what to do next
tests that prevent accidental breakage

Once those foundations are in place, Part 3 can be the fun stuff again:
priorities, due dates, tags, search, interactive TUI… whatever you want.
But without Part 2? Every new feature is built on sand.
Production Grade Rust CLI: https://tobiweissmann.gumroad.com/l/vxlefy

A Rust To-Do List CLI App (Part 1): Clap, TDD, and a HashMap That Behaves

Tobias weissmann — Wed, 11 Mar 2026 21:49:05 +0000

I like small tools that disappear into your workflow.

Not “disappear” as in crash silently — disappear as in you stop noticing they exist because they just work. A tiny CLI you can run 30 times a day without thinking. Fast. Predictable. Boring in the best way.

So for my first “real” Rust project, I followed a classic learning move: rebuild something simple, but treat it like it’s going to ship.

This post is a guided walkthrough inspired by (and crediting) Claudio Restifo’s to-do CLI tutorial. I’m using his approach as a reference point while adding my own beginner-friendly notes and a more TDD-ish mindset. Any code snippets shown below are either directly from, or adapted from, that tutorial and the Rust Book examples — this is not presented as original code. (Mistakes in the explanations, if any, are mine.)

Production Grade Rust CLI: https://tobiweissmann.gumroad.com/l/vxlefy

What we’re building (and why it’s worth it)
A tiny CLI called todo that can:

Manage a list of entries: each item is either to-do or done
Provide commands to:
list
add "Buy milk"
delete "Buy milk" (we’ll wire this in later)
mark-done "Buy milk"
mark-todo "Buy milk" (later)
Persist data to a file (not in Part 1)
The interaction should feel like:

$ todo list

TO DO

Write post
Buy milk # DONE
Feed the cat $ todo add "Update CV" $ todo mark-done "Buy milk" $ todo list # TO DO
Write post
Update CV # DONE
Feed the cat
Buy milk This is intentionally “small.” The goal is not to build a universe. The goal is to learn Rust fundamentals the way you learn a language for real: by trying to build something end-to-end.

Step 0: Cargo gives you a project skeleton in 10 seconds
cargo new todo-cli
cd todo-cli
Cargo will create:

Cargo.toml (metadata + dependencies)
src/main.rs (entry point)
The default main.rs is the usual:

fn main() {
    println!("Hello, world!");
}

Run it:

cargo run
Build it:

cargo build
Test it:

cargo test
Cargo isn’t just a build tool — it’s the workflow. If you learn nothing else early, learn how Cargo wants you to live.

Step 1: CLI parsing the “naive” way (and why we won’t stay there)
The classic Unix pattern is reading args directly:


let action = std::env::args().nth(1).expect("Please specify an action");
let item   = std::env::args().nth(2).expect("Please specify an item");

This works, but it scales badly. You’ll quickly end up reinventing:

validation
help text
optional flags
subcommands
defaults
Rust will happily let you write this… and then politely let you regret it.

Step 2: Let Clap do the hard work
Clap is the standard go-to for Rust CLIs.

Install it:

cargo add clap --features derive
Minimal parsing with derive (adapted from common Clap patterns):

use clap::Parser;

#[derive(Parser)]
struct Cli {
    command: String,
    key: Option<String>,
}

fn main() {
    let args = Cli::parse();
    println!("Command: {:?}", args.command);
    println!("Key: {:?}", args.key);
}

Why derive matters
Rust’s #[derive(...)] is everywhere because it compresses a lot of boilerplate into readable intent. You don’t need to master procedural macros on day one—just get comfortable using them.

Step 3: The data model — a deliberately simple TodoList
Claudio’s tutorial uses a HashMap, which is a clean beginner-friendly choice:

key = item text (String)
value = status (bool)
true → to-do
false → done
Yes, a bool is slightly “too clever” (an enum would be clearer). But as a learning tool, it’s perfect: you get storage + state with minimal ceremony.

Start with a test (tiny TDD)
Rust lets you put unit tests in the same file:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn init_todo() {
        let _todo = TodoList::new();
    }
}

Now your compiler forces you to create the type.

A minimal implementation (structure and approach are aligned with the referenced tutorial, but condensed):

use std::collections::HashMap;

struct TodoList {
    items: HashMap<String, bool>,
}
impl TodoList {
    fn new() -> TodoList {
        TodoList { items: HashMap::new() }
    }
}

This is the first “Rust truth” you’ll internalize:

Rust rewards you for building tiny, correct pieces that compile.

Step 4: Add items (and learn what &mut self really means)
Test first:

#[test]
fn add_item() {
    let mut todo = TodoList::new();
    todo.add("Something to do".to_string());
    assert_eq!(todo.items.get("Something to do"), Some(&true));
}
Implementation:

impl TodoList {
    fn add(&mut self, key: String) {
        self.items.insert(key, true);
    }
}

The important bit: &mut self
Read it like this (it helps):

&mut self = “borrow the struct mutably so I can change its internals”
The reference isn’t “mutating.” The data behind it is.

This is where Rust starts training your brain to be explicit about changes — and once you get used to it, it’s incredibly calming.

Step 5: Don’t overwrite existing items (entry API = superpower)
You may want: “adding the same item twice shouldn’t reset its status.”

Test (conceptually):

add item
manually mark it done
add again
status should remain done
To achieve this, HashMap::entry is your friend. It lets you express the idea:

“Only insert if the key doesn’t exist.”

In Rust, that often looks like:

check if entry is vacant
insert only then
This pattern matters beyond CLIs — this is the same mental model you’ll use in caches, deduping, idempotency, and more.

Step 6: Mark items as done / to-do (Option → Result, the Rust way)
We want:

mark(key, value) updates the item if it exists
if it doesn’t exist, return an error
Test idea:

#[test]
fn mark_item_does_not_exist() {
    let mut todo = TodoList::new();
assert!(todo.mark("Missing".to_string(), false).is_err());
}

Implementation idea:

use get_mut → returns Option<&mut bool>
convert Option → Result
use ? to propagate errors cleanly
This is the part where Rust starts feeling professional.

Why ? feels like cheating (in a good way)
Instead of writing nested match blocks forever, you let errors bubble up naturally—but still explicitly. It’s one of the most productivity-friendly language features Rust has.

Step 7: List items without mixing logic and printing
A surprisingly “real world” rule:

If you mix business logic and printing, your CLI becomes hard to test and hard to evolve.

So we want a list() method that returns two groups:

items where status is true (to-do)
items where status is false (done)
A clean approach is to return iterators filtered by status. (This is the kind of thing Rust does extremely well: lazily, without allocating extra memory unless you ask for it.)

Then the CLI layer decides how to print them.

Step 8: Wire methods into CLI commands (with match)
We parse the command and run the correct operation:

add needs a key
mark-done needs a key
list doesn’t
In Rust, match is the natural control flow tool here.

A key nuance: each branch should resolve to a uniform result type (often Result<(), String>), so the program can print a success/error outcome consistently.

This is where you’ll naturally practice:

Option handling (Some/None)
converting Option to Result
formatting error messages
keeping side effects (printing) near the edge
What you’ve quietly learned in Part 1
Even without persistence, this “tiny” app already touched the core Rust muscles:

Cargo as your workflow
Clap for real CLI parsing
struct + impl as your “object model”
HashMap + entry API for safe updates
Ownership and &mut self without tears
Option, Result, and ? as your error language
Iterators as a performance-friendly default
match as a clean command router
This is why small projects matter: they force you to connect the dots.

What’s next (Part 2)
Right now the CLI “forgets” everything when it exits.

In Part 2, we’ll add persistence the right way:

default storage file (and a --file option)
load on startup, save on updates
pick a format (JSON/TOML) and keep it stable
tighten error handling so failures are actionable
(optional) add integration tests for the CLI surface
Credits (important)
This walkthrough is inspired by and based on Claudio Restifo’s Rust to-do list CLI tutorial. The structure and several implementation ideas (CLI flow + HashMap-based state management) follow that reference, and the Rust concepts are cross-checked against the Rust Book. This post is intended as an educational “learning notes” version, not as an originality claim.

Production Grade Rust CLI: https://tobiweissmann.gumroad.com/l/vxlefy