Reflow to ~72 chars/line

[msdemlei]

I'd appreciate it if the source code came a a width of about 72 characters per line max. Diffs are more readable that way (and even without special tooling), and edit conflicts are less likely.

I'd prepare a PR for that if you want. We shouldn't have any open PRs when I do that, though, as these PRs would all break with such a change.

[JeremyMcCormick]

I usually do max width of 79 - 72 seems a bit low to me. But I agree some standard would be nice for the markdown files rather than a free for all. Maybe we could enforce this with a pre-commit hook and/or GitHub action.

[JeremyMcCormick]

Something like this might work for a pre-commit hook:

repos:
  - repo: https://github.com/hukkin/mdformat
    rev: 0.7.22
    hooks:
      - id: mdformat
        args: ["--wrap=80"]  # Put whatever max width you want here
        files: \.md$

And possibly this for a GitHub action:

name: markdown-check

on:
  pull_request:
    branches: [ main ]

jobs:
  check-markdown:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.x"
      - name: Install mdformat
        run: pip install mdformat
      - name: Check markdown formatting
        run: mdformat --wrap=80 --check .

Whater the line width, I would support adding these types of checks to keep the files consistently formatted.

[msdemlei]

On Thu, Aug 28, 2025 at 02:56:05PM -0700, Jeremy McCormick wrote: JeremyMcCormick left a comment (ivoa/ivoa-web#142) Something like this might work for a pre-commit hook: ``` repos: - repo: https://github.com/hukkin/mdformat rev: 0.7.22 # pin to a specific release—update as needed hooks: - id: mdformat args: ["--wrap=80"] # Put whatever max width you want here

Hm, no... I wouldn't do anything automatic. We shouldn't usually reflow paragraphs when editing. I actually like it if heavily-edited paragraphs look ragged in the source, but the main thing is that automatic reflowing blows the diffs big time (and blows up the repo, too). There's nothing wrong with a pre-commit check that warns if there are overly long lines (140 chars?), but other than that I'd say a brief style guide and existing files in this style should work fine.

[JeremyMcCormick]

I'd appreciate it if the source code came a a width of about 72 characters per line max. Diffs are more readable that way (and even without special tooling), and edit conflicts are less likely.

I'd prepare a PR for that if you want. We shouldn't have any open PRs when I do that, though, as these PRs would all break with such a change.

Are we talking about markdown files or site source code or both?

[gmantele]

I generally do 80 characters max, but this is a personal preference.

Hm, no... I wouldn't do anything automatic. We shouldn't usually reflow paragraphs when editing. I actually like it if heavily-edited paragraphs look ragged in the source, but the main thing is that automatic reflowing blows the diffs big time (and blows up the repo, too). There's nothing wrong with a pre-commit check that warns if there are overly long lines (140 chars?), but other than that I'd say a brief style guide and existing files in this style should work fine.

I agree, a warning seems to be a better approach. There are always exceptions. I particularly think to URLs that can sometimes be quite long (especially with the Markdown syntax []()) and must not be cut.

Are we talking about markdown files or site source code or both?

I think at least Markdown files. For HTML sources, it may sometimes be complicated to limit lines width.

[msdemlei]

On Mon, Sep 01, 2025 at 02:16:17AM -0700, Grégory Mantelet wrote: > Are we talking about markdown files or site source code or both? I think at least Markdown files. For HTML sources, it may sometimes be complicated to limit lines width.

I'm only interested in what's version controlled. The "compiled" site can be as messy as convenient; for my purposes here, it's binary. So: Markdown files (and perhaps css and friends, but there line length rarely is an issue).

[JeremyMcCormick]

Revisiting this, I would prefer a max width of 79, as that is somewhat of a standard. I am using this on a recent markdown document on another project and I think it works nicely. (It isn't so different from the proposed 72, just a tad bit wider.)

I would also be in favor of having a CI and/pre-commit check to flag lines in markdown files that are over the maximum so that there is some enforcement mechanism. I would personally be in favor of automatic reformatting; otherwise I think it will tend to be ignored. There are several tools which can reflow entire documents as well as insert breaks for new sentences (mdformat is one of these to consider).

With tools like this, very long "words" like URLs are not split, nor are code blocks, etc. So it should work fine without hindering anyone's ability to edit the files.