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: Sun, 27 Oct 2019 02:09:30 +1300 Message-ID: <86c669a1-8cd5-3819-1291-4eaaa389ef3d@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> <46229722-5fd5-f1a3-c7d7-96f3f5e05ad8@orcon.net.nz> <83d0ejvj91.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="174632"; 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: rudalics@gmx.at, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 26 15:12:14 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 1iOLrZ-000jIF-8D for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 15:12:13 +0200 Original-Received: from localhost ([::1]:40062 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOLrU-0000JU-IB for ged-emacs-devel@m.gmane.org; Sat, 26 Oct 2019 09:12:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42386) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOLp1-0007Nd-PY for emacs-devel@gnu.org; Sat, 26 Oct 2019 09:09:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOLp0-0000L7-9Y for emacs-devel@gnu.org; Sat, 26 Oct 2019 09:09:35 -0400 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:44531) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iOLoz-0000KF-Uv; Sat, 26 Oct 2019 09:09:34 -0400 Original-Received: from [116.251.203.173] (port=36129 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iOLow-0003cL-H9; Sun, 27 Oct 2019 02:09:30 +1300 In-Reply-To: <83d0ejvj91.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:241452 Archived-At: On 27/10/19 12:28 AM, Eli Zaretskii wrote: > Looks like the problem was specifically with setting the buffer > read-only? Why does so-long do that? The reasoning for this default was that *editing* a long line might be slow, and in the sorts of files which I was expecting so-long to trigger for, the user probably doesn't want to be manually editing them; so this is to protect against the user accidentally modifying the line (and probably then needing to undo it), all while Emacs is responding more slowly than usual. The particular issue raised was certainly with the read-only state, but it did make me think that other issues might well be possible, and that NOT messing with invisible buffers would be a much safer (and much less surprising) default behaviour from the point of view of other libraries doing automated things to files behind the scenes. (It's configurable, so the original approach can be restored if users choose to.) >> 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'll have to have a play. My initial feeling is that the *potential* to break such background processing (which is liable to be hidden from the user) by triggering so-long is a more significant risk than the potential for background processing to run slowly because of long lines; so I'm still leaning towards using the "visible buffers only" approach as the preferable compromise here. >> 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. I think it's quite a nice use of the hook, to be honest (even if it's not a use-case that was originally envisaged). I was very pleased when I realised how very simple and efficient this approach was. The behaviour I wanted arises almost effortlessly from setting a single buffer-local value. I definitely didn't see that as a downside. >> 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? Do you mean, in the case where I have done this... (add-hook 'window-configuration-change-hook #'so-long nil :local) ...that my test could just call `so-long' directly, rather than running the hook? If I did that, the test would really be redundant. It certainly wouldn't be testing any part of the new behaviour. Other existing tests already assert what happens when `so-long' is called directly. The entire purpose of this test was to confirm that `so-long' gets called *in*directly. -Phil