docs: some nitpicks

- replaced double spaces with single space where applicable
- replaced "favourite" with "favorite"
- added language identifiers to code blocks in markdown files
- added extra line after code blocks and after headings in markdown
  files

Cloes #20748

docs/internals/BUFQ.md

@@ -14,7 +14,7 @@ to and read from. It manages read and write positions and has a maximum size.
 Its basic read/write functions have a similar signature and return code
 handling as many internal curl read and write ones.
 
-```
+```c
 ssize_t Curl_bufq_write(struct bufq *q, const unsigned char *buf, size_t len, CURLcode *err);
 
 - returns the length written into `q` or -1 on error.
@@ -29,7 +29,7 @@ ssize_t Curl_bufq_read(struct bufq *q, unsigned char *buf, size_t len, CURLcode
 
 To pass data into a `bufq` without an extra copy, read callbacks can be used.
 
-```
+```c
 typedef ssize_t Curl_bufq_reader(void *reader_ctx, unsigned char *buf, size_t len,
                                  CURLcode *err);
 
@@ -45,7 +45,7 @@ once or only read in a maximum amount of bytes.
 
 The analog mechanism for write out buffer data is:
 
-```
+```c
 typedef ssize_t Curl_bufq_writer(void *writer_ctx, const unsigned char *buf, size_t len,
                                  CURLcode *err);
 
@@ -60,7 +60,7 @@ remove the amount that `writer` reports.
 
 It is possible to get access to the memory of data stored in a `bufq` with:
 
-```
+```c
 bool Curl_bufq_peek(const struct bufq *q, const unsigned char **pbuf, size_t *plen);
 ```
 
@@ -69,7 +69,7 @@ may read. This is only valid until another operation on `bufq` is performed.
 
 Instead of reading `bufq` data, one may simply skip it:
 
-```
+```c
 void Curl_bufq_skip(struct bufq *q, size_t amount);
 ```
 
@@ -80,7 +80,7 @@ This removes `amount` number of bytes from the `bufq`.
 `bufq` is initialized and freed similar to the `dynbuf` module. Code using
 `bufq` holds a `struct bufq` somewhere. Before it uses it, it invokes:
 
-```
+```c
 void Curl_bufq_init(struct bufq *q, size_t chunk_size, size_t max_chunks);
 ```
 
@@ -91,12 +91,13 @@ about memory management.
 
 The user of the `bufq` has the responsibility to call:
 
-```
+```c
 void Curl_bufq_free(struct bufq *q);
 ```
+
 to free all resources held by `q`. It is possible to reset a `bufq` to empty via:
 
-```
+```c
 void Curl_bufq_reset(struct bufq *q);
 ```
 
@@ -154,7 +155,7 @@ the `bufq` from growing ever larger and larger.
 A `struct bufc_pool` may be used to create chunks for a `bufq` and keep spare
 ones around. It is initialized and used via:
 
-```
+```c
 void Curl_bufcp_init(struct bufc_pool *pool, size_t chunk_size, size_t spare_max);
 
 void Curl_bufq_initp(struct bufq *q, struct bufc_pool *pool, size_t max_chunks, int opts);

docs/internals/CLIENT-READERS.md

@@ -28,7 +28,7 @@ The transfer loop that sends and receives, is using `Curl_client_read()` to get
 more data to send for a transfer. If no specific reader has been installed yet,
 the default one that uses `CURLOPT_READFUNCTION` is added. The prototype is
 
-```
+```c
 CURLcode Curl_client_read(struct Curl_easy *data, char *buf, size_t blen,
                           size_t *nread, bool *eos);
 ```
@@ -44,7 +44,7 @@ The chain of readers allows processing of the data to send.
 
 The definition of a reader is:
 
-```
+```c
 struct Curl_crtype {
   const char *name;        /* writer name. */
   CURLcode (*do_init)(struct Curl_easy *data, struct Curl_creader *writer);
@@ -78,7 +78,7 @@ the order in which they are called is relevant for the outcome. When a reader
 is created, it gets the `phase` property in which it operates. Reader phases
 are defined like:
 
-```
+```c
 typedef enum {
   CURL_CR_NET,  /* data send to the network (connection filters) */
   CURL_CR_TRANSFER_ENCODE, /* add transfer-encodings */

docs/internals/CLIENT-WRITERS.md

@@ -29,13 +29,13 @@ All code in `libcurl` that handles response data is ultimately expected to
 forward this data via `Curl_client_write()` to the application. The exact
 prototype of this function is:
 
-```
+```c
 CURLcode Curl_client_write(struct Curl_easy *data, int type, const char *buf, size_t blen);
 ```
 
 The `type` argument specifies what the bytes in `buf` actually are.
 The following bits are defined:
-```
+```c
 #define CLIENTWRITE_BODY    (1 << 0) /* non-meta information, BODY */
 #define CLIENTWRITE_INFO    (1 << 1) /* meta information, not a HEADER */
 #define CLIENTWRITE_HEADER  (1 << 2) /* meta information, HEADER */
@@ -56,7 +56,7 @@ application callbacks. This is similar to the design of connection filters:
 client writers can be chained to process the bytes written through them. The
 definition is:
 
-```
+```c
 struct Curl_cwtype {
   const char *name;
   CURLcode (*do_init)(struct Curl_easy *data,
@@ -87,7 +87,7 @@ in which the are called is relevant for the outcome. When a writer is created,
 one property it gets is the `phase` in which it operates. Writer phases are
 defined like:
 
-```
+```c
 typedef enum {
   CURL_CW_RAW,  /* raw data written, before any decoding */
   CURL_CW_TRANSFER_DECODE, /* remove transfer-encodings */

docs/internals/CONNECTION-FILTERS.md

@@ -76,7 +76,7 @@ etc.
 
 Each filter does in principle the following:
 
-```
+```c
 static CURLcode myfilter_cf_connect(struct Curl_cfilter *cf,
                                     struct Curl_easy *data,
                                     bool *done)
@@ -109,7 +109,7 @@ transfers.
 
 The memory footprint of a filter is relatively small:
 
-```
+```c
 struct Curl_cfilter {
   const struct Curl_cftype *cft; /* the type providing implementation */
   struct Curl_cfilter *next;     /* next filter in chain */
@@ -138,13 +138,14 @@ zero cost *if the filter does not transform the data*. An http proxy or socks
 filter, once it is connected, just passes the calls through. Those filters
 implementations look like this:
 
-```
+```c
 ssize_t Curl_cf_def_send(struct Curl_cfilter *cf, struct Curl_easy *data,
                          const void *buf, size_t len, CURLcode *err)
 {
   return cf->next->cft->do_send(cf->next, data, buf, len, err);
 }
 ```
+
 The `recv` implementation is equivalent.
 
 ## Filter Types
@@ -231,7 +232,7 @@ Users of `curl` may activate them by adding the name of the filter type to the
 `--trace-config` argument. For example, in order to get more detailed tracing
 of an HTTP/2 request, invoke curl with:
 
-```
+```sh
 > curl -v --trace-config ids,time,http/2 https://curl.se/
 ```
 

docs/internals/SCORECARD.md

@@ -25,7 +25,7 @@ locally build `src/curl` (by default).
 
 A typical invocation for measuring performance of HTTP/2 downloads would be:
 
-```
+```sh
 curl> python3 tests/http/scorecard.py -d h2
 ```
 
@@ -35,7 +35,7 @@ JSON instead of text.
 
 Help for all command line options are available via:
 
-```
+```sh
 curl> python3 tests/http/scorecard.py -h
 ```
 
@@ -48,7 +48,7 @@ specify these in some way if you are just interested in a particular case.
 For example, to run downloads of a 1 MB resource only, 100 times with at max 6
 parallel transfers, use:
 
-```
+```sh
 curl> python3 tests/http/scorecard.py -d --download-sizes=1mb --download-count=100 --download-parallel=6 h2
 ```
 
@@ -69,7 +69,7 @@ interactive SVG. Either clone the `Flamegraph` repository next to your `curl`
 project or set the environment variable `FLAMEGRAPH` to the location of your
 clone. Then run scorecard with the `--flame` option, like
 
-```
+```sh
 curl> FLAMEGRAPH=/Users/sei/projects/FlameGraph python3 tests/http/scorecard.py \
    -r --request-count=50000 --request-parallels=100 --samples=1 --flame h2
 ```