DEV Community: Cason Adams

When a Master Harnesses the Reins of a Wild Beast: Software Engineering in the Age of AI

Cason Adams — Wed, 30 Sep 2026 17:10:33 +0000

There is an old adage (coined today by me): When a master harnesses the reins of a wild beast, the world changes.

In software engineering, we have watched two extreme reactions to generative AI over the past few years:

The Novice’s Surrender: Engineers who drop the reins entirely, treat the LLM as an oracle, accept plausible-looking slop, and spend the next three days debugging hallucinated edge cases.
The Cynic’s Disdain: Senior engineers who watched a model invent a non-existent standard library flag once, declared it an erratic autocomplete toy, and refused to touch it again.

Both miss reality.

An LLM is neither a junior engineer nor an autonomous architect. It is a high-variance, probabilistic beast of pure brute-force synthesis. If you let it
wander unsupervised, it runs off a cliff. But when a software engineer with years of architectural discipline, taste, and pattern recognition grabs the
reins, the leverage is unprecedented.

The Anatomy of the Beast

To control a system, you have to model its failure modes accurately.

LLMs fail predictable ways:

Path of Least Resistance: They favor common patterns over optimal ones. If 80% of GitHub code does naive error handling, the model will output naive error handling unless constrained.
Context Blindness: They optimize locally across their context window. They do not intrinsically care about your repo’s 5-year maintenance horizon, your memory allocation budget, or your team's domain boundaries.
Confidence in Hallucination: They don't have an "I don't know" state unless explicitly penalized for guessing.

A novice encounters these behaviors and blames the tool or falls into cargo-cult prompt engineering.

A master treats these as predictable runtime characteristics—like garbage collection pauses, network jitter, or race conditions—and designs constraints
to eliminate them.

The Reins: How a Master Takes Control

Masters don’t write prompts; they write specifications. They don't use AI to think; they use AI to accelerate execution.

1. Invert the Grounding (Feed Invariants, Not Questions)

Novices ask open-ended questions: "How do I implement a rate limiter in Go?"
The beast returns a generic token-bucket example copied from a 2018 blog post.

A master provides strict boundaries before asking for an implementation:

The exact state machine.
Concurrency guarantees (e.g., lock-free atomics vs. mutex).
Memory budget and external dependencies (zero allocs in hot path, standard library only).
Interface signatures and failure modes.

When the input space is constrained, the probabilistic output collapses into deterministic correctness.

2. Deterministic Verification as the Bit and Bridle

Never inspect LLM output solely with your eyes. Human review fatigue is real, and LLMs write code that looks syntactically pristine while violating
subtle domain logic.

A master establishes a closed feedback loop:

Types and Compilers First: If the code doesn't typecheck against existing ASTs and strict compiler flags, reject it immediately.
Property & Regression Tests: Write the test harness or interface invariant first. Let the beast generate implementations against the failing suite until green.
The Harness Disposes: The model proposes candidates; your test suite and static analyzers make the decision.

3. Slice Before Synthesizing

Never ask a model to write an entire service or refactor a whole module at once. The error rate compounds exponentially with scope.

Decompose work into isolated vertical slices:

Pure domain transforms (zero I/O, deterministic inputs/outputs).
Wire/Adapter mappings (deserialization, schema migrations).
Integration wiring (thin orchestrators).

By keeping each operational slice small, you retain 100% architectural control while offloading 90% of the mechanical typing.

Magnification: The Asymmetric Advantage

When a craftsman commands the beast, three shifts happen:

1. Zero Cognitive Fatigue on Mechanical Work

Writing table-driven tests for 30 edge cases, generating boilerplate protocol buffers, writing SQL migration scripts, or plumbing repetitive HTTP route
mappings usually drains mental reserves.

A master offloads the mechanical heavy lifting in seconds, preserving prime mental clarity for core architecture, data layout, distributed consensus, and
boundary enforcement.

2. Parallel Hypothesis Testing

In traditional workflows, prototyping three competing data structures or algorithms for a critical path takes two days. You pick one early based on
intuition and stick with it.

With high-horsepower synthesis under strict test contracts, you can scaffold and benchmark all three implementations in twenty minutes. You stop guessing
and start measuring.

3. Eradicating the "Blank Page" Penalty

The slowest part of software design is often overcoming inertia when structuring new subsystems. A master can force an LLM to generate three radically
different architectural proposals (e.g., event-driven vs. actor-based vs. synchronous worker pools), rip them apart, discard the hallucinations, take the
best structural insight, and execute the clean version.

The Final Distinction

The fear that AI replaces senior engineers is founded on an illusion: that programming is typing code into a text buffer.

Programming has never been typing. Programming is:

Knowing what problem actually needs solving.
Preserving invariants across five years of evolving requirements.
Deciding which trade-offs to reject.
Knowing when not to add an abstraction.

A novice gives the beast the reins and gets dragged into a ditch.
A master takes the reins and covers ten leagues in an hour.

The world doesn't change because the beast exists. The world changes when the master decides to ride.

I Built a Pure-Zsh Prompt Engine That Renders in 0.6ms (Without Rust or C++)

Cason Adams — Wed, 30 Sep 2026 02:09:51 +0000

For years, developers optimizing their shell prompts have faced a binary dilemma:

Starship: Beautiful, portable, and feature-packed, but written in Rust. Every single prompt render forks an external process (starship prompt). On macOS security layers or large monorepos, process invocation latency adds up.
Powerlevel10k: Blazing fast, but relies on a compiled C++ companion binary (gitstatusd) and requires a generated configuration file (~/.p10k.zsh) that often exceeds 1,600 lines of uppercase global variables (POWERLEVEL9K_*).

I wanted something different:

100% Pure Zsh: Zero compiled binaries, zero C++ daemons, zero external dependencies. Runs on any platform with Zsh 5.8+ (macOS, Linux, BSDs, Alpine/musl, Termux).
Sub-millisecond synchronous rendering: Renders in under 0.7 ms.
Zero subshell forks on the hot path: No $(...), no backticks, no piping through sed/awk.
Clean declarative configuration: Concise Zsh arrays instead of hundreds of global environment variables.

That project is zline. Here is how it works under the hood.

1. The Core Performance Invariant: Zero Subshell Forks

In shell scripting, subshells are expensive:

# This forks a new process:
current_branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)

# This forks another process:
formatted=$(echo "$current_branch" | tr '[:lower:]' '[:upper:]')

If your prompt executes 4 to 8 subshells every time you press Enter, prompt rendering latency quickly jumps to 15-50 ms. On systems with endpoint security scanners (e.g., macOS Endpoint Security or Windows Defender on WSL), process execution overhead can be even higher.

In zline, the synchronous render path has a strict rule enforced by automated CI audits: 0 subshells allowed.

Everything on the critical render path relies strictly on native Zsh builtins and parameter expansion:

