From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Al Petrofsky Newsgroups: gmane.emacs.bugs Subject: bug#64075: 28.2; ispell broken on uncolored terminals Date: Thu, 15 Jun 2023 19:19:23 -0400 Message-ID: References: <42ff58c7e8e4095a1f34@heytings.org> <835y7puw0z.fsf@gnu.org> <83r0qdtbbr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002e187605fe334db8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13369"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64075@debbugs.gnu.org, gregory@heytings.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 16 01:20:20 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 1q9wGJ-0003IR-BJ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Jun 2023 01:20:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q9wG6-0006Ty-U0; Thu, 15 Jun 2023 19:20:06 -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 1q9wG3-0006To-7X for bug-gnu-emacs@gnu.org; Thu, 15 Jun 2023 19:20: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 1q9wG2-00041F-T6 for bug-gnu-emacs@gnu.org; Thu, 15 Jun 2023 19:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q9wG2-0005bW-F3 for bug-gnu-emacs@gnu.org; Thu, 15 Jun 2023 19:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Al Petrofsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Jun 2023 23:20: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.168687118421505 (code B ref 64075); Thu, 15 Jun 2023 23:20:02 +0000 Original-Received: (at 64075) by debbugs.gnu.org; 15 Jun 2023 23:19:44 +0000 Original-Received: from localhost ([127.0.0.1]:48198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9wFj-0005an-DO for submit@debbugs.gnu.org; Thu, 15 Jun 2023 19:19:43 -0400 Original-Received: from mail-pf1-f177.google.com ([209.85.210.177]:40197) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9wFh-0005aX-0n for 64075@debbugs.gnu.org; Thu, 15 Jun 2023 19:19:41 -0400 Original-Received: by mail-pf1-f177.google.com with SMTP id d2e1a72fcca58-657c4bcad0bso63976b3a.1 for <64075@debbugs.gnu.org>; Thu, 15 Jun 2023 16:19:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686871175; x=1689463175; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EL6nC5qrLRpTJmJtLKdGJWDxr3GOJGdM1jLbH/XJT6s=; b=E95A9RicSR1ukDWu7bU/uOdTvYiB9icMCIdJ9ceqJEaMh+0MFiJSTES69yiMr8S09G Pen3zj/tot4wDItxkzZIcVrOCSctRSYfrIbRtPWRrlZ9XvfL7aDhrw+3pVslIccNTOw0 ruVH0lJTDvw0t2c3QZNSntr84vGqKkkYOMXX8DOBi6KaeDwI5yfmr8b2Imc0D/r0YexD Ck/2IBWMKpq8SH1Hq+yS+HowuwuORkGp8vGJHvqSfD4dmgJXAXN6MochFl+29vCyKviq 1QzuWvwJm7EbaWezT9/3qTDflP1CBm9MlzrCtp/561lXXXZwgBNea9+QredpX/2g7sBp RwAQ== X-Gm-Message-State: AC+VfDx+geKlp1GWwBNLhBJg0iKUu+4Qbjbym+WQ8XZqTN4RBsy/lhXY oe/iYIdqRC2hNeEHkEmAEE1Cnjv7IWKYzCzE725fIQ4ghAk= X-Google-Smtp-Source: ACHHUZ6hVeLCJeuczb8KCSCZcHkPxBf31vi0qJVUrXS9uOtxiR48Jv6ATLZ687Tnfzr2IYhaAjjYrUjO04LR+BoIjHs= X-Received: by 2002:a17:90b:3a8a:b0:25b:e2e1:e252 with SMTP id om10-20020a17090b3a8a00b0025be2e1e252mr527125pjb.3.1686871175205; Thu, 15 Jun 2023 16:19:35 -0700 (PDT) In-Reply-To: <83r0qdtbbr.fsf@gnu.org> 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:263442 Archived-At: --0000000000002e187605fe334db8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Resending because I mistakenly used reply rather than reply-all. Sorry] This ispell code is still broken in emacs-29.0.91. New recipe: emacs-29.0.91 -Q -nw --color=3Dno 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. The same results are obtained in an xterm version 372 or in a M-x term inside emacs-29.0.91. As was the case for the original recipe, changing "(display-color-p)" to "t" in ispell-highlight-spelling-error fixes the bugs. On Thu, Jun 15, 2023 at 3:48=E2=80=AFAM Eli Zaretskii wrote: > 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). 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. > You've ignored what I wrote about that possibility: when faces are > customized by users, they are usually customized in simplistic ways, > and are thus unlikely to work for all the cases. IOW, once you allow > for face customizations, it is very hard to make sure this face will > still be distinct on a colorless terminal. Fortunately, the face doesn't really need to be distinct, because the location is also indicated by the cursor (which we all found to be a sufficient interface for isearch and ispell in Emacs's first decade or two). So this is a much lesser concern than the bugs at issue. But I think I do see what you mean. Starting with an empty HOME directory, I started emacs on a color terminal, used M-x customize to change the colors of the isearch face and save the changes, then restarted emacs on a monochrome terminal, and now the isearch face is rendered the same as the default face. 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. 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. 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). --0000000000002e187605fe334db8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Resending because I mistakenly used reply rather tha= n reply-all. Sorry]

