bug#44171: Make cwarn.el obsolete

bug#44171: Make cwarn.el obsolete

[Stefan Kangas]

cwarn.el is a package that highlights three types of "suspicious C and
C++ constructions".

;; * Assignments inside expressions, including variations like "+=".
;; * Semicolon following immediately after `if', `for', and `while'
;;   (except, of course, after a `do .. while' statement).
;; * C++ functions with reference parameters.

This was written in 1999, but is it useful today?

Modern compilers should warn about the above, and for the cases where
they don't, users are probably better off using a real linter (such as
cppcheck for C).

Should cwarn.el be obsoleted?

bug#44171: Make cwarn.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 23 Oct 2020 10:53:50 +0000
> 
> cwarn.el is a package that highlights three types of "suspicious C and
> C++ constructions".
> 
> ;; * Assignments inside expressions, including variations like "+=".
> ;; * Semicolon following immediately after `if', `for', and `while'
> ;;   (except, of course, after a `do .. while' statement).
> ;; * C++ functions with reference parameters.
> 
> This was written in 1999, but is it useful today?

I'm still using it, and it sometimes shows mistakes I'm about to make.
Are there any alternatives that highlight such suspicious constructs?

> Modern compilers should warn about the above, and for the cases where
> they don't, users are probably better off using a real linter (such as
> cppcheck for C).

The point of that feature is to show you potential mistakes
_as_you_program_, without waiting for the compilation.  Besides, one
could compile while turning warnings off, in which case they will not
see the warnings at all.

> Should cwarn.el be obsoleted?

As a general rule, IMO we shouldn't lose a feature unless either
(a) there is a replacement that does at least as well; or (b) the
feature no longer makes sense at all, e.g. because the problem it
tries to solve can no longer happen.

bug#44171: Make cwarn.el obsolete

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> This was written in 1999, but is it useful today?
>
> I'm still using it, and it sometimes shows mistakes I'm about to make.
> Are there any alternatives that highlight such suspicious constructs?

I was under the impression that flymake was such a replacement?

> As a general rule, IMO we shouldn't lose a feature unless either
> (a) there is a replacement that does at least as well; or (b) the
> feature no longer makes sense at all, e.g. because the problem it
> tries to solve can no longer happen.

That looks like sound criteria, as a first approximation.

I'm not sure how to fit in things like obsoleting support for the Mosaic
web browser in browse-url.el, but I suppose we could say that "the
problem [of using that browser] can no longer happen".

To be clear, I'm not on a quest to remove actually useful features.  I
just stumbled across cwarn.el while looking for stuff that need tests
and/or should be converted to lexical-binding.

bug#44171: Make cwarn.el obsolete

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 23 Oct 2020 12:12:49 +0000
> Cc: 44171@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This was written in 1999, but is it useful today?
> >
> > I'm still using it, and it sometimes shows mistakes I'm about to make.
> > Are there any alternatives that highlight such suspicious constructs?
> 
> I was under the impression that flymake was such a replacement?

Flymake is a much larger package which affects the workflow in many
ways.  Telling people to use Flymake when all they need is what
cwarn.el provides would be like deprecating Outline mode because we
have Org, for example.

I thought CC mode could have something similar.  Or maybe there's a
way of adding to CC mode a similar feature, then we could retire
cwarn.el.

> To be clear, I'm not on a quest to remove actually useful features.  I
> just stumbled across cwarn.el while looking for stuff that need tests
> and/or should be converted to lexical-binding.

I'm very happy with its functionality, FWIW.  Thank you for taking
care of it.

bug#44171: Make cwarn.el obsolete

[Stefan Kangas]

tags 44171 + wontfix
close 44171
thanks

Eli Zaretskii <eliz@gnu.org> writes:

> Flymake is a much larger package which affects the workflow in many
> ways.  Telling people to use Flymake when all they need is what
> cwarn.el provides would be like deprecating Outline mode because we
> have Org, for example.

I see your point.

>> To be clear, I'm not on a quest to remove actually useful features.  I
>> just stumbled across cwarn.el while looking for stuff that need tests
>> and/or should be converted to lexical-binding.
>
> I'm very happy with its functionality, FWIW.  Thank you for taking
> care of it.

Thanks for sharing your input.  It seems like the logical thing here is
to close this bug report, so I'm doing that now.