From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45898: 27.1; wedged in redisplay again Date: Tue, 07 Jun 2022 17:00:01 +0300 Message-ID: <83bkv47evy.fsf@gnu.org> References: <46b65e3f-cf3d-a3f2-9a9a-100e58274ff6@jovi.net> <87h74wh9x7.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1179"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs-hacker2018@jovi.net, 45898@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 07 16:01: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 1nyZln-000AXA-25 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jun 2022 16:01:19 +0200 Original-Received: from localhost ([::1]:49704 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyZlk-0001AQ-6R for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Jun 2022 10:01:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyZlW-00019F-8Z for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 10:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47126) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nyZlV-0006Wk-Vv for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 10:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nyZlV-0002Wu-VX for bug-gnu-emacs@gnu.org; Tue, 07 Jun 2022 10:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Jun 2022 14:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45898 X-GNU-PR-Package: emacs Original-Received: via spool by 45898-submit@debbugs.gnu.org id=B45898.16546104249669 (code B ref 45898); Tue, 07 Jun 2022 14:01:01 +0000 Original-Received: (at 45898) by debbugs.gnu.org; 7 Jun 2022 14:00:24 +0000 Original-Received: from localhost ([127.0.0.1]:41023 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyZkt-0002Vr-GD for submit@debbugs.gnu.org; Tue, 07 Jun 2022 10:00:23 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nyZkq-0002Vc-3g for 45898@debbugs.gnu.org; Tue, 07 Jun 2022 10:00:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36172) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyZkk-0006L0-DT; Tue, 07 Jun 2022 10:00:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1t2/yS9fSp/f4K9jHAwlyy2vfzyRJeuqBkmzsCRpSYA=; b=Y6L2/27yQUdq cY/HPQCM5AoZPuDOWh129DiDeDxSxXkLIoGYk7/B+NfemynQfC0GBOhQGD7IHumhBbQNoR5lo/NpO /EDzv9nan1M4EpIqvn4I35cvtQEzI+tNcSo73HpnsSRJ8OJd1cDFprOxj8vwzoXBDCqb9fstJM5P1 MOwsgH+kiDzoth1fWfQlpuPnEUXN8y/ocKH6Kxb26I7zb7v6GzFH2da0kKUINmfwW6m2Tro81AuVa pDpuFu6CchEGWdWXMSYJlsxKti65xPihKes4/+GPaFJqApL4A+FTGuitCDfhFEttOzHf/s5EnENS5 /JMKFYwQGil/XGm7xcN/TQ==; Original-Received: from [87.69.77.57] (port=2715 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyZkh-0006kk-Eg; Tue, 07 Jun 2022 10:00:14 -0400 In-Reply-To: <87h74wh9x7.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 07 Jun 2022 15:37:08 +0200) 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:233893 Archived-At: > From: Lars Ingebrigtsen > Cc: 45898@debbugs.gnu.org, Eli Zaretskii > Date: Tue, 07 Jun 2022 15:37:08 +0200 > > Devon Sean McCullough writes: > > > If lldb forces read_char to return Qnil or redisplay_internal to return, > > will Emacs crash immediately or survive long enough to save all buffers > > or better yet continue working? > > (I'm going through old bug reports that unfortunately weren't resolved > at the time.) > > It probably won't continue working, but it's hard to say. I think it is more important to realize that Emacs will re-enter redisplay right away. > > P.S. If there exists a way to quickly and safely abort redisplay, > > perhaps there should be a hook invoked when repeated keyboard-quit > > has no effect, allowing experimentation into workarounds for this > > apparently intractable redisplay problem? > > I wonder whether there's been any discussion about handling `C-g' during > redisplay. For instance, if the user hits `C-g' six times in a row > during redisplay, that should be an indication that perhaps Emacs should > stop doing what it's doing -- and, for instance, switch on so-long-mode. > > Eli, would it be possible to implement something like that? Not directly from redisplay, I think, no. We could perhaps push an event onto the input queue that would do something Lispy when processed, like turn on some mode. But I think the main problem here is that we don't necessarily read the keyboard or do QUIT processing inside redisplay, at least the parts of it which triggered this discussion. We also don't currently have any mechanism to quickly exit redisplay, so we will need to develop that somehow. Basically, each time this issue comes up, I get the impression that it is not quite clear what (not how, but what) people would like to happen. They want to unwedge Emacs, that much is clear, but what to do after that to avoid immediately wedging it again? Because even so-long-mode is not a guarantee of getting a responsive Emacs.