doc: use consistent markdown in README

[Trott]

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

Description of change

Changes include:

• consistent header indications
• wrap bare URLs in < and >
• consistent emphasis indications
• specifying a language in fenced code
• wrapping at 80 characters

Linting tool possibly on the way.

[Fishrock123]

[Trott]

I disagree, but I'm open to be persuaded. Bike shed time, I guess but here are the reasons:

• This is a shell command. It may be bash. Or it maybe csh or zsh or tcsh or even Windows PowerShell. There is nothing bash-specific about curl.
• If shell is not more appropriate than bash here, then when would it ever be more appropriate?
• This is more of an argument that it doesn't matter than that one or the other is right, but bash is an alias for shell in the syntax highlighting tool used by GitHub Flavored Markdown so there is no difference in the rendered output of one versus the other.

[Fishrock123]

¯_(ツ)_/¯

[ChALkeR]

This should be either «```console» or commands should not start with «$».

[Trott]

Done.

[ChALkeR]

ditto

This either shouldn't be «```console» or the lines should start with a prompt like «$ » or «> ».
Or this is going to be formatted like text output.

I would just use sh or shell here (in this specific block), perhaps.

One issue with a code block language specification (console → shell), everything else LGTM.

@ChALkeR Switched that one instance to shell. Thanks.

@Trott Ah, noticed one more thing.

$ gpg --keyserver pool.sks-keyservers.net \
  --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

is inaccurate and gets wrong highlight.

It should be either shell without the $ to allow copy-pasting the whole thing:

gpg --keyserver pool.sks-keyservers.net \
  --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

or console with a > on the second line to depicture the actual console behaviour and serve as an example:

$ gpg --keyserver pool.sks-keyservers.net \
>  --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D

@ChALkeR I suppose another option is just to get rid of the line break and have it be a single line by itself. Does that work for you?

@Trott Yes, it does, it doesn't break the maximum-line-length rule.

It does break a guideline rule regarding the sources code style, but there is no other way to achieve a similar display and this looks like a valid reason for an exception. We already have those in other places (long links, for example).

LGTM.

LGTM

LGTM!

Landed in cc3a9e7!