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

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 24 Sep 2023 09:29:23 -0700
> Cc: michael_heerdegen@web.de, jporterbugs@gmail.com, 62677@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> 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.