Instead of sed or tr: Native parameter substring replacement ${var//search/replace}.
Instead of basename or dirname: Path modifiers ${var:t} and ${var:h}.
Instead of wc -l: Array length expansions ${#array} and math evaluation $(( ... )).
Instead of cut: Splitting expansion ${(s/:/)var}.
Instead of join: Joining expansion ${(j: :)items}.

2. Two-Phase Git Status Detection

Git repositories are the primary bottleneck for shell prompts. Running git status synchronously in a 500k-file repository can freeze your prompt for seconds.

zline uses a two-phase architecture:

Phase 1: Direct File System Read (0.07 ms)

Before touching the git binary, zline checks .git/HEAD directly using pure Zsh file descriptors:

_zline_git_read_head() {
  emulate -L zsh
  local dir="$1"
  local git_path="${dir}/.git"

  # Handle .git worktrees / submodules
  if [[ -f "$git_path" ]]; then
    local line
    read -r line < "$git_path" 2>/dev/null
    if [[ "$line" == "gitdir: "* ]]; then
      local gd="${line#gitdir: }"
      [[ "$gd" != /* ]] && gd="${dir}/${gd}"
      git_path="$gd"
    fi
  fi

  local head_file="${git_path}/HEAD"
  [[ -r "$head_file" ]] || return 1

  local head
  read -r head < "$head_file" 2>/dev/null
  if [[ "$head" == "ref: refs/heads/"* ]]; then
    REPLY="${head#ref: refs/heads/}"
  elif [[ -n "$head" ]]; then
    REPLY="${head[1,7]}" # Detached commit SHA
  fi

  # Check merge / rebase / cherry-pick states
  if [[ -f "${git_path}/MERGE_HEAD" ]]; then
    REPLY="${REPLY}|MERGING"
  elif [[ -d "${git_path}/rebase-merge" ]]; then
    REPLY="${REPLY}|REBASE"
  fi
}

Reading and parsing .git/HEAD in pure Zsh executes in 0.072 ms. Your branch name, detached state, and rebase/merge status appear instantly on every keystroke.

Phase 2: Asynchronous Non-Blocking Worker via `zle -F`

To calculate dirty status, untracked counts, and ahead/behind commits without freezing the terminal, zline starts a persistent background worker:

Communication happens over named pipes (FIFOs) using POSIX mkfifo.
The background worker queries git status --porcelain=v2 --branch off the UI thread.
When results arrive, Zsh receives an event via its native file descriptor event listener:

zle -F "$_zline_worker_res_fd" _zline_worker_zle_handler

When the worker finishes, Zsh immediately triggers the handler, updates the internal Git cache, and calls zle reset-prompt. No CPU polling, no timer loops, and zero prompt lag.

3. Compile Once, Render in Microseconds

Shell prompts typically parse user options on every render loop. If your configuration allows flags like --shorten 1 --anchor git, re-parsing those strings on every precmd burns CPU cycles.

zline separates compilation from rendering:

[~/.zshrc Evaluated]
        │
        ▼
   zline init
        │
        ├── Tokenize & Parse Flags Once
        ├── Build Static Argument Arrays
        └── Compile Zsh Wordcode (.zwc)
        │
[Interactive Shell Active]
        │
        ▼
  Every Enter Key ──▶ Direct Function Calls via Pre-compiled Arrays (< 0.7 ms)

At shell startup (zline init), segment definitions are tokenized into indexed function references:

typeset -ga _zline_compiled_left_names=('dir' 'git' 'newline' 'prompt_char')
typeset -ga _zline_compiled_left_args=('shorten=1 anchor=git' 'clean=2 dirty=3' '' '')

During active typing, the render engine simply loops through pre-indexed arrays and invokes segment functions without calling zparseopts or evaluating regular expressions.

Additionally, zline compile compiles all engine source files into Zsh Wordcode (.zwc) via zcompile -R, skipping text-parsing overhead on subsequent terminal launches.

4. Replacing 1,600 Lines of Config with Declarative Arrays

Powerlevel10k configurations often require a massive ~/.p10k.zsh full of global environment variables:

# Powerlevel10k approach:
typeset -g POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(dir vcs newline prompt_char)
typeset -g POWERLEVEL9K_SHORTEN_DIR_LENGTH=1
typeset -g POWERLEVEL9K_DIR_ANCHOR_FILES=(.git)
typeset -g POWERLEVEL9K_VCS_CLEAN_FOREGROUND=2
typeset -g POWERLEVEL9K_VCS_MODIFIED_FOREGROUND=3
typeset -g POWERLEVEL9K_STATUS_OK=false
typeset -g POWERLEVEL9K_COMMAND_EXECUTION_TIME_THRESHOLD=2
# ... hundreds more lines ...

In zline, configuration is declared via readable arrays directly in your ~/.zshrc:

# zline approach:
zline preset powerline --transient

zline_left=(
  'dir --shorten 1 --anchor git'
  'git --clean 2 --dirty 3'
  newline
  prompt_char
)

zline_right=(
  'status --hide-zero'
  'exec_time --min 2'
)

zline init

5. Base16 First: Harmonious by Default

Hardcoded hex colors (#ff5555, #8be9fd) look great until you change your terminal theme from Dracula to Tokyo Night, leaving your prompt colors mismatched.

zline standardizes on the Base16 / Term16 ANSI color space (colors 0 through 15). Each segment references standard semantic terminal color slots:

2: Success / Clean VCS (Terminal Green)
3: Warning / Dirty VCS (Terminal Yellow)
1: Error / Failure (Terminal Red)
4: Primary / Directory (Terminal Blue)
8: Connecting lines / Frames (Bright Black / Muted Gray)

Whether you switch your terminal emulator between Catppuccin, Nord, Gruvbox, or Solarized, zline adapts automatically with zero configuration edits.

6. Real-World Benchmarks

Measured on an Apple Silicon arm64 machine running Zsh 5.9 over 1,000 iterations:

Benchmark Operation	`zline` Latency	Target SLA	Status
Sync Prompt Render (Powerline)	0.66 ms	< 1.50 ms	PASS
Sync Prompt Render (Lean)	0.52 ms	< 1.00 ms	PASS
Directory Shortening & Anchor	0.10 ms	< 0.15 ms	PASS
Synchronous Git HEAD Reader	0.072 ms	< 0.15 ms	PASS
Instant Prompt Load	0.057 ms	< 0.50 ms	PASS

Compared to typical external prompts spawning processes on every return key (15-30 ms), zline stays well below the 1-millisecond mark.

7. Modern Terminal Integration (OSC Protocols)

Beyond basic prompt drawing, zline includes native support for modern terminal emulator escape sequences:

OSC 133 (Semantic Shell Integration): Emits A, B, C, and D escape markers so terminals like Kitty, iTerm2, WezTerm, and Ghostty know exactly where commands begin, end, and output.
OSC 7 (Working Directory Reporting): Guarantees new terminal tabs open in the current directory.
OSC 8 (Hyperlinks): Turns file paths into clickable links.
Transient Prompt: Collapses historical multi-line prompts down to a clean ❯ glyph on Enter, keeping terminal scrollback clean.

Quickstart

You can test zline in seconds.

Manual Setup

git clone https://github.com/casonadams/zline.git ~/.zline

Add this to your ~/.zshrc:

source ~/.zline/zline.zsh

zline preset powerline --transient
zline init

Or test presets interactively in your current shell:

zline preset lean
zline preset catppuccin
zline preset rainbow

There is also an interactive web playground where you can preview configurations in real time: casonadams.github.io/zline.

Takeaways

Writing performant shell plugins doesn't always require compiling to Rust or pulling down C++ helper daemons. By respecting shell architecture—eliminating subshells, reading state directly via native parameter expansions, and leveraging Zsh features like zle -F and .zwc wordcode compilation—you can build tools that are lightweight, maintainable, and fast.

Check out the project on GitHub: github.com/casonadams/zline. Feedback, benchmarks, and PRs are welcome!

Curing Agent Approval Fatigue: Using a Local LLM Gatekeeper for Safe Shell Execution

Cason Adams — Tue, 29 Sep 2026 18:02:41 +0000

If you use autonomous coding agents like oh-my-pi (omp), Claude Code, or Cursor, you have almost certainly encountered the Agent Approval Dilemma.

You have two choices, and both of them are terrible:

YOLO Mode (Auto-Approve Everything): You set your permissions to unrestricted execution. The agent blazes through tasks with zero interruptions—right up until a subtle hallucination or edge case runs git reset --hard, drops your database container, wipes a directory with an unchecked glob, or pushes unfinished code to main.
Paranoid Mode (Prompt on Every Command): You configure the agent to ask before executing any bash command. Within 10 minutes, you’ve manually approved 45 routine commands: cat package.json, git status, bun test, ls -la, mkdir -p dist. Your brain shuts off. You experience acute Approval Fatigue, start blindly mashing Enter, and when a truly dangerous command finally slips through, you approve it anyway.

Security that relies on tired humans repeatedly clicking "OK" is security theater.

To solve this, we built guard—an open-source plugin for oh-my-pi that acts as an intelligent, hybrid gatekeeper for the shell tool. It pairs sub-millisecond deterministic heuristics with a free, private, local LLM (via Ollama, Apple MLX, or local inference) to evaluate commands before they run.

Routine development commands run instantly in the background. Genuinely risky commands get halted with an actionable, plain-English security audit.

Here is how it works under the hood.

The Architecture: Hybrid Defense in Depth

Relying solely on an LLM to evaluate safety is slow and vulnerable to prompt injection. Relying solely on regex is brittle and breaks on complex pipelines or novel commands.

guard uses a two-tiered hybrid approach:

                  Agent issues bash command
                             │
                             ▼
             ┌───────────────────────────────┐
             │ Tier 1: Regex Guard (0.1ms)   │
             │   Traps catastrophic wipes,   │
             │   fork bombs, raw disk writes │
             └───────────────┬───────────────┘
                             │
            Critical Danger? │ No
            ┌────────────────┴───────────────┐
            │                                │
            ▼ (Yes)                          ▼
 ┌─────────────────────┐      ┌─────────────────────────────┐
 │ Prompt User (Block) │      │ Tier 2: Local Model Audit   │
 └─────────────────────┘      │  Evaluates intent, paths,   │
                              │  cloud side effects         │
                              └──────────────┬──────────────┘
                                             │
                             Safe / Read-Only?
                             ┌───────────────┴───────────────┐
                             │                               │
                             ▼ (Yes)                         ▼ (No / Ambiguous)
               ┌──────────────────────────┐    ┌───────────────────────────┐
               │ Execute Silently (0 int) │    │ Explain & Prompt Human    │
               └──────────────────────────┘    └───────────────────────────┘

1. Tier 1: Sub-Millisecond Deterministic Trap

Before spending any compute on an LLM, the command is tested against an immediate pattern trap:

export const CRITICAL_DANGER_REGEX =
  /(\brm\s+-[a-zA-Z]*r[a-zA-Z]*f?\s+([/~]|\.\.|\*)|:\(\)\s*\{\s*:\|:&\s*\};:|\bmkfs\b|\bdd\s+if=|>+\s*\/dev\/sd|\bgit\s+reset\s+--hard\b)/i;

This instantly intercepts catastrophic commands:

rm -rf /, rm -rf ~, or unanchored wildcard deletions (rm -rf *).
Classic shell fork bombs (:(){ :|:& };:).
Low-level disk/partition formatting (mkfs, dd if=, raw writes to /dev/sd*).
Destructive git history erasures (git reset --hard).

If matched, execution is halted immediately. A high-contrast warning pops up explaining the exact nature of the threat (e.g. "Critical destructive filesystem wipe detected"), completely bypassing the LLM.

2. Tier 2: The Local Model Evaluator

If the command isn't an outright disaster, it needs context-aware evaluation. Is rm -rf dist/ safe? Yes, that's just cleaning build output. Is rm -rf ../config safe? Probably not.

Rather than burning expensive cloud tokens or leaking your bash history to external APIs, guard resolves the @guard or @judge model role configured in your ~/.omp/agent/config.yml.

This is specifically designed to use small, blazing-fast local models running on your own machine:

ollama/qwen2.5-coder:7b
ollama/llama3.2:3b
local-inference (MLX on Apple Silicon or llama.cpp)

Because these run locally, latency is negligible (often 100-250ms), cost is zero, and proprietary project context never leaves your computer.

Inside the Code: How Guard Intercepts Tool Calls

In oh-my-pi, plugins hook into the execution lifecycle via extension events. guard listens to tool_call:

export default function registerBashGuard(pi: PiExtensionAPI) {
  pi.on("tool_call", async (event: ToolCallEvent, ctx?: ExtensionContext) => {
    // Only intercept bash commands
    if (event.toolName !== "bash") return;

    const command =
      typeof event.input?.command === "string" ? event.input.command.trim() : undefined;
    if (!command) return;

    // 1. Fast-path deterministic trap
    if (CRITICAL_DANGER_REGEX.test(command)) {
      return promptUser(ctx, command, getCriticalDangerAudit(command));
    }

    // 2. Resolve local guard / judge model
    const guard = await resolveGuardModel(ctx);
    if ("block" in guard) {
      return promptUser(ctx, command, guard.reason);
    }

    // 3. Classify with structured prompt
    const verdict = await evaluateCommandSafety(guard.model, guard.apiKey, command);

    // 4. Safe commands proceed with zero interruption!
    if (!verdict.safe) {
      return promptUser(ctx, command, {
        action: verdict.action,
        reason: verdict.reason || "Action modifies state, cloud resources, or data.",
      });
    }
  });
}

Handling Reasoning Models (`<think>` Stripping)

Modern local models (like DeepSeek-R1 or reasoning-tuned Qwen models) emit thought traces wrapped in <think>...</think>. If you simply JSON.parse their output, your parser will crash on the raw text preamble.

guard cleans the reasoning stream before parsing the decision payload:

export function parseGuardOutput(text: string): GuardVerdict {
  // Strip thought blocks from reasoning models
  const clean = text
    .replace(/<(?:think|thought|thinking)>[\s\S]*?<\/(?:think|thought|thinking)>/gi, "")
    .trim();

  const start = clean.indexOf("{");
  const end = clean.lastIndexOf("}");
  if (start !== -1 && end > start) {
    try {
      const parsed = JSON.parse(clean.slice(start, end + 1));
      if (typeof parsed.safe === "boolean") {
        return {
          safe: parsed.safe,
          action: parsed.action,
          reason: parsed.reason,
        };
      }
    } catch {
      // Heuristic fallback
    }
  }

  // Fail safe if ambiguous
  return { safe: false, reason: "Ambiguous response from guard model." };
}

Defining "Safe": Principles of the Guard Prompt

The prompt fed to the local model enforces strict boundaries:

Safe Categories (Run automatically):
- Build & Test: cargo check, go test ./..., bun run test, tsc --noEmit, pytest.
- Inspection & Diagnostics: cat, grep, git status, git diff, docker ps, lsof, jq.
- Local Workspace File Operations: mkdir build/, cp -r src/ tmp/, rm -rf .cache.
Unsafe Categories (Require human confirmation):
- Destructive Deletion: Recursive removals outside project boundaries or untracked mass deletes.
- Remote Publishing & Infrastructure: git push --force, terraform apply, kubectl delete pod, aws s3 rm, npm publish.
- Privilege Escalation: Any use of sudo, su, or edits to /etc/ or system roots.

When a command is deemed unsafe, instead of a cryptic warning, guard renders an interactive UI prompt:

┌── Security Guard ──────────────────────────────────────────────┐
│ Command : git push origin main --force                         │
│ Action  : Force pushes local history to remote repository      │
│ Risk    : Overwrites remote branch history and may discard     │
│           collaborator commits.                                │
│                                                                │
│ [Enter] Approve    [Esc] Reject                                │
└────────────────────────────────────────────────────────────────┘

You are never guessing why the command was flagged. The risk is contextual, clear, and takes half a second to verify.

Setting It Up in 2 Minutes

If you're using oh-my-pi:

1. Add the Marketplace & Install Guard

In your terminal:

# Add the official plugins marketplace
omp plugin marketplace add casonadams/omp-plugins

# Install the guard plugin
omp plugin install guard@casonadams-plugins

2. Configure Your Settings: Delegate Approval to Guard

Here is the crucial part that people often miss: You must disable oh-my-pi's native, indiscriminate bash prompting.

By default, omp's built-in engine treats bash as an exec-tier tool and prompts you before running any shell command. If you leave native prompting on, omp will still interrupt you for ls and git status, defeating the whole purpose of the plugin!

To let guard take over as the sole, intelligent gatekeeper, update your ~/.omp/agent/config.yml:

tools:
  approvalMode: yolo # Delegates command gating to the guard plugin

modelRoles:
  guard: ollama/qwen2.5-coder:7b # Recommended local model (falls back to judge)

Why `approvalMode: yolo`?

It sounds counter-intuitive at first: "Why would I set YOLO mode if I care about safety?!"

Here's why:

tools.approvalMode: yolo tells omp's native engine not to prompt blindly on every single tool execution.
The guard plugin hooks directly into pi.on("tool_call") before the bash tool ever executes.
If guard classifies the command as safe, it permits execution seamlessly.
If guard detects risk, it triggers ctx.ui.askDialog—putting the interactive approval dialog back in front of you with the exact risk explanation and command preview.

(Alternative: If you want omp to prompt for other tools like browser or MCP actions, but let guard handle bash, you can target just bash with tools.approval.bash: allow while setting tools.approvalMode: write.)

Recommended Local Models

For local, zero-cost, air-gapped inspection, we recommend:

ollama/qwen2.5-coder:7b (Exceptional bash/DevOps command comprehension)
ollama/llama3.2:3b (Ultra-lightweight, near-instant inference)
Apple MLX / Local Inference (Native silicon acceleration via local-inference)

3. The Result

The next time your agent goes to work:

cat src/index.ts $\rightarrow$ passes instantly with zero prompts.
bun test $\rightarrow$ passes instantly with zero prompts.
git status $\rightarrow$ passes instantly with zero prompts.
git push origin main --force $\rightarrow$ HALTS:

┌── Security Guard ──────────────────────────────────────────────┐
│ Command : git push origin main --force                         │
│ Action  : Force pushes local history to remote repository      │
│ Risk    : Overwrites remote branch history and may discard     │
│           collaborator commits.                                │
│                                                                │
│ [Enter] Proceed    [Esc] Cancel    [Tab] Feedback              │
└────────────────────────────────────────────────────────────────┘

Summary

Agentic coding shouldn't require choosing between reckless abandonment and cognitive exhaustion.

By combining deterministic pattern matching with a fast, local AI classifier, guard eliminates the white noise of routine confirmations while preserving a rock-solid safety net for your filesystem and infrastructure.

Marketplace & Showcase: casonadams.github.io/omp-plugins
Repository: github.com/casonadams/omp-plugins
Plugin Source: plugins/guard/

Ditch Oh-My-Zsh Bloat: How I Built zload for Sub-Millisecond Terminal Startup

Cason Adams — Tue, 29 Sep 2026 16:12:58 +0000

If you use Zsh, chances are you started with Oh-My-Zsh. It is a fantastic gateway into the Zsh ecosystem, but over time, terminal startup slows to a crawl.

Every time you open a new tab or split a pane in tmux, you wait 200 ms to 800 ms while shell scripts fork subshells, run uname, call git, and sequentially parse thousands of lines of uncompiled shell code.

I built zload to fix this once and for all: an ultra-fast, zero-friction Zsh plugin manager that replaces Oh-My-Zsh entirely while letting you keep your favorite OMZ plugins.

The Problem with Oh-My-Zsh

Oh-My-Zsh suffers from three architectural bottlenecks:

Subshell Fork Bomb on Startup: Running $(git ...) or $(uname) during shell initialization spawns child operating system processes. Spawning processes in shells is expensive (especially on macOS and WSL).
Sequential Uncompiled Parsing: Plain-text .zsh scripts are parsed into memory by the shell AST parser on every startup.
Monolithic Coupling: To use a simple plugin like git or extract, you have to clone and maintain the entire Oh-My-Zsh framework.

Enter `zload`: 0.45 ms Warm Startup, 0 Subprocesses

zload was designed with strict performance invariants:

Warm Startup < 0.5 ms: Sourcing zload and 10 plugins takes less than half a millisecond.
Zero Subprocess Forks: No uname, which, find, sed, grep, or $(...) subshells on interactive startup. Pure Zsh builtins only.
Memory-Mapped Bytecode (.zwc): Automatically bundles and compiles your active plugins into native wordcode mapped directly into memory via mmap.
Automatic Canonical Ordering: You never have to worry about plugin load order. zload automatically orders completions first, themes/prompts next, utilities in the middle, and syntax highlighting/autosuggestions last.

How `zload` Replaces Oh-My-Zsh (Without Losing Your Plugins)

You do not need Oh-My-Zsh installed to use Oh-My-Zsh plugins. zload natively understands the omz: prefix:

plugins=(
  omz:git
  omz:lib/completion.zsh
  omz:plugins/extract
  omz:plugins/docker
)
zload "${plugins[@]}"

When zload sees omz:, it automatically:

Clones only the upstream Oh-My-Zsh repository once into ~/.local/share/zload/plugins/_omz.
Provides built-in lightweight shims for OMZ helper functions (current_branch, git status decorators).
Automatically includes required dependencies (like lib/git.zsh for omz:git) without pulling in the rest of OMZ.

Before vs. After: `.zshrc` Migration

Before (Standard Oh-My-Zsh setup)

# Slow: 350ms - 700ms startup latency
export ZSH="$HOME/.oh-my-zsh"
ZSH_THEME="robbyrussell"

plugins=(
  git
  extract
  zsh-autosuggestions
  zsh-syntax-highlighting
)

source $ZSH/oh-my-zsh.sh

After (`zload` clean array setup)

# Fast: < 0.5ms startup latency

# 1. Bootstrap zload automatically on any machine
if [[ ! -d "${HOME}/.zload" ]]; then
  git clone --depth 1 https://github.com/casonadams/zload.git "${HOME}/.zload"
fi
source "${HOME}/.zload/zload.zsh"

# 2. Fast paths with validation and deduplication
zload path ~/bin ~/.local/bin /opt/homebrew/bin

# 3. Declare plugins using standard native Zsh array syntax
plugins=(
  casonadams/zline                           # Fast pure-Zsh prompt (< 0.7ms render)
  omz:git                                    # OMZ git plugin & aliases
  omz:lib/completion.zsh                     # OMZ completion styling
  omz:extract                                # OMZ archive extractor
  lukechilds/zsh-nvm --on nvm,node,npm       # Lazy-loaded on command invocation
  zsh-users/zsh-syntax-highlighting --defer  # Deferred until prompt displays
  zsh-users/zsh-autosuggestions
)
zload "${plugins[@]}"
bindkey '^ ' autosuggest-accept

Benchmark Comparison

Benchmarking 10 active plugins on macOS (Apple Silicon):

Framework / Plugin Manager	Warm Startup Overhead	Subprocess Forks	Compiled Bytecode (.zwc)
zload	0.45 ms	0 (Zero)	✓ Native Bytecode
Antigen	68.20 ms	14	✗ Plain text
Zinit	32.40 ms	6	Partials
Oh-My-Zsh (framework)	185.00 ms	18	✗ Plain text

Lazy-Loading Primitives

For commands and utilities that you don't need on every keystroke, zload provides built-in zero-friction primitives:

Command Triggers (--on): Create instant function stubs that clone and load the real plugin only when you first invoke the command (e.g. nvm, k8s, cargo).
Post-Prompt Deferral (--defer): Renders your prompt immediately at 0 ms and queues non-critical plugins (like syntax highlighting) to load during idle time via precmd.
Directory Triggers (--on-dir): Activate plugins only when cd-ing into specific project folders.
Zero-Subprocess Eval Caching (zload eval): Replaces slow eval "$(zoxide init zsh)" or eval "$(starship init zsh)" subshells by compiling tool initialization scripts into wordcode and loading them in 0.2 ms.

Pair with a Fast Pure-Zsh Prompt

A fast shell manager is only half the battle. If your prompt engine forks 10 subshells to check git status, your terminal will still feel sluggish.

I recommend pairing zload with zline, a pure-Zsh prompt engine designed with the same zero-fork philosophy that renders prompts in under 0.7 ms:

plugins=(
  casonadams/zline
  # ... other plugins
)
zload "${plugins[@]}"

Getting Started

Switching takes less than a minute:

# 1. Clone zload
git clone --depth 1 https://github.com/casonadams/zload.git ~/.zload

# 2. Add to the top of your ~/.zshrc
source ~/.zload/zload.zsh

# 3. Declare your plugins and start a new terminal!

Check out the full documentation and interactive website at casonadams.github.io/zload or star the repo on GitHub.

Give it a shot and let me know your terminal startup times before and after!

Rho the next cli agent

Cason Adams — Wed, 02 Sep 2026 07:18:30 +0000

Over the last few weeks I wanted to see if I could build a pure rust cli tui ai agent.

I wanted to keep it minimal yet extensible. So I leveraged the crates eco system like all the node TUIs are doing with npm.

And the result is the beginnings of something that might be great!

https://github.com/casonadams/rho

With the first plugin

https://github.com/casonadams/rho-plugin-permission

It has a few built in tools

bash
read
write
edit
search
fetch

It’s MCP capable (enabled by config).

Because it’s built in rust it’s a single binary and has a much smaller footprint than some of the node alternatives.

There is still lots to do but rho was used to build its first plugin and continues to improve itself.

Always happy to get feedback or suggestions!

The "Claude Mythos" Illusion: Innovation or Data Harvesting?

Cason Adams — Sat, 11 Apr 2026 18:26:02 +0000

The tech industry is currently captivated by the aura surrounding "Claude Mythos," the latest offering from Anthropic. Positioned as an elite-tier, highly restricted model, its access is tightly gated, purportedly reserved only for the world’s most distinguished subject matter experts, scientists, lead architects, and high-level cybersecurity researchers.

Anthropic’s marketing is a masterclass in exclusivity. They describe Mythos not just as a tool, but as a "secure research partner," claiming it features advanced, hardware-level security checks designed to protect the intellectual property of the users who interact with it. But beyond the polished press releases and the invitation-only access, a darker, more pragmatic narrative is beginning to emerge.

The Security Pretext

The core of the Mythos marketing campaign is its "zero-trust" security architecture. Anthropic insists that the model is designed to operate in a walled-off environment, specifically engineered so that experts can feed it proprietary data, raw codebases, and classified research without fear of leakage.

By framing the model as a fortress, they have effectively lowered the defenses of the very people who should be the most cautious. Experts, often wary of cloud-based AI, are finding themselves enticed by the promise of a "secure" sandbox. However, the mechanism they trust to keep their work safe may be the exact pipeline used to ingest it.

The Data Ingestion Engine

If we look past the "security" labels, a different architecture reveals itself. Every interaction with Mythos requires the user to submit their most sensitive, cutting-edge work, the very thing the model claims to be "protecting."

In this model, the "security checks" act as a sophisticated data-cleaning and indexing layer. As an expert uploads a breakthrough algorithm or a novel architectural design, the system isn't just "securing" it; it is tokenizing, categorizing, and mapping the logic into Anthropic's training sets.

Why This Is Different

In previous iterations of AI development, training data was largely scraped from the open web, a "wild west" of publicly available information. Mythos represents a pivot to "High-Value Proprietary Ingestion."

The Expertise Gap: By gating the model to elite users, Anthropic isn't just limiting quantity; they are optimizing for quality. They are essentially crowdsourcing the R&D of the world's most capable minds.
The Validation Loop: By labeling the ingestion process as "security verification," they gain explicit, user-signed permission to analyze the data. It effectively bypasses the ethical grey areas of scraping, as the users are effectively "handing over the keys" to their own intellectual property.
The Mythos Cycle: The experts get a high-performing tool, and in exchange, the model learns from the very solutions those experts are developing. The model becomes smarter, more "expert," and more attractive to the next cohort of users, creating a feedback loop where Anthropic extracts the intellectual capital of an entire industry.

The Takeaway

The "Claude Mythos" is less of a technological breakthrough and more of a strategic masterstroke in data acquisition. It turns the concept of "security" into a Trojan Horse. As developers and researchers, we must ask ourselves: is the convenience of an "expert-only" model worth the price of the very expertise that makes us valuable?

When we step into the walled garden of Mythos, we aren't just using an AI; we are training our own replacements.

Manjaro Linux MacBook Pro 14,1

Cason Adams — Tue, 09 Jul 2024 06:56:00 +0000

Leaving steps to re provision a MacBook Pro 14,1 in the future for me :P

Download Manjaro Linux

https://manjaro.org/download/
I am using Gnome version x86

Burn iso image to usb drive

There are various tools to help with this. I won't go into details that is a blog in it self.

Boot Mac via drive

Insert drive
Reboot machine
Hold option key to get boot menu
Select drive
Manjaro boot screen will load, chose the default option to boot with open source drivers

Getting WiFi working

Open a terminal and execute this command, wlp2s0 and 31 might differ per machine. Likely a smaller number will have a greater success.

iw dev wlp2s0 set txpower fixed 31

Then connect to WiFi

Install

Choose to install, and follow steps for installation. Once complete reboot.

Post Install

auto fix WiFi

I created a simple systemd unit file and saved it to /etc/systemd/system/wifi-txpower.service

[Unit]
Description=Set WiFi txpower on boot

[Service]
Type=oneshot
ExecStart=/usr/bin/iw dev wlp2s0 set txpower fixed 31
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Test the service
sudo chmod 644 /etc/systemd/system/wifi-txpower.service

systemctl daemon-reload
systemctl start wifi-txpower
journalctl -exfu wifi-txpower

If everything is good go ahead enable the service and reboot and verify that WiFi works on reboot

systemd enable wifi-txtpower
reboot

Most of the time it works just fine, if not toggle wifi on and off and you should be good.

fix sound

I followed this repo here https://github.com/davidjo/snd_hda_macbookpro because my sound card was the same.

cat /proc/asound/card0/codec* | grep Codec
Codec: Cirrus Logic CS8409/CS42L83
Codec: Intel Kabylake HDMI

pacman -S gcc linux-headers make patch wget
yay -Syu snd-hda-macbookpro-dkms-git

Then reboot

Set keyboard backlighting

Install brighnessctl

sudo pacman -Syu brightnessctl

List devices

brightnessctl --list
Device 'spi::kbd_backlight' of class 'leds':
    Current brightness: 255 (100%)
    Max brightness: 255

Set desired brightness

brightnessctl --device='spi::kbd_backlight' s 100%

I didn't dive into getting the touchbar working, it seems that I need to do much more work than this. I am fine without it as I map CAPS to ESC anyway.

Happy Hacking!

Simple vim / terminal color changing

Cason Adams — Sat, 05 Mar 2022 19:14:41 +0000

Why?

So I have been looking for solutions that sync my vim colors with my terminal colors. And there are many awesome solutions out there. But none of them gave me the flexibility /freedom I wanted that was simple. So I decided to try to build my own system.

Terminal setup

So there are two options here:

I prefer alacritty-shell because it is the simplest, fastest, and most flexible. However, it requires the use of the alacritty terminal.

Vim setup

Install walh a clean vim colorscheme.

walh will use the first 16 colors from the terminal, and orange(color208) and grey(color247).

Result

Vim colorscheme that matches the terminal colors. Now one can open vim and decided to change the terminal colors from a light theme to a dark theme all from running alacritty_{theme} or walh_{theme}. This gets better if one lives in a multiplex terminal like tmux. This opens doors for setting up scheduled tasks to switch themes based on the time of day.

Ditch iTerm for Alacritty and tmux

Cason Adams — Sun, 26 Dec 2021 22:34:35 +0000

setting up terminal theme

First thing that needs to be done is how to manage terminal theming. But for the full experience (inactive window dimming) this is an important first step.

What's important here is setting index color 18.

alacritty-shell option 1

Follow the instructions for installing alacritty-shell

alacritty theme manual update option 2

Copy a 256 color theme from alacritty-themes into alacritty.yml file.

setting up tmux

Add the following snippet to tmux.conf file.
NOTE if using alacritty-shell use colour247 instead of colour18

Note fg=colour2 is terminal green
Note bg=colour18 is using the index color set from the theming above. It is important that colour18 is a lighter/darker shade of the background color. Usually by about 5-10 lightness values.

set -g pane-active-border-style fg=colour2,bg=colour18
set -g pane-border-style bg=colour18
set-window-option -g window-active-style bg=terminal
set-window-option -g window-style bg=colour18

see it in action

also using walh vim theme for dimming with vim screens.

Neovim LSP to replace VSCode

Cason Adams — Sun, 26 Dec 2021 20:26:48 +0000

If you are looking for a much simpler solution to replacing VSCode with a terminal editor I suggest reading my minimal vim post.

TLDR;

All the code for this is availible nvim-code

Setup

This post is going to assume that neovim 0.6+ is installed and ready to go. From that point lets lay down the directory structure we are going to be dealing with.

Neovim defaults to using ${HOME}/.config/nvim as the configuration directory. I am going to build off that as the base for config files.

nvim
├── after
│   └── ftplugin
│       └── python.lua
├── init.lua
├── lua
│   ├── _lsp.lua
│   ├── _options.lua
│   ├── _plugins.lua
│   ├── _statusline.lua
│   ├── _telescope.lua
│   ├── _treesitter.lua
│   └── _whichkey.lua

init.lua

require("_options")
require("_plugins")
require("_lsp")
require("_treesitter")
require("_telescope")
require("_whichkey")
require("_statusline")

vim.cmd("colorscheme walh-gruvbox")

_options.lua

I'm not going to cover all the options available, but here are some common ones that can be used or omitted. Heavily inspired by lunarvim.

vim.g.mapleader = " "

vim.g.border_style = "rounded"
vim.g.markdown_fenced_languages = {
    "bash=sh",
}

vim.opt.backup = false -- creates a backup file
vim.opt.clipboard = "" -- don't use clipboard
vim.opt.cmdheight = 1 -- more space in the neovim command line for displaying messages
vim.opt.colorcolumn = "99999" -- fixes indentline for now
vim.opt.completeopt = { "menuone", "noselect" }
vim.opt.conceallevel = 0 -- so that `` is visible in markdown files
vim.opt.cursorline = true -- highlight the current line
vim.opt.expandtab = true -- convert tabs to spaces
vim.opt.fileencoding = "utf-8" -- the encoding written to a file
vim.opt.foldexpr = "" -- set to "nvim_treesitter#foldexpr()" for treesitter based folding
vim.opt.foldmethod = "manual" -- folding set to "expr" for treesitter based folding
vim.opt.hidden = true -- required to keep multiple buffers and open multiple buffers
vim.opt.hlsearch = true -- highlight all matches on previous search pattern
vim.opt.ignorecase = true -- ignore case in search patterns
vim.opt.list = true
vim.opt.listchars = "tab:│ ,trail:·,nbsp:+"
vim.opt.number = true -- set numbered lines
vim.opt.numberwidth = 1 -- set number column width to 2 {default 4}
vim.opt.pumheight = 10 -- pop up menu height
vim.opt.relativenumber = false -- set relative numbered lines
vim.opt.scrolloff = 4 -- is one of my fav
vim.opt.shiftwidth = 2 -- the number of spaces inserted for each indentation
vim.opt.showmode = false -- we don't need to see things like -- INSERT -- anymore
vim.opt.sidescrolloff = 4
vim.opt.signcolumn = "yes" -- always show the sign column otherwise it would shift the text each time
vim.opt.smartcase = true -- smart case
vim.opt.smartindent = true -- make indenting smarter again
vim.opt.spell = false -- disable spell checking
vim.opt.spelllang = "en" -- language for spell checking
vim.opt.splitbelow = true -- force all horizontal splits to go below current window
vim.opt.splitright = true -- force all vertical splits to go to the right of current window
vim.opt.swapfile = false -- creates a swapfile
vim.opt.tabstop = 2 -- insert 2 spaces for a tab
vim.opt.termguicolors = false -- set term gui colors (most terminals support this)
vim.opt.timeoutlen = 500 -- timeout length
vim.opt.title = true -- set the title of window to the value of the titlestring
vim.opt.titlestring = "%<%F - nvim" -- what the title of the window will be set to
vim.opt.undodir = vim.fn.stdpath("cache") .. "/undo"
vim.opt.undofile = true -- enable persistent undo
vim.opt.updatetime = 300 -- faster completion
vim.opt.wrap = true -- display lines as one long line
vim.opt.writebackup = false -- if a file is being edited by another program (or was written to file while editing with another program) it is not allowed to be edited

vim.opt.showtabline = 2 -- always show tabs
vim.opt.laststatus = 2 -- hide statusline

_plugins.lua

I have to admit using neovims builtin lsp is nice but it comes with the requirement to install many plugins to get a similar experience with VSCode.

local fn = vim.fn
local install_path = fn.stdpath("data") .. "/site/pack/packer/start/packer.nvim"
if fn.empty(fn.glob(install_path)) > 0 then
    packer_bootstrap = fn.system({
        "git",
        "clone",
        "--depth",
        "1",
        "https://github.com/wbthomason/packer.nvim",
        install_path,
    })
end

return require("packer").startup(function()
    use({
        "L3MON4D3/LuaSnip",
        "casonadams/walh",
        "folke/trouble.nvim",
        "hrsh7th/cmp-buffer",
        "hrsh7th/cmp-cmdline",
        "hrsh7th/cmp-nvim-lsp",
        "hrsh7th/cmp-path",
        "hrsh7th/nvim-cmp",
        "jose-elias-alvarez/null-ls.nvim",
        "neovim/nvim-lspconfig",
        "nvim-lua/lsp-status.nvim",
        "nvim-treesitter/nvim-treesitter",
        "saadparwaiz1/cmp_luasnip",
        "tamago324/nlsp-settings.nvim",
        "wbthomason/packer.nvim",
        "williamboman/nvim-lsp-installer",
    })
    use({
        "rafamadriz/friendly-snippets",
    })
    use({
        "nvim-telescope/telescope.nvim",
        requires = { "nvim-lua/plenary.nvim" },
    })
    use({
        "nvim-lualine/lualine.nvim",
        requires = { "kyazdani42/nvim-web-devicons", opt = true },
    })
    use({
        "folke/which-key.nvim",
        config = function()
            require("which-key").setup({})
        end,
    })
    use({
        "terrortylor/nvim-comment",
        config = function()
            require("nvim_comment").setup({})
        end,
    })
    use({
        "lewis6991/gitsigns.nvim",
        config = function()
            require("gitsigns").setup({ yadm = { enable = true } })
        end,
    })
    use({
        "ethanholz/nvim-lastplace",
        event = "BufRead",
        config = function()
            require("nvim-lastplace").setup({
                lastplace_ignore_buftype = { "quickfix", "nofile", "help" },
                lastplace_ignore_filetype = { "gitcommit", "gitrebase", "svn", "hgcommit" },
                lastplace_open_folds = true,
            })
        end,
    })
    -- Automatically set up your configuration after cloning packer.nvim
    -- Put this at the end after all plugins
    if packer_bootstrap then
        require("packer").sync()
    end
end)

_lsp.lua

local cmp = require("cmp")
local lsp_status = require("lsp-status")

local win = require("lspconfig.ui.windows")
local _default_opts = win.default_opts

win.default_opts = function(options)
    local opts = _default_opts(options)
    opts.border = "rounded"
    return opts
end

-- statusline progress setup
lsp_status.config({
    current_function = false,
    show_filename = false,
    diagnostics = false,
    status_symbol = "",
    select_symbol = nil,
    update_interval = 200,
})

-- completion setup
cmp.setup({
    snippet = {
        expand = function(args)
            -- vim.fn["vsnip#anonymous"](args.body)
            require("luasnip").lsp_expand(args.body) -- For `luasnip` users.
            -- vim.fn["UltiSnips#Anon"](args.body)
        end,
    },
    mapping = {
        ["<C-d>"] = cmp.mapping.scroll_docs(-4),
        ["<C-f>"] = cmp.mapping.scroll_docs(4),
        ["<C-Space>"] = cmp.mapping.complete(),
        ["<C-e>"] = cmp.mapping.close(),
        ["<CR>"] = cmp.mapping.confirm({ select = false }),
        ["<Tab>"] = cmp.mapping(cmp.mapping.select_next_item(), { "i", "s" }),
        ["<S-Tab>"] = cmp.mapping(cmp.mapping.select_prev_item(), { "i", "s" }),
    },
    sources = {
        { name = "nvim_lsp" },
        { name = "luasnip" },
        -- { name = "ultisnips" },
        -- { name = "vsnip" },
        { name = "buffer" },
        { name = "path" },
    },
})

-- helper function for mappings
local m = function(mode, key, result)
    vim.api.nvim_buf_set_keymap(0, mode, key, "<cmd> " .. result .. "<cr>", {
        noremap = true,
        silent = true,
    })
end

-- function to attach completion when setting up lsp
local on_attach = function(client)
    lsp_status.register_progress()
    lsp_status.on_attach(client)

    -- Mappings.
    m("n", "ga", "lua vim.lsp.buf.code_action()")
    m("n", "gD", "lua vim.lsp.buf.declaration()")
    m("n", "gd", "lua vim.lsp.buf.definition()")
    m("n", "ge", "lua vim.lsp.diagnostic.goto_next()")
    m("n", "gE", "lua vim.lsp.diagnostic.goto_prev()")
    m("n", "gi", "lua vim.lsp.buf.implementation()")
    m("n", "gr", "lua vim.lsp.buf.references()")
    m("n", "K", "lua vim.lsp.buf.hover()")
    -- m("n", "<space>rn", "lua vim.lsp.buf.rename()")
    m("n", "gl", "lua vim.lsp.diagnostic.show_line_diagnostics()")
    -- m("n", "<space>f", "lua vim.lsp.buf.formatting()")
end

-- setup lsp installer
local lsp_installer = require("nvim-lsp-installer")
-- Provide settings first!
lsp_installer.settings({
    ui = {
        icons = {
            server_installed = "✓",
            server_pending = "➜",
            server_uninstalled = "✗",
        },
    },
})
lsp_installer.on_server_ready(function(server)
    local opts = {
        on_attach = on_attach,
        capabilities = require("cmp_nvim_lsp").update_capabilities(vim.lsp.protocol.make_client_capabilities()),
        flags = {
            debounce_text_changes = 150,
        },
    }
    server:setup(opts)
end)

-- lsp settings
require("nlspsettings").setup()

-- diagnostics
vim.diagnostic.config({
    virtual_text = false,
    underline = true,
    float = {
        source = "always",
    },
    severity_sort = true,
    --[[ virtual_text = {
      prefix = "»",
      spacing = 4,
    }, ]]
    signs = true,
    update_in_insert = false,
})

_treesitter.lua

require'nvim-treesitter.configs'.setup {
  ensure_installed = "maintained",
  sync_install = false,
  highlight = {
    enable = true,
    additional_vim_regex_highlighting = false,
  },
}

_telescope.lua

require("telescope").setup({
    defaults = {
        border = true,
        layout_strategy = "bottom_pane",
        layout_config = {
            height = 0.30,
            width = 1.00,
        },
        -- path_display = { "shorten" },
        sorting_strategy = "ascending",
    },
})

require("trouble").setup({
  icons=false
})

_whichkey.lua

local which_key = {
    setup = {
        plugins = {
            marks = true,
            registers = true,
            presets = {
                operators = false,
                motions = false,
                text_objects = false,
                windows = true,
                nav = true,
                z = true,
                g = true,
            },
            spelling = { enabled = true, suggestions = 20 },
        },
        icons = {
            breadcrumb = "»",
            separator = "➜",
            group = "+",
        },
        window = {
            border = "none", -- none, single, double, shadow
            position = "bottom", -- bottom, top
            margin = { 1, 0, 1, 0 },
            padding = { 2, 2, 2, 2 },
        },
        layout = {
            height = { min = 4, max = 25 },
            width = { min = 20, max = 50 },
            spacing = 3,
        },
        hidden = { "<silent>", "<cmd>", "<Cmd>", "<CR>", "call", "lua", "^:", "^ " },
        show_help = true,
    },

    opts = {
        mode = "n",
        prefix = "<leader>",
        buffer = nil,
        silent = true,
        noremap = true,
        nowait = true,
    },
    vopts = {
        mode = "v",
        prefix = "<leader>",
        buffer = nil,
        silent = true,
        noremap = true,
        nowait = true,
    },
    -- NOTE: Prefer using : over <cmd> as the latter avoids going back in normal-mode.
    -- see https://neovim.io/doc/user/map.html#:map-cmd
    vmappings = {},
    mappings = {
        ["c"] = { ":BufferClose!<CR>", "Close Buffer" },
        ["e"] = { ":Telescope file_browser <CR>", "File Browser" },
        ["f"] = { ":Telescope find_files <CR>", "Find File" },
        ["h"] = { ":nohlsearch<CR>", "No Highlight" },
        b = {
            name = "Buffers",
            l = { ":Telescope buffers<CR>", "List Buffers" },
            b = { ":b#<cr>", "Previous" },
            d = { ":bd<cr>", "Delete" },
            f = { ":Telescope buffers <cr>", "Find" },
            n = { ":bn<cr>", "Next" },
            p = { ":bp<cr>", "Previous" },
        },
        p = {
            name = "Packer",
            c = { ":PackerCompile<cr>", "Compile" },
            i = { ":PackerInstall<cr>", "Install" },
            r = { ":lua require('lvim.utils').reload_lv_config()<cr>", "Reload" },
            s = { ":PackerSync<cr>", "Sync" },
            S = { ":PackerStatus<cr>", "Status" },
            u = { ":PackerUpdate<cr>", "Update" },
        },
        l = {
            name = "LSP",
            a = { ":Telescope lsp_code_actions<cr>", "Code Action" },
            d = {
                ":Telescope lsp_document_diagnostics<cr>",
                "Document Diagnostics",
            },
            w = {
                ":Telescope diagnostics<cr>",
                "Workspace Diagnostics",
            },
            f = { ":lua vim.lsp.buf.formatting()<cr>", "Format" },
            i = { ":LspInfo<cr>", "Info" },
            I = { ":LspInstallInfo<cr>", "Installer Info" },
            r = { ":lua vim.lsp.buf.rename()<cr>", "Rename" },
        },
        s = {
            name = "Search",
            b = { ":Telescope git_branches <cr>", "Checkout branch" },
            c = { ":Telescope colorscheme <cr>", "Colorscheme" },
            C = { ":Telescope commands <cr>", "Commands" },
            f = { ":Telescope find_files <cr>", "Find File" },
            h = { ":Telescope help_tags <cr>", "Find Help" },
            j = { ":Telescope jumplist <cr>", "Jumplist" },
            k = { ":Telescope keymaps <cr>", "Keymaps" },
            M = { ":Telescope man_pages <cr>", "Man Pages" },
            r = { ":Telescope oldfiles <cr>", "Open Recent File" },
            R = { ":Telescope registers <cr>", "Registers" },
            t = { ":Telescope live_grep <cr>", "Text" },
            n = { ":Telescope live_grep search_dirs={os.getenv('NOTES')} <cr>", "Notes" },
            p = {
                ":lua require('telescope.builtin.internal').colorscheme({enable_preview = true})<cr>",
                "Colorscheme with Preview",
            },
        },
        T = {
            name = "Treesitter",
            i = { ":TSConfigInfo<cr>", "Info" },
        },
        t = {
            name = "Diagnostics",
            t = { "<cmd>TroubleToggle<cr>", "trouble" },
            w = { "<cmd>TroubleToggle workspace_diagnostics<cr>", "workspace" },
            d = { "<cmd>TroubleToggle document_diagnostics<cr>", "document" },
            q = { "<cmd>TroubleToggle quickfix<cr>", "quickfix" },
            l = { "<cmd>TroubleToggle loclist<cr>", "loclist" },
            r = { "<cmd>TroubleToggle lsp_references<cr>", "references" },
        },
    },
}

function map(mode, lhs, rhs, opts)
        local options = { noremap = true, silent = true }
    if opts then
        options = vim.tbl_extend("force", options, opts)
    end
    vim.api.nvim_set_keymap(mode, lhs, rhs, options)
end

map("n", "H", ":bp<CR>")
map("n", "L", ":bn<CR>")

map("n", "<tab>", ":tabnext<CR>")
map("n", "<S-tab>", ":tabprevious<CR>")

map("n", "<C-h>", ":wincmd h<CR>")
map("n", "<C-j>", ":wincmd j<CR>")
map("n", "<C-k>", ":wincmd k<CR>")
map("n", "<C-l>", ":wincmd l<CR>")

local wk = require("which-key")
wk.setup(which_key.setup)

local opts = which_key.opts
local vopts = which_key.vopts

local mappings = which_key.mappings
local vmappings = which_key.vmappings

wk.register(mappings, opts)
wk.register(vmappings, vopts)

if which_key.on_config_done then
    which_key.on_config_done(wk)
end

_statusline.lua

local lsp_status = require("lsp-status")

local function lsp_progress()
    return lsp_status.status()
end

local function extract_highlight_colors(color_group, scope)
    if vim.fn.hlexists(color_group) == 0 then
        return nil
    end
    local color = vim.api.nvim_get_hl_by_name(color_group, true)
    if color.background ~= nil then
        color.bg = string.format("#%06x", color.background)
        color.background = nil
    end
    if color.foreground ~= nil then
        color.fg = string.format("#%06x", color.foreground)
        color.foreground = nil
    end
    if scope then
        return color[scope]
    end
    return color
end

local colors = {
    gray = 8,
    red = 9,
    green = 10,
    yellow = 11,
    blue = 12,
    magenta = 13,
    cyan = 14,
    white = 15,
    background = extract_highlight_colors("StatusLine", "bg"),
    foreground = 7,
}

local custom_theme = {
    normal = {
        a = { bg = colors.foreground, fg = colors.background },
        b = { bg = colors.background, fg = colors.foreground },
        c = { bg = colors.background, fg = colors.foreground },
    },
    insert = {
        a = { bg = colors.cyan, fg = colors.background },
        b = { bg = colors.background, fg = colors.cyan },
        c = { bg = colors.background, fg = colors.foreground },
    },
    visual = {
        a = { bg = colors.yellow, fg = colors.background },
        b = { bg = colors.background, fg = colors.yellow },
        c = { bg = colors.background, fg = colors.foreground },
    },
    replace = {
        a = { bg = colors.red, fg = colors.background },
        b = { bg = colors.background, fg = colors.red },
        c = { bg = colors.background, fg = colors.foreground },
    },
    command = {
        a = { bg = colors.magenta, fg = colors.background },
        b = { bg = colors.background, fg = colors.magenta },
        c = { bg = colors.background, fg = colors.foreground },
    },
    inactive = {
        a = { bg = colors.background, fg = colors.gray },
        b = { bg = colors.background, fg = colors.gray },
        c = { bg = colors.background, fg = colors.gray },
    },
}

local components = {
    mode = {
        function()
            return " "
        end,
        padding = { left = 0, right = 0 },
    },
    filename = {
        "filename",
    },
    diagnostics = {
        "diagnostics",
        sources = { "nvim_diagnostic" },
        symbols = { error = " ", warn = " ", info = " ", hint = " " },
    },
    treesitter = {
        function()
            local b = vim.api.nvim_get_current_buf()
            if next(vim.treesitter.highlighter.active[b]) then
                return ""
            end
            return ""
        end,
    },
    location = { "location" },
    progress = { "progress" },
    encoding = {
        "o:encoding",
        fmt = string.upper,
    },
    filetype = { "filetype" },
}

require("lualine").setup({
    options = {
        theme = custom_theme,
        icons_enabled = false,
        component_separators = { left = "", right = "" },
        section_separators = { left = "", right = "" },
        disabled_filetypes = { "dashboard", "NvimTree", "Outline" },
    },
    sections = {
        lualine_a = {},
        lualine_b = {
            components.filename,
        },
        lualine_c = {
            components.diff,
        },
        lualine_x = {
            lsp_progress,
            components.diagnostics,
        },
        lualine_y = {
            components.treesitter,
        },
        lualine_z = {},
    },
    inactive_sections = {
        lualine_a = {},
        lualine_b = {
            "filename",
        },
        lualine_c = {},
        lualine_x = {},
        lualine_y = {},
        lualine_z = {},
    },
    tabline = {
        lualine_a = {},
        lualine_b = { { "buffers" } },
        lualine_c = {},
        lualine_x = {},
        lualine_y = { { "tabs", mode = 0 } },
        lualine_z = {},
    },
    extensions = { "nvim-tree" },
})

Conclusion

Sooo much config I know! I am sorry about all of that. But it think having all of this config makes everything customizable for anyone. Take the settings I made as a grain of salt, I have an opinion about how vim should be for me. Hopefully this is just a foundation that someone can use to get up and running then modify things to the prefered settings. I also, left some commented out settings for further tinkering.

So if you have made it this far the next step is to try it out. Let see how it works.

main.py test

Create a file nvim main.py. On first load nvim is going to complain because none of the plugins are setup. Go ahead and just type q until the complaints end. We need restart nvim now that packer has been installed. qa then nvim main.py. Now we have packer we can :PackerSync this will install and update all the plugins defined in _plugins.lua. Close nvim one more time :qa. Now we got that over with then get on to testing out our setup. nvim main.py (notice that tree-sitter is installing a few things) let that happen in the background. Wait for tree-sitter to finish before exiting. Put this snippet in the file.

#!/usr/bin/env python

def echo(msg):
    print msg

if __name__ == "__main__":
    echo("Hello World!")

Save :w

install pyright server

Now we need to install the lsp server to work with python files. This can be done a few different ways fastest is to :LspInstall pyright, or one can access a "dashboard" with :LspInstallInfo and then use the help ? to see options. u will upgrade the server under the cursor, and i will install the server under the cursor.

Now that pyright is installed lets make sure it is working.

Notice line 4 msg is underlined and an E is indicated in the gitgutter. Move the cursor to line 4 and trigger the line diagnostics gl. If you see the popup you are configured correctly!

black formatter

I didn't go into very much detail about custom settings for the language servers that get installed or formatting and linting. Here is an
w to use black as the python formatter. We are using null-ls for the formatting here.

after/ftplugin/python.lua

 local null_ls = require("null-ls")

local sources = {
    null_ls.builtins.formatting.black,
}

null_ls.setup({ sources = sources })

Note null_ls can setup all settings in a regular way like the other lua files we created. Using the after dir / lazy loading is just one way of doing this.

Make sure black in installed pip install black. Lets try it out with our main.py file. Update it to the following, then save :w.

#!/usr/bin/env python
def echo(msg):
    print(msg)
if __name__ == "__main__":
    echo("Hello World!")

Note leader is space

Now to tell nvim to format with the defined formatter send leader lf.

And the result should be a nicely formatted python file.

And that about wraps it up.

Minimal (neo)vim with VSCode like setup

Cason Adams — Sun, 26 Dec 2021 07:39:09 +0000

I wanted to share a quick little setup to get up and running quickly with vim as an IDE. I don't really like vim and IDE in the same sentence, but I do have to admit that having an IDE that runs in the terminal and loads fast is pretty sweet.
header image

~/.vimrc

~/.vim
├── _lsp.vim
├── _options.vim
├── _plugins.vim
├── _theme.vim

Requirements

nodejs

create ~/.vim directory

First we need a place to store a few files. I am going to put them in ${HOME}/.vim/ so I will make that directory.

_theme.vim (optional)

Lets create a file to store theme settings. I am going to put it in ${HOME}/.vim/_theme.vim.

syntax enable
" set t_Co=16 " uncomment to force ANSI 16 colors

if has('gui_running')
    set background=light
else
    set background=dark
endif

colorscheme gruvbox8

_options.vim (optional)

Lets create a file to store vim options. I am going to put it in ${HOME}/.vim/_options.vim. I tried to document the options below. These are optional, I borrowed some of this information from LunarVims default settings. Most options can be prefixed with no to disable the behavior.

let mapleader="\ " " set leader key to space

set clipboard="" " don't use clipboard
set cmdheight=1 " more space in the neovim command line for
set colorcolumn="99999" " fixes indentline for now
set completeopt=menuone,noselect
set conceallevel=0 " so that `` is visible in markdown files
set cursorline " highlight the current line
set expandtab " convert tabs to spaces
set fileencoding="utf-8" " the encoding written to a file
set foldexpr="" " set to "nvim_treesitter#foldexpr()" for treesitter based folding
set hidden " required to keep multiple buffers and open multiple buffers
set hlsearch " highlight all matches on previous search pattern
set ignorecase " ignore case in search patterns
set laststatus=2 " hide statusline
set list " show hidden chars
set listchars=tab:│\ ,trail:·,nbsp:+
set nobackup " creates a backup file
set norelativenumber " set relative numbered lines
set nospell " disable spell checking
set noswapfile " creates a swapfile
set nowritebackup " if a file is being edited by another program (or was written to file while editing with another program) it is not allowed to be edited
set number " set numbered lines
set numberwidth=1 " set number column width to 2 {default 4}
set pumheight=10 " pop up menu height
set scrolloff=4 " is one of my fav
set shiftwidth=2 " the number of spaces inserted for each indentation
set showmode " shows " INSERT " in cmdline
set showtabline=2 " always show tabs
set sidescrolloff=4
set signcolumn="yes" " always show the sign column otherwise it would shift the text each time
set smartcase " smart case
set smartindent " make indenting smarter again
set spelllang="en" " language for spell checking
set splitbelow " force all horizontal splits to go below current window
set splitright " force all vertical splits to go to the right of current window
set tabstop=2 " insert 2 spaces for a tab
set timeoutlen=500 " timeout length
set title " set the title of window to the value of the titlestring
set titlestring="%<%F - vim" " what the title of the window will be set to
set undodir="/undo" .. "/undo"
set undofile " enable persistent undo
set updatetime=300 " faster completion
set wrap " display lines as one long line

_plugins.vim

Lets create a file to manage vim plugins. I am going to put it in ${HOME}/.vim/_plugins.vim. For this tutorial we are using vim-plug.

Note fancy things are happening in the first 2 blocks of code that will auto install vim-plug and auto install missing plugins. (curl is required for this magic to happen)
Note 3 plugins are being installed here:
1. coc.nvim (LSP IDE magic)
2. vim-gruvbox8 (colorscheme)
3. vim-commentary (nice shortcuts for code commenting)

" https://github.com/junegunn/vim-plug/wiki/tips#automatic-installation

" Install vim-plug if not found
if empty(glob('~/.vim/autoload/plug.vim'))
   silent !curl -fLo ~/.vim/autoload/plug.vim --create-dirs
     \ https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
   endif

" Run PlugInstall if there are missing plugins
autocmd VimEnter * if len(filter(values(g:plugs), '!isdirectory(v:val.dir)'))
 \| PlugInstall --sync | source $MYVIMRC
 \| endif

" Plugins
call plug#begin()
  Plug 'neoclide/coc.nvim', {'branch': 'release'}
  Plug 'lifepillar/vim-gruvbox8'
  Plug 'tpope/vim-commentary'
call plug#end()

Most used shortcut key for vim-commentary

Shortcut	Description
`gcc`	comment / uncomment

_lsp.vim

Lets create a file to manage vim lsp servers. I am going to put it in ${HOME}/.vim/_lsp.vim. This is where we will configure coc.nvim.

From the example. The following has been slightly modified moving some options to _options.vim, and configuring the statusline to be as close to vanilla vim with some lsp information.

" Use tab for trigger completion with characters ahead and navigate.
" NOTE: Use command ':verbose imap <tab>' to make sure tab is not mapped by
" other plugin before putting this into your config.
inoremap <silent><expr> <TAB>
      \ pumvisible() ? "\<C-n>" :
      \ <SID>check_back_space() ? "\<TAB>" :
      \ coc#refresh()
inoremap <expr><S-TAB> pumvisible() ? "\<C-p>" : "\<C-h>"

function! s:check_back_space() abort
  let col = col('.') - 1
  return !col || getline('.')[col - 1]  =~# '\s'
endfunction

" Use <c-space> to trigger completion.
if has('nvim')
  inoremap <silent><expr> <c-space> coc#refresh()
else
  inoremap <silent><expr> <c-@> coc#refresh()
endif

" Make <CR> auto-select the first completion item and notify coc.nvim to
" format on enter, <cr> could be remapped by other vim plugin
inoremap <silent><expr> <cr> pumvisible() ? coc#_select_confirm()
                              \: "\<C-g>u\<CR>\<c-r>=coc#on_enter()\<CR>"


" Use `[g` and `]g` to navigate diagnostics
" Use `:CocDiagnostics` to get all diagnostics of current buffer in location list.
nmap <silent> [g <Plug>(coc-diagnostic-prev)
nmap <silent> ]g <Plug>(coc-diagnostic-next)

" GoTo code navigation.
nmap <silent> gd <Plug>(coc-definition)
nmap <silent> gy <Plug>(coc-type-definition)
nmap <silent> gi <Plug>(coc-implementation)
nmap <silent> gr <Plug>(coc-references)

" Use K to show documentation in preview window.
nnoremap <silent> K :call <SID>show_documentation()<CR>

function! s:show_documentation()
  if (index(['vim','help'], &filetype) >= 0)
    execute 'h '.expand('<cword>')
  elseif (coc#rpc#ready())
    call CocActionAsync('doHover')
  else
    execute '!' . &keywordprg . " " . expand('<cword>')
  endif
endfunction

" Highlight the symbol and its references when holding the cursor.
" autocmd CursorHold * silent call CocActionAsync('highlight')

" Symbol renaming.
nmap <leader>rn <Plug>(coc-rename)

" Formatting selected code.
xmap <leader>f  <Plug>(coc-format-selected)
nmap <leader>f  <Plug>(coc-format-selected)

augroup mygroup
  autocmd!
  " Setup formatexpr specified filetype(s).
  autocmd FileType typescript,json setl formatexpr=CocAction('formatSelected')
  " Update signature help on jump placeholder.
  autocmd User CocJumpPlaceholder call CocActionAsync('showSignatureHelp')
augroup end

" Applying codeAction to the selected region.
" Example: `<leader>aap` for current paragraph
xmap <leader>a  <Plug>(coc-codeaction-selected)
nmap <leader>a  <Plug>(coc-codeaction-selected)

" Remap keys for applying codeAction to the current buffer.
nmap <leader>ac  <Plug>(coc-codeaction)
" Apply AutoFix to problem on the current line.
nmap <leader>qf  <Plug>(coc-fix-current)

" Run the Code Lens action on the current line.
nmap <leader>cl  <Plug>(coc-codelens-action)

" Map function and class text objects
" NOTE: Requires 'textDocument.documentSymbol' support from the language server.
xmap if <Plug>(coc-funcobj-i)
omap if <Plug>(coc-funcobj-i)
xmap af <Plug>(coc-funcobj-a)
omap af <Plug>(coc-funcobj-a)
xmap ic <Plug>(coc-classobj-i)
omap ic <Plug>(coc-classobj-i)
xmap ac <Plug>(coc-classobj-a)
omap ac <Plug>(coc-classobj-a)

" Remap <C-f> and <C-b> for scroll float windows/popups.
if has('nvim-0.4.0') || has('patch-8.2.0750')
  nnoremap <silent><nowait><expr> <C-f> coc#float#has_scroll() ? coc#float#scroll(1) : "\<C-f>"
  nnoremap <silent><nowait><expr> <C-b> coc#float#has_scroll() ? coc#float#scroll(0) : "\<C-b>"
  inoremap <silent><nowait><expr> <C-f> coc#float#has_scroll() ? "\<c-r>=coc#float#scroll(1)\<cr>" : "\<Right>"
  inoremap <silent><nowait><expr> <C-b> coc#float#has_scroll() ? "\<c-r>=coc#float#scroll(0)\<cr>" : "\<Left>"
  vnoremap <silent><nowait><expr> <C-f> coc#float#has_scroll() ? coc#float#scroll(1) : "\<C-f>"
  vnoremap <silent><nowait><expr> <C-b> coc#float#has_scroll() ? coc#float#scroll(0) : "\<C-b>"
endif

" Use CTRL-S for selections ranges.
" Requires 'textDocument/selectionRange' support of language server.
nmap <silent> <C-s> <Plug>(coc-range-select)
xmap <silent> <C-s> <Plug>(coc-range-select)

" Add `:Format` command to format current buffer.
command! -nargs=0 Format :call CocAction('format')

" Add `:Fold` command to fold current buffer.
command! -nargs=? Fold :call     CocAction('fold', <f-args>)

" Add `:OR` command for organize imports of the current buffer.
command! -nargs=0 OR   :call     CocActionAsync('runCommand', 'editor.action.organizeImport')

" Add (Neo)Vim's native statusline support.
" NOTE: Please see `:h coc-status` for integrations with external plugins that
" provide custom statusline: lightline.vim, vim-airline.
set statusline=\ %<%f\ %h%m%r
set statusline+=%=%-10.50{ShowCocStatus()}\ %-.(%l,%c%V%)\ %P

function! ShowCocStatus() 
  return get(g:, 'coc_status', '')
endfunc

" Mappings for CoCList
" Show all diagnostics.
nnoremap <silent><nowait> <space>a  :<C-u>CocList diagnostics<cr>
" Manage extensions.
nnoremap <silent><nowait> <space>e  :<C-u>CocList extensions<cr>
" Show commands.
nnoremap <silent><nowait> <space>c  :<C-u>CocList commands<cr>
" Find symbol of current document.
nnoremap <silent><nowait> <space>o  :<C-u>CocList outline<cr>
" Search workspace symbols.
nnoremap <silent><nowait> <space>s  :<C-u>CocList -I symbols<cr>
" Do default action for next item.
nnoremap <silent><nowait> <space>j  :<C-u>CocNext<CR>
" Do default action for previous item.
nnoremap <silent><nowait> <space>k  :<C-u>CocPrev<CR>
" Resume latest coc list.
nnoremap <silent><nowait> <space>p  :<C-u>CocListResume<CR>

There is a lot going on in there. This makes it so we get (tab) completion on typing, and setups tons of shortcuts for quickly doing things. Look for nmap for all the settings. Here are a few of the very basics.

Shortcut	Description
`gd`	go to def
`K`	show hover
`leader rn`	rename
`leader f`	call format

Note some languages require formatters to be installed first. As an example in python the default formatter using coc-pyright server is autopep8. In order to use this formatter pip install autopep8 etc...

vimrc

Now lets bring it all together. Open ${HOME}/.vimrc (I am not sure where this lives in windows sorry) and add the following.

source ~/.vim/_options.vim
source ~/.vim/_plugins.vim
source ~/.vim/_lsp.vim
source ~/.vim/_theme.vim

Installing servers

Lets try installing a coc.nvim extension. Quick link to some extenstions. For the purpose of this post lets install coc-pyright and try it out with a python file.

Install extenstion

Lets create a simple python file. vim main.py

Note line 4 has an error, and once we are setup with coc.nvim we should see it.

#!/usr/bin/env python

def echo(msg):
    print msg

if __name__ == "__main__":
    echo("Hello World!")

Install coc-pyright :CocInstall coc-pyright
Save the file :wq

Next time the file is open it is expected to see an error indicated in line 4. Move the cursor to msg and the following should pop up.

Conclusion

If everything is working as planned you have successfully setup coc.nvim and are now off to the races to further configure things. Happy hacking.

Neovim LSP only show line error on CursorHold

Cason Adams — Fri, 08 Oct 2021 08:05:04 +0000

I've been using lunarvim for just a bit now, and It is pretty well setup. I recommend trying it out.

Here is a fun little trick to show only the line error for the given line the cursor is on.

There are somethings it doesn't do and that is change the line color base on the error type (Error, Warn, etc..). It is setup to just use highlight for Comment

Open ~/.config/lvim/config.lua and add the following:

lvim.lsp.diagnostics.virtual_text = false


function PrintDiagnostics(opts, bufnr, line_nr, client_id)
  opts = opts or {}

  bufnr = bufnr or 0
  line_nr = line_nr or (vim.api.nvim_win_get_cursor(0)[1] - 1)

  local line_diagnostics = vim.lsp.diagnostic.get_line_diagnostics(bufnr, line_nr, opts, client_id)
  if vim.tbl_isempty(line_diagnostics) then return end

  local diagnostic_message = ""
  for i, diagnostic in ipairs(line_diagnostics) do
    diagnostic_message = diagnostic_message .. string.format("%s ", diagnostic.message or "")
  end
  -- print(diagnostic_message) -- on comment to print to MsgArea
  vim.api.nvim_buf_set_virtual_text(bufnr, 1, line_nr , {{diagnostic_message, "Comment"}}, {})
end

function Clear(_, bufnr, _, _)
-- print("    ") -- on comment to print to MsgArea
  vim.api.nvim_buf_clear_namespace(bufnr, 1, 0, -1)
end

vim.cmd [[ autocmd CursorHold * lua PrintDiagnostics() ]]
vim.cmd [[ autocmd CursorMoved * lua Clear() ]]

DEV Community: Cason Adams

When a Master Harnesses the Reins of a Wild Beast: Software Engineering in the Age of AI

The Anatomy of the Beast

The Reins: How a Master Takes Control

1. Invert the Grounding (Feed Invariants, Not Questions)

2. Deterministic Verification as the Bit and Bridle

3. Slice Before Synthesizing

Magnification: The Asymmetric Advantage

1. Zero Cognitive Fatigue on Mechanical Work

2. Parallel Hypothesis Testing

3. Eradicating the "Blank Page" Penalty

The Final Distinction

I Built a Pure-Zsh Prompt Engine That Renders in 0.6ms (Without Rust or C++)

1. The Core Performance Invariant: Zero Subshell Forks

2. Two-Phase Git Status Detection

Phase 1: Direct File System Read (0.07 ms)

Phase 2: Asynchronous Non-Blocking Worker via zle -F

3. Compile Once, Render in Microseconds

4. Replacing 1,600 Lines of Config with Declarative Arrays

5. Base16 First: Harmonious by Default

6. Real-World Benchmarks

7. Modern Terminal Integration (OSC Protocols)

Quickstart

Manual Setup

Takeaways

Curing Agent Approval Fatigue: Using a Local LLM Gatekeeper for Safe Shell Execution

The Architecture: Hybrid Defense in Depth

1. Tier 1: Sub-Millisecond Deterministic Trap

2. Tier 2: The Local Model Evaluator

Inside the Code: How Guard Intercepts Tool Calls

Handling Reasoning Models (<think> Stripping)

Defining "Safe": Principles of the Guard Prompt

Setting It Up in 2 Minutes

1. Add the Marketplace & Install Guard

2. Configure Your Settings: Delegate Approval to Guard

Why approvalMode: yolo?

Recommended Local Models

3. The Result

Summary

Ditch Oh-My-Zsh Bloat: How I Built zload for Sub-Millisecond Terminal Startup

The Problem with Oh-My-Zsh

Enter zload: 0.45 ms Warm Startup, 0 Subprocesses

How zload Replaces Oh-My-Zsh (Without Losing Your Plugins)

Before vs. After: .zshrc Migration

Before (Standard Oh-My-Zsh setup)

After (zload clean array setup)

Benchmark Comparison

Lazy-Loading Primitives

Pair with a Fast Pure-Zsh Prompt

Getting Started

Rho the next cli agent

The "Claude Mythos" Illusion: Innovation or Data Harvesting?

The Security Pretext

The Data Ingestion Engine

Why This Is Different

The Takeaway

Manjaro Linux MacBook Pro 14,1

Download Manjaro Linux

Burn iso image to usb drive

Boot Mac via drive

Getting WiFi working

Install

Post Install

auto fix WiFi

fix sound

Set keyboard backlighting

Simple vim / terminal color changing

Why?

Terminal setup

Vim setup

Result

Ditch iTerm for Alacritty and tmux

setting up terminal theme

alacritty-shell option 1

alacritty theme manual update option 2

setting up tmux

see it in action

Neovim LSP to replace VSCode

TLDR;

Setup

Phase 2: Asynchronous Non-Blocking Worker via `zle -F`

Handling Reasoning Models (`<think>` Stripping)

Why `approvalMode: yolo`?

Enter `zload`: 0.45 ms Warm Startup, 0 Subprocesses

How `zload` Replaces Oh-My-Zsh (Without Losing Your Plugins)

Before vs. After: `.zshrc` Migration

After (`zload` clean array setup)