bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#64075: 28.2; ispell broken on uncolored terminals


From: Eli Zaretskii
Subject: bug#64075: 28.2; ispell broken on uncolored terminals
Date: Thu, 15 Jun 2023 08:36:28 +0300

> Cc: 64075@debbugs.gnu.org
> From: Al Petrofsky <al@petrofsky.org>
> Date: Wed, 14 Jun 2023 19:48:37 -0400
> 
> Still, this anachronistic kludge should really be nuked entirely.

Why?  And what's "anachronistic" about that code?

> Even with the current fix, it fails to use ispell-highlight-face,
> instead always using inverse-video.

Why is that a problem?  This function exists so that even the dumbest
terminals could be used for spell-checking with reasonable
convenience.

> By "nuked entirely" I mean:
>    (1) delete ispell-highlight-spelling-error
>    (2) delete ispell-highlight-spelling-error-generic
>    (3) rename ispell-highlight-spelling-error-overlay 
>            to ispell-highlight-spelling-error

Sorry, not going to happen.  You are suggesting to delete a useful
capability for no good reason, just because you happen to think it's
"anachronistic".

Unlike what you seem to think, display-color-p is not "a 20th-century
kludge from before face support for ttys was added in emacs-21 in
2001".  Quite to the contrary, display-color-p was introduced with
Emacs 21, to replace references to window-system (which _was_ "the
20-century kludge" for requesting faces) in a way that would support
text-mode terminals.

Now, I'm okay will adding more tests to display-color-p, for
monochrome terminals that can support other face attributes which will
make the misspelled word stand out, but then the ispell-highlight-face
should probably be modified accordingly, keeping in mind that (a) the
user could customize the 'isearch' and/or 'highlight' faces from which
it inherits, and (b) face customization is global, not specific to
frame, let alone Emacs command, and users rarely customize faces in
complex ways that can account for frame capabilities.

And in any case, we should keep that code for terminals which can only
support inverse video.  There's no reason to delete it, none
whatsoever.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]