From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Date: Sun, 06 Jun 2021 11:12:24 +0200 Message-ID: <87o8cjuzk7.fsf@gnus.org> References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23489"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 48584@debbugs.gnu.org To: Philipp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 06 11:13:27 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpoqV-0005sT-3C for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Jun 2021 11:13:27 +0200 Original-Received: from localhost ([::1]:44146 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lpoqU-0007aw-5L for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 06 Jun 2021 05:13:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpoq6-0007aj-10 for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 05:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39084) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpoq5-0008B3-Q7 for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 05:13:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lpoq5-0005No-Lm for bug-gnu-emacs@gnu.org; Sun, 06 Jun 2021 05:13:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 09:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs Original-Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162297075720660 (code B ref 48584); Sun, 06 Jun 2021 09:13:01 +0000 Original-Received: (at 48584) by debbugs.gnu.org; 6 Jun 2021 09:12:37 +0000 Original-Received: from localhost ([127.0.0.1]:50630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpopg-0005N8-UC for submit@debbugs.gnu.org; Sun, 06 Jun 2021 05:12:37 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:57280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpope-0005Mw-KI for 48584@debbugs.gnu.org; Sun, 06 Jun 2021 05:12:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dd/M0xL/Od1DNBIKILZmN3cR1ISL6AAQo3MAhkisOoQ=; b=Zcx1T1V1FfpXFuOKVc6EI3CWuy h4dEc/KJj0I+4W62owFtXwoitjx3oDPel1wFELYKht0dizNsYjMw6FcgcezgQoy/mzc+XaOt0PUGe OkvgAXnr4X4IUTgPSMnfNREhM8LEjN6tw+7uCQDTsBabT+oPGcbYdo8KUvuDYGvpX3ww=; Original-Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lpopU-0004mC-JA; Sun, 06 Jun 2021 11:12:28 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAGFBMVEX489f+/Obe2sPY z66ckVlgYCIvLxn///8+Oln3AAAAAWJLR0QHFmGI6wAAAAd0SU1FB+UGBgg6EBZ7FUgAAAFoSURB VDjLnZRtkoMgDIax9gAyvYArPYBD2v3dGaEH2GIOsJXc/wgN+IWWzuxs/CHDY94XAlEUMhdVJfJA zkBppaAEUKDbLQAdZhWA1hsQhxzFXkrKg9JB6OsN5MzPZhe3CVz7Xfz8D8i/AJMBzuQynP0oNRPM euAHc2doiucGuFYcs+DBVS/vM5AjYG+81eLUAY92GXQTolIDGGMX8+8IdC3EBYew0d9NBtSNyCzX mq6F2mLcaZoBtQLXnvpj2GgCnG7U2XfQcobHdVXoAEpL/hKsfeKBXA+wSF2/A70drDNIw5WmVcll uehZhh73WJ0UjIUfLCttM0ZAHgl9moE+fMovpD6p7nSAPtbGj1LFYh4pZ+wAfxowMvBvUoEiET6X jOV+REArIBxrEbSI/ArCnGeTsI35liwgmET/cB5V7FPxFrGFQysKwTfhsEyPrV0V/OMotWq0bvhR rZCrSNUkUciN+q7LP8cL2tDmE4p07lIAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjEtMDYtMDZUMDg6 NTg6MTYrMDA6MDBCAGq6AAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTA2LTA2VDA4OjU4OjE2KzAw OjAwM13SBgAAAABJRU5ErkJggg== X-Now-Playing: Bana Haffar's _Breathing Instruments_: "Circulations" In-Reply-To: (Philipp's message of "Fri, 4 Jun 2021 15:20:34 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:208099 Archived-At: Philipp writes: >> If I'm reading run_hook_with_args correctly, it'll loop over the local >> hook first (in order), and when it happens upon a t in that value, it'll >> then loop over the global value (in order), and then finish up the rest >> of the local ones. > > Yes - and that's a reasonable behavior to expect, and we should document it. I think it's an implementation detail that users should not depend on. Where that `t' ends up being depends on many subtle things like the order of your add-hook/remove-hook calls in your .emacs file. > Correct hook ordering is crucial for abnormal hooks. We already rely > on the very specific ordering behavior several times in the Emacs > codebase alone. I've searched a bit through the Emacs codebase, and > found the following places where Emacs runs an abnormal hook with > `run-hook-with-args-until-success/failure' that also gains a local > part somewhere the codebase: [...] > That is, we rely on this "undefined" behavior already in very basic > operations such as saving buffers to file. In Eldoc, we even > explicitly tell users to add functions to the local part of this > abnormal hook (eldoc-documentation-functions), thereby telling them to > rely on "undefined" behavior! This hopefully shows that the behavior > is far from being undefined. I don't think it shows any such thing. I think it'd be a good idea to implement (and document) something in this area that actually allows users to control the hook running order properly, which currently just isn't possible. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no