This i= spell code is still broken in emacs-29.0.91.=C2=A0 New recipe:

=C2= =A0 =C2=A0emacs-29.0.91 -Q -nw --color=3Dno
=C2=A0 =C2=A0C-x b x RET
= =C2=A0 =C2=A0M-x enriched-mode RET
=C2=A0 =C2=A0M-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&q= uot; is bold and
the "tonks" has the default face.=C2=A0 Less = importantly, while the ispell
choices were displayed, "stonks"= should have been in inverse-video,
but it was not.

The same resu= lts are obtained in an xterm version 372 or in a M-x term
inside emacs-2= 9.0.91.

As was the case for the original recipe, changing "(dis= play-color-p)"
to "t" in ispell-highlight-spelling-error = fixes the bugs.
On Thu, Jun 15, 2023 at 3:48=E2=80=AFAM Eli Zaretskii <eliz@gnu.org> wrote:

> = It's a working code whose replacement (basically, a cleanup) will mean<= br>> extra work for us, and all that for quite rare situations.=C2=A0 Ba= sed on
> my long experience with Emacs, it also means some subtle bug= s in some
> even rarer use cases, which will take years to find and f= ix.

As you said in bug #56219, it's code that hasn't = worked in any release
in the last 15 years (now 16 years).=C2=A0 What I&= #39;m saying is it's also
code for a special case that hasn't ex= isted for 22 years (that the
terminal has an "so" capability b= ut the display code can't render
inverse-video faces on it), and tha= t's why it makes more sense to me
to simply eliminate this code and = let monochrome terminals be handled
by ispell-highlight-spelling-error-o= verlay (which is working code),
rather than go in and try to fix the log= ic 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.=

> You've ignored what I wrote about that possibility: when f= aces are
> customized by users, they are usually customized in simpli= stic ways,
> and are thus unlikely to work for all the cases.=C2=A0 I= OW, once you allow
> for face customizations, it is very hard to make= sure this face will
> still be distinct on a colorless terminal.
=
Fortunately, the face doesn't really need to be distinct, be= cause the
location is also indicated by the cursor (which we all found t= o be a
sufficient interface for isearch and ispell in Emacs's first = decade or
two).=C2=A0 So this is a much lesser concern than the bugs at = issue.

But I think I do see what you mean.=C2=A0 Starting with an em= pty HOME
directory, I started emacs on a color terminal, used M-x custom= ize to
change the colors of the isearch face and save the changes, then<= br>restarted emacs on a monochrome terminal, and now the isearch face isrendered the same as the default face.

I can easily use the default= s, 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.

Is this situation so bad tha= t it would be preferable for isearch to be
hard-coded to always use inve= rse video on monochrome displays?=C2=A0 Is
that your position?=C2=A0 I t= hink I prefer it as is, and would prefer that
ispell worked the same way= .

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.=C2=A0 That would result in no change to the=
default appearances, with the benefit that after a simple
customizat= ion of the colors during an emacs session on a color
terminal, emacs ses= sions on monochrome terminals would still use
inverse-video for isearch = (and ispell).

--0000000000002e187605fe334db8--