Consider providing a standard way for formatters to report errors
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- vim
- Domain
- tooling
Research direction
Start by reviewing the formatter API around FormatRange() and the behavior discussed in issues #58 and #44. Clarify whether errors should be returned structurally or reported through a callback, including range-relative locations and stacked formatters. Done means codefmt consistently owns quickfix merging, clearing, populating, and hiding across supported formatters.
Written by the indexing model from the issue text.
Description
Currently, if formatters want to report errors, they update the quickfix list directly. (As shipped, only the gofmt formatter does this, but it would also make sense for e.g. google-java-format, were we to add support for that.) It would be nice to make it easier for formatters to report errors.
Additionally, we have some questions around when formatters should clear the quickfix list (e.g. #58), and I'm not sure how stacked formatters (#44) would work if formatters were managing the quickfix list individually.
I've been wondering whether formatters could pass a structured error list to codefmt somehow, and then codefmt itself could be responsible for merging/populating/hiding the quickfix list as appropriate, consistently.
As a strawman, perhaps FormatRange() (etc) could return a list of (line, column, message)? (Or accept a callback instead, if that sounds like a restrictive API? Would the line numbers be relative to the start of the range, for range formatting?)
And/or, since most formatters can get errors by looking for "file:line:column: error" on stderr, it might even be work providing a helper that handled exactly that pattern directly.
- Dominant language
- Vim Script
- Stars
- 1.1k
- Forks
- 102
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from google/vim-codefmt
-
Write a codefmt FAQ Openenhancement
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
google/vim-codefmt#53 ·
-
Add meson format Opennew formatter
Difficulty 3/5 1-2 days Newbie friendliness 45/100
google/vim-codefmt#243 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
google/vim-codefmt#240 · 1 comment ·
-
Add `:CodefmtInfo` command to report diagnostics to help users check config / diagnose problems Openenhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
google/vim-codefmt#234 · 2 comments ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 45/100
google/vim-codefmt#222 · 3 comments ·
All issues in google/vim-codefmt
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
pastelsky/bundlephobia#1122 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
anthropics/skills#1811 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
CachyOS/distribution#587 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
datalayer/mcp-compose#42 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100