From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: 27.0.50: How can I test a buffer-local window-configuration-change-hook in batch mode? Date: Sat, 26 Oct 2019 23:57:49 +1300 Message-ID: <46229722-5fd5-f1a3-c7d7-96f3f5e05ad8@orcon.net.nz> References: <83ftjixlwh.fsf@gnu.org> <72dda818-78b6-953f-ba5c-e2e1c81c036e@orcon.net.nz> <93cb893c-a77d-112e-e84c-e4f358686abd@gmx.at> <7c3b27d1-7be1-b1de-ae85-728d11f0e771@orcon.net.nz> <474b5ee0-d765-03fd-51df-789532a9fd32@gmx.at> <83tv7vvpqv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71040"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: martin rudalics , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 26 12:58:15 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOJls-000IH0-S0 for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 12:58:13 +0200 Original-Received: from localhost ([::1]:39674 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOJlr-0002gd-LO for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 06:58:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33017) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOJli-0002ep-7B for emacs-devel@gnu.org; Sat, 26 Oct 2019 06:58:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOJle-00017u-2x for emacs-devel@gnu.org; Sat, 26 Oct 2019 06:58:01 -0400 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:55707) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iOJlc-00015I-H2; Sat, 26 Oct 2019 06:57:57 -0400 Original-Received: from [116.251.203.173] (port=20114 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iOJlV-0004iP-Uq; Sat, 26 Oct 2019 23:57:50 +1300 In-Reply-To: <83tv7vvpqv.fsf@gnu.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 60.234.4.59 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241438 Archived-At: On 26/10/19 2:44 AM, Eli Zaretskii wrote: >> if you feel it belongs in NEWS then let's do that. > > I do. TIA. All good. I'll write that along with some updates for the manuals sometime soon. On 26/10/19 10:07 PM, Eli Zaretskii wrote: > Could be. But why does it have to be related to the first time a > buffer is displayed? Don't we want to do that when the file is > visited instead? Your comment was to Martin, but were you wondering why so-long would wait for the buffer to be displayed? It did originally act as soon as the file was visited (and the code currently in master still does) regardless of buffer visibility; but I ended up with some bug reports related to libraries which were visiting files in order to do some processing behind-the-scenes, but which were getting tripped up by so-long doing things to those buffers unexpectedly. Refer to: https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-10/msg01726.html I don't think long lines pose any performance problems in buffers which are never displayed, so the revised approach means those buffers are simply left alone (they just get a buffer-local hook value which will most likely never be examined or acted on), and it's only buffers which actually get displayed that are subject to so-long's actions. I've not been able to spot any down-sides to the change, so I'm pretty sure it's the right thing to do. >> > Without `run-window-configuration-change-hook' I'd have to replicate >> > some of that functionality myself, and the test would be getting even >> > further away from the real processes, and therefore becoming less and >> > less useful as a test. I'd like to have to fake as little as possible. >> >> Understandable. Rewriting this in Elisp is no fun. > > Per previous messages, rewriting in Lisp is either (a) not necessary, > or (b) will not help even if done. So I don't think this discussion > concluded that run-window-configuration-change-hook is of any > importance that would justify leaving it in our sources in the long > run. I'll argue for not removing the function while it has a use. The actual implementation in C is going to remain, so removing the lisp binding seems like an extremely minimal saving, whereas keeping it provides a concrete benefit in at least this case. Running the hook explicitly in my test may not be the same thing as redisplay running it; but then the thing I'm really testing is that when the hook runs, so-long does its thing, so ultimately I don't think it's too important how we get to that point, so long as I get to compare 'before hooks runs' and 'after hook runs' -- which, at present, I can do. -Phil