From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56815: 29.0.50; Isearch lazy-highlight highlights too much when truncate-lines is in effect Date: Mon, 01 Aug 2022 14:51:56 +0300 Message-ID: <83wnbs2nc3.fsf@gnu.org> References: <83mtct87ti.fsf@gnu.org> <865yjhc85k.fsf@mail.linkov.net> <83fsik8o39.fsf@gnu.org> <87r124kul6.fsf@gnus.org> <86mtcrpyzs.fsf@mail.linkov.net> <83bkt77nf9.fsf@gnu.org> <83a68r7m2d.fsf@gnu.org> <837d3v7kr9.fsf@gnu.org> <86fsih5bch.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30592"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56815@debbugs.gnu.org, gregory@heytings.org, larsi@gnus.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 01 13:53:26 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 1oITzC-0007mH-8K for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 13:53:26 +0200 Original-Received: from localhost ([::1]:43048 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oITzB-00032Z-Af for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 01 Aug 2022 07:53:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oITyo-0002zP-QH for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 07:53:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49756) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oITyo-00019l-Hz for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 07:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oITyo-0000hk-87 for bug-gnu-emacs@gnu.org; Mon, 01 Aug 2022 07:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Aug 2022 11:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56815 X-GNU-PR-Package: emacs Original-Received: via spool by 56815-submit@debbugs.gnu.org id=B56815.16593547412652 (code B ref 56815); Mon, 01 Aug 2022 11:53:02 +0000 Original-Received: (at 56815) by debbugs.gnu.org; 1 Aug 2022 11:52:21 +0000 Original-Received: from localhost ([127.0.0.1]:39505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oITy9-0000gi-FD for submit@debbugs.gnu.org; Mon, 01 Aug 2022 07:52:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oITy7-0000gV-QY for 56815@debbugs.gnu.org; Mon, 01 Aug 2022 07:52:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47306) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oITy2-0000z9-0q; Mon, 01 Aug 2022 07:52:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=QgQAkI9P6JKFcafyqj3B0ERgZncd1g0hmaaW2ininPs=; b=gEyq3GK4lAB7 fWugBNrV3RNsKnYDdAuLakoysgUkjAf4xonRVxtialBFA2nm/iyRFkR0cthPXO6VZka/JvBxigqat yC6FK4KCQKo2rPekYmWoD6dgmELwrPSPenfNFpUGGGXE7e5WMMghOmLYjTWxIty/eohAWgo0AXFwQ phb2ZyLF5XNdtNsSPxHoBw6VaE8sO1YwvkiW6ixNcgpxeojyHA/0TcCJVbJCknIMY9IhZEoAXAnkA MaSTL2sLZsIwD+/2+D0jECEkiPzywDjo58tRa8dr7211eVIg3pfdwy7XmDx1ExlhVAEkEgeQopb7f +ds5Rx/xRIZKZh9rN/dDuA==; Original-Received: from [87.69.77.57] (port=1281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oITxu-0003jp-Rw; Mon, 01 Aug 2022 07:52:13 -0400 In-Reply-To: <86fsih5bch.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 31 Jul 2022 22:40:22 +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:238413 Archived-At: > From: Juri Linkov > Cc: Eli Zaretskii , larsi@gnus.org, 56815@debbugs.gnu.org > Date: Sun, 31 Jul 2022 22:40:22 +0300 > > >> And yes, if we want truncate-lines to work reasonably well, we need to > >> fix any features which behave silly in that display mode. > >> > > > > If we want truncate-lines to work reasonably well without fixing all such > > features one-by-one, we need to fix the root cause of that dysfunction, > > which is not inside these individual features, but is the fact that (- > > (window-end) (window-start)) is huge. > > Do you think introducing the rectangular narrowing could be a more general fix? > We already have rectangular regions generalized as non-contiguous regions. > Could non-contiguous narrowing help to restrict the accessible buffer area > to the visible screen rectangle? I don't understand how such a restriction will work on the level of buffer text. E.g., what happens when you insert a single character before the beginning of one of the narrowed regions? does the region move with the text or does it stay on the same buffer positions? Basically, as long as Emacs represents buffer text as a single long C string (aside of the gap), with no additional structure, I don't see how implement this with any reasonable complexity. And I agree with Gregory that the gains in this case will be too low, relative to the complexity. Let's keep this in its correct proportions: we "just" want isearch to behave reasonably well in long-and-truncated lines, because IMO isearch is one of the few features that we cannot break or disable in such buffers -- the ability to search is too fundamental to editing, even if that editing means just viewing the text. So if no good ideas arise that are simple enough to implement, I'm okay with simply disabling isearch-lazy-highlight in such buffers, as I wrote in the original bug report. (Doing that will probably require exposing the "long-lines" flag to Lisp, but that's fine by me.) Thanks.