bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#40838: 28.0.50; [feature/native-comp] Function overrides in init.el


From: Andrea Corallo
Subject: bug#40838: 28.0.50; [feature/native-comp] Function overrides in init.el are not honored after deferred compilation
Date: Mon, 18 May 2020 20:15:31 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Ihor Radchenko <yantar92@gmail.com> writes:

>> thanks this is appreciated because I haven't managed to reproduce it
>> myself.
>
> Finally, I found some reproducible example.
> straight.el redefines some org functions before loading org.
> It is done in straight--fix-org-function (org-git-version and
> org-release are redefined). 
> The redefined version works with org.elc, but somehow get overridden
> when org.eln is loaded (in my case, the loading is triggered by elfeed-org).
>
> Steps to reproduce:
>
> 1. Use the attached file to load emacs. No errors should appear.
> 2. Wait until org is native-compiled.
> 3. Restart emacs. The following errors appears
> (straight--fix-org-function supposed to be a workaround for this error):
>
> Error (use-package): elfeed-org/:catch: Invalid version syntax: ‘N/A’
> (must start with a number)
>
> 4. Delete org.eln
> 5. Restart emacs. The error disappears.

Okay I think I've an idea of what is going on here.

straight given wants to build org in a way org is not made for is
hacking around the problem predefining in the compilation environment
`org-release' and `org-git-version'.

When org.el is loaded is executing at top level the expansion of
`org-check-version' that is supposed to define these two functions,
given are already defined by straight.el we should fall in the first if
clause an the hacked functions remains.

When the eln are compiled by deferred-compilation no-one is hacking the
definition of these two functions in the way straight.el would like and
so the trouble raise.

In summary this is not a problem of the deferred compilation mechanism
but is an hack that is not working for this case.

To mitigate this I've added a new customize you can use to define those
functions (or whatever) into the compiler environment of the async
compilation workers, is called `comp-async-env-modifier-form'.

2ac6194585 * Add new customize `comp-async-env-modifier-form' (Bug#40838)

I'm for closing this.

Bests

  Andrea

-- 
akrl@sdf.org





reply via email to

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