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.bugs Subject: bug#38407: 27.0.50; infinite loop with display of large file without newlines Date: Sat, 7 Dec 2019 14:28:37 +1300 Message-ID: References: <39c498717f8958e7fdc408d4da51d378@webmail.orcon.net.nz> <24031.28277.201123.531348@cochabamba.vanoostrum.org> <83r21sowx1.fsf@gnu.org> <24032.4698.256238.87458@cochabamba.vanoostrum.org> <83k17jq1ch.fsf@gnu.org> <24032.17845.921546.629745@cochabamba.vanoostrum.org> <83fti7p349.fsf@gnu.org> <4B1ABCA7-A69C-4251-8EBD-A11654A92642@vanoostrum.org> <83v9r2o4z9.fsf@gnu.org> <24035.27244.755074.180653@cochabamba.vanoostrum.org> <83lfrwlz2w.fsf@gnu.org> <83o8wpjsx5.fsf@gnu.org> <83zhg8hz6j.fsf@gnu.org> <83fthyizpq.fsf@gnu.org> <002bd5c4-a9c1-4bda-6005-a98a6118d94b@orcon.net.nz> <83fthxhocr.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="175951"; 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: rpluim@gmail.com, pieter@vanoostrum.org, 38407@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 07 02:29:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1idOuH-000jap-1E for geb-bug-gnu-emacs@m.gmane.org; Sat, 07 Dec 2019 02:29:13 +0100 Original-Received: from localhost ([::1]:46944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idOuF-0000vb-7Z for geb-bug-gnu-emacs@m.gmane.org; Fri, 06 Dec 2019 20:29:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58302) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1idOu8-0000uW-0D for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2019 20:29:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1idOu6-0002xC-S3 for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2019 20:29:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41239) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1idOu6-0002vp-N8 for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2019 20:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1idOu6-0007MC-JA for bug-gnu-emacs@gnu.org; Fri, 06 Dec 2019 20:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2019 01:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38407 X-GNU-PR-Package: emacs Original-Received: via spool by 38407-submit@debbugs.gnu.org id=B38407.157568212428253 (code B ref 38407); Sat, 07 Dec 2019 01:29:02 +0000 Original-Received: (at 38407) by debbugs.gnu.org; 7 Dec 2019 01:28:44 +0000 Original-Received: from localhost ([127.0.0.1]:47212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1idOto-0007Ld-FP for submit@debbugs.gnu.org; Fri, 06 Dec 2019 20:28:44 -0500 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:34845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1idOtl-0007LS-Nz for 38407@debbugs.gnu.org; Fri, 06 Dec 2019 20:28:42 -0500 Original-Received: from [116.251.203.246] (port=50131 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1idOti-0003O9-0A; Sat, 07 Dec 2019 14:28:38 +1300 In-Reply-To: <83fthxhocr.fsf@gnu.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:172989 Archived-At: On 6/12/19 9:04 PM, Eli Zaretskii wrote: > Did you try a different heuristic for detecting long lines, one that > isn't based on searching some portion of the buffer? E.g., what > about going to a couple of random places and looking at the value > returned by current-column? No, the library has essentially used the current approach from the beginning. However one of the changes I made for the new version was to allow users to set a custom function for detecting long lines via the `so-long-predicate' option, so it's easy to plug in alternatives. I haven't planned to implement any alternatives myself, but if other people do so I'd be interested to see how they compare in practice. > In general, searching for a newline is very fast in Emacs, so if you > use the right primitives, you should be able to scan quite a lot of > text before the time begins affecting responsiveness. `so-long-detected-long-line-p' is the provided predicate, and it relies on `forward-line' (which I've assumed is as quick as I'm going to get for finding newlines), along with narrowing to limit the amount of text scanned to the maximum value that we care about (i.e. the minimum length of a too-long line). I've just done a bit of testing with much larger files and values, and suspect that we could indeed make these values quite dramatically bigger without any noticeable impact. Files with lots of lines, yet no excessively-long ones, will ensure that so-long scans the (customizable) maximum number of lines that it's going to try before giving up. I expect that will be a useful test case for testing responsiveness on slow systems. -Phil