From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Newsgroups: gmane.emacs.bugs Subject: bug#48584: 28.0.50; Incorrect hook ordering between local and global hooks with depth Date: Fri, 4 Jun 2021 15:20:34 +0200 Message-ID: References: <871r9uefvy.fsf@gnus.org> <87bl8xb1vg.fsf@gnus.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11883"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48584@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 04 15:21:17 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 1lp9lE-0002rL-SK for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 15:21:16 +0200 Original-Received: from localhost ([::1]:33210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp9lD-0001zf-7j for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 09:21:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32850) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp9l0-0001xj-6s for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34283) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lp9kz-0005hp-VS for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lp9kz-0001cT-QQ for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 09:21:01 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.16228128526189 (code B ref 48584); Fri, 04 Jun 2021 13:21:01 +0000 Original-Received: (at 48584) by debbugs.gnu.org; 4 Jun 2021 13:20:52 +0000 Original-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 Original-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 Original-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) Original-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) In-Reply-To: <87bl8xb1vg.fsf@gnus.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) 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:208013 Archived-At: > 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.=