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#56393: Actually fix the long lines display bug Date: Wed, 06 Jul 2022 14:41:08 +0000 Message-ID: <762d224809114fbaf4af@heytings.org> References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <83a69n90t8.fsf@gnu.org> <38c1a31040ad21b41adc@heytings.org> <835ykb8x3z.fsf@gnu.org> <38c1a310403dbabc7270@heytings.org> <834jzv8sv4.fsf@gnu.org> <38c1a31040ba2976eb4d@heytings.org> <83y1x77c2w.fsf@gnu.org> <87k08rkvgb.fsf@gnus.org> <38c1a31040e94458bd3d@heytings.org> <83o7y277b8.fsf@gnu.org> <762d224809bcab0d6bbc@heytings.org> <83fsje74pz.fsf@gnu.org> <762d224809bc038d2030@heytings.org> <838rp672p7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31303"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56393@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 06 16:42:12 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 1o96EE-0007uN-EC for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 16:42:10 +0200 Original-Received: from localhost ([::1]:56712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o96ED-00082V-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Jul 2022 10:42:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o96E6-00082L-RO for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 10:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60928) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o96E6-0006VF-Ip for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 10:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o96E6-0006dF-Cr for bug-gnu-emacs@gnu.org; Wed, 06 Jul 2022 10:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 06 Jul 2022 14:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165711847225427 (code B ref 56393); Wed, 06 Jul 2022 14:42:02 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 6 Jul 2022 14:41:12 +0000 Original-Received: from localhost ([127.0.0.1]:54825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o96DI-0006c3-Ed for submit@debbugs.gnu.org; Wed, 06 Jul 2022 10:41:12 -0400 Original-Received: from heytings.org ([95.142.160.155]:55282) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o96DG-0006bs-NF for 56393@debbugs.gnu.org; Wed, 06 Jul 2022 10:41:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1657118469; bh=MZ0nBsn53Bzf47p3zkmCJQqcsKztcBW7xTnAaDSAYUY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=yBDB6aa6ZidaKEoq1cycSr58Kgq4PS7MdCwFQWoBFyA8lIyghKjKomiMfylskXJJM hQS4ly0AiE16oFQWbenpsI/jOBzJsHnItfUF3TUvfMuDy77IOS1u8v67JdaVzQBE0G tkPnT7hY4h6CNzZ1LHFqtVieTFL8fAN4l/+9AvUkC5/hUcLqmw0X/y2EZxTCjdLuM+ jv053vyCbBXyodIOocEf9F1NnCUd4qt/x74y+VWKPQ42KeEOCoqUeXznRGSJdJBeqb zSbJ1SgKyKsczYIEFmfKEltch4yJer4rI52iyMOWqiIhj/Xehd+5H0YP2boriDPxpB pEEdMiIrKkuqg== In-Reply-To: <838rp672p7.fsf@gnu.org> 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" Xref: news.gmane.io gmane.emacs.bugs:236258 Archived-At: > > I think we must, because font-lock is run by the display engine, and if > font-lock makes redisplay significantly slower, it's part of the same > problem. > I disagree. It's not the redisplay part that make font-lock slower, but how it parses the buffer. So it's a different problem. > > Oh, we agree here: it's definitely way better. I'm just saying that a > complete solution cannot force users to make such sacrifices. > Users can reasonably expect and understand that in exceptional circumstances a non-essential editing feature is, by default, turned off, if the purpose of doing that is to maintain responsiveness. If you load a very big file in a browser (or for that matter in any application), it will become sluggish. Try to open the 1GB hugedictionay.json file with vim, nano, VS Code, Atom, and try opening it with the patched Emacs. (Atom is the only one that displays a warning: "Atom will be unresponsive during the loading of very large files. Do you still want to load this file?" If you proceed, Atom becomes unuseable.) > > Why is 'recenter' at all relevant, btw? It isn't called by the display > code, AFAIR, so why do we have to disable it? > Because commands in auto-narrow-widen-automatically might call "recenter" for aesthetic purposes. One example is end-of-buffer. Which means that what you have is (progn (widen) (recenter)), which takes a few seconds without fundamentally changing what is on display. > > I think there's a misunderstanding here: what these Lisp programs don't > expect is to find narrowing that is different from what the user sees or > expects top have. Narrowing is largely a user-level feature, so using > it for internal purposes is problematic at best. > Sorry, I don't get what you mean. Do you have a concrete example of a problematic function? A Lisp program that takes into account the possibility that the user uses narrowing and that needs to have access to the whole buffer will use (save-restriction (widen) ...). A Lisp program that requires the user to narrow the buffer to work properly will still work, because explicit narrowing can still be used with auto-narrow mode. What are the remaining possibilities?