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: Fri, 31 Mar 2023 09:51:45 +0300 Message-ID: <83sfdl2z26.fsf@gnu.org> References: <87sfdnyuxc.fsf@posteo.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26281"; mail-complaints-to="usenet@ciao.gmane.io" Cc: m.eliachevitch@posteo.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 31 08:52:45 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 1pi8cu-0006fE-Fo for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Mar 2023 08:52:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pi8cT-0003Yj-R2; Fri, 31 Mar 2023 02:52:17 -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 1pi8cI-0003Y0-1g for emacs-devel@gnu.org; Fri, 31 Mar 2023 02:52:08 -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 1pi8cG-0007O6-Jn; Fri, 31 Mar 2023 02:52:04 -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=i2Dj8NzAQBMb14PbwQnYyxkwdEdV+2eNJdt2RO3DnkE=; b=U16iHAvOos+z czw04Dr5q58qYYZzk7gC+a37zI3Veb/V2mij5Pd3f31GcC0nporAbiZUxslT/JoDzYS5NUSUqKux4 VKcZoUy+E2B6J/yETL/6v+NNcWxlmWtqn7ZVAptTnF8WrI8pTS2J4ZA4ZbhXfj61RucDzQpsPslfJ hxfv1cciFvoc4Bz6h3MrE7QEap/UMK7wIhZ4Fnl7EzSr2XRjUE2AdTjyxpp3ZomuhePm3inG2xExl mXo0olXKKQICZAJ4VW3rCoAm19ZkbJd1Q7s7Uqnnqwu/d2pC7jJTZigg0eJlzHyhOPc4+KmdAdWMf XtVUe/ysgzh9mn9La5xq0Q==; 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 1pi8bk-0004Wc-8r; Fri, 31 Mar 2023 02:51:40 -0400 In-Reply-To: (message from Richard Stallman on Fri, 31 Mar 2023 00:29:23 -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:304886 Archived-At: > From: Richard Stallman > 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.