Comments (10)
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.
from mdsf.
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
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
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
Missing formatters should most likely be merged/omitted for nested blocks if atleast one succeeds, but flat lists should warn.
from mdsf.
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"
from mdsf.
Do you mean printing that formatting with a formatter failed, or the actual formatting error?
from mdsf.
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
from mdsf.
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
from mdsf.
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$DURATION
ms
Finished unchanged (info, but dimmed):
$PATH
finished in$DURATION
ms (unchanged)
Missing binary (warn):
$FORMATTER_NAME
not found in path
from mdsf.
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.
from mdsf.
Something like this
The formatting X using Y
is actually dimmed but my terminal/neovim is not rendering it correctly.
from mdsf.
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)
from mdsf.
Related Issues (20)
- Add support for rstfmt HOT 4
- Add support for dotenv-linter
- Add support for elvis
- mdsf applies changes outside code snippet HOT 9
- Feature request: implement a timeout when running formatter HOT 10
- every processing time are now reported as 0ms since 0.0.2 HOT 2
- Feature request: add a verbose (or debug mode) HOT 4
- invalid JSON is being produced once formatted HOT 4
- golang formatter: problem when code snippet is not a full file HOT 7
- Add support for "http" HOT 1
- Check go snippets for commented out package
- issue shell block quote is not always directly about formatting shell scripts HOT 3
- possible ideas and aliases sources HOT 5
- Report missing formatter HOT 4
- Add link to formatters HOT 1
- add links to competitors HOT 3
- consider adding a homebrew tap to provide your tool HOT 2
- Documentation: add the list of fenced block you support in the README file HOT 4
- Feature request: add a `--dry-run` mode
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mdsf.