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

Previous Next

Full log

Message #29 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: Sat, 11 May 2019 16:54:42 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 35508 <at> debbugs.gnu.org
> Date: Sat, 11 May 2019 09:26:10 -0400
> 
> >> Other objections?
> > Thanks.  Should we perhaps change 100 to 110 and 90 to 100?
> 
> You mean make it go https://en.wikipedia.org/wiki/Up_to_eleven ?  ;-)

Yes.  The idea is that 100 is easier to remember than either 90 or
110.

> > And perhaps not document the 110 value?  Just a thought.
> 
> I think we do want to document values greater than what `t` does: it can
> be important (e.g. for syntax-ppss-flush-cache) to make sure we stay
> closer to the end than those hooks appended via `t` for weaker reasons
> (e.g. because they don't want to be before some other function, although
> they don't really care if they're the very last one or not).
> 
> Also I think it's important to use the same convention as for add-function.

We can always document that in comments.

> But what I wonder is whether we should enforce the convention: currently
> we don't in add-function (and in this add-hook patch), so you can use
> a depth of 8345 if you feel like: it's really just a convention.
> 
> Also, maybe the docs should insist on the fact that 100/-100 should
> basically never be used since they imply that you're 100% sure that
> noone will ever need to come before/after you, and you can never be sure
> 100%.

We could have checkdoc complain about values we don't want to see in
application code.

Previous Next

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