settings very noisy

[ghost]

fmt version:

3.1.1

Expected behavior:

only used languages appear in the config

Actual behavior:

all languages appear/ most of them like "fortran-formatter": "", which is quite disturbing

I hope this is either a user error or relatively inexpensive to fix.

[sum01]

A setting for each language was on purpose.

You're saying you only want your enabled formatters to show up in the settings, and nothing else? If so, that might be doable, but I don't really see a problem with the current approach.

[ghost]

You're saying you only want your enabled formatters to show up in the settings, and nothing else? If so, that might be doable

yes that would be great

but I don't really see a problem with the current approach.

I probably will never program in nearly all of those languages 😄 but I will probably come back to some other settings of micro or other plugins one day or another. Now the fmt plugin bloats it in a way that makes it harder for me to parse for the other useful options.

Apart from that, I installed uncrustify and love it! It just works! I wanted to do something similar in sublime but it seemed a bit more involved so I am happy to see how easy it is in micro!

[sum01]

So I could remove the create_options() function, which creates empty options, but that doesn't solve this entirely. If someone uses fmt unsetall formattername then it leaves behind empty languages like you don't want.

As far as I'm aware, there isn't a DeleteOption to go with AddOption, so I'd have to edit the settings.json directly, which I'd rather not have to do, as that brings in problems of checking that the file even exists, parsing the json to not mess up other settings, and whatnot.

[ghost]

maybe just go for changing the create_options() and have it improve the current way for the 90% use case and let the deletion be an obligation of the user for the time being?
That would be a very good compromise for me at least.

[sum01]

That would technically be an "API" change, since it changes the users interaction (even if only when manipulating settings.json directly), which means I'd push to v4 when fixing this.

I'm not against making the move to v4 over something like this, but if I was going to do that then I'd want to address the issue with fmt unsetsall leaving empty options as well, instead of having to move to v5 when that is eventually fixed.

@zyedidia Is there any way of deleting an option previously created with AddOption, instead of just setting to false (or an empty string)? Something like DeleteOption?

[ghost]

not sure how many people rely on that api as of now but better safe than sorry, right.

xkcd

good to know you're not against it 👍

[sum01]

So I'm working on this at the moment, since I have no idea if/when a DeleteOption will be added. Mostly works, but something is mangling the end of the file after trying to write the changed settings.json. Unsure if it's because Micro itself is reading the file while running, or what...

[sum01]

Hmm.. If I made all of the plugin's settings into its own (Lua) file, then I could read/write/edit at-will without it getting messed up by Micro. Then that file could be included with require() and the path from configDir

That would also allow for any over-rides to dynamically call/get the editor's current settings (tab width, tabs/spaces, etc).

edit: Or maybe just parse the custom commands for some sort of identifier to insert tabwidth & whatnot.

[sum01]

Continued discussion should take place here https://gitlab.com/sum01/fmt-micro/issues/15