You have thrown out the baby with the bathwater.
Integrated, offline, semantically tagged documentation subsystem is better than your dependency-riddled, half baked webapp of the day.
And I'm going to to prove it.
You have thrown out the baby with the bathwater.
Integrated, offline, semantically tagged documentation subsystem is better than your dependency-riddled, half baked webapp of the day.
And I'm going to to prove it.
Are there kernconfs to compile the module? We also usually put that in synopsis.
Thank you
Nobody is pushing this until the content is verified.
Okay. Thanks for the better explanations.
I gave a talk on this, so, this is actually important to me. So, this is a very bad time to use "you're wrong because you're simply wrong".
If that is your consensus you should fix the FDP primer.
To be absolutely clear, here is where it is written in the FreeBSD Documentation Project Primer:
By "it is correct
I want you to not do this. It is correct as it is. Prose does not belong in synopsis.
Thanks Mark. With the time crunch I elected to increase the precision of the statement to answer one question, even though it doesn't answer all of them, as you said. I'm definitely interested in improving this more as SME availability increases!
I like what you did here of calling it a module continuously.
Pressing request changes because I gave a whole talk about how I want to get this out of the tree and have spent several months working on that.
We have a lot of different styles in use, and I think this one is a violation of the consistency patterns in the manual as a whole. I gave a talk about it at BSDCan '25. Here's a link youtu.be/RthIOXpwwsM
I would love this. This change should probably also revert the commit I just made to strip "device iwx" from iwx.4 synopsis so it's atomic.
In D53741#1227292, @0mp wrote:Seems fine but would upstream accept it? What do you think?
E610 support has been published on the 15.0R hardware release notes.
Expand prose based on Pau Ammas suggestion.
Can I do anything with this or push it? I want to have 15.0R not have a doc that says it's going to be removed in 5 years ago at the top.
@0mp this is how I was thinking we can solve this problem without boxing ourselves into a corner.
Copy ioctls and event from apm.4, tweaking very slightly so it looks
intentional, and re-aligning list widths as well for that effect.
Ping
You are very welcome and I appreciate your attention to this matter.
Would it fix it if we add a FILES section to acpi.4 showing the device
nodes?
Thanks pauamma! You've been really crushing it finding typos that I sincerely read over and didn't notice lately!
In D53290#1226634, @pauamma_gundo.com wrote:Perhaps something less judgemental than "criminal", like "misleading" or "incomplete"?
A huge motivator is I ask how to use controllers, and people point me to this:
I'm not sure what you mean by "Smooth criminal edition". Can you explain?
I suppose hgame_load is a variable, not a command.
Add something about devfs.rules. I don't actually know if any of this
is accurate because I don't have this working. So far, 0660ing
/dev/input/event* lets the applications I've tried see something is
plugged in, but the buttons don't work yet.
You should tag SPDX too while going this far.
Thanks Yogesh! I pushed the commit to main.