GNU bug report logs -
#37837
[PATCH] Make sb-image.el obsolete
Previous Next
Reported by: Stefan Kangas <stefan <at> marxist.se>
Date: Sun, 20 Oct 2019 20:29:02 UTC
Severity: normal
Tags: patch
Fixed in version 28.1
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37837 in the body.
You can then email your comments to 37837 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37837
; Package
emacs
.
(Sun, 20 Oct 2019 20:29:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefan <at> marxist.se>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 20 Oct 2019 20:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
sb-image.el says:
;; Supporting Image display for Emacs 20 and less, Emacs 21, and XEmacs,
;; is a challenging task, which doesn't take kindly to being byte compiled.
;; When sharing speedbar.elc between these three applications, the Image
;; support can get lost.
;;
;; By splitting out that hard part into this file, and avoiding byte
;; compilation, one copy speedbar can support all these platforms together.
I suggest to get rid of this compatibility kludge. Is the attached
patch an acceptable way to do that?
Best regards,
Stefan Kangas
[0001-Make-sb-image.el-to-obsolete.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37837
; Package
emacs
.
(Mon, 21 Oct 2019 06:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37837 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sun, 20 Oct 2019 22:28:40 +0200
>
> sb-image.el says:
>
> ;; Supporting Image display for Emacs 20 and less, Emacs 21, and XEmacs,
> ;; is a challenging task, which doesn't take kindly to being byte compiled.
> ;; When sharing speedbar.elc between these three applications, the Image
> ;; support can get lost.
> ;;
> ;; By splitting out that hard part into this file, and avoiding byte
> ;; compilation, one copy speedbar can support all these platforms together.
>
> I suggest to get rid of this compatibility kludge. Is the attached
> patch an acceptable way to do that?
Did we decide to drop support of those older Emacs versions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37837
; Package
emacs
.
(Sat, 02 Nov 2019 03:22:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 37837 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > From: Stefan Kangas <stefan <at> marxist.se>
> > Date: Sun, 20 Oct 2019 22:28:40 +0200
> >
> > sb-image.el says:
> >
> > ;; Supporting Image display for Emacs 20 and less, Emacs 21, and XEmacs,
> > ;; is a challenging task, which doesn't take kindly to being byte compiled.
> > ;; When sharing speedbar.elc between these three applications, the Image
> > ;; support can get lost.
> > ;;
> > ;; By splitting out that hard part into this file, and avoiding byte
> > ;; compilation, one copy speedbar can support all these platforms together.
> >
> > I suggest to get rid of this compatibility kludge. Is the attached
> > patch an acceptable way to do that?
>
> Did we decide to drop support of those older Emacs versions?
I'm not aware of any general requirement to maintain backwards
compatibility with ancient Emacs versions on master. For example, we
have dropped all compatibility function and variable aliases.
Users of Emacs 21 or older should surely just use whatever was shipped
with the version of Emacs that they are using. Or am I missing
something?
To be clear, this package is not distributed on GNU ELPA as far as I can tell.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37837
; Package
emacs
.
(Sun, 17 Nov 2019 09:58:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 37837 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> I'm not aware of any general requirement to maintain backwards
> compatibility with ancient Emacs versions on master. For example, we
> have dropped all compatibility function and variable aliases.
We routinely drop support for old versions of Emacs from the .el files
in Emacs -- there's no point in carrying around dead weight.
So I think the patch looks good to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37837
; Package
emacs
.
(Fri, 17 Jan 2020 05:58:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 37837 <at> debbugs.gnu.org (full text, mbox):
close 37837 28.1
thanks
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> We routinely drop support for old versions of Emacs from the .el files
> in Emacs -- there's no point in carrying around dead weight.
>
> So I think the patch looks good to me.
No further comments within 8 weeks, so I pushed this to master as
commit 6dbe2c932a.
Best regards,
Stefan Kangas
bug marked as fixed in version 28.1, send any further explanations to
37837 <at> debbugs.gnu.org and Stefan Kangas <stefan <at> marxist.se>
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Fri, 17 Jan 2020 05:58:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 14 Feb 2020 12:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.