Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Ihor Radchenko <yantar92@gmail.com> writes:

> Allen Li <darkfeline@felesatra.moe> writes:
>
>>> I agree. The question is whether changing to
>>> (defvar org-id-link-to-org-use-id)
>>> solves your problem.
>>
>> Thanks for your concern.  By editing ob-tangle.el, I can confirm that
>> changing this does solve my problem.
>>
>> If I must, I could provide a reproducible example, but I feel like
>> that costs unnecessary effort on the part of everyone involved if we
>> agree on the above point.
>
> Let me clarify what I am worrying about.
> We have 132 occurrences of (defvar foo nil) in the code.
> I am genuinely surprised that changing defvar fixed the problem for you
> and at the same time nobody reported similar issues with the other 131
> defvars. That's why I really want to get a reproducer and understand
> what is going on there. So far, I don't understand how defvar can break
> anything except in case of some strange compilation/mixed installation
> problems.

I see.  In my opinion those occurrences should be fixed even if no one
is reporting issues because it is bad/improper code, and it is not
especially surprising that no one has reported it yet; there is always a
first person who reports a bug, and there are always more old bugs to be
found in a big project like Emacs/Org mode.

This is annoying to reproduce because it relies on the normal Emacs
startup process, which loads packages.  Anyway, I have found a reproduction.

This is using the Emacs install on Arch Linux.

GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo 
version 1.17.4)
 of 2021-03-26

Have the packages org-9.5.2 and org-contrib-0.3 installed in
~/.emacs.d/elpa.  I have these installed from
https://elpa.gnu.org/packages/ and https://elpa.nongnu.org/nongnu/
respectively.

Start emacs by loading a tmp.el file with the contents provided below.

1. emacs -Q --load tmp.el
2. C-h v org-id-link-to-org-use-id

Note that the value is nil instead of the expected
'create-if-interactive

3. Press RET on the customize link.

Note that the Customize UI says "CHANGED outside Customize."

Expected behavior:

User sees org-id-link-to-org-use-id set to the value they saved in
Customize.

Personal aside:

It is easy to get subtle bugs in between autoloading, package activation
and Customize when some bit of code is not following all of the right
conventions.  I suspect most Emacs users are adding setqs to their init
file until things work.  Meanwhile I foolishly read and follow all of
the conventions and thus I make the above claim ("It is easy to get
subtle bugs...") from my experience running into other bugs like this one.
Hence my stance on fixing the aforementioned 132 occurrences, lest they
cause yet another subtle bug later on.

;; tmp.el starts here.

;; This is usually called by Emacs before loading init.el.
;; It is skipped when using -Q so we call it manually.
;; 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Startup-Summary.html
(package-activate-all)

;; This is added to init.el and is the standard way user
;; customizations are saved/loaded.
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(org-id-link-to-org-use-id 'create-if-interactive)
 '(org-babel-load-languages '((emacs-lisp . t) (python . t) (shell . t))))

;; tmp.el ends here.