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#68441: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D:?= bug#68441: Fix the unaligned tab in whitespace mode Date: Sun, 28 Jan 2024 13:09:50 +0200 Message-ID: <86bk9567ep.fsf@gnu.org> References: <837ckcfchd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68441@debbugs.gnu.org To: Young Arto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 28 12:11:17 2024 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 1rU34H-0006wr-7c for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 28 Jan 2024 12:11:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rU33w-00045D-JE; Sun, 28 Jan 2024 06:10:56 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rU33u-00044q-DP for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 06:10:54 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rU33u-0001N9-4R for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 06:10:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rU341-0006Oj-M1 for bug-gnu-emacs@gnu.org; Sun, 28 Jan 2024 06:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jan 2024 11:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68441 X-GNU-PR-Package: emacs Original-Received: via spool by 68441-submit@debbugs.gnu.org id=B68441.170644021024516 (code B ref 68441); Sun, 28 Jan 2024 11:11:01 +0000 Original-Received: (at 68441) by debbugs.gnu.org; 28 Jan 2024 11:10:10 +0000 Original-Received: from localhost ([127.0.0.1]:56753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rU33B-0006NL-VM for submit@debbugs.gnu.org; Sun, 28 Jan 2024 06:10:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rU33A-0006N1-6c for 68441@debbugs.gnu.org; Sun, 28 Jan 2024 06:10:08 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rU32w-00017J-SU; Sun, 28 Jan 2024 06:09:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=i0dGELGgjFQxNxJU1y4WGKIhgQ7uV2cYyLKQ3fuCVjE=; b=NIq+zl8npBc8k230x4AH 3mFAycC/v80Pi8Q3Lt1WHO1VLGegyk0sJ9VZBP7fqTIbJ74jV5XqYMsmTs3zkZp/lq6GsDLjSfhIs 41mraeXvfBYwSLs4SDT2sx3PT4jYxsjx3PTpxuDFP+HxWTg2LeteAH66v2S/f3tHFzzo1RYfufGVk x16Rzk6E+lzCEAStQigMumyDpG6ZcWZZ1s1s5WNsNX12WXblBP7FiMOJsaoKgm5rRcR98tH1HQFEp 0t7+eprm1EUU20Llfa8/3CJIaCEnK8VuoPuKOJlA5AGb9Xuo86/YkAUdT2SdYmh0eX84BBr5XhSbM u6EL6Dhu1fXyMw==; In-Reply-To: (message from Young Arto on Sun, 28 Jan 2024 10:43:16 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:279081 Archived-At: > From: Young Arto > CC: "68441@debbugs.gnu.org" <68441@debbugs.gnu.org> > Date: Sun, 28 Jan 2024 10:43:16 +0000 > > So this patch changes long-standing behavior in non-trivial ways, and > I'm not sure what it can break, after so many years. I understand > that it makes certain customizations in whitespace-mode look better on > display in some cases, but display-tables are used in Emacs not just > in whitespace-mode. > > Yes, You are right. In fact, I'm not sure what it can break either. So I have > used this patch locally for about one year with self-compiled emacs29. > Fortunately, it didn't bring any side effects for me. However, of course, > I cannot cover every function and every package for emacs. > > It is really fundamental code. On the other hand, it is also annoying to > use whitespace-mode with unaligned tabs-mark. Would you be happy > if I add an option for this behavior like 'display-vector-limit-tab' which > defaults to nil? Finally, it won't change default behavior for all emacsers > and anybody like me who has trouble with this issue can turn it on in > their configuration file so they can test if it has side effects for them or > they can share this fix. Adding an option is better, but I'm not sure I understand in what circumstances that option will affect the display of a TAB that comes from a display vector. Your changes seem to have some conditions whose exact rationale and effect are not clear to me. I mean the following conditions: . it->current.dpvec_index > 0 . absolute_x % it->tab_width == 0 What are the reasons for each of these conditions, and what kinds of display-table entries they are supposed to support? Also, did you test the results in situations like line-truncation and display-line-numbers-mode, including the combination of the two? And what about visual-line-mode? And what about line-prefix and wrap-prefix? See, the Emacs display engine supports a gazillion of features, so the effect of these changes in each of these situations should be well understood, otherwise we will be unable to document the expected effect of the option you are suggesting to introduce. Thanks.