From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#45085: Have so-long mode fire-sprinkler system always ready for M-x compile, M-x shell Date: Sat, 23 Oct 2021 03:35:00 -0700 Message-ID: References: <87im9fuli6.5.fsf@jidanni.org> <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9722"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 45085@debbugs.gnu.org, =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson To: Phil Sainty Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 23 12:36:20 2021 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 1meENv-0002Jp-Vx for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 12:36:19 +0200 Original-Received: from localhost ([::1]:57942 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meENu-00061T-Ra for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 06:36:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meENf-000614-Jp for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 06:36:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51163) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1meENe-0003tR-0k for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 06:36:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1meENd-0007Ue-Tj for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 06:36:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Oct 2021 10:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45085 X-GNU-PR-Package: emacs Original-Received: via spool by 45085-submit@debbugs.gnu.org id=B45085.163498531228730 (code B ref 45085); Sat, 23 Oct 2021 10:36:01 +0000 Original-Received: (at 45085) by debbugs.gnu.org; 23 Oct 2021 10:35:12 +0000 Original-Received: from localhost ([127.0.0.1]:34473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meEMq-0007TK-Au for submit@debbugs.gnu.org; Sat, 23 Oct 2021 06:35:12 -0400 Original-Received: from mail-pl1-f176.google.com ([209.85.214.176]:39439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meEMk-0007Sa-Uj for 45085@debbugs.gnu.org; Sat, 23 Oct 2021 06:35:09 -0400 Original-Received: by mail-pl1-f176.google.com with SMTP id t21so4489695plr.6 for <45085@debbugs.gnu.org>; Sat, 23 Oct 2021 03:35:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=mVt5Iecr3yv3emeYXmP/Jvmf7BzmBANNHq1A0FPS2jc=; b=bPruIs+0Oa0DxPYHcIo8GJnuuJvdvSF6FK88sEiNuHFzJ/npk4Y7Zaz8AmCLJaMrjW KefW44X8hyvbGzeVmbi3XYe/ZtahYFwce2waRg2HBNx432VJ6VKO7RmCbJo9rrBMj+Dk KvjaG+St3r+bjTetnIlxPs5PSUb7c7L0EWOZ2SZxKCBNJbHUY0WRkcER9bZCCrCPafGt UYidabI6qB+iGLXh8Z70tSnrc/Lgzj/YY63f/yS6Mcv7GVwGn9IHSvYV9cbqiPqdejut ybZ1XvBIOFKGZTnfXPEaTsiG4Tcmui16lk7bTE56kvYW4wir/wmxj7uteQEZnKlxL4s4 H9BA== X-Gm-Message-State: AOAM531Awr+bDmva9+vRDFBHEbBkGv6qVWjTLaByn26jfJckR/O6w4rT SWoStScWlWFWHnj88QfwUCjHLBLvv2cYEdpeNgc= X-Google-Smtp-Source: ABdhPJzbDmcxcb0k2OHvOEpJQ7ms+mbY00UeLJ/hfWOwHnB8yZYY8Xhr/7pIwTeFBs1CAT807iMklZjmMyVDR8mH4Oo= X-Received: by 2002:a17:902:e750:b0:140:2693:b2e8 with SMTP id p16-20020a170902e75000b001402693b2e8mr5009076plf.22.1634985301094; Sat, 23 Oct 2021 03:35:01 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 23 Oct 2021 03:35:00 -0700 In-Reply-To: <76bfb5aa-3bbf-3e0f-ccbc-08cbeff4668f@orcon.net.nz> (Phil Sainty's message of "Thu, 10 Dec 2020 00:02:22 +1300") 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:217969 Archived-At: tags 45085 + wontfix close 45085 thanks Phil Sainty writes: > One immediate issue with the scenario you're considering > is that buffers handling process output are commonly > auto-scrolling to the end of the output, which means that > after running a command which produces a massive line, > you're liable to be left with the *end* of the giant line > visible in the window (which is the worst-case situation); > so Emacs might struggle with that even if so-long was > active. > > I do think it would be interesting to experiment with using > `after-change-functions' to detect the insertion of > extremely long lines into a buffer, but I also think it > might bring significant complications, so I don't have any > current plans to extend the library in these directions. > > We can be relatively confident about the suitability of > calling `so-long' in a buffer which is visiting a file of > programming code; but it's harder to have such confidence > when considering buffers *generally* -- Emacs buffers can be > used for almost anything, and it may be wildly inappropriate > for `so-long' to get involved in many of those cases. > Especially when considering buffers dealing with external > processes, when the buffer's mode might be fairly generic, > yet with a wide variety of different output possibilities. > > Explicit/white-listed uses of `so-long-minor-mode' can be > useful, however. For example, I recall an Emacs 26 user > reporting excellent performance improvements (albeit at the > cost to the readability) from using `so-long-minor-mode' in > debugger backtrace buffers when giant lists of text > properties were involved; so there's certainly scope to use > so-long outside of file-visiting buffers in particular > scenarios; but my gut feeling is that such uses ought to be > targeted individually. It seems like this is not something we want to do or even see as feasible. So I'm closing this as wontfix. If this conclusion is incorrect, please reply to this email (use "Reply to all" in your email client) and we can reconsider.