From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: jinx Date: Sat, 01 Apr 2023 09:01:27 +0300 Message-ID: <834jq016q0.fsf@gnu.org> References: <874jq4c4lt.fsf@posteo.net> <87tty1pf0y.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5627"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 01 08:02:02 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1piUJN-0001BY-Qx for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Apr 2023 08:02:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piUIn-0007Qe-MA; Sat, 01 Apr 2023 02:01:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piUIl-0007QR-Rw for emacs-devel@gnu.org; Sat, 01 Apr 2023 02:01:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piUIl-0007Ll-Gx; Sat, 01 Apr 2023 02:01:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1TZLx/7gyxM4GP48rVPajNgRoIVkvq4EpNzHvMfr8tg=; b=r3AyicouFMbz F4mc2kOJHjledr+yHK1s+P0BPaC6bFzccIQfhS8Lr29+fDs5+UW6uu2C3LIrJwNYiuSfPcEM6MMv7 JI5PUlPHf5FaQtT8VA5lqM5Z0D4OQu69XvCwZWL6XU5GsxjOiFvLolxh+aeF95og5Rbwfydenr9OR 0LCMIJrzttIAM3xOEhHPYBN+ZZj5vT6mZ80Cj0tgKltX1DVZ8j3nmevmVtAXukACirPQWsQj0cxPF XjJO8gCoxcGOpg6xLozrTOgjcW72nOmgf/79u3aKKWn2l1dsNUr8mwgpH5uUcc2cfGimwcTF4pqZz ZAZZ30BNBdnrrEz2f59veQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piUIZ-0008NX-FD; Sat, 01 Apr 2023 02:01:11 -0400 In-Reply-To: (message from Richard Stallman on Fri, 31 Mar 2023 23:11:57 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304962 Archived-At: > From: Richard Stallman > 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.