From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Wed, 30 Nov 2022 22:09:59 +0000 Message-ID: References: <83o7wjc6o2.fsf@gnu.org> <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83czcyd8jf.fsf@gnu.org> <83a682d66r.fsf@gnu.org> <837d36ceno.fsf@gnu.org> <37dd2827f54f8bbda5e3@heytings.org> <735c1d5b-0d64-a8e1-3aaa-91fc0248abd3@yandex.ru> <97049541-f5b4-ed3b-b8de-7c0bdc86f0f5@yandex.ru> <6e305c9b-7702-133a-3347-f64db05ade3f@yandex.ru> <83mt89kt10.fsf@gnu.org> <834juglesn.fsf@gnu.org> <83r0xkjw5s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="g2T9Iajleu" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="665"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 30 23:11:24 2022 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 1p0VIa-000ATW-HI for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Nov 2022 23:11:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0VIJ-0003HR-NZ; Wed, 30 Nov 2022 17:11:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0VIE-0003H3-Dv for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 17:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p0VIE-0002dw-1A for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 17:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p0VID-0004cx-Rt for bug-gnu-emacs@gnu.org; Wed, 30 Nov 2022 17:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Nov 2022 22:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.166984620417775 (code B ref 56682); Wed, 30 Nov 2022 22:11:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 30 Nov 2022 22:10:04 +0000 Original-Received: from localhost ([127.0.0.1]:35400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0VHI-0004ca-0k for submit@debbugs.gnu.org; Wed, 30 Nov 2022 17:10:04 -0500 Original-Received: from heytings.org ([95.142.160.155]:38462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p0VHF-0004bm-6t for 56682@debbugs.gnu.org; Wed, 30 Nov 2022 17:10:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669846200; bh=n5Yu1Ru2fFO31U90I8pHG4OWRLvLaEup1NxLnpD9fuc=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=15wFCEQogMyA45oUdvuAwpAzzkaPOCJ171sFR8+RNkwBUyZl5qwSWReTeL9e5jClj 6Ca11W8snlMSkPLDducqJi45bDtMnhA/safmIiLwlhY8CjnqGg5Zb+4/4JZgTOpsXp IhFf6FDIkwRcRhbF4ePZred2ewOXr98p0/e7yc1368fOtffxf+IWTm5cY02gsEqJsP INthRlHWnV+Mzsp+5C3gferlSw9V9Ne+wBXGH3et2j/jMczxjz26XU8cMm7YPqatkM 71iqvpfh9f2/fVW4OuYUqrrXOP0WZlqhF40pLzzSKTKplDFHVw9W0JccklL5YxYbLM 2hLOIHGpoU2Bw== In-Reply-To: <83r0xkjw5s.fsf@gnu.org> Content-ID: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249577 Archived-At: --g2T9Iajleu Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: > > It could (although that would be an unusual thing to do), but that's=20 > immaterial: the display engine will never look outside of the=20 > restriction, and so searching beyond that is not useful. Moreover, safe= =20 > code in Emacs cannot look beyond BEGV..ZV without calling 'widen',=20 > because various primitives and subroutines don't expect that and will=20 > barf sooner or later; that's why I made that change in the loop. > I had to refresh my memory about this, and I think there is a=20 misunderstanding here: we check whether a buffer contains long lines only= =20 when it is about to be redisplayed and its contents have changed enough=20 since the last time it was displayed. What happened between these two=20 redisplays can be anything, e.g. it could be a buffer that has not been on= =20 display during an hour and that has been filled by a process in the=20 meantime. Using BEGV/ZV is wrong, again because we don't know what=20 happened between these two redisplays, it could have been filled by a=20 process and narrowed, and if after switching to that buffer the user=20 widens it, Emacs would become unresponsive. Or it could be a buffer that= =20 has been emptied in the background by a command, filled with the contents= =20 of a file, and narrowed to some portion of that file (e.g. a single hunk=20 of a diff file); again if the user widens it to look at the whole file,=20 Emacs will hang. The only safe way to be certain that a buffer does not=20 contain long lines is to check the whole buffer. > > If we are going to narrow the buffer to PT =C2=B1 N characters, then=20 > searching inside slightly more than this region (say, twice more or 5=20 > times more) should be enough, I think. It might fail in some borderline= =20 > cases, but most files with very long lines have almost all of their=20 > lines long, so I see no problem here. > The intention when this detection mechanism was designed was explicitly to= =20 also support non-file visiting buffers, e.g. a shell buffer in which a=20 user cat's a file with long lines. > > OTOH, "punishing" large buffers that have no long lines at all doesn't=20 > strike me as a good balance. Your proposed patch will solve a=20 > particular use case, but it cannot solve all of them. > Indeed, by definition no heuristic can solve all problems. > > When modiff becomes large enough, we will search again, and the=20 > threshold of 8 is not so large to prevent it from happening frequently=20 > enough to be an annoyance. > Please, let's not throw away something that was designed with care and=20 about which literally no one complained since it was introduced, for the=20 sole reason that an artificial benchmark shows a slowdown of ~80=20 milliseconds in a 30 MB buffer. And note that it's not "modiff becomes=20 large enough", it is "modiff changed enough between two redisplays". > > That annoyance will be for no good reason in buffers that have no long=20 > lines. > It's not "for no good reason", it's for an excellent reason: it's the=20 price to pay to ensure that Emacs remains responsive in as many cases as=20 possible. And it's not an annoyance, for all basic editing commands the=20 detection loop will not run. > > If you are still unhappy with such a simple heuristics, we could go with= =20 > something slightly more complex, like change the threshold of modiff=20 > dynamically based on the buffer size and perhaps the number of times we= =20 > already searched without finding long lines -- the larger these two are,= =20 > the higher we could bump the threshold. > I don't see how such a heuristic could catch a case such as a user cat'ing= =20 a file with long lines in a shell buffer. --g2T9Iajleu--