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: Sat, 30 Jul 2022 08:35:58 +0300 Message-ID: <835yjf6u2p.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56815@debbugs.gnu.org, juri@linkov.net To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 30 07:36: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 1oHf92-0007w7-0Y for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 07:36:12 +0200 Original-Received: from localhost ([::1]:60902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHf90-0006Pk-CW for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Jul 2022 01:36:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHf8t-0006PN-2a for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 01:36:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44017) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHf8s-0005x6-Q6 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 01:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oHf8s-0000w1-G8 for bug-gnu-emacs@gnu.org; Sat, 30 Jul 2022 01:36: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: Sat, 30 Jul 2022 05:36: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.16591593563581 (code B ref 56815); Sat, 30 Jul 2022 05:36:02 +0000 Original-Received: (at 56815) by debbugs.gnu.org; 30 Jul 2022 05:35:56 +0000 Original-Received: from localhost ([127.0.0.1]:33766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHf8l-0000vg-Ku for submit@debbugs.gnu.org; Sat, 30 Jul 2022 01:35:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oHf8i-0000vT-15 for 56815@debbugs.gnu.org; Sat, 30 Jul 2022 01:35:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58170) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHf8b-0005wV-IJ; Sat, 30 Jul 2022 01:35:45 -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=+La4uXt5AtJYZCKSa1v0+QyGEgC4fhbND+nNpqXl/qo=; b=FOatl5enBZKc yko5RqWH1P2GY0Q8cNHqAWl46+lskt3oOAf4zCzU0RjzWcgN0uPJdgXMLhJ1PK07aR7aVpIflF8Ni VApvlczws8TxrNJryoTiBWmMvXqxspGqW9xTGfQbzWdiiK+2/HRSDCf/hSthqXtUOW3w/YlL6GcYG Ivm95ZHm5nEgoof9l/6sIvW1rIjPgj2sZFhKEpRpof6ndQ9XiBDFVvS+H2VfnQrAInMsenrKAz5Lr h5Bb2cqKNWXzGADGjmZuaLBsC0fnk+9ATJd57JJR31yuj30wJrf9hirAPCl1zT7p9AzGGunf42QRU c9yWMBWwSnWpcGrAj510cQ==; Original-Received: from [87.69.77.57] (port=3884 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 1oHf8b-0000kI-0B; Sat, 30 Jul 2022 01:35:45 -0400 In-Reply-To: (message from Gregory Heytings on Fri, 29 Jul 2022 20:26:00 +0000) 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:238232 Archived-At: > Date: Fri, 29 Jul 2022 20:26:00 +0000 > From: Gregory Heytings > cc: larsi@gnus.org, 56815@debbugs.gnu.org, juri@linkov.net > > > 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. I'm not convinced that this is the root cause, nor that there is indeed a single cause. So far we have found only one feature where this is true, and even that is only because Isearch uses that particular method of deciding when to produce the highlight overlays. It is true that the narrowing optimizations work less well under truncate-lines, for these reasons, but there are other places where we can make improvements and other methods of doing that. There's no reason to believe that the general issue of long lines can be solved by a small number of changes that narrow the buffer. Whatever is left after that we should try solving by other methods. > > We will not remove truncate-lines from Emacs, and we will not make it > > dysfunctional. > > > > Nobody is asking or suggesting to remove truncate-lines from Emacs, or to > make is dysfunctional. Admitting that it doesn't work together with long > lines, which has always been the case, is something entirely different. I admit that it's a tougher nut that currently is not yet cracked, yes. But if improvements can be made in that mode, we should at least try making them, even if those improvements call for some complications in our code.