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 13:58:21 -0400 Message-ID: References: <83edxgfi75.fsf@gnu.org> <5e3c3081-f098-8140-c767-b895c32bf30b@yandex.ru> <835yisffil.fsf@gnu.org> <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> 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="32524"; 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 19:59: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 1oONK2-0008Lq-Er for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 19:59:18 +0200 Original-Received: from localhost ([::1]:60272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oONK1-0002Jz-5y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 13:59:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oONJm-0002Jb-CL for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 13:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35038) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oONJm-0000up-33 for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 13:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oONJl-0000zD-Tx for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 13:59: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 17:59: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.16607591193762 (code B ref 56682); Wed, 17 Aug 2022 17:59:01 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 17 Aug 2022 17:58:39 +0000 Original-Received: from localhost ([127.0.0.1]:53020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oONJO-0000yc-WE for submit@debbugs.gnu.org; Wed, 17 Aug 2022 13:58:39 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oONJJ-0000yL-P4 for 56682@debbugs.gnu.org; Wed, 17 Aug 2022 13:58:37 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 50417804AB; Wed, 17 Aug 2022 13:58:28 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A3296804F6; Wed, 17 Aug 2022 13:58:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660759102; bh=wqZED/E7MWlp9y+vkmA3BbTrLR5vLm37f8SUekUKEYg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OkQpcdNLbdDluhzde8o10JJPH17XvHUwCo4O47XeztRBBlpxK//997xJUsgj4bO+z KmxoNlsJNocWDejNuJpmgXmN5VxRsv2f4EiO1ULzGLdMMh00BjPuiDcYA1LWka/1Fe yUZzLFt+pl3RG4G0isURPdeMs/yrg+sjst7yzz5jkaJxAeWWYyXPF5V0DP+wHw+7vP COIe8I5kE6sYwt8nGpoEtvJBYOa6jEsGGyaA1GhP7VlWCtUcDjuGFWiROoEg7C5gNF Etb7BiSot+JNWdDOWDLoHwgCI3zmxt1U2tD60Ofh2REWAbFmrD1GqziNA3CmeYWyiD GfNV3p/lgKAbw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5FE0E120281; Wed, 17 Aug 2022 13:58:22 -0400 (EDT) In-Reply-To: <83k076dd7d.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 17 Aug 2022 19:52:54 +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:240101 Archived-At: >> >> - The problem I already mentioned: the cache seems to be >> >> maintained/flushed by the redisplay code, so when the function is >> >> called outside of redisplay I don't know if `w->base_line_number/pos` >> >> is still valid. >> > >> > So you are saying that any command which uses vertical-motion or more >> > generally any of the move_it_* functions will work incorrectly when >> > line numbers are on display? I'm not aware of any such problems. >> >> No, I'm sure the existing code somehow handles it right. I just don't >> know how. I can't see anything in the code of `insert` (say) which >> flushes `w->base_line_number` when needed, so there needs to be code >> somewhere which flushes it more lazily before using that value. I just >> don't know where that code is and which data it uses to flush it. >> For this reason I don't know under which condition I can make use of >> `w->base_line_number`. > > Why can't you simply use the same code maybe_produce_line_number uses > for that? Because I can't find that code. Apparently `maybe_produce_line_number` just uses `w->base_line_number` whenever it's not 0, so apparently it's set to 0 elsewhere. [ BTW, apparently when `display_line_numbers_widen` is in use and the buffer is narrowed, we don't use that cache at all for `maybe_produce_line_number` (according to xdisp.c:24217). IOW that cache always counts from BEGV, so we also need to check that BEGV is still the same as when the cache was filled. I also can't see in `decode_mode_spec` where we check that the narrowing has changed before using the cached value. All in all, I just don't understand how that cache is maintained. ] >> [ BTW, another hurdle if that the existing cache is linked to windows, >> whereas the actual info requested doesn't care about windows (as long >> as we count logical lines rather than screen lines) and would also >> make sense in a buffer that's not displayed at all. This should >> usually not be a problem for nlinum-mode, tho it could happen >> when called from `font-lock-ensure`. ] > Why does it matter which line numbers you compute if they are never > displayed? They may be displayed at some other time: nlinum-mode won't be invoked if that same portion of the buffer becomes visible later on (it's just like font-lock: the highlighting applied stays until something like the after-change-function causes it to be refreshed). Stefan