From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line Date: Sat, 10 Jun 2023 12:07:22 +0300 Message-ID: References: <831qij24qm.fsf@gnu.org> <83wn0bzoeb.fsf@gnu.org> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28353"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 63988@debbugs.gnu.org, aaronjensen@gmail.com, Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 11:08:13 2023 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 1q7uZw-0007D5-Np for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 11:08:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7uZp-0006Ol-El; Sat, 10 Jun 2023 05:08:05 -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 1q7uZm-0006OW-FD for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 05:08:02 -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 1q7uZm-0000nB-6X for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 05:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7uZm-0002kz-2w for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 05:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 09:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63988 X-GNU-PR-Package: emacs Original-Received: via spool by 63988-submit@debbugs.gnu.org id=B63988.168638804910551 (code B ref 63988); Sat, 10 Jun 2023 09:08:02 +0000 Original-Received: (at 63988) by debbugs.gnu.org; 10 Jun 2023 09:07:29 +0000 Original-Received: from localhost ([127.0.0.1]:33281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7uZE-0002k7-OF for submit@debbugs.gnu.org; Sat, 10 Jun 2023 05:07:29 -0400 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:55976 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7uZC-0002jz-Va for 63988@debbugs.gnu.org; Sat, 10 Jun 2023 05:07:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1686388046; bh=ncFfUboNlsUWYQ5LjTiuq4NoUHtquEo9TnicQdWPqVQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RkRUTqoL5PaXshqCAwzrF7plR/yOW0+6jo7rAcC6U9vzAMVhvrQ0dcKUjiOFbuDwo l5VN6Pc2tKQrqsK5sfoZABXAC3LNBZ2fd7rZOMXxzPWshpkuBnBRKjRbaDysPbB5C0 U4Q6iE/mK7hFXroGhOKvw3gkSS0RHW0UFwVyzANZ4rU6WH6LdcBEQogFhYy6Rojliv eZJbJSS5uRR3dJh1wSELYLOIYFaoTpn7eomezo2+xTl7XMjz5yX9N2mu67gyhx1TfJ GmJtbnTjWuCUxehp9xRzs7icbg1cCeehwzkOWmUdSH3J3YGlczCRUhFEEN7Jnp5wp0 0zDowqqCcQiHw== In-Reply-To: <83wn0bzoeb.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Jun 2023 11:56:28 +0300") 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:263204 Archived-At: Eli Zaretskii writes: >> Cc: 63988@debbugs.gnu.org >> Date: Sat, 10 Jun 2023 09:47:29 +0300 >> From: Eli Zaretskii >> >> > From: Aaron Jensen >> > Date: Fri, 09 Jun 2023 21:09:45 -0400 >> > >> > >> > (setq header-line-format '(:eval (format-mode-line ""))) >> > >> > This causes Emacs to spin as of commit: >> > 4f66cbbfe520ee31ef26676e09a926217d9736fe >> > >> > After some time, it will segfault. >> >> It causes infinite recursion, since format-mode-line also calls >> window_wants_header_line (indirectly). >> >> But what is the purpose of such a strange (to use a civilized word) >> setting of header-line-format? Why do you need :eval at all in this >> case? >> >> IOW, why not say "don't do that" and be done? > > For now, I installed a semi-kludgey fix. > > However, I wonder whether we should rethink this minor feature. > Perhaps this minor convenience is not worth the complications? > window_wants_header_line is called in many places, all of which can > now evaluate arbitrary Lisp, and all of which can now GC. I've > audited the various callers, and didn't see anything obvious that > could cause problems with calling Lisp or GC in those places, but I > could have missed something. > > This is actually a general issue with Emacs: we keep piling one minor > feature upon another, and don't always reflect on the hard-to-maintain > monster that creates. We have already a couple of areas in the code > base where we are afraid of making changes, because we don't have a > good understanding of the complicated state variables there. Maybe we > should reject such minor features instead of keeping doing what we > have been doing? > > So maybe we should declare this feature a failed experiment and remove > it? FWIW I think that make sense, but IMO it'd be best to only remove the treatment of `:eval` in `window_wants_header_line`, and keep the new treatment of `header-line-format` being a cons cell with a void or nil-valued variable car. That's still useful because it works well with minor mode variables, and it's less risky as it doesn't involve evaluating arbitrary lisp, just inspecting a variable.