[Testers needed] General refactor on new branch

[kylechui]

I've shifted around the code quite a bit on refactor-code, as well as introduced a bunch of comments that make use of Sumneko's type annotating system. I've been meaning to do this as a way to "prepare" for the (presumably large) changes that might crop up next week due to #60. It's already passed all of my automated tests, but I would appreciate it very much if people could test out this branch's stability with respect to their average workflows. I don't want to merge it into main just for it to break a bunch of things. Thanks everyone!

Edit: I'll be doing a review of all of the changes that I've made sometime tomorrow, to make sure that all of the changes that I've made to the code base have only changed the plumbing and none of the porcelain :)

Known "breaking changes":

• When inserting a new character to surround, "ad-hoc" insertions as per #59 is no longer the default [intentional]
• utils.get_input(prompt) has been deprecated due to dependency loops; please use vim.fn.input({ prompt = prompt }) instead

[andrewferrier]

I don't mind doing some testing, but you haven't mentioned the name of the branch ;)

[kylechui]

Oops, the branch is refactor-code; it should be linked to this issue as a pending PR

[kylechui]

On a semi-unrelated note: would it be preferred to have a discussion page or issue for breaking changes?

[andrewferrier]

Just did some testing. The only issue I could find:

• Doing ysiw* (on an unconfigured pair, in other words) is a no-op - nothing appears. I'm not sure where you are with #59 and its relationship to this branch, but just for your awareness - not sure if this is a bug at this stage.

Otherwise, it seems pretty solid to me.

[kylechui]

@andrewferrier I've noted that this is a breaking change in the top-level comment of this issue thread, and will probably merge that feature into this PR since it's reasonably small

[andrewferrier]

On a semi-unrelated note: would it be preferred to have a discussion page or issue for breaking changes?

I think an issue seems to be the evolving convention. NeoVim does that, null-ls does that, treesitter does that, and I'm pretty sure a few other plugins do that. It's easy to subscribe to.

Note also that I think another convention is to add a ! to your conventional commits. e.g. feat! Did some stuff that broke things. I think that packer.nvim at least then highlights them specially.