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: Sat, 01 Apr 2023 09:01:27 +0300

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 31 Mar 2023 23:11:57 -0400
> 
>   > >   > ispell already supports enchant, but it communicates via IPC 
> instead of
>   > >   > the library interface.
>   > >
>   > > Would it be possible for jinx to do this?
>   > > Would it be better overall for jinx to do this?
> 
>   > Do what?
> 
> Communicate with enchant via IPC.
> 
> I understood the other person to be saying that communicating that way
> is an advantage for ispell.  If it is an advantage, could jinx be made
> to do it that way?
> 
> Maybe perse did not mean that this was an advantage.

AFAIU, the IPC interface that is bypassed is the one between Emacs and
Enchant, implemented in ispell.el.  The IPC that is NOT bypassed is
the one between Enchant and the speller used as its back-end: Aspell
or Hunspell.

Personally, I don't think this is a significant matter: the IPC
interface used by ispell.el is not slow, because we keep the
spell-checking process running at all times.  What might be slow is
the Flyspell's reliance on post-command-hook to spell-check as you
type: this slows down Emacs in some important scenarios.  But again:
if we want to improve that aspect, we don't need jinx, we should
redesign and reimplement how we pass words to the speller using more
efficient mechanisms, such as JIT font-lock hooks.  I believe there's
already an ELPA package which attempts to do something like that.



reply via email to

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