Width of heading separators too great, causing wrapping in RStudio

[torfason]

The width of the ─ character, when printed in RStudio console, is greater than the standard single width, causing the message to be wrapped, and thus not very neat. This applies at least to cli_h1() and cli_rule() on a Mac. Below are two representations of some output.

• First a screenshot, this shows the wrapping clearly:

• Then the actual text that got printed out, wrapped in code fences, compared to the same number of regular dashes. This seems to result in correct width when I view it in the browser:

── x ───────────────────────────────────────────────────────────────────────────
-- x ---------------------------------------------------------------------------

This is probably affected by the font that is in use, but I've tested it with Consolas, Inconsolata and Courier, and I always get this issue, making me thing that the glyph that is being used is not guaranteed to be standard-width even in fixed width fonts (although I found that it does work in some other fonts, such as Menlo). The issue seems closely related to #91.

I'm not sure what the most appropriate fix is. In the readme I don't see any emphasis on which typeface to use with cli, making me think that the intention is to be relatively agnostic about the typeface, but in this case it is quite sensitive to the font. If a better glyph is not available, should there be a prominent notice discussing which fonts have been tested and are supported?

[gaborcsardi]

I don't think that there is a better glyph, unfortunately. (But FIXME!) Box drawing characters have ambiguous width in Unicode. It seems to me that most modern terminals assume that they are single width, which is best for most people, except probably people working with East-Asian text.

E.g. in iterm2 there is a configuration switch for this, and by default they are narrow. In Rstudio it is font-dependent, as you say. FWIW some good modern fonts are fine, e.g. Menlo, Fira Code, Source Code Pro.

We can introduce an option to treat these characters as double width, but then you need to synchronize the option and the font, so it is not great.

You can also opt out of Unicode characters completely: options(cli.unicode = FALSE).

You are right that we should discuss this somewhere in the manual.

[torfason]

OK, I've switched to Menlo for now, not much of an issue, I just didn't realize it until now (it was actually pasting the example into the issue report that made me realize that this was a font issue – initially I thought it was a miscalculation of terminal width). Documentation would help, although many end-users will probably not even realize that they are using the cli package because they see the issue in messages from other packages.

But anyway, thanks for the cli package, it has made output much nicer overall I think :-)