-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
more -i is not portable #71
Comments
This was introduced in f528c25. Looks like I did not do my portability research: on macOS, Thanks for all the bug reports, by the way! |
Fixed in 33b8f54. This will go out in the 0.10 release. |
Just for the time travelers from the future who will also hit this before 0.10 is released, the workaround is to set the PAGER or the MANPAGER environment variable to
|
This reverts commit e7df1f0, reversing changes made to c3fd67e. Commit was introduce as a aesthetic change when using `-Kutf8 -Tutf8`. Quoting from the issue that led to the PR: > This may seem a little strange, it's more aesthetic then anything > else. When troff is run with -Kutf8 -Tutf8 to ensure that utf8 > characters appear correctly then the bullets generated by \(bu appear as > small squares (I'm using 13pt Pragmata Pro). However, in `bundler` we're not using `-Tutf8`, but `-Tascii`, and this results in weird characters for list items as reported [here](cli-kit/cli-command#78). Since this change never made it into any `ronn` release, I think reverting it could encourage adoption of `ronn-ng` as a drop-in replacement of `ronn`. At least for us :)
ronn has:
However,
more -i
does not work on my Debian buster system:And therefore,
ronn -m
fails out of the box.The text was updated successfully, but these errors were encountered: