GNU bug report logs - #62677
Merge flyspell-mode with flyspell-prog-mode

Previous Next

To reply to this bug, email your comments to 62677 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Need to find a better name for flyspell-prog-mode
Date: Wed, 05 Apr 2023 15:13:18 +0200

Hello,

`flyspell-prog-mode' is a variant of `flyspell-mode' for editing
programs: it limits spell checking to areas of text fontified with
certain faces (`flyspell-prog-text-faces', normally strings and
comments).  The intention is obviously to skip keywords and tags that
are used by the programming language itself.

However, the name is confusing and undiscoverable: the name suggests
that `flyspell-prog-mode' has a direct relation to `prog-mode' or that
it would be a major mode (like `prog-mode').

`flyspell-prog-mode' seems to be much older than `prog-mode', but since
we have added `prog-mode' the name "flyspell-prog-mode" is kind of a
"false friend".  AFAIU there is no relation between the two names at all
but an etymological one.  In particular it is not necessary for
`flyspell-prog-mode' that the current major mode derives from
`prog-mode'.

In sum the name "flyspell-prog-mode" has become a very bad one.  We
should obsolete it and find a better one.


TIA,

Michael.


In GNU Emacs 30.0.50 (build 7, x86_64-pc-linux-gnu, cairo version
 1.16.0) of 2023-04-04 built on drachen
Repository revision: e1e4974862517ad5df2831508c39179ce178e0ef
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Message #8 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Payas Relekar <relekarpayas <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 05 Apr 2023 05:02:41 +0530

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> `flyspell-prog-mode' is a variant of `flyspell-mode' for editing
> programs: it limits spell checking to areas of text fontified with
> certain faces (`flyspell-prog-text-faces', normally strings and
> comments).  The intention is obviously to skip keywords and tags that
> are used by the programming language itself.
>
> In sum the name "flyspell-prog-mode" has become a very bad one.  We
> should obsolete it and find a better one.

flyspell-limit-region-mode ?
--

Message #11 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Akib Azmain Turja <akib <at> disroot.org>
To: Payas Relekar <relekarpayas <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 05 Apr 2023 21:04:38 +0600

[Message part 1 (text/plain, inline)]

Payas Relekar <relekarpayas <at> gmail.com> writes:

> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> `flyspell-prog-mode' is a variant of `flyspell-mode' for editing
>> programs: it limits spell checking to areas of text fontified with
>> certain faces (`flyspell-prog-text-faces', normally strings and
>> comments).  The intention is obviously to skip keywords and tags that
>> are used by the programming language itself.
>>
>> In sum the name "flyspell-prog-mode" has become a very bad one.  We
>> should obsolete it and find a better one.

flyspell-human-text-mode?
flyspell-comment-and-string-mode?

>
> flyspell-limit-region-mode ?
> --

flyspell-limited-mode?
flyspell-ltd-mode?
flyspell-co-mode?
flyspell-inc-mode?

-- 
Akib Azmain Turja, GPG key: 70018CE5819F17A3BBA666AFE74F0EFA922AE7F5
Fediverse: akib <at> hostux.social
Codeberg: akib
emailselfdefense.fsf.org | "Nothing can be secure without encryption."

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Akib Azmain Turja <akib <at> disroot.org>
Cc: michael_heerdegen <at> web.de, relekarpayas <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Wed, 05 Apr 2023 18:26:00 +0300

> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 62677 <at> debbugs.gnu.org
> Date: Wed, 05 Apr 2023 21:04:38 +0600
> From:  Akib Azmain Turja via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> >> In sum the name "flyspell-prog-mode" has become a very bad one.  We
> >> should obsolete it and find a better one.
> 
> flyspell-human-text-mode?
> flyspell-comment-and-string-mode?
> 
> >
> > flyspell-limit-region-mode ?
> > --
> 
> flyspell-limited-mode?
> flyspell-ltd-mode?
> flyspell-co-mode?
> flyspell-inc-mode?

flyspell-skip-keywords-mode
flyspell-ignore-keywords-mode

Message #17 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Akib Azmain Turja <akib <at> disroot.org>,
 Payas Relekar <relekarpayas <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 5 Apr 2023 18:46:28 +0300

On 05/04/2023 18:04, Akib Azmain Turja via Bug reports for GNU Emacs, 
the Swiss army knife of text editors wrote:

> flyspell-comment-and-string-mode?

I like this one.

Message #20 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 05 Apr 2023 19:17:46 +0300

> We should obsolete it and find a better one.

Too late to rename it because it runs 'flyspell-prog-mode-hook'
customized by users.

Message #23 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 05 Apr 2023 19:44:50 +0200

Juri Linkov <juri <at> linkov.net> writes:

> > We should obsolete it and find a better one.
>
> Too late to rename it because it runs 'flyspell-prog-mode-hook'
> customized by users.

Can't we use a `defvaralias' like in other places?

Michael.

Message #26 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: michael_heerdegen <at> web.de, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Wed, 05 Apr 2023 22:04:13 +0300

> Cc: 62677 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 05 Apr 2023 19:17:46 +0300
> 
> > We should obsolete it and find a better one.
> 
> Too late to rename it because it runs 'flyspell-prog-mode-hook'
> customized by users.

We could keep the hook name, with or without an alias.

Message #29 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Wed, 5 Apr 2023 13:29:59 -0700

On 4/5/2023 6:13 AM, Michael Heerdegen wrote:
> `flyspell-prog-mode' is a variant of `flyspell-mode' for editing
> programs: it limits spell checking to areas of text fontified with
> certain faces (`flyspell-prog-text-faces', normally strings and
> comments).  The intention is obviously to skip keywords and tags that
> are used by the programming language itself.

For what it's worth, when I started using flyspell-mode last year and 
subsequently discovered flyspell-prog-mode, I immediately understood 
what its intent was from the name. So from my perspective, it's actually 
a very good name. In particular, I never got the sense that it was a 
major mode or that it was *directly* tied to prog-mode; only that 
flyspell-prog-mode is most useful for programming-like modes (which are 
usually, but not always, derived from prog-mode).

It's possible there's a better name, but is the name really the main 
problem for discoverability? As far as discoverability goes, I believe I 
found out about flyspell-prog-mode via flyspell-mode's docstring:

> This mode is geared toward text modes.  In buffers that contain
> code, ‘flyspell-prog-mode’ is usually a better choice.

If there are still discoverability issues, then I think we should try to 
provide appropriate keywords in manuals, etc so that it's easier to find 
this. The problem of undiscoverable/misleading/opaque names in Emacs 
comes up fairly regularly (e.g. with Eglot), and while clear naming is 
helpful, I think it would be more helpful to make it easier for users to 
search for packages, modes, etc using whatever keywords make sense to 
them. Then discoverability is more about ensuring that we specify an 
appropriate set of keywords.

Message #32 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: michael_heerdegen <at> web.de, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Thu, 06 Apr 2023 09:24:46 +0300

> Date: Wed, 5 Apr 2023 13:29:59 -0700
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> On 4/5/2023 6:13 AM, Michael Heerdegen wrote:
> > `flyspell-prog-mode' is a variant of `flyspell-mode' for editing
> > programs: it limits spell checking to areas of text fontified with
> > certain faces (`flyspell-prog-text-faces', normally strings and
> > comments).  The intention is obviously to skip keywords and tags that
> > are used by the programming language itself.
> 
> For what it's worth, when I started using flyspell-mode last year and 
> subsequently discovered flyspell-prog-mode, I immediately understood 
> what its intent was from the name. So from my perspective, it's actually 
> a very good name.

That depends on what you understood ;-)  It could be that you
understood it immediately, but incorrectly or inaccurately.

> > This mode is geared toward text modes.  In buffers that contain
> > code, ‘flyspell-prog-mode’ is usually a better choice.

The above is inaccurate as well: text-derived modes for markup text
can also benefit.  Basically, anything where you have keywords that
are not necessarily words in a human language.

> If there are still discoverability issues, then I think we should try to 
> provide appropriate keywords in manuals, etc so that it's easier to find 
> this.

IMO, we should start with what the manual says:

     Flyspell Prog mode works just like ordinary Flyspell mode, except
  that it only checks words in comments and string constants.  This
  feature is useful for editing programs.

Which might try to explain the name, but in doing so, it misses the
opportunity to let the readers discover what that mode truly is and
what it can do.

Message #35 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 62677 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Thu, 06 Apr 2023 14:14:20 +0200

On Wed,  5 Apr 2023 at 19:44, Michael Heerdegen wrote:

> Juri Linkov <juri <at> linkov.net> writes:
>
>> > We should obsolete it and find a better one.
>>
>> Too late to rename it because it runs 'flyspell-prog-mode-hook'
>> customized by users.
>
> Can't we use a `defvaralias' like in other places?
>
> Michael.

I don't think a name tweak is useful.  If an improvement is at all
necessary, then just get rid of flyspell-prog-mode, that is, make
flyspell-mode skip keywords and the like by default in prog-derived
modes.  This is what is intended 99.7% of the time.

For the remaining 0.3% of the cases, it's more productive to provide an
easier way to customize what is ignored by Flyspell, using e.g. the
`spelling-ignore-functions' hook I suggested in the emacs-devel thread.

Message #38 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Thu, 6 Apr 2023 10:46:13 -0700

On 4/5/2023 11:24 PM, Eli Zaretskii wrote:
>> Date: Wed, 5 Apr 2023 13:29:59 -0700
>> From: Jim Porter <jporterbugs <at> gmail.com>
>>
>> On 4/5/2023 6:13 AM, Michael Heerdegen wrote:
>>> `flyspell-prog-mode' is a variant of `flyspell-mode' for editing
>>> programs: it limits spell checking to areas of text fontified with
>>> certain faces (`flyspell-prog-text-faces', normally strings and
>>> comments).  The intention is obviously to skip keywords and tags that
>>> are used by the programming language itself.
>>
>> For what it's worth, when I started using flyspell-mode last year and
>> subsequently discovered flyspell-prog-mode, I immediately understood
>> what its intent was from the name. So from my perspective, it's actually
>> a very good name.
> 
> That depends on what you understood ;-)  It could be that you
> understood it immediately, but incorrectly or inaccurately.

To be clear, my understanding was that 'flyspell-prog-mode' is what you 
should use for modes where some text should be ignored for 
spell-checking. (Code is the most obvious example, but not the only one.)

>>> This mode is geared toward text modes.  In buffers that contain
>>> code, ‘flyspell-prog-mode’ is usually a better choice.
> 
> The above is inaccurate as well: text-derived modes for markup text
> can also benefit.  Basically, anything where you have keywords that
> are not necessarily words in a human language.

Maybe something like this would be more-precise?

"This mode spell checks all the text in a buffer.  In buffers that 
contain text that shouldn't be spell-checked (such as code or markup), 
'flyspell-prog-mode' is usually a better choice."

Then, we could expand on the docstring for 'flyspell-prog-mode', since 
it's pretty short right now.

> IMO, we should start with what the manual says:
> 
>       Flyspell Prog mode works just like ordinary Flyspell mode, except
>    that it only checks words in comments and string constants.  This
>    feature is useful for editing programs.
> 
> Which might try to explain the name, but in doing so, it misses the
> opportunity to let the readers discover what that mode truly is and
> what it can do.

Yeah, this could probably use a bit of expansion too. It does a 
reasonable job of explaining why you'd use it in a programming mode, but 
that's (arguably) already obvious from the name.

Message #41 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Thu, 06 Apr 2023 22:43:01 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > flyspell-skip-keywords-mode
  > flyspell-ignore-keywords-mode

I don't think that name correctly describes what the function does.
Its code suggests that it limits spell checking to string constants
and comments.  That means, if I understand it right, that keywords
won't be spell checked, and symbol names also won't be spell checked.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #44 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Fri, 07 Apr 2023 09:39:38 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: 62677 <at> debbugs.gnu.org
> Date: Thu, 06 Apr 2023 22:43:01 -0400
> 
>   > flyspell-skip-keywords-mode
>   > flyspell-ignore-keywords-mode
> 
> I don't think that name correctly describes what the function does.
> Its code suggests that it limits spell checking to string constants
> and comments.

??? Where do you see a reference to strings and comments in the two
names I suggested?

> That means, if I understand it right, that keywords
> won't be spell checked, and symbol names also won't be spell checked.

"Symbol" has no meaning for descendants of Text mode which use markup
commands.  It is only meaningful for programming language modes.  And
this feature is not limited to programming languages, that's the
source of the original confusing name to begin with.

Message #47 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Sun, 09 Apr 2023 22:53:25 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > flyspell-skip-keywords-mode
  > >   > flyspell-ignore-keywords-mode
  > > 
  > > I don't think that name correctly describes what the function does.
  > > Its code suggests that it limits spell checking to string constants
  > > and comments.

  > ??? Where do you see a reference to strings and comments in the two
  > names I suggested?

I saw that in a diff that was in one of the emails in this thread.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #50 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Mon, 10 Apr 2023 07:48:33 +0300

> From: Richard Stallman <rms <at> gnu.org>
> Cc: 62677 <at> debbugs.gnu.org
> Date: Sun, 09 Apr 2023 22:53:25 -0400
> 
>   > >   > flyspell-skip-keywords-mode
>   > >   > flyspell-ignore-keywords-mode
>   > > 
>   > > I don't think that name correctly describes what the function does.
>   > > Its code suggests that it limits spell checking to string constants
>   > > and comments.
> 
>   > ??? Where do you see a reference to strings and comments in the two
>   > names I suggested?
> 
> I saw that in a diff that was in one of the emails in this thread.

That was a suggestion from someone else, and I agree that it is
sub-optimal, for the reasons you gave.  Which is why I suggested
different names, without a reference to comments or strings.

Message #55 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, Jim Porter <jporterbugs <at> gmail.com>,
 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Tue, 5 Sep 2023 13:57:50 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > This mode is geared toward text modes.  In buffers that contain
>> > code, ‘flyspell-prog-mode’ is usually a better choice.
>
> The above is inaccurate as well: text-derived modes for markup text
> can also benefit.  Basically, anything where you have keywords that
> are not necessarily words in a human language.

FWIW, that's actually not been clear to me.  I've only use it in
`prog-mode' derived modes so far.

But perhaps this goes even deeper:

I'm not sure why I can't just enable `flymake-mode' and have it do the
right thing, which IMO would be to enable `flymake-prog-mode' in modes
where it might make sense to have that behavior.  Major modes can tell
us what makes sense themselves, and if there are modes where the
decision is not clear-cut, they could make it into a user option.

Enabling something like `flymake-global-mode' and have it just work
would be pretty neat.

Message #58 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Wed, 06 Sep 2023 14:19:34 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 5 Sep 2023 13:57:50 -0700
> Cc: Jim Porter <jporterbugs <at> gmail.com>, michael_heerdegen <at> web.de, 62677 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > This mode is geared toward text modes.  In buffers that contain
> >> > code, ‘flyspell-prog-mode’ is usually a better choice.
> >
> > The above is inaccurate as well: text-derived modes for markup text
> > can also benefit.  Basically, anything where you have keywords that
> > are not necessarily words in a human language.
> 
> FWIW, that's actually not been clear to me.  I've only use it in
> `prog-mode' derived modes so far.
> 
> But perhaps this goes even deeper:
> 
> I'm not sure why I can't just enable `flymake-mode' and have it do the
> right thing, which IMO would be to enable `flymake-prog-mode' in modes
> where it might make sense to have that behavior.  Major modes can tell
> us what makes sense themselves, and if there are modes where the
> decision is not clear-cut, they could make it into a user option.
> 
> Enabling something like `flymake-global-mode' and have it just work
> would be pretty neat.

I guess you mean flyspell-mode.

Yes, having the command automatically DTRT is always best.  So if we
can do that in at least some significant proportion of cases, I think
we should.

Message #61 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Wed, 6 Sep 2023 11:51:14 -0700

retitle 62677 Merge flyspell-mode with flyspell-prog-mode
tags 62677 + easy
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> I'm not sure why I can't just enable `flymake-mode' and have it do the
>> right thing, which IMO would be to enable `flymake-prog-mode' in modes
>> where it might make sense to have that behavior.  Major modes can tell
>> us what makes sense themselves, and if there are modes where the
>> decision is not clear-cut, they could make it into a user option.
>>
>> Enabling something like `flymake-global-mode' and have it just work
>> would be pretty neat.
>
> I guess you mean flyspell-mode.
>
> Yes, having the command automatically DTRT is always best.  So if we
> can do that in at least some significant proportion of cases, I think
> we should.

I took a look, and it seems like it would be a relatively
straightforward addition to `flyspell-mode'.  I'm adding the tag "easy",
as this seems like a pretty good introductory project.

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.

Would `prog-mode' be a candidate though, or do we expect any modes
inheriting from it to want the regular `flyspell-mode'?

Message #68 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50;
 Need to find a better name for flyspell-prog-mode
Date: Wed, 06 Sep 2023 22:05:38 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 6 Sep 2023 11:51:14 -0700
> Cc: jporterbugs <at> gmail.com, michael_heerdegen <at> web.de, 62677 <at> 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?

Message #71 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com,
 Eli Zaretskii <eliz <at> gnu.org>, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Thu, 07 Sep 2023 09:30:16 +0300

> 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.
>
> Would `prog-mode' be a candidate though, or do we expect any modes
> inheriting from it to want the regular `flyspell-mode'?

Removing flyspell-prog-mode will break a lot of user configs
that often contain such a pair:

  (add-hook 'text-mode-hook 'flyspell-mode)
  (add-hook 'prog-mode-hook 'flyspell-prog-mode)

Message #74 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, stefankangas <at> gmail.com,
 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: 30.0.50; Need to find a better name for
 flyspell-prog-mode
Date: Thu, 07 Sep 2023 10:09:31 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  michael_heerdegen <at> web.de,
>   jporterbugs <at> gmail.com,  62677 <at> debbugs.gnu.org
> Date: Thu, 07 Sep 2023 09:30:16 +0300
> 
> > 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.
> >
> > Would `prog-mode' be a candidate though, or do we expect any modes
> > inheriting from it to want the regular `flyspell-mode'?
> 
> Removing flyspell-prog-mode will break a lot of user configs
> that often contain such a pair:
> 
>   (add-hook 'text-mode-hook 'flyspell-mode)
>   (add-hook 'prog-mode-hook 'flyspell-prog-mode)

There's no intent to remove flyspell-prog-mode, just to make
flyspell-mode more intelligent.

Message #77 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: Merge flyspell-mode with flyspell-prog-mode
Date: Sun, 24 Sep 2023 07:08:56 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 6 Sep 2023 11:51:14 -0700
>> Cc: jporterbugs <at> gmail.com, michael_heerdegen <at> web.de, 62677 <at> 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?

[0001-Make-flyspell-mode-DWIM-in-prog-mode-buffers.patch (text/x-patch, attachment)]

Message #80 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: Merge flyspell-mode with flyspell-prog-mode
Date: Sun, 24 Sep 2023 18:41:35 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 24 Sep 2023 07:08:56 -0700
> Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Wed, 6 Sep 2023 11:51:14 -0700
> >> Cc: jporterbugs <at> gmail.com, michael_heerdegen <at> web.de, 62677 <at> 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.

Message #83 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: Merge flyspell-mode with flyspell-prog-mode
Date: Sun, 24 Sep 2023 09:29:23 -0700

Eli Zaretskii <eliz <at> 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?

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.

If not, I think it makes sense to have just the one command, because it
is simpler.  This is what I had in mind.

> 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.

> 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.

Message #86 received at 62677 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: michael_heerdegen <at> web.de, jporterbugs <at> gmail.com, 62677 <at> debbugs.gnu.org
Subject: Re: bug#62677: Merge flyspell-mode with flyspell-prog-mode
Date: Sun, 24 Sep 2023 19:42:39 +0300

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.