Kyle Meyer <k...@kyleam.com> writes:
> Bastien writes:
>
>> Kyle Meyer <k...@kyleam.com> writes:
> [...]
>
>>> Every spot that calls org-assert-version is preceded by a line that
>>> requires org-macs, so isn't this error likely due to a mixed
>>> installation/load-path issue where the wrong/older org-macs is taking
>>> precedence?
>>
>> Yes: I thought `org-assert-version' job was to help catching mixed
>> installations, so my reasoning was that, even when an old org-macs
>> version has been loaded, autoloading `org-assert-version' would help
>> report about mixed installation.
>
> I see. So your goal isn't to resolve any errors due to mixed
> installation but instead to get the more informative error message from
> org-assert-version?
>
> I don't think autoloading will help because it will look in the
> org-macs file at the front of the load-path, and, in the bad case, that
> does not have the org-assert-version definition.
Question: which end of load-path is "front" if you look at load-path via
describe-variable? It's been far too long since my days of Elisp
hacking.
Another typical use case is Org bundled with Emacs and you want to
install a later version of Org via package-install.
>> That said, do you have any idea how to fix the bug people encounter
>> when installing Org from ELPA and being bitten by "invalid-function
>> org-assert-version"?
>
> Sorry, I don't. Given a mixed installation where the org-macs at the
> front of load-path does _not_ have org-assert-version, I don't see a way
> to catch that. Not helpful at the moment, but I suppose the situation
> improves with time as Org versions that do not have org-assert-version
> become less abundant.
Is Org the only thing that will call 'org-assert-version'? Then assume
that a pre-built version of Emacs/Org is self-consistent. Then
(perhaps?) patch an early spot in Org-9.6 to do:
(if (and (featurep 'org) (< org-version 9.6))
(unload-feature 'org))
--
David Masterson
