A "--fix" option would be amazing

[marcusoftnet]

Hi,

Love the tool but I do miss a --fix option that I've come to love in the Node-sister project (https://github.com/igorshubovych/markdownlint-cli)

Is this on the horizon, or have I missed something simple and it's already present?

[jackdewinter]

Thinking about this, as to whether I keep it in my long-term ideas bucket or move it to the short-term bucket. I know how I could do it, but there are some scenarios that I need to work through before I start working on it. I.e. technically, I would need to scan, see if there are any fixes, apply the fixes, and scan again... repeat until no more fixes to apply. Also, edge cases where a fix would make things worse, etc.

but thinking about it.

[gsalvatella]

I totally second the initiative. This linter should be the de facto replacement for its node counterpart when developing a python project. None should have to deal with node just to set up some checkers and linters. Additionally, having the --fix option would allow the tool to be integrated as a formatter in IDEs (e.g. neovim's null-ls, VSCode, etc). The already existing support for pyproject.toml config makes it all the more suitable for any python project requiring markdown linting and formatting for its documentation.

[jackdewinter]

Have placed some thought into this, and will be focusing on this after 0.9.12 is out.

[jackdewinter]

Will be cutting a new release sometime this week with an alpha for this, supporting fixing for md001, md009, md010, and md047.
If you guys want to try this from the repository, I should be making the merge in the next couple of hours.

Right now the trigger is to do a normal scan with the hidden -x-fix command line option.

I am split evenly between -fix scan and fix over scan. Thoughts? From an internal perspective, they are practically the same, just a bit more work for the fix path.

[jackdewinter]

working on this... started with v0.9.13, but will take a couple of releases to get everything covered

[aasmundbo]

I am split evenly between -fix scan and fix over scan. Thoughts? From an internal perspective, they are practically the same, just a bit more work for the fix path.`

I don't have a strong opinion here (I'm fine with both suggestions), but it is polite to answer, so here are my 2 cents.

Of the 2 suggestions, I prefer the fix alternative. The fix feature is quite big and deserves to be a positional argument in my opinion. Since scan "scan the Markdown files in the specified paths" (from the help), it makes sense to have fix "attempt to fix the Markdown files in the specified paths".

[aasmundbo]

I tested 0.9.13.4 for a bit and observe that when using -x-fix scan, nothing is printed to stdout. It would be nice if the issues that didn't get fixed are still printed to stdout.

E.g. where pymarkdown scan ./test prints

test/README.md:52:1: MD040: Fenced code blocks should have a language specified (fenced-code-language)
test/README.md:106:62: MD047: Each file should end with a single newline character. (single-trailing-newline)

... pymarkdown -x-fix scan ./test will print

test/README.md:52:1: MD040: Fenced code blocks should have a language specified (fenced-code-language)

... because single-trailing-newline got fixed.

Edit: Fixed language

[gsalvatella]

Will be cutting a new release sometime this week with an alpha for this, supporting fixing for md001, md009, md010, and md047. If you guys want to try this from the repository, I should be making the merge in the next couple of hours.

Right now the trigger is to do a normal scan with the hidden -x-fix command line option.

I am split evenly between -fix scan and fix over scan. Thoughts? From an internal perspective, they are practically the same, just a bit more work for the fix path.

While the fix subcommand seems the most sensible one, I would still add the --fix scan option to maintain compatibility with the nodejs version of markdownlint. People wanting to migrate to the python version will find it much more convenient if their existing scripts and integrations work out of the box. The best would be to have the fix subcommand implement the functionality and then add an option --fix to the scan subcommand which basically calls fix.

[gsalvatella]

What is the progress on this? I'm quite sure that having this flag would make this tools' popularity skyrocket...

[jackdewinter]

Been plugging away at it... check out the main branch and the changelog.md in it. I have the first salvo of fixes done, just need to make sure they do not collide that much, then will roll something out.

Can I count on you to help test? :nudge nudge:

[jackdewinter]

Added in the first pass in last nights release. It does not have all the fixes yet, but the bulk of them. Use it just like scan. And yes, will be changing the docs, but going to do a more sweeping redo of the docs soon.

[jackdewinter]

closing with no comments