docs: Linting markdown files (#2762)

INSTALL.md

@@ -282,7 +282,8 @@ better settings to us):
 CFLAGS="-mcpu=athlon -O2" # AMD Athlon processor with code optimisations
 CFLAGS="-mcpu=pentium" # Intel Pentium processor
 CFLAGS="-mcpu=pentium4" # Intel Pentium4 processor
-CFLAGS="-O2 -msse -msse2 -mfpmath=sse -minline-all-stringops" # Intel XEON 64bit processor
+CFLAGS="-O2 -msse -msse2 -mfpmath=sse \
+        -minline-all-stringops" # Intel XEON 64bit processor
 CFLAGS="-mtune=nocona -m64 -minline-all-stringops" # Intel Pentium 64bit processor
 ```
 

README.md

@@ -17,7 +17,8 @@ a Geographic Information System used for geospatial data management and
 analysis, image processing, graphics/map production, spatial modeling, and
 visualization.
 
-Launch this repository in Binder and experiment with GRASS's Python API in Jupyter Notebooks by clicking the button below:
+Launch this repository in Binder and experiment with GRASS's Python API in
+Jupyter Notebooks by clicking the button below:
 
 [![Binder](https://camo.githubusercontent.com/581c077bdbc6ca6899c86d0acc6145ae85e9d80e6f805a1071793dbe48917982/68747470733a2f2f6d7962696e6465722e6f72672f62616467655f6c6f676f2e737667)](https://mybinder.org/v2/gh/OSGeo/grass/main?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fjupyter_example.ipynb)
 
@@ -36,7 +37,9 @@ Want to become a core developer? See
 
 > See the INSTALL.md file.
 
-Yes, you should really read [INSTALL.md](INSTALL.md). In addition, there are detailed [compile instructions](https://grasswiki.osgeo.org/wiki/Compile_and_Install) in the Wiki.
+Yes, you should really read [INSTALL.md](INSTALL.md). In addition, there are
+detailed [compile instructions](https://grasswiki.osgeo.org/wiki/Compile_and_Install)
+in the Wiki.
 
 ## Docker
 
@@ -91,8 +94,9 @@ Note that the first `grassgis` is the name of the image while the second
 xhost local:$(id -u)
 docker run -it --privileged --user=$(id -u):$(id -g) --rm \
     --volume="$(pwd)/:/data" --volume="/tmp/.X11-unix:/tmp/.X11-unix:rw" \
-    --env HOME=/data/ --env DISPLAY=$DISPLAY --device="/dev/dri/card0:/dev/dri/card0" \
-        grassgis grass --gui
+    --env HOME=/data/ --env DISPLAY=$DISPLAY \
+    --device="/dev/dri/card0:/dev/dri/card0" \
+    grassgis grass --gui
 ```
 
 Note: If you compiled locally before building the Docker image, you may

doc/development/rfc/PSC_guidelines.md

@@ -8,9 +8,10 @@ Status: Adopted (6 April 2007)
 
 ## Summary
 
