From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 30 16:37:36 2019 Received: (at submit) by debbugs.gnu.org; 30 Apr 2019 20:37:36 +0000 Received: from localhost ([127.0.0.1]:42493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLZVP-0003W0-Va for submit@debbugs.gnu.org; Tue, 30 Apr 2019 16:37:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLZVN-0003Vm-Mg for submit@debbugs.gnu.org; Tue, 30 Apr 2019 16:37:35 -0400 Received: from lists.gnu.org ([209.51.188.17]:59233) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hLZVH-00040k-8b for submit@debbugs.gnu.org; Tue, 30 Apr 2019 16:37:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLZVF-0002L4-2t for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 16:37:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLZVD-0003yT-80 for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 16:37:25 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:53696) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hLZVC-0003xo-Rm for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2019 16:37:23 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 9095C87D14EA for ; Tue, 30 Apr 2019 16:37:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:message-id:date:date :subject:subject:to:from:from; s=dkim; t=1556656640; x= 1557520641; bh=RtL/wVFpNaTk4WM0HxTk4MZsQJ44qHknFeYhrTHB+ww=; b=a KPqAnmMyDf+SAivllJCv+4cdTv9f0GXvvPUn9S5ecWrEul9cFD4WpQQjtjV1NCgc kb6ccauCAT+/UYcpQnFV5vO1+R/AlfGWN/6fU9BrebklIBYOq3IWbLl5yPATOP/6 vf/FHdzsapMprlyYlqGcl2nJKTtlvASGlm+04xVlo0Cv0gb+Enx7UKOdFNitF4Iu Y9yZcUtRA+ysemEjB1SPxfjPPOydZ21WwcWH/K9nH2ILm5zoWce7FgTgfJoudjQt 21oqaQzCJt11YHpTlFDXbUqmfB2gxl5coy8s6IJ8xx1tnuIU3eDjiuppNiaAHj4B s8yyRwU5ntdPg9isFOxtA== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VENWKq-2N6WK for ; Tue, 30 Apr 2019 16:37:20 -0400 (EDT) Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 89B3787D14E0 for ; Tue, 30 Apr 2019 16:37:19 -0400 (EDT) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 27.0.50; Fine-ordering of functions on hooks Date: Tue, 30 Apr 2019 16:37:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.201 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Package: Emacs Version: 27.0.50 Occasionally it's important to control the relative ordering of functions on hooks. It's usually a bad idea, but sometimes alternatives are worse. When such needs show up, packages usually resort to ugly tricks such as using some other hook (e.g. post-command-hook) to try and detect when the ordering was broken and re-impose the desired ordering by hand. An example I saw recently is in `c-after-font-lock-init`. A few months ago the idea came up again (tho I can't remember in which context), which finally motivated me to look at this. So, I suggest the patch below which generalizes the `append` argument of `add-hook` to a `depth` argument similar to the `depth` used in `add-function`. Any objection/comment? Stefan diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi index 97e9be9918..9d98cf64fd 100644 --- a/doc/lispref/modes.texi +++ b/doc/lispref/modes.texi @@ -142,7 +142,7 @@ Setting Hooks (add-hook 'lisp-interaction-mode-hook 'auto-fill-mode) @end example -@defun add-hook hook function &optional append local +@defun add-hook hook function &optional depth local This function is the handy way to add function @var{function} to hook variable @var{hook}. You can use it for abnormal hooks as well as for normal hooks. @var{function} can be any Lisp function that can accept @@ -167,9 +167,16 @@ Setting Hooks in which they are executed does not matter. Any dependence on the order is asking for trouble. However, the order is predictable: normally, @var{function} goes at the front of the hook list, so it is executed -first (barring another @code{add-hook} call). If the optional argument -@var{append} is non-@code{nil}, the new hook function goes at the end of -the hook list and is executed last. +first (barring another @code{add-hook} call). + +But in some cases, it is important to control the relative ordering of +functions on the hook. The optional argument @var{depth} lets you indicate +where the function should be inserted in the list: it should then be a number +between -100 and 100 where the higher the value, the closer to the end of the +list the function should go. The @var{depth} defaults to 0 and for backward +compatibility when @var{depth} is a non-nil symbol it is interpreted as a depth +of 90. Furthermore, when @var{depth} is strictly greater than 0 the function +is added @emph{after} rather than before functions of the same depth. @code{add-hook} can handle the cases where @var{hook} is void or its value is a single function; it sets or changes the value to a list of diff --git a/etc/NEWS b/etc/NEWS index f6676e0e0b..aee5d7c91a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1555,6 +1555,10 @@ never worked reliably, and now causes an error. * Lisp Changes in Emacs 27.1 +** The 'append' arg of 'add-hook' is generalized to a finer notion of 'depth' +This allows to more precisely control the ordering of functions, +as was already possible in 'add-function'. + ** New 'help-fns-describe-variable-functions' hook. Makes it possible to add metadata information to describe-variable. diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el index 3be09d87b4..3caceee279 100644 --- a/lisp/elec-pair.el +++ b/lisp/elec-pair.el @@ -564,13 +564,6 @@ electric-pair-post-self-insert-function (matching-paren (char-after)))) (save-excursion (newline 1 t))))))) -;; Prioritize this to kick in after -;; `electric-layout-post-self-insert-function': that considerably -;; simplifies interoperation when `electric-pair-mode', -;; `electric-layout-mode' and `electric-indent-mode' are used -;; together. Use `vc-region-history' on these lines for more info. -(put 'electric-pair-post-self-insert-function 'priority 50) - (defun electric-pair-will-use-region () (and (use-region-p) (memq (car (electric-pair-syntax-info last-command-event)) @@ -622,8 +615,14 @@ electric-pair-mode (if electric-pair-mode (progn (add-hook 'post-self-insert-hook - #'electric-pair-post-self-insert-function) - (electric--sort-post-self-insertion-hook) + #'electric-pair-post-self-insert-function + ;; Prioritize this to kick in after + ;; `electric-layout-post-self-insert-function': that + ;; considerably simplifies interoperation when + ;; `electric-pair-mode', `electric-layout-mode' and + ;; `electric-indent-mode' are used together. + ;; Use `vc-region-history' on these lines for more info. + 50) (add-hook 'self-insert-uses-region-functions #'electric-pair-will-use-region)) (remove-hook 'post-self-insert-hook diff --git a/lisp/electric.el b/lisp/electric.el index 07da2f1d9e..53e53bd975 100644 --- a/lisp/electric.el +++ b/lisp/electric.el @@ -190,17 +190,6 @@ electric--after-char-pos (eq (char-before) last-command-event))))) pos))) -(defun electric--sort-post-self-insertion-hook () - "Ensure order of electric functions in `post-self-insertion-hook'. - -Hooks in this variable interact in non-trivial ways, so a -relative order must be maintained within it." - (setq-default post-self-insert-hook - (sort (default-value 'post-self-insert-hook) - #'(lambda (fn1 fn2) - (< (or (if (symbolp fn1) (get fn1 'priority)) 0) - (or (if (symbolp fn2) (get fn2 'priority)) 0)))))) - ;;; Electric indentation. ;; Autoloading variables is generally undesirable, but major modes @@ -297,8 +286,6 @@ electric-indent-post-self-insert-function (indent-according-to-mode) (error (throw 'indent-error nil))))))))) -(put 'electric-indent-post-self-insert-function 'priority 60) - (defun electric-indent-just-newline (arg) "Insert just a newline, without any auto-indentation." (interactive "*P") @@ -341,8 +328,8 @@ electric-indent-mode (remove-hook 'post-self-insert-hook #'electric-indent-post-self-insert-function)) (add-hook 'post-self-insert-hook - #'electric-indent-post-self-insert-function) - (electric--sort-post-self-insertion-hook))) + #'electric-indent-post-self-insert-function + 60))) ;;;###autoload (define-minor-mode electric-indent-local-mode @@ -472,8 +459,6 @@ electric-layout-post-self-insert-function-1 ('after-stay (save-excursion (funcall nl-after))) ('around (funcall nl-before) (funcall nl-after)))))))) -(put 'electric-layout-post-self-insert-function 'priority 40) - ;;;###autoload (define-minor-mode electric-layout-mode "Automatically insert newlines around some chars. @@ -482,8 +467,8 @@ electric-layout-mode :global t :group 'electricity (cond (electric-layout-mode (add-hook 'post-self-insert-hook - #'electric-layout-post-self-insert-function) - (electric--sort-post-self-insertion-hook)) + #'electric-layout-post-self-insert-function + 40)) (t (remove-hook 'post-self-insert-hook #'electric-layout-post-self-insert-function)))) @@ -623,8 +608,6 @@ electric-quote-post-self-insert-function (replace-match (string q>>)) (setq last-command-event q>>)))))))))) -(put 'electric-quote-post-self-insert-function 'priority 10) - ;;;###autoload (define-minor-mode electric-quote-mode "Toggle on-the-fly requoting (Electric Quote mode). @@ -651,8 +634,8 @@ electric-quote-mode (remove-hook 'post-self-insert-hook #'electric-quote-post-self-insert-function)) (add-hook 'post-self-insert-hook - #'electric-quote-post-self-insert-function) - (electric--sort-post-self-insertion-hook))) + #'electric-quote-post-self-insert-function + 10))) ;;;###autoload (define-minor-mode electric-quote-local-mode diff --git a/lisp/subr.el b/lisp/subr.el index f68f9dd419..f11cbaabdc 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1602,12 +1602,20 @@ 'user-original-login-name ;;;; Hook manipulation functions. -(defun add-hook (hook function &optional append local) +(defun add-hook (hook function &optional depth local) "Add to the value of HOOK the function FUNCTION. FUNCTION is not added if already present. -FUNCTION is added (if necessary) at the beginning of the hook list -unless the optional argument APPEND is non-nil, in which case -FUNCTION is added at the end. + +The place where the function is added depends on the DEPTH +parameter. DEPTH defaults to 0. 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. + +For backward compatibility reasons, a symbol other than nil is +interpreted as a DEPTH of 90. The optional fourth argument, LOCAL, if non-nil, says to modify the hook's buffer-local value rather than its global value. @@ -1620,6 +1628,7 @@ add-hook function, it is changed to a list of functions." (or (boundp hook) (set hook nil)) (or (default-boundp hook) (set-default hook nil)) + (unless (numberp depth) (setq depth (if depth 90 0))) (if local (unless (local-variable-if-set-p hook) (set (make-local-variable hook) (list t))) ;; Detect the case where make-local-variable was used on a hook @@ -1632,12 +1641,22 @@ add-hook (setq hook-value (list hook-value))) ;; Do the actual addition if necessary (unless (member function hook-value) - (when (stringp function) + (when (stringp function) ;FIXME: Why? (setq function (purecopy function))) + (setf (alist-get function (get hook 'hook--depth-alist) + 0 'remove #'equal) + depth) (setq hook-value - (if append + (if (< 0 depth) (append hook-value (list function)) - (cons function hook-value)))) + (cons function hook-value))) + (let ((depth-alist (get hook 'hook--depth-alist))) + (when depth-alist + (setq hook-value + (sort (if (< 0 depth) hook-value (copy-sequence hook-value)) + (lambda (f1 f2) + (< (alist-get f1 depth-alist 0 nil #'equal) + (alist-get f2 depth-alist 0 nil #'equal)))))))) ;; Set the actual variable (if local (progn diff --git a/test/lisp/subr-tests.el b/test/lisp/subr-tests.el index c458eef2f9..36470d0650 100644 --- a/test/lisp/subr-tests.el +++ b/test/lisp/subr-tests.el @@ -373,5 +373,25 @@ subr-test--frames-1 (should (equal (flatten-tree '(1 ("foo" "bar") 2)) '(1 "foo" "bar" 2)))) +(defvar subr-tests--hook nil) + +(ert-deftest subr-tests-add-hook-depth () + "Test the `depth' arg of `add-hook'." + (setq-default subr-tests--hook nil) + (add-hook 'subr-tests--hook 'f1) + (add-hook 'subr-tests--hook 'f2) + (should (equal subr-tests--hook '(f2 f1))) + (add-hook 'subr-tests--hook 'f3 t) + (should (equal subr-tests--hook '(f2 f1 f3))) + (add-hook 'subr-tests--hook 'f4 50) + (should (equal subr-tests--hook '(f2 f1 f4 f3))) + (add-hook 'subr-tests--hook 'f5 -50) + (should (equal subr-tests--hook '(f5 f2 f1 f4 f3))) + (add-hook 'subr-tests--hook 'f6) + (should (equal subr-tests--hook '(f5 f6 f2 f1 f4 f3))) + (add-hook 'subr-tests--hook 'f7 t) + (should (equal subr-tests--hook '(f5 f6 f2 f1 f4 f3 f7))) + ) + (provide 'subr-tests) ;;; subr-tests.el ends here From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 30 17:37:53 2019 Received: (at 35508) by debbugs.gnu.org; 30 Apr 2019 21:37:53 +0000 Received: from localhost ([127.0.0.1]:42620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLaRl-00054W-BC for submit@debbugs.gnu.org; Tue, 30 Apr 2019 17:37:53 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:56156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLaRk-00054J-CS for 35508@debbugs.gnu.org; Tue, 30 Apr 2019 17:37:52 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3ULTH11041367; Tue, 30 Apr 2019 21:37:46 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=RGr9jZ0DDQhZPeDNSX/ff4e67eVdqT5Ir3+hzV20G7E=; b=OjXStT7/vXox39yu4ku9h6Krm0mw1vgbFxZqWvsml6y+fI5V0Vt/tdv1pqngr1bmsUBI M9Wa+QxFzsQiRtENnT4jlvGedB4MI7lQxbKb4ZjNzcNXzdxIDO9xyF7bn3Ua0qVCv7f6 bVvtpqH8Nf5kJXUQL4ozCz+baTeIlmVg+JdwTwTtx7gW7Pbky+PqvYt5RVhPt1j9THem X+2p7xP/tAbdUG7Pyt1piK54tc/yp6nSZ/OSzwwPXbAPlxnFZHACzsDMOSXOz77/jZFi PoDbN3KCQgez1ExAzqWZMI3UQPxhEds3FAh0lqf3kFmwonkUYOat6Lu6jobc7eWl1dxB 9A== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2s4fqq7296-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Apr 2019 21:37:46 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3ULaxY6055299; Tue, 30 Apr 2019 21:37:45 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2s4ew1fve7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 30 Apr 2019 21:37:45 +0000 Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x3ULbgMf005988; Tue, 30 Apr 2019 21:37:43 GMT MIME-Version: 1.0 Message-ID: <80d76085-af3c-4b74-b9ae-6f831922aa80@default> Date: Tue, 30 Apr 2019 14:37:41 -0700 (PDT) From: Drew Adams To: Stefan Monnier , 35508@debbugs.gnu.org Subject: RE: bug#35508: 27.0.50; Fine-ordering of functions on hooks References: In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9243 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=736 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904300126 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9243 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=764 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904300126 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > +But in some cases, it is important to control the relative ordering of > +functions on the hook. The optional argument @var{depth} lets you indic= ate > +where the function should be inserted in the list: it should then be a > number > +between -100 and 100 where the higher the value, the closer to the end o= f > the > +list the function should go. The @var{depth} defaults to 0 and for back= ward > +compatibility when @var{depth} is a non-nil symbol it is interpreted as = a > depth > +of 90. Furthermore, when @var{depth} is strictly greater than 0 the > function > +is added @emph{after} rather than before functions of the same depth. Commenting on just this part. If by "default" you mean that providing nil or no DEPTH arg has the same effect as providing a DEPTH of 0, then I don't think that defaulting to 0 is backward-compatible. Currently the default behavior is to prepend. Presumably 0 does not mean prepend but insert ~halfway. And currently if you provide 0 as the APPEND arg you get the effect of 100, not 0 (IIUC). I think that if you add this feature the doc should say something about an expected/possible use case - when "it is important to control the relative ordering". (I'm curious, for example, never having come across the need.) The way you describe it makes it seem like it will be common to supply a specific number rather than just appending (i.e. at the end). Will it be common to need a number other than 100? BTW, do similar considerations not apply to advice? There we have before, after, and replace, essentially. Why don't we need -100 to 100 for ordering there? (Again, just curious.) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 30 18:31:07 2019 Received: (at 35508) by debbugs.gnu.org; 30 Apr 2019 22:31:07 +0000 Received: from localhost ([127.0.0.1]:42728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLbHH-0006QB-5c for submit@debbugs.gnu.org; Tue, 30 Apr 2019 18:31:07 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:39212) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLbHF-0006Q2-49 for 35508@debbugs.gnu.org; Tue, 30 Apr 2019 18:31:06 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x3UMV2xG025291; Tue, 30 Apr 2019 18:31:03 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 26DDE66184; Tue, 30 Apr 2019 18:31:02 -0400 (EDT) From: Stefan Monnier To: Drew Adams Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <80d76085-af3c-4b74-b9ae-6f831922aa80@default> Date: Tue, 30 Apr 2019 18:31:02 -0400 In-Reply-To: <80d76085-af3c-4b74-b9ae-6f831922aa80@default> (Drew Adams's message of "Tue, 30 Apr 2019 14:37:41 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6536=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6536> : inlines <7066> : streams <1820202> : uri <2839045> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > (I'm curious, for example, never having come across the need.) Just look at the patch, it includes an example. > The way you describe it makes it seem like it will be > common to supply a specific number rather than just > appending (i.e. at the end). Will it be common to need > a number other than 100? 100 (resp -100) should almost never be used, since they basically mean that noone should ever have the right to come after (resp before), which is rather presumptuous. > BTW, do similar considerations not apply to advice? As the NEWS entry mentions, this semantics mimics that already existing in add-function (and hence advice-add). Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed May 01 14:00:49 2019 Received: (at 35508) by debbugs.gnu.org; 1 May 2019 18:00:49 +0000 Received: from localhost ([127.0.0.1]:44859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLtXE-00039i-Uc for submit@debbugs.gnu.org; Wed, 01 May 2019 14:00:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLtXD-00039X-OX for 35508@debbugs.gnu.org; Wed, 01 May 2019 14:00:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLtX7-0001k8-IR; Wed, 01 May 2019 14:00:41 -0400 Received: from [176.228.60.248] (port=2892 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hLtX2-0002Kf-LR; Wed, 01 May 2019 14:00:40 -0400 Date: Wed, 01 May 2019 21:00:21 +0300 Message-Id: <831s1iqclm.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Tue, 30 Apr 2019 16:37:08 -0400) Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed May 01 16:29:15 2019 Received: (at 35508) by debbugs.gnu.org; 1 May 2019 20:29:15 +0000 Received: from localhost ([127.0.0.1]:45032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLvqt-0006fr-0z for submit@debbugs.gnu.org; Wed, 01 May 2019 16:29:15 -0400 Received: from mail01.iro.umontreal.ca ([132.204.25.201]:50656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hLvqq-0006fd-Hk for 35508@debbugs.gnu.org; Wed, 01 May 2019 16:29:13 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 4B57487FD33A for <35508@debbugs.gnu.org>; Wed, 1 May 2019 16:29:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1556742546; x=1557606547; bh=PIA5Wax5Gzysi8AJkwoeosbI cxHJp3erHGV/Dt5m1jA=; b=hiyuS2brJqWxy1RNTJIri6yIUfeaUbh2w4+BMGIv foGeYeGvj8+4AV6/J8YcFOyfqjwtwWdaIjXGgDZILnVhcm/H5BQ+xTMWOuNE6dHl U0esPQ/EZktTAyipl6XyJl7g7Nj3Xxg4Ksor6fJ8yr10DoaW+HMSSb5TLqQL7+9T 2nV3DPPRBCzy4fNLYtB/Y9+/WdE6ZkVE8WdIDND9j8KqPK4nzr/ATYO+KrHK5hk5 EO7B3E4OILZtp2gERWRNkQUf6FE4Z1hwMhtUi8qEcCO7cYULp+LzKAWN0FQoqedr XIZSEiDoni8q0xdS9SdRtMRUHJ/mijZxjbzpxMsFe4/sOg== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQdHoSuOlHvs for <35508@debbugs.gnu.org>; Wed, 1 May 2019 16:29:06 -0400 (EDT) Received: from alfajor (unknown [167.88.24.70]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 681AE87FD314; Wed, 1 May 2019 16:29:05 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <831s1iqclm.fsf@gnu.org> Date: Wed, 01 May 2019 16:29:00 -0400 In-Reply-To: <831s1iqclm.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 May 2019 21:00:21 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> 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? The patch includes the post-self-insert-hook example, I already mentioned the after-change-functions example (where cc-mode wants his hook to come before font-lock's), and I could add the case of syntax-propertize's before-change-functions which needs to "come last". > I agree that it's usually a bad idea, so maybe we should resist the > temptation. So far people haven't resisted the temptation, but have instead worked around the lack of direct support for it, either by ad-hoc ways to detect mis-ordering and re-set the ordering accordingly, or by hoping for the best. > If the worse comes to worst, a Lisp program could concoct > the entire hook list in any order it sees fit, right? I don't understand what you mean here. >> +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? Indeed. Same for `t` not always going to the very end. > That's backward-incompatible, no? Sure. > In any case, this default is insufficiently tested by the tests > you propose. What other tests do you suggest? > So using 100 more than once makes the last one "win"? Yes. This is so that when using `t` more than once, the last one wins, just as it used to. >> +For backward compatibility reasons, a symbol other than nil is >> +interpreted as a DEPTH of 90. > This is not explicitly tested by the test. I can a test to try and check that `90` corresponds to `t`, if you want, although this property is trivially verified by looking at the code. [ I tend to prefer tests that try and catch tricky interactions rather than straightforward bases cases. E.g. the tests I included are the ones that failed during development ;-) ] Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed May 08 14:50:30 2019 Received: (at 35508) by debbugs.gnu.org; 8 May 2019 18:50:30 +0000 Received: from localhost ([127.0.0.1]:34012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hORe9-00016L-5g for submit@debbugs.gnu.org; Wed, 08 May 2019 14:50:30 -0400 Received: from mail.iro.umontreal.ca ([132.204.27.60]:11064 helo=mail01.iro.umontreal.ca) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hORe7-000168-1Y for 35508@debbugs.gnu.org; Wed, 08 May 2019 14:50:27 -0400 Received: from mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) by mail01.iro.umontreal.ca (Postfix) with ESMTP id 23CC38943CDC for <35508@debbugs.gnu.org>; Wed, 8 May 2019 14:33:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; h=content-type:content-type:mime-version:user-agent:in-reply-to :date:date:references:message-id:subject:subject:to:from:from; s=dkim; t=1557340364; x=1558204365; bh=37EiSvg+de24e4xWYltqogZq g2Ho/sM5sOvjCA3APOQ=; b=hOjfzp8BGXxZT9gjf3xsrPatUzsl7ivdQLI+Hfot bVFgNkKV5hFfz9yf5h6n3wnzoAtrrXrXcGsh1HYZTy4GdMZvGHF4E3mtOTHd9wDW rqLEpLusByfTiV+ZXSIxAR3ch30qd8nGKN0l363xzW6Xg1kQB87iz2et67HsI5lf WN3x87hxN6gXMutVSboNmURt7baSUxUqUCuG2A+UcMAomHOannYZCglmh6i1O61T xVdVrLKiYUhzu2FoMo+cWMuIaRvvq9TDLc0EMy6TktvRa8FloJXRIdFx+i+2pncF 9NnkIWoP9xC4NqiJqmSsXBORIcIdGs70GrMDDIxHdi1IPw== X-Virus-Scanned: amavisd-new at iro.umontreal.ca Received: from mail01.iro.umontreal.ca ([127.0.0.1]) by mail01.iro.umontreal.ca (mail01.iro.umontreal.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPWwhQZ_FKFJ for <35508@debbugs.gnu.org>; Wed, 8 May 2019 14:32:44 -0400 (EDT) Received: from alfajor (modemcable213.149-175-137.mc.videotron.ca [137.175.149.213]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C388D8943CA2; Wed, 8 May 2019 14:32:43 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <831s1iqclm.fsf@gnu.org> Date: Wed, 08 May 2019 14:32:43 -0400 In-Reply-To: (Stefan Monnier's message of "Wed, 01 May 2019 16:29:00 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> 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? > > The patch includes the post-self-insert-hook example, I already mentioned > the after-change-functions example (where cc-mode wants his hook to > come before font-lock's), and I could add the case of > syntax-propertize's before-change-functions which needs to "come last". I updated the patch so we use it for syntax-propertize's before-change-functions as well as a comment showing where we'd use it in cc-mode (using it in CC-mode would take more work in order to make sure it doesn't break on older Emacsen). >> If the worse comes to worst, a Lisp program could concoct >> the entire hook list in any order it sees fit, right? > I don't understand what you mean here. [ Still don't understand. ] >> That's backward-incompatible, no? > Sure. I added a note in the "incompatible changes" section of NEWS. >> In any case, this default is insufficiently tested by the tests >> you propose. > What other tests do you suggest? I added a test to make sure nil is treated like 0. >> So using 100 more than once makes the last one "win"? > Yes. This is so that when using `t` more than once, the last one wins, > just as it used to. > >>> +For backward compatibility reasons, a symbol other than nil is >>> +interpreted as a DEPTH of 90. >> This is not explicitly tested by the test. I added a test to make sure t is treated like 90. Other objections? Stefan diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi index 97e9be9918..3a2a7f6397 100644 --- a/doc/lispref/modes.texi +++ b/doc/lispref/modes.texi @@ -142,7 +142,7 @@ Setting Hooks (add-hook 'lisp-interaction-mode-hook 'auto-fill-mode) @end example -@defun add-hook hook function &optional append local +@defun add-hook hook function &optional depth local This function is the handy way to add function @var{function} to hook variable @var{hook}. You can use it for abnormal hooks as well as for normal hooks. @var{function} can be any Lisp function that can accept @@ -167,9 +167,16 @@ Setting Hooks in which they are executed does not matter. Any dependence on the order is asking for trouble. However, the order is predictable: normally, @var{function} goes at the front of the hook list, so it is executed -first (barring another @code{add-hook} call). If the optional argument -@var{append} is non-@code{nil}, the new hook function goes at the end of -the hook list and is executed last. +first (barring another @code{add-hook} call). + +In some cases, it is important to control the relative ordering of +functions on the hook. The optional argument @var{depth} lets you indicate +where the function should be inserted in the list: it should then be a number +between -100 and 100 where the higher the value, the closer to the end of the +list the function should go. The @var{depth} defaults to 0 and for backward +compatibility when @var{depth} is a non-nil symbol it is interpreted as a depth +of 90. Furthermore, when @var{depth} is strictly greater than 0 the function +is added @emph{after} rather than before functions of the same depth. @code{add-hook} can handle the cases where @var{hook} is void or its value is a single function; it sets or changes the value to a list of diff --git a/etc/NEWS b/etc/NEWS index d10a553244..ebb1dacf22 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1452,6 +1452,12 @@ documentation of the new mode and its commands. * Incompatible Lisp Changes in Emacs 27.1 +** add-hook does not always add to the front or the end any more. +The replacement of `append` with `depth` implies that the function is not +always added to the very front (when append/depth is nil) or the very end (when +append/depth is t) any more because other functions on the hook may have +specified higher/lower depths. + ** In 'compilation-error-regexp-alist' the old undocumented feature where 'line' could be a function of 2 arguments has been dropped. @@ -1583,6 +1589,12 @@ valid event type. * Lisp Changes in Emacs 27.1 ++++ +** The 'append' arg of 'add-hook' is generalized to a finer notion of 'depth' +This allows to control the ordering of functions more precisely, +as was already possible in 'add-function' and `advice-add`. + +--- ** New 'help-fns-describe-variable-functions' hook. Makes it possible to add metadata information to 'describe-variable'. diff --git a/lisp/elec-pair.el b/lisp/elec-pair.el index 3be09d87b4..5fb9d751e2 100644 --- a/lisp/elec-pair.el +++ b/lisp/elec-pair.el @@ -564,13 +564,6 @@ electric-pair-post-self-insert-function (matching-paren (char-after)))) (save-excursion (newline 1 t))))))) -;; Prioritize this to kick in after -;; `electric-layout-post-self-insert-function': that considerably -;; simplifies interoperation when `electric-pair-mode', -;; `electric-layout-mode' and `electric-indent-mode' are used -;; together. Use `vc-region-history' on these lines for more info. -(put 'electric-pair-post-self-insert-function 'priority 50) - (defun electric-pair-will-use-region () (and (use-region-p) (memq (car (electric-pair-syntax-info last-command-event)) @@ -622,8 +615,14 @@ electric-pair-mode (if electric-pair-mode (progn (add-hook 'post-self-insert-hook - #'electric-pair-post-self-insert-function) - (electric--sort-post-self-insertion-hook) + #'electric-pair-post-self-insert-function + ;; Prioritize this to kick in after + ;; `electric-layout-post-self-insert-function': that + ;; considerably simplifies interoperation when + ;; `electric-pair-mode', `electric-layout-mode' and + ;; `electric-indent-mode' are used together. + ;; Use `vc-region-history' on these lines for more info. + 50) (add-hook 'self-insert-uses-region-functions #'electric-pair-will-use-region)) (remove-hook 'post-self-insert-hook diff --git a/lisp/electric.el b/lisp/electric.el index 07da2f1d9e..53e53bd975 100644 --- a/lisp/electric.el +++ b/lisp/electric.el @@ -190,17 +190,6 @@ electric--after-char-pos (eq (char-before) last-command-event))))) pos))) -(defun electric--sort-post-self-insertion-hook () - "Ensure order of electric functions in `post-self-insertion-hook'. - -Hooks in this variable interact in non-trivial ways, so a -relative order must be maintained within it." - (setq-default post-self-insert-hook - (sort (default-value 'post-self-insert-hook) - #'(lambda (fn1 fn2) - (< (or (if (symbolp fn1) (get fn1 'priority)) 0) - (or (if (symbolp fn2) (get fn2 'priority)) 0)))))) - ;;; Electric indentation. ;; Autoloading variables is generally undesirable, but major modes @@ -297,8 +286,6 @@ electric-indent-post-self-insert-function (indent-according-to-mode) (error (throw 'indent-error nil))))))))) -(put 'electric-indent-post-self-insert-function 'priority 60) - (defun electric-indent-just-newline (arg) "Insert just a newline, without any auto-indentation." (interactive "*P") @@ -341,8 +328,8 @@ electric-indent-mode (remove-hook 'post-self-insert-hook #'electric-indent-post-self-insert-function)) (add-hook 'post-self-insert-hook - #'electric-indent-post-self-insert-function) - (electric--sort-post-self-insertion-hook))) + #'electric-indent-post-self-insert-function + 60))) ;;;###autoload (define-minor-mode electric-indent-local-mode @@ -472,8 +459,6 @@ electric-layout-post-self-insert-function-1 ('after-stay (save-excursion (funcall nl-after))) ('around (funcall nl-before) (funcall nl-after)))))))) -(put 'electric-layout-post-self-insert-function 'priority 40) - ;;;###autoload (define-minor-mode electric-layout-mode "Automatically insert newlines around some chars. @@ -482,8 +467,8 @@ electric-layout-mode :global t :group 'electricity (cond (electric-layout-mode (add-hook 'post-self-insert-hook - #'electric-layout-post-self-insert-function) - (electric--sort-post-self-insertion-hook)) + #'electric-layout-post-self-insert-function + 40)) (t (remove-hook 'post-self-insert-hook #'electric-layout-post-self-insert-function)))) @@ -623,8 +608,6 @@ electric-quote-post-self-insert-function (replace-match (string q>>)) (setq last-command-event q>>)))))))))) -(put 'electric-quote-post-self-insert-function 'priority 10) - ;;;###autoload (define-minor-mode electric-quote-mode "Toggle on-the-fly requoting (Electric Quote mode). @@ -651,8 +634,8 @@ electric-quote-mode (remove-hook 'post-self-insert-hook #'electric-quote-post-self-insert-function)) (add-hook 'post-self-insert-hook - #'electric-quote-post-self-insert-function) - (electric--sort-post-self-insertion-hook))) + #'electric-quote-post-self-insert-function + 10))) ;;;###autoload (define-minor-mode electric-quote-local-mode diff --git a/lisp/emacs-lisp/syntax.el b/lisp/emacs-lisp/syntax.el index d09d6c1225..d3cb04d1ca 100644 --- a/lisp/emacs-lisp/syntax.el +++ b/lisp/emacs-lisp/syntax.el @@ -298,7 +298,7 @@ syntax-propertize ;; between syntax-ppss and syntax-propertize, we also have to make ;; sure the flush function is installed here (bug#29767). (add-hook 'before-change-functions - #'syntax-ppss-flush-cache t t)) + #'syntax-ppss-flush-cache 99 t)) (save-excursion (with-silent-modifications (make-local-variable 'syntax-propertize--done) ;Just in case! @@ -429,7 +430,7 @@ syntax-ppss-flush-cache ;; Unregister if there's no cache left. Sadly this doesn't work ;; because `before-change-functions' is temporarily bound to nil here. ;; (unless cache - ;; (remove-hook 'before-change-functions 'syntax-ppss-flush-cache t)) + ;; (remove-hook 'before-change-functions #'syntax-ppss-flush-cache t)) (setcar cell last) (setcdr cell cache))) )) @@ -533,13 +534,14 @@ syntax-ppss ;; Setup the before-change function if necessary. (unless (or ppss-cache ppss-last) - ;; We should be either the very last function on - ;; before-change-functions or the very first on - ;; after-change-functions. ;; Note: combine-change-calls-1 needs to be kept in sync ;; with this! (add-hook 'before-change-functions - 'syntax-ppss-flush-cache t t)) + #'syntax-ppss-flush-cache + ;; We should be either the very last function on + ;; before-change-functions or the very first on + ;; after-change-functions. + 99 t)) ;; Use the best of OLD-POS and CACHE. (if (or (not old-pos) (< old-pos pt-min)) diff --git a/lisp/progmodes/cc-mode.el b/lisp/progmodes/cc-mode.el index ea865e0b0f..2aef071cf8 100644 --- a/lisp/progmodes/cc-mode.el +++ b/lisp/progmodes/cc-mode.el @@ -653,6 +653,8 @@ c-basic-common-init (make-local-hook 'after-change-functions)) (add-hook 'before-change-functions 'c-before-change nil t) (setq c-just-done-before-change nil) + ;; FIXME: We should use the new `depth' arg in Emacs-27, e.g. a depth of -10 + ;; would do since font-lock uses a(n implicit) depth of 0. (add-hook 'after-change-functions 'c-after-change nil t) (when (boundp 'font-lock-extend-after-change-region-function) (set (make-local-variable 'font-lock-extend-after-change-region-function) diff --git a/lisp/subr.el b/lisp/subr.el index be21dc67a0..e4bf4998ef 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1604,12 +1604,20 @@ 'user-original-login-name ;;;; Hook manipulation functions. -(defun add-hook (hook function &optional append local) +(defun add-hook (hook function &optional depth local) "Add to the value of HOOK the function FUNCTION. FUNCTION is not added if already present. -FUNCTION is added (if necessary) at the beginning of the hook list -unless the optional argument APPEND is non-nil, in which case -FUNCTION is added at the end. + +The place where the function is added depends on the DEPTH +parameter. DEPTH defaults to 0. By convention, it 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. + +For backward compatibility reasons, a symbol other than nil is +interpreted as a DEPTH of 90. The optional fourth argument, LOCAL, if non-nil, says to modify the hook's buffer-local value rather than its global value. @@ -1622,6 +1630,7 @@ add-hook function, it is changed to a list of functions." (or (boundp hook) (set hook nil)) (or (default-boundp hook) (set-default hook nil)) + (unless (numberp depth) (setq depth (if depth 90 0))) (if local (unless (local-variable-if-set-p hook) (set (make-local-variable hook) (list t))) ;; Detect the case where make-local-variable was used on a hook @@ -1634,12 +1643,25 @@ add-hook (setq hook-value (list hook-value))) ;; Do the actual addition if necessary (unless (member function hook-value) - (when (stringp function) + (when (stringp function) ;FIXME: Why? (setq function (purecopy function))) + (when (or (get hook 'hook--depth-alist) (not (zerop depth))) + ;; Note: The main purpose of the above `when' test is to avoid running + ;; this `setf' before `gv' is loaded during bootstrap. + (setf (alist-get function (get hook 'hook--depth-alist) + 0 'remove #'equal) + depth)) (setq hook-value - (if append + (if (< 0 depth) (append hook-value (list function)) - (cons function hook-value)))) + (cons function hook-value))) + (let ((depth-alist (get hook 'hook--depth-alist))) + (when depth-alist + (setq hook-value + (sort (if (< 0 depth) hook-value (copy-sequence hook-value)) + (lambda (f1 f2) + (< (alist-get f1 depth-alist 0 nil #'equal) + (alist-get f2 depth-alist 0 nil #'equal)))))))) ;; Set the actual variable (if local (progn diff --git a/test/lisp/subr-tests.el b/test/lisp/subr-tests.el index c458eef2f9..d832958363 100644 --- a/test/lisp/subr-tests.el +++ b/test/lisp/subr-tests.el @@ -373,5 +373,31 @@ subr-test--frames-1 (should (equal (flatten-tree '(1 ("foo" "bar") 2)) '(1 "foo" "bar" 2)))) +(defvar subr-tests--hook nil) + +(ert-deftest subr-tests-add-hook-depth () + "Test the `depth' arg of `add-hook'." + (setq-default subr-tests--hook nil) + (add-hook 'subr-tests--hook 'f1) + (add-hook 'subr-tests--hook 'f2) + (should (equal subr-tests--hook '(f2 f1))) + (add-hook 'subr-tests--hook 'f3 t) + (should (equal subr-tests--hook '(f2 f1 f3))) + (add-hook 'subr-tests--hook 'f4 50) + (should (equal subr-tests--hook '(f2 f1 f4 f3))) + (add-hook 'subr-tests--hook 'f5 -50) + (should (equal subr-tests--hook '(f5 f2 f1 f4 f3))) + (add-hook 'subr-tests--hook 'f6) + (should (equal subr-tests--hook '(f5 f6 f2 f1 f4 f3))) + ;; Make sure `t' is equivalent to 90. + (add-hook 'subr-tests--hook 'f7 90) + (add-hook 'subr-tests--hook 'f8 t) + (should (equal subr-tests--hook '(f5 f6 f2 f1 f4 f3 f7 f8))) + ;; Make sue `nil' is equivalent to 0. + (add-hook 'subr-tests--hook 'f9 0) + (add-hook 'subr-tests--hook 'f10) + (should (equal subr-tests--hook '(f5 f6 f10 f9 f2 f1 f4 f3 f7 f8))) + ) + (provide 'subr-tests) ;;; subr-tests.el ends here From debbugs-submit-bounces@debbugs.gnu.org Sat May 11 08:05:15 2019 Received: (at 35508) by debbugs.gnu.org; 11 May 2019 12:05:15 +0000 Received: from localhost ([127.0.0.1]:40011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPQkc-0004m1-OR for submit@debbugs.gnu.org; Sat, 11 May 2019 08:05:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPQkb-0004lk-0F for 35508@debbugs.gnu.org; Sat, 11 May 2019 08:05:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38233) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPQkV-0006CS-SB; Sat, 11 May 2019 08:05:07 -0400 Received: from [176.228.60.248] (port=2557 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPQkV-0004z9-25; Sat, 11 May 2019 08:05:07 -0400 Date: Sat, 11 May 2019 15:05:03 +0300 Message-Id: <835zqhdwnk.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Wed, 08 May 2019 14:32:43 -0400) Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks References: <831s1iqclm.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 35508@debbugs.gnu.org > Date: Wed, 08 May 2019 14:32:43 -0400 > > I updated the patch so we use it for syntax-propertize's > before-change-functions as well as a comment showing where we'd use it > in cc-mode (using it in CC-mode would take more work in order to make > sure it doesn't break on older Emacsen). > > >> If the worse comes to worst, a Lisp program could concoct > >> the entire hook list in any order it sees fit, right? > > I don't understand what you mean here. > > [ Still don't understand. ] > > >> That's backward-incompatible, no? > > Sure. > > I added a note in the "incompatible changes" section of NEWS. > > >> In any case, this default is insufficiently tested by the tests > >> you propose. > > What other tests do you suggest? > > I added a test to make sure nil is treated like 0. > > >> So using 100 more than once makes the last one "win"? > > Yes. This is so that when using `t` more than once, the last one wins, > > just as it used to. > > > >>> +For backward compatibility reasons, a symbol other than nil is > >>> +interpreted as a DEPTH of 90. > >> This is not explicitly tested by the test. > > I added a test to make sure t is treated like 90. > > Other objections? Thanks. Should we perhaps change 100 to 110 and 90 to 100? And perhaps not document the 110 value? Just a thought. No other objections. From debbugs-submit-bounces@debbugs.gnu.org Sat May 11 09:26:25 2019 Received: (at 35508) by debbugs.gnu.org; 11 May 2019 13:26:25 +0000 Received: from localhost ([127.0.0.1]:40072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPS1A-0006nX-QN for submit@debbugs.gnu.org; Sat, 11 May 2019 09:26:25 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40639) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPS19-0006nL-FS for 35508@debbugs.gnu.org; Sat, 11 May 2019 09:26:23 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0A50D10069C; Sat, 11 May 2019 09:26:18 -0400 (EDT) Received: from mail02.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 43CF8100623; Sat, 11 May 2019 09:26:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1557581172; bh=JnRpxnhSfcWfmnaTzGvs+epQeVaCphuo5stLj7fW+qg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=iOwzHWwyBXiDAZNQOEfXbu5BB7SE12dNBK8/x8t9UMEqKrTiZEZY+IVdk/b79LwNP 6bSU1NjHJQidUzN06XGJ/Ga8fX0pgwgX6tWsAQFKkeq9z5owjshbXV0BSPN+dNKMyE adNbrRfkwRM3ChR1Y4EQKCoD3MJwwaXbblX5HgyVJJz63k1HzpUhHiuji8wEPK5cHU aXQnLYcl0dlirpryHbx85HMzzQSt0TaFWFlOBUBbyDZNeYmMjQQMwjqSknDKFw9ztw CocZQtMvYLg8B6itgFKlF+gSGx+XFZ0Pt7o5cKM75c+5K/p4fWm3yZiKUaSyte0qUp nyI5LRbQ9ti1A== Received: from pastel (69-196-155-191.dsl.teksavvy.com [69.196.155.191]) by mail02.iro.umontreal.ca (Postfix) with ESMTPSA id 9CEB5120781; Sat, 11 May 2019 09:26:11 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <831s1iqclm.fsf@gnu.org> <835zqhdwnk.fsf@gnu.org> Date: Sat, 11 May 2019 09:26:10 -0400 In-Reply-To: <835zqhdwnk.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 May 2019 15:05:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. X-SPAM-LEVEL: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> 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 ? ;-) > 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. 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%. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat May 11 09:54:52 2019 Received: (at 35508) by debbugs.gnu.org; 11 May 2019 13:54:52 +0000 Received: from localhost ([127.0.0.1]:40079 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPSSi-0007Qw-90 for submit@debbugs.gnu.org; Sat, 11 May 2019 09:54:52 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45789) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPSSg-0007Ql-Tz for 35508@debbugs.gnu.org; Sat, 11 May 2019 09:54:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:39790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPSSb-0005dH-C7; Sat, 11 May 2019 09:54:45 -0400 Received: from [176.228.60.248] (port=1516 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hPSSa-0000jO-Pp; Sat, 11 May 2019 09:54:45 -0400 Date: Sat, 11 May 2019 16:54:42 +0300 Message-Id: <83tve1cd0d.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-reply-to: (message from Stefan Monnier on Sat, 11 May 2019 09:26:10 -0400) Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks References: <831s1iqclm.fsf@gnu.org> <835zqhdwnk.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 35508@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. From debbugs-submit-bounces@debbugs.gnu.org Mon May 13 09:29:43 2019 Received: (at 35508) by debbugs.gnu.org; 13 May 2019 13:29:43 +0000 Received: from localhost ([127.0.0.1]:44460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQB1S-0001kk-H6 for submit@debbugs.gnu.org; Mon, 13 May 2019 09:29:42 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:60572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hQB1P-0001ka-42 for 35508@debbugs.gnu.org; Mon, 13 May 2019 09:29:40 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x4DDTaxD017750; Mon, 13 May 2019 09:29:37 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 5E46B66227; Mon, 13 May 2019 09:29:36 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <831s1iqclm.fsf@gnu.org> <835zqhdwnk.fsf@gnu.org> <83tve1cd0d.fsf@gnu.org> Date: Mon, 13 May 2019 09:29:36 -0400 In-Reply-To: <83tve1cd0d.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 May 2019 16:54:42 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Rules: 3 Rules triggered TRK_NCM1=0.1, EDT_SA_DN_PASS=0, RV6545=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6545> : inlines <7074> : streams <1821408> : uri <2843991> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 35508 Cc: 35508@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> >> 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? =CF=80? >> Also I think it's important to use the same convention as for add-functi= on. > 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 From debbugs-submit-bounces@debbugs.gnu.org Wed May 29 15:56:49 2019 Received: (at 35508-done) by debbugs.gnu.org; 29 May 2019 19:56:49 +0000 Received: from localhost ([127.0.0.1]:59972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW4gr-0000wP-1z for submit@debbugs.gnu.org; Wed, 29 May 2019 15:56:49 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62376) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW4gp-0000wB-7q for 35508-done@debbugs.gnu.org; Wed, 29 May 2019 15:56:47 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BE068442DE5; Wed, 29 May 2019 15:56:41 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9E719442DE3; Wed, 29 May 2019 15:56:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1559159800; bh=FnheC16NeYZ4a8VM87M/58yOFFR1fqqo7HURA5enF2w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=J4/RVlYwYkQebdmK2qlMuEMoIrhS4fLMdWaxhJjT5cG2FybAoSGcCrsHAhKx9w07H oONBJ99fJySk6TXKLYodHzV8l1OyoGcwH2DP2bw/LdyPrLHRFvocY4uPbDDL+/y0Yz DqY9MeD0QRfA23MJ2Fxu7lum8kWUCxxzh+LtrKsULTijbrIi4ihLpZWrcDHL3iSe6/ T//fLIYx5jkKzgQQo+YrHbprCbqsb5+ptnKdBRn63mh9LHmbp72B/QM+VIjWViy1bX H2LDmnNPrFX7fEotWNUFS2CYIZJdA8I2KCWw508V5A8YvrNeeaui0+jzB+NTTr6hts dvY61fLRk33mQ== Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 651D6120BBB; Wed, 29 May 2019 15:56:40 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks Message-ID: References: <831s1iqclm.fsf@gnu.org> <835zqhdwnk.fsf@gnu.org> <83tve1cd0d.fsf@gnu.org> Date: Wed, 29 May 2019 15:56:38 -0400 In-Reply-To: (Stefan Monnier's message of "Mon, 13 May 2019 09:29:36 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.578 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 35508-done Cc: 35508-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 66? 50? 10? 99? =CF=80? For lack of a better idea, I kept 90. > I think that'd be more trouble than it's worth. > But I'll warn against using 100 (or -100), in the doc. Done and pushed, Stefan From unknown Fri Jun 13 10:51:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 27 Jun 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator