* bug#52351: Is bad-packages-alist still relevant?
@ 2021-12-07 14:10 Stefan Kangas
2021-12-10 12:27 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Kangas @ 2021-12-07 14:10 UTC (permalink / raw)
To: 52351; +Cc: Glenn Morris
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
Severity: wishlist
Is bad-packages-alist still relevant now that we have package.el or
should it just be removed, as in the attached?
It was added in this commit and hasn't seen much use since, AFAICT:
commit a2603048ce283d22b37b35c9098d4583db244073
Author: Glenn Morris <rgm@gnu.org>
Date: Tue Aug 14 07:41:59 2007 +0000
(bad-packages-alist): New constant.
(bad-package-check): New function. Together, these two add
elements to `after-load-alist' to check for problematic external
packages.
The idea is to give warnings for incompatible external packages, but
this should be rather unusual these days, as most packages will be
installed with package.el and any incompatibilities are better handled
in that context. Furthermore, it seems to currently just warn about
really ancient versions of semantic and cua-mode.
IOW, not a bad idea at the time, but the passing of time has meant that
it's hard to see the relevance of the feature.
[-- Attachment #2: 0001-Remove-bad-packages-alist.patch --]
[-- Type: text/x-diff, Size: 3092 bytes --]
From ed1e061961cfc3eba7d692f93e5fbb70e7df4760 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 7 Dec 2021 14:46:34 +0100
Subject: [PATCH] Remove bad-packages-alist
* lisp/simple.el (bad-packages-alist, bad-package-check): Remove.
---
lisp/simple.el | 51 --------------------------------------------------
1 file changed, 51 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 84928caa31..d9845dc3cd 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -9783,57 +9783,6 @@ messages-buffer
;; (list 'modification-hooks '(minibuffer-prompt-modification)
;; 'insert-in-front-hooks '(minibuffer-prompt-insertion)))
-\f
-;;;; Problematic external packages.
-
-;; rms says this should be done by specifying symbols that define
-;; versions together with bad values. This is therefore not as
-;; flexible as it could be. See the thread:
-;; https://lists.gnu.org/r/emacs-devel/2007-08/msg00300.html
-(defconst bad-packages-alist
- ;; Not sure exactly which semantic versions have problems.
- ;; Definitely 2.0pre3, probably all 2.0pre's before this.
- '((semantic semantic-version "\\`2\\.0pre[1-3]\\'"
- "The version of `semantic' loaded does not work in Emacs 22.
-It can cause constant high CPU load.
-Upgrade to at least Semantic 2.0pre4 (distributed with CEDET 1.0pre4).")
- ;; CUA-mode does not work with GNU Emacs version 22.1 and newer.
- ;; Except for version 1.2, all of the 1.x and 2.x version of cua-mode
- ;; provided the `CUA-mode' feature. Since this is no longer true,
- ;; we can warn the user if the `CUA-mode' feature is ever provided.
- (CUA-mode t nil
-"CUA-mode is now part of the standard GNU Emacs distribution,
-so you can now enable CUA via the Options menu or by customizing `cua-mode'.
-
-You have loaded an older version of CUA-mode which does not work
-correctly with this version of Emacs. You should remove the old
-version and use the one distributed with Emacs."))
- "Alist of packages known to cause problems in this version of Emacs.
-Each element has the form (PACKAGE SYMBOL REGEXP STRING).
-PACKAGE is either a regular expression to match file names, or a
-symbol (a feature name), like for `with-eval-after-load'.
-SYMBOL is either the name of a string variable, or t. Upon
-loading PACKAGE, if SYMBOL is t or matches REGEXP, display a
-warning using STRING as the message.")
-
-(defun bad-package-check (package)
- "Run a check using the element from `bad-packages-alist' matching PACKAGE."
- (condition-case nil
- (let* ((list (assoc package bad-packages-alist))
- (symbol (nth 1 list)))
- (and list
- (boundp symbol)
- (or (eq symbol t)
- (and (stringp (setq symbol (eval symbol)))
- (string-match-p (nth 2 list) symbol)))
- (display-warning package (nth 3 list) :warning)))
- (error nil)))
-
-(dolist (elem bad-packages-alist)
- (let ((pkg (car elem)))
- (with-eval-after-load pkg
- (bad-package-check pkg))))
-
\f
;;; Generic dispatcher commands
--
2.30.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
* bug#52351: Is bad-packages-alist still relevant?
2021-12-07 14:10 bug#52351: Is bad-packages-alist still relevant? Stefan Kangas
@ 2021-12-10 12:27 ` Lars Ingebrigtsen
2021-12-10 20:00 ` Stefan Kangas
2021-12-19 15:19 ` Stefan Kangas
0 siblings, 2 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-10 12:27 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Glenn Morris, 52351
Stefan Kangas <stefan@marxist.se> writes:
> IOW, not a bad idea at the time, but the passing of time has meant that
> it's hard to see the relevance of the feature.
Yeah, it doesn't seem very useful to me. We should probably obsolete
it, though, instead of removing it outright, I guess? (Even if it's a
defconst.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52351: Is bad-packages-alist still relevant?
2021-12-10 12:27 ` Lars Ingebrigtsen
@ 2021-12-10 20:00 ` Stefan Kangas
2021-12-19 15:19 ` Stefan Kangas
1 sibling, 0 replies; 6+ messages in thread
From: Stefan Kangas @ 2021-12-10 20:00 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Glenn Morris, 52351
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Yeah, it doesn't seem very useful to me. We should probably obsolete
> it, though, instead of removing it outright, I guess? (Even if it's a
> defconst.)
Sure, we might as well obsolete it.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52351: Is bad-packages-alist still relevant?
2021-12-10 12:27 ` Lars Ingebrigtsen
2021-12-10 20:00 ` Stefan Kangas
@ 2021-12-19 15:19 ` Stefan Kangas
2021-12-21 4:15 ` Richard Stallman
1 sibling, 1 reply; 6+ messages in thread
From: Stefan Kangas @ 2021-12-19 15:19 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Glenn Morris, 52351
close 52351 29.1
thanks
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Stefan Kangas <stefan@marxist.se> writes:
>
>> IOW, not a bad idea at the time, but the passing of time has meant that
>> it's hard to see the relevance of the feature.
>
> Yeah, it doesn't seem very useful to me. We should probably obsolete
> it, though, instead of removing it outright, I guess? (Even if it's a
> defconst.)
No further comments within 9 days, so I have now made it obsolete on
master (commit 8f82a83cae).
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52351: Is bad-packages-alist still relevant?
2021-12-19 15:19 ` Stefan Kangas
@ 2021-12-21 4:15 ` Richard Stallman
2021-12-21 10:02 ` Stefan Kangas
0 siblings, 1 reply; 6+ messages in thread
From: Richard Stallman @ 2021-12-21 4:15 UTC (permalink / raw)
To: Stefan Kangas; +Cc: rgm, larsi, 52351
[[[ 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. ]]]
bad-packages-alist may be useful again some day, so please restore its
non-obsoleteness.
The specific issue about Semantic and Emacs 22 is no longer pertinent,
so we should set the variable's default value to nil.
However, that kind of problem could happen again some day. We hope it
won't, but few of us are perfect and none of us is precognitive. Why
not be prepared in case such problems occur again?
--
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)
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#52351: Is bad-packages-alist still relevant?
2021-12-21 4:15 ` Richard Stallman
@ 2021-12-21 10:02 ` Stefan Kangas
0 siblings, 0 replies; 6+ messages in thread
From: Stefan Kangas @ 2021-12-21 10:02 UTC (permalink / raw)
To: rms; +Cc: rgm, larsi, 52351
Richard Stallman <rms@gnu.org> writes:
> bad-packages-alist may be useful again some day, so please restore its
> non-obsoleteness.
>
> The specific issue about Semantic and Emacs 22 is no longer pertinent,
> so we should set the variable's default value to nil.
>
> However, that kind of problem could happen again some day. We hope it
> won't, but few of us are perfect and none of us is precognitive. Why
> not be prepared in case such problems occur again?
Beyond the original Semantic case, this hasn't seen much use in 15
years. If we need it back in the future, we can make it non-obsolete
then. We have another decade to think about its obsoletion before it
would normally be considered for final removal.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-21 10:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-07 14:10 bug#52351: Is bad-packages-alist still relevant? Stefan Kangas
2021-12-10 12:27 ` Lars Ingebrigtsen
2021-12-10 20:00 ` Stefan Kangas
2021-12-19 15:19 ` Stefan Kangas
2021-12-21 4:15 ` Richard Stallman
2021-12-21 10:02 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).