>>>>> Max Nikulin <maniku...@gmail.com> writes:
> On 21/04/2023 23:17, Colin Baxter wrote:
>> I will address the other points in your reply the next time I
>> update org-mode. In the meantime, I can answer some of your other
>> questions immediately.
> Thanks for info. I have asked for org git branch. I am almost sure
> it is main, but to be sure
> git -C ~/git/org-mode branch --show-current git -C
> ~/git/org-mode describe
main
> If the issue was caused by specific order of file changes, even in
> the current state output of the following command may be used for
> attempt to replay updates by git checkout + make
> git -C ~/git/org-mode reflog --max-count 20
f81ba451a (HEAD -> main, origin/main, origin/HEAD) HEAD@{0}: pull --stat:
Fast-forward
3c449cc43 HEAD@{1}: pull: Fast-forward
4929f0c55 HEAD@{2}: pull: Fast-forward
f4446ce79 HEAD@{3}: pull: Fast-forward
7c8623be9 HEAD@{4}: clone: from
https://git.savannah.gnu.org/git/emacs/org-mode.git
> I assume you build it yourself. Do you run emacs binary from
> source+build tree or from install tree (make install)?
>From a local install-tree.
> The latter
> has .el.gz files instead of .el, and at least in Emacs-28 it
> affects behavior of compilation of ELPA packages by package.el.
> Another point is that the origin of your issue might be in
> built-in version of Org. It has `org-assert-version' as
> well. Perhaps there is a bug in make rules for Org in Emacs
> tree. Could you, please, try the following for your *current*
> emacs build?
> emacs -Q -l org-agenda
Only message and scratch buffers present.
>> 1. emacs <RET>
> Till `org-reload' C-c C-x ! at the step 10 org is not
> involved. Does you init file loads some Org component or some Org
> buffer is created at startup? To be sure
> M-: (featurep 'org)
"No match."
This figures since loading org-mode is only the second load-path
adjustment done by my ~/.emacs. The first is setting the path to
slime. All other load-path adjustments, such as other org-mode
application libraries come later after org-mode itself.
> I assume that ~/git/org-mode/lisp is added to `load-path' in your
> init file.
Yes, via (add-to-list 'load-path (expand-file-name "~/git/org-mode/lisp"))
>> 2. M-x vc-dir <RET> 3. Navigate to ~/git/org-mode. 4. + (to
>> pull) 5. M-x compile <RET> 6. make clean <RET> 7. make <RET>
> I am sorry for my ignorance, I usually run make from a terminal
> independent of emacs. Doesn't M-x compile runs make, so I expect
> it is the same as
In the case of build org-mode, I first select "make clean" from the
history of "M-x compile". Then I do "M-x compile" again and select "make"
from the history. The effect is the same using the terminal, except the
outputs are now contained in emacs buffers.
> make; make clean; make
> and it is a bit strange for me.
>> 8. In an eshell buffer navigate to ~/git/emacs/lisp.
>> Typo! I meant navigate to ~/git/org-mode/lisp.
>> 9. rm *.elc <RET>
> Why did you decided to manually delete *.elc files? I have lost at
> which step you got the warning. I expect that "make clean" should
> remove .elc files.
If I don't delete the elc files in ~/git/org-mode/lisp after the first
build then I do get errors. I find that a running emacs-session at this
stage of the process is happy to load new org-mode .el files but not
.elc files. I then repeat "make clean" and "make". Now the running emacs
will load the .elc files and complete the update.
>> 10. Open any org-mode file or buffer and do C-c C-x !
> `org-reload' immediately after removing of .elc files sounds
> strange for me. At least since previous command was "make", not
> "make clean", org-loaddefs.el should exist at this moment, so
> uncompiled version should be loaded, but prefix argument should be
> used to load Org uncompiled
> C-u C-c C-x !
> If org has not been loaded before the step 10, then `org-reload'
> should-not be necessary at all.
>> 11. Return to vc-dir or eshell 12. make clean <RET> 13. make
>> <RET> 15. Return to org-mode buffer and do C-c C-x ! again.
>> 16. Update complete, usually with no warnings or errors.
> Is org-loaddefs loaded from ~/git/org-mode/lisp? It is a sanity
> check for working Org and more interesting when it is broken.
I think it must be because ~/git/org-mode/ is the first org-mode found
and not the org-mode within emacs itself. How can I check?
> emacs -Q -L ~/git/org-mode/lisp -l org-agenda
> is not affected, so the problem is solely with reloading of
> updated version without emacs restart.
Ok. I will do that.
Colin.
