Kate: Introducing the Code Formatting plugin

4 Likes

Hello,
I have some questions about the formatting plugin,

  1. How are the plugin different than the format function in the LSP plugin?

  2. Why the configuration keys in the settings are the name of the program and not the name of the language? What does mean if the key name is jq and the command for this key is ["clang-format"]?

  3. How to setup a new language for formatting, for example if I want to write a custom formatter for a not well know language, how would I set it up in the plugin?

  4. I would like to set formatOnSave: true for all file except for html files, but I couldn’t make it work, setting a formatOnSave: false per key doesn’t seem to work,

{
  "formatOnSave": true,
  "xmllint": {
    "formatOnSave": false,
    "command": ["xmllint"]
  }
}

How could I achieve that?

Thanks a lot for the formatting plugin, I think it is bound to help Kate users a lot.

Hugues

How are the plugin different than the format function in the LSP plugin?

LSP plugin relies on lsp server to do the formatting. This plugin invokes the formatter directly.

Why the configuration keys in the settings are the name of the program and not the name of the language?

Because you are configuring the formatters, not languages.

What does mean if the key name is jq and the command for this key is ["clang-format"]?

It means that “clang-format” will be the binary that the plugin will try to invoke for formatting.

How to setup a new language for formatting, for example if I want to write a custom formatter for a not well know language, how would I set it up in the plugin?

You can’t atm. The supported formatters are baked into the code. So yes, things are quite rigid atm

I would like to set formatOnSave: true for all file except for html files, but I couldn’t make it work, setting a formatOnSave: false per key doesn’t seem to work,

The formatter for html is prettier (sorry forgot to mention it in the blog). So, you will have to disable formatOnSave for prettier.


The plugin works by looking at the “highlighting mode” of a file, and then finds a formatter for the mode and then invokes it. You can see this here: addons/format/FormatterFactory.h · master · Utilities / Kate · GitLab

The plugin is still new and doesn’t support a lot of formatters and has limitations atm e.g., you can’t add new formatters at runtime, but I think for a lot of usecases it will work and I plan on improving it in the future based as needed.

Thanks a lot for trying it out.

Thanks a lot for the quick response!

Oh nice indeed it seems to work with “formatOnSave”: false on prettier, thanks

Another issue I had is when opening a file with a language not supported by the plugin, I encounter messages like these every time I save:

Format Info] Failed to run formatter. Unsupported language bash
Format Info] Failed to run formatter. Unsupported language markdown

Last year, I had an issue where the LSP plugin would run the LSP server of the highlighted language even when editing another language. For example, when using Bazel, I code in Starlark, which is essentially Python (so I use Python highlighting), but I still want to use the Bazel LSP and in this case I would also want to use Bazel formatter. Issue: bugs kde org id=474887

Also might be of interest, I was able to use another json formatter using:

{
  "formatterForJson": "compact-json",
  "compact-json": {
    "command": ["compact-json", "/dev/stdin"]
  }
}

Thanks a lot for the work you put into the plugin, and for smoothing the rough edges :slight_smile:
Hugues

So I just wanted to say thanks, because this makes my life so much better.

The only thing I’ve been missing is information about where the formatting settings are coming from. Extra CMake Modules (ECM) generates a nice clang-format file for most repositories, but not all of them. So my regular format-on-save might look a tiny bit different for files that aren’t using the generated KDE default, and I don’t have an easy way to tell which files I can rely on getting it right and which are just using the unmodified clang-format defaults.

That, and having to disable it for XML files because it’s taking out some beneficial whitespace from the existing KConfig specifications. But I guess that can be adjusted with a file-type setting as per your blog post.

Thanks again! Great stuff!

This was fixed in master a few days ago. I kind of kept the warning with the idea that when users will get warning they will complain and I will know what new formatters are needed. But yeah, it was too annoying.

Great! Yeah such configs would work as long as the original server (that you modified) also reads from stdin. The formatters that take a document path as an argument (instead of stdin) will be slightly more difficult to change like this.

It varies from server to server, but most have some kind of config file e.g., .clang-format. I am not sure if there is a way to find out which config file a formatter-tool will pick up when it runs.

However, you can just enforce the same style everywhere for clang-format if you want:

The default command for clang-format is:

"command": ["clang-format", "--fallback-style=Webkit"],

You can change it to:

"command": ["clang-format", "--style=/path/to/clang-format-file"],

to force the style you want.