walpo commented 2025年06月17日 17:29:27 +02:00

Changelog

The format is based on Keep a Changelog.

Fixed

• Lint issues:
  • Line length (MD013).
  • Heading levels should only increment by one level at a time (MD001).
  • Link fragments should be valid (MD051).

---

# Changelog The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). ## Fixed - Lint issues: - Line length ([MD013](https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md013.md)). - Heading levels should only increment by one level at a time ([MD001](https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md001.md)). - Link fragments should be valid ([MD051](https://github.com/DavidAnson/markdownlint/blob/v0.38.0/doc/md051.md)). ---

walpo commented 2025年06月17日 17:31:08 +02:00

The Spell Checker, markdownlint and Prettier lint checks pass successfully in my local machine for 90c3f47e17.

docker run -v $PWD:/workdir davidanson/markdownlint-cli2:v0.18.1 "**/*.md" "#node_modules"; docker run --rm -it -v ./:/app/ --entrypoint='prettier' documentation:prettier --check .; docker run --rm -itv ./:/app documentation:cspell pnpx cspell lint --no-progress --gitignore '{**,.*}/{*,.*}'
markdownlint-cli2 v0.18.1 (markdownlint v0.38.0)
Finding: **/*.md !node_modules
Linting: 76 file(s)
Summary: 0 error(s)
Checking formatting...
All matched files use Prettier code style!
! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-10.12.1.tgz
? Do you want to continue? [Y/n] y
Packages: +113
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Progress: resolved 113, reused 0, downloaded 113, added 113, done
CSpell: Files checked: 78, Issues found: 0 in 0 files.

The Spell Checker, markdownlint and Prettier lint checks pass successfully in my local machine for 90c3f47e17. ```bash docker run -v $PWD:/workdir davidanson/markdownlint-cli2:v0.18.1 "**/*.md" "#node_modules"; docker run --rm -it -v ./:/app/ --entrypoint='prettier' documentation:prettier --check .; docker run --rm -itv ./:/app documentation:cspell pnpx cspell lint --no-progress --gitignore '{**,.*}/{*,.*}' markdownlint-cli2 v0.18.1 (markdownlint v0.38.0) Finding: **/*.md !node_modules Linting: 76 file(s) Summary: 0 error(s) Checking formatting... All matched files use Prettier code style! ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-10.12.1.tgz ? Do you want to continue? [Y/n] y Packages: +113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Progress: resolved 113, reused 0, downloaded 113, added 113, done CSpell: Files checked: 78, Issues found: 0 in 0 files. ```

renovate-bot commented 2025年06月18日 10:41:59 +02:00

Surge PR preview deployment succeeded. View it at https://Codeberg-Documentation-pr-629.surge.sh

<!--woodpeckerci-plugin-surge-preview--> Surge PR preview deployment succeeded. View it at https://Codeberg-Documentation-pr-629.surge.sh

walpo commented 2025年06月18日 21:00:49 +02:00

The matter of having a line length limit of 120 characters was discussed and agreed upon in the Matrix chat channel if I remember correctly. The resultant pull requests were Codeberg/Documentation#463 and Codeberg/Documentation#623.

In Markdown/CommonMark, even if you split a line into multiple lines, as long as there is no blank lines separating them, they will be all rendered as part of the same paragraph, separated by a whitespace.

In my opinion, the new line length limit helps to improve code readability because it reduces the need to use word wrap in text editors when working with long lines of text, as well as leading people to write content in a more structured way (avoiding "wall of texts"). The documentation had some very long lines of text prior to the merged PR.

Feel free to discuss this matter with other key members of the community, but please keep in mind this PR simply fixes the lint issues raised by markdownlint as currently configured in .markdownlint.yaml.

The matter of having a line length limit of 120 characters was discussed and agreed upon in the Matrix chat channel if I remember correctly. The resultant pull requests were Codeberg/Documentation#463 and Codeberg/Documentation#623. In Markdown/CommonMark, even if you split a line into multiple lines, as long as there is no blank lines separating them, they will be all rendered as part of the same paragraph, separated by a whitespace. In my opinion, the new line length limit helps to improve code readability because it reduces the need to use word wrap in text editors when working with long lines of text, as well as leading people to write content in a more structured way (avoiding "wall of texts"). The documentation had some very long lines of text prior to the merged PR. Feel free to discuss this matter with other key members of the community, but please keep in mind this PR simply fixes the lint issues raised by `markdownlint` as currently configured in `.markdownlint.yaml`.

pat-s commented 2025年06月22日 00:00:12 +02:00

In Markdown/CommonMark, even if you split a line into multiple lines, as long as there is no blank lines separating them, they will be all rendered as part of the same paragraph, separated by a whitespace.

