[vim/vim] setting formatprg in $VIMRUNTIME/ftplugin/*.vim (Issue #16807)

[Enno]

Since there's :help gw to format without &formatprg as an alternative to the better kown gq, how about setting some defaults in $VIMRUNTIME/ftplugin/*.vim ? For example, gofmt as in #16804 is a natural choice whereas for others there's not such a standard but maybe still more useful than internal formatting, say in markup files such X/HTML, JSON, YAML ...

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807@github.com>

Konfekt created an issue (vim/vim#16807)

Since there's :help gw to format without &formatprg as an alternative to the better kown gq, how about setting some defaults in $VIMRUNTIME/ftplugin/*.vim ? For example, gofmt as in #16804 is a natural choice whereas for others there's not such a standard but maybe still more useful than internal formatting, say in markup files such X/HTML, JSON, YAML ...

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807@github.com>

[Maxim Kim]

for json we can use "builtin" formatter:

import autoload 'dist/json.vim'
setl formatexpr=json.FormatExpr()

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703481116@github.com>

habamax left a comment (vim/vim#16807)

for json we can use "builtin" formatter:

import autoload 'dist/json.vim'
setl formatexpr=json.FormatExpr()

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703481116@github.com>

[Enno]

Yes, true, thank you for that, on latest Vim. That's yet rather an exception though and may be dependent on the whole formatter being implemented in Vimscript. The idea was rather that if a common executable is found, say gofmt for Go, then this is used; otherwise keep it as is

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703648534@github.com>

Konfekt left a comment (vim/vim#16807)

Yes, true, thank you for that, on latest Vim. That's yet rather an exception though and may be dependent on the whole formatter being implemented in Vimscript. The idea was rather that if a common executable is found, say gofmt for Go, then this is used; otherwise keep it as is

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703648534@github.com>

[Phạm Bình An]

whereas for others there's not such a standard but maybe still more useful than internal formatting, say in markup files such X/HTML, JSON, YAML ...

While I like the idea of a more out-of-the box Vim, I think we should be careful with such cases. If those formaters are abandoned, Vim will be stuck with them for backward compatibility.

gofmt for Golang and raco -f for Racket are safer choice for default because they are maintained by the maintainers of the language itself (aka they are official)

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703847635@github.com>

brianhuster left a comment (vim/vim#16807)

whereas for others there's not such a standard but maybe still more useful than internal formatting, say in markup files such X/HTML, JSON, YAML ...

While I like the idea of a more out-of-the box Vim, I think we should be careful with such cases. If those formaters are abandoned, Vim will be stuck with them for backward compatibility.

gofmt for Golang and raco -f for Racket are safer choice for default because they are maintained by the maintainers of the language itself (aka they are official)

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703847635@github.com>

[Enno]

True as well, but file type specific formatters are still more useful then Vim internal formatter if they don't happen to have a C syntax. I just tested with HTML and I don't see any use case other than breaking comment lines

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703859824@github.com>

Konfekt left a comment (vim/vim#16807)

True as well, but file type specific formatters are still more useful then Vim internal formatter if they don't happen to have a C syntax. I just tested with HTML and I don't see any use case other than breaking comment lines

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2703859824@github.com>

[Romain Lafourcade]

We debated doing just that for javascript but there are too many options available and too many ways to use or not use them. Coming up with a working piece of vimscript wouldn't be that difficult but maintaining it over time would be challenging and it wouldn't be possible to do everything automatically anyway: you would have to expose some options… that nobody would know about because nobody reads the doc.

I quite like the "compiler" mechanism and I wonder if it would be a good idea to design a similar "formatter" mechanism, where Vim comes with a number of scripts under $VIMRUNTIME/formatter/ that define &formatexpr or &formatprg, etc. properly, and users can do :formatter foobar.

Users still have to know about the feature, of course, but that would save a bit on the logic and the maintenance.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745138077@github.com>

romainl left a comment (vim/vim#16807)

We debated doing just that for javascript but there are too many options available and too many ways to use or not use them. Coming up with a working piece of vimscript wouldn't be that difficult but maintaining it over time would be challenging and it wouldn't be possible to do everything automatically anyway: you would have to expose some options… that nobody would know about because nobody reads the doc.

I quite like the "compiler" mechanism and I wonder if it would be a good idea to design a similar "formatter" mechanism, where Vim comes with a number of scripts under $VIMRUNTIME/formatter/ that define &formatexpr or &formatprg, etc. properly, and users can do :formatter foobar.

Users still have to know about the feature, of course, but that would save a bit on the logic and the maintenance.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745138077@github.com>

[Enno]

While the compiler is switched many times while editing a buffer, that's less the case for the formatter.

Similar to folding, maybe the most cautious and still useful approach for those interested could be documenting a global variable g:ft_javascript_formatter = 'prettier' and then refer to $VIMRUNTIME/ftplugin/javascript.vim to adapt to one's personal liking in $HOME/.vim/ftplugin/javascript.vim.

But then, why should there be in Vim defaults, which are always opinionated, for C, but not other languages?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745144755@github.com>

Konfekt left a comment (vim/vim#16807)

While the compiler is switched many times while editing a buffer, that's less the case for the formatter.

Similar to folding, maybe the most cautious and still useful approach for those interested could be documenting a global variable g:ft_javascript_formatter = 'prettier' and then refer to $VIMRUNTIME/ftplugin/javascript.vim to adapt to one's personal liking in $HOME/.vim/ftplugin/javascript.vim.

But then, why should there be in Vim defaults, which are always opinionated, for C, but not other languages?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745144755@github.com>

[Phạm Bình An]

But then, why should there be in Vim defaults, which are always opinionated, for C, but not other languages?

Because C is directly used by the Vim project, so whatever built-in plugin for it will be better maintained.

Even VSCode doesn't ship most filetype supports by default (except for filetype detector and syntax highlighting, I guess), instead they make it easy to discover and install filetype-specific extensions.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745152871@github.com>

brianhuster left a comment (vim/vim#16807)

But then, why should there be in Vim defaults, which are always opinionated, for C, but not other languages?

Because C is directly used by the Vim project, so whatever built-in plugin for it will be better maintained.

Even VSCode doesn't ship most filetype supports by default (except for filetype detector and syntax highlighting, I guess), instead they make it easy to discover and install filetype-specific extensions.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745152871@github.com>

[Enno]

C will be better maintained.

Yes, better maintenance, and here for the formatprg of most other file types this is rather the question of > 0 maintenance.

@romainl, if understood correctly, was rather questioning if &formatprg should be set at all since there are too many options. Often one tool more popular than the others, for example Prettier for Javascript!? For Rust, rustfmt is more natural than C style formatting (now that formatprg=gofmt for Go has been merged).

Since users can fall back to gw to still have C formatting in, say Javascript, it doesn't feel too intrusive and makes Vim more welcoming for programmers of languages other than C.

I suspect that at the current state most, say Javascript programmers in Vim, either do not use gq at all or go for some plug-in with its opionated defaults.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745182797@github.com>

Konfekt left a comment (vim/vim#16807)

C will be better maintained.

Yes, better maintenance, and here for the formatprg of most other file types this is rather the question of > 0 maintenance.

@romainl, if understood correctly, was rather questioning if &formatprg should be set at all since there are too many options. Often one tool more popular than the others, for example Prettier for Javascript!? For Rust, rustfmt is more natural than C style formatting (now that formatprg=gofmt for Go has been merged).

Since users can fall back to gw to still have C formatting in, say Javascript, it doesn't feel too intrusive and makes Vim more welcoming for programmers of languages other than C.

I suspect that at the current state most, say Javascript programmers in Vim, either do not use gq at all or go for some plug-in with its opionated defaults.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745182797@github.com>

[Romain Lafourcade]

I can't speak for all "Javascript programmers" but it is generally considered best practice to use the tools and settings agreed upon at the project level rather than one's preferred tools and settings. "Configuration over convention", if you will.

One user might have jsbeautify installed globally while still having to use prettier locally because that is what is set at the project level. Or one user might have nothing at all installed globally and just iterating on a script in a directory without package.json or node_modules/, in which case doing npx prettier --stdin-filepath % upon every gq will become tiring very quickly. Or one user could work on a project where eslint --fix is used for formatting. Etc.

Ideally JavaScript/TypeScript projects should have lint and, eventually, format commands defined in package.json along with the required dependencies and eventual config files, that editors could leverage directly. But reality is more… varied, which makes inconditionnaly setting &formatprg to prettier\ --stdin-filepath\ % for all JS/TS buffers a bad idea.

Again, writing the necessary logic for choosing the right strategy for the current context is not impossible. I have 60 lines of vimscript for just that in my config and I think it is already too complicated and fragile.

One option would be to keep not defining anything for any filetype and let the user do all the work or defer it to plugin authors.

A second option would be to explicitly define &formatexpr for various filetypes, to the risk of writing faulty logic or making arbitrary choices that go against the user's best interest.

The third option that I propose, would be to provide users with a collection of built-in "formatters" to choose from. Those "formatters" would handle as little logic as needed for &formatprg to do its magic.

Note that properly setting &formatexpr and/or &formatprg is half the battle. Once that is done, either implicitly or explicitly, there is also the burden of setting up autocommands and such. Would that be part of a "formatter" or ftplugin as well? I don't know.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745204552@github.com>

romainl left a comment (vim/vim#16807)

I can't speak for all "Javascript programmers" but it is generally considered best practice to use the tools and settings agreed upon at the project level rather than one's preferred tools and settings. "Configuration over convention", if you will.

One user might have jsbeautify installed globally while still having to use prettier locally because that is what is set at the project level. Or one user might have nothing at all installed globally and just iterating on a script in a directory without package.json or node_modules/, in which case doing npx prettier --stdin-filepath % upon every gq will become tiring very quickly. Or one user could work on a project where eslint --fix is used for formatting. Etc.

Ideally JavaScript/TypeScript projects should have lint and, eventually, format commands defined in package.json along with the required dependencies and eventual config files, that editors could leverage directly. But reality is more… varied, which makes inconditionnaly setting &formatprg to prettier\ --stdin-filepath\ % for all JS/TS buffers a bad idea.

Again, writing the necessary logic for choosing the right strategy for the current context is not impossible. I have 60 lines of vimscript for just that in my config and I think it is already too complicated and fragile.

One option would be to keep not defining anything for any filetype and let the user do all the work or defer it to plugin authors.

A second option would be to explicitly define &formatexpr for various filetypes, to the risk of writing faulty logic or making arbitrary choices that go against the user's best interest.

The third option that I propose, would be to provide users with a collection of built-in "formatters" to choose from. Those "formatters" would handle as little logic as needed for &formatprg to do its magic.

Note that properly setting &formatexpr and/or &formatprg is half the battle. Once that is done, either implicitly or explicitly, there is also the burden of setting up autocommands and such. Would that be part of a "formatter" or ftplugin as well? I don't know.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745204552@github.com>

[Enno]

there is also the burden of setting up autocommands

I had a look at how Rust does it. They provide options to define autocmd's to run rustfmt on every buffer save. They make also assumptions such as enabling --unstable if available.

I think this should be up to the user though, as it's a one-liner.

Would that be part of a "formatter" or ftplugin as well? I don't know.

So maybe this is the criterion. Don't hide one-liners behind options.

built-in "formatters" to choose from. Those "formatters" would handle as little logic as needed for &formatprg to do its magic.

Okay, even though I observed little need in switching formatters during editing, I think it makes sense to define a dedicated command, say :FormatPrg fmt, that setlocal &formatprg=fmt\ ...common\ options.

I opened this issue since &formatprg, somewhat similar to :compiler, is a built-in option that seems to be not so well-known. For example, rust.vim went to great lengths defining formatting commands instead of setting &formatprg=rustfmt\ ...sensible\ options. Neither is :FormatCommand more convenient, nor does it work on text objects.

By setting some defaults, at least people would start to notice and come to conclusions and eventually some consensus.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745249109@github.com>

Konfekt left a comment (vim/vim#16807)

there is also the burden of setting up autocommands

I had a look at how Rust does it. They provide options to define autocmd's to run rustfmt on every buffer save. They make also assumptions such as enabling --unstable if available.

I think this should be up to the user though, as it's a one-liner.

Would that be part of a "formatter" or ftplugin as well? I don't know.

So maybe this is the criterion. Don't hide one-liners behind options.

built-in "formatters" to choose from. Those "formatters" would handle as little logic as needed for &formatprg to do its magic.

Okay, even though I observed little need in switching formatters during editing, I think it makes sense to define a dedicated command, say :FormatPrg fmt, that setlocal &formatprg=fmt\ ...common\ options.

I opened this issue since &formatprg, somewhat similar to :compiler, is a built-in option that seems to be not so well-known. For example, rust.vim went to great lengths defining formatting commands instead of setting &formatprg=rustfmt\ ...sensible\ options. Neither is :FormatCommand more convenient, nor does it work on text objects.

By setting some defaults, at least people would start to notice and come to conclusions and eventually some consensus.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745249109@github.com>

[David Mandelberg]

Another approach that I like is https://github.com/google/vim-codefmt. Unlike gq, it can support formatters that require the entire file, not just specific lines. And it can leave the cursor a lot closer to where it started when formatting an entire file. Getting something similar into vim itself would be great.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745350135@github.com>

dseomn left a comment (vim/vim#16807)

Another approach that I like is https://github.com/google/vim-codefmt. Unlike gq, it can support formatters that require the entire file, not just specific lines. And it can leave the cursor a lot closer to where it started when formatting an entire file. Getting something similar into vim itself would be great.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745350135@github.com>

[Enno]

And it can leave the cursor a lot closer to where it started

That's gw achieves but it does not respect &formatprg. 'A brittle workaround for gq is m'gq...g', but more stable and common winsaveview()..winrestview()`.

formatters that require the entire file

Those that do not read stdin? Or you mean require additional context? Some formatters read stdin and accept the file path as argument for additional context.

I didn't know https://github.com/google/vim-codefmt, and it looks thorough and does much more than gq, for example giving a quickfix list with all errors found during formatting.

Again, setting &formatprg is rather about making gq more useful as gw does already what every one expects better than gq by using the default formatprg and keeping cursor position.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745417651@github.com>

Konfekt left a comment (vim/vim#16807)

And it can leave the cursor a lot closer to where it started

That's gw achieves but it does not respect &formatprg. 'A brittle workaround for gq is m'gq...g', but more stable and common winsaveview()..winrestview()`.

formatters that require the entire file

Those that do not read stdin? Or you mean require additional context? Some formatters read stdin and accept the file path as argument for additional context.

I didn't know https://github.com/google/vim-codefmt, and it looks thorough and does much more than gq, for example giving a quickfix list with all errors found during formatting.

Again, setting &formatprg is rather about making gq more useful as gw does already what every one expects better than gq by using the default formatprg and keeping cursor position.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745417651@github.com>

[Enno]

There's this pull request to set &formatexpr to that of codefmt. So maybe that would be a good built-in starting point

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745418468@github.com>

Konfekt left a comment (vim/vim#16807)

There's this pull request to set &formatexpr to that of codefmt. So maybe that would be a good built-in starting point

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745418468@github.com>

[Romain Lafourcade]

It looks like most of the "formatters" in vim-codefmt either work on a range or a or buffer due the inherent limitations of the corresponding external tools. Also, the "syntax" used to define formatters seems overly complicated to me, but that is because the authors try to provide a complete polished user experience that is, IMO, off-topic, here. In other words: meh.

The initial proposal is more realistic: set a sensible &formatprg in individual ftplugins, but it has one big issue: some filetypes can have several formatters. Which one to choose? How to choose it? If we don't choose, how do we let the user choose?

Setting &makeprg and &errorformat on a per-filetype basis is problematic for the same reason, which is why we have "compilers", hence my proposal to do the same thing with "formatters".

Providing users with more polished abstractions over gq is an entirely different story.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745494560@github.com>

romainl left a comment (vim/vim#16807)

It looks like most of the "formatters" in vim-codefmt either work on a range or a or buffer due the inherent limitations of the corresponding external tools. Also, the "syntax" used to define formatters seems overly complicated to me, but that is because the authors try to provide a complete polished user experience that is, IMO, off-topic, here. In other words: meh.

The initial proposal is more realistic: set a sensible &formatprg in individual ftplugins, but it has one big issue: some filetypes can have several formatters. Which one to choose? How to choose it? If we don't choose, how do we let the user choose?

Setting &makeprg and &errorformat on a per-filetype basis is problematic for the same reason, which is why we have "compilers", hence my proposal to do the same thing with "formatters".

Providing users with more polished abstractions over gq is an entirely different story.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2745494560@github.com>

[Enno]

some filetypes can have several formatters. Which one to choose? How to choose it? If we don't choose, how do we let the user choose?

Okay, these are web dev files? Just asking how common that is outside Javascript constructs. But even if it's only Javascript, that accounts in practice for 80% or so of all written code.

Setting &makeprg and &errorformat on a per-filetype basis is problematic for the same reason, which is why we have "compilers", hence my proposal to do the same thing with "formatters".

So would :FormatPrg just set &formatprg? Or, say, also &errorformat for parsing formatter output? That would mess with :compiler, though, and formatting is not so much about linting, so undoing faulty formatting by a ShellFilterPost auto command maybe suffices for now.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2746051762@github.com>

Konfekt left a comment (vim/vim#16807)

some filetypes can have several formatters. Which one to choose? How to choose it? If we don't choose, how do we let the user choose?

Okay, these are web dev files? Just asking how common that is outside Javascript constructs. But even if it's only Javascript, that accounts in practice for 80% or so of all written code.

Setting &makeprg and &errorformat on a per-filetype basis is problematic for the same reason, which is why we have "compilers", hence my proposal to do the same thing with "formatters".

So would :FormatPrg just set &formatprg? Or, say, also &errorformat for parsing formatter output? That would mess with :compiler, though, and formatting is not so much about linting, so undoing faulty formatting by a ShellFilterPost auto command maybe suffices for now.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2746051762@github.com>

[Romain Lafourcade]

Okay, these are web dev files? Just asking how common that is outside Javascript constructs. But even if it's only Javascript, that accounts in practice for 80% or so of all written code.

The JavaScript/TypeScript ecosystem is certainly guilty of that (in addition to jsbeautify and prettier, there's also tsfmt, clang-format, etc.) but it is not the only one with those "problems". PHP has a bunch at the language level and frameworks have their own too. Java has a few, too. And so on.

I actually like the idea of having only one official $SPECIALIZED_TOOL for a given $LANGUAGE, the way Go and Rust and other recent programming languages do it, but those are the exception more than the rule. It is very cool that you can set gofmt as default formatter for the go filetype, but that approach can't be generalized. There is just too much choice out there for that.

So would :FormatPrg just set &formatprg?

First, I would stick with the pattern established by the "compiler" feature: :formatter clang-format.

Second, depending on the case, it could also set &formatexpr to something more refined than the :[range]!<cmd> you get if you only set &formatprg.

Here is how a "formatter" script could look:

" $VIMRUNTIME/formatters/prettier.vim

setlocal formatprg=npx\ prettier\ --yes\ --stdin-filepath\ %
setlocal formatexpr=format#FormatExpr()

and the related autoloaded script (this is the "universal" &formatexpr that I use everywhere in my config, defaults to the internal formatter if no &formatprg is set) :

" $VIMRUNTIME/autoload/format.vim

function! format#FormatExpr()
    if empty(&formatprg)
        return 1
    endif
    let l1 = v:lnum
    let l2 = (v:lnum + v:count) - 1
    let tempfile = tempname()
    call getline(l1, l2)->writefile(tempfile)
    let output = systemlist(expandcmd(&formatprg) .. ' < ' .. tempfile)
    if v:shell_error
        echohl WarningMsg | echo 'Shell error: ' .. v:shell_error | echohl None
        return v:shell_error
    else
        execute 'silent ' .. l1 .. ',' .. l2 .. 'd_'
        if wordcount().bytes == 0
            call setline('.', output)
        else
            execute 'silent ' .. (l1 - 1) .. 'put=output'
        endif
        return 0
    endif
endfunction

Or, say, also &errorformat for parsing formatter output?

I don't like that.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2746063710@github.com>

romainl left a comment (vim/vim#16807)

Okay, these are web dev files? Just asking how common that is outside Javascript constructs. But even if it's only Javascript, that accounts in practice for 80% or so of all written code.

The JavaScript/TypeScript ecosystem is certainly guilty of that (in addition to jsbeautify and prettier, there's also tsfmt, clang-format, etc.) but it is not the only one with those "problems". PHP has a bunch at the language level and frameworks have their own too. Java has a few, too. And so on.

I actually like the idea of having only one official $SPECIALIZED_TOOL for a given $LANGUAGE, the way Go and Rust and other recent programming languages do it, but those are the exception more than the rule. It is very cool that you can set gofmt as default formatter for the go filetype, but that approach can't be generalized. There is just too much choice out there for that.

So would :FormatPrg just set &formatprg?

First, I would stick with the pattern established by the "compiler" feature: :formatter clang-format.

Second, depending on the case, it could also set &formatexpr to something more refined than the :[range]!<cmd> you get if you only set &formatprg.

Here is how a "formatter" script could look:

" $VIMRUNTIME/formatters/prettier.vim

setlocal formatprg=npx\ prettier\ --yes\ --stdin-filepath\ %
setlocal formatexpr=format#FormatExpr()

and the related autoloaded script (this is the "universal" &formatexpr that I use everywhere in my config, defaults to the internal formatter if no &formatprg is set) :

" $VIMRUNTIME/autoload/format.vim

function! format#FormatExpr()
    if empty(&formatprg)
        return 1
    endif
    let l1 = v:lnum
    let l2 = (v:lnum + v:count) - 1
    let tempfile = tempname()
    call getline(l1, l2)->writefile(tempfile)
    let output = systemlist(expandcmd(&formatprg) .. ' < ' .. tempfile)
    if v:shell_error
        echohl WarningMsg | echo 'Shell error: ' .. v:shell_error | echohl None
        return v:shell_error
    else
        execute 'silent ' .. l1 .. ',' .. l2 .. 'd_'
        if wordcount().bytes == 0
            call setline('.', output)
        else
            execute 'silent ' .. (l1 - 1) .. 'put=output'
        endif
        return 0
    endif
endfunction

Or, say, also &errorformat for parsing formatter output?

I don't like that.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2746063710@github.com>

[David Mandelberg]

Not sure about other languages, but at least in Python, the formatter is dependent on the project, not the syntax region. E.g., if pyproject.toml exists in a parent directory and contains [tool.black], then the formatter is probably black.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755061040@github.com>

dseomn left a comment (vim/vim#16807)

Not sure about other languages, but at least in Python, the formatter is dependent on the project, not the syntax region. E.g., if pyproject.toml exists in a parent directory and contains [tool.black], then the formatter is probably black.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755061040@github.com>

[Romain Lafourcade]

Yeah I'm not sure where that idea of switching formatters within a same buffer comes from.

The usual scenario is:

1. Project is started.

2. Choices are made regarding compiler, linter, formatter, indenting, etc. and written into the configuration of the project.

3. Developers come and go, always following the conventions of the project. If the formatter is foobar, then they use foobar. Etc.

   Taking a typical front-end project as example, you would have a .editorconfig file and entries for Prettier and ESLint in the package.json, all with the expectations that the developers have their editor/IDE of choice properly configured to lint with ESLint and the settings defined for the project, format with Prettier and the eventual settings defined for the project, and indent with Editorconfig.

Now, modern editors and IDEs are all developed with user experience in mind, so users don't have to think about all that. The correct formatter is used with the relevant settings without any conscious decision from the user.

Vim is definitely not like that. Lots of third-party plugins exist to improve that experience but you are in for a lot of fiddling if you don't want to use them.

Giving users an easy way to define a formatter would certainly be an incremental improvement and I suggest we stay focused on that part.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755371407@github.com>

romainl left a comment (vim/vim#16807)

Yeah I'm not sure where that idea of switching formatters within a same buffer comes from.

The usual scenario is:

1. Project is started.

2. Choices are made regarding compiler, linter, formatter, indenting, etc. and written into the configuration of the project.

3. Developers come and go, always following the conventions of the project. If the formatter is foobar, then they use foobar. Etc.

   Taking a typical front-end project as example, you would have a .editorconfig file and entries for Prettier and ESLint in the package.json, all with the expectations that the developers have their editor/IDE of choice properly configured to lint with ESLint and the settings defined for the project, format with Prettier and the eventual settings defined for the project, and indent with Editorconfig.

Now, modern editors and IDEs are all developed with user experience in mind, so users don't have to think about all that. The correct formatter is used with the relevant settings without any conscious decision from the user.

Vim is definitely not like that. Lots of third-party plugins exist to improve that experience but you are in for a lot of fiddling if you don't want to use them.

Giving users an easy way to define a formatter would certainly be an incremental improvement and I suggest we stay focused on that part.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755371407@github.com>

[Enno]

some filetypes can have several formatters

I think there was a misunderstanding when referring to Webdev where embedded Syntax could change between, say HTML and Javascript with different formatters taken care of different syntaxes.

Now it seems that meant was that there is for every file type several formatters, every one of them formatting all embedded syntaxes

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755818653@github.com>

Konfekt left a comment (vim/vim#16807)

some filetypes can have several formatters

I think there was a misunderstanding when referring to Webdev where embedded Syntax could change between, say HTML and Javascript with different formatters taken care of different syntaxes.

Now it seems that meant was that there is for every file type several formatters, every one of them formatting all embedded syntaxes

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2755818653@github.com>

[Phạm Bình An]

I think there was a misunderstanding when referring to Webdev where embedded Syntax could change between, say HTML and Javascript with different formatters taken care of different syntaxes.

No, I'm pretty sure he meant a filetype like Python has multiple formatters like Ruff and prettier`. That is not related to "embedded syntax"

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2756895355@github.com>

brianhuster left a comment (vim/vim#16807)

I think there was a misunderstanding when referring to Webdev where embedded Syntax could change between, say HTML and Javascript with different formatters taken care of different syntaxes.

No, I'm pretty sure he meant a filetype like Python has multiple formatters like Ruff and prettier`. That is not related to "embedded syntax"

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2756895355@github.com>

[Enno]

The new :formatter feature is to be modeled after :compiler, which is invoked to switch from (inside the current buffer) the default compiler of a filetype, for example, between a builder like make and various linters, say tsc and eslint. By :compiler! the global build program of the project can be set.

How is this situation is analog to &formatprg now that there's no need to switch the formatprg of a filetype inside the current buffer (say, for different syntax portions such as Javascript and HTML, my initial mistaken assumption). Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice? For starters: #16989

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2757199787@github.com>

Konfekt left a comment (vim/vim#16807)

The new :formatter feature is to be modeled after :compiler, which is invoked to switch from (inside the current buffer) the default compiler of a filetype, for example, between a builder like make and various linters, say tsc and eslint. By :compiler! the global build program of the project can be set.

How is this situation is analog to &formatprg now that there's no need to switch the formatprg of a filetype inside the current buffer (say, for different syntax portions such as Javascript and HTML, my initial mistaken assumption). Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice? For starters: #16989

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2757199787@github.com>

[Romain Lafourcade]

The new :formatter feature is to be modeled after :compiler, which is invoked to switch from (inside the current buffer) the default compiler of a filetype, for example, between a builder like make and various linters, say tsc and eslint.

That is only one (weird, IMO) way to use it. In practice, the "builder" runs in the background, via something like $ npm run dev, and the "linter" is ran on write or manually in the editor. This means that :compiler eslint only needs to be executed once, when the buffer is created, and that would also be the case for :formatter in the common case.

Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice?

Because that means a lot more code than the one you put in your PR. Code that must be maintained, and so on.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2757339026@github.com>

romainl left a comment (vim/vim#16807)

The new :formatter feature is to be modeled after :compiler, which is invoked to switch from (inside the current buffer) the default compiler of a filetype, for example, between a builder like make and various linters, say tsc and eslint.

That is only one (weird, IMO) way to use it. In practice, the "builder" runs in the background, via something like $ npm run dev, and the "linter" is ran on write or manually in the editor. This means that :compiler eslint only needs to be executed once, when the buffer is created, and that would also be the case for :formatter in the common case.

Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice?

Because that means a lot more code than the one you put in your PR. Code that must be maintained, and so on.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2757339026@github.com>

[Phạm Bình An]

Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice?

Because such kinds of configuration is not consistent. Javascript ftplugin uses g:javascript_formatter, but Rust ftplugin use g:rustfmt_command. Also there is already an official Vim plugin for prettier https://github.com/prettier/vim-prettier

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800053302@github.com>

brianhuster left a comment (vim/vim#16807)

Why would an initial choice by the user for all filetypes by a mere variable such as javascript_formatter = 'prettier' not suffice?

Because such kinds of configuration is not consistent. Javascript ftplugin uses g:javascript_formatter, but Rust ftplugin use g:rustfmt_command. Also there is already an official Vim plugin for prettier https://github.com/prettier/vim-prettier

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800053302@github.com>

[Enno]

That's been nagging me as well as a lack of global coordination of each filetype many maintainer choosing her proper naming: for example g:ftplugin_javascript..., g:ft_javascript_.. or g:javascript_ are all possible. ftplugin_java is used by @zzzyxwvut for java, ft_man by @goweol, and the last option by many others.

It would make sense to agree to one binding convention indeed

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800392150@github.com>

Konfekt left a comment (vim/vim#16807)

That's been nagging me as well as a lack of global coordination of each filetype many maintainer choosing her proper naming: for example g:ftplugin_javascript..., g:ft_javascript_.. or g:javascript_ are all possible. ftplugin_java is used by @zzzyxwvut for java, ft_man by @goweol, and the last option by many others.

It would make sense to agree to one binding convention indeed

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800392150@github.com>

[Enno]

$ npm run dev, and the "linter" is ran on write or manually in the editor. This means that :compiler eslint only needs to be executed once

Let's assume that all developers for all languages use hot reload. Still, why does the errorformat not have to be switched back and fro between the compiler and linter? Are you assuming that the quickfix list is continually updated by npm run dev ?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800395050@github.com>

Konfekt left a comment (vim/vim#16807)

$ npm run dev, and the "linter" is ran on write or manually in the editor. This means that :compiler eslint only needs to be executed once

Let's assume that all developers for all languages use hot reload. Still, why does the errorformat not have to be switched back and fro between the compiler and linter? Are you assuming that the quickfix list is continually updated by npm run dev ?

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800395050@github.com>

[Romain Lafourcade]

Still, why does the errorformat not have to be switched back and fro between the compiler and linter? Are you assuming that the quickfix list is continually updated by npm run dev ?

$ npm run dev typically builds your project and runs it in a tight feedback loop. It is a live beast that can throw all kinds of build and runtime errors at any time, some relevant others less so. Good IDEs have the infrastructure necessary for dealing with that but Vim doesn't and the way $ npm run dev is generally implemented is not very Vim-friendly. For starters, it would have to write its output to a file as well as the console (think tee), that one could parse and ten update the quickfix in a loop. None of that is impossible, mind you, but the built-in features are not designed for that kind of usage at all.

Some plugins might offer that kind of refined workflow but, If we stick to Vim proper, the current workflow for a webdev is:

• start the dev server in a separate terminal window or in a :term, where build/runtime errors/warnings/whatever are displayed,
• edit code in Vim and run your buffer through both a linter and a formatter on :w, with the eventual errors going in the quickfix.

Vim doesn't have a built-in ready-to-use "automake" or "autoformat" or "autoreadanerrorfile" features and it wouldn't know what to do with the output of a dev server if it saw one anyway.

What it has is a very low-level and perfectly working way to define a "compiler" for the current buffer and consume its output. This means that, yes, the user must switch "compilers" if they want to actually "compile" a buffer or "lint" it. There is simply nothing higher-level built-in. Instead, users can write their own vimscript or use more powerful third-party plugins.

So I think that the discussion is going sideways a little:

• One topic is how to provide default &formatprg/&formatexpr that users can leverage via gq or their own vimscript or plugins.
• Another topic is how those things as well as &makeprg/&errorformat can be used productively at a high-level.

Regarding the first topic, we have established that setting &formatprg at the filetype level is not generalizable because some ecosystems have plenty of formatters available, unless we write a lot of specialized vimscript and make lots of assumptions about a lot of things. This lead to my proposal of mimicking the "compiler" feature with a "formatter", which would allow us to stay at a low level (with al the simplicity and ease of maintenance that comes with it), letting users and third-party plugins make use of it or not.

Regarding the second topic, making Vim "smarter" out-of-the-box would certainly be valuable for the end-user but the question is too vast. It's definitely worthwhile butit should be discussed in a dedicated thread. We can't solve every problem in one go.

I think I can find the time to draft a "formatter" PR, with a couple of formatters, this week.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800572782@github.com>

romainl left a comment (vim/vim#16807)

Still, why does the errorformat not have to be switched back and fro between the compiler and linter? Are you assuming that the quickfix list is continually updated by npm run dev ?

$ npm run dev typically builds your project and runs it in a tight feedback loop. It is a live beast that can throw all kinds of build and runtime errors at any time, some relevant others less so. Good IDEs have the infrastructure necessary for dealing with that but Vim doesn't and the way $ npm run dev is generally implemented is not very Vim-friendly. For starters, it would have to write its output to a file as well as the console (think tee), that one could parse and ten update the quickfix in a loop. None of that is impossible, mind you, but the built-in features are not designed for that kind of usage at all.

Some plugins might offer that kind of refined workflow but, If we stick to Vim proper, the current workflow for a webdev is:

• start the dev server in a separate terminal window or in a :term, where build/runtime errors/warnings/whatever are displayed,
• edit code in Vim and run your buffer through both a linter and a formatter on :w, with the eventual errors going in the quickfix.

Vim doesn't have a built-in ready-to-use "automake" or "autoformat" or "autoreadanerrorfile" features and it wouldn't know what to do with the output of a dev server if it saw one anyway.

What it has is a very low-level and perfectly working way to define a "compiler" for the current buffer and consume its output. This means that, yes, the user must switch "compilers" if they want to actually "compile" a buffer or "lint" it. There is simply nothing higher-level built-in. Instead, users can write their own vimscript or use more powerful third-party plugins.

So I think that the discussion is going sideways a little:

• One topic is how to provide default &formatprg/&formatexpr that users can leverage via gq or their own vimscript or plugins.
• Another topic is how those things as well as &makeprg/&errorformat can be used productively at a high-level.

Regarding the first topic, we have established that setting &formatprg at the filetype level is not generalizable because some ecosystems have plenty of formatters available, unless we write a lot of specialized vimscript and make lots of assumptions about a lot of things. This lead to my proposal of mimicking the "compiler" feature with a "formatter", which would allow us to stay at a low level (with al the simplicity and ease of maintenance that comes with it), letting users and third-party plugins make use of it or not.

Regarding the second topic, making Vim "smarter" out-of-the-box would certainly be valuable for the end-user but the question is too vast. It's definitely worthwhile butit should be discussed in a dedicated thread. We can't solve every problem in one go.

I think I can find the time to draft a "formatter" PR, with a couple of formatters, this week.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2800572782@github.com>

[Phạm Bình An]

Now, I feel kinda bad that I sent the PR that set go doc and go fmt.

IMO, Vim is just a text editor, it shouldn't have to face all the complexities around a language's ecosystem. Even VSCode doesn't ship a formatter by default, instead they make it very easy to install the Prettier extension, just by "search and click". I think Vim should instead ship an easy package manager (can look at Emacs' install-package) so that users could easily find and install plugins they need.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801478376@github.com>

brianhuster left a comment (vim/vim#16807)

Now, I feel kinda bad that I sent the PR that set go doc and go fmt.

IMO, Vim is just a text editor, it shouldn't have to face all the complexities around a language's ecosystem. Even VSCode doesn't ship a formatter by default, instead they make it very easy to install the Prettier extension, just by "search and click". I think Vim should instead ship an easy package manager (can look at Emacs' install-package) so that users could easily find and install plugins they need.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801478376@github.com>

[Enno]

The gq operator works on text-objects, whereas :!prettier % prints the whole file to stdout. Then most will not want to explicitly call shell commands on the command line to format a file, but expect this somewhat essential function to be more easily reachable.

Installing a plug-in in Visual Code for easy access would then correspond to setting a variable g:ft/ftplugin/_javascript_formatter.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801568923@github.com>

Konfekt left a comment (vim/vim#16807)

The gq operator works on text-objects, whereas :!prettier % prints the whole file to stdout. Then most will not want to explicitly call shell commands on the command line to format a file, but expect this somewhat essential function to be more easily reachable.

Installing a plug-in in Visual Code for easy access would then correspond to setting a variable g:ft/ftplugin/_javascript_formatter.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801568923@github.com>

[Phạm Bình An]

Installing a plug-in in Visual Code for easy access would then correspond to setting a variable g:ft/ftplugin/_javascript_formatter.

Yes, users can easily set 'formatprg' in their config. Not to say that there is already a plugin called vim-prettier

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801578234@github.com>

brianhuster left a comment (vim/vim#16807)

Installing a plug-in in Visual Code for easy access would then correspond to setting a variable g:ft/ftplugin/_javascript_formatter.

Yes, users can easily set 'formatprg' in their config. Not to say that there is already a plugin called vim-prettier

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801578234@github.com>

[Enno]

What's easy for you, must not be easy for everyone as there's also finetuning involved (&textwidth,&expandtab,&shiftwidth, ...). Few even know about &formatprg but rather rely on it being unset to use gq for adding line breaks in comments

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801639696@github.com>

Konfekt left a comment (vim/vim#16807)

What's easy for you, must not be easy for everyone as there's also finetuning involved (&textwidth,&expandtab,&shiftwidth, ...). Few even know about &formatprg but rather rely on it being unset to use gq for adding line breaks in comments

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801639696@github.com>

[Phạm Bình An]

That's why plugins exist

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801643197@github.com>

brianhuster left a comment (vim/vim#16807)

That's why plugins exist

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2801643197@github.com>

[Romain Lafourcade]

For anyone interested, I've created a PR to illustrate my idea: #17145

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2814889456@github.com>

romainl left a comment (vim/vim#16807)

For anyone interested, I've created a PR to illustrate my idea: #17145

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/2814889456@github.com>

[Enno]

Closed #16807 as completed.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/16807/issue_event/19652246424@github.com>

[Enno]

Konfekt left a comment (vim/vim#16807)

Let's shift focus to @romainl 's #17145 then

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/16807/3283795358@github.com>