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#64075: 28.2; ispell broken on uncolored terminals Date: Fri, 16 Jun 2023 09:27:29 +0300 Message-ID: <835y7nudke.fsf@gnu.org> References: <42ff58c7e8e4095a1f34@heytings.org> <835y7puw0z.fsf@gnu.org> <83r0qdtbbr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4054"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64075@debbugs.gnu.org, gregory@heytings.org To: Al Petrofsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 16 08:28:21 2023 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 1qA2wX-0000sD-BG for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Jun 2023 08:28:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qA2wG-00020c-O9; Fri, 16 Jun 2023 02:28:04 -0400 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 1qA2wE-00020R-WE for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 02:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qA2wE-0007lI-Mr for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 02:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qA2wE-0007bx-8t for bug-gnu-emacs@gnu.org; Fri, 16 Jun 2023 02:28: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: Fri, 16 Jun 2023 06:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64075 X-GNU-PR-Package: emacs Original-Received: via spool by 64075-submit@debbugs.gnu.org id=B64075.168689683629199 (code B ref 64075); Fri, 16 Jun 2023 06:28:02 +0000 Original-Received: (at 64075) by debbugs.gnu.org; 16 Jun 2023 06:27:16 +0000 Original-Received: from localhost ([127.0.0.1]:48508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2vT-0007at-ED for submit@debbugs.gnu.org; Fri, 16 Jun 2023 02:27:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2vQ-0007af-Nq for 64075@debbugs.gnu.org; Fri, 16 Jun 2023 02:27:13 -0400 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 1qA2vK-0006hv-Pm; Fri, 16 Jun 2023 02:27:06 -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=l+UHUoex74rj5xwg0aPsm9y/sUt6ImaMQoIdMcWe9kQ=; b=OoIPfGq7OCTd HFnCU3s4pri8L9VCv1Fe11uw71ARg1UGADk4BUQy0tLIZw4IOWGh1ztqJfA2cEZGpbKVa1mfO37zj AauPrgIDBOiCd3od3fRQmHDd2JTySRlUF5/irIbb9CFtpzlxMDz9X31oOOMxwcRmhlnBawzbpkTAw OtufgQQ64Rr15m+NjRaRheHmL6cgB+41WnHTJ4Y7HPQCvO/aHt91c2qCuSWK0C25UiW0T2v6LOUEP QSLaAmRj2JV+aHJED3mVz5e9IXdQrDstcOHWWC/JINSwF9n7OprLIIDb2ECDxyL5phN2rxlD+yuKU rE59u/AM8hbwKYZ4A4031Q==; Original-Received: from [87.69.77.57] (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 1qA2vK-0003nq-6R; Fri, 16 Jun 2023 02:27:06 -0400 In-Reply-To: (message from Al Petrofsky on Thu, 15 Jun 2023 19:19:23 -0400) 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:263456 Archived-At: > From: Al Petrofsky > Date: Thu, 15 Jun 2023 19:19:23 -0400 > Cc: gregory@heytings.org, 64075@debbugs.gnu.org > > emacs-29.0.91 -Q -nw --color=no > C-x b x RET > M-x enriched-mode RET > M-o b stonks M-$ SPC > > At this point, "stonks" should have been unchanged by the M-$ SPC, and > therefore should still be bold, but instead only the "s" is bold and > the "tonks" has the default face. Less importantly, while the ispell > choices were displayed, "stonks" should have been in inverse-video, > but it was not. Your expectations are wrong: no one said pasting arbitrary text in Enriched mode over a word should necessarily retain the face information from the original miss-spelled word. > As was the case for the original recipe, changing "(display-color-p)" > to "t" in ispell-highlight-spelling-error fixes the bugs. Because that uses overlays, so it doesn't interfere with faces. But you haven't tested it with any other feature that uses overlays with face information. So your testing is not balanced: it is designed to emphasize the disadvantages of only one method, and disregards the disadvantages of the other. > > It's a working code whose replacement (basically, a cleanup) will mean > > extra work for us, and all that for quite rare situations. Based on > > my long experience with Emacs, it also means some subtle bugs in some > > even rarer use cases, which will take years to find and fix. > > As you said in bug #56219, it's code that hasn't worked in any release > in the last 15 years (now 16 years). That's not what I said in that bug. > What I'm saying is it's also > code for a special case that hasn't existed for 22 years (that the > terminal has an "so" capability but the display code can't render > inverse-video faces on it), and that's why it makes more sense to me > to simply eliminate this code and let monochrome terminals be handled > by ispell-highlight-spelling-error-overlay (which is working code), > rather than go in and try to fix the logic in a function that is a > self-labeled "kludge" that depends on details of the low-level > redisplay engine, and hope no new subtle bug has been introduced. I've considered your proposal and decided against removing this code. Please don't keep pushing for it, as I won't change my mind just because you are reiterating the same arguments. > I can easily use the defaults, or easily change the face to suit my > preferences on whatever type of terminal I use most, but to get > support for different types of terminals in a custom manner takes more > work. That was exactly my point. So if we want to make ispell.el work better in these cases, we need more complex setting of the faces used in this case, and in particular to depend less on (possibly customized) other faces. > Is this situation so bad that it would be preferable for isearch to be > hard-coded to always use inverse video on monochrome displays? Is > that your position? I think I prefer it as is, and would prefer that > ispell worked the same way. My position is as I already explained it. let me reiterate it: . I'm okay with adding more conditions to use the overlay code, by testing terminal capabilities other that display-color-p . Each such capability should have a distinct face to go with it, and that face should use the corresponding display capabilities without inheriting from other, more general faces It is possible that, if we support enough display capabilities in the above way, the set of terminals that use ispell-highlight-spelling-error-generic will become much smaller, or even empty. But the difference is that we will have a comprehensive and sound solution based on specific terminal capabilities instead of a hack that works only in some situations. > I do wonder if it would make sense to make :inverse-video t in all the > defaults for the isearch face, and swap all the default :background > and :foreground properties. That would result in no change to the > default appearances, with the benefit that after a simple > customization of the colors during an emacs session on a color > terminal, emacs sessions on monochrome terminals would still use > inverse-video for isearch (and ispell). Sorry, we will not change the defaults for a face as general and widely-used as 'isearch', because such a change will cause annoyance from many users. Definitely not due to marginal use cases such as this one. (You can, of course, make such face customizations locally.) This problem should be solved where it happens: in ispell.el, not by changing a much wider used face.