From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 May 2021 11:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 48584@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16216824905597 (code B ref -1); Sat, 22 May 2021 11:22:02 +0000 Received: (at submit) by debbugs.gnu.org; 22 May 2021 11:21:30 +0000 Received: from localhost ([127.0.0.1]:38379 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkPhC-0001SD-G6 for submit@debbugs.gnu.org; Sat, 22 May 2021 07:21:30 -0400 Received: from lists.gnu.org ([209.51.188.17]:44986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkPhA-0001S4-JK for submit@debbugs.gnu.org; Sat, 22 May 2021 07:21:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36502) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkPhA-0008To-7O for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:21:28 -0400 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:56045) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkPh7-0008UV-Qx for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 07:21:27 -0400 Received: by mail-wm1-x332.google.com with SMTP id b7so11834554wmh.5 for ; Sat, 22 May 2021 04:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=dtMGqCcktWYEIvjFmnb++xvMGyg6sSYC0mrvhB8LXng=; b=JOuY1HSvxdZPY7QG3+i0Wmhc07NKEFmF0ILenDwoSfZ1Y/GT+Ula71X0qTGegCB+q3 A4Et1CUK2Ebp8sj2dYqLBW6gq1Xn9yv/s8uTBlWRBxsZPLi+ChqNYpl48aukn2gUJeGv ofdsUmtp5qT1iu6jYSJhTLV9/TtoyPdXams4ssgW1EamkiC0el9S1YVYvwZ0lO6lYYFw TMq3ZYjculO6FMeSPLZGe0C+D5KBXF055ajbPhzMn9P8AWK/8UQbgikhDm2zCDSEylJy r2J1KgoTynRFS9ppfzEDStolTUEtph4Kf8YApzPUVNWWP6dY19DemhIR0kLPRneIr6Ds eBvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=dtMGqCcktWYEIvjFmnb++xvMGyg6sSYC0mrvhB8LXng=; b=GaAZ0ulJPJLvKAWHTnCxeeDL0e/Dn/qybwK05XPKCM+RSJ6xCFCCF4OxpPU/E09yd1 emVZkZo6WxpEt7TvosXOK//m1c4TiJStURwYDMUYdAMrBNbOCW9oWmDypoqayvKnfhgo NA/M1ckQ+2ViZOsZfxDSYll3lYUZhfaOnhJlMIVz8n33JKCJRfutjwyfU7E9ayCNet4S YqvoNBBO6Y/gY/4sRaR53eh95sarqBKQyUyq6nlbi5BIqdhaaDd9mN9APjaNgvkNVdT2 SJXCVUzwc3rS27Nqo+CyDTlHGvJ8OPNkmuf6zhwNRuCr+XUi+W1Qqi6pk4NDK/l+0vCF YL7w== X-Gm-Message-State: AOAM533g4E5kjdu4ZMJWvyBHe9HlwmHCQ3zBCTMLe7gcp40cYTnCOKBu iSYuNC0E8LV+/a9eY39xO9/Hu4GmRe4gPA== X-Google-Smtp-Source: ABdhPJzTcW1GqenW0tpkhP8eOAm6oe13TmFbBuY8clLxJmWhVGjZowd1nCRgsMlADjoqj2yDdJg4fg== X-Received: by 2002:a05:600c:4ca7:: with SMTP id g39mr12613127wmp.1.1621682482898; Sat, 22 May 2021 04:21:22 -0700 (PDT) Received: from Philipps-MBP.fritz.box ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id b10sm5288583wrt.24.2021.05.22.04.21.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 22 May 2021 04:21:22 -0700 (PDT) From: Philipp Date: Sat, 22 May 2021 13:21:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::332; envelope-from=p.stephani2@gmail.com; helo=mail-wm1-x332.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.1 (-) 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.1 (--) Evaluate these forms: (add-hook 'my-hook (lambda () (message "Outer")) 20) (with-temp-buffer (add-hook 'my-hook (lambda () (message "Inner")) 10 :local) (run-hooks 'my-hook)) Then in the *Messages* buffer, "Inner" appears *after* "Outer" even though the local function's depth is lower than the global one's. In GNU Emacs 28.0.50 (build 124, aarch64-apple-darwin20.4.0, NS appkit-2022.44 Version 11.3.1 (Build 20E241)) of 2021-05-22 Repository revision: a3de48687eb28121f3dbfc20be19bd06c4cd6e98 Repository branch: master Windowing system distributor 'Apple', version 10.3.2022 System Description: macOS 11.3.1 Configured using: 'configure --with-modules --without-xml2 --without-pop --with-mailutils --enable-gcc-warnings=warn-only --enable-checking=all --enable-check-lisp-object-type 'CFLAGS=-ggdb3 -O0'' Configured features: ACL GNUTLS JSON LCMS2 MODULES NOTIFY KQUEUE NS PDUMPER PNG THREADS TOOLKIT_SCROLL_BARS ZLIB Important settings: value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc dired dired-loaddefs rfc822 mml mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils phst skeleton derived edmacro kmacro pcase ffap thingatpt url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs password-cache json map url-vars mailcap rx gnutls puny dbus xml subr-x seq byte-opt gv bytecomp byte-compile cconv compile text-property-search comint ansi-color ring cl-loaddefs cl-lib iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 70771 6618) (symbols 48 8363 1) (strings 32 24252 2098) (string-bytes 1 793122) (vectors 16 16068) (vector-slots 8 212664 8593) (floats 8 26 28) (intervals 56 220 0) (buffers 992 10)) From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 May 2021 20:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162197327811166 (code B ref 48584); Tue, 25 May 2021 20:08:01 +0000 Received: (at 48584) by debbugs.gnu.org; 25 May 2021 20:07:58 +0000 Received: from localhost ([127.0.0.1]:46977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lldLK-0002u2-0I for submit@debbugs.gnu.org; Tue, 25 May 2021 16:07:58 -0400 Received: from quimby.gnus.org ([95.216.78.240]:49298) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lldLG-0002tm-Pq for 48584@debbugs.gnu.org; Tue, 25 May 2021 16:07:56 -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=h+JW82ZQ1Xl/tVyVd3q6I71+7+5A38gf41IPvGkYQKo=; b=pHTSXQrFd0rt9DAjs84IZueEF+ m6J8zDEWmKsr3J/oCC3BaWmfi+GGno0yVX/aqOfDBLs/6z0zoHf7DxnpkD+LOYmcHFcqPAFTMohbS uQfzdVKn7GIIgT0j/+QQYvJz0Poz2c90Bw4v7TBt8Nfqnr5bcKOidGS3R9SQ+KP2ri9o=; 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 1lldL8-0004fK-15; Tue, 25 May 2021 22:07:48 +0200 From: Lars Ingebrigtsen References: X-Now-Playing: Satomimagae's _awa_: "Hono" Date: Tue, 25 May 2021 22:07:45 +0200 In-Reply-To: (Philipp's message of "Sat, 22 May 2021 13:21:21 +0200") Message-ID: <871r9uefvy.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Philipp writes: > Evaluate these forms: > > (add-hook 'my-hook (lambda () (message "Outer")) 20) > (with-temp-buffer > (add-hook 'my-hook (lambda () (message "Inner")) 10 :local) > (run-hooks 'my-hook)) > > Then in t [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) 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 (-) Philipp writes: > Evaluate these forms: > > (add-hook 'my-hook (lambda () (message "Outer")) 20) > (with-temp-buffer > (add-hook 'my-hook (lambda () (message "Inner")) 10 :local) > (run-hooks 'my-hook)) > > Then in the *Messages* buffer, "Inner" appears *after* "Outer" even > though the local function's depth is lower than the global one's. Looking at the code, the order is computed by `add-hook' by stashing data in the symbol plist of my-hook, but the hook function is then pushed onto either the local or the global version of the variable. So the ordering isn't global -- it's one ordering for the local and one for the global, and `run-hooks' doesn't say anything about what order the local and global values are run in? (The global value is run when `t' appears in the local value.) So... I don't see any obvious way to fix this, and perhaps we should just document that the order is undefined when you have both local and global hooks with the same name. Any opinions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 May 2021 20:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162197422621451 (code B ref 48584); Tue, 25 May 2021 20:24:02 +0000 Received: (at 48584) by debbugs.gnu.org; 25 May 2021 20:23:46 +0000 Received: from localhost ([127.0.0.1]:47033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lldac-0005Zv-Eh for submit@debbugs.gnu.org; Tue, 25 May 2021 16:23:46 -0400 Received: from mail-oi1-f171.google.com ([209.85.167.171]:46821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lldaZ-0005Zi-TZ for 48584@debbugs.gnu.org; Tue, 25 May 2021 16:23:45 -0400 Received: by mail-oi1-f171.google.com with SMTP id x15so31443138oic.13 for <48584@debbugs.gnu.org>; Tue, 25 May 2021 13:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6FqmSHcNpA1IblSThcIPtPrQK+yqQ1LFRiR5TQvoWu4=; b=C9+6EnY4LhX9q5yA633eblKs+hNwA0gX4eGZT09//FXwgByBGKthV/IW+bz4eMZ03y wtNRy9oup2skyrjmQT307tvFFK7XFhSa3pBKCQRq1nI7eEe0NW2Q/VuKenc7lrbxjKAx PDHcZ87SNDvNASmvMtYwwkbH8so9QsX/QemM45H+S7l7inh1PDhA3RTOe3dT+fie3J9a 8Fa9x/PeXmaifoSyjQuiGoQqp17cvEKNPACbyEKnOje3eV0qgdj6MuhAa1oZTCTkZlt4 wmohJORihOqf9qzZzomUz6r6PP4DOmcM/1QKWnZGXskhiYa+e6sTjamHBm/0Q++2xteo fwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6FqmSHcNpA1IblSThcIPtPrQK+yqQ1LFRiR5TQvoWu4=; b=gBzTawjMMmFGjmF2jK/FP4caK/0sVJUrrDa8NkRzXOak9rF+Tf9EqzfVraOHc0wksB LZkIsYDjIzlRmq/ewlMg08dStaU4AioniDoKMUj/FGThUtghkP7egEx2S+cXzEEU+znU Glv4EjKcGuGMvnfX0eHsFHQqUGCPiLigpJip2/5bkwEMLR/Za3Oewdkt2JLX/Zd1UjwD vq3/8qMsK/pWp4OvLIpXNa0IanM6MZcLhhwTgHyNjN3aCHlN8MzxYdKulWa28PuOmO1S edXHIROusLDbUtu6C5QWrRKQx4JcQrPagkXI9iaNfcJyDTPoKMs7k/0jsHASciLn2qCj qlzQ== X-Gm-Message-State: AOAM532M/xN8IzJS+awNlqO4g+ILqxB0WvBfqx2hlGoXfwR6Blyrk6gp 4OBV7UWFgPCXGAld5rmf5DOliRRMAKq667FD3AE= X-Google-Smtp-Source: ABdhPJz+o7ntSrAltuPOp3QcEyf8PxBe0J5cnX+KNRLXZ5mWYTV/huGeHsGxiAMSkSr9UiEkgdko2LYb82ZVvftxUnY= X-Received: by 2002:aca:4d01:: with SMTP id a1mr15452094oib.158.1621974218121; Tue, 25 May 2021 13:23:38 -0700 (PDT) MIME-Version: 1.0 References: <871r9uefvy.fsf@gnus.org> In-Reply-To: <871r9uefvy.fsf@gnus.org> From: Philipp Stephani Date: Tue, 25 May 2021 22:23:26 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) 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: -0.8 (/) Am Di., 25. Mai 2021 um 22:07 Uhr schrieb Lars Ingebrigtsen : > > So... I don't see any obvious way to fix this, and perhaps we should > just document that the order is undefined when you have both local and > global hooks with the same name. > > Any opinions? The order isn't undefined, and add-hook carefully distinguishes between negative and nonnegative depths in this case. It's just that the relative ordering of depths with the same sign but different "localness" isn't considered/documented. How about documenting something along those lines? In "Running hooks", amend the paragraph "If the hook variable is buffer-local, the buffer-local variable will be used instead of the global variable. However, if the buffer-local variable contains the element @code{t}, the global hook variable will be run as well." to say that the global hook is run at exactly the place where the "t" appears. In "Setting hooks", amend the paragraph "If @var{local} is non-@code{nil}, that says to add @var{function} to the buffer-local hook list instead of to the global hook list. This makes the hook buffer-local and adds @code{t} to the buffer-local value." to specify where the "t" is added (IIUC it's appended if depth > 0 and prepended otherwise). From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 May 2021 21:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162206587018275 (code B ref 48584); Wed, 26 May 2021 21:52:02 +0000 Received: (at 48584) by debbugs.gnu.org; 26 May 2021 21:51:10 +0000 Received: from localhost ([127.0.0.1]:50076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm1Qk-0004kg-Df for submit@debbugs.gnu.org; Wed, 26 May 2021 17:51:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:34508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lm1Qi-0004kT-Ri for 48584@debbugs.gnu.org; Wed, 26 May 2021 17:51:09 -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=lN4B82VyvI1TwIuE/uUxAJNgvUYHWMrOXig4rYW72EM=; b=VN/ahGmeZ8PqR0x5+07jDXpwf8 w5nJPDeruKkLzZ7g3RiXkaBptWUgQg8U98Sa3F0OirCL6jWNWc+YDFrylcPthg0riG7mjJB9XWXYR rh5dZWynptRjdxHzo/cPTpu61oePZSOXIkcbNQGhgD/CMmJXq6bSFiZ23cYlIcOZRhNU=; 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 1lm1QZ-0003YU-M1; Wed, 26 May 2021 23:51:01 +0200 From: Lars Ingebrigtsen References: <871r9uefvy.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UFGhUnDLSHh88AAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA1LTI2VDIxOjM5OjEyKzAwOjAwoKk3/wAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNS0yNlQyMTozOToxMiswMDowMNH0j0MAAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Nite and Day" Date: Wed, 26 May 2021 23:50:59 +0200 In-Reply-To: (Philipp Stephani's message of "Tue, 25 May 2021 22:23:26 +0200") Message-ID: <87bl8xb1vg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Philipp Stephani writes: > The order isn't undefined, and add-hook carefully distinguishes > between negative and nonnegative depths in this case. It's just that > the relative ordering of depths with the same sign but differ [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) 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 (-) Philipp Stephani writes: > The order isn't undefined, and add-hook carefully distinguishes > between negative and nonnegative depths in this case. It's just that > the relative ordering of depths with the same sign but different > "localness" isn't considered/documented. That's a different way to say "undefined". :-) 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. > How about documenting something along those lines? > In "Running hooks", amend the paragraph > "If the hook variable is buffer-local, the buffer-local variable will > be used instead of the global variable. However, if the buffer-local > variable contains the element @code{t}, the global hook variable will > be run as well." > to say that the global hook is run at exactly the place where the "t" appears. (Oh, I should have read your entire mail before starting to answer.) Well, you're still not saying that that's what'll happen with the t. And I'm not sure that's really a conscious design, but just an odd implementation. > In "Setting hooks", amend the paragraph > "If @var{local} is non-@code{nil}, that says to add @var{function} to the > buffer-local hook list instead of to the global hook list. This makes > the hook buffer-local and adds @code{t} to the buffer-local value." > to specify where the "t" is added (IIUC it's appended if depth > 0 and > prepended otherwise). I think I'd just prefer to say that the ordering is undefined if you have both a global and a local hook. Either that, or actually implement a proper ordering system, because "do the global where the t is" is very odd and somewhat brittle. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Jun 2021 13:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.16228128526189 (code B ref 48584); Fri, 04 Jun 2021 13:21:01 +0000 Received: (at 48584) by debbugs.gnu.org; 4 Jun 2021 13:20:52 +0000 Received: from localhost ([127.0.0.1]:45829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9km-0001be-1y for submit@debbugs.gnu.org; Fri, 04 Jun 2021 09:20:52 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:34531) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lp9kf-0001bN-JA for 48584@debbugs.gnu.org; Fri, 04 Jun 2021 09:20:46 -0400 Received: by mail-wr1-f48.google.com with SMTP id q5so9326057wrm.1 for <48584@debbugs.gnu.org>; Fri, 04 Jun 2021 06:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9VoEC5lBLHrM9lGpKYN4Pe0iwwxyGp5q/ef74ykzww=; b=W/GsMYVscYrntV4voVW5FMurQtqzD2z2q79yw5JbaIt08Q7lVbBxErrKs1Q08hpynB s9f58LVcMqHpti88tA6KfjydGRbzfG2KVwkO+nejYPQM10qtiuQ9IwaemzedOveHITH2 lrJB/aIWylIdwuDJfVa/05505TgIq4OBLKj7kcvFo43fFnBU8DtATQfgsNcQSGDjdRfk zDGTjOrahQCeXcZQAYVXz5FQzFhy0WqMwOdhKDiJ+h8WIhcefPHP9FOoTi2CcuhLUMPf pFbHG03LTcUqdPQUTIefO6wLmAsmGXDzyPSYkjV9DFkvpeA+AIlz4e3MENTx73NgcFdi FY+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9VoEC5lBLHrM9lGpKYN4Pe0iwwxyGp5q/ef74ykzww=; b=EsiRlsG+9Gh9JQi3nPZdR6g+YI2IOFxu0Vly2t2s9XiOscjs3na+2HqETslgf+9KOk WAs/2Tw8XHtKmkGpy7Zwo/vrSRzN+W6t7zYN8C6UJNLzQdbuFy7FJESeo+prShycL320 HojqcsdLs2NJqXH8PlCJISqLFQAef56dPPB6c12qWZG/O1uUQHhBHfASePC69g+PEUXv S1a6aTn3A653yocQBHB7jkClrGMk4OSqM+B8OmqR7F6iXMZnoKHNcMHlAoVDfzkfSiqm 0PJjPXNuXAZFQlmCrqMDMGXtc8vzVGxid4kWB6xiXUIi/Nb2muF/+XLzB6EQOIHHRDda Zq7A== X-Gm-Message-State: AOAM533eduiEFXwI46yeGc98gERztsduBatZ/E6wRI9snIcQ+HzRYpcW xQ6yngL0Qq4IVC6csH4w62Q= X-Google-Smtp-Source: ABdhPJzz+IG8ZvhZOhqR6OF0XlaneVKIXV0vL5wbBDO5eSu1bST3+mY99aT+jseAJdqsTZgR2NLKQQ== X-Received: by 2002:adf:df87:: with SMTP id z7mr3991457wrl.56.1622812835735; Fri, 04 Jun 2021 06:20:35 -0700 (PDT) Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id d3sm6427918wrs.41.2021.06.04.06.20.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Jun 2021 06:20:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Philipp In-Reply-To: <87bl8xb1vg.fsf@gnus.org> Date: Fri, 4 Jun 2021 15:20:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Spam-Score: 0.2 (/) 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: -0.8 (/) > Am 26.05.2021 um 23:50 schrieb Lars Ingebrigtsen : >=20 > Philipp Stephani writes: >=20 >> The order isn't undefined, and add-hook carefully distinguishes >> between negative and nonnegative depths in this case. It's just that >> the relative ordering of depths with the same sign but different >> "localness" isn't considered/documented. >=20 > That's a different way to say "undefined". :-) >=20 > 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. >=20 >> How about documenting something along those lines? >> In "Running hooks", amend the paragraph >> "If the hook variable is buffer-local, the buffer-local variable will >> be used instead of the global variable. However, if the buffer-local >> variable contains the element @code{t}, the global hook variable will >> be run as well." >> to say that the global hook is run at exactly the place where the "t" = appears. >=20 > (Oh, I should have read your entire mail before starting to answer.) >=20 > Well, you're still not saying that that's what'll happen with the t. > And I'm not sure that's really a conscious design, but just an odd > implementation.=20 That doesn't really matter: now that it's implemented that way, people = rely on the behavior. >=20 >> In "Setting hooks", amend the paragraph >> "If @var{local} is non-@code{nil}, that says to add @var{function} to = the >> buffer-local hook list instead of to the global hook list. This = makes >> the hook buffer-local and adds @code{t} to the buffer-local value." >> to specify where the "t" is added (IIUC it's appended if depth > 0 = and >> prepended otherwise). >=20 > I think I'd just prefer to say that the ordering is undefined if you > have both a global and a local hook. Either that, or actually = implement > a proper ordering system, because "do the global where the t is" is = very > odd and somewhat brittle. That's not going to work. People don't rely on documented but = observable behavior; this is Hyrum's law (https://www.hyrumslaw.com). = Just stating that something is "undefined" won't change that. 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: lisp/textmodes/fill.el:405: (run-hook-with-args-until-success = 'fill-nobreak-predicate))))) lisp/files.el:1894: (unless (run-hook-with-args-until-failure = 'kill-buffer-query-functions) lisp/files.el:5353: (unless (run-hook-with-args-until-success = 'write-contents-functions) lisp/files.el:5373: (run-hook-with-args-until-success = 'write-file-functions) lisp/minibuffer.el:2948: (run-hook-with-args-until-success = 'file-name-at-point-functions))) lisp/minibuffer.el:4079: (run-hook-with-args-until-success = 'file-name-at-point-functions)))) lisp/progmodes/grep.el:1017: (run-hook-with-args-until-success = 'file-name-at-point-functions))) lisp/progmodes/which-func.el:280: = (run-hook-with-args-until-success 'which-func-functions))) lisp/progmodes/xref.el:266: (run-hook-with-args-until-success = 'xref-backend-functions)) lisp/emacs-lisp/eldoc.el:619: (run-hook-with-args-until-success = 'eldoc-documentation-functions 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.= From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth 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 X-GNU-PR-Keywords: To: Philipp Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162297075720660 (code B ref 48584); Sun, 06 Jun 2021 09:13:01 +0000 Received: (at 48584) by debbugs.gnu.org; 6 Jun 2021 09:12:37 +0000 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 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=; 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 From: Lars Ingebrigtsen References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> 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" Date: Sun, 06 Jun 2021 11:12:24 +0200 In-Reply-To: (Philipp's message of "Fri, 4 Jun 2021 15:20:34 +0200") Message-ID: <87o8cjuzk7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -0.7 (/) 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.7 (-) 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 From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Philipp Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Jul 2021 18:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162551024511266 (code B ref 48584); Mon, 05 Jul 2021 18:38:01 +0000 Received: (at 48584) by debbugs.gnu.org; 5 Jul 2021 18:37:25 +0000 Received: from localhost ([127.0.0.1]:46654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TTB-0002ve-2i for submit@debbugs.gnu.org; Mon, 05 Jul 2021 14:37:25 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:51106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0TT9-0002vR-OH for 48584@debbugs.gnu.org; Mon, 05 Jul 2021 14:37:24 -0400 Received: by mail-wm1-f50.google.com with SMTP id o22so12001150wms.0 for <48584@debbugs.gnu.org>; Mon, 05 Jul 2021 11:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og9+5sdwq7ocDmTbUyT8UJR/NolSjLJ7FHwGz3UunPc=; b=udE/lFWItVNEVhQZtlczgCNkWFQGn8kuYCSTrfA7eEy10BLp5ktzx0ioruTBGeTGKn UP65gXbLjNFPYMNvOphgAkoJPAbBJJHH3zLbMU430oZziiqmJbR3ciRYK35KBTTUUj1C 1Tkbt/nBK9Qnglt4qG5K10L+ZPpZF+NwFuccOe8rMtuSK+9kLNxbzRSl0qHwiYt3uasN nbHQa3hxws53Liem2h6HYhhTd00863RIz9lNU+7d1Sas2wnc5geeFAOWrKaiVjKXaqlB Ax/eeYfWk79UmwKqHVFq1eZPpIPuVuVeN2b+ymwdMulmHxW5ad8gDBLQbiXd/1zH9uUI 1H4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=og9+5sdwq7ocDmTbUyT8UJR/NolSjLJ7FHwGz3UunPc=; b=lWeaWfco1b1v9qTYnRTaiHNVcg8c6QQFx/2R3FKYDj4i9LUcMPhlbrN2nS2KsHr5// toPlrMfKQAbiWUXfWZO8qEKZkhhv0+y1NAfJoU3YOxc63e0LLVwguC4is4gjre26ksFW wuiIaDR2hv5W4qdjl+rhr1coiA//1Zb9KMKihF7FhQEogiLZUqfvwCQABTWTL2ra0bCM 143tzKsIGOdrI8haAO1WpA/pGskNPGmSnDSbl2mHTIESL4R0h4KECccnIuzDN8gETsCI ht+m+ScJIuwN+iBty8bUddD6AgCmuTyUMW63tCVK2GZ4zWzZvbqJZHH0N6Q8C+GRjXjh Xefg== X-Gm-Message-State: AOAM532Vfyijh+7lX8qelS05GI2RH6Zk3CD438tgPU/TNvJfO74nx3m4 MWwSCRcRJKMotUPqwLfBlOP9A0e+LNUY0Q== X-Google-Smtp-Source: ABdhPJwdnTHOR9d1l4oFXe5kGdlgodU7AwChjBuzC0rzmOMAuhrAUV2iPJvEguMkDNmNaUCjeWlAiA== X-Received: by 2002:a7b:c449:: with SMTP id l9mr466186wmi.98.1625510237651; Mon, 05 Jul 2021 11:37:17 -0700 (PDT) Received: from smtpclient.apple ([46.128.198.100]) by smtp.gmail.com with ESMTPSA id l17sm261855wmq.3.2021.07.05.11.37.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Jul 2021 11:37:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Philipp In-Reply-To: <87o8cjuzk7.fsf@gnus.org> Date: Mon, 5 Jul 2021 20:37:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06A4701F-78A8-4904-AD18-ECBE4617ECDC@gmail.com> References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> <87o8cjuzk7.fsf@gnus.org> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Spam-Score: 0.2 (/) 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: -0.8 (/) > Am 06.06.2021 um 11:12 schrieb Lars Ingebrigtsen : >=20 > Philipp writes: >=20 >>> 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. >>=20 >> Yes - and that's a reasonable behavior to expect, and we should = document it. >=20 > 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. What we think about this doesn't matter much. As I explained, people = depend on observable/observed behavior. Besides, hook ordering for abnormal hooks is crucial, so we can't just = say "don't depend on it." >=20 >> 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: >=20 > [...] >=20 >> 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. >=20 > I don't think it shows any such thing. Why not? Clearly there are hooks that are both abnormal and = partially-local in the Emacs codebase, and for those hooks this issue = arises. >=20 > 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. >=20 Yes, and arguably the current implementation with the "shadow" ordering = stored in a private symbol property is already kind of a hack. However, = the second-best option is still to document the current behavior. As = I've tried to explain, just stating "it's undefined" won't fly. From unknown Sun Jun 15 01:08:55 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Jul 2021 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48584 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Cc: 48584@debbugs.gnu.org Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162557991312575 (code B ref 48584); Tue, 06 Jul 2021 13:59:02 +0000 Received: (at 48584) by debbugs.gnu.org; 6 Jul 2021 13:58:33 +0000 Received: from localhost ([127.0.0.1]:49558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0lar-0003Gl-Im for submit@debbugs.gnu.org; Tue, 06 Jul 2021 09:58:33 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40456) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m0lap-0003GY-2Z for 48584@debbugs.gnu.org; Tue, 06 Jul 2021 09:58:31 -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=KS00dAz4i/rO+qABPQsns+vN9MsJDNnSqRkLKQzIsLk=; b=FcL1gHlVUMGWt52waqNGFUtPSP NsmyT2wDlgOiELqkL0XufcVd/Hr1tel2NqYc+NsqtEvC02pQRFar87UeThV5rwxMgtcdbk07XfTeK 0qLM7oy21xypEAeVLxPrl6ybymW35YU88XnqydqeI5RYy4jVX9vJpxRM+BWeXxs8mDXk=; Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0lag-0001by-55; Tue, 06 Jul 2021 15:58:24 +0200 From: Lars Ingebrigtsen References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> <87o8cjuzk7.fsf@gnus.org> <06A4701F-78A8-4904-AD18-ECBE4617ECDC@gmail.com> X-Now-Playing: Sam Amidon's _Lily-O_: "Blue Mountains" Date: Tue, 06 Jul 2021 15:58:21 +0200 In-Reply-To: <06A4701F-78A8-4904-AD18-ECBE4617ECDC@gmail.com> (Philipp's message of "Mon, 5 Jul 2021 20:37:16 +0200") Message-ID: <87h7h7v91e.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Philipp writes: > Yes, and arguably the current implementation with the "shadow" > ordering stored in a private symbol property is already kind of a > hack. However, the second-best option is still to document the > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) 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 (---) Philipp writes: > Yes, and arguably the current implementation with the "shadow" > ordering stored in a private symbol property is already kind of a > hack. However, the second-best option is still to document the > current behavior. As I've tried to explain, just stating "it's > undefined" won't fly. Well, whether it flies or not, that's what we have. But we should fix this and allow proper, non-brittle ordering. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no