Ihor Radchenko writes: >> 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'. > > If this is what is happening with straight.el, then my recipe is not > actually reproducing my initial bug report. I have other cases when > functions redefined in my config are overridden by initial definition > when .eln is loaded. I think that I still need to investigate for a real > recipe then. > > Best, > Ihor > > > Andrea Corallo writes: > >> Ihor Radchenko 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 > > -- > Ihor Radchenko, > PhD, > Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) > State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China > Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg