report issue somehow

[ccoVeille]

Your code is a markdown code snippet formatter. That's the project purpose OK.

Your code is formatting block that could be invalid.

So your code is somehow also a linter, as you are able to know when you are facing an error when formatting a code block.

In debug mode I can see the code that are invalid (or with an strafe, I'm unsure)

What about reporting something like a warning aside file names to say you face x errors when processing a file.

[ccoVeille]

Please note, I'm on my phone. Your code may already report it now. But I don't think I saw it earlier when I was formatting "partial go code"

[hougesen]

Do you mean printing that formatting with a formatter failed, or the actual formatting error?

[ccoVeille]

Right now if you are not using debug.

You cannot know there was something that wasn't in the right format to be formatted.

I would expect something at least like

file1.md (unchanged) 13ms
file2.md (formatted) 1280.ms
files3.md (formatted) 400ms
file4.md (unchanged) 1466 ms with 2 errors.

Or you display the error log you display with the debug mode with the line and error, but only when an error occurs.

Or it could be a sum up.

I think that your tool should help to report fenced blocks that contains invalid code. But then you might report things you are not able to handle, so you will get bug report with examples. As I do,it would be better than displaying nothing except in debug mode

[hougesen]

Or you display the error log you display with the debug mode with the line and error, but only when an error occurs.

Seems like the best option.

[ccoVeille]

Is there anything else to do on this issue?

I'm unsure and I'm a bit lost in what you implemented vs what I suggested

[hougesen]

I still want to add a log for formatter errors.

I'm unsure and I'm a bit lost in what you implemented vs what I suggested

After implementing file4.md (unchanged) 1466 ms with 2 errors I realized that the error message was pretty annoying to deal with, since you had no way of knowing why without formatting everything again with --debug enabled.

The same thing happened when I tried reporting all errors/missing formatters at the end.

The current implementation (with default log level and without --debug) goes something like this:

`$PATH1` formatting `$LANGUAGE` block from :`$LINE_START` to :`$LINE_END` using `$FORMATTER`
`$PATH1` finished in `$DURATION`ms

`$PATH2` formatting `$LANGUAGE` block from :`$LINE_START` to :`$LINE_END` using `$FORMATTER`
`$PATH2` formatting `$LANGUAGE` block from :`$LINE_START` to :`$LINE_END` using `$FORMATTER`
`$PATH2` formatting `$LANGUAGE` block from :`$LINE_START` to :`$LINE_END` using `$FORMATTER`
`$PATH2` finished in `$DURATION`ms (unchanged)

`$PATH3` formatting `$LANGUAGE` block from :`$LINE_START` to :`$LINE_END` using `$FORMATTER`
`$FORMATTER_NAME` not found in path
`$PATH3` finished in `$DURATION`ms (unchanged)

I am thinking that the formatter error could look something like this

$PATH error formatting using $FORMATTER_NAME

For reference these are the existing ones.

Formatter info (debug):

$PATH formatting $LANGUAGE block from :$LINE_START to :$LINE_END using $FORMATTER

Finished changed (info):

$PATH finished in $DURATIONms

Finished unchanged (info, but dimmed):

$PATH finished in $DURATIONms (unchanged)

Missing binary (warn):

$FORMATTER_NAME not found in path

[hougesen]

I tried playing around with formatter stderr on by default but it was a bit messy since some formatters (looking at you taplo) spam stderr.

[hougesen]

Something like this

The formatting X using Y is actually dimmed but my terminal/neovim is not rendering it correctly.

[ccoVeille]

One thing I noticed locally is that mdsf now reports warning about missing formatter:

• multiple time (each time it tries to get one)
• multime time per markdown file if there are multiple blocks of the same type
• even if another formatter is found

For example, I don't have goimports locally, I don't need it as I use gofumpt that superseeds it

But I get this error message

'goimports' not found in path

Thus, the message is displayed each time I launch the formatter even on a formatted text

whatever.md finished in 1581ms

whatever.md formatting 'go' block from :226 to :234 using goimports
'goimports' not found in path
whatever.md formatting 'go' block from :226 to :234 using gofumpt
whatever.md finished in 4ms

I would expect to have something like that

For example, this file is not formatted

[debug] whatever.md formatting 'go' block from :226 to :234 using gofumpt
[info] whatever.md finished in 4ms

Here there is no need to warn there that goimports was not found.

Then when running mdsf again on same file

[debug] whatever.md formatting 'go' block from :226 to :234 was already formatted (gofumpt)
[info] whatever.md 0ms (unchanged)

I would only expect to see a warning when there is NO formatter found for a block

[debug] whatever.md formatting 'go' block from :226 to :234
[warn] whatever.md no formatter available for 'go' block: [goimports, gofumpt, gofmt]
[info] whatever.md 0ms (unchanged)

[hougesen]

I am still not happy with the way warnings/errors are reported.

You are right that missing formatters could all be printed after, or omitted unless all are missing. It all kinda depends on the expected user behaviour, but since we are only 2 users (i think? 🤷🏼).

If the user is using mdsf without a config I don't really see a need for printing missing formatters since they haven't actually configured anything. Users with configs might want to know that their tool is missing?

From a code perspective printing before is a lot easier since it is sequential and no state is needed.

I am thinking about adding support for linters, which would be a lot harder when printing after, since I would have to hijack stderr of the process instead of just letting it inherit.

One thing I noticed locally is that mdsf now reports warning about missing formatter .. multiple time (each time it tries to get one)

It actually did that before if you had --debug on.

I would only expect to see a warning when there is NO formatter found for a block

(This might be completely unrelated to what you meant, I just got on a roll 😁)

The way the formatter config works (or atleast should 😅) is that a single level list tries to format using all tools

{
  "go": ["goimports", "gofumpt", "gofmt"]
}

which would translate to

flowchart TB
    goimports["format using goimports"]
        --> gofumpt["format using gofumpts"]
        --> gofmt["format using gofmt"]
        --> exit

Loading

Whereas nested list are used for fallbacks

{
  "go": [["goimports", "gofumpt", "gofmt"]]
}

flowchart TB
    goimports["format using goimports"]
    gofumpt["format using gofumpts"]
    gofmt["format using gofmt"]

    exit["exit"]

    goimports --> success1["success?"]

    success1 -- true --- exit
    success1 -- false --- gofumpt

    gofumpt --> success2["success?"]

    success2 -- true --- exit
    success2 -- false --- gofmt

    gofmt --> exit

Loading

The reason behind this architecture is rooted in python, where you might have a tool for sorting your imports (isort, usort) and a different for formatting (black, yapf, etc).

A "common" config could look something like this

{
  "python": [
    ["usort", "isort"],
    ["black", "yapf"]
  ]
}

Which would mean

flowchart TB
    usort
    isort

    black
    yapf

    exit

    usort --> success1["success?"]
    success1 -- true --- black
    success1 -- false --- isort

    isort --> success2["success?"]
    success2 -- true --- black
    success2 -- false --- black

    black --> success3["success?"]
    success3 -- true --- exit
    success3 -- false --- yapf

    yapf --> exit

Loading

Missing formatters should most likely be merged/omitted for nested blocks if atleast one succeeds, but flat lists should warn.