From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#56682: locked narrowing Date: Wed, 17 Aug 2022 16:04:20 -0400 Message-ID: References: <831qtgff78.fsf@gnu.org> <83zgg4dw4y.fsf@gnu.org> <83r11gdrr4.fsf@gnu.org> <83edxfds7s.fsf@gnu.org> <83r11fc80o.fsf@gnu.org> <83o7wjc6o2.fsf@gnu.org> <83lernc5gu.fsf@gnu.org> <83k076dd7d.fsf@gnu.org> <83edxed8qe.fsf@gnu.org> <83bksid6eb.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29948"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 56682@debbugs.gnu.org, gregory@heytings.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 17 22:07:04 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 1oOPJf-0007bP-Aa for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 22:07:03 +0200 Original-Received: from localhost ([::1]:54468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOPJe-00041x-ER for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 16:07:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOPI2-00025Z-Nv for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 16:05:22 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOPHh-0008D9-VH for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 16:05:22 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oOPHh-00049V-Pd for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 16:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Aug 2022 20:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.166076667715926 (code B ref 56682); Wed, 17 Aug 2022 20:05:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 17 Aug 2022 20:04:37 +0000 Original-Received: from localhost ([127.0.0.1]:53118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOPHI-00048o-UQ for submit@debbugs.gnu.org; Wed, 17 Aug 2022 16:04:37 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOPHD-00048W-4a for 56682@debbugs.gnu.org; Wed, 17 Aug 2022 16:04:34 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 562F78076F; Wed, 17 Aug 2022 16:04:25 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4061A8012F; Wed, 17 Aug 2022 16:04:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660766663; bh=oiWPulMyfgH6CsgEJ4Xw0+wAJUxixWgbOJBl9KEHkgk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=B4x0X923gGMg02nLDx+U4v6hz6tlOpgdbOt5HVYdXzjwv57INTAIm6iZ2T0XAlMQO 4skFPFaOZU3A0IWxJB6QFveceb+UR28hUQqNJ/hEI+SgjjSHztOxkz7RDQ8UwK4/KE 6c69nyRbqWFoVrFyOdMoEN7xOIOM8Y0gFg4okcOZMCvIlhZ9osMQXuRSJFPHvSBfJi P5vCZo4R0SEDwSOrwtHNGOSXRUEkz1N7DkgcfIof3Ec2SC9Y/5fK31TDo+u1tzGoTW /ZNGIMa1k7DcBFeBFW4HBeVcHAwb6VURCzwSEzsMqsISmmMJ5itxWeSwKpsbDLrhkc GxtjuM/LbcWzg== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0567C120195; Wed, 17 Aug 2022 16:04:23 -0400 (EDT) In-Reply-To: <83bksid6eb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 17 Aug 2022 22:19:56 +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" Xref: news.gmane.io gmane.emacs.bugs:240110 Archived-At: >> >> Because I can't find that code. >> > What do you mean? it's in maybe_produce_line_number, obviously... >> My intuition tells me it should be there, but I can't find it. > > Really? I meant this: > > if (!last_line) > { > /* If possible, reuse data cached by line-number-mode. */ > if (it->w->base_line_number > 0 > && it->w->base_line_pos > 0 > && it->w->base_line_pos <= IT_CHARPOS (*it) > /* line-number-mode always displays narrowed line > numbers, so we cannot use its data if the user wants > line numbers that disregard narrowing, or if the > buffer's narrowing has just changed. */ > && !(line_numbers_wide > && (BEG_BYTE != BEGV_BYTE || Z_BYTE != ZV_BYTE)) > && !current_buffer->clip_changed) > { > start_from = CHAR_TO_BYTE (it->w->base_line_pos); > last_line = it->w->base_line_number - 1; > } > else > start_from = beg_byte; > if (!it->lnum_bytepos) > first_time = true; > } > else > start_from = it->lnum_bytepos; > > /* Paranoia: what if someone changes the narrowing since the > last time display_line was called? Shouldn't really happen, > but who knows what some crazy Lisp invoked by :eval could do? */ > if (!(beg_byte <= start_from && start_from <= z_byte)) > { > last_line = 0; > start_from = beg_byte; > } > > this_line = > last_line + display_count_lines_logically (start_from, > IT_BYTEPOS (*it), > IT_CHARPOS (*it), &bytepos); This checks for changes in narrowing (via !current_buffer->clip_changed), but not for changes in the buffer contents (these are apparently checked in `redisplay_window` and `try_scrolling` instead). >> >> Apparently `maybe_produce_line_number` >> >> just uses `w->base_line_number` whenever it's not 0, so apparently it's >> >> set to 0 elsewhere. >> > It's set to zero in several places in xdisp.c. >> I can't seem to find even one of them related to the fact that the >> buffer was modified. > > This: > > if (!just_this_one_p > || current_buffer->clip_changed > || BEG_UNCHANGED < CHARPOS (startp)) > /* Forget any recorded base line for line number display. */ > w->base_line_number = 0; > > And this: > > /* Forget any previously recorded base line for line number display. */ > if (!buffer_unchanged_p) > w->base_line_number = 0; Right, I did find them in the end. Note that these are in code which is not used for `format-mode-line`. >> > But again, if you don't want to trust the cached values, just use >> > display_count_lines starting from BOB. >> >> That's already what nlinum does (via `line-number-at-pos`). > > Then maybe all this discussion is just a waste of breath. It'll help me improve the code's doc, tho. Stefan