Ihor Radchenko writes:
> 1. emacs -Q
> 2. M-x org-version (built-in)
> 3. M-: (push "/path/to/git/version/of/org/lisp" load-path)
> 4. M-x org-mode
> 5. Observe recursive loading error
... which is also happening with the other approach using (provide
'org-foo-9.7-pre)
progn: Recursive load:
Stefan Monnier writes:
But then it will not run during byte-compilation.
>>> Yeah, I was assuming that you had replaced all `require`s with
>>> `org-require-with-shadowcheck`, but that's probably not what you'd done.
>> That's exactly what I have done.
>
> Ah. The issue comes from the fact
>>> But then it will not run during byte-compilation.
>> Yeah, I was assuming that you had replaced all `require`s with
>> `org-require-with-shadowcheck`, but that's probably not what you'd done.
> That's exactly what I have done.
Ah. The issue comes from the fact that `require` is treated
Stefan Monnier writes:
>> But then it will not run during byte-compilation.
>
> Yeah, I was assuming that you had replaced all `require`s with
> `org-require-with-shadowcheck`, but that's probably not what you'd done.
That's exactly what I have done.
> Not knowing what you had done (beside
>> For this one I can see the problem. You define:
>>
>> (defmacro org-require-with-shadowcheck (feature)
>> [...]
>> `(eval-and-compile ...))
>>
>> so it will behave like a function, except that it's also
>> executed during macroexpansion, so the (require 'org-element) within
>>
Stefan Monnier writes:
>> My attempt to use shadowcheck idea you proposed failed with some very
>> strange errors and I gave up.
>> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311
>
> For this one I can see the problem. You define:
>
> (defmacro org-require-with-shadowcheck
Max Nikulin writes:
> On 16/08/2023 18:08, Ihor Radchenko wrote:
>> Every library will have
>>
>> (require 'org-foo-9.X "org-foo")
>> (require 'org-bar-9.X "org-bar")
>> ...
>> (provide 'org-lib)
>> (provide 'org-lib-9.X)
>
> Are you going to update patch version of particular library on each
On 16/08/2023 18:08, Ihor Radchenko wrote:
Every library will have
(require 'org-foo-9.X "org-foo")
(require 'org-bar-9.X "org-bar")
...
(provide 'org-lib)
(provide 'org-lib-9.X)
Are you going to update patch version of particular library on each
change of macro definitions?
> My attempt to use shadowcheck idea you proposed failed with some very
> strange errors and I gave up.
> See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#311
For this one I can see the problem. You define:
(defmacro org-require-with-shadowcheck (feature)
[...]
Stefan Monnier writes:
>> After trying several more approaches,
>
> [ Side note: did you keep notes about the various approaches you tried
> and their respective downsides? E.g. I'm curious what were the
> problems linked to my proposal of using a `require-with-check` like
> the one below
Ihor Radchenko [2023-08-16 11:08:15] wrote:
> Ihor Radchenko writes:
>> Stefan Monnier writes:
>>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>>> from the new version the already loaded files from the old version.
>>> It suffers from a different set of problem :-(
Ihor Radchenko writes:
> Stefan Monnier writes:
>
>> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
>> from the new version the already loaded files from the old version.
>> It suffers from a different set of problem :-(
>> [ I suspect `defvar` is the main problem for
Stefan Monnier writes:
> BTW, rather than unloading, `package.el` relies on forcibly "re"loading
> from the new version the already loaded files from the old version.
> It suffers from a different set of problem :-(
> [ I suspect `defvar` is the main problem for that solution. ]
Could it be
> when using unload-feature), so yes, ideally Emacs would make it
> possible to have multiple versions of the same package.
Having multiple versions *installed* has been supported since "for ever"
(AFAIK support for that was added very early in `package.el`s life,
before Emacs-24.1).
Having
Hi Ihor,
I have been able to use `unload-feature' (with some additional
hackery) to get things working. It is not a pretty sight (there are a
bunch of pitfalls and unexpected side-effects that are likely bugs
when using unload-feature), so yes, ideally Emacs would make it
possible to have
Tom Gillespie writes:
> Without going into too much detail, an orgstrap shebang block is
> forced to use the system installed version of org because it is
> intended to work in the absence of an init.el file, or before an
> init.el file can ever be loaded.
Once you load built-in Org partially,
Sorry to be so late chiming in here. I've only now encountered this
due to the 9.6 release. In short, org-assert-version is an absolute
disaster for me.
At the very least org-assert-version should be non-fatal by default.
Without going into too much detail, an orgstrap shebang block is
forced to
>> It should not be necessary and it does not happen on my side (as you can
> >> imagine, I re-compile very often).
> >
> > Perhap's my issue stems from the particular versions of org I was upgrading
> > between and/or (earlier) poor management of multiple contending org
> > versions (e.g. git
"Cook, Malcolm" writes:
>> It should not be necessary and it does not happen on my side (as you can
>> imagine, I re-compile very often).
>
> Perhap's my issue stems from the particular versions of org I was upgrading
> between and/or (earlier) poor management of multiple contending org
> > Then, when I occasionally wished to update org, I would
> >
> > `cd ~/.emacs.d/org-mode && git pull && make autoloads && make`
> >
> > Recently I started getting errors invalid-function "org-assert-version".
> >
> > Upon cursory reading of this thread I guessed that I could fix them by
> >
"Cook, Malcolm" writes:
> Then, when I occasionally wished to update org, I would
>
> `cd ~/.emacs.d/org-mode && git pull && make autoloads && make`
>
> Recently I started getting errors invalid-function "org-assert-version".
>
> Upon cursory reading of this thread I guessed that I could fix
"Cook, Malcolm" writes:
> Hello,
>
> I found this recent thread researching why my strategy for staying abreast
> with org head had started failing with invalid-function
> "org-assert-version"
>
> My strategy had been to build org initially with
>
> ` cd ~/.emacs.d && git clone
>
> Malcolm,
> I also ran into troubles which are similar, apparently due to mixed org-mode
> versions; we've got to load org-mode before emacs tries to do it for us or we
> get mixed stuff.
Thanks Daniel, yes, I understand the need to load org early, and am sure that
my approach succeeds in
Malcolm,
I also ran into troubles which are similar, apparently due to mixed
org-mode versions; we've got to load org-mode before emacs tries to do
it for us or we get mixed stuff.
My resolution was to load the org-mode path first in my init.el file and
then require org:
(add-to-list
Hello,
I found this recent thread researching why my strategy for staying abreast with
org head had started failing with invalid-function "org-assert-version"
My strategy had been to build org initially with
` cd ~/.emacs.d && git clone
https://git.savannah.gnu.org/git/emacs/org-mode.git &&
Ihor Radchenko writes:
> Done now.
Thanks!
--
Bastien
Bastien writes:
> Ihor Radchenko writes:
>
>> Then, I am inclined towards easing the version check to (org-version)
>> instead of (org-git-version).
>
> FWIW strong +1 here.
Done now.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=73f25bba8ffb9fe434486832c6acb98794dd2e69
Note
Bastien writes:
> Still, "Org mode version 9.6-pre (...)" is more accurate IMO.
Ok.
Pushed the patch + version change onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c29d3e997d703f6bf14db559e351729cc25e4f26
Ihor Radchenko writes:
> One valid option is 9.6-pre
Let's go for this one. I've add a note about our conventions for the
;; Version header in https://orgmode.org/worg/org-maintenance.html
--
Bastien
Ihor Radchenko writes:
> Also, they are used by Makefile to generate orgcard.tex
> We need to be careful in this area.
Yes...
> Note that in
> Org mode version 9.6 (release_9.5.5-830-g77f9e1 @ [load-path])
>
> release_9.5.5 while version is 9.6
> I feel like you missed this detail.
Yes I did
Bastien writes:
>> The code I quoted explicitly removes the "-dev" part. Would you prefer
>> to keep it?
>
> Yes, let's keep it, otherwise (org-release) reads like a lie.
>
> Why is it necessary to emit org-version.el?
>
> We could have (defun org-version ...) and (defun org-git-version ...)
>
Bastien writes:
>> The code I quoted explicitly removes the "-dev" part. Would you prefer
>> to keep it?
>
> Yes, let's keep it, otherwise (org-release) reads like a lie.
Note that 9.6-dev is not a valid package version string.
See `version-to-list'.
One valid option is 9.6-pre
--
Ihor
Ihor Radchenko writes:
> I think that it will still be useful. In particular, consider major new
> feature development. We may take a longer delay between releases then.
Yes.
> The code I quoted explicitly removes the "-dev" part. Would you prefer
> to keep it?
Yes, let's keep it, otherwise
Bastien writes:
> Ihor Radchenko writes:
>
>> org-git-version is very useful when people report bugs.
>> M-x org-submit-bug-report supplies org-git-version output for bug
>> subject. Thus, we can easily check which git commit their build
>> corresponds to.
>
> Let's keep `org-git-version'. If
Ihor Radchenko writes:
> org-git-version is very useful when people report bugs.
> M-x org-submit-bug-report supplies org-git-version output for bug
> subject. Thus, we can easily check which git commit their build
> corresponds to.
Let's keep `org-git-version'. If we manage to release Org
Bastien writes:
>> Should we use the next planned release version number on main branch as
>> a convention?
>
> I'd rather use the value set in the ";; Version:" header.
>
> It is "9.5.5" in the bugfix branch and "9.6-dev" on the main branch.
Makes sense.
> I'm not even sure we should keep
Ihor Radchenko writes:
> Currently, main and bugfix branches both have (org-version) ; => "9.5.5"
> As a result, the assertion will not catch the important case when users
> mix Org version installed via package.el and Org version installed from
> git.
>
> Should we use the next planned release
Hi Ihor,
> Should we use the next planned release version number on main branch as
> a convention?
For what it’s worth, in my own build of Org I set `org-release' to
`MAJOR.(MINOR+1).0', e.g. when the last tag is `9.5.5' I set `org-release' to
`9.6.0'.
The `.0' suffix serves to differentiate
Bastien writes:
> Ihor Radchenko writes:
>
>> Then, I am inclined towards easing the version check to (org-version)
>> instead of (org-git-version).
>
> FWIW strong +1 here.
There is one more concern we may need to solve prior to changing
org-git-version to org-version.
Currently, main and
Ihor Radchenko writes:
> Then, I am inclined towards easing the version check to (org-version)
> instead of (org-git-version).
FWIW strong +1 here.
--
Bastien
Stefan Monnier writes:
>>> In my book step 3 above is a mistake (even if moved to step 2).
>> I am confused.
>> AFAIK, changing the load-path is a common way for users to install
>> packages manually.
>
> No, you're not confused, I just think that installing packages manually
> (including
>> In my book step 3 above is a mistake (even if moved to step 2).
> I am confused.
> AFAIK, changing the load-path is a common way for users to install
> packages manually.
No, you're not confused, I just think that installing packages manually
(including messing with `load-path` and writing
Stefan Monnier writes:
>>> Yup. But there's no option to automatically find those dependencies in
>>> ELisp, and (IIRC from last time I looked at it, in many packages obeying
>>> such dependencies would end up introducing circular dependencies in
>>> the Makefile), so we'd have to depend on the
>> Yup. But there's no option to automatically find those dependencies in
>> ELisp, and (IIRC from last time I looked at it, in many packages obeying
>> such dependencies would end up introducing circular dependencies in
>> the Makefile), so we'd have to depend on the package's author to provide
Stefan Monnier writes:
>>> - git pull => switches to 9.5.5, but several .el files are left unchanged.
>>> - make autoloads => this refreshes the autoloads, but the .elc files
>>> of those .el files which didn't change still won't be recompiled.
>>
>> Isn't it a bug in the elpa scripts
>> - git pull => switches to 9.5.5, but several .el files are left unchanged.
>> - make autoloads => this refreshes the autoloads, but the .elc files
>> of those .el files which didn't change still won't be recompiled.
>
> Isn't it a bug in the elpa scripts then?
> If a macro definition is
Stefan Monnier writes:
>> Does it help if you run make autoloads after git fetch?
>
> Not that I can tell, no. But note that I'm not using Org's makefile to
> compile the files, I'm using the elpa.git scripts instead, which don't
> take into account dependencies between files.
>
> So the
Ihor Radchenko [2022-09-13 09:52:37] wrote:
> Stefan Monnier writes:
>> I can see the reason for this macro, and I don't really have a better
>> solution to offer, but as someone who has a Git clone of Org that is
>> regularly updated using (basically) the normal compilation
>> system used in
Hi Ihor and Stefan,
Considering the separate cases of:
• Installing an Org version different to the bundled Org
• Having a development Org version with some slightly-out-of-date cache/autoload
files.
I’d think the second case has a dramatically reduced chance of issues. Could it
be reasonable
Stefan Monnier writes:
> I can see the reason for this macro, and I don't really have a better
> solution to offer, but as someone who has a Git clone of Org that is
> regularly updated using (basically) the normal compilation
> system used in Emacs (i.e. not systematically recompiling all the
I can see the reason for this macro, and I don't really have a better
solution to offer, but as someone who has a Git clone of Org that is
regularly updated using (basically) the normal compilation
system used in Emacs (i.e. not systematically recompiling all the files,
but only those whose `.el`
51 matches
Mail list logo
