Revert \(bu to \[ci] change

[deivid-rodriguez]

This reverts commit e7df1f0, reversing changes made to c3fd67e.

Commit was introduced as a aesthetic change when using -Kutf8 -Tutf8 in rtomayko/ronn#71, which closed ronn issue rtomayko/ronn#70.

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.

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 :)

[apjanke]

Based on reading this PR and the linked upstream issues, I think your change here is probably the right thing to do. But I'm going to have to do a little reading on troff's handling of UTF8 vs. ASCII and the bullet markers before I'll be comfortable merging it.

How urgent is this for you? Unfortunately I have a lot on my plate at the day job this week.

[deivid-rodriguez]

Not urgent at all, take your time :)

[deivid-rodriguez]

I rebased this PR for you so it's ready to merge once you review it.

[apjanke]

Thank you!

[apjanke]

Can you give me the TL;DR on how to run ronn and troff on your .ronn file to reproduce your issue with the bullets, so I can see it in action myself?

[apjanke]

Note to self:

References:

• groff_char man page
• groff man page - see "Special Characters" section

[apjanke]

Okay, I've read through all the linked pages and the groff/troff man pages enough to understand what's going on here. I don't think upstream's change of \[bu] to \[ci] was the right thing to do in the first place; that sounds to me more like a user unhappy with their font and terminal configuration, and not an issue with ronn itself. I think "bullet" is a more appropriate character for bulleted lists than "circle".

The fact that the \[ci] change never made it in to a versioned Ronn release gives me a strong presumption in favor of reverting that change in Ronn-NG: It is my intention that Ronn-NG serve as an easy drop-in replacement for the original Ronn. And especially so when I have an actual user complaint about it.

Merging. This will go out in the Ronn-NG 0.10.0 release, which will probably happen in the next couple weeks.

If you encounter any other issues using Ronn-NG as a drop-in replacement for classic Ronn, feel free to let me know, and I'll address those too.

[deivid-rodriguez]

Thank you!

[deivid-rodriguez]

@apjanke First, sorry I never replied to this:

Can you give me the TL;DR on how to run ronn and troff on your .ronn file to reproduce your issue with the bullets, so I can see it in action myself?

To try this against bundler you need to:

• Clone the https://github.com/rubygems/rubygems repo.
• Checkout this branch.
• Run gem install ronn-ng.
• Run bin/rake man:build.

Then the man pages in the man/ folder should be built using ronn-ng.

Note that the differences created by ronn-ng in the docs are already committed to the branch, including the \[ci] vs \(bu discrepancy.

[deivid-rodriguez]

Second, any news on the 0.10.0 release?

[apjanke]

Second, any news on the 0.10.0 release?

Work has let up a bit now, so I should be able to pull in all the outstanding PRs and assemble an 0.10.0 release over this weekend; figure on seeing it Monday.

[deivid-rodriguez]

Thanks a lot @apjanke!

[apjanke]

Work got me after all last weekend. This weekend...

[deivid-rodriguez]

Just checking in here in case there's any movement?

[apjanke]

Sorry for the delay on this!

I'm calling the current state of master as ready for the 0.10.0 release. I have tagged a 0.10.0-beta1 release which includes this fix, and published it to RubyGems as version 0.10.0-SNAPSHOT. Are you up for giving this a test? If no issues are found, I will release this as version 0.10.0 tomorrow.

[deivid-rodriguez]

Thanks, let me try this now!

[deivid-rodriguez]

Everything seems almost ready now for us to migrate. All changes are avoid some unnecessary blank lines and some unnecessary escaping which I don't think cause any changes in how the final output renders. See rubygems/rubygems@b275f4e.

Only issue is in bundle config SYNOPSIS, where we get the following changes:

-\fBbundle config\fR [list|get|set|unset] [\fIname\fR [\fIvalue\fR]]
-.
+.TS
+allbox;
+\fBbundle config\fR [list	get	set	unset] [\fIname\fR [\fIvalue\fR]]
+.TE

which make the synopsis display as empty.

[apjanke]

Ack. That's bad enough it should be fixed before pushing out a release. I'll look in to it.

[simi]

@apjanke any plans for new stable release? Anything I can help with?

[apjanke]

Hi, @simi,

Yeah, I think I've got a set of changes ready to go out for an 0.10 release, which I think. will address this issue? Details and "dev journal" are in #103. Work is on the Let's go, Pikachu! 0.10 branch.

Basic problem here is that I have no idea what the fuck I'm doing here. I don't really know what the Ruby 2.x to 3.x transition means, especially in terms of how downstream packagers consume Ronn-NG or express dependencies, and I'm having trouble just getting it built and running on my dev boxes.

Any input or advice you have here is welcome.