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#56393: Actually fix the long lines display bug Date: Tue, 19 Jul 2022 15:00:24 +0300 Message-ID: <83fsixnwh3.fsf@gnu.org> References: <38c1a31040d2d2bc47ae@heytings.org> <83let43xg9.fsf@gnu.org> <83sfna3gzq.fsf@gnu.org> <83fsja36an.fsf@gnu.org> <34362AA6-6404-4727-9C60-6B6CA6736DD4@gnus.org> <83v8rvpxx7.fsf@gnu.org> <209e6aa436f84e1f729a@heytings.org> <83sfmzpw4e.fsf@gnu.org> <83h73epq7v.fsf@gnu.org> <83cze2pmtk.fsf@gnu.org> <838roqpkjs.fsf@gnu.org> <831quipdt2.fsf@gnu.org> <83r12intar.fsf@gnu.org> <83lespomnu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 19 14:02:00 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 1oDlvM-0007og-2j for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 14:02:00 +0200 Original-Received: from localhost ([::1]:37266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDlvK-0005NV-PG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Jul 2022 08:01:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDlua-0005KU-4I for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 08:01:12 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55273) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDluQ-00007p-FY for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 08:01:11 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oDluQ-0004Bb-BD for bug-gnu-emacs@gnu.org; Tue, 19 Jul 2022 08:01: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: Tue, 19 Jul 2022 12:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56393 X-GNU-PR-Package: emacs Original-Received: via spool by 56393-submit@debbugs.gnu.org id=B56393.165823205116066 (code B ref 56393); Tue, 19 Jul 2022 12:01:02 +0000 Original-Received: (at 56393) by debbugs.gnu.org; 19 Jul 2022 12:00:51 +0000 Original-Received: from localhost ([127.0.0.1]:53032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDluF-0004B4-43 for submit@debbugs.gnu.org; Tue, 19 Jul 2022 08:00:51 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36012) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oDluD-00046L-Od for 56393@debbugs.gnu.org; Tue, 19 Jul 2022 08:00:50 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33806) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDlu7-0008Uz-Ev; Tue, 19 Jul 2022 08:00:43 -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=riU0CIqsxl2OZRd673yMMNKKFg2Nntt/f+rnkc5zYJo=; b=ijIPxnepEFbK KYTwrPyjAuzcJu9JOwvoYb3ZUr9krNw8e317CJy4t+5I34rlApw/UdgRJZdpp7iROqSf1ZcYgf2yC t/6gAehtlPz6o8Bt3JCRUCX8TSGJUmNGgIGDSbCGniv8+q+1KL1DJ1qqBhRjAhJFthGP01WajNeGc 7D4RvVmEupcH77919JQovwtJSE6Xi9A7gXCTrKe5sCO/FLNr1/IwnXtTpeHQxuYoPBwlPrfJr6Kep jAUgPfUPaVL6BOYNJ/9Bh+/I8CgsffctSXv8pl8KpvqwWRa1eVmtoUGPhwwm29L8IoaJjwWE9zgBG 2nCRQuUumdqtL1ajAkZkfw==; Original-Received: from [87.69.77.57] (port=1882 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 1oDlu0-0000qx-Kr; Tue, 19 Jul 2022 08:00:42 -0400 In-Reply-To: (message from Gregory Heytings on Tue, 19 Jul 2022 05:39:24 +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:237426 Archived-At: > Date: Tue, 19 Jul 2022 05:39:24 +0000 > From: Gregory Heytings > cc: gerd.moellmann@gmail.com, larsi@gnus.org, 56393@debbugs.gnu.org > > To be honest, I don't really understand the purpose of BUF_CHARS_MODIFF. > As the comment in buffer.h explains: "It is set to modiff for each such > event, and never otherwise changed." So it doesn't contain new > information. Yes, it does: it allows you to keep track of changes to the buffer text only, ignoring any other changes (like faces, overlays, etc.) which affect the buffer's modified status. The number itself is not interesting, the only thing that is interesting is when the number goes up -- this means the buffer text was changed in some way. > And it's inconvenient that you have to keep a copy of its previous > value around, using MODIFIED != UNCHANGED_MODIFIED as I did earlier > is much easier. We could indeed keep using MODIFIED != UNCHANGED_MODIFIED (and I'm not really sure why you decided it was not good enough: can you describe the problems using it?). Alternatively, we could add a new member of 'struct buffer_text' called, say, unchanged_chars_modiff, and use it instead of MODIFIED != UNCHANGED_MODIFIED in the same way as we use MODIFIED != UNCHANGED_MODIFIED. My point is that if you want the member you added, unchanged_size, to be as responsive to text changes as BUF_CHARS_MODIFF, you will need to add code to increment it in all the places where we already do that with BUF_CHARS_MODIFF, and that sounds like redundancy, since we don't really care about how many characters were added/deleted/replaced.