I opened an issue in which I used 72 as the wrapping width for the body, following CONTRIBUTING.md, but rad issue show forces wrapping at 60 without reflowing. This caused paragraphs to be chopped-up and harder to read, and this caused lines in ordered-list blocks to be truncated with … which omitted some of the contents making it impossible to read.

I think the …-truncation should not be applied just because some text is in a list-point block, whereas that doesn’t occur for text that is not in such blocks but still does exceed the width of 60.

While I’m happy to follow the width (and all other) conventions when contributing to Radicle, I personally, and I imagine other developers / customers, will want to use a greater width for their own projects.

I imagine others would appreciate if the Radicle tools could reflow content according to a personally-chosen width value. I understand if this isn’t a priority.

For the near-term, might it be easier to enhance the code to use a width variable gotten from the environment or settings? This way, when contents are wider, the user can choose how much of their terminal width they’d like to be allowed to be used, and, for extra-wide contents, could increase a terminal’s width and their variable. This would not require a “reflowing” capability.