emacs-devel
[Top][All Lists]
Advanced

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

Re: jinx


From: Michael Eliachevitch
Subject: Re: jinx
Date: Wed, 29 Mar 2023 22:46:01 +0000


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

Attachment: signature.asc
Description: PGP signature


reply via email to

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