20220327 WireGuard documentation

[Paraphraser]

Repairs broken internal hyperlinks by restoring internal anchors.

Restored anchors converted to null-anchor form.

Fixes some spacing and alignment errors (apparent in MacDown authoring tool).

Signed-off-by: Phill Kelley 34226495+Paraphraser@users.noreply.github.com

[ukkopahis]

Fixes some spacing and alignment errors (apparent in MacDown authoring tool).

Is this something that affects only your tool or also the resulting page? I can't seem to find anything wrong with https://sensorsiot.github.io/IOTstack/Containers/WireGuard/ in regards to your changes.

[Paraphraser]

Short answer: probably only the tool.

The tool (MacDown - side-by-side editor and renderer) adopts a fairly strict interpretation of the spec - although exactly which spec that is might be a bit challenging to pin down. Nevertheless, the experience of the last few years has taught me that paying careful attention to what MacDown shows me usually results less re-work to get the various rendering engines to "play nice" so I lean towards trusting it. Whether MacDown is "correct" in every situation…

On this occasion, what caught my attention was:

The subtle misalignment between the left hand edge of the "D" in "Do note" being slightly to the right of the first back-tick on the preceding line (and the "A" in the earlier para). It just jumped out at me. My first thought that there might be trailing invisibles after the back-ticks. Nope. Second thought was the lack of a blank line between the close-fence and follow-on para (not strictly needed, I know) but that didn't cure it either. The artifact only went away when I selected the para and did Command[, Command] to remove and re-apply the indentation.

Necessary? Probably not. Really just a reflex. Kinda similar to the change you might feel yourself wanting to make if you saw some C code like:

if (someCondition)
   doThis();
else
doThat();
doSomethingElse();

I know I'd feel the urge to indent the "doThat" to make it clear it was conditional execution. What about you? For me it would be a reflexive Command].

Although, since I started playing with Swift and got into the habit, I might be more inclined to add curly braces as well.

[ukkopahis]

• You've changed indentation from four spaces to a tab-character. (not visible, you have to do a selection to see it)
• You've removed line wrapping and made the whole paragraph one long line.

The point of markdown is to look nice both as pure text and when rendered, correct? When a normal text editor has to wrap long lines they don't look nice anymore.

This is even apparent how your editor handles long lines: Clearly the "IP address... "-line looks like it haven't been indented at all! This doesn't annoy you? But your editor showing tab and 4-space indent slightly differently is a big problem. Better to be really ugly than one random editor being off by a few pixels. Even though markdown specifications treat both as equivalent.

To continue on your example, to me it looks like you're writing:

if (someCondition) doThis(); else doThat(); doSomethingElse();

And telling me: "Well my editor does auto-formatting like that, so you must be wrong".