-A GRASS Project Steering Committee ([PSC](https://trac.osgeo.org/grass/wiki/PSC)) is proposed to formalize control
-over the GRASS codebase and to facilitate GRASS project management issues.
-It is desired to keep the administrational overhead as low as possible.
+A GRASS Project Steering Committee ([PSC](https://trac.osgeo.org/grass/wiki/PSC))
+is proposed to formalize control over the GRASS codebase and to facilitate GRASS
+project management issues. It is desired to keep the administrational overhead
+as low as possible.
 
 This document describes how the GRASS Project Steering Committee
 determines membership, and makes decisions on GRASS project issues.
@@ -41,7 +42,8 @@ currently include:
 
 * Maintaining submitter guidelines and making all developers aware of them.
 * Granting write access to the source code repository for new developers.
-* Enforcing the submitter guidelines, with the ultimate sanction against non-compliance being removal of write access to the source code repository.
+* Enforcing the submitter guidelines, with the ultimate sanction against
+  non-compliance being removal of write access to the source code repository.
 
 In general, once write access has been granted, developers are allowed to
 make changes to the codebase as they see fit. For controversial or
@@ -59,7 +61,8 @@ community can request the PSC to choose options best preserving the
 quality of the GRASS project.
 
 Removal of write access to the source code repository is handled as a
-proposal to the committee as described below in the [Operation of the PSC](#operation-of-the-psc) section.
+proposal to the committee as described below in the
+[Operation of the PSC](#operation-of-the-psc) section.
 
 ### Legal aspects
 

doc/development/rfc/PSC_voting_procedures.md

@@ -8,23 +8,50 @@ Status: Adopted (6 Oct 2014)
 
 ## Introduction
 
-In brief, the PSC members vote on proposals on the dedicated [GRASS-PSC mailing list](http://lists.osgeo.org/mailman/listinfo/grass-psc).
+In brief, the PSC members vote on proposals on the dedicated
+[GRASS-PSC mailing list](http://lists.osgeo.org/mailman/listinfo/grass-psc).
 Proposals are available for review for at least seven calendar days, and a
 single veto is sufficient to delay progress although ultimately a majority
 of committee members can pass a proposal.
 
 ## Detailed Process
 
 Proposals:
- 1. Proposals are written up and submitted on the PSC mailing list for discussion. Any committee member may call a vote on any proposal, although it is normal practice for the proposer to call the vote. Any interested  party may subscribe to the list and join the discussion, but only [PSC committee members](https://trac.osgeo.org/grass/wiki/PSC) including the PSC Chair get a vote ("eligible voters").
- 1. Proposals are available for review for at least seven calendar days before a vote can be closed. It is acknowledged that some more complex issues may require more time for discussion and deliberation: a vote should only be closed after the minimum time period (see above) has passed and sufficient discussion has taken place, or no more progress is being made. The PSC Chair may override this and prolong the discussion period or close a vote straight away if necessary (although the minimum time period for discussion/voting always applies).
+
+ 1. Proposals are written up and submitted on the PSC mailing list for discussion.
+    Any committee member may call a vote on any proposal, although it is normal
+    practice for the proposer to call the vote. Any interested  party may subscribe
+    to the list and join the discussion, but only
+    [PSC committee members](https://trac.osgeo.org/grass/wiki/PSC) including the
+    PSC Chair get a vote ("eligible voters").
+ 2. Proposals are available for review for at least seven calendar days before a
+    vote can be closed. It is acknowledged that some more complex issues may
+    require more time for discussion and deliberation: a vote should only be closed
+    after the minimum time period (see above) has passed and sufficient discussion
+    has taken place, or no more progress is being made. The PSC Chair may override
+    this and prolong the discussion period or close a vote straight away if
+    necessary (although the minimum time period for discussion/voting always
+    applies).
 
 Voting:
- 1. A voting procedure is started by the proposer. For a more visible communication, the word [MOTION] should be put into the subject of the email to the [GRASS-PSC mailing list](http://lists.osgeo.org/mailman/listinfo/grass-psc) along with a short title.
- 1. Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation.
- 1. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning and alternative approaches to resolving the problem within the period the issue is open for discussion/voting. Otherwise the veto will be considered invalid.
- 1. A vote of -0 indicates mild disagreement, but has no effect.  A 0 indicates no opinion.  A +0 indicate mild support, but has no effect.
- 1. A proposal will be accepted if it receives majority (51% of all eligible voters including the proposer) of votes (+1) and no vetoes (-1).
- 1. The committee member who called the vote (normally the proposer) is responsible for collating votes and presenting the result to the PSC after closing the vote.
- 1. The Chair adjudicates in cases of disputes over voting.
- 1. If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all eligible voters, not just those who actively vote.
+
+ 1. A voting procedure is started by the proposer. For a more visible communication,
+    the word [MOTION] should be put into the subject of the email to the
+    [GRASS-PSC mailing list](http://lists.osgeo.org/mailman/listinfo/grass-psc)
+    along with a short title.
+ 2. Respondents may vote "+1" to indicate support for the proposal and a
+    willingness to support implementation.
+ 3. Respondents may vote "-1" to veto a proposal, but must provide clear reasoning
+    and alternative approaches to resolving the problem within the period the issue
+    is open for discussion/voting. Otherwise the veto will be considered invalid.
+ 4. A vote of -0 indicates mild disagreement, but has no effect.  A 0 indicates
+    no opinion.  A +0 indicate mild support, but has no effect.
+ 5. A proposal will be accepted if it receives majority (51% of all eligible
+    voters including the proposer) of votes (+1) and no vetoes (-1).
+ 6. The committee member who called the vote (normally the proposer) is responsible
+    for collating votes and presenting the result to the PSC after closing the vote.
+ 7. The Chair adjudicates in cases of disputes over voting.
+ 8. If a proposal is vetoed, and it cannot be revised to satisfy all parties, then
+    it can be resubmitted for an override vote in which a majority of all eligible
+    voters indicating +1 is sufficient to pass it. Note that this is a majority of
+    all eligible voters, not just those who actively vote.

doc/development/rfc/language_standards_support.md

@@ -5,23 +5,50 @@ Author of the first draft: Nicklas Larsson
 Status: Motion passed, 29 March 2021
 
 ## Introduction
-The code base of GRASS GIS consists today (Feb. 2021) of predominantly C code (ca 50 %), Python (ca 30 %) and a smaller amount of C++ (ca 5 %). Each of these languages have evolved significantly in the last 10–20 years. There is, however, no clearly stated policy of supported language standard(s), nor mechanism to update this policy when needed or wanted. This result in uncertainty for contributors for what may be allowed and solutions that may not be optimal.
 
-This RFC aims at setting a policy for GRASS GIS project regarding language standard support for C and C++.
+The code base of GRASS GIS consists today (Feb. 2021) of predominantly C code
+(ca 50 %), Python (ca 30 %) and a smaller amount of C++ (ca 5 %). Each of these
+languages have evolved significantly in the last 10–20 years. There is, however,
+no clearly stated policy of supported language standard(s), nor mechanism to
+update this policy when needed or wanted. This result in uncertainty for
+contributors for what may be allowed and solutions that may not be optimal.
 
-In addition, this is also intended to set a precedent for future updates on this subject.
+This RFC aims at setting a policy for GRASS GIS project regarding language
+standard support for C and C++.
+
+In addition, this is also intended to set a precedent for future updates on this
+subject.
 
 ## Background
-Throughout its long history, soon 40 years, GRASS GIS has evolved and steps have been taken to adapt and modernize. The latest big modernization of the C code was done in 2002–2006 ([summary](https://lists.osgeo.org/pipermail/grass-dev/2021-February/094955.html)), when it was updated to conform to C89 (ANSI C) standard. A major job, which has payed-off well. However, during the years, language features of successive standards have slipped into the code base, which is no longer strictly C89 (nor C90) conformant. There are no compelling reasons to revert the existing code to strict C89, therefore the community has to decide which standard to adhere to.
 
-The small amount of C++ code in GRASS GIS has never been formalised and officially made to conform to any specific standard.
+Throughout its long history, soon 40 years, GRASS GIS has evolved and steps have
+been taken to adapt and modernize. The latest big modernization of the C code
+was done in 2002–2006 ([summary](https://lists.osgeo.org/pipermail/grass-dev/2021-February/094955.html)),
+when it was updated to conform to C89 (ANSI C) standard. A major job, which has
+payed-off well. However, during the years, language features of successive
+standards have slipped into the code base, which is no longer strictly C89
+(nor C90) conformant. There are no compelling reasons to revert the existing
+code to strict C89, therefore the community has to decide which standard to
+adhere to.
+
+The small amount of C++ code in GRASS GIS has never been formalised and
+officially made to conform to any specific standard.
 
-See also the discussion leading to this RFC on the mailing list [thread](https://lists.osgeo.org/pipermail/grass-dev/2021-January/094899.html).
+See also the discussion leading to this RFC on the mailing list
+[thread](https://lists.osgeo.org/pipermail/grass-dev/2021-January/094899.html).
 
 ## Discussion
-The advantage of having clearly stated policy on language standard requirements/support is important not only for contributors, but also sets the frame for supported platforms. For the latter, also the reverse is true: in deciding supported standard the community needs to consider the degree of support of standards for various platforms.
 
-It should be emphasized that existing GRASS GIS C and C++ code compiles also with C17 and C++17. There is therefore no need to modernize it the way it was done to C in the 2000’s. Nevertheless, conforming to newer standards may provide better cross platform support and possibly safer code.
+The advantage of having clearly stated policy on language standard
+requirements/support is important not only for contributors, but also sets the
+frame for supported platforms. For the latter, also the reverse is true: in
+deciding supported standard the community needs to consider the degree of
+support of standards for various platforms.
+
+It should be emphasized that existing GRASS GIS C and C++ code compiles also
+with C17 and C++17. There is therefore no need to modernize it the way it was
+done to C in the 2000’s. Nevertheless, conforming to newer standards may
+provide better cross platform support and possibly safer code.
 
 Regarding C, there are three standards that may be considered: C99, C11 and
 C17. C99 never really reached full support on key platforms, this is
@@ -40,15 +67,21 @@ hand, doesn’t add new features compared to C11. Its difference is more
 interesting from compiler point of view, whereas code “good for C11” is
 good for C17.
 
-Regarding C++, there are the C++98, C++03, C++11, C++14 and C++17 standards to consider. The platform and compiler support for all of these are significantly better. However, C++11 is at this date in general considered the standard and until compelling reasons argue otherwise, the C++11 standard should be policy of the GRASS GIS project.
+Regarding C++, there are the C++98, C++03, C++11, C++14 and C++17 standards to
+consider. The platform and compiler support for all of these are significantly
+better. However, C++11 is at this date in general considered the standard and
+until compelling reasons argue otherwise, the C++11 standard should be policy of
+the GRASS GIS project.
 
 ## Proposed Language Standards Support
 
 ### C Language
+
 C11 with core (mandatory) features [brief summary](https://en.wikipedia.org/wiki/C11_(C_standard_revision))
 
-Optional features may be used if availability is tested with macro, and if not supported, alternative fallback code must be provided.
+Optional features may be used if availability is tested with macro, and if not
+supported, alternative fallback code must be provided.
 
 ### C++ Language
-C++11 [summary](https://en.wikipedia.org/wiki/C%2B%2B11)
 
+C++11 [summary](https://en.wikipedia.org/wiki/C%2B%2B11)

doc/development/rfc/legal_aspects_of_code_contributions.md

@@ -52,9 +52,9 @@ source repository:
  licensing (grass/COPYRIGHT.txt).
 * Existing copyright headers and license text should never be stripped
  from a file. If a copyright holder wishes to give up copyright they
- must do so in writing to the GRASS [PSC](https://trac.osgeo.org/grass/wiki/PSC) before copyright messages
- are removed. If license terms are changed, it has to be by agreement
- (written in email is ok) of the copyright holders.
+ must do so in writing to the GRASS [PSC](https://trac.osgeo.org/grass/wiki/PSC)
+ before copyright messages are removed. If license terms are changed, it has to
+ be by agreement (written in email is ok) of the copyright holders.
 * When substantial contributions are added to a file (such as
  substantial patches) the author/contributor should be added to the
  list of copyright holders for the file in the file header.
@@ -67,4 +67,3 @@ Questions regarding GRASS GIS should be directed to the
 GRASS Development Team at the following address:
 
 Internet: <http://grass.osgeo.org/home/contact-us/>
-