Threading rod bevels do not default to false, so fix docs

[coryrc]

The actual logic is more complicated. Change all the docs for rods to reference "generic_threaded_rod" and explain how the logic actually works.

I did not look at nuts.

[coryrc]

OTOH since beveling doesn't affect the threads of blunt start, it's almost certainly a better default to make them consistent, so maybe the default should be considered the same as "true" instead?

This would change the angle and length of existing code which doesn't set bevel though:

square_threaded_rod(d=19,l=15.6,pitch=4);

Current:

Assume bevel==undef means bevel==true:

Happy to make that change instead, if you want.

[adrianVmariano]

I am uncertain about whether changing the default to bevel blunt start threaded rods is the right thing to do. Beveling does affect the threads of blunt start. The amount of threading is decreased to make space for the bevel, so you lose some thread, and possibly some engagement when beveling is turned on. I think that's why in the docs beveling is primarily identified as an alternative to blunt start.

For fixing the docs, I think it would be better to repeat the correct explanation every time instead of sending the user off to generic_threaded_rod. The text is not so long that it can't be repeated, and it's a nuisance for the user to have to go find the other function and then find the entry for bevel in the lengthy arg list.

You might want to consider discussing this kind of updates in the dev chat before going to the trouble to create a PR so that your efforts are efficiently directed in a fashion we agree on.

The text "When not provided, bevels are disabled for blunt_start ends and enabled otherwise." should be something more like "Default: false for blunt start ends, true otherwise".

[coryrc]

I think it would be better to repeat the correct explanation every time

Will do.

"Default: false for blunt start ends, true otherwise".

This is a little confusing when one end is blunt and the other isn't in the context of the bevel= argument. But I can't come up with something less ambiguous that isn't much wordier. Will change.

[coryrc]

I am uncertain about whether changing the default to bevel blunt start threaded rods is the right thing to do.

For my thinking, I like the end of my bolts to be slightly beveled to reduce sharp edges and to make inserting easier. But it's easy to turn on, so it's not that big of a deal.

[adrianVmariano]

With blunt start, beveling the edges has no effect on ease of insertion, at least for the test printed bolt/nut combo I just fiddled with. They are not beveled and very easy to insert. I think it comes down to this: without blunt start, beveling is basically essential to avoid a knife-edge on the thread and to give you a chance of inserting without a lot of trouble. But blunt start fixes both issues. Beveling then becomes more like optional bevels on a cuboid or other object, hence it is consistent that it defaults to false.

Why did you change bevel1==undef to is_undef(bevel1)?

[coryrc]

Why did you change bevel1==undef to is_undef(bevel1)?

I initially thought the behaviour was wrong and that the undef check didn't actually work right, then I saw is_num() so shouldn't this also be is_undef()?

but now that I've read more, is_undef() is for if you're unsure the variable even exists, not that a known variable has a value of undef, so this should probably be reverted.

[adrianVmariano]

The change doesn't break anything. The test foo==undef will fail with an error when foo doesn't exist. The test is_undef(foo) always works.