From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#56393: Actually fix the long lines display bug Date: Thu, 07 Jul 2022 13:29:10 +0200 Message-ID: References: <38c1a31040d2d2bc47ae@heytings.org> <38c1a310405bd4bbe370@heytings.org> <87a69n98yy.fsf@yahoo.com> <38c1a31040f5546dbd3a@heytings.org> <87czej6buq.fsf@gnus.org> <38c1a31040e66d2b273e@heytings.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24798"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: Lars Ingebrigtsen , 56393@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 07 13:30:13 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 1o9Pi1-0006DQ-Jt for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jul 2022 13:30:13 +0200 Original-Received: from localhost ([::1]:35562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o9Pi0-0001be-4x for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jul 2022 07:30:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o9Phq-0001bC-In for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 07:30:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33811) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o9Phq-0001In-7w for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 07:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o9Phq-00045n-4N for bug-gnu-emacs@gnu.org; Thu, 07 Jul 2022 07:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Jul 2022 11:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165719336015657 (code B ref 56393); Thu, 07 Jul 2022 11:30:02 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 7 Jul 2022 11:29:20 +0000 Original-Received: from localhost ([127.0.0.1]:55939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9PhA-00044S-4L for submit@debbugs.gnu.org; Thu, 07 Jul 2022 07:29:20 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:37573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o9Ph8-00044F-LV for 56393@debbugs.gnu.org; Thu, 07 Jul 2022 07:29:19 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id y4so9371663edc.4 for <56393@debbugs.gnu.org>; Thu, 07 Jul 2022 04:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version; bh=sq3M2NYVuoh/klfhJBzFQmYt/u8B6+6d9oMo055/LZo=; b=ftuLBvX9LX+8ae75j7HuMbWBqd0BcFbbCH3Wi3IFaF/pTfSHtXdLYAFHkvAcO7EZkt PRjiKfi79u1HHOxROZKQmEIDc3uQ3/eQYaqKnwaEUpvBLbvecN2tt8ngi+Jx68Dz6SwX +hkdPesXLapetay+Nof8ZMaTyLVgCYRP0wetsbg028LTJQkjtsjcyO41t7ydo/WGdrWN RfKM5Crk7MRJC0szP+eWRYgrCUvFJ54fR09RP7H0C/hA+QNp8cDZWgMeCOVoRvrPMYv1 KYsdhNZzb9chU9LE1B1zyJIe1oCNXQjjqSIln+CG/Y8zQ7uGqaipmMKs9ReIMLKOV1nJ LI4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version; bh=sq3M2NYVuoh/klfhJBzFQmYt/u8B6+6d9oMo055/LZo=; b=k7L57gmg/tCuTUfo9BI5wpVejF0YS1mgzM382lXAR8BFlNaRUpZJmMoS3QI+uUsR9U TImJijkn6bp6EF/4VYSmCD+ovktK2rH70JeIIAUrl8Wm+NQy6bJbeXeVfQKTYuphIrd2 znJxbcWJ8rmRpRglFfFRZcGFj9CqIUvQhYwkno3ztBSGRzFOAjQR0WnNhlPyLIPJgjw+ YLnP8AadtrDEUGbTxQgCiq+ijRSKv2xxNVv9argMJrcfZJYEVz0m/3Mu/MFUEk7AfYEz +LC4D5zVTfwDizwpyONw4Obizk9ESWr+wv/KlcWIkmhh16oU9gJpOcazc65EShZx2ElM 8s6g== X-Gm-Message-State: AJIora9a0WQEcwCQPAfwFv4BaRhoPJXA7jkVAuuedCoFm0ZxZ1RjaFZv 0XY8MpafQultdRdK/jci6tphMMhcAdxwlw== X-Google-Smtp-Source: AGRyM1sYW7m13MsOFczJUt707PoLDtzNaNXhfECt9dMrRNvOnH9VWDl6U2KLYPyT8SZ7+TxmTdhxUg== X-Received: by 2002:a05:6402:1691:b0:43a:db2:a213 with SMTP id a17-20020a056402169100b0043a0db2a213mr30885816edv.100.1657193352191; Thu, 07 Jul 2022 04:29:12 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e3694f.dip0.t-ipconnect.de. [217.227.105.79]) by smtp.gmail.com with ESMTPSA id x21-20020aa7dad5000000b0043a2338ca10sm10460921eds.92.2022.07.07.04.29.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Jul 2022 04:29:11 -0700 (PDT) In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Tue, 05 Jul 2022 14:59:37 +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:236358 Archived-At: Looking at the changes in 0463368a7b..7b19ce51fc, I don't have much to bicker, i.e. except about Magit, lldb, gcc-11, dap-mode, ... :-). >From my POV it's ready to go to master. The sooner more people get to use this the better. Thanks again, Gregory! P.S. I currently can't compile Emacs because of reasons, so I can't try it myself: What happens when evaluating an expression in *scratch* that returns a really large result? Or maybe in a Shell buffer some large output? Does Auto Narrow kick in? I'm not sure it does. Should it? modified src/buffer.c @@ -6363,6 +6366,10 @@ from (abs POSITION). If POSITION is positive, point was at the front If value is a floating point number, it specifies the spacing relative to the default frame line height. A value of nil means add no extra space. */); + DEFVAR_PER_BUFFER ("auto-narrow--narrowing-state", + &BVAR (current_buffer, auto_narrow__narrowing_state), Qnil, + doc: /* Internal variable used by `auto-narrow-mode'. */); + Don't know about the "--" in the name. AFAICS, no other per-buffer variable has that. Likewise the "__" in the name. Not that it is important. I just noticed it. And, maybe it's some convention that I don't know. @@ -832,6 +835,11 @@ bset_width_table (struct buffer *b, Lisp_Object val) { b->width_table_ = val; } +INLINE void +bset_auto_narrow__narrowing_state (struct buffer *b, Lisp_Object val) +{ + b->auto_narrow__narrowing_state_ = val; +} If someone feels like it, could you tell me what the '[bw]set_.*' business is for? A serializer? Or for setting breakpoints? @@ -6557,6 +6557,11 @@ DEFUN ("recenter", Frecenter, Srecenter, 0, 2, "P\np", if (buf != current_buffer) error ("`recenter'ing a window that does not display current-buffer."); + /* Refuse to recenter auto-narrowed buffers that are not actually narrowed, + as this can be very slow. */ + if (BUFFER_AUTO_NARROWED_NON_NARROWED_P (buf)) + return Qnil; + Hm, I don't know. Is it always the right thing that recenter does nothing in this case? I'm not saying it isn't. modified src/xdisp.c @@ -18872,11 +18872,20 @@ set_vertical_scroll_bar (struct window *w) && NILP (echo_area_buffer[0]))) { struct buffer *buf = XBUFFER (w->contents); - whole = BUF_ZV (buf) - BUF_BEGV (buf); - start = marker_position (w->start) - BUF_BEGV (buf); - /* I don't think this is guaranteed to be right. For the - moment, we'll pretend it is. */ - end = BUF_Z (buf) - w->window_end_pos - BUF_BEGV (buf); + if (! BUFFER_AUTO_NARROWED_P (buf)) + { + whole = BUF_ZV (buf) - BUF_BEGV (buf); + start = marker_position (w->start) - BUF_BEGV (buf); + /* I don't think this is guaranteed to be right. For the + moment, we'll pretend it is. */ + end = BUF_Z (buf) - w->window_end_pos - BUF_BEGV (buf); I can almost guarantee that it's not guaranteed that window_end_pos is always right. But I don't have an alternative, ATM. Could you please add a TODO or what's customary today in the comment, so it's easier to find? + } + else + { + whole = BUF_Z (buf) - BUF_BEG (buf); + start = marker_position (w->start) - BUF_BEG (buf); + end = BUF_Z (buf) - w->window_end_pos - BUF_BEG (buf); + } I'd find it easier to read if the if/else were reversed to that the ! isn't needed. @@ -19133,6 +19142,14 @@ redisplay_window (Lisp_Object window, bool just_this_one_p) variables. */ set_buffer_internal_1 (XBUFFER (w->contents)); + if (BUFFER_NEEDS_AUTO_NARROWING_P (current_buffer)) + { + safe_call (1, Qauto_narrow_mode); + /* Normally set by auto-narrow-mode, set it here anyway as a safety measure. */ + bset_auto_narrow__narrowing_state (current_buffer, Qauto); + message1 ("Auto-Narrow mode enabled in current buffer"); + } Could you please tell in what circumstances the call would not set the variable? And wouldn't the minot mode print something, also? In other words, can we remove it more or less safely? (If the user screws up, all bets are off anyway.) @@ -27667,7 +27684,12 @@ decode_mode_spec (struct window *w, register int c, int field_width, case 'n': if (BUF_BEGV (b) > BUF_BEG (b) || BUF_ZV (b) < BUF_Z (b)) - return " Narrow"; + { + if (! BUFFER_AUTO_NARROWED_P (b)) + return " Narrow"; + else + return " Auto-Narrow"; + } break; This if/else I'd also reverse because of the !. @@ -27675,17 +27697,27 @@ decode_mode_spec (struct window *w, register int c, int field_width, { ptrdiff_t toppos = marker_position (w->start); ptrdiff_t botpos = BUF_Z (b) - w->window_end_pos; - ptrdiff_t begv = BUF_BEGV (b); - ptrdiff_t zv = BUF_ZV (b); + ptrdiff_t beg, z; - if (zv <= botpos) - return toppos <= begv ? "All" : "Bottom"; - else if (toppos <= begv) + if (! BUFFER_AUTO_NARROWED_P (b)) + { + beg = BUF_BEGV (b); + z = BUF_ZV (b); + } + else + { + beg = BUF_BEG (b); + z = BUF_Z (b); + } Reverse if/else?