Refactor use of glamour to allow style overrides#3243
Conversation
There was a problem hiding this comment.
This looks great from the code perspective, but something that I'm wondering about is whether this will degrade the experience in some existing view commands. In most of them, I don't think the margin mattered much, but I think that in issue view --comments the left margin that was the previous default might have actually improved readability.
|
Also, now that I think about it, I would prefer that code blocks are indented by default in markdown rendering. It resembles how they would usually be formatted in plain text documents such as man pages. Is there a way that removing indentation could be opt-in? |
|
@vilmibm ran this by me, and I thought removing indentation overall helped, but agree that codeblocks could be indented. On comments, I think removing indentation could help but I also think it could use some spacing cleanup between blocks of information if we do. |
|
thanks yall! I'll tweak this accordingly. |
|
I've rolled back the default indentation changes for now until we can be more thorough with them across the board; for now I've just made it possible to do what I want to do in |
4 participants
This PR gently augments
markdown.Render, overriding the margin settings that come default in theglamourstyles to remove all margins.This came about because I wanted
workflow viewto list yaml without 4 spaces of unneeded indentation and, after discovering thatglamourindeed supported cascading styles, decided I wanted to remove the excessive indentation from all of our markdown output.To see this in action, view any issue, PR, or gist. The leading 2-4 spaces will be gone from the markdown output.
Note that codeblocks in an issue body are now at the same indentation level as the surrounding text. I like this change, but if others don't I can re-add the margin for code blocks and then change my
workflow viewPR to one-off remove it again.Sample screenshot (first invocation is before, second is after):