emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ELPA] Add compat.el


From: Philip Kaludercic
Subject: [ELPA] Add compat.el
Date: Mon, 04 Oct 2021 23:00:38 +0000

Hello again,

I have been working on compat.el over the last week, and have written a
number of tests. The source code has been uploaded here:

       https://git.sr.ht/~pkal/compat

The library should be usable in it's current state, but I'd be
interested to hear from other people and developers too.  There might be
missing functions or macros, edge cases that could be added to the
tests, etc. that could be improved.

Finally, compat.el now ends with these lines:

--8<---------------cut here---------------start------------->8---
;; ;;;; Ensure NonGNU ELPA is in `package-archives'
;; (with-eval-after-load 'package
;;   (unless (or (rassoc "https://elpa.nongnu.org/nongnu/"; package-archives)
;;               (rassoc "http://elpa.nongnu.org/nongnu/"; package-archives)
;;               (rassoc "https://elpa.nongnu.org/nongnu-devel/"; 
package-archives)
;;               (rassoc "http://elpa.nongnu.org/nongnu-devel/"; 
package-archives))
;;     (add-to-list 'package-archives '("nongnu" . 
"https://elpa.nongnu.org/nongnu/";))))

;; To ensure that compat.el is loaded as soon as possible, a require
;; call is inserted directly into the autoload file:
;;;###autoload (require 'compat)
--8<---------------cut here---------------end--------------->8---

The first block ensures that NonGNU ELPA is added to package-archives,
in the hope that if ELPA packages were to use compat.el, older versions
would automatically be configured to use NonGNU ELPA.  The upside is
wider adoption, the downside is that this is pretty invasive (an
alternative would be to check if package-archives is unmodified, and
only update it in that case).

The second block would automatically require compat.el in the autoload
file, so as to avoid manual (require 'compat) statements in packages
that use the library. I haven't tested this part extensively yet, but
could there be something that this might break?

Philip Kaludercic <philipk@posteo.net> writes:

> Hi,
>
> over the last few days I have been working on a forwards-compatibility
> library for Emacs, here is a first iteration:
>
> The idea is to allow developers who don't want to break backwards
> compatibility to use newer functionality that wasn't provided in older
> versions of Emacs. This version tries to implement as much as possible
> from Emacs 24.2 onwards.
>
> [...]

-- 
        Philip Kaludercic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]