mandoc.db(5) names.bits
Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 06:34:45AM -0700: CVSROOT: /cvs Module name: src Changes by: j...@cvs.openbsd.org2014/11/20 06:34:45 Modified files: lib/libevent : Makefile Log message: put MLINKS in the order they appear in the man page, so i don;t go blind trying to check what's missing; No objection whatsoever, keeping the Makefiles clean is always good. Just mentioning a different approach in case anybody is interested - this got more powerful with some of my latest commits and is partly documented in mandoc.db(5): $ cd /usr/src/lib/libevent/ $ make cleandir $ cvs up -dP $ make obj $ make depend $ make $ sudo make install $ sudo makewhatis /usr/share/man $ alias qm='sqlite3 /usr/share/man/mandoc.db' # query mandoc.db $ qm 'select * from names where name=evbuffer_new;' 30|evbuffer_new|878 $ qm 'select * from names where pageid=878 and bits!=18;' 30|evbuffer_new|878 $ qm 'select * from names where name=event;' 16|event|877 $ qm 'select * from names where pageid=877 and bits!=18;' 16|event|877 30|event_init|877 Looks good now. The bits from /usr/src/usr.bin/mandoc/mansearch.h in the order of decreasing precedence for the new man(1) are: 16 file name (only this one is used by the old man(1)) 8 page header line (from the .Dt macro) 4 first .Nm entry in the NAME section 2 any .Nm entry in the NAME section 1 any .Nm entry in the SYNOPSIS section Right now, .Fo and .Fn in the SYNOPSIS do not yet set bit 1, but that's on my todo list. So, consistent values are: 31 (Christmas tree) for the primary page name 19 (= ~(8+4))for secondary page names Anything else is suspicious. This already works quite well for mdoc(7) pages. Regarding man(7) and cat pages, there are still some items on my todo list. Yours, Ingo
Re: mandoc.db(5) names.bits
On Thu, Nov 20, 2014 at 03:51:36PM +0100, Ingo Schwarze wrote: Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 06:34:45AM -0700: CVSROOT:/cvs Module name:src Changes by: j...@cvs.openbsd.org2014/11/20 06:34:45 Modified files: lib/libevent : Makefile Log message: put MLINKS in the order they appear in the man page, so i don;t go blind trying to check what's missing; No objection whatsoever, keeping the Makefiles clean is always good. Just mentioning a different approach in case anybody is interested - this got more powerful with some of my latest commits and is partly documented in mandoc.db(5): $ cd /usr/src/lib/libevent/ $ make cleandir $ cvs up -dP $ make obj $ make depend $ make $ sudo make install $ sudo makewhatis /usr/share/man $ alias qm='sqlite3 /usr/share/man/mandoc.db' # query mandoc.db $ qm 'select * from names where name=evbuffer_new;' 30|evbuffer_new|878 $ qm 'select * from names where pageid=878 and bits!=18;' 30|evbuffer_new|878 $ qm 'select * from names where name=event;' 16|event|877 $ qm 'select * from names where pageid=877 and bits!=18;' 16|event|877 30|event_init|877 Looks good now. The bits from /usr/src/usr.bin/mandoc/mansearch.h in the order of decreasing precedence for the new man(1) are: 16 file name (only this one is used by the old man(1)) 8 page header line (from the .Dt macro) 4 first .Nm entry in the NAME section 2 any .Nm entry in the NAME section 1 any .Nm entry in the SYNOPSIS section Right now, .Fo and .Fn in the SYNOPSIS do not yet set bit 1, but that's on my todo list. So, consistent values are: 31 (Christmas tree) for the primary page name 19 (= ~(8+4))for secondary page names Anything else is suspicious. This already works quite well for mdoc(7) pages. Regarding man(7) and cat pages, there are still some items on my todo list. Yours, Ingo better still, you had a diff that made MLINKS redundant. that's what i want. jmc
Re: mandoc.db(5) names.bits
Hi Jason, Jason McIntyre wrote on Thu, Nov 20, 2014 at 03:00:49PM +0001: better still, you had a diff that made MLINKS redundant. that's what i want. Jajaja! :-) But before i can put that in, i want to check off the list of things that i already know might go wrong. I don't want people ending up with not getting shown the pages they request, or being shown pages they don't request. Once the old man(1) is gone, that would really be inconvenient. After my list becomes empty, we still need a public testing phase, and not too close to release. So i think it won't make 5.7. What i have shown here is part of the way to get there, though. Yours, Ingo
