fix: Keep the markdown pipeline ASCII in plain view - #30
Merged
Conversation
#7 made the issue view's own decorations ASCII in plain mode, but plain output isn't printed from Issue.String() — it goes through glamour, and descriptions and comments from Jira cloud go through the ADF translator first. Both layers add non-ASCII of their own, so `LC_ALL=C jira issue view --plain` still emitted characters the locale can't represent. Three sources, all decorations the tool adds around issue data: - glamour's `notty` style prefixes list items with a bullet and suffixes image alt text with an arrow. Its `ascii` style is a byte-for-byte copy of `notty`, so switching styles doesn't help; plain view now builds the style itself and overrides those two. - the ADF translator marks inline cards with a pin emoji. - the ADF translator replaces `<` and `>` with lookalike glyphs, because the markdown renderer would otherwise eat them as an HTML tag. In ASCII mode we backslash-escape instead, which renders as the original character — so `--plain` output can now be grepped for `<foo>`. Code blocks and inline code are left alone, since the renderer prints those verbatim and an escape would show up as a literal backslash. Non-plain output is unchanged: the ADF translator only drops to ASCII when the view asks it to, which it does when Display.Plain is set. What's left in plain output is the issue text itself — if someone typed a curly apostrophe into a description, it still prints. Transliterating user content is a separate decision from not decorating it. Addresses ankitpokhrel#213.
Render() already routed dumb terminals and pipes through renderPlain, but only the glamour style followed: the header and the ADF translator branch on Display.Plain, which is set solely by the --plain flag. Piping without the flag thus mixed ASCII bullets with emoji headers and Unicode ADF decorations. Setting the flag on the (value) receiver before rendering makes every layer agree. Also pin the one leak the renderer can't avoid: glamour truncates a table cell's link URL with a hardcoded ellipsis (ansi/table_links.go), out of reach of the style config. The new test documents it as a known issue and will flag when a glamour upgrade changes the behavior. Getting the leak to reproduce needs a real table — the ADF translator only writes pipes between cells, so a one-column table is never parsed as one.
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.
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 --plainstill emitted characters the locale can't represent, because plain output is not printed straight fromIssue.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:
nottystyle prefixes list items with•and suffixes image alt text with→. Itsasciistyle is a byte-for-byte copy ofnotty, so asking for that style instead does nothing — plain view now builds the style itself and overrides those two fields.<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.Plainis set.Checked against real issues in a
LC_ALL=Cshell: 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.