freebsd
cdefs(9): Start to document what sys/cdefs.h does
Start to trudge through documenting cdefs.h.
Creating a github pull request as an experiment. I'll land this when it's ready.
Also, I know there's all kinds of things in cdefs.h not yet documented. I'm struggling to find good orgnaization.
Also, this is mostly a developer facing doc, not a user-facing document, as such.
OK. I'm down to the ISOC / POSIX namespace selector portion of cdefs.h. Not al the functions are filled in. It's clear we have duplicated functionality, we need to reorg this file, update comments, etc. But at least everything is listed and some have descriptions. And at least 2 more things can be deleted from cdefs.h, I think, after some careful analysis (though maybe these need an exp run? Unlikely, but close to maybe).
Thank you for inviting me.
I've began to learn about "gh pr checkout 1313", but now I want to "git push" or similar?
Thank you for inviting me.
I've began to learn about "gh pr checkout 1313", but now I want to "git push" or similar?
I'm looking more for comments in general. If there's a lot you want to do, then I'm not sure how to proceed... maybe I'll get the outline and most things in and you could revise if that's what you want or think is fastest.
Add Macro in ND Nocaps beginning ND Pp after tables within same subsection No dot macros in width/offset args
Thanks again, this is awesome.
Add Macro in ND Nocaps beginning ND Pp after tables within same subsection No dot macros in width/offset args
OK... I think I'm going to need this shorthand explained a smidge more. i'm not sure what ND is, and I'm not sure about width/offset args thing. The .Pp I think I can handle...
Thanks for the feedback... I've wanted to do this for a long time, and I've wanted to reorg cdefs.h to match the organization in the man page. Right now it's a free-for-all that's hard to read, edit or understand.
and you could revise if that's what you want or think is fastest.
I was thinking/hoping for a command similar to git push that applies the diff as suggestions.
and you could revise if that's what you want or think is fastest.
I was thinking/hoping for a command similar to
git pushthat applies the diff as suggestions.
Don't I wish. Please tell me if you find one.
For now, I'll make the suggested changes, but may push it in incomplete to allow others to try their hand at a pull request :)
I was thinking/hoping for a command similar to
git pushthat applies the diff as suggestions.Don't I wish. Please tell me if you find one.
I found this issue request. I want to say "The FreeBSD Project also wants to do this", which is true and meaningful but I don't think it's appropriate for me.
https://github.com/cli/cli/issues/5905
OK. 100% through cdefs.h adding at least sub entries for everything... Now to document the approximately 50 that I've left empty...
I'm debating committing in the unfinished state... But I'd like at least what's done to be good...
I've applied everything (or commented that I was doing things a different way) and force pushed a new version due to rebase (though that doesn't affect the diff). Thanks for the comments so far.
We should consider the 'discoverability' of this document, i.e. which existing pages should link to it. A top-level comment in the header itself pointing here would be warranted; future changes to the file should be reflected here.
I'm open to how to do this. It's targeted mostly at the developer community.....
OK. Looked at @mhorne changes and @concussious I think I've got it all in. GH's interface is getting a bit overloaded at this point...
Thanks again for inviting me! I'll keep working on it... but I like traditional bsd collaborative culture where this is your project, you do one commit, take all principal credit before all mankind, no commit log clutter, whole world benefits, but individual retains their power and agency.
OK. I've pushed this. The time for comment has drawn to a close. Though improvements through pull requests, etc are now fair game.
Thanks again for inviting me! I'll keep working on it... but I like traditional bsd collaborative culture where this is your project, you do one commit, take all principal credit before all mankind, no commit log clutter, whole world benefits, but individual retains their power and agency.
huh?
I'll keep working on it... but
huh?
Fixing it in review feels like I'm purely helping, but fixing it in another PR later feels like I'm cluttering the commit log and stealing credit.