From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Chris Hecker" Newsgroups: gmane.emacs.bugs Subject: bug#59038: Re[2]: bug#59038: loading this base64 file makes emacs -Q 28.2 peg a core infinitely Date: Sat, 05 Nov 2022 10:39:49 +0000 Message-ID: References: <83h6zd51h0.fsf@gnu.org> <9719cff6-4534-46d9-0fed-1476633ac37d@gmail.com> <83a6554ujx.fsf@gnu.org> Reply-To: Chris Hecker Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBAEEE1BE4-F726-48F8-A17F-391F1FE12CC2" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30489"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/8.2.1721.0 Cc: gerd.moellmann@gmail.com, 59038@debbugs.gnu.org, acm@muc.de To: "Eli Zaretskii" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Nov 05 11:40:19 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 1orGb4-0007l1-TB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 05 Nov 2022 11:40:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1orGaw-0003I4-LF; Sat, 05 Nov 2022 06:40:10 -0400 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 1orGap-0003Fu-F2 for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 06:40:03 -0400 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 1orGao-0003AA-9Y for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 06:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1orGao-0006MH-14 for bug-gnu-emacs@gnu.org; Sat, 05 Nov 2022 06:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Chris Hecker" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Nov 2022 10:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59038 X-GNU-PR-Package: emacs Original-Received: via spool by 59038-submit@debbugs.gnu.org id=B59038.166764479924429 (code B ref 59038); Sat, 05 Nov 2022 10:40:01 +0000 Original-Received: (at 59038) by debbugs.gnu.org; 5 Nov 2022 10:39:59 +0000 Original-Received: from localhost ([127.0.0.1]:55566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orGal-0006Lx-9g for submit@debbugs.gnu.org; Sat, 05 Nov 2022 06:39:59 -0400 Original-Received: from mail-pj1-f43.google.com ([209.85.216.43]:36663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orGaj-0006Lj-BR for 59038@debbugs.gnu.org; Sat, 05 Nov 2022 06:39:58 -0400 Original-Received: by mail-pj1-f43.google.com with SMTP id u8-20020a17090a5e4800b002106dcdd4a0so10397516pji.1 for <59038@debbugs.gnu.org>; Sat, 05 Nov 2022 03:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=d6-com.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:cc:subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=hDu3ezHs8oBbVShNOOZ4gfxamOESLLZDL6SJXyRV9QI=; b=Bd1bh4KPZt3kqjOD7K8qipPgGTGwOvSB11gBdugKXtV5PgqEtqYfpLbxC132wgI33D a3yRF6vJZeANUoFLwgNrHqA2rqoYPYd70D+/ex+cziO+/3xGiXOchh5Fk3DF1Y9yKpQs rp82OXGKG97mFb+Rwuib54IPVJZpFbpJBrt/RnWkK+/GGYfcipieHSPVQkQnTDNYxSve WUpueCpKYxQxT0/kminmN5ubRo4B1Xu2ffDv7yx1Mt0JphPD74U2Fwxkg8QFVwwCM9zl rq/kyV6azi5C/Hhiqo66dqvYPcXBYeRrfVuNH5VV/OnrR9Z/+R72Qi0oAAXzGv5HgtfR QJ8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:reply-to:references:in-reply-to:message-id :date:cc:subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hDu3ezHs8oBbVShNOOZ4gfxamOESLLZDL6SJXyRV9QI=; b=NYCBitssoHCbtfEmnn5WRdqhVSMFyX1r2UMFNePj8CagdbuSX/xlWwXyAY+rUQ05jT VMKaZQ6P2XGB5IuyLHTqkZyENFucCEVY2NggX5n7XSWL3apNNIIQGZ/99SNgR9I7pBox fk01oE8M2Ej4bsq7xFkjOxXA8o6m2w44i4KEYXo6GMZpwaWO+rPKDp36nHxEQs8D0oNy jv8IoIcGZy77TfYn9+VVzNYrcgmFfRdtcRYtIdF/JKPYAWP1bwsmG0lRoOzg+oDIzDc8 vNgbU5SlQBpArOp+2Uhomn01JfqAILG0YMgCeg5SFfqYjel/XpC9prNJpzCOt+e1ZTi8 m8zQ== X-Gm-Message-State: ACrzQf1z+Em2DGuj4vrSLbeAachxZowK3+JSlY95QeRmFzKiMj6RplTQ G4uQ0BZguumxQy2HZo5fOYz++w== X-Google-Smtp-Source: AMsMyM5VzZ+o2QdhriL8YaTA/K0fLnv+SzVyUWciBIBDQMj923oR0UqQetBseXdyWc7tXrfS/4h4tg== X-Received: by 2002:a17:90b:3103:b0:213:2578:e5c5 with SMTP id gc3-20020a17090b310300b002132578e5c5mr40572889pjb.217.1667644791317; Sat, 05 Nov 2022 03:39:51 -0700 (PDT) Original-Received: from [192.168.1.129] (157-131-207-86.fiber.dynamic.sonic.net. [157.131.207.86]) by smtp.gmail.com with ESMTPSA id w3-20020a628203000000b00562784609fbsm1027767pfd.209.2022.11.05.03.39.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Nov 2022 03:39:50 -0700 (PDT) In-Reply-To: <83a6554ujx.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: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:247142 Archived-At: --------=_MBAEEE1BE4-F726-48F8-A17F-391F1FE12CC2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I mentioned the actual length of the line FTR, not as an excuse for unbearably slow display. Ah, ok, sorry, I thought you were disagreeing that the line was not that=20 long. :) It's nice to have that fixed, if it isn't too complex, but in general visiting such a file as C file is not a reasonable thing to do. Right, but I didn't know this was what ?format=3DTEXT downloaded from=20 googlesource.com, so if I'd had unsaved buffers I would have been=20 screwed. Luckily I didn't lose work (except having to reopen a bunch of=20 files to get back to where I was). Like I said, try Emacs 29, where this should be fixed. I just upgraded to 28 from 26, which took a while! :) Anyway, I'll=20 give it a shot sometime, but it sounds like you and Gerd are having=20 different experiences with this file? Chris ------ Original Message ------ From: "Eli Zaretskii" To: "Chris Hecker" Cc: gerd.moellmann@gmail.com; 59038@debbugs.gnu.org; acm@muc.de Sent: 2022-11-05 02:30:58 Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 peg=20 a core infinitely >> From: Chris Hecker >> Date: Sat, 5 Nov 2022 01:21:34 -0700 >> Cc: 59038@debbugs.gnu.org, Eli Zaretskii , acm@muc.de >> >> > It's a single 21,728-character line. >> >> Yeah? This isn=E2=80=99t 1970. I have 32gb of ram and a 12 core cpu. = It=E2=80=99s a bug. It should either parse the file >> (instantly, it=E2=80=99s 27kb) or it should at least stop after a few m= s and tell me it=E2=80=99s lame and needs me to switch >> manually to another mode. I mean, given the 28.2 user experience, ther= e is no opportunity to switch to >> fundamental mode because emacs was hosed. I don=E2=80=99t even think c= trl-g worked for me. > >Like I said, try Emacs 29, where this should be fixed. > >I mentioned the actual length of the line FTR, not as an excuse for >unbearably slow display. --------=_MBAEEE1BE4-F726-48F8-A17F-391F1FE12CC2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

I m= entioned the actual length of the line FTR, not as an excuse for
unbeara= bly slow display.

Ah, ok, sorr= y, I thought you were disagreeing that the line was not that long.=C2=A0 :)=

