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.bugs Subject: bug#20543: 24.5; in ispell-buffer accepts spelling for the whole line Date: Fri, 28 May 2021 09:25:16 +0300 Message-ID: <83eedr8jeb.fsf@gnu.org> References: <87fuuwvuzy.fsf@mbork.pl> <87h7in3egl.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4491"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juergen_hartmann_@hotmail.com, mbork@mbork.pl, 20543@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 28 08:26:21 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1lmVwr-0000vm-9c for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 May 2021 08:26:21 +0200 Original-Received: from localhost ([::1]:36208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmVwp-00035k-SY for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 May 2021 02:26:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmVwa-00035N-2B for bug-gnu-emacs@gnu.org; Fri, 28 May 2021 02:26:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41935) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmVwY-0000q9-Ck for bug-gnu-emacs@gnu.org; Fri, 28 May 2021 02:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lmVwY-0001N3-8j for bug-gnu-emacs@gnu.org; Fri, 28 May 2021 02:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 May 2021 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20543 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 20543-submit@debbugs.gnu.org id=B20543.16221831305231 (code B ref 20543); Fri, 28 May 2021 06:26:02 +0000 Original-Received: (at 20543) by debbugs.gnu.org; 28 May 2021 06:25:30 +0000 Original-Received: from localhost ([127.0.0.1]:53481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmVw1-0001MI-W4 for submit@debbugs.gnu.org; Fri, 28 May 2021 02:25:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lmVvx-0001M4-DN for 20543@debbugs.gnu.org; Fri, 28 May 2021 02:25:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48808) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmVvn-0000EY-RW; Fri, 28 May 2021 02:25:15 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3206 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 1lmVvk-0004bR-TT; Fri, 28 May 2021 02:25:15 -0400 In-Reply-To: <87h7in3egl.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 28 May 2021 02:10:50 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:207440 Archived-At: > From: Lars Ingebrigtsen > Date: Fri, 28 May 2021 02:10:50 +0200 > Cc: Jürgen Hartmann , > 20543@debbugs.gnu.org > > Marcin Borkowski writes: > > >> line 3651 of emacs-24.5/lisp/textmodes/ispell.el: > >> > >>    ;; Do not recheck accepted word on this line. > > I think there's two meanings of "accepted" in that function -- one is > hitting SPC, and the other is when the word is already in the dictionary. No, the two meanings of "accepted" here are: . the user hits SPC to "leave the word unchanged" . the user hits 'a' to "accept the word for this session" See below. > >> This suggests that there might be a reason for that behavior. If this is > >> true, what is it? > > > > I've just seen this report. I'm also very curious about that reason. > > It seems nonsensical to me -- just because you accept the word once on a > line, it might not be acceptable in the next instance. So I've changed > this in Emacs 28. This is wrong, because now 'a' doesn't work as expected. Recipe: . emacs -Q . type into *scratch*: foobarical something foobarical something else . M-x ispell-buffer . a (to "accept" the first "foobarical") . observe Emacs stopping on the next "foobarical", instead of skipping it, as expected The problem is that replace == nil means two things: either the user pressed SPC or the user pressed 'a' (but NOT 'A'). However, the "don't check the same line" logic should only be applied for 'a', not for SPC. So what we need to fix this is IMO adding a way to distinguish between 'a' and SPC (perhaps by looking at ispell-buffer-session-localwords?). Note that the comments in ispell-process-line wrt the meaning of the value of 'replace' are AFAICT inaccurate: ;; Insert correction if needed. (cond ((equal 0 replace) ; INSERT (if (equal 0 replace) ; BUFFER-LOCAL DICT ADD (ispell-add-per-file-word-list (car poss))) ;; Do not recheck accepted word on this line. (setq accept-list (cons (car poss) accept-list))) (t ;; The user hit SPC, so accept this word, but keep ;; checking the rest of the line. (unless replace (setq accepted t) (setq replace (list (buffer-substring-no-properties (point) (+ word-len (point)))))) (This is also inelegant, as it tests 'replace' for being zero twice.) Contrary to the comment, as can be seen from ispell-command-loop, the value of 'replace' can be: nil if user pressed 'i' or 'u' nil if user pressed 'a' nil if user typed SPC 0 if user pressed 'A' replacement word if user typed 'r' or 'R' t if the spelling session should end So the above 'cond' is incorrect and should be fixed. In any case, the change, as it is, is for the worse, because 'a' is by far more important than SPC during spell-checking of technical text, where there are many acronyms and jargon words unknown to the dictionary. If we don't have good ideas how to fix the SPC case, we should revert the change and add a FIXME.