PR227408: apropos(1) doesn't sort

[yuripv]

Summary

mandoc is trying to be smart here applying what seems to be a "relevance" comparison depending on the "bits" described in mandoc.db.5 (which we don't ship, so src/contrib/mandoc/mandoc.db.5):

0x10: The name appears in a filename.
0x08: The name appears in a header line, i.e. in a .Dt or .TH macro.
0x04: The name is the first one in the title line, i.e. it
      appears in the first .Nm macro in the NAME section.
0x02: The name appears in any .Nm macro in the NAME section.
0x01: The name appears in an .Nm block in the SYNOPSIS section.

...so we sort first based on these "bits". Doing direct arithmetical comparison for bitfields doesn't seem to be correct, more so I'm not sure we should care about them at all -- first section, then alphabetically seems to be "just enough" for me, i.e. I don't see why the page not having relevant .Nm in the SYNOPSIS section would sort less than one containing it if the .Dt sorts otherwise, and that's what going to happen when doing "(bits1 - bits2) != 0".

Remove the "bits" comparison to make the apropos(1) output sorting meet common expectations. With the change, apropos -s9 map no longer puts pmap(9) in between vm_*(9) pages.

Not submitting this upstream as this is NOT a bug, rather a matter of preference and common expectations.

Test Plan

apropos -s9 map

[bapt]

First we should ship the said manpage :)

I think this is debattable, but I think upstream is opened enought to accept such change, you should anyway talk to them to see if that will remain a freebsd only patch or not :)

[yuripv]

In D17449#375264, @bapt wrote:

First we should ship the said manpage :)

I think this is debattable, but I think upstream is opened enought to accept such change, you should anyway talk to them to see if that will remain a freebsd only patch or not :)

OK, will do.

[yuripv]

In D17449#375265, @yuripv wrote:

In D17449#375264, @bapt wrote:

First we should ship the said manpage :)

I think this is debattable, but I think upstream is opened enought to accept such change, you should anyway talk to them to see if that will remain a freebsd only patch or not :)

OK, will do.

Got no reply from mandoc devel list (it happens sometimes). Let's go with this patch for now, and we can discuss it later with Ingo once he has more time to look into it, sounds good?

[yuripv]

There's a reply and action upstream, the patch integrated there is more complete (removing all "bits" stuff from mansearch), will use that one.