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: Wed, 26 May 2021 23:50:59 +0200 Message-ID: <87bl8xb1vg.fsf@gnus.org> References: <871r9uefvy.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="16890"; 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 Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 26 23:52:58 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 1lm1ST-000493-Ty for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 23:52:57 +0200 Original-Received: from localhost ([::1]:40786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lm1SS-0000lK-UI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 17:52:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lm1Ra-0000Bd-Uf for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 17:52:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38530) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lm1Ra-0001V9-6n for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 17:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lm1Ra-0004lo-5i for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 17:52:02 -0400 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 48584-submit@debbugs.gnu.org id=B48584.162206587018275 (code B ref 48584); Wed, 26 May 2021 21:52:02 +0000 Original-Received: (at 48584) by debbugs.gnu.org; 26 May 2021 21:51:10 +0000 Original-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 Original-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=; 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 1lm1QZ-0003YU-M1; Wed, 26 May 2021 23:51:01 +0200 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" In-Reply-To: (Philipp Stephani's message of "Tue, 25 May 2021 22:23:26 +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:207320 Archived-At: 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