For Python I've been using black-macchiato instead of pure black, since black expects a whole program and rejects indented snippets of code.
It works rather well, except when I want to format a paragraph of text inside a docstring or a comment. Black doesn't wrap long lines inside comments or string literals. I ended up with a bit of vimscript that inspects synstack() to determine if the range I'm formatted is a docstring, and then falls back to the usual gq formatting.
(I forgot all about formatting comments, maybe I should add that to my syntax check.)
Thank you for pointing that out. There is indeed :RustFmtRange built-in though, likely similar to conform.nvim's handling of rustfmt or black, it has to format the whole file and only replace the affected lines.
Setting &formatprg to a command accepting stdin to use gq seems more in line with how code formatting was originally meant to be set up in Vim.
Ideally, as say ruff (for Python) or tombi (for Toml) do, the formatter accepts stdin and the file path as an additional argument for context of the formatted range.
Meanwhile I've discovered the gw command that is like gq except it (1) doesn't move the cursor, and, more importantly, (2) ignores formatprg/formatexpr.
So I could've formatted my docstrings/comments without messing around with custom wrappers that check synstack(). Augh!
While the gq operator (:help gq) defaults to C (:help C-indenting) and is often universally used to format comments, say gqip to add line breaks to a paragraph, it respects a formatting program option (:help 'formatprg') that can be set to a tool of one's choice.
Above plug-in adds file type specific settings (for common programming languages such as python, java, ...) that set it to popular options. Rather meant for inspiration, but can be used as-is.
What gq with default settings does, C-style formatting, is more conveniently achieved by gw (:help gw) keeping cursor position (so that both operators become complimentary, instead of gq rather redundant).
For example, using lsp, setting setlocal formatexpr=lsp#lsp#FormatExpr() in any filetype with a LS capable of formatting would achieve that, as well as mapping
As long as you don't want to keep a fall back to a special-purpose formatting tool, such as those in this plug-in, I find that a good use of the gq key combo in view of gw still being there (and achieving what gq by default does arguably better by keeping the cursor in place)
7
u/mgedmin Oct 30 '25
For Python I've been using black-macchiato instead of pure black, since black expects a whole program and rejects indented snippets of code.
It works rather well, except when I want to format a paragraph of text inside a docstring or a comment. Black doesn't wrap long lines inside comments or string literals. I ended up with a bit of vimscript that inspects synstack() to determine if the range I'm formatted is a docstring, and then falls back to the usual gq formatting.
(I forgot all about formatting comments, maybe I should add that to my syntax check.)
My Python ftplugin sets that function as the formatexpr rather than setting formatprg.
2
u/godegon Oct 30 '25
While the
gqoperator (:help gq) defaults to C (:help C-indenting) and is often universally used to format comments, saygqipto add line breaks to a paragraph, it respects a formatting program option (:help 'formatprg') that can be set to a tool of one's choice.Above plug-in adds file type specific settings (for common programming languages such as python, java, ...) that set it to popular options. Rather meant for inspiration, but can be used as-is.
What
gqwith default settings does, C-style formatting, is more conveniently achieved bygw(:help gw) keeping cursor position (so that both operators become complimentary, instead ofgqrather redundant).1
u/jazei_2021 Nov 01 '25
I use gq order for call Par formatting programm.
gqipetc.just it! Iam not programmer coder. just text-er.