It's nice to have that fixed, if it isn't too complex, but in general
visitin= g such a file as C file is not a reasonable thing to do.
<= div>
Right, but I didn't know this was what ?format= =3DTEXT downloaded from googlesource.com, so if I'd had unsaved buffers I w= ould have been screwed.=C2=A0 Luckily I didn't lose work (except having to= reopen a bunch of files to get back to where I was).

=
Like I said, try Emacs 29, where this should be f= ixed.

I just upgraded to 28 from 26, which = took a while!=C2=A0 :)=C2=A0 =C2=A0Anyway, I'll give it a shot sometime, b= ut it sounds like you and Gerd are having different experiences with this f= ile?

Chris





------ Original Message ------
From: "Eli Zaretskii" <eliz@gnu.org= >
To: "Chris Hecker" <checker@d6.co= m>
Sent: 2022-11-05 02:30:58
Subject: Re: bug#59038: loading this base64 file makes emacs -Q 28.2 p= eg a core infinitely

From: Chris Hecker <checker@d6.com>
Date: Sat, 5 Nov 2022 01:21:34 -0700
Cc: 590= 38@debbugs.gnu.org, Eli Zaretskii <e= liz@gnu.org>, acm@muc.de
=C2=A0
> It's a single 21,728-character line.
=C2=A0
Yeah? This isn=E2=80=99t 1970. I have 32gb of= ram and a 12 core cpu. It=E2=80=99s a bug. It should either parse the fi= le
(instantly, it=E2=80=99s 27kb) or it should at l= east stop after a few ms and tell me it=E2=80=99s lame and needs me to swit= ch
manually to another mode. I mean, given the 28.= 2 user experience, there is no opportunity to switch to
fundamental mode because emacs was hosed. I don= =E2=80=99t even think ctrl-g worked for me.
=C2=A0
Like I said, try Emacs 29, where this should be f= ixed.
=C2=A0
I mentioned the actual length of the line FTR, no= t as an excuse for
unbearably slow display.
--------=_MBAEEE1BE4-F726-48F8-A17F-391F1FE12CC2--