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: Fri, 6 Dec 2019 09:38:05 +1300 Message-ID: <002bd5c4-a9c1-4bda-6005-a98a6118d94b@orcon.net.nz> 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> 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="197585"; 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: pieter@vanoostrum.org, 38407@debbugs.gnu.org To: Eli Zaretskii , Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Dec 05 21:40:45 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 1icxvZ-000pH3-28 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 21:40:45 +0100 Original-Received: from localhost ([::1]:60752 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icxvX-0000qg-N3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 05 Dec 2019 15:40:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43879) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1icxtw-0008CK-17 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:39:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1icxtu-0002yH-Ke for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:39:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39342) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1icxtu-0002xC-FW for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:39:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1icxtu-0005ga-A7 for bug-gnu-emacs@gnu.org; Thu, 05 Dec 2019 15:39: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: Thu, 05 Dec 2019 20:39: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.157557829221756 (code B ref 38407); Thu, 05 Dec 2019 20:39:02 +0000 Original-Received: (at 38407) by debbugs.gnu.org; 5 Dec 2019 20:38:12 +0000 Original-Received: from localhost ([127.0.0.1]:45315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icxt6-0005ep-9B for submit@debbugs.gnu.org; Thu, 05 Dec 2019 15:38:12 -0500 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:54213) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1icxt4-0005ef-2z for 38407@debbugs.gnu.org; Thu, 05 Dec 2019 15:38:10 -0500 Original-Received: from [116.251.203.246] (port=3738 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1icxsz-0004yH-Jd; Fri, 06 Dec 2019 09:38:06 +1300 In-Reply-To: <83fthyizpq.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:172933 Archived-At: On 6/12/19 4:01 AM, Eli Zaretskii wrote: > If we want [so-long] to be enabled by default, it "needs work", IMO. > For starters, the default line length beyond which it kicks in, 250 > characters, is waaay too low. IME, problems start with much longer > lines, perhaps more than 10000 characters. Agreed. There is a whole discussion pending (I intended to raise it soon), asking people to test the library more widely, and to help to figure out what the default settings should actually be. The current settings are almost entirely based on modes and features I have tried personally, after all. That 250 value is, as you note, incredibly small. As with many things in so-long it's something of a heuristic and trade-off. The reasoning was that not all files with extremely long lines are just one line -- newline chars may still occur in the text for reasons other than the formatting of the file -- and so the question was: "given the context of a buffer in some prog-mode derivative, what length is "long enough" to indicate that we're not looking at a normal file, but something which probably contains minified code? In conjunction is the "how many lines do we test" variable. It would be nice to arrive at a decision without doing a lot of work, so we don't want to inspect a really large number of lines; but we also don't necessarily want to *require* that we've seen a line which will definitely cause problems -- a shorter line which strongly suggests that we're looking at minified code/data may be sufficient. With the current conservative (*very* conservative) values we very quickly reach a decision, but we're more likely to trigger in false- positive situations (this has happened to me, but only very rarely; and by default `so-long-revert' is a C-c C-c away). With larger values we may more effort to reach a decision. With *much* larger values, that extra effort might be noticeable (on slower systems even if not on faster ones), so I think we want to be a bit careful of that. (Not that I've been testing large values for performance -- I've been leaving that for the later discussion, and in the meantime I've been content to have the small default values, in part because it seemed more likely that people would discover potential problems with the library if it was a bit more trigger-happy.) As with most things in so-long, there's no single right solution; but I'm keen to arrive at a set of defaults that people can agree are a reasonable starting point for most users; and I'm certainly not suggesting that I've done that already ("what should the default settings be?" has been an open question from the outset, really.) -Phil