From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#35508: 27.0.50; Fine-ordering of functions on hooks Date: Wed, 01 May 2019 16:29:00 -0400 Message-ID: References: <831s1iqclm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="150426"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 35508@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 01 22:30:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLvro-000cx3-1x for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 May 2019 22:30:12 +0200 Original-Received: from localhost ([127.0.0.1]:40982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLvrn-0006kQ-3L for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 May 2019 16:30:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLvrg-0006i7-E1 for bug-gnu-emacs@gnu.org; Wed, 01 May 2019 16:30:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLvrf-00055P-9H for bug-gnu-emacs@gnu.org; Wed, 01 May 2019 16:30:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59722) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hLvrf-00054k-5C for bug-gnu-emacs@gnu.org; Wed, 01 May 2019 16:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hLvrd-0006hA-U9 for bug-gnu-emacs@gnu.org; Wed, 01 May 2019 16:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 May 2019 20:30:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35508 X-GNU-PR-Package: emacs Original-Received: via spool by 35508-submit@debbugs.gnu.org id=B35508.155674255525664 (code B ref 35508); Wed, 01 May 2019 20:30:01 +0000 Original-Received: (at 35508) by debbugs.gnu.org; 1 May 2019 20:29:15 +0000 Original-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 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <831s1iqclm.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 01 May 2019 21:00:21 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158604 Archived-At: >> 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