feat!: Remove deprecated execution message

[primeapple]

This removes the execution message and adds a comment to the README on how to readd them via Autocommands.

Also I implemented a function to handle breaking changes. It can later be used for #48

This merges in a feature branch. I would like to collect all potential breaking changes there until we can release it all together in a version 1.0.0

[primeapple]

Hi @okuuva ,
I'd like to get your opinion on this one. Especially if we should completely remove the execution_message or if we should just remove the coloring.

I did the first here, because an execution message is a perfect example for an Autocommand, that the user can define themselves. But I'm open to other opinions.

Next thing, is there any other breaking change to add (besides #48 )? I thought about letting the user specify the save command (would remove the config options write_all_buffers, noautocmd and lockmarks). But we can also keep them to keep it simple for the user.

[okuuva]

Great job, as always!

[okuuva]

Hi @okuuva , I'd like to get your opinion on this one. Especially if we should completely remove the execution_message or if we should just remove the coloring.

I did the first here, because an execution message is a perfect example for an Autocommand, that the user can define themselves. But I'm open to other opinions.

I think we should just axe it altogether. The whole functionality is reinventing the wheel and I have a feeling the most common first edit to default config is to disable the message. I personally like it but that's what AutoCommands are for.

Next thing, is there any other breaking change to add (besides #48 )? I thought about letting the user specify the save command (would remove the config options write_all_buffers, noautocmd and lockmarks). But we can also keep them to keep it simple for the user.

Let's start with this and #48 and make the save command configurable in the next major version. I don't have any real justifications for this, it's just that I'd like to start small when introducing breaking changes. If for nothing else then to give people time to bind their plugin version to v1 before breaking more things. After a sufficient time after v1 we can introduce breaking changes as often as we like. Version numbers are cheap after all.

[okuuva]

It's not ideal that we can't use the same syntax for all package managers when it comes to version binding but I still think we should by default instruct people to pin their plugin version to the latest version using the syntax the different tools support.

[primeapple]

I applied your suggestions @okuuva . If anything doesn't work with plug or packer, we can always update it. Also we might want to remove packer alltogether instead of pckr.nvim. I honestly would rather add https://github.com/nvim-neorocks/rocks.nvim imho that's more the direction of the ecosystem.

But we can do this in a separate task. Let's merge this :)