emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el
Date: Sun, 2 Apr 2023 22:59:51 +0700	[thread overview]
Message-ID: <u0c8pp$lh1$1@ciao.gmane.io> (raw)
In-Reply-To: <87mt3qn0lb.fsf@localhost>

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))

However I am still in doubts if it is improvement in comparison to 
simple (org-assert-verions) without any conditions.

  reply	other threads:[~2023-04-02 16:02 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01  7:26 [PATCH] Autoload `org-assert-version' and remove org-loaddefs.el Bastien
2022-12-02  3:38 ` Kyle Meyer
2022-12-02  7:44   ` Bastien
2022-12-03  4:18     ` Kyle Meyer
2022-12-06  3:54       ` David Masterson
2022-12-06  5:44         ` tomas
2022-12-06  7:13           ` David Masterson
2022-12-07 11:43     ` Ihor Radchenko
2022-12-07 14:08       ` Max Nikulin
2023-03-29 13:38     ` Ihor Radchenko
2023-03-29 16:04       ` Max Nikulin
2023-03-29 16:52         ` Ihor Radchenko
2023-04-01 14:44           ` Max Nikulin
2023-04-02  8:35             ` Ihor Radchenko
2023-04-02 15:59               ` Max Nikulin [this message]
2023-04-02 16:44                 ` Ihor Radchenko
2023-04-04 12:08                   ` Max Nikulin
2023-04-04 13:29                     ` Ihor Radchenko
2023-04-05 11:41                       ` Max Nikulin
2023-04-08 16:47           ` Max Nikulin
2023-04-09  8:29             ` Ihor Radchenko
2023-04-10  6:13               ` Max Nikulin
2023-04-10 16:58                 ` Ihor Radchenko
2023-06-04 10:58                   ` Max Nikulin
2022-12-06  3:00   ` David Masterson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='u0c8pp$lh1$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).