[Top][All Lists]

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

Re: feature/integrated-elpa 4f6df43 15/23: README added

From: Phillip Lord
Subject: Re: feature/integrated-elpa 4f6df43 15/23: README added
Date: Wed, 19 Oct 2016 21:24:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Alain Schneble <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>> (error "org-html is now deprecated")
>> (provide 'org-html)
>> Yes, that would work, but does not provide a good solution to my mind.
> Yes, that is one approach.  The other I proposed is using
> after-load-alist:
> Extract the example in the attached file.
> - emacs -Q
> - Eval the following fragment, after having replaced [path-to] to the
>   proper path where the example was extracted to:
>   (push "[path-to]/deprecated-feature-example/foo-package-1.0" load-path)
>   (push "[path-to]/deprecated-feature-example/foo-package-2.0" load-path)
>   (require 'foo-old)
>   => an error will be signaled "foo-old is no longer supported..."
> But don't get me wrong.  I really don't think this will be the usual
> case.  In most if not all packages, accounting for such misuses won't be
> required at all.  I just wanted to prove it's not an unsolvable problem.

I like this, and it gives a nice error message of deprecation, and I
think that is good. But this is a solution which requires package
developers to explicitly support declarations of deprecation.

Just removing "food-package-1.0" from `load-path` gives a less nice
error message, but it still fails fast, and requires no developer


reply via email to

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