I know, no need to explain the basics :) (and I am aware you didn't mean this in a negative context)

In my opinion, the new line length limit helps to improve code readability because it reduces the need to use word wrap in text editors when working with long lines of text, as well as leading people to write content in a more structured way (avoiding "wall of texts"). The documentation had some very long lines of text prior to the merged PR.

Applying a hard-split doesn't help with this at all IMO. Too long sentences are best detected with the "one sentence per line" rule and then realizing that certain ones are just super/too long. Yes, this can be combined with a line-length linter to have an automatic lint fail during CI checks but just hard-breaking at length X is not at all a solution.

Editors can soft-wrap and that should be used if screen real estate is an error.

Feel free to discuss this matter with other key members of the community,

CB has no official responsibilities for (almost) any repo, which is a (huge) problem since ever. I am a "CB core" member for years and due to this could consider myself "having a word" here but I don't have more to say than anybody else. This then again means the same for "the community in the matrix chat" - whoever that refers to exactly.

And yes, I could/should have intervened in the previous PR already but I didn't want to bring up this general discussion again. But yes, I should have realized it will come up anyhow in a follow-up PR.

Anyways, I shouldn't get myself into such discussions in the first place, as the main issue is that nobody is "officially" responsible and setting the rules, so everything is vague and often stuck.
So in the end it was my fault (without any irony) and I should just focus on other things than doing reviews here.

Sorry if that is perceived negatively in any way, it shouldn't be, people like you are needed to push something forward! (I am just over and over again desperate about the lack of roles & responsibilities). Anyhow, I'll unblock and leave future reviews to somebody else.

> In Markdown/CommonMark, even if you split a line into multiple lines, as long as there is no blank lines separating them, they will be all rendered as part of the same paragraph, separated by a whitespace. I know, no need to explain the basics :) (and I am aware you didn't mean this in a negative context) > In my opinion, the new line length limit helps to improve code readability because it reduces the need to use word wrap in text editors when working with long lines of text, as well as leading people to write content in a more structured way (avoiding "wall of texts"). The documentation had some very long lines of text prior to the merged PR. Applying a hard-split doesn't help with this at all IMO. Too long sentences are best detected with the "one sentence per line" rule and then realizing that certain ones are just super/too long. Yes, this can be combined with a line-length linter to have an automatic lint fail during CI checks but just hard-breaking at length X is not at all a solution. Editors can soft-wrap and that should be used if screen real estate is an error. > Feel free to discuss this matter with other key members of the community, CB has no official responsibilities for (almost) any repo, which is a (huge) problem since ever. I am a "CB core" member for years and due to this *could* consider myself "having a word" here but I don't have more to say than anybody else. This then again means the same for "the community in the matrix chat" - whoever that refers to exactly. And yes, I could/should have intervened in the previous PR already but I didn't want to bring up this general discussion again. But yes, I should have realized it will come up anyhow in a follow-up PR. Anyways, I shouldn't get myself into such discussions in the first place, as the main issue is that nobody is "officially" responsible and setting the rules, so everything is vague and often stuck. So in the end it was my fault (without any irony) and I should just focus on other things than doing reviews here. Sorry if that is perceived negatively in any way, it shouldn't be, people like you are needed to push something forward! (I am just over and over again desperate about the lack of roles & responsibilities). Anyhow, I'll unblock and leave future reviews to somebody else.

walpo commented 2025年06月22日 20:44:05 +02:00

This PR simply enforces what was agreed previously in the Matrix chat channel.

If you need any more changes from my side, feel free to bring them up.
From my point of view, the PR is ready for review and merge.

This PR simply enforces what was agreed previously in the Matrix chat channel. If you need any more changes from my side, feel free to bring them up. From my point of view, the PR is ready for review and merge.

walpo commented 2025年07月25日 20:05:25 +02:00

Do I have to make any more changes to this PR to make it progress?

Do I have to make any more changes to this PR to make it progress?

walpo commented 2025年11月20日 14:49:07 +01:00

I have fixed new lint errors that have emerged these last few months.

This PR needs to be reviewed again.

I have fixed new lint errors that have emerged these last few months. This PR needs to be reviewed again.

walpo commented 2025年11月20日 17:16:33 +01:00

@gusted

@gusted

Gusted commented 2025年11月21日 00:29:26 +01:00

So for my understanding, fixes are from existing lint rules right? But markdown lint is called in the CI, why wasn't it catched before?

So for my understanding, fixes are from existing lint rules right? But markdown lint is called in the CI, why wasn't it catched before?

Gusted commented 2025年11月21日 00:43:56 +01:00

You can ignore the CI failure for links.

[warn] content/getting-started/faq.md

looks interesting from prettier. Could you run prettier -w . and commit the result?

You can ignore the CI failure for links. > [warn] content/getting-started/faq.md looks interesting from prettier. Could you run `prettier -w .` and commit the result?

Gusted commented 2025年11月21日 00:50:27 +01:00

@Gusted wrote in #629 (comment):

So for my understanding, fixes are from existing lint rules right? But markdown lint is called in the CI, why wasn't it catched before?

Found the problem, !702

@Gusted wrote in https://codeberg.org/Codeberg/Documentation/pulls/629#issuecomment-8382147: > So for my understanding, fixes are from existing lint rules right? But markdown lint is called in the CI, why wasn't it catched before? Found the problem, !702

walpo commented 2025年11月21日 12:33:49 +01:00

I had an outdated version of the Prettier image locally which produced a different result than the lint job running in the Codeberg CI. I have updated the local image and applied the lint --write in both PRs.

I have also added the .pnpm-store directory to the Pretty ignore file in both PRs. As soon as that change is merged through one PRs, the other should merge just fine as well (identical change).

Let's see if the lint tests now run successfully here.

I had an outdated version of the Prettier image locally which produced a different result than the lint job running in the Codeberg CI. I have updated the local image and applied the lint `--write` in both PRs. I have also added the `.pnpm-store` directory to the Pretty ignore file in both PRs. As soon as that change is merged through one PRs, the other should merge just fine as well (identical change). Let's see if the lint tests now run successfully here.