From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen 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 07:59:30 -0400 Message-ID: References: <831qij24qm.fsf@gnu.org> <83o7lnzhm5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26566"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63988@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 14:00:17 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 1q7xGT-0006kV-9h for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 14:00:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q7xGG-0004M7-0X; Sat, 10 Jun 2023 08:00:04 -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 1q7xGE-0004Lx-Ol for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 08:00: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 1q7xGE-000756-FY for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 08:00:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q7xGD-0001e5-TB for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 08:00:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Jun 2023 12:00:01 +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.16863983926282 (code B ref 63988); Sat, 10 Jun 2023 12:00:01 +0000 Original-Received: (at 63988) by debbugs.gnu.org; 10 Jun 2023 11:59:52 +0000 Original-Received: from localhost ([127.0.0.1]:33391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7xG4-0001dG-DZ for submit@debbugs.gnu.org; Sat, 10 Jun 2023 07:59:52 -0400 Original-Received: from mail-pg1-f182.google.com ([209.85.215.182]:46355) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7xG0-0001cz-7p for 63988@debbugs.gnu.org; Sat, 10 Jun 2023 07:59:51 -0400 Original-Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-53f8da65701so1189565a12.1 for <63988@debbugs.gnu.org>; Sat, 10 Jun 2023 04:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686398382; x=1688990382; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=w3GcXN7gvJ+modYJSqxNArkGcFGLEv9vl18Py6RZCOU=; b=abXXpfqMHiJBy/KzQPQr450NgaRuiYH8KGIPYUjScVFwYKlyX12Pc5m1e6ECjP0Om7 jsvWyPVMLZki7PRoWa1eq3Fa7pkbmh7A5Owtm/IeTZEKMQwoRVcQhGc00d5o8FpILr+v iAm6EqUvzBgvMFwftaq+BJzXfW0PAJcExSZdVfqqu/RH8MDTYoaFvP8otNJdDeiOQtfc 0ihpQKlPO8A9BdRsNimZyUy2N5spI1PKV9cWdJeS/14BUHwCeHqYM0nEmBZVdx/Xh/v6 HOo1xv3F1ExuObt22D4WwsN2zW+fDYknWUi9lmsM06KGy3MMA5/QXtzN1hvhDL7Gz0AS grUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686398382; x=1688990382; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=w3GcXN7gvJ+modYJSqxNArkGcFGLEv9vl18Py6RZCOU=; b=UrmekOQBVvIEHpE8wohHiAl72gszYJ6RkkweUsh9e7SSW7LVTfJf/BVBeUbZLxBb+H lMMTV6eL/M7dOEnIDr8Lt2smz1J8ZwyXdEr5qaHeTQScMuHky+0Dq5/0MATeS48Zn39/ FeqVyYyeuqstEEiex1+2lzHaR+jIfZoaexARuIze9QmB/o9FzEEpMW5X87JTCqGruaY4 ukmZ7krMB7FRZoUVZ8i2grXvevYP/0nA/Tf6VNVt2bBQ9Zvvcxczew2bHtLpAYReFVrr mtsNh7TiCxNI1AoVEvfdPBidbh+BJYgzSW8x3OYi6zm6yRe7xr9+SdsNX4CyUEDS6qYo 60Qw== X-Gm-Message-State: AC+VfDzBSms/UH3aDNy5nPaj1O6IugDuo0DB7WzAEnQIf+WmkuH3kg0l dJA0xyGZNVELKORiIbMsPay3msFQPmSXFxmls5c= X-Google-Smtp-Source: ACHHUZ7WScZivagupNYqwHBPz7ZlSGNfyWaxLlCVYkQ+HSH0baUBFEN96umpaJa228YnTn41U2kKZwIqq99uJlfKpFU= X-Received: by 2002:a17:90a:617:b0:256:dbfb:9b5e with SMTP id j23-20020a17090a061700b00256dbfb9b5emr3290809pjj.29.1686398382065; Sat, 10 Jun 2023 04:59:42 -0700 (PDT) In-Reply-To: <83o7lnzhm5.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: , 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:263214 Archived-At: On Sat, Jun 10, 2023 at 7:22=E2=80=AFAM Eli Zaretskii wrote: > > > From: Aaron Jensen > > Date: Sat, 10 Jun 2023 07:08:20 -0400 > > Cc: 63988@debbugs.gnu.org > > > > > 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? > > > > It's a minimal repro for an issue I encountered with a package that doe= s this: > > > > https://github.com/rougier/nano-modeline/blob/master/nano-modeline.el#L= 532 > > > > It's how this modeline/header line adds line number/cursor position to > > a more complicated line. As I understand it, it has to format it first > > in order to use its width to properly right align it: > > > > https://github.com/rougier/nano-modeline/blob/master/nano-modeline.el#L= 278 > > > > Is there a better way to do this? > > Use just 'format'? I still don't understand why they use > format-mode-line there. Unless I'm mistaken, the closest equivalent to (format-modeline "%l:%c) is something like: (format "%d:%d" (line-number-at-pos) (current-column)) It seems like that behaves the same in narrowed buffers and not, so I can probably use that instead. > > > So maybe we should declare this feature a failed experiment and remov= e > > > it? > > > > I'll admit I don't really understand the change. Is it actually > > evaluating the cdr of the eval form up to two additional times to in > > order to determine whether or not to display the headerline at all? > > Only two? Well, 2 per render. I'm just guessing at reading the diff. > > Wouldn't this have performance implications? > > Probably, although I wouldn't expect the performance to suffer too > much. Header-line is rarely used. By some it's rarely used. By me and others it's used often as I use it in place of modeline. I prefer the buffer name to be at the top. > But yes, that's one more implication to consider when introducing such > minor convenience features. I'd personally prefer performance to being able to hide the header line optionally, though I still don't really understand the change and why the one time it's eval'd in order to get the actual text/format can't be used to determine whether or not to show the header line. Aaron