From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 14:28:10 +0300 Message-ID: <83d0ejvj91.fsf@gnu.org> 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> <46229722-5fd5-f1a3-c7d7-96f3f5e05ad8@orcon.net.nz> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218830"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rudalics@gmx.at, emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 26 13:29:04 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 1iOKFk-000uij-7b for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 13:29:04 +0200 Original-Received: from localhost ([::1]:39736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOKFi-0002wO-VN for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 07:29:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34685) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOKF7-0002vS-SE for emacs-devel@gnu.org; Sat, 26 Oct 2019 07:28:27 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iOKF6-00020t-7b; Sat, 26 Oct 2019 07:28:24 -0400 Original-Received: from [176.228.60.248] (port=4109 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iOKF4-0005GU-2s; Sat, 26 Oct 2019 07:28:22 -0400 In-reply-to: <46229722-5fd5-f1a3-c7d7-96f3f5e05ad8@orcon.net.nz> (message from Phil Sainty on Sat, 26 Oct 2019 23:57:49 +1300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:241439 Archived-At: > Cc: martin rudalics , emacs-devel@gnu.org > From: Phil Sainty > Date: Sat, 26 Oct 2019 23:57:49 +1300 > > 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. Thanks. > 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 Looks like the problem was specifically with setting the buffer read-only? Why does so-long do that? > I don't think long lines pose any performance problems in buffers > which are never displayed You are wrong: it will cause problems in any function that uses the display code, even if nothing is displayed. For example, vertical-motion, next-line, posn-at-point, etc. all use the display code internally. > 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. Well, one downside is that you now need to use a hook that was not really meant for that, or we'd need to introduce yet another hook. Which is perfectly OK, as long as we are sure there's no simpler solution, one that uses existing facilities. > > 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. I'm not going to push to remove this, but I think your basic premise here is wrong. These hooks cannot be possibly tested in full from batch mode anyway, so your ability to test them is limited, with or without that function. > 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 And you cannot test that by calling the hook function directly? Why not?