[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el
From: |
Max Nikulin |
Subject: |
Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el |
Date: |
Sun, 2 Apr 2023 22:59:51 +0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 |
On 02/04/2023 15:35, Ihor Radchenko wrote:
I was able to reproduce on Debian using virtual machine.
To be precise, I am surprised that you are unable to reproduce the issue
with older Emacs version compiled from source.
Does it mean that you are able to?
I reproduced the issue with packages available in Debian and Ubuntu,
including -Q, so minimally affected by distribution-specific
configuration, but I have not tried to compile Emacs myself. I am
judging from changes in Emacs code made after release of version 28.
I only tried on Gentoo, because my Debian-foo is not good enough to hunt
all the required compile-time dependencies for Emacs.
apt build-dep emacs
and perhaps "apt install" for some …-dev packages for new features.
However my surprise is namely dependence on specific
packaging/distribution. My expectation that it should be reproducible in
Gentoo as well.
https://old.reddit.com/r/orgmode/comments/123qnqq/workaround_for_orgassertversion_problem_not/
I have no clue why your patch should help in this case.
It won't, but the very reason that message appeared is the need to do
that awkward workaround. It must not be needed - we are causing way too
much inconvenience to users of Emacs versions we claim to support.
Either I missed your point or the issue will be just postponed. Patched
variant will not prevent mixed version compilation, so users still may
experience calls of undefined functions or incompatible argument types.
I am in doubts if emacs version should be checked or it should be e.g.
(fboundp 'org-assert-version).
It is indeed a cleaner approach.
I am not sure. Perhaps it should be (or (fboundp 'org-assert-version)
(new-package-management-code)). Since testing for private function is
not a reliable solution, only version check is available.
May you elaborate?
I do not think it is good idea to rely on
(or (fboundp 'org-assert-version)
(fboundp 'package--reload-previously-loaded))
I have not checked if some public function may be used for feature
detection of code appeared in Emacs-29. That is why I would consider
(when (or (fboundb 'org-assert-version)
(version<= "29" emacs-version))
(org-assert-version))
However I am still in doubts if it is improvement in comparison to
simple (org-assert-verions) without any conditions.