bug#64075: 28.2; ispell broken on uncolored terminals

[Al Petrofsky <al@petrofsky.org>]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]

[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=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.

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 AM Eli Zaretskii <eliz@gnu.org> 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).

[-- Attachment #2: Type: text/html, Size: 4227 bytes --]