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#62677: Merge flyspell-mode with flyspell-prog-mode Date: Sun, 24 Sep 2023 19:42:39 +0300 Message-ID: <83il7z34lc.fsf@gnu.org> References: <87mt3mv5e9.fsf@web.de> <076460cb-f203-de49-c949-bdc213fd1965@gmail.com> <83y1n5r0i9.fsf@gnu.org> <83o7if35x5.fsf@gnu.org> <83bkef15rx.fsf@gnu.org> <83lecv37f4.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21119"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael_heerdegen@web.de, jporterbugs@gmail.com, 62677@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 24 18:44:10 2023 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 1qkSDJ-0005Lv-VJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Sep 2023 18:44:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkSD2-0000h8-HY; Sun, 24 Sep 2023 12:43:52 -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 1qkSD1-0000gz-2P for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 12:43:51 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qkSD0-0002HY-Qy for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 12:43:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkSDC-0006qn-E4 for bug-gnu-emacs@gnu.org; Sun, 24 Sep 2023 12:44: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: Sun, 24 Sep 2023 16:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62677 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: easy Original-Received: via spool by 62677-submit@debbugs.gnu.org id=B62677.169557381326284 (code B ref 62677); Sun, 24 Sep 2023 16:44:02 +0000 Original-Received: (at 62677) by debbugs.gnu.org; 24 Sep 2023 16:43:33 +0000 Original-Received: from localhost ([127.0.0.1]:43529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkSCj-0006pr-DQ for submit@debbugs.gnu.org; Sun, 24 Sep 2023 12:43:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkSCe-0006pX-7N for 62677@debbugs.gnu.org; Sun, 24 Sep 2023 12:43:31 -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 1qkSCM-00029E-Ry; Sun, 24 Sep 2023 12:43:10 -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=Uh+nwnljsE46xO2l1EKx2cqRWY1wXf9OEP+/KB0qSt8=; b=UOojpzx4EgFt H1iXu/dENpC35hDcT+1VmvygmN9wa3HuO19pgmu7gjwiduvdaUPgOWf9CY3ZqWACAER+eSWycKYwk QhIiHH9dH9NVDVOuqnKEuZS03Sh72eYp3MdB4FbNL4bWVd20x1QzDXoNB6GLw8v9vJXZxymBBYPSC mROmTIRP8wKxYzZs/Mw/D2SBRk5fTNkdyi1+OulQwMc22BRPqWB/35pE+cxo70RmzXHmOE6jhaqKJ PrsxyEUNBUiBn7P0xlZcNomZhhTtJ9L+vin0QJ5siAR8i3yI8Nuv+pfBbGE0sSx1OJ0G1I0/EiDcX 57cY/QmcfLD3XyMKA6MxKw==; In-Reply-To: (message from Stefan Kangas on Sun, 24 Sep 2023 09:29:23 -0700) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271263 Archived-At: > From: Stefan Kangas > Date: Sun, 24 Sep 2023 09:29:23 -0700 > Cc: michael_heerdegen@web.de, jporterbugs@gmail.com, 62677@debbugs.gnu.org > > Eli Zaretskii writes: > > > Looks good in general, but why deprecate and de-document > > flyspell-prog-mode? I can easily envision a major mode that doesn't > > inherit from prog-mode, but still has defined syntax for comments and > > strings: why not let users invoke flyspell-prog-mode in those cases? > > Shouldn't such modes simply be added to the new > `flyspell-programming-mode-list' variable? Why introduce this new variable at all? It urges people to migrate, for no good reason: this variable and what it does is IMO no more elegant or easier to maintain than what we have now. I thought we would just turn flyspell-prog-mode automatically in descendants of prog-mode, and leave the rest to users and authors of major modes. What you seem to be suggesting is a much more radical change, and I'm not sure it's justified, especially since it comes with deprecation and user annoyance. > Or do you envision situations where which one is "best" will be a matter > of user preference? If yes, we should of course keep them both. That, too, could be possible, yes. > If not, I think it makes sense to have just the one command, because it > is simpler. Is it, though? It doesn't seem simpler for us: we still need to maintain and document the facilities for programming modes, just different facilities from what we have now. And it definitely isn't simpler for users, because what worked in Emacs 29 and before will suddenly start producing warnings in Emacs 30. > This is what I had in mind. Well, AFAICT, it was never said in the discussion until now. Which is why I'm surprised to see this. > > Moreover, users might have customizations that reference > > flyspell-prog-mode, and I see no reason to annoy them with obsoletion > > warnings. > > This will not be relevant if we're keeping both commands, but just in > case: > > You're right that such warnings would be a nuisance, and not really > worth it. That's why I chose to document it as deprecated, without any > warnings. We could also remove the sentence saying that it will be > marked as obsolete. If we do not obsolete flyspell-prog-mode, I'm okay with the changes, although I still think we could do equally well by just turning on flyspell-prog-mode automatically in prog-mode descendants. > > IOW, we just made the users' lives easier by automatically activating > > flyspell-prog-mode when we know it's appropriate, we are not saying > > that what flyspell-prog-mode does is incorrect or suboptimal. > > This seems to suggest that you envision that users might want to use one > or the other, at least in some cases. That's perfectly fine by me, if > that's the case. Maybe, I don't know. What I know is that every change can potentially break someone's setup, so we should avoid making changes that are not really necessary.