Bracket-Pair-Colorizer-2 VS el-patch

The original developer doesn't sound too worried and seems to have collaborated on the feature: https://github.com/CoenraadS/Bracket-Pair-Colorizer-2/issues...

Plus it helps him getting rid of 399 open issues.

It works mostly, but there are still a few bugs, such as escaped brackets in Python's f-strings not working, as noted in CoenraadS/Bracket-Pair-Colorizer-2#156 (the issue I was originally looking up).

Is there a way to do something like what they have in VSCode? https://github.com/CoenraadS/Bracket-Pair-Colorizer-2

I also tweak that function for similar reasons. I personally use el-patch for that: https://github.com/radian-software/el-patch. This way, at least we can ensure our redefinition does not get out of step with the original. Anyway, I also find it hard to do otherwise, because we need the match data at the correct point, so just advising the function becomes tricky.

Check out el-patch--if I understand what you're trying to do, it's designed for exactly this use case!

Yeah and even in personal config one could use el-patch[1], to make monkeypatching future proof.

[1] https://github.com/raxod502/el-patch

Speaking for myself, I have a lot of (use-package some-package :config (defun some-package-function-I-want-to-override (...) ...)) in my config file, which works well enough to override package definitions. In case you don't use use-package, then (eval-after-load 'some-package '(defun ...)) also works. I also use a lot of advice. Although I don't use it, https://github.com/raxod502/el-patch provides a more structured approach to patching definitions using a novel sexpy patch format.