Alacritty's input and rendering layer holds its oldest debt — 5 functions to fix first

A cyclomatic-complexity-150 glyph rasterizer in Alacritty's renderer has sat unchanged for 269 days, heading a list of five structurally risky functions concentrated in input handling and rendering.

Stephen Collins · September 16, 2026

oss rust refactoring code-health

Generated by hotspots · free & open source · find your own box_drawing

pip

$ pip install hotspots-cli

Activity Risk15.46Low

Hottest Functionbox_drawing

Hottest Filealacritty/src/renderer/text/builtin_font.rs

Antipatterns Detected

Run this on your own codebase

See if your own repo has a box_drawing-style hotspot — run this in any local git repo:

pip

$ pip install hotspots-cli

npm

$ npm install -g @stephencollinstech/hotspots

Run in any repo

$ hotspots analyze .

★ Star on GitHub

Key Points

What is a god function and why does it matter in alacritty?

A god function is one that has grown to handle far too many responsibilities, usually visible as very high cyclomatic complexity combined with a large fan-out — the count of distinct other functions it calls directly. Alacritty's scan flags 5 functions with this pattern, including `execute` in `alacritty/src/input/mod.rs` with a cyclomatic complexity of 173 and a fan-out of 57, and `box_drawing` with a cyclomatic complexity of 150. The problem is practical: a function dispatching to 57 different callees is hard to unit test in isolation, and every new feature that needs to plug into that dispatch point adds one more branch to an already sprawling match statement.

How do I reduce cyclomatic complexity in Rust?

The standard technique is extract-method: pull self-contained match arms or branch bodies out into their own named functions, keeping the outer function as a thin dispatcher. A cyclomatic complexity above 15 is worth flagging for review, and anything above 30 — like `execute` at 173 or `box_drawing` at 150 in this scan — warrants breaking up before the next feature touches it. A concrete first step for `execute` in `alacritty/src/input/mod.rs`: split the `Vi(...)` sub-action arms into a dedicated `execute_vi_action` function, immediately removing a large chunk of the 173-path complexity from the main match without changing any behavior.

Is alacritty actively maintained?

The scan itself can't answer that directly, but it does show where structural risk is concentrated versus where recent editing is happening. All five of the highest-risk functions — including `box_drawing`, untouched for 269 days with zero touches in the last 30 days, and `regex_search_internal`, untouched for 462 days with zero touches in the last 30 days — fall in the debt quadrant: complex, but not being edited right now. The one function that is both complex and recently edited, `motion` in `vi_mode.rs`, sits in the fire quadrant with 1 touch in the last 30 days and only 14 days since its last change. That split suggests any active work is happening elsewhere in the codebase, while these five debt-quadrant functions sit untouched until their next necessary change.

How do I reproduce this analysis?

The scan was run against alacritty/alacritty at commit d692748 using the open-source hotspots CLI on GitHub. After checking out that commit with `git checkout d692748`, run `hotspots analyze . --mode snapshot --explain-patterns --force`. The same command runs against any local git repository with no configuration required.

What does activity-weighted risk mean?

The activity-weighted risk score combines structural complexity — cyclomatic complexity, nesting depth, and fan-out — with recent commit frequency, so functions that are both hard to understand and actively changing score highest. In this scan, that combination is rare: only `motion` in `vi_mode.rs` sits in the fire quadrant with an activity-weighted risk score of 9.67, while `box_drawing`, despite a cyclomatic complexity of 150, scores 15.46 even with zero touches in the last 30 days and 269 days since its last change. The scoring is deliberate — a complex function nobody is editing poses less near-term regression risk than a simpler function under constant change, so this ranking points teams toward where a bug is more likely to be introduced next, not just where the code looks the most tangled on paper.

