Read :border, not the dead :border_style key, when picking box glyphs#527
Merged
DROOdotFOO merged 1 commit intoJul 15, 2026
Merged
Conversation
A box declaring border: :rounded (or :double, :ascii) always rendered square corners. render_clipped_box checks :border to decide WHETHER to draw a border; the glyph-selection clause right below it read a different key, :border_style, to decide WHICH glyph set -- a key nothing in the codebase ever sets, so it silently fell back to :single every time. Same failure class as the divider background default: two names for one job, and the wrong one wins invisibly on a border that's already visible, so nobody noticed the corners were wrong shape. :border can also hold :bold or :dashed (documented variants with no glyph set in BorderRenderer) or, in principle, a stray value from somewhere unexpected -- normalize_border_variant/1 routes anything BorderRenderer doesn't have glyphs for to :single rather than letting BorderRenderer's own catch-all fall through to :none, whose horizontal run is a space (an invisible border, worse than a square one).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
`render_clipped_box/5` reads `:border` to decide whether to draw a border.
The very next clause, `render_box_with_border_option/6`, read a different
key -- `:border_style` -- to decide which glyph set. Nothing in the box
pipeline ever sets `:border_style`, so it always fell back to `:single`:
a box declaring `border: :rounded` rendered square corners regardless.
Same shape as the divider background default (#526) and the whole ADR-0029
catalog: two names doing one job, and the wrong one wins silently because
the failure only shows up once you're looking at the actual glyph.
`:border` can also legitimately hold `:bold`/`:dashed` (documented variants
with no glyph set in `BorderRenderer`) -- routed to `:single` rather than
falling through `BorderRenderer`'s own catch-all to `:none`, whose
horizontal run is a space (an invisible border, worse than a square one).
No test asserted a specific square-corner glyph; the two tests that touch
this path (`theme_handling_test.exs`, `demo_render_test.exs`) check
fg/bg/attrs and a regex that already matches both box-drawing sets.
Full suite: 4713/4715 -- the 2 failures are pre-existing env-leak/timing
flakes, present on master, unrelated.
Found, not fixed here (same audit, separate concern): the layout engine
nests a top-level-declared `:border` under `:attrs` (`engine.ex:464`) and
nothing lifts it back into `:style` before render -- a box whose variant is
declared outside the `:style` map renders no border at all. Flagging for a
follow-up.