The technical questions where answered by Philip. I tried the package today and can comment from a user perspective:

> I saw the announcement about the jinx spelling package.  It sounds
> very powerful.  Could it replace ispell.el?  If so, do people think
> that would be a good idea?  If not, why not?
>
> Same questions for flyspell.el.

These packages are used in different ways and may complement each other.

jinx spell-checks the visible text and underlines errors. It's very fast at finding errors due to focusing on the visible text and using the libenchant API instead of subprocess calls. But it currently lacks the ability to check the entire buffer and e.g. jump to the next error or list all errors.

In its README, the jinx author writes that flyspell only checks the work under point. However, it doesn't mention that one can run flyspell-buffer (or flycheck-region) to check the entire buffer for errors, so that's not a huge issue. But jinx just feels more snappy in that regard, incorrect are just highlighted immediately without having to do anything except having the mode enabled.

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.

What I personally enjoy most about jinx are the ergonomics of being able to exclude certain syntactic categories from spell-checking. One convenient way are  `jinx-include-faces' and `jinx-exclude-faces', which are alists of major modes to faces to include/ignore. Also there's `jinx-exclude-regexps' which is an alist from major modes to regexes. For example made it easy for me to get rid of false-positives on macros in LaTeX [fn 1]. Some spell-checking programs (aspell, hunspell) have LaTeX-detection built-in, but it doesn't always work reliably and is not as easily configurable. And that functionality doesn't extend to other markup languages. This is also useful for e.g. org-mode or checking comments and docstrings in programming languages.


Ergonomic-wise I also enjoyed that `jinx-languages', which configures the language, can be a list of language (locale) strings (or just a single string).. I'll use that for my private notes, which tend to be a mix of German and English. `ispell-dictionary' in comparison can only be a single string. (Though through online search I found that when used with hunspell one can provide a comma-seperated list of locales to ispell-dictionary and hunspell will recognise that).

I feel like from a user-perspective, jinx, possibly extended, could replace most use-cases of flyspell. Alternatively, one could also try to add a feature to make flyspell always check the visible text in the buffer, which would need to happen asynchronously I don't know whether technically that would be possible  One could also consider trying to port some of its other ideas back to the existing spell-checking packages in emacs, like using mode-alists for the faces-configuration.

[fn 1]: While writing the mail I looked into the flyspell documentation and that is has similar features via `flyspell-prog-text-faces' and `flyspell-tex-command-regexp', but those are less flexible. `flyspell-prog-text-faces' doesn't work for modes that do not inherit from prog-mode and I can't configure it on a mode-specific granularity, except by using major-mode-hooks and dir- or file-local variables.

--
Michael Eliachevitch
Public PGP Key: https://keyoxide.org/hkp/546908c782383ad0e7d894ec1b8f95c8125dce31