Bug 227408

Summary: apropos(1) doesn't sort
Product: Base System Reporter: Edward Tomasz Napierala <trasz>
Component: binAssignee: Baptiste Daroussin <bapt>
Status: New ---    
Severity: Affects Only Me CC: yuripv
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description Edward Tomasz Napierala freebsd_committer 2018-04-10 07:42:18 UTC
It appears that apropos(1) fails to sort.  It kind of does, but in a funny way.  You can see it with "apropos -s 9 map", and look for eg "pmap" in the output.
Comment 1 Yuri Pankov 2018-10-05 22:30:19 UTC
That's interesting one.

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".

To sum it up, the proposal is to remove bits comparison from src/contrib/mandoc/mansearch.c:manpage_compare(), and let it sort in "first section, then alphabetically" order.
Comment 2 Edward Tomasz Napierala freebsd_committer 2021-04-05 15:44:41 UTC
This appears to be fixed now.