Age | Commit message (Collapse) | Author |
|
|
|
This makes the behavior of formatexpr more consistent with
`vim.lsp.formatexpr`; do not run vim's builtin formatter.
Problem: When conform's formatexpr is used and (range or buffer) but
conform can't do formatting and there is no LSP formatter with the
formatting capabilities, it will fall back to the (wrong) built-in
formatting, which might result in simply concatenating all the words.
This is a breaking change, reverting the behavior introduced in #55.
|
|
This is a breaking API change, but there is a shim in place that will keep existing functions working, just with a warning notification. Most people should not encounter this at all. For anyone overriding a formatter config value with a function that takes `(ctx)` as the parameter, it will need to be updated to take `(self, ctx)`.
|
|
|
|
|
|
|
|
This breaking change should make it significantly easier to modify formatters. While I expect 99% of configs to be backwards-compatible, this can still potentially cause problems. If you:
* define a formatter in the `formatters` option
* that has the same name as a built-in formatter
* and omits a property from the original formatter (e.g. leaves out `range_args` or `cwd`)
Then you may encounter breaking behavior from this commit, because now your config definition will be merged with the built-in definition, and so will inherit those omitted properties. This config merging behavior can be opted-out of by adding `inherit = false` to your formatter config.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes one the main issue with a BufWritePost format autocmd:
that if the user does `:wq` vim will exit before the formatting changes
are applied. Now we will block in VimLeavePre until the formatter
completes (or a timeout is reached).
|
|
|
|
|
|
|
|
|
|
When lsp_fallback = true AND the only formatters for the buffer are from
the "*" or "_" filetype, format with LSP instead of the "*"/"_"
formatters.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alternations are now supported. You can specify a sub-list in place of a
formatter name and conform will use the first formatter in that list
that is available. For example, this will use either prettierd or
prettier (whichever is available), and then always trim whitespace
afterwards:
conform.format(formatters = { { "prettierd", "prettier" }, "trim_whitespace" })
This syntax is available both in the formatters_by_ft config option and
in the `formatters` argument of the `format` method.
|
|
run_all_formatters is now the default. To only run the first formatter
(the previous behavior), see the next commit
|
|
|
|
|
|
* refactor: replicate lsp.buf.format call
* feat: format() takes an optional callback
* fix: improper logging
* fix: callback returns error if buffer is no longer valid
* fix: provide more detailed error message to callback
* fix: properly detect task interruption
* cleanup: remove unnecessary error code translation
* fix: lsp formatting for Neovim 0.9
* doc: add example of async formatting on save
* fix: async LSP formatter discards changes if buffer was modified
* fix: error code comparison
* fix: use the same LSP client filtering logic everywhere
* fix: add buffer validity guard checks
* fix: add buffer validity guard to LSP formatter
* refactor: change the default log level to WARN
|
|
* feat: apply changes as text edits using LSP utils
This means we can leverage all of the work that was done in the LSP
client to preserve marks, cursor position, etc
* log: add trace logging to debug performance
* feat: use the same diff -> TextEdit technique for bad LSP servers
Some LSP servers simply return a single TextEdit that replaces the whole
buffer. This is bad for extmarks, cursor, and if the buffer is open in
multiple windows the non-active window will jump to the top. We can
detect that situation and apply the same vim.diff logic to convert it
into more granular TextEdits.
|
|
|
|
|
|
|
|
|
|
Should work the same as vim.lsp.buf.format(). Additionally, range
formatting is supported for *any* formatter. If the formatter doesn't
have native support for ranges, conform will do its best to only apply the
diffs that affect that range.
|
|
|
|
I realized that there are so, so many possible features people would
want when configuring the autoformatter, but it's better to just code it
up yourself rather than try to create a config language that can
describe all possible logic. Also adding new docs to provide examples of
more advanced autoformat logic.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|