[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#66752: 30.0.50; [PATCH] Add support for 'thing-at-point' to 'bug-ref
From: |
Stefan Monnier |
Subject: |
bug#66752: 30.0.50; [PATCH] Add support for 'thing-at-point' to 'bug-reference-mode' |
Date: |
Sun, 05 Nov 2023 18:20:29 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> I'm not sure. The only example I saw for adding to
>> 'thing-at-provider-alist' was for EWW (a major mode). I thought, "What
>> if someone activated and deactivated 'bug-reference-mode' and then later
>> added something to the default value of 'thing-at-provider-alist'?"
It's a general problem we have in Emacs, indeed. We have solutions for
it for the specific case of hooks (with `add/remove-hook` and their
`local` argument), and for variables holding functions (with
`add-function`), but not for anything else :-(
I've played with the idea of adding a new set of functions to help
major&minor modes set variables in a more declarative way, so that any
sequence of enabling/disabling or major/minor modes would still result
in "the right" value, and I even have some basic PoC code but nothing
good enough for `master`.
The basic idea would be something like:
(changevar-add VAR FUNCTION &optional ID LOCAL PRIO)
(changevar-remove VAR FUNCTION-OR-ID &optional LOCAL)
where `changevar-add` conceptually does something akin to
(set VAR (funcall FUNCTION (symbol-value VAR)))
and you use `changevar-remove` to set it back to its "previous" value.
But as it stands, you're trying to solve a problem in your code which
affects pretty much every other minor mode out there, so I think it's OK
to just disregard the problem, like everyone else has done until now.
Maybe you can even get away with modifying the variable globally and
not removing the entry when the mode is disabled.
Stefan