[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#62677: Merge flyspell-mode with flyspell-prog-mode
From: |
Eli Zaretskii |
Subject: |
bug#62677: Merge flyspell-mode with flyspell-prog-mode |
Date: |
Sun, 24 Sep 2023 18:41:35 +0300 |
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 24 Sep 2023 07:08:56 -0700
> Cc: michael_heerdegen@web.de, jporterbugs@gmail.com, 62677@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Wed, 6 Sep 2023 11:51:14 -0700
> >> Cc: jporterbugs@gmail.com, michael_heerdegen@web.de, 62677@debbugs.gnu.org
> >>
> >> 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.