On 10/04/2023 23:58, Ihor Radchenko wrote:
Max Nikulin writes:
Currently I do not understand:
- Why presence of .el files in the same directory (old Org version) with
.elc files affects result of compilation (at least for Emacs-28)?
I may be missing your point, but `load-prefer-newer' maybe?
Max Nikulin writes:
>> What about creating org-assert-version.el file that will contain
>> something like
>>
>> (if (fboundp 'org-assert-version)
>> (org-assert-version)
>> (warn ""))
>>
>> Then, instead of (org-assert-version) call, we can put
>> (load "org-assert-version.el") in Org
On 09/04/2023 15:29, Ihor Radchenko wrote:
Max Nikulin writes:
I would consider adding to ELPA README and Org manual something like:
If compiling of ELPA packages causes a lot of warnings related to
`org-assert-version' then delete just installed Org package, start new
Emacs session ensuring
Max Nikulin writes:
> I would consider adding to ELPA README and Org manual something like:
>
> If compiling of ELPA packages causes a lot of warnings related to
> `org-assert-version' then delete just installed Org package, start new
> Emacs session ensuring that Org is not loaded (-q?) and
On 29/03/2023 23:52, Ihor Radchenko wrote:
I was able to reproduce on Debian using virtual machine.
Also, several people were able to reproduce in Matrix when I asked them.
And we got one report from Fedora user. + Several from Ubuntu users.
Recently, there was also
Ihor, I am sorry, but I sent this message off-list at first.
On 04/04/2023 20:29, Ihor Radchenko wrote:
Sure. Anything Emacs devs can act on. If you can prove that the problem
is in Emacs source code, we can report it in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882 and let Emacs devs
Max Nikulin writes:
> On 02/04/2023 23:44, Ihor Radchenko wrote:
>> 1. The old problem with mixed installation that manifests itself for
>> some users
>> 2. The new problem with org-assert-version, which appears to be even
>> more frequent, despite trying preventing (1).
>
> I leave
On 02/04/2023 23:44, Ihor Radchenko wrote:
1. The old problem with mixed installation that manifests itself for
some users
2. The new problem with org-assert-version, which appears to be even
more frequent, despite trying preventing (1).
I leave decision up to you. My opinion that both
Max Nikulin writes:
>> 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
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
Max Nikulin writes:
>> 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 only tried on Gentoo, because my Debian-foo is not
On 29/03/2023 23:52, Ihor Radchenko wrote:
Max Nikulin writes:
Sorry, I have not tried to compile Emacs myself and I am really puzzled
why you was not able to reproduce the issue.
I was able to reproduce on Debian using virtual machine.
To be precise, I am surprised that you are unable to
Max Nikulin writes:
> On 29/03/2023 20:38, Ihor Radchenko wrote:
>> Even though we identified that the problem is related to a combination
>> of old Emacs version and OS-specific Emacs customization
>
> Ihor, who should notice improvement due to this patch? Is it related to
> Emacs-29.1
On 29/03/2023 20:38, Ihor Radchenko wrote:
Even though we identified that the problem is related to a combination
of old Emacs version and OS-specific Emacs customization
Ihor, who should notice improvement due to this patch? Is it related to
Emacs-29.1 release? The issue is weird, but on the
Bastien writes:
> 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"?
Even though we identified that the problem is related to a combination
of old Emacs version and OS-specific Emacs
On 07/12/2022 18:43, Ihor Radchenko wrote:
That said, I find David Masterson's suggestion promising:
(if (and (featurep 'org) (< org-version 9.6))
`version<'?
Mixed install may be still a problem in the case of bug fix ("patch"
component of the version) release.
Bastien writes:
> 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"?
I just asked Emacs devs as it does not look like we do anything wrong
here. It is probably Emacs package.el doing
writes:
> On Mon, Dec 05, 2022 at 07:54:25PM -0800, David Masterson wrote:
>
>> 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.
>
> This goes "left to right" when looking at it on a
On Mon, Dec 05, 2022 at 07:54:25PM -0800, David Masterson wrote:
[...]
> 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.
This goes "left to right" when looking at it on a conventional
Kyle Meyer writes:
> Bastien writes:
>
>> Kyle Meyer 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
>>>
Kyle Meyer writes:
> Bastien writes:
>
>> Some users reported an (invalid-function org-assert-version) error
>> when installing Org from ELPA:
>>
>> https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
>>
Bastien writes:
> Kyle Meyer 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
Kyle Meyer writes:
>> This patch autoloads `org-assert-version'.
>
> I don't understand the rationale behind this.
It was my naive attempt at fixing the "invalid-function
org-assert-version" error several people reported.
> Every spot that calls
> org-assert-version is preceded by a line
Bastien writes:
> Some users reported an (invalid-function org-assert-version) error
> when installing Org from ELPA:
>
> https://lists.sr.ht/~bzg/emacsfr/%3Cd091463e1615422eb00070727d6a094ec0ae3c73.camel%40adocentyn.io%3E
>
24 matches
Mail list logo
