From unknown Sat Jun 14 03:48:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#22143 <22143@debbugs.gnu.org> To: bug#22143 <22143@debbugs.gnu.org> Subject: Status: 24.5; Emacs blocked on long lines. Reply-To: bug#22143 <22143@debbugs.gnu.org> Date: Sat, 14 Jun 2025 10:48:07 +0000 retitle 22143 24.5; Emacs blocked on long lines. reassign 22143 emacs submitter 22143 Oleksandr Gavenko severity 22143 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 11 12:32:12 2015 Received: (at submit) by debbugs.gnu.org; 11 Dec 2015 17:32:12 +0000 Received: from localhost ([127.0.0.1]:40685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a7RYC-0007mq-2c for submit@debbugs.gnu.org; Fri, 11 Dec 2015 12:32:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41155) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a7RYA-0007md-Es for submit@debbugs.gnu.org; Fri, 11 Dec 2015 12:32:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a7Q1p-0002z3-DC for submit@debbugs.gnu.org; Fri, 11 Dec 2015 10:54:42 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34033) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7Q1p-0002yz-9w for submit@debbugs.gnu.org; Fri, 11 Dec 2015 10:54:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7Q1n-0004gj-WF for bug-gnu-emacs@gnu.org; Fri, 11 Dec 2015 10:54:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a7Q1i-0002yI-UB for bug-gnu-emacs@gnu.org; Fri, 11 Dec 2015 10:54:39 -0500 Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:34255) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a7Q1i-0002y5-FL for bug-gnu-emacs@gnu.org; Fri, 11 Dec 2015 10:54:34 -0500 Received: by lfcy184 with SMTP id y184so8621364lfc.1 for ; Fri, 11 Dec 2015 07:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; bh=7WeDhIn72OyNPtxDdtKk2BHOMh5/rhs2kz6U8IhP51Y=; b=IOaJhDIJnlkYOWppdbf+pE/TlYwl5PUcpEu3ifotBtMfXE6weBc3nNKrPqrLMfkqVJ XAQk1dC0mzaePW/F0dbbSlHr95f3ooJxxuts0HL15jgiwY8uqHTP8C5X3WLyHI1BapgL kF33GLRI/7PUWPKA5wYhP0kzFzmBb9qr2OC4lsQjusLxIp6S4CzNADio6wrSpx46CzwT /23UaLe1UtahYPfQZqyAp81rM+1x7J8FMLbOm/XlS8QSUw/XhhAVwlmqb0IvotS6K9Y8 0R+Yu8zO4GGY3mGrPFyW2LYQYku7zuT/tcMMg0F17l6tpnfGSvh+25JbEprQbjH6IxQS hfQg== X-Received: by 10.25.38.2 with SMTP id m2mr8275133lfm.113.1449849273380; Fri, 11 Dec 2015 07:54:33 -0800 (PST) Received: from desktop ([46.118.53.144]) by smtp.gmail.com with ESMTPSA id dz6sm3313782lbb.17.2015.12.11.07.54.32 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Dec 2015 07:54:32 -0800 (PST) From: Oleksandr Gavenko To: bug-gnu-emacs@gnu.org Subject: 24.5; Emacs blocked on long lines. Date: Fri, 11 Dec 2015 17:54:31 +0200 Message-ID: <87d1ud6kw8.fsf@gavenkoa.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) It is usual for me to open files with large lines in Emacs. Some times this was log, or executable, or dump. But usually this was minified .js or .json file. And only thing I can do is to live with slowness or to kill Emacs and may be clean corresponding desktop-mode entries for *bad* file. I contribute piece to: http://emacs.stackexchange.com/questions/598/how-do-i-handle-files-with-e= xtremely-long-lines Here it is: (setq line-number-display-limit large-file-warning-threshold) (setq line-number-display-limit-width 200) (defun my--is-file-large () "If buffer too large and my cause performance issue." (< large-file-warning-threshold (buffer-size))) (define-derived-mode my-large-file-mode fundamental-mode "LargeFile" "Fixes performance issues in Emacs for large files." ;; (setq buffer-read-only t) (setq bidi-display-reordering nil) (jit-lock-mode nil) (buffer-disable-undo) (set (make-variable-buffer-local 'global-hl-line-mode) nil) (set (make-variable-buffer-local 'line-number-mode) nil) (set (make-variable-buffer-local 'column-number-mode) nil) ) (add-to-list 'magic-mode-alist (cons #'my--is-file-large #'my-large-file-= mode)) But it is for a large files (but help me in many case because files with lo= ng lines usually also themselves big). I didn't investigate how to make test f= or long lines jet. Even with those settings some files (usually minified .js libraries or .json files) froze Emacs. I think due to js-mode, but... I would like to hear solution for long line issue or a way to detect long lines and prevent file from opening (or decide to risk if lines is not toooo long). My point instead of restarting Emacs daemon - safely warn about long lines = so I have a chance to preserve my Emacs session before Emacs die. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (info "(emacs) Visiting") say about large files: If you try to visit a file larger than =E2=80=98large-file-warning-thr= eshold=E2=80=99 (the default is 10000000, which is about 10 megabytes), Emacs asks you for confirmation first. You can answer =E2=80=98y=E2=80=99 to proceed wi= th visiting the file. Note, however, that Emacs cannot visit files that are larger than the maximum Emacs buffer size, which is limited by the amount of memory Emacs can allocate and by the integers that Emacs can represent (*note Buffers::). If you try, Emacs displays an error message saying that the maximum buffer size has been exceeded. User warned about large files. But there are nothing about long lines in manual! I would like to see corresponding entry in manual about long line handling: If you try to scroll to line longer then `long-line-warning-threshold' (t= he default is 10000, which is about 100 lines long), Emacs asks you for confirmation first. In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.2) of 2015-10-24 on trouble, modified by Debian Windowing system distributor `The X.Org Foundation', version 11.0.11702000 System Description: Debian GNU/Linux testing (stretch) Configured using: `configure --build x86_64-linux-gnu --prefix=3D/usr --sharedstatedir=3D/va= r/lib --libexecdir=3D/usr/lib --localstatedir=3D/var/lib --infodir=3D/usr/share/= info --mandir=3D/usr/share/man --with-pop=3Dyes --enable-locallisppath=3D/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24= .5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-li= sp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=3D/usr --sharedstatedir=3D/var/lib --libexecdir=3D/usr/lib --localstatedir=3D/var/lib --infodir=3D/usr/share/= info --mandir=3D/usr/share/man --with-pop=3Dyes --enable-locallisppath=3D/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24= .5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-li= sp:/usr/share/emacs/site-lisp --with-x=3Dyes --with-x-toolkit=3Dgtk3 --with-toolkit-scroll-bars 'CFLAGS= =3D-g -O2 -fstack-protector-strong -Wformat -Werror=3Dformat-security -Wall' CPPFLAGS=3D-D_FORTIFY_SOURCE=3D2 LDFLAGS=3D-Wl,-z,relro' Important settings: value of $LC_TIME: en_DK.utf8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix --=20 Best regards! From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 05 10:41:51 2018 Received: (at 22143) by debbugs.gnu.org; 5 Apr 2018 14:41:51 +0000 Received: from localhost ([127.0.0.1]:39550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f465H-0004Rp-40 for submit@debbugs.gnu.org; Thu, 05 Apr 2018 10:41:51 -0400 Received: from mout.web.de ([217.72.192.78]:38025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f465F-0004Rc-4W for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 10:41:49 -0400 Received: from drachen.dragon ([94.218.191.141]) by smtp.web.de (mrweb101 [213.165.67.124]) with ESMTPSA (Nemesis) id 0M6mL2-1eGmig2Oto-00wTjB; Thu, 05 Apr 2018 16:41:42 +0200 From: Michael Heerdegen To: Oleksandr Gavenko Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. References: <87d1ud6kw8.fsf@gavenkoa.example.com> Date: Thu, 05 Apr 2018 16:41:41 +0200 In-Reply-To: <87d1ud6kw8.fsf@gavenkoa.example.com> (Oleksandr Gavenko's message of "Fri, 11 Dec 2015 17:54:31 +0200") Message-ID: <87muyh4swq.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:0GsMqaUXjDcY4fToSVu8q1SZJvZlHwF/KhW1aGDDQN5ImFZ1rOB bUsIHaECukWIJlLsFX1ZGcC06NMJjpRmcXcDzia4xtzVXHdwz9nReDM04blPkFe64i6oICS I6aZcGVQKw21sfvJfuqxrQxqOAWE/bH+XWxXk+BwoT1yRjnGvGmJs87mevOa61Vp+Bd4RDc 7hslhwaJWCzqx+BIgkBFA== X-UI-Out-Filterresults: notjunk:1;V01:K0:q5cdeSOb0dM=:oPKHBS3u7pOCByJjPpaOBC F50/JoDgLIR2pPs7WGPchdw27KOJIDoZa8StMzZyD9d/Vnwc+sMaZos88gIoPi3dz3eOhFhej T2T0NLIAvgS/4ABxSmFe80Oi/J+xFTEytImnMBTKdwLi+3A+K4jqnhpn0L9E8L1729UPqo403 ux2HVlJudl53m/nSci9+eyHrs0FDF6+I2zK1451qAG0SHq4y6+KON5HX+b4F7+2SPq3lWm9Js SgUbNe6G3ERBJ2UgGn6Js4uKENTaWlqNCKssGjBFuy6XQ7quZxWcDY1N2Po6nhGPm6xad6m2e 00e2lxCeyAAqdnREV4Wxrrj07aCHV42A+Bwm2XetQ+sNFPxf1tdVVP7UWs6FagypsYn70p9fC nEYmQXR/MgfRZkjpi2iT+lqyKRIJoclFvdsYeNEiRJUrElZq8fq9JZvstsNRLApl5IYgOWivs DDHhZC9FifjwCAdQBjPh2DyWEyX09vtw7kVVRv68vt8sQP+XCkSafNbrTavqeQyiF+6TnBTjR WEBEmQeW2qZflYY4vaB1Iei7CiCE2pussUokk7s+znskhy2k9HjYsLSV9fo9v+065UOpGVO0n uOoZU1ZRvTVPg9YdSJlWocLOky7Gd3NSEOa63dKu/3capc45PZVtmjy8RRJwQiZbnHjxfN4jy d5z1z1EDVvW/zT/v+60lz5omMh0U6NBKSWeD76xkBSgfidQvL/719b749RzplqPbLsM9OHCom PeLLYWUTCUsGotE+ylWHvun7ipcy6uP4p+ZdtXYvp7i9s4XS/HfZU6cZwnuK2s21KG6SNQtUC ja8auZjSmQDdTaD2mZTFeSDbR0hUt20ulfIaL/N5VVt6W02hZ8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, (First, I don't think this is wishlist. Isn't it a bug when an editor can't open a file or freezes when doing so?) In the last weeks I had to look at my .gnus.registry.eieio. It has a line with ~ 400000 chars in my case. Opening it with Emacs is not fun. Searching and scrolling is all extremely sluggish. I then realized that something simple like #+begin_src emacs-lisp (add-hook 'find-file-hook (defun my-find-file-care-about-long-lines () (save-excursion (when (and (search-forward-regexp ".\\{2000\\}" 50000 t) (y-or-n-p "Very long lines detected - enable longlines-mode? ")) (require 'longlines) (longlines-mode +1))))) #+end_src seems to work around the problem quite nicely (though the rest is only a heuristic). But - longlines is obsolete, and - this requires user configuration. When I tried to open the .gnus.registry.eieio file with other editors in my Debian, most froze. "kate" OTOH warned about the extremely long line and added line breaks automatically - AFAIU this is quite the same as what longlines does. If we can't solve the issue with long lines in the display code, maybe we should do something like this by default? Just freezing or presenting a buffer where most actions are very sluggish is not a good choice. Needing to kill an editor after opening the "wrong file" is not good. Thanks, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 05 11:00:10 2018 Received: (at 22143) by debbugs.gnu.org; 5 Apr 2018 15:00:10 +0000 Received: from localhost ([127.0.0.1]:39555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46N0-0004vc-KV for submit@debbugs.gnu.org; Thu, 05 Apr 2018 11:00:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46My-0004uY-RB for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 11:00:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f46Mq-0004io-B1 for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 11:00:03 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f46Mq-0004ik-6b; Thu, 05 Apr 2018 11:00:00 -0400 Received: from [176.228.60.248] (port=3092 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f46Mp-0002eF-Ev; Thu, 05 Apr 2018 10:59:59 -0400 Date: Thu, 05 Apr 2018 18:00:12 +0300 Message-Id: <83y3i11ywz.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <87muyh4swq.fsf@web.de> (message from Michael Heerdegen on Thu, 05 Apr 2018 16:41:41 +0200) Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. References: <87d1ud6kw8.fsf@gavenkoa.example.com> <87muyh4swq.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org, gavenkoa@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Michael Heerdegen > Date: Thu, 05 Apr 2018 16:41:41 +0200 > Cc: 22143@debbugs.gnu.org > > (First, I don't think this is wishlist. Isn't it a bug when an editor > can't open a file or freezes when doing so?) This bug was marked wishlist because it asks for a new feature: a warning about long lines when visiting a file. The bug report about slow redisplay in this case and in similar cases is bug#13675, and it is not marked wishlist. > If we can't solve the issue with long lines in the display code, maybe > we should do something like this by default? Practical and detailed proposals, let alone patches, in that direction will be most welcome. But please don't forget that long lines could materialize not just when a file is first visited, but also as result of its editing, or more generally when some text is generated by editing, even if the buffer doesn't visit any file. Bonus points for displaying such warnings in those cases as well. TIA From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 05 11:20:58 2018 Received: (at 22143) by debbugs.gnu.org; 5 Apr 2018 15:20:58 +0000 Received: from localhost ([127.0.0.1]:39561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46h8-0005Pm-CF for submit@debbugs.gnu.org; Thu, 05 Apr 2018 11:20:58 -0400 Received: from mout.web.de ([212.227.15.14]:43047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46h6-0005PZ-38 for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 11:20:56 -0400 Received: from drachen.dragon ([94.218.191.141]) by smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id 0MWBA1-1f2BwG1EYD-00XOpk; Thu, 05 Apr 2018 17:20:49 +0200 From: Michael Heerdegen To: Eli Zaretskii Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. References: <87d1ud6kw8.fsf@gavenkoa.example.com> <87muyh4swq.fsf@web.de> <83y3i11ywz.fsf@gnu.org> Date: Thu, 05 Apr 2018 17:20:48 +0200 In-Reply-To: <83y3i11ywz.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 Apr 2018 18:00:12 +0300") Message-ID: <87in954r3j.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:R+SyFwdv6nbct7WzUlsvWI9Y++y6Gcozouha/oy1YeC0biYXVMh 1q8ueZ/b10GmuSFDWgFPxJuEBaW1Pi9fYHe3jxv+37bzHQEHDZaDIY26TmIDmCY4LCE2q1e JPKoiMT0rODoiiZadlBDbIfK9jvfAI84EIEh1EK0Zj7V2Tjm7ooy0+dFUnOqKBnYabWQ1Tv E/vofG7nyWru6Ui3gTnWQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:ThI54TlEiKk=:X+HuwuP9Yd6m7fhjoC16gv sQbOEEmsSBSMnmGZ3eVyDrxleIrtrsqFYmpQQg6BjPCV0VKVaffFb5rIp+eYzfB64KctoUdA8 QwHQ1GfKnpAW4gKKLDV5iMCu4eHriBoUKe81fgrBYYFjF85nBhjdOiDpfYE7dROe5RldH/CC+ P+cgG6jAIJNsT/LGuvNHPznZkt1pcuNXVoYT5duLJxXbPpwRgV1gjNtUEE6ka+xtBqNSf9pEX GSmpQVAmjpCgj0ishiqs/xhwNrtbo09IDju0S2Y8LK0Y2KOy+coL7wwhlLFkOq6wAfraQbuEV 4ULDvZlLpDCpnillvSmMLP0GG7HuKa1guSMD/p1HtSrI6KQkiWfd8FLkKhBhNJEJnG1JDp8HB zbutvutC6IpNKXeTddZ90d1fdngt8OlJcOtczE3z/3mbqbycBKfiCf0z/SGqH+b6BnOYbZmrc oPCEmQz2Ot8jAUGyFshP8JDfgcAJDugiwM3cUEuwlvIycEXs93K7OSukU1sowLY9lullxvM4K +iHhsvgvmnmnW5JiXp7Z/3dleAaFhjRTpSNPL62wtCXGLPoqdObCfofrsnQiHJFkBD3UBJ00v 7O+jMAyfDooQCYRN+a8P6vf10mdhi7F4iRzhDFOzt50BiYBWgqg6JzcnRFjpY+71d1e0pbf6S SJzO4VIa3CTAVmWh5u+vqI3zx3ayI6CaJiJOLMNUvJkvPS+sXPTuvdhJFJOtOMOVJ0/flchx3 xW4nc1+tns5mcUf8u/c1FApFNOjVHI5EtjzyCqMEsE+ezJm88vpj4dmnd4FC2GDLrLtk3VYhx jYbTcTrNVZy5hhs2VcGO2er74T8Ebgs5IeozaGyiT7sMPMUsvE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org, gavenkoa@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Eli Zaretskii writes: > The bug report about slow redisplay in this case and in similar cases > is bug#13675, and it is not marked wishlist. Ah, thanks. Didn't expect multiple reports about this. > > If we can't solve the issue with long lines in the display code, maybe > > we should do something like this by default? > > Practical and detailed proposals, let alone patches, in that direction > will be most welcome. Sorry about my ignorance, but - are there reliable means of handling such buffers other than longlines? Does longlines always behave sane with such files? Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 05 11:34:37 2018 Received: (at 22143) by debbugs.gnu.org; 5 Apr 2018 15:34:37 +0000 Received: from localhost ([127.0.0.1]:39566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46uL-0005jV-JU for submit@debbugs.gnu.org; Thu, 05 Apr 2018 11:34:37 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f46uJ-0005jI-FT for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 11:34:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f46uB-0004Aa-3f for 22143@debbugs.gnu.org; Thu, 05 Apr 2018 11:34:30 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f46uA-0004AS-WE; Thu, 05 Apr 2018 11:34:27 -0400 Received: from [176.228.60.248] (port=3482 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f46uA-0000AD-Fb; Thu, 05 Apr 2018 11:34:26 -0400 Date: Thu, 05 Apr 2018 18:34:40 +0300 Message-Id: <83woxl1xbj.fsf@gnu.org> From: Eli Zaretskii To: Michael Heerdegen In-reply-to: <87in954r3j.fsf@web.de> (message from Michael Heerdegen on Thu, 05 Apr 2018 17:20:48 +0200) Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. References: <87d1ud6kw8.fsf@gavenkoa.example.com> <87muyh4swq.fsf@web.de> <83y3i11ywz.fsf@gnu.org> <87in954r3j.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org, gavenkoa@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Michael Heerdegen > Cc: gavenkoa@gmail.com, 22143@debbugs.gnu.org > Date: Thu, 05 Apr 2018 17:20:48 +0200 > > > Practical and detailed proposals, let alone patches, in that direction > > will be most welcome. > > Sorry about my ignorance, but - are there reliable means of handling > such buffers other than longlines? Does longlines always behave sane > with such files? I don't know; it's possible. I know that turning on truncate-lines sometimes helps, but not always. Some research is probably needed to see if longlines-like solution is "good enough". Also, if we decide that something like longlines is a reasonably good solution, or the best we can come up with, I think we need a stripped-down version of it, we don't need all the bells and whistles of a full-fledged customizable minor mode. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 09:53:33 2020 Received: (at 22143) by debbugs.gnu.org; 21 Aug 2020 13:53:33 +0000 Received: from localhost ([127.0.0.1]:45456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k97U4-00022l-TW for submit@debbugs.gnu.org; Fri, 21 Aug 2020 09:53:33 -0400 Received: from mail-yb1-f175.google.com ([209.85.219.175]:46735) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k97U2-00022T-H6 for 22143@debbugs.gnu.org; Fri, 21 Aug 2020 09:53:31 -0400 Received: by mail-yb1-f175.google.com with SMTP id x10so1060300ybj.13 for <22143@debbugs.gnu.org>; Fri, 21 Aug 2020 06:53:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=J2lAG1mTFfzNnXzC+hfGrg7TNZYcdDTqkyPpNugxnmc=; b=h/oNLTeGb7xc8XAOvUwL4qSCZErb6EFk84SENtMOrOCe1s3L2CkScrVgUsxWetFR+9 34P0Fu754dGYj9F7AOmccBJ7ugJC2Gkcxlo0mKU9I1SB3JxhR6UxNlXTjgNrZEJ+qCSZ CSqsZYUynkbq5ojhPdWVTL2V08ltmCXbrLYDdQJgnuTbCyqnqkzMHsbU1riqJJFH7cLE N3Fl5ezlvYYjb6LvOzli84DySdPJjU6tX8dPiaRI3lAPdrJBoac38G2mVvLODFc/TJq0 EO3cMbSfAKh+/Oj0SRJURYTtJ/ZMaJESZ66VR/i+gzVWRz6wWiXuf73Z15yqqWNcvThP ItwA== X-Gm-Message-State: AOAM530nAlnA+qQpsyEkhdEV0xWbhL9DvlxuEA+7eIi+CXdow+rcMyKS 8NLG9RrsDqBgkZy5YHnEukK0h6zX7/d5Ubjwhso= X-Google-Smtp-Source: ABdhPJyymWqKFMtrUGgUqqZwFj87H2jH2wtgkd1pwr0lMBbyvpJsx15T+I9IaML+/0LeGzaEhi2s7blit0xkks1za3s= X-Received: by 2002:a25:9843:: with SMTP id k3mr3895479ybo.466.1598018004919; Fri, 21 Aug 2020 06:53:24 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Aug 2020 06:53:24 -0700 From: Stefan Kangas In-Reply-To: <87d1ud6kw8.fsf@gavenkoa.example.com> (Oleksandr Gavenko's message of "Fri, 11 Dec 2015 17:54:31 +0200") References: <87d1ud6kw8.fsf@gavenkoa.example.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Date: Fri, 21 Aug 2020 06:53:24 -0700 Message-ID: Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. To: Oleksandr Gavenko Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Oleksandr Gavenko writes: > It is usual for me to open files with large lines in Emacs. > > Some times this was log, or executable, or dump. > > But usually this was minified .js or .json file. > > And only thing I can do is to live with slowness or to kill Emacs and may be > clean corresponding desktop-mode entries for *bad* file. > > I contribute piece to: > > http://emacs.stackexchange.com/questions/598/how-do-i-handle-files-with-extremely-long-lines > > Here it is: > > (setq line-number-display-limit large-file-warning-threshold) > (setq line-number-display-limit-width 200) > > (defun my--is-file-large () > "If buffer too large and my cause performance issue." > (< large-file-warning-threshold (buffer-size))) > > (define-derived-mode my-large-file-mode fundamental-mode "LargeFile" > "Fixes performance issues in Emacs for large files." > ;; (setq buffer-read-only t) > (setq bidi-display-reordering nil) > (jit-lock-mode nil) > (buffer-disable-undo) > (set (make-variable-buffer-local 'global-hl-line-mode) nil) > (set (make-variable-buffer-local 'line-number-mode) nil) > (set (make-variable-buffer-local 'column-number-mode) nil) ) > > (add-to-list 'magic-mode-alist (cons #'my--is-file-large #'my-large-file-mode)) > > But it is for a large files (but help me in many case because files with long > lines usually also themselves big). I didn't investigate how to make test for long > lines jet. > > Even with those settings some files (usually minified .js libraries or .json > files) froze Emacs. I think due to js-mode, but... > > I would like to hear solution for long line issue or a way to detect long > lines and prevent file from opening (or decide to risk if lines is not toooo > long). > > My point instead of restarting Emacs daemon - safely warn about long lines so > I have a chance to preserve my Emacs session before Emacs die. Is this better with so-long.el? etc/PROBLEMS says: *** Editing files with very long lines is slow. For example, simply moving through a file that contains hundreds of thousands of characters per line is slow, and consumes a lot of CPU. This is a known limitation of Emacs with no solution at this time. Is there anything more we can/should do in this case short of rewriting the display engine? Does it make sense to track this limitation in a bug report? Best regards, Stefan Kangas From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 10:02:03 2020 Received: (at 22143) by debbugs.gnu.org; 21 Aug 2020 14:02:03 +0000 Received: from localhost ([127.0.0.1]:47897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k97cJ-0002ux-H8 for submit@debbugs.gnu.org; Fri, 21 Aug 2020 10:02:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k97cI-0002uS-7U for 22143@debbugs.gnu.org; Fri, 21 Aug 2020 10:02:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43862) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k97cC-0003mC-RL; Fri, 21 Aug 2020 10:01:56 -0400 Received: from [176.228.60.248] (port=4703 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k97c4-0002Dt-Om; Fri, 21 Aug 2020 10:01:50 -0400 Date: Fri, 21 Aug 2020 17:01:43 +0300 Message-Id: <83blj4ayig.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Fri, 21 Aug 2020 06:53:24 -0700) Subject: Re: bug#22143: 24.5; Emacs blocked on long lines. References: <87d1ud6kw8.fsf@gavenkoa.example.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 22143 Cc: 22143@debbugs.gnu.org, gavenkoa@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Fri, 21 Aug 2020 06:53:24 -0700 > Cc: 22143@debbugs.gnu.org > > Is this better with so-long.el? No, I think so-long.el is better, and in any case so-long.el is our canonical solution (or, rather, band-aid) for this annoying problem. > etc/PROBLEMS says: > > *** Editing files with very long lines is slow. > > For example, simply moving through a file that contains hundreds of > thousands of characters per line is slow, and consumes a lot of CPU. > This is a known limitation of Emacs with no solution at this time. > > Is there anything more we can/should do in this case short of rewriting > the display engine? Maybe there is, but I have yet to hear ideas for how to do that. Ideas are still welcome. > Does it make sense to track this limitation in a bug report? We already have one: bug#13675. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 13:42:23 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 17:42:23 +0000 Received: from localhost ([127.0.0.1]:48238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9B3X-0007VV-2l for submit@debbugs.gnu.org; Fri, 21 Aug 2020 13:42:23 -0400 Received: from mail-yb1-f178.google.com ([209.85.219.178]:35257) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k9B3S-0007V9-Lg for control@debbugs.gnu.org; Fri, 21 Aug 2020 13:42:21 -0400 Received: by mail-yb1-f178.google.com with SMTP id y134so1460055yby.2 for ; Fri, 21 Aug 2020 10:42:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=EWV69o2tJibW/qvbUF6dqOcHAYWps8Mkc9e4bv8rbhU=; b=YEkv0iJYDZN6/jvtVYM+J+9Buy6yaMMVfwpDA2uVayEEXsKmG5G2AHclYojzVAdWyi c5bLtHXM//llNE9Gd90wXhfJ4cXrQISpaEP5Dmp9CfXUwPPVm99Dbvylxb5I3IauF6NW d+06q/oRRvxfyKJvOkxjkDTU+KahbmbGGLTLXgGw+T1RL+8W68u16qai50C05UfwJ47o gGFkTUM7S3p/xeT3Tv+90nf7zzqMp8lNJphMaQJ59fDMikCxVelwwKKKbTbiFqvtkd+Y g28ksVg4znTVM7Sm5bvk2HFjxOMusIfjRqalwGwy8R7Bh8UH1gt8Hzc4e8JSRSFUPNSf tH+Q== X-Gm-Message-State: AOAM532EKDD4THkT5g2xf++7vJ3rgfsWJRYCXq0rjqH7KsH/VZ4bKwLS S3mOHKcIar3cyUJfwGx7PZkobleXeCaY2Se+WxhOv4h/gnWEgQ== X-Google-Smtp-Source: ABdhPJyhkJ+ZWtZcBFaHE1oBMiKOVWOQnTSGkJIWAH4N+fWv8b8N8GlbjMdcPi5Fg7F2qQj4/LPz1s7H71KL6bxtXLc= X-Received: by 2002:a5b:410:: with SMTP id m16mr4981727ybp.309.1598031732879; Fri, 21 Aug 2020 10:42:12 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Aug 2020 10:42:11 -0700 From: Stefan Kangas MIME-Version: 1.0 Date: Fri, 21 Aug 2020 10:42:11 -0700 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 22143 normal merge 13675 22143 thanks Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.178 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.178 listed in wl.mailspike.net] 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: severity 22143 normal merge 13675 22143 thanks Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.219.178 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.219.178 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.0 BLANK_SUBJECT Subject is present but empty -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines severity 22143 normal merge 13675 22143 thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 23 04:59:21 2022 Received: (at control) by debbugs.gnu.org; 23 Jul 2022 08:59:21 +0000 Received: from localhost ([127.0.0.1]:43440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFAym-0002AM-Vv for submit@debbugs.gnu.org; Sat, 23 Jul 2022 04:59:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:49244) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFAyl-0002A7-My for control@debbugs.gnu.org; Sat, 23 Jul 2022 04:59:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZOx7Or2+rJP/3U1mbA613hdzQoIuBCaxaSR0wzztDYo=; b=TvSFuQGmBnIZFLC5hrnyBpbKew KxSTZ4bKgdNagP4ifRZ5WDMNpXTRFbQHB/xYij+kk6DbSJq/H92szpaQDDrixujkYMvHvfbz00rBM +fumZNM2Z+l1I0Madiv/J93c94FN5KfQ3WuoVCqFBIUk/8Q2iQoYKtbXkL6iVo2xBW2w=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFAyd-0000g5-U0 for control@debbugs.gnu.org; Sat, 23 Jul 2022 10:59:13 +0200 Date: Sat, 23 Jul 2022 10:59:08 +0200 Message-Id: <87mtd0tdb7.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #40007 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 40007 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 40007 29.1 quit From unknown Sat Jun 14 03:48:07 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 20 Aug 2022 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator