Subject: Re: bug#62677: Merge flyspell-mode with flyspell-prog-mode

From: Eli Zaretskii <[email-masked]>
Date: Sun, 24 Sep 2023 18:41:35 +0300

> From: Stefan Kangas <[email-masked]>
> Date: Sun, 24 Sep 2023 07:08:56 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> From: Stefan Kangas <[email-masked]>
> >> Date: Wed, 6 Sep 2023 11:51:14 -0700
> >> Cc: [email-masked], [email-masked], [email-masked]
> >>
> >> Here's the plan I'd propose: Add a new defvar-local
> >> `flyspell-use-prog-mode' or somesuch that major modes can set.  Now,
> >> when a user enables `flymake-mode' in a buffer where that variable is
> >> non-nil, the extra stuff done in `flyspell-prog-mode' gets done too.
> >> Then decide which built-in major modes that would benefit, and set that
> >> variable in them.
> >
> > SGTM.
> >
> >> Would `prog-mode' be a candidate though, or do we expect any modes
> >> inheriting from it to want the regular `flyspell-mode'?
> >
> > The former, I guess?
> 
> Thanks.  How does the attached patch look?

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?
Moreover, users might have customizations that reference
flyspell-prog-mode, and I see no reason to annoy them with obsoletion
warnings.

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.