emacs-devel
[Top][All Lists]
Advanced

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

Re: jinx


From: Eli Zaretskii
Subject: Re: jinx
Date: Fri, 31 Mar 2023 09:51:45 +0300

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 31 Mar 2023 00:29:23 -0400
> 
>   > But as far as I know it doesn't have yet the ability to check and
>   > list the spelling mistakes in the entire buffer. Therefore, I will
>   > probably still be using ispell-buffer to iterate through all
>   > spelling errors.
> 
> It was pointed out that there is a way to do this.  Of course, if we
> install it in Emacs we could adjust the calling conventions however we
> think users will like.  We could make `ispell-buffer' call jinx
> if that's what we want.
> 
> Given that, do you still think you would have a need for the existing
> `ispell-buffer' that uses ispell.el, if jinx were always available?

We cannot assume that "jinx is always available", since it requires
Emacs to be linked against the enchant library.

Anyway, after looking at jinx, I must say that I don't see why we
should replace ispell and flyspell with jinx.  From my POV, ispell and
flyspell provide all the required spell-checking functionalities:

  . spell-check a word
  . spell-check a region
  . spell-check the entire buffer
  . spell-check comments and strings in a prog-mode buffer
  . spell-check as you type

jinx spell-checks the visible portion of the window.  I don't see why
we would need that.  Suppose I scroll the window by 2 lines: why would
I want the new visible portion to be spell-checked again, when the
overlap with the last check is so large?  In any case, if someone
wants a handy command to spell-check only the part that is currently
visible in the window, we can add such a command to ispell.el.  (Btw,
jinx relies on window-end for this, and window-end is a problematic
function which cannot be trusted.)

Another feature of jinx is the ability to skip some buffer text, e.g.,
relying on font-lock faces or user-defined regexps to identify the
parts that should be skipped.  We have similar features:
spell-checking of comments and strings, but if that is not enough, we
could extend these capabilities in ispell and flyspell by simple
enough additions.

All those are minor extensions of the existing spell-checking
capabilities that require no deep changes in the infrastructure and
documentation, which have been stable and useful for many years.

Having jinx as an ELPA package is fine, of course.  Likewise, it's
fine if someone wants to work on redesigning and reimplementing the
low level of ispell.el so that it could optionally use libenchant if
that is available.  But I see no reason to throw out the window the
whole spelling infrastructure we have and replacing it with what jinx
provides.  That would require not just coding and testing, but also
rewriting the manual and will require people to re-learn how they use
spell-checking features in Emacs.  I see no justification for that,
especially since jinx doesn't bring any new spell-checking technology
to Emacs -- libenchant uses those same spell-checking programs, aspell
and hunspell, that we have been using for ages.

As an aside, a technology I would like to see in Emacs is grammar
checking.  Last I looked, there are no free grammar-checking libraries
or services out there, even just for the English language.  But if
that's no longer true, then adding such capabilities to Emacs will be
very welcome, I think, since word-based spell-checking is clearly not
enough these days.



reply via email to

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