Across 1,174 analyzed functions in alacritty/alacritty, 48 land in the critical band, and the top five share one pattern: high structural complexity paired with almost no recent change activity. The worst offender, box_drawing in the text renderer, carries a cyclomatic complexity of 150 and hasn’t been modified in 269 days — not a live regression risk, but a time bomb sitting in the box-drawing glyph rasterizer, waiting to detonate on whoever touches it next. I’d treat this list as a debt inventory to work through before the next big feature push touches these files, not a fire drill.

The table below ranks functions by activity-weighted risk — a score that multiplies structural complexity by recent commit frequency. A function that is both hard to understand (high cyclomatic complexity) and actively changing is a higher priority than one that is complex but untouched. CC = cyclomatic complexity (independent execution paths); ND = max nesting depth; FO = fan-out (distinct callees).

Top 5 Hotspots

Function	File	Risk	CC	ND	FO
`box_drawing`	alacritty/src/renderer/text/builtin_font.rs	15.5	150	4	21
`handle_event`	alacritty/src/event.rs	14.5	101	5	36
`key_input`	alacritty/src/input/keyboard.rs	13.1	22	2	25
`regex_search_internal`	alacritty_terminal/src/term/search.rs	12.8	27	6	16
`execute`	alacritty/src/input/mod.rs	12.6	173	3	57

The quadrant split tells the real story here: 203 functions sit in the debt quadrant against a single function in the fire quadrant. Alacritty’s structural risk is overwhelmingly dormant-but-complex, not actively churning. That single fire-quadrant function, motion in alacritty_terminal/src/vi_mode.rs, carries an activity-weighted risk score of 9.67 with 1 touch in the last 30 days and a cyclomatic complexity of 53 — worth a mention because it’s the one place in this dataset where complexity and live editing overlap, but it didn’t make the top five and isn’t a top-priority item today.

All five of my top hotspots score in the debt quadrant. Each is complex enough to be dangerous whenever someone next has to modify it, but none are being actively edited right now. I’m framing each one below by its blast radius, not its churn.

`box_drawing` — alacritty/src/renderer/text/builtin_font.rs

This is the top-ranked function in the whole scan, and the numbers explain why. A cyclomatic complexity of 150 against a max nesting depth of 4 and fan-out of 21 puts it solidly in ‘god function’ territory — the source excerpt confirms it: a match over character ranges (diagonal box-drawing glyphs like ╱, ╲, ╳) that branches into per-character canvas construction, followed by a second large match handling dash and gap variants, each with its own local closures for line-drawing math. It hasn’t been touched in 269 days and saw zero commits in the last 30 days, with only 6 total commits and zero linked bug fixes on record — this reads as maintainability debt rather than a known-defective area. The risk isn’t that it’s buggy today; it’s that the next person who has to add a new box-drawing character or fix a rendering edge case has to hold 150 branches of glyph-specific geometry in their head at once. I’d extract each character-family branch (diagonals, dashes, rounded corners, etc.) into its own named function before the next glyph gets added here.

`handle_event` — alacritty/src/event.rs

Cyclomatic complexity of 101, nesting depth of 5, and a fan-out of 36 make this the broadest-reaching function in the set. The excerpt shows a nested match over WinitEvent and then EventType — cursor blink timeout handling, bell command spawning, clipboard store and load, title updates, color requests — each branch touching a different subsystem through self.ctx. That fan-out of 36 distinct calls means a change to any one event type risks rippling into display state, PTY writes, or clipboard handling elsewhere in the file. It’s been dormant for 179 days, but the file’s history shows a bug-fix rate of 26.7% and one prior revert across 15 total commits, plus a review-comment density of 7.875 — meaningfully higher scrutiny than the other functions here, suggesting reviewers have already flagged this area as tricky. I’d start by splitting the terminal-event branch out of the top-level match into its own handler function; it’s the largest single arm and self-contained enough to extract without touching the winit-level dispatch.

`key_input` — alacritty/src/input/keyboard.rs

