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 11:58:32 -0400 Message-ID: References: <83edxghqg2.fsf@gnu.org> <325f95fd2bcc0b666b0b@heytings.org> <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> 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="20995"; 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 18:21:12 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 1oOLn6-0005BC-GA for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 18:21:12 +0200 Original-Received: from localhost ([::1]:41126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOLn5-0005wu-Hm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 12:21:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOLRe-0006Ol-Li for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 11:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34962) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOLRe-0002Uu-As for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 11:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oOLRe-0006UT-4d for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 11:59:02 -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 15:59:02 +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.166075193324932 (code B ref 56682); Wed, 17 Aug 2022 15:59:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 17 Aug 2022 15:58:53 +0000 Original-Received: from localhost ([127.0.0.1]:52944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOLRU-0006U4-Q7 for submit@debbugs.gnu.org; Wed, 17 Aug 2022 11:58:53 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOLRP-0006Tm-Jo for 56682@debbugs.gnu.org; Wed, 17 Aug 2022 11:58:51 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 2C4D0442515; Wed, 17 Aug 2022 11:58:42 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B6A8644250E; Wed, 17 Aug 2022 11:58:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1660751920; bh=lzakCRxKKLs8BBvAHP967C1utZEBy3tscJ9qn40r+OY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fv5+uYjHkoqQPvu8eS6WeVqXz+WPhGOqYEjep4ngRl+npl0JEz+nvGrdAop/TOBYb 4vUSpWP+rwM0va7ipNr0hArEF+s0K6ZYuT9b69tgw10qI8gDMXUheCe4POfxAOFYud 73K8rAtTDnYU4EwbtzkECEnuRmOvl/MWGbWya2X599pkt+xnuYv1yJvGk+28775z32 0qAJ2HsnxwqjHjzKr6jrQgPM3QiDZbuAanSJO2inNpONNXr6BMAcvCNilrRIQiVGcK Vk10n0dnt2Zfg9GB/NPd5nHr9NXLUS9rkIhfsCaw8Xk66L/RDHzxDWPJ8kHF38RG4c QbCv1K/NqRSKg== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 82FAE1203F4; Wed, 17 Aug 2022 11:58:40 -0400 (EDT) In-Reply-To: <83lernc5gu.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 17 Aug 2022 17:25:21 +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:240096 Archived-At: >> >> Last time I looked at it, I couldn't quite understand how the cache >> >> works there, so I wasn't sure how to make sure it returns valid >> >> information even if called outside of redisplay. >> > Looking at what maybe_produce_line_number does doesn't help? >> >> I see two problems: >> >> - 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`. >> - The fact that this uses line numbers counted from BEGV whereas nlinum >> counts from BEG. > > I think you missed the display-line-numbers-widen variable and its > effect. Ah, indeed, thanks, that helps. [ 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`. ] Stefan