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.=