fix: Respect --plain in issue view header - #7
Merged
Merged
Conversation
The header() rendering in issue view unconditionally embedded emoji glyphs regardless of Display.Plain, so `jira issue view --plain` still leaked emoji into piped/plain output. Other parts of the same view (separator, footer) already branch on Display.Plain; header() now follows the same pattern and uses plain ASCII labels instead of emoji when Plain is set.
The header was only one of the places that hard-coded non-ascii decorations. Subtasks, linked issues and comment metadata still separated their fields with a U+2022 bullet, and long summaries were truncated with a U+2026 ellipsis, so plain output was not ascii-only yet and still broke under LC_ALL=C. Plain mode now uses '|' as the field separator and '...' as the truncation marker. The ellipsis is measured in runes so both markers occupy the same column width and existing alignment is preserved. Non-plain output is unchanged.
shortenAndPad measured the message in bytes, so a multi-byte summary could be cut mid-rune and produce invalid UTF-8. Measure both the message and the ellipsis in runes. Also compute the emoji parent field only on the non-plain path of header(), where it is actually used.
rethab
added a commit
that referenced
this pull request
Jul 12, 2026
Follow-up to #7, which made the issue view's own decorations ASCII in plain mode but left the layers underneath it alone. `LC_ALL=C jira issue view --plain` still emitted characters the locale can't represent, because plain output is not printed straight from `Issue.String()`: it is rendered by glamour, and on Jira cloud the description and comments are translated from ADF before that. Both layers decorate. Three sources, all of them markup the tool adds around issue data: - glamour's `notty` style prefixes list items with `•` and suffixes image alt text with `→`. Its `ascii` style is a byte-for-byte copy of `notty`, so asking for that style instead does nothing — plain view now builds the style itself and overrides those two fields. - the ADF translator marks inline cards with 📍. - the ADF translator swaps `<` and `>` for the lookalikes `❬`/`❭`, because the markdown renderer would otherwise consume them as an HTML tag and drop the text. In ASCII mode it backslash-escapes them instead, which renders as the original character — so plain output can now be grepped for `<foo>`, which it couldn't before. Code blocks and inline code keep the raw brackets, since the renderer prints those verbatim and an escape would show up as a literal backslash. Non-plain output is byte-identical: the ADF translator only drops to ASCII when the view asks it to, which it does when `Display.Plain` is set. Checked against real issues in a `LC_ALL=C` shell: where the old binary emitted six bullets and an `❭`, the new one emits neither. What remains is the issue text itself — a curly apostrophe someone typed into a description still prints. Deciding whether to transliterate *content* is a different question from not decorating it, and I left it alone. Refs ankitpokhrel#213.
rethab
added a commit
that referenced
this pull request
Aug 5, 2026
`jira issue view --plain` (and non-TTY output that auto-detects plain mode) still leaked non-ASCII decorations into piped output. Parts of the view — `separator()` and `footer()` — already branch on `Display.Plain`, but the rest didn't. Plain output should be safe to pipe, grep, and render in a non-UTF-8 locale like `LC_ALL=C`, so no decoration the view adds around issue data may be non-ASCII. Two changes: - `header()` now follows the same pattern as the rest of the view: when `Display.Plain` is set it renders ASCII labels (`Type:`, `Status:`, `Assignee:`, …) instead of emoji-decorated fields. - The remaining decorations go ASCII in plain mode too: subtask, linked-issue, and comment fields are separated by `|` instead of `•`, and truncated summaries end in `...` instead of `…` (`shortenAndPad` now takes the ellipsis as a parameter and keeps the same column width either way, so alignment is unaffected). Non-plain output is unchanged. A new test asserts the plain issue view contains no non-ASCII characters at all, so future decorations can't silently regress this; a counterpart test pins that the non-plain view keeps its decorations. Addresses ankitpokhrel#213.
rethab
added a commit
that referenced
this pull request
Aug 5, 2026
Follow-up to #7, which made the issue view's own decorations ASCII in plain mode but left the layers underneath it alone. `LC_ALL=C jira issue view --plain` still emitted characters the locale can't represent, because plain output is not printed straight from `Issue.String()`: it is rendered by glamour, and on Jira cloud the description and comments are translated from ADF before that. Both layers decorate. Three sources, all of them markup the tool adds around issue data: - glamour's `notty` style prefixes list items with `•` and suffixes image alt text with `→`. Its `ascii` style is a byte-for-byte copy of `notty`, so asking for that style instead does nothing — plain view now builds the style itself and overrides those two fields. - the ADF translator marks inline cards with 📍. - the ADF translator swaps `<` and `>` for the lookalikes `❬`/`❭`, because the markdown renderer would otherwise consume them as an HTML tag and drop the text. In ASCII mode it backslash-escapes them instead, which renders as the original character — so plain output can now be grepped for `<foo>`, which it couldn't before. Code blocks and inline code keep the raw brackets, since the renderer prints those verbatim and an escape would show up as a literal backslash. Non-plain output is byte-identical: the ADF translator only drops to ASCII when the view asks it to, which it does when `Display.Plain` is set. Checked against real issues in a `LC_ALL=C` shell: where the old binary emitted six bullets and an `❭`, the new one emits neither. What remains is the issue text itself — a curly apostrophe someone typed into a description still prints. Deciding whether to transliterate *content* is a different question from not decorating it, and I left it alone. Refs ankitpokhrel#213.
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
1 participant
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.
jira issue view --plain(and non-TTY output that auto-detects plain mode) still leaked non-ASCII decorations into piped output. Parts of the view —separator()andfooter()— already branch onDisplay.Plain, but the rest didn't. Plain output should be safe to pipe, grep, and render in a non-UTF-8 locale likeLC_ALL=C, so no decoration the view adds around issue data may be non-ASCII.Two changes:
header()now follows the same pattern as the rest of the view: whenDisplay.Plainis set it renders ASCII labels (Type:,Status:,Assignee:, …) instead of emoji-decorated fields.|instead of•, and truncated summaries end in...instead of…(shortenAndPadnow takes the ellipsis as a parameter and keeps the same column width either way, so alignment is unaffected).Non-plain output is unchanged. A new test asserts the plain issue view contains no non-ASCII characters at all, so future decorations can't silently regress this; a counterpart test pins that the non-plain view keeps its decorations.
Addresses ankitpokhrel#213.