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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Tue, 30 Apr 2019 20:38:02 UTC

Severity: wishlist

Found in version 27.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35508 <at> debbugs.gnu.org
Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks
Date: Mon, 13 May 2019 09:29:36 -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.

How 'bout 42, then?

More seriously: since I don't want `t` to be equivalent to the maximum
depth, there are 2 numbers to be "remembered".  In order to follow the
same convention as add-function, I'd really much prefer to keep 100 as
the maximum.  As for the value corresponding to `t`, I'm definitely not
wedded to 90, it could be any value in the ]0,100[ interval.
66?  50?  10?  99?  π?

>> Also I think it's important to use the same convention as for add-function.
> We can always document that in comments.

Will do.

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

I think that'd be more trouble than it's worth.
But I'll warn against using 100 (or -100), in the doc.


        Stefan




This bug report was last modified 5 years and 353 days ago.

Previous Next


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