Spelling fixes in raster addons documentation

[echoix]

Following some work already pulled recently, I continued proofreading the documentation and strings from the documentation, staying in the raster modules. Since I've stopped working on it without finishing the 167 subfolders (41 folders done on 167), I think it is still valuable to fine-tune and pull these changes, since I still passed through 20k lines of code.

All modules from r.accumulate to r.futures (alphabetically), inclusively, were proofread and changed if needed, except r.estimap.recreation and r.damflood. I skipped r.estimap.recreation since it appears to be developed on an external GitLab repository, so fetching upstream changes are more appropriate. For r.damflood, the changes are bigger and more complex, they are in another branch and the pull request will follow.

I saw that the r.edm.eval add-on is only a shell script, that seems to be what add-ons were in GRASS 6 if I understood correctly. Does that mean that it is incompatible with GRASS 7 or GRASS 8?

I have some other notes that I took on a paper when working on this, but unfortunately I don't have the paper with me at the moment, so I will add the revision comments to the specific lines where I wasn't sure either tomorrow or later, anyway this PR should take a couple days to review.

[echoix]

+1 for the spell checks test in the CI. For example, MegaLinter has cspell and misspell.

Indeed, I checked it up, MegaLinter seems a good upgrade to the project. It seems that MegaLinter was based off a rejected PR of Super-Linter, which is the GitHub general linter used here. So, that would mean replacing this, plus the Black and flake8 actions, since they are already included?

I'm thinking of using it locally for the following checks, if possible. However, many .c files were not formatted consistently at all, so it might need a separate PR. I remember fighting my VScode to not include the "fixed" indentation when posting back the fixes, since some mixed tab and spaces (in the same line) were used. I wanted to keep the diffs clean.

[ecodiv]

Great work! I quickly went through some of the commits, but I am not sure how the review process works. One can review and comment or approve each commit separately? If I open a commit, there is this green button 'Review changes'. Is that button about the commit I opened, or the whole list?

[ecodiv]

I saw that the r.edm.eval add-on is only a shell script, that seems to be what add-ons were in GRASS 6 if I understood correctly. Does that mean that it is incompatible with GRASS 7 or GRASS 8?

That is one I still wanted to port to Python, but to be honest sort of forgot about. It is mostly R code, should not be too difficult to change to Python. I'll have a look at it.

[neteler]

One can review and comment or approve each commit separately?

Yes. You can comment on each line or propose edits:

Edit: pull down the blue "+" to edit multiple lines at once!

[neteler]

Following some work already pulled recently, I continued proofreading the documentation and strings from the documentation

Thanks for your great work.

BTW: in GRASS-core, we also have the script codespell.py borrowed from GDAL, see https://github.com/OSGeo/grass/blob/main/utils/fix_typos.sh (I used it once, time ago).

[neteler]

However, many .c files were not formatted consistently at all, so it might need a separate PR.

For this, we have

• https://github.com/OSGeo/grass/blob/main/utils/grass_indent.sh
• https://github.com/OSGeo/grass/blob/main/utils/grass_indent_ALL.sh

They are naturally pretty invasive, so some care needs to be taken with the open large pull requests (maybe skip indentation of those for now till they have been merged).

[echoix]

They are naturally pretty invasive, so some care needs to be taken with the open large pull requests (maybe skip indentation of those for now till they have been merged).

Of course. I was thinking of maybe having a preparatory pull request if we were to have a CI that would make sure it doesn't get dirty again.

[echoix]

Ok, for my notes that I took, finally there isn't much more than the sentence in r.edm.eval, and the modules that I skipped.
The remaining fix was a spelling fix in the r.extract.py append_random() that should be fixed upstream since it was copied from the core repo, and a reminder to enter an issue to flag that r.diversity might not work in grass 8 since the code explicitly makes extra checks and builds a path with "GRASS7" in its main().

So once everyone who wants to review has reviewed, it will be ready to merge.

[echoix]

Great work! I quickly went through some of the commits, but I am not sure how the review process works. One can review and comment or approve each commit separately? If I open a commit, there is this green button 'Review changes'. Is that button about the commit I opened, or the whole list?

@ecodiv You can open the commits or the files, and press the "+" like @neteler showed. A comment or suggested change can be made for the cumulative code changed in the PR (like if additionnal commits change something and it is still not right). See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request if you want to learn more. :)

[echoix]

I found unnecessary lines changed in a diff.

[neteler]

a reminder to enter an issue to flag that r.diversity might not work in grass 8 since the code explicitly makes extra checks and builds a path with "GRASS7" in its main().

(hopefully addressed in #667)

[echoix]

After resolving the last two opened conversations, I think the PR can be merged.

[wenzeslaus]

Sorry, unrelated to this already long PR discussion, but anyway:

+1 for the spell checks test in the CI. For example, MegaLinter has cspell and misspell.

So, that would mean replacing [Super-Linter]...

Maybe, maybe not, my guess is that MegaLinter and Super-Linter diverged now enough that each has its own merits.

...plus the Black and flake8 actions, since they are already included?

Not necessarily, direct and possibly finer control over Flake8 and Black (and possibly Pylint) is likely desired, e.g., due to changes in Black versions.

[neteler]

If there are no objections, I'll merge this PR. Thanks for your efforts @echoix!

[echoix]

Looks good to me! I will be ready to continue next weekend!

[echoix]

+1 for the spell checks test in the CI. For example, MegaLinter has cspell and misspell.

Jusr to let you know that its been two weekends I'm playing around with MegaLinter in my fork. I'm learning how it works and configuring it correctly to be confident about it when it will be time to make a PR. Last week, the maintainer of MegaLinter jumped into my test PR, and made some performance changes to MegaLinter itself with what I observed. He even forked my fork to test an even more optimal configuration. I'm writing it here just to not make some duplicated work if someone though of implementing it while I'm working on it. My goal is to try it out, have it here, and one day have it in the core repo too.