Lower nesting (2) and moderate complexity (22) compared to the others, but a fan-out of 25 and a string of early returns — IME preedit check, key-release short-circuit, hint-selection loop, inline-search capture, key-binding dispatch, search-input loop, vi-mode guard — each exiting the function before reaching the final byte-writing logic. That’s the ‘exit-heavy’ pattern showing up directly in the excerpt: seven distinct early-return points before the main input path runs, meaning seven separate conditions a test suite has to cover to reach full path coverage. It hasn’t changed in 288 days, the longest gap in the top five, and the file carries a bug-fix rate of 50% across 10 commits with one prior revert — half of this function’s history has been fix-related, which raises the stakes on any future change here even though nothing recent points to an active author working on it. I’d consolidate the early-return guards into a single ordered predicate chain or a should_handle_as_text helper, cutting the exit count without touching the byte-construction logic at the bottom.

`regex_search_internal` — alacritty_terminal/src/term/search.rs

The nesting depth of 6 stands out here — the deepest in the top five — and the excerpt shows why: a DFA-driven search loop with a macro_rules! state-reset block, byte-order branching for search direction, and inner per-byte match arms checking match and dead states, all inside an outer labeled loop ('outer: loop). This is Rust’s ownership and lifetime machinery layered on top of already-deep control flow — the borrow of regex.cache and regex.dfa across mutable state transitions makes this harder to safely refactor than the complexity number alone suggests. It’s gone 462 days without a change, the longest dormancy in the set, on a file with only 3 total commits and no linked bug fixes, so there’s no historical defect signal pointing at this function specifically — it’s complexity that has simply never needed to be touched. If it does need to change, I’d budget time to extract the reset-and-rescan logic out of the macro into a standalone method first, since debugging a macro_rules!-driven state machine six levels deep is its own tax on anyone unfamiliar with it.

`execute` — alacritty/src/input/mod.rs

This is the largest function by raw complexity in the entire dataset — cyclomatic complexity of 173, fan-out of 57 — even though its nesting depth (3) is the shallowest of the top five. The excerpt shows why: a single flat match over the Action enum, one arm per action variant (Esc, Command, Hint, ToggleViMode, ViMotion, and a long run of Vi(...) sub-actions for selection toggling and search navigation), each arm calling out to a different context method. That’s the textbook ‘god function’ shape — not deeply nested, just enormously wide, dispatching to 57 distinct callees. Any new key action or vi-mode command has to be added here, so this function’s blast radius grows with every feature the project adds to its action model. It’s been untouched for 467 days, the file’s history includes one revert across 11 commits, and a bug-fix rate of 27.3%. Given how mechanically uniform the match arms are, this is a strong candidate for splitting into per-category dispatch functions — one for Vi actions, one for Mouse or Search actions, one for everything else — reducing the fan-out per function without changing behavior.

Patterns Found

Antipatterns detected across the top functions in this snapshot:

Pattern	Occurrences
`long_function`	6
`god_function`	5
`stale_complex`	4
`complex_branching`	3
`exit_heavy`	2
`deeply_nested`	2

These labels belong to two tiers — Tier 1 (structural): complex_branching, deeply_nested, exit_heavy, long_function, god_function. Tier 2 (relational/temporal): hub_function, cyclic_hub, middle_man, neighbor_risk, stale_complex, churn_magnet, shotgun_target, volatile_god.

See more analyses with these patterns: complex_branching, deeply_nested, exit_heavy, god_function, long_function, stale_complex.

Reproduce This Analysis

git clone https://github.com/alacritty/alacritty
cd alacritty
git checkout d692748d3f61253ebe9f5094320120d22f6a046f
hotspots analyze . --mode snapshot --explain-patterns --force

To run the same analysis on your own codebase, run hotspots analyze . --mode snapshot in any local git repo — no configuration required.

I use Hotspots to highlight structural and activity risk — not “bad code.” I treat these findings as a prioritization aid, not a bug predictor. Editorial policy →

Was this useful? Let me know →