style: Also format markdown files with Prettier (#1177)

Co-authored-by: Edouard Choinière <echoix@users.noreply.github.com>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,9 +2,8 @@
 name: Bug report
 about: Create a report to help us improve
 title: "[Bug] "
-labels: ''
-assignees: ''
-
+labels: ""
+assignees: ""
 ---
 
 **Name of the addon**

CONTRIBUTING.md

@@ -23,36 +23,36 @@ GRASS GIS developer mailing list.
 
 ### First time setup
 
-* Create an account on GitHub.
-* Install Git on your computer.
-* Set up Git with your name and email.
-* Fork the repository.
-* Clone your fork (use SSH or HTTPS URL):
+- Create an account on GitHub.
+- Install Git on your computer.
+- Set up Git with your name and email.
+- Fork the repository.
+- Clone your fork (use SSH or HTTPS URL):
 
 ```bash
 git clone git@github.com:your_GH_account/grass-addons.git
 ```
 
-* Enter the directory
+- Enter the directory
 
 ```bash
 cd grass-addons/
 ```
 
-* Add main GRASS GIS Addons repository as "upstream" (use HTTPS URL):
+- Add main GRASS GIS Addons repository as "upstream" (use HTTPS URL):
 
 ```bash
 git remote add upstream https://github.com/OSGeo/grass-addons
 ```
 
-* Your remotes now should be "origin" which is your fork and "upstream" which
+- Your remotes now should be "origin" which is your fork and "upstream" which
   is this main GRASS GIS Addons repository. You can confirm that using:
 
 ```bash
 git remote -v
 ```
 
-* You should see something like:
+- You should see something like:
 
 ```text
 origin  git@github.com:your_GH_account/grass-addons.git (fetch)
@@ -65,19 +65,19 @@ It is important that "origin" points to your fork.
 
 ### Update before creating a feature branch
 
-* Download updates from all branches from the _upstream_ remote:
+- Download updates from all branches from the _upstream_ remote:
 
 ```bash
 git fetch upstream
 ```
 
-* Make sure your are starting with the branch for the latest version, i.e., _grass8_:
+- Make sure your are starting with the branch for the latest version, i.e., _grass8_:
 
 ```bash
 git switch grass8
 ```
 
-* Update your local branch to match the one in the upstream repository:
+- Update your local branch to match the one in the upstream repository:
 
 ```bash
 git rebase upstream/grass8
@@ -92,13 +92,13 @@ then move your uncommitted local changes to "stash" using:
 git stash
 ```
 
-* Now you can rebase:
+- Now you can rebase:
 
 ```bash
 git rebase upstream/grass8
 ```
 
-* Apply your local changes on top of the updated code:
+- Apply your local changes on top of the updated code:
 
 ```bash
 git stash pop
@@ -109,7 +109,7 @@ git stash pop
 Now you have updated your local branch, you can create a feature branch
 based on it.
 
-* Create a new feature branch and switch to it:
+- Create a new feature branch and switch to it:
 
 ```bash
 git switch -c new-feature
@@ -123,22 +123,22 @@ general [GRASS GIS Programming Style Guide](https://github.com/OSGeo/grass/blob/
 
 ### Committing
 
-* Add files to the commit (changed ones or new ones):
+- Add files to the commit (changed ones or new ones):
 
 ```bash
 git add file1
 git add file2
 ```
 
-* Commit the change (first word is the module name):
+- Commit the change (first word is the module name):
 
 ```bash
 git commit -m "module: added a new feature"
 ```
 
 ### Pushing changes to GitHub
 
-* Push your local feature branch to your fork:
+- Push your local feature branch to your fork:
 
 ```bash
 git push origin new-feature

src/imagery/i.fusion.hpf/README.md

@@ -72,61 +72,61 @@ After installation, from within a GRASS-GIS session, see help details via
 
 ### Remarks
 
-* easy to use, i.e.:
-  * for one band `i.fusion.hpf pan=Panchromatic msx=${Band}`
-  * for multiple bands `i.fusion.hpf pan=Panchromatic msx=Red,Green,Blue,NIR`
-* easy to test various parameters that define the High-Pass filter’s
-  *kernel size* and *center value*
-* should work with **any** kind of imagery (think of bitness)
-* the "black border" effect, possibly caused due to a non-perfect match of the
+- easy to use, i.e.:
+  - for one band `i.fusion.hpf pan=Panchromatic msx=${Band}`
+  - for multiple bands `i.fusion.hpf pan=Panchromatic msx=Red,Green,Blue,NIR`
+- easy to test various parameters that define the High-Pass filter’s
+  _kernel size_ and _center value_
+- should work with **any** kind of imagery (think of bitness)
+- the "black border" effect, possibly caused due to a non-perfect match of the
   high vs. the low resolution of the input images, can be trimmed out by using
   the `trim` option --a floating point "trimming factor" with which to multiply
   the pixel size of the low resolution image-- and shrink the extent of the
   output image
 
 ## Implementation notes
 
-* First commit on Sat Oct 25 12:26:54 2014 +0300
-* Working state reached on Tue Nov 4 09:28:25 2014 +0200
+- First commit on Sat Oct 25 12:26:54 2014 +0300
+- Working state reached on Tue Nov 4 09:28:25 2014 +0200
 
 ## To Do
 
-* Go through <http://trac.osgeo.org/grass/wiki/Submitting/Python>
-* Access input raster by row I/O ?
-* Proper command history tracking. Not all "r" modules do it... ?
-* Add timestamps (r.timestamp)
-* Deduplicate code where applicable
-* Make the -v messages shorter, yet more informative (ie report center cell)
-* Test. Will it compile in other systems?
-* Checking options to integrate in `i.pansharpen`. Think of FFM methods vs.
+- Go through <http://trac.osgeo.org/grass/wiki/Submitting/Python>
+- Access input raster by row I/O ?
+- Proper command history tracking. Not all "r" modules do it... ?
+- Add timestamps (r.timestamp)
+- Deduplicate code where applicable
+- Make the -v messages shorter, yet more informative (ie report center cell)
+- Test. Will it compile in other systems?
+- Checking options to integrate in `i.pansharpen`. Think of FFM methods vs.
   Others?
-* Who else to thank?  Transfer from archive/
-* Improve [Documentation.lyx](https://gitlab.com/NikosAlexandris/i.fusion.hpf/blob/master/lyx/Documentation.lyx)
+- Who else to thank? Transfer from archive/
+- Improve [Documentation.lyx](https://gitlab.com/NikosAlexandris/i.fusion.hpf/blob/master/lyx/Documentation.lyx)
 
 ## Questions
 
-* To Ask!
+- To Ask!
 
 ## References
 
-* Gangkofner, U. G., Pradhan, P. S., and Holcomb, D. W. (2008). Optimizing
+- Gangkofner, U. G., Pradhan, P. S., and Holcomb, D. W. (2008). Optimizing
   the high-pass filter addition technique for image fusion.
   PHOTOGRAMMETRIC ENGINEERING & REMOTE SENSING, 74(9):1107–1118.
-* “ERDAS IMAGINE.” Accessed March 19, 2015. <http://doc.hexagongeospatial.com/ERDAS%20IMAGINE/ERDAS_IMAGINE_Help/#ii_hpfmerge_mergedialog.htm>.
+- “ERDAS IMAGINE.” Accessed March 19, 2015. <http://doc.hexagongeospatial.com/ERDAS%20IMAGINE/ERDAS_IMAGINE_Help/#ii_hpfmerge_mergedialog.htm>.
 
-* Aniruddha Ghosh & P.K. Joshi (2013) Assessment of pan-sharpened very
+- Aniruddha Ghosh & P.K. Joshi (2013) Assessment of pan-sharpened very
   high-resolution WorldView-2 images, International Journal of Remote Sensing,
   34:23, 8336-8359
 
 ## Ευχαριστώ
 
-* Nikos Ves
-* Ranjith, <https://class.coursera.org/interactivepython-005/forum/profile?user_id=9361576>
-* Anonymous on coursera's discussion forums
-* Pietro Zambelli
-* StackExchange contributors
-  * <http://stackoverflow.com/a/1140966/1172302>
-  * <http://stackoverflow.com/a/275025/1172302>
-* Yann Chemin
-* Aniruddha Ghosh
-* Παναγιώτης Μαυρογιώργος (<https://github.com/pmav99>)
+- Nikos Ves
+- Ranjith, <https://class.coursera.org/interactivepython-005/forum/profile?user_id=9361576>
+- Anonymous on coursera's discussion forums
+- Pietro Zambelli
+- StackExchange contributors
+  - <http://stackoverflow.com/a/1140966/1172302>
+  - <http://stackoverflow.com/a/275025/1172302>
+- Yann Chemin
+- Aniruddha Ghosh
+- Παναγιώτης Μαυρογιώργος (<https://github.com/pmav99>)

src/imagery/i.landsat8.swlst/README.md

@@ -1,12 +1,12 @@
 # i.landsat8.swist
 
-*i.landsat8.swlst* is a GRASS GIS add-on, implementing a practical Split-Window (SW)
+_i.landsat8.swlst_ is a GRASS GIS add-on, implementing a practical Split-Window (SW)
 algorithm, estimating land surface temperature (LST), from the Thermal Infra-Red
 Sensor (TIRS) aboard Landsat 8 with an accuracy of better than 1.0 K.
 
 ## Quick examples
 
-After installation (see section *Installation* below), from within a GRASS-GIS
+After installation (see section _Installation_ below), from within a GRASS-GIS
 session, retrieve usage details via `i.landsat8.swlst --help`
 
 The shortest call for processing a complete Landsat8 scene normally is:
@@ -58,7 +58,7 @@ brightness temperature (BT); land surface emissivities (LSEs); and the
 coefficients of the main Split-Window equation (SWCs).
 
 **LSEs** are derived from an established look-up table linking the FROM-GLC
-classification scheme to average emissivities. The NDVI and the FVC are *not*
+classification scheme to average emissivities. The NDVI and the FVC are _not_
 computed each time an LST estimation is requested. Read [0] for details.
 
 The **SWCs** depend on each pixel's column water vapor (CWV). **CWV** values are
@@ -70,7 +70,7 @@ size of the spatial window querying for CWV values in adjacent pixels, is a key
 parameter of the MSWCVMR method. It influences accuracy and performance. In [2]
 it is stated:
 
-> A small window size n (N = n * n, see equation (1a)) cannot ensure a high
+> A small window size n (N = n \* n, see equation (1a)) cannot ensure a high
 > correlation between two bands' temperatures due to the instrument noise. In
 > contrast, the size cannot be too large because the variations in the surface
 > and atmospheric conditions become larger as the size increases.
@@ -128,13 +128,14 @@ Making the script `i.lansat8.swlst` available from within any GRASS-GIS ver.
 - ~~Fix retrieval of adjacent subranges (exclude 6, get it only if there is no
   match for subranges 1, 2, 3, 4, and 5)~~
 
-- Evaluate BIG mapcalc expressions -- are they correct?  I guess so ;-)
+- Evaluate BIG mapcalc expressions -- are they correct? I guess so ;-)
+
   - ~~Expression for Column Water Vapor~~
   - ~~CWV output values range -- is it rational?~~ It was not. There is a
     typo in paper [0]. The correct order of the coefficients is in papers [1,
     2].
   - ~~Expression for Land Surface Temperature~~
-  - ~~LST output values range -- is it rational?  At the moment, not!~~
+  - ~~LST output values range -- is it rational? At the moment, not!~~
     Fixed. The main Split-Window equation was wrong.
 
 - ~~Why is the LST out of range when using a fixed land cover class?~~ Cloudy
@@ -155,9 +156,9 @@ Making the script `i.lansat8.swlst` available from within any GRASS-GIS ver.
 
 - ~~Redo the example screenshots for the manual after corrections for CWV, LST
   equations.~~
-- Use existing i.emissivity?  Not exactly compatible -- read paper for details.
+- Use existing i.emissivity? Not exactly compatible -- read paper for details.
   Anyhow, options to input average and delta emissivity maps implemented.
-- Raster Row I/O -- Maybe *not* an option: see discussion with Pietro Zambelli
+- Raster Row I/O -- Maybe _not_ an option: see discussion with Pietro Zambelli
 - How to perform pixel value validity checks for in-between and end products?
   `r.mapcalc` can't do this. Best to implement a test checking the values
   on-the-fly while they are created. A C-function?
@@ -167,8 +168,8 @@ Making the script `i.lansat8.swlst` available from within any GRASS-GIS ver.
 - ~~Test for too small region?~~ Works for a region of 267 rows x 267 cols
   (71289 cells)
 - Deduplicate code in `split_window_lst` class, in functions
-`_build_average_emissivity_mapcalc()` and
-`_build_delta_emissivity_mapcalc()`
+  `_build_average_emissivity_mapcalc()` and
+  `_build_delta_emissivity_mapcalc()`
 - Implement a median window filter, as another option in addition to mean.
 - Profiling
 - Implement a complete cloud masking function using the BQA image. Support for