GNU bug report logs - #35508
27.0.50; Fine-ordering of functions on hooks

Previous Next

Full log

Message #14 received at 35508 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 35508 <at> debbugs.gnu.org
Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks
Date: Wed, 01 May 2019 21:00:21 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 30 Apr 2019 16:37:08 -0400
> 
> Occasionally it's important to control the relative ordering of
> functions on hooks.  It's usually a bad idea, but sometimes alternatives
> are worse.

Could you please give a couple of examples?  I agree that it's usually
a bad idea, so maybe we should resist the temptation.  If the worse
comes to worst, a Lisp program could concoct the entire hook list in
any order it sees fit, right?

> +The place where the function is added depends on the DEPTH
> +parameter.  DEPTH defaults to 0.

So from now on, omitting DEPTH will not necessarily put the function
at the beginning of the hook list?  That's backward-incompatible, no?

In any case, this default is insufficiently tested by the tests you
propose.

>                                         By convention, should be
> +a number between -100 and 100 where 100 means that the function
> +should be at the very end of the list, whereas -100 means that
> +the function should always come first.  When two functions have
> +the same depth, the new one gets added after the old one if
> +depth is strictly positive and before otherwise.

So using 100 more than once makes the last one "win"?

> +For backward compatibility reasons, a symbol other than nil is
> +interpreted as a DEPTH of 90.

This is not explicitly tested by the test.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.