Add option to define a selection of MouseButtons to ignore

[Pietrrrek]

Replaces #214

[simonwep]

Thank you very much, what do you think of swapping the option into explicitly listing buttons via mouseButtons that can be used? I would say by default you only want to enable the primary button.

[Pietrrrek]

That is probably the more correct approach considering the approach that is taken in the rest of the config (enabling over disabling).

The current implementation ensures backwards compatibility. Consumers of this package may safely update the dependency without having to tweak existing code, I'd say that the decision is up to you given that you're the main maintainer :^)

I'd gladly contribute such a change if you decide to go for it, I could also add support for modifier buttons (such that e.g. only CTRL + LMB triggers selection)

[simonwep]

The current implementation ensures backwards compatibility. Consumers of this package may safely update the dependency without having to tweak existing code, I'd say that the decision is up to you given that you're the main maintainer :^)

Yeah, I didn't really follow semver considering this is one of my oldest projects. I'd actually take the breaking change in exchange for a cleaner config and add a note in the release notes.

I'd gladly contribute such a change if you decide to go for it, I could also add support for modifier buttons (such that e.g. only CTRL + LMB triggers selection)

That'd be awesome, not sure how I'd represent these combination in the config though - this can quickly get complicated if you, for example, only want to have to press CTRL if you're using the second button. I think, for now, having a positive mouseButtons config,

[Pietrrrek]

Take a look at how I've structured the config and let me know if you'd like any changes. It might also be a good idea to use strings (primary | auxiliary | secondary ...) instead of the numbers from MouseEvent.button (0 | 1 | 2 ... , respectively).

Edit; on second thought, I'm really now sure whether strings would be better as that may give the impression that the library provides it's own definitions of mouse buttons and that it maps it to the space of MouseEvent.button, which of course is not the case (and probably shouldn't be). The usage of strings would provide a thin layer of abstraction, but in this case it may be misleading - I think that using the numeric values forces the consumers of the library to understand the underlying data-model of the event, which is necessary anyways when working with events in JS.

[simonwep]

Thank you very much for your contribution, I'll release a new version soon with these changes :) Happy holidays!