* bug#33601: 26; Add macro `with-hook-added' [not found] ` <<20181204184614.2049.qmail@mail.muc.de> @ 2018-12-04 19:18 ` Drew Adams 2018-12-04 20:10 ` Alan Mackenzie 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2018-12-04 19:18 UTC (permalink / raw) To: Alan Mackenzie, Drew Adams; +Cc: 33601 > > Enhancement request: Please consider adding a macro such as this, to > > facilitate temporary use of a hook function. > > > (defmacro with-hook-added (hook function &rest body) > > "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION." > > (declare (indent 1) (debug t)) > > `(unwind-protect (progn (add-hook ',hook ',function) ,@body) > > (remove-hook ',hook ',function))) > > Just a big point: you need to test whether FUNCTION is already on HOOK > at the start, and if so, not remove it at the end. Hi Alan, A big point? Need to? That wasn't the behavior I had in mind for this, but it's another possibility. I intended to provide only for the behavior of always removing at the end. There are in fact several different possibilities for such a macro. We could provide also for `add-hook' args APPEND and LOCAL. I left that out as well. Choices: 1. Provide a single macro for all such possibilities, with 3 (mandatory) args for APPEND, LOCAL and whether to remove FUNCTION at the end if it was already present at the outset. 2. Provide multiple macros, each specific for a given case. #2 would mean 8 macros, to cover all the combinations (nil or t for each of the 3 args). Another possibility would be to accept a single arg for the BODY code, instead of that being a &rest parameter, and so be able to provide those 3 behavior-specifying args as optional. In that case, we'd want to decide on the best order among those args, e.g., based on which we expect to be used most often. I'm not sure what the right approach is. I think the most common use case would be the one I wrote up (but I don't know that): . Always remove FUNCTION at the end . Prepend, not append. . Global, not local. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-04 19:18 ` bug#33601: 26; Add macro `with-hook-added' Drew Adams @ 2018-12-04 20:10 ` Alan Mackenzie 2018-12-04 21:22 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Alan Mackenzie @ 2018-12-04 20:10 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 Hello, Drew. On Tue, Dec 04, 2018 at 11:18:29 -0800, Drew Adams wrote: > > > Enhancement request: Please consider adding a macro such as this, to > > > facilitate temporary use of a hook function. > > > (defmacro with-hook-added (hook function &rest body) > > > "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION." > > > (declare (indent 1) (debug t)) > > > `(unwind-protect (progn (add-hook ',hook ',function) ,@body) > > > (remove-hook ',hook ',function))) > > Just a big point: you need to test whether FUNCTION is already on HOOK > > at the start, and if so, not remove it at the end. > Hi Alan, > A big point? Need to? I think so, yes. The essence of the `with-...' macros is that they temporarily change something, then evaluate ,@body, and at the end, the something is restored to what it was. If with-hook-added didn't preserve the hook, it would be an anomaly, an outlier, and quite possibly a PITA. > That wasn't the behavior I had in mind for this, but it's > another possibility. I intended to provide only for the > behavior of always removing at the end. Why? What's the use case? > There are in fact several different possibilities for such > a macro. We could provide also for `add-hook' args APPEND > and LOCAL. I left that out as well. > Choices: > 1. Provide a single macro for all such possibilities, with > 3 (mandatory) args for APPEND, LOCAL and whether to remove > FUNCTION at the end if it was already present at the outset. > 2. Provide multiple macros, each specific for a given case. > #2 would mean 8 macros, to cover all the combinations > (nil or t for each of the 3 args). How many of these would actually be of any use? > Another possibility would be to accept a single arg for > the BODY code, instead of that being a &rest parameter, > and so be able to provide those 3 behavior-specifying > args as optional. In that case, we'd want to decide on > the best order among those args, e.g., based on which we > expect to be used most often. > I'm not sure what the right approach is. I think the > most common use case would be the one I wrote up (but > I don't know that): > . Always remove FUNCTION at the end > . Prepend, not append. > . Global, not local. -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-04 20:10 ` Alan Mackenzie @ 2018-12-04 21:22 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2018-12-04 21:22 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 33601 > > > Just a big point: you need to test whether FUNCTION is already on > > > HOOK at the start, and if so, not remove it at the end. > > > A big point? Need to? > > I think so, yes. The essence of the `with-...' macros is that they > temporarily change something, then evaluate ,@body, and at the end, the > something is restored to what it was. > > If with-hook-added didn't preserve the hook, it would > be an anomaly, an outlier, and quite possibly a PITA. If there's an unwritten rule that `with-*' macros preserve and restore everything then clearly the macro I proposed was not a `with-*' macro. Another name for it would be fine, if that's the rule. ;-) > > That wasn't the behavior I had in mind for this, but it's > > another possibility. I intended to provide only for the > > behavior of always removing at the end. > > Why? What's the use case? The kind of thing I showed (with two examples). Yes, I would use them where I either know that the function is not on the hook already or I don't care - cases where I would want it removed at the end in any case. And yes, given your question, the doc of such a macro would need to make clear that it always removes FUNCTION from the hook afterward. > > Choices: > > 1. Provide a single macro for all such possibilities, with > > 3 (mandatory) args for APPEND, LOCAL and whether to remove > > FUNCTION at the end if it was already present at the outset. > > 2. Provide multiple macros, each specific for a given case. > > > > #2 would mean 8 macros, to cover all the combinations > > (nil or t for each of the 3 args). > > How many of these would actually be of any use? All of the behaviors are useful. If you meant to ask whether it is useful to have 8 individual macros, then my answer is probably not. > > Another possibility would be to accept a single arg for > > the BODY code, instead of that being a &rest parameter, > > and so be able to provide those 3 behavior-specifying > > args as optional. In that case, we'd want to decide on > > the best order among those args, e.g., based on which we > > expect to be used most often. > > > I'm not sure what the right approach is. I think the > > most common use case would be the one I wrote up (but > > I don't know that): > > > > . Always remove FUNCTION at the end > > . Prepend, not append. > > . Global, not local. I really have no problem with what you requested: not removing FUNCTION at the end if it was present beforehand. However, now you've gone beyond that to suggest that we should restore the original hook value: "preserve the hook". Should it preserve the hook? Maybe, maybe not. How strict is your unwritten `with-*' rule? Does it apply only to undoing the particular change _it_ makes, or does it also undo changes that might be made by the BODY? In this case, the BODY might itself make changes to the hook. If I had to choose only one macro, it would probably be a general one. I guess it would, as you first requested, remove FUNCTION only if it was not already present. And it would accept args for APPEND and LOCAL. But it would not restore the original hook value. Whether it should require args APPEND and LOCAL or it should instead make you wrap body sexps in a progn is another choice. Dunno which I'd prefer, but probably the former (probably less error prone). Other ideas are welcome. What is your preference (besides always restoring the original hook value)? ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' @ 2018-12-03 18:47 Drew Adams 2018-12-03 19:01 ` Glenn Morris ` (3 more replies) 0 siblings, 4 replies; 13+ messages in thread From: Drew Adams @ 2018-12-03 18:47 UTC (permalink / raw) To: 33601 Enhancement request: Please consider adding a macro such as this, to facilitate temporary use of a hook function. (defmacro with-hook-added (hook function &rest body) "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION." (declare (indent 1) (debug t)) `(unwind-protect (progn (add-hook ',hook ',function) ,@body) (remove-hook ',hook ',function))) In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.16299 Configured using: `configure --without-dbus --host=x86_64-w64-mingw32 --without-compress-install 'CFLAGS=-O2 -static -g3'' ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 18:47 Drew Adams @ 2018-12-03 19:01 ` Glenn Morris 2018-12-03 20:58 ` Drew Adams 2018-12-03 19:03 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 1 reply; 13+ messages in thread From: Glenn Morris @ 2018-12-03 19:01 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 Drew Adams wrote: > Enhancement request: Please write "Severity: wishlist" as the first line of the message body. Also, FYI your customized bug reporting is (I assume) messing up the version number in the subject of your reports. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 19:01 ` Glenn Morris @ 2018-12-03 20:58 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2018-12-03 20:58 UTC (permalink / raw) To: Glenn Morris; +Cc: 33601 > FYI your customized bug reporting is (I assume) messing up the > version number in the subject of your reports. Thanks. Yes, in Emacs 26 vanilla emacsbug.el changed the way it reports the version number in the Subject line. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 18:47 Drew Adams 2018-12-03 19:01 ` Glenn Morris @ 2018-12-03 19:03 ` Drew Adams 2018-12-03 22:37 ` Phil Sainty [not found] ` <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> 2022-02-12 8:46 ` Lars Ingebrigtsen 3 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2018-12-03 19:03 UTC (permalink / raw) To: 33601 Maybe a better name would be `with-function-on-hook' or `with-hook-function-added'. It is the function, not the hook, that is added (to the hook). ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 19:03 ` Drew Adams @ 2018-12-03 22:37 ` Phil Sainty 2018-12-03 22:50 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Phil Sainty @ 2018-12-03 22:37 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 On 2018-12-04 08:03, Drew Adams wrote: > Maybe a better name would be `with-function-on-hook' or > `with-hook-function-added'. It is the function, not the > hook, that is added (to the hook). True, but `with-hook-added' seems consistent with the name of `add-hook' itself (which likewise isn't for creating hooks). ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 22:37 ` Phil Sainty @ 2018-12-03 22:50 ` Drew Adams 2018-12-03 23:13 ` Phil Sainty 0 siblings, 1 reply; 13+ messages in thread From: Drew Adams @ 2018-12-03 22:50 UTC (permalink / raw) To: Phil Sainty; +Cc: 33601 > > Maybe a better name would be `with-function-on-hook' or > > `with-hook-function-added'. It is the function, not the > > hook, that is added (to the hook). > > True, but `with-hook-added' seems consistent with the name of > `add-hook' itself (which likewise isn't for creating hooks). Yeah, that's why I used that name. I'm OK with any of those names mentioned so far, and probably with other alternatives too. The real question is whether such a macro is useful. I think it can be. I gave a couple examples in bug #33595. It was those examples that made me think such a macro might be useful. ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 22:50 ` Drew Adams @ 2018-12-03 23:13 ` Phil Sainty 2018-12-03 23:51 ` Drew Adams 0 siblings, 1 reply; 13+ messages in thread From: Phil Sainty @ 2018-12-03 23:13 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 On 2018-12-04 11:50, Drew Adams wrote: > The real question is whether such a macro is useful. > I think it can be. I gave a couple examples in bug > #33595. It was those examples that made me think > such a macro might be useful. I certainly think it can be useful. On a couple of occasions I've used code which does a similar thing with advice -- adding temporary advice, running a body, and removing the advice again. In both cases one could argue for a more persistent hook or advice which performs its own check to see whether it should do things, but that might also entail writing a new wrapper to perform the test, so there's appeal in a with-* approach (particularly for things which are wanted only very occasionally). -Phil ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 23:13 ` Phil Sainty @ 2018-12-03 23:51 ` Drew Adams 0 siblings, 0 replies; 13+ messages in thread From: Drew Adams @ 2018-12-03 23:51 UTC (permalink / raw) To: Phil Sainty; +Cc: 33601 > > The real question is whether such a macro is useful. > > I think it can be. I gave a couple examples in bug > > #33595. It was those examples that made me think > > such a macro might be useful. > > I certainly think it can be useful. > > On a couple of occasions I've used code which does a similar thing > with advice -- adding temporary advice, running a body, and removing > the advice again. > > In both cases one could argue for a more persistent hook or advice > which performs its own check to see whether it should do things, but > that might also entail writing a new wrapper to perform the test, so > there's appeal in a with-* approach (particularly for things which are > wanted only very occasionally). Yes to all that. A propos, I don't think advice (even nadvice) replaces the special utility of a hook, for reasons similar to those I gave in bug #33595 for why a hook is handier for that use case than is using `:exit-function' on `completion-extra-properties'. Each such function behavior-modifying tool has a purpose, even if sometimes they can substitute for each other. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org>]
* bug#33601: 26; Add macro `with-hook-added' [not found] ` <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> @ 2018-12-04 18:46 ` Alan Mackenzie 0 siblings, 0 replies; 13+ messages in thread From: Alan Mackenzie @ 2018-12-04 18:46 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 Hello, Drew. In article <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> you wrote: > Enhancement request: Please consider adding a macro such as this, to > facilitate temporary use of a hook function. > (defmacro with-hook-added (hook function &rest body) > "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION." > (declare (indent 1) (debug t)) > `(unwind-protect (progn (add-hook ',hook ',function) ,@body) > (remove-hook ',hook ',function))) Just a big point: you need to test whether FUNCTION is already on HOOK at the start, and if so, not remove it at the end. Apologies if somebody else has already pointed this out. > In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) > of 2018-05-30 > Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea > Windowing system distributor `Microsoft Corp.', version 10.0.16299 > Configured using: > `configure --without-dbus --host=x86_64-w64-mingw32 > --without-compress-install 'CFLAGS=-O2 -static -g3'' -- Alan Mackenzie (Nuremberg, Germany). ^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#33601: 26; Add macro `with-hook-added' 2018-12-03 18:47 Drew Adams ` (2 preceding siblings ...) [not found] ` <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> @ 2022-02-12 8:46 ` Lars Ingebrigtsen 3 siblings, 0 replies; 13+ messages in thread From: Lars Ingebrigtsen @ 2022-02-12 8:46 UTC (permalink / raw) To: Drew Adams; +Cc: 33601 Drew Adams <drew.adams@oracle.com> writes: > Enhancement request: Please consider adding a macro such as this, to > facilitate temporary use of a hook function. > > (defmacro with-hook-added (hook function &rest body) > "Evaluate forms in BODY with FUNCTION added to HOOK, then remove FUNCTION." > (declare (indent 1) (debug t)) > `(unwind-protect (progn (add-hook ',hook ',function) ,@body) > (remove-hook ',hook ',function))) I don't think this is generally useful enough, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-02-12 8:46 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> [not found] ` <<20181204184614.2049.qmail@mail.muc.de> 2018-12-04 19:18 ` bug#33601: 26; Add macro `with-hook-added' Drew Adams 2018-12-04 20:10 ` Alan Mackenzie 2018-12-04 21:22 ` Drew Adams 2018-12-03 18:47 Drew Adams 2018-12-03 19:01 ` Glenn Morris 2018-12-03 20:58 ` Drew Adams 2018-12-03 19:03 ` Drew Adams 2018-12-03 22:37 ` Phil Sainty 2018-12-03 22:50 ` Drew Adams 2018-12-03 23:13 ` Phil Sainty 2018-12-03 23:51 ` Drew Adams [not found] ` <mailman.5097.1543862895.1284.bug-gnu-emacs@gnu.org> 2018-12-04 18:46 ` Alan Mackenzie 2022-02-12 8:46 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.