fix/paragraphs #5431

2025-10-26T15:03:52Z

delliott commented

2025-10-26 15:03:52 +00:00

Currently implements both a format hook to remove white-space paragraphs, and a check to make their existence a critical failure.

In the end may implement only one or none of these, subject to major design changes.

Solves #5409

Currently implements both a format hook to remove white-space paragraphs, and a check to make their existence a critical failure. In the end may implement only one or none of these, subject to major design changes. Solves https://git.fsfe.org/FSFE/fsfe-website/issues/5409

delliott referenced this pull request

2025-10-26 15:22:30 +00:00

CSS: increase spacing before and after <blockquote> #5409

delliott requested review from tobiasd 2025-10-26 17:33:51 +00:00

delliott requested review from hl 2025-10-26 17:33:55 +00:00

tobiasd requested changes

2025-10-27 08:43:13 +00:00

.drone.yml Outdated

						
				@@ -143,5 +143,3 @@ volumes:

				---

				kind: signature

				hmac: 997582ae47807c3367efcda28920c2d0f84bfd05d6fddf224bf7440a636d91e1

tobiasd commented

2025-10-27 05:50:41 +00:00

These lines should not be removed I think

delliott commented

2025-10-27 10:58:38 +00:00

That is what prettier does to yml files, and then drone sign changes it again.

tobiasd commented

2025-10-27 08:44:22 +00:00

CI is failing, I cannot check all the 11k changed files - but what I've seen of the trivial removals of whitespace LGTM for the 1st two commits they look good for me as well.

tobiasd removed review request for hl 2025-10-27 08:44:29 +00:00

delliott commented

2025-10-27 11:05:54 +00:00

So, there is a little bit of discussion t be had here when it comes to automating some formatting of xhtml files.

At present we have a bunch of formatters and linters, as we have many kinds of files in the repo.

We currently have automated linting but nor formatting of xhtml. The lints are generally easy enough to fix manually.

Using the empty paragraph remover does perform some whitespace changes on files, and so we have kind of introduced our first xhtml formatter. Perhaps when we are already altering 11k files, and causing the biggest merge and ensuring merge conflicts to follow, we should just go whole hog and run the xmllint format we currently use on xml and xsl files on xhtml too? I do not mind.

Also, we are now entering a somewhat interesting point with our ci.

So, at present all the pre-commit checks are ran as ci. Some of them do not fail if the files have changed, like most of the formatters. But the formatters will fail if they see invalid xml, or js, or so forth. But assuming that committed files are not formatted, but syntactically correct they will pass ci.

And then we also have checks, which are mainly some bash and python scripts that assert something is/is not the case. These fail ci if they check is failed.

Do we want to make unformatted files a CI failure? I would like to, but know that this project has many contributors who use the web interface, without pre-commit hooks, quite frequently.

So, there is a little bit of discussion t be had here when it comes to automating some formatting of xhtml files. At present we have a bunch of formatters and linters, as we have many kinds of files in the repo. We currently have automated linting but nor formatting of xhtml. The lints are generally easy enough to fix manually. Using the empty paragraph remover does perform some whitespace changes on files, and so we have kind of introduced our first xhtml formatter. Perhaps when we are already altering 11k files, and causing the biggest merge and ensuring merge conflicts to follow, we should just go whole hog and run the `xmllint format` we currently use on xml and xsl files on xhtml too? I do not mind. Also, we are now entering a somewhat interesting point with our ci. So, at present all the pre-commit checks are ran as ci. Some of them do not fail if the files have changed, like most of the formatters. But the formatters will fail if they see invalid xml, or js, or so forth. But assuming that committed files are not formatted, but syntactically correct they will pass ci. And then we also have checks, which are mainly some bash and python scripts that assert something is/is not the case. These fail ci if they check is failed. Do we want to make unformatted files a CI failure? I would like to, but know that this project has many contributors who use the web interface, without pre-commit hooks, quite frequently.

delliott commented

2025-10-27 11:13:16 +00:00

Or we could do something maybe inadvisable, and use drone to push to the branch after running the formatters:

https://github.com/appleboy/drone-git-push/blob/master/DOCS.md

So if the commits failed the checks, requring manual intervention, one does so and no automated commits will be made yet.

Once the manual intervention requiring errors are fixed, the ci will proceed to the next stage, and push the formatting changes, if there are any. There will be none for those using the pre-commit hooks locally properly, but for web edit changes there might be.

And then merge.

We could also maybe do something like having it make the commits during a merge, so they are not seen in the pr, or making the commits on master after a merge? I am not sure.

Or we could do something maybe inadvisable, and use drone to push to the branch after running the formatters: https://github.com/appleboy/drone-git-push/blob/master/DOCS.md So if the commits failed the checks, requring manual intervention, one does so and no automated commits will be made yet. Once the manual intervention requiring errors are fixed, the ci will proceed to the next stage, and push the formatting changes, if there are any. There will be none for those using the pre-commit hooks locally properly, but for web edit changes there might be. And then merge. We could also maybe do something like having it make the commits during a merge, so they are not seen in the pr, or making the commits on master after a merge? I am not sure.

delliott commented

2025-10-27 16:53:24 +00:00