bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
"Berry, Charles" writes:
> Rudy,
>
> Thanks for the comment, but ...
>
>> On Dec 25, 2021, at 1:37 PM, Rudolf Adamkovič wrote:
>>
>> I think we look at the problem from two different perspectives. You
>> look at the problem from the "how" perspective, whereas I look at it
>> from the "why" perspective. Sure, we can work around everything in
>> Org. Now, does that mean that Org should try to execute BibTeX
>> blocks when executing a buffer? I do not think so.
>
> Using standard features (properties, header-args) in a standard way
> does not strike me as a `work around'.
I apologize for the lack of clarity. I used the term "workaround" from
the perspective of a user, who probably does not expect Org to try
"execute BibTeX" ever.
> You have not made a clear case that src blocks are even needed to
> support your use case. It may well be that export blocks (which never
> execute) would work just as well. But with no ECM, one can only
> guess.
True that, I did not include an example! Below, I include a typical use
case: Org notes about an article with a corresponding BibTeX entry.
(Note: I do not know what ECM stands for.)
[…]
#+property: header-args+ :comments link
#+cite_export: csl apa.csl
* Notes
[…]
* References
#+print_bibliography:
* Sources
#+begin_src bibtex :tangle knuth+2021.bib
@Article{knuth+2021,
author = {Knuth, Donald E. and Shustek, Len},
title= {Let's Not Dumb down the History of Computer Science},
journal = {Communications of the {ACM}},
year = 2021,
volume = 64,
number = 2,
pages= {33–35},
month= {jan},
issue_date = {February 2021},
publisher= {Association for Computing Machinery, {ACM}},
issn = {0001-0782},
doi = {10.1145/3442377},
abstract = {Donald Knuth on the best way to recognize the history
of computer science.},
numpages = 3
}
#+end_src
> I'm still inclined to call this a feature request, not a bug. And
> decisions about adding complexity to an already complicated code base
> should take that point of view, IMO.
Sure. As a user, I can see it as both a bug, where Org tries to execute
BibTeX, but also as a feature, where Org needs to become smarter and
differentiate BibTeX from, say, Scheme or C.
Rudy
--
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place." -- Immanuel
Kant, 1785
Rudolf Adamkovič [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
Bug report: org-preview-latex fails when using tramp
Hello, Since the instructions say that bugs should be reported on the mailing list, I do so here. When visiting a file by tramp over ssh, doing latex preview fails. * Version Tag 9.4.6 (commit:652430128) * To reproduce: Create the following org file: #+begin_example * Testing formulas \[\xi^2+\chi^2\] #+end_example and invoke =org-latex-preview=. The result is that org-latex preview fails finding the temporary tex file (which was saved on the remote server) #+begin_example This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017) (preloaded format=latex) restricted \write18 enabled. entering extended mode ! I can't find file `/tmp/orgtexq5rOVI.tex'. <*> /tmp/orgtexq5rOVI.tex (Press Enter to retry, or Control-D to exit) Please type another input file name ! Emergency stop. <*> /tmp/orgtexq5rOVI.tex No pages of output. Transcript written on /tmp//texput.log. #+end_example Regards, Dov
[PATCH] Fix caption format for custom latex src block
This patch fixes an issue in which captions for custom listing
environments are not converted correctly. To illustrate the issue,
take the following MWE.
file.org:
```
#+caption: Perform inter-sample interpolation.
#+begin_src python
import numpy as np
#+end_src
```
file.el:
```
;; Loading straight isn't necessary if you don't use it, just need to
;; load org.
(load "~/.config/emacs/straight/repos/straight.el/bootstrap.el")
(straight-use-package 'org)
(find-file "file.org")
(setq org-latex-listings 'minted)
(setq org-latex-custom-lang-environments
'((python "\\begin{listing}
\\begin{minted}[%o]{python}
%s\\end{minted}
\\caption{%c}
\\label{%l}
\\end{listing}")))
(org-latex-export-to-latex)
```
Run the example with:
emacs -Q --batch -l file.el
Before the patch, you get:
```
[...]
\begin{listing}
\begin{minted}[]{python}
import numpy as np
\end{minted}
\caption{(((Perform inter-sample interpolation.)))}
\label{nil}
\end{listing}
[...]
```
After the patch, you get:
```
[...]
\begin{listing}
\begin{minted}[]{python}
import numpy as np
\end{minted}
\caption{Perform inter-sample interpolation.}
\label{nil}
\end{listing}
[...]
```
I'm not actually 100% confident that the patch is the optimal way to
do this. The API wasn't totally clear to me in this case. Any advice
here is appreciated.
Matt
From 5b0601d6d3b8034202c4b9b820c64a719e3129b9 Mon Sep 17 00:00:00 2001
From: Matt Huszagh
Date: Wed, 29 Dec 2021 19:35:42 -0800
Subject: [PATCH] ox-latex.el: Fix caption format for custom latex src block
2021-12-29 Matt Huszagh
* lisp/ox-latex.el (org-latex-src-block): Use
`org-export-get-caption' to extract caption from
element. Otherwise, the full caption contains a large number
of unnecessary parentheses.
---
lisp/ox-latex.el | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 8187119ec..a9c6a4b5c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3021,7 +3021,8 @@ contextual information."
custom-env)
(format-spec custom-env
`((?s . ,formatted-src)
- (?c . ,caption)
+ (?c . ,(org-export-data (org-export-get-caption src-block)
+ info))
(?f . ,float)
(?l . ,(org-latex--label src-block info))
(?o . ,(or (plist-get attributes :options) "")))
--
2.31.1
Re: [PATCH] update ob-scheme to latest changes in geiser package
On Wednesday, 29 December 2021 15.03.47 -03 Felipe Lema wrote:
> Sup, y'all
>
> The geiser package had a recent update in which `geiser-eval-region` behaves
> like an async function and does not return evaluation result. In exchange,
> the newly introduced `geiser-eval-region/wait` does that now.
>
> I've attached a patch to update ob-scheme.el to reflect these changes.
> Without them, evaluating scheme dialect code blocks in Org will end up with
> empty results.
>
> To learn more about the change (and how it impacted other people's flows) see
> issue thread below
>
> https://gitlab.com/emacs-geiser/geiser/-/issues/30
>
> Felipe
>
>
I was pointed out that I was missing the corresponding `declare-function`.
I've included it in the attached patch. Sorry about the double-posting
Felipe
update to new API call to evaluate region and wait for result
* ob-scheme.el replace `geiser-eval-region` with `geiser-eval-region/wait` as the former changed expected behaviour; the latter returns the result of evaluating.
diff --git a/lisp/org/ob-scheme.el b/lisp/org/ob-scheme.el
index f4836b23fe..bcceba1258 100644
--- a/lisp/org/ob-scheme.el
+++ b/lisp/org/ob-scheme.el
@@ -53,8 +53,8 @@ geiser-repl-window-allow-split
(declare-function run-geiser "ext:geiser-repl" (impl))
(declare-function geiser-mode "ext:geiser-mode" ())
-(declare-function geiser-eval-region "ext:geiser-mode"
- (start end &optional and-go raw nomsg))
+(declare-function geiser-eval-region/wait "ext:geiser-mode"
+ (start end &optional timeout))
(declare-function geiser-repl-exit "ext:geiser-repl" (&optional arg))
(declare-function geiser-eval--retort-output "ext:geiser-eval" (ret))
(declare-function geiser-eval--retort-result-str "ext:geiser-eval" (ret prefix))
@@ -176,7 +176,7 @@ org-babel-scheme-execute-with-geiser
(setq geiser-impl--implementation nil)
(let ((geiser-debug-jump-to-debug-p nil)
(geiser-debug-show-debug-p nil))
- (let ((ret (geiser-eval-region (point-min) (point-max
+ (let ((ret (geiser-eval-region/wait (point-min) (point-max
(setq result (if output
(or (geiser-eval--retort-output ret)
"Geiser Interpreter produced no output")
Re: [PATCH 2/2] ox-texinfo: Define definition commands using description lists
Hello,
Jonas Bernoulli writes:
> Would it be okay to represent e.g. "C-c SPC" as:
>
>(export-snippet
> (:back-end "texinfo" :value "@kbd{C-c @key{SPC}}" :post-blank 0 :parent
> #2))
Just use (org-export-raw-string "@kbd{C-c @key{SPC}}") instead.
> I think that is one of the things I tried that ox-texinfo insisted on
> quoting anyway. I might misremember, so I will have another look.
`org-export-raw-string' is a recent addition in Org.
> Above I suggested using an `export-snippet' element (instead of `raw');
> to me that seems appropriate too.
I think that's abusing export snippets. They are more user-oriented,
e.g. filters can apply to them.
Note you can write (org-export-raw-string (some-public-function "C-c
SPC")) where (some-public-function "C-c SPC") => "@kbd{C-c @key{SPC}}",
as done currently by the "kbd" macro.
Regards,
--
Nicolas Goaziou
Re: block folding - should this work?
Robert Nikander writes: > I started reading about “blocks" in the manual. I wanted a chunk of text that > I could hide, so I tried this: > > * Test > Some text > #+BEGIN > Hide this > #+END > > Hitting TAB on the BEGIN line does nothing. But if I add a blank line before > it, > then hitting TAB hides and shows the block. Is that a bug? Or am I doing it > wrong? Seems like it should work without the blank line. > > * Test > Some text > > #+BEGIN > Hide this > #+END > > M-x org-version => 9.5.1. The problem here is that your blocks are not correctly specified. If you run M-x org-lint on your example, it will tell you the blocks may not be correctly specified. You need to tell org what sort of block it is. Org supports a number of different block types, such as source code blocks (#+begin_src/#+end_src), example blocks (#+begin_example/#+end_example), centred blocks (#+begin_center/#+end_center) etc. You can use C-c C-, to run the command org-insert-structured-template to select the block type. If you first highlight the region, it will be wrapped in the block you select.
[BUG] org-crypt: CRYPTKEY property does not work as expected [9.5.1 (9.5.1-g36086a @ /home/ignacio/.emacs.d/elpa/org-9.5.1/)]
Hello, I think I have found a bug in org-crypt, or that org-crypt documentation is not clear enough. The following configuration snippet in the org-crypt section of the org manual, as well as the docstring for org-crypt-key, suggest that a key value of nil can be used to specify symmetric encryption: (setq org-crypt-key nil) ;; GPG key to use for encryption ;; Either the Key ID or set to nil to use symmetric encryption. The same section of the manual, and again the docstring for org-crypt-key, suggest that the value of org-crypt-key can be overridden with the CRYPTKEY property. However, if I set in my configuration org-crypt-key to nil, to use symmetric encryption by default, and try to override it in a heading setting the CRYPTKEY property to one of my keys, it still uses symmetric encryption and prompts me for a password. And if I set in my configuration org-crypt-key to one of my keys, to use it by default, and try to override it in a heading setting the CRYPTKEY property to nil to use symmetric encryption, it still uses my key and does not prompt me for a password. In both cases, if I use as key value a string that does not match any key instead of nil (e.g, the empty string ""), which also means symmetric encryption if epa-file-encrypt-to is not set according to the docstring of org-crypt-key, everything works as expected. So maybe that is the only value that should be used to specify symmetric encryption when you want to combine it with asymmetric encryption depending of the file or entry, but if that is the case I think the documentation does not insist on that fact enough. It's true that the docstring for org-crypt-key does say "If this variable is nil, always use symmetric encryption, unconditionally.", and that "unconditionally" could be interpreted as even if a CRYPTKEY property has been set, but for me that is not clear enough and I only considered that interpretation after having this issue and debugging it for a while. To exhibit the behaviour exposed, the following simple org and init files and playing around with the value of org-crypt-key suffice: Org file: * Encrypted heading 1 :crypt: :PROPERTIES: :CRYPTKEY: :END: This text should be encrypted using , regardless of the value of org-crypt-key * Encrypted heading 2 :crypt: :PROPERTIES: :CRYPTKEY: nil :END: This text should be encrypted using symmetric encryption, regardless of the value of org-crypt-key Init file: (require 'package) (package-initialize) (require 'org) (require 'org-crypt) (org-crypt-use-before-save-magic) (add-to-list 'org-tags-exclude-from-inheritance "crypt") (customize-set-variable org-crypt-disable-auto-save t) (setq org-crypt-key nil) ;; (setq org-crypt-key "") Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Package: Org mode version 9.5.1 (9.5.1-g36086a @ /home/ignacio/.emacs.d/elpa/org-9.5.1/)
Org for non-users, part 2: `C-c C-e', a.k.a. `org-export-dispatch'
Hi all, a few weeks ago I recorded a video called "Org for non-users" - link: http://angg.twu.net/2021-org-for-non-users.html that was about a way to understand some of the data structures that are used in the support for code blocks. Now I would like to do something similar with the exporter, but I am stuck at the first step... When I run `M-x org-export-dispatch' or `C-c C-e' it creates a second window whose mode line says "*Org Export Dispatcher*" - My first question is: What are the recommended ways to abort org-export-dispatch without letting it destroy the "*Org Export Dispatcher*" window and its buffer? I will probably get stuck at other points later, but I think that I'll be able to get quite far by myself if I can inspect that buffer with the tools that I know. All suggestions are welcome, including suggestions related to questions that you guess that I will have later. =) Thanks in advance! Eduardo Ochs http://angg.twu.net/#eev http://angg.twu.net/emacsconf2021.html
Re: [PATCH] ob-maxima.el: Fix execution on MS Windows
If your temporary-file-directory is something like "/tmp/apostrophe'", it would not work currently either. So apostrophe is a very special case here. As for possible evaluation within the double quotes, while this is theoretically possible, user sort of has to go out of his way to trigger it, so the question is whether we should introduce any platform-specific code to mitigate such an obscure case? Then we are also limited by Maxima itself since it has to be able to read that path too and it's very picky when it comes to file paths.
[PATCH] update ob-scheme to latest changes in geiser package
Sup, y'all
The geiser package had a recent update in which `geiser-eval-region` behaves
like an async function and does not return evaluation result. In exchange, the
newly introduced `geiser-eval-region/wait` does that now.
I've attached a patch to update ob-scheme.el to reflect these changes. Without
them, evaluating scheme dialect code blocks in Org will end up with empty
results.
To learn more about the change (and how it impacted other people's flows) see
issue thread below
https://gitlab.com/emacs-geiser/geiser/-/issues/30
Felipe
update to new API call to evaluate region and wait for result
* ob-scheme.el replace `geiser-eval-region` with `geiser-eval-region/wait` as the former changed expected behaviour; the latter returns the result of evaluating.
diff --git a/lisp/org/ob-scheme.el b/lisp/org/ob-scheme.el
index f4836b23fe..89c6abf686 100644
--- a/lisp/org/ob-scheme.el
+++ b/lisp/org/ob-scheme.el
@@ -176,7 +176,7 @@ org-babel-scheme-execute-with-geiser
(setq geiser-impl--implementation nil)
(let ((geiser-debug-jump-to-debug-p nil)
(geiser-debug-show-debug-p nil))
- (let ((ret (geiser-eval-region (point-min) (point-max
+ (let ((ret (geiser-eval-region/wait (point-min) (point-max
(setq result (if output
(or (geiser-eval--retort-output ret)
"Geiser Interpreter produced no output")
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
Max, > On Dec 29, 2021, at 4:53 AM, Max Nikulin wrote: > > On 25/12/2021 02:52, Berry, Charles wrote: >> For that case, setting buffer or heading properties, such as: >> #+begin_src org >> :PROPERTIES: >> :header-args: :eval yes :exports results >> :header-args:bibtex: :eval no >> :END: >> #+end_src >> resolves the issue. > > Chuck, is it expected that the following form to specify properties > suppresses of evaluation during export but allows execution during processing > of `org-babel-execute-buffer'? I am puzzled that behavior for property drawer > is different. > It isn't different when you have `:header-args:elisp: :eval no' in the drawer. I get the message `Evaluation of this elisp code block is disabled.' either way. Caveat: I am running release_9.5.1-233-ged5335. But a couple of things: 1) Be sure to refresh when introducing `#+property' lines. If you paste in a property line and then org-babel-execute-src-block, the property will not be acknowledged. AFAICS, property drawers do not suffer from this. 2) Property drawers only affect the heading under which they are placed unless placed at the top of the file. And either way, it is an error to insert a blank line above a property drawer. org-lint will complain although the message may be cryptic. 3) You probably know this, but exports use `org-babel-exp-process-buffer' which may perform differently than `org-babel-execute-buffer'. > >8 > #+property: header-args :eval yes :exports both > #+property: header-args:elisp :eval no > > #+begin_src elisp > (message "From elisp") > #+end_src > 8< HTH, Chuck
Re: [PATCH] ob-maxima.el: Fix execution on MS Windows
On 27/12/2021 03:18, Nikolay Kudryavtsev wrote: Ob-maxima currently does not work on Windows due to it using single quotes in the Maxima invocation and those not being supported by Windows CMD. After some testing I've found an invocation that seems to work fine on both Windows and Linux. I don't think this patch can cause any real issue, since the string in those quotes is just the temp file path. --- a/lisp/ob-maxima.el +++ b/lisp/ob-maxima.el @@ -77,7 +77,7 @@ This function is called by `org-babel-execute-src-block'." (result (let* ((cmdline (or (cdr (assq :cmdline params)) "")) (in-file (org-babel-temp-file "maxima-" ".max")) - (cmd (format "%s --very-quiet -r 'batchload(%S)$' %s" + (cmd (format "%s --very-quiet -r \"batchload(\\\"%S\\\")\"$ %s" org-babel-maxima-command in-file cmdline))) I do not like original variant, but suggested change makes it unsafe in more cases. `in-file' might contain apostrophe in the case of peculiar path of the directory for temporary files. More characters may be interpreted by BASH inside double quotes. Even docstring for `shell-quote-argument' mentions security issues with the function. Ideally command arguments should be passed as a list to avoid intermediate interpretation by shell at all. Unfortunately gluing strings to make a shell command is used too widely in org code and emacs API encourages such unsafe way.
Re: C-c C-, in a terminal?
On 28/12/2021 15:25, Anssi Saari wrote: As C-, isn't usually a control character in a terminal, terminals send just the comma if I hit C-,. Some terminals (at least wsltty) do send some kind of control sequence but I don't know if mapping other terminals to do the same (Konsole and urxvt at least) and changing the keys for Emacs makes sense. I'd have to do it for every terminal I ever use. I have never tried recipes that deals with features of modern terminal emulators. Alternatively, any suggestions for a more terminal friendly key combination for org-insert-structure-template in Emacs? You may try old method (require 'org-tempo) < s TAB instead.
(ledger?) The fair Christmas problem: splitting expenses automatically
Hi I am not sure whether this is the right place to ask this, but anyhow. Suppose two friends want to buy Christmas presents, but when they have finished, they want to have spent the same amount of money. If they don't a compensation must be transferred. Here is an example ** Start #+name: presents #+begin_src ledger 2010/01/01 * Starting balance assets:bank:savings 0 income:starting balances 2021/12/01 User1:Jacket expenses:User1:Jacket 80 income:User1:creditcard1 2010/07/24 User1:Pajama expenses:User1:Pajama 30 income:User1:creditcard1 2010/07/23 User2:Flowers expenses:User2:Flowers 20 income:User2:creditcard2 2010/07/23 User2:ChristmasTree expenses:User2:ChristmasTree 40.00 income:User2:creditcard2 #+end_src #+RESULTS: presents #+begin_example 170 expenses 110User1 80 Jacket 30 Pajama 60User2 40 ChristmasTree 20 Flowers -170 income -110User1:creditcard1 -60User2:creditcard2 0 #+end_example So user1 spent 110, while user2 spent 60 ** Compensation manually So the compensation is (trivally) | User1 | User2 | User2-->Uwer1 | |---+---+---| | 110 |60 | -25 | #+TBLFM: $3=($2-$1)/2;f2 Leading to #+name: compensated #+begin_src ledger 2010/01/01 * Starting balance assets:bank:savings 0 income:starting balances 2021/12/01 User1:Jacket expenses:User1:Jacket 80 income:User1:creditcard1 2010/07/24 User1:Pajama expenses:User1:Pajama 30 income:User1:creditcard1 2010/07/23 User2:Flowers expenses:User2:Flowers 20 income:User2:creditcard2 2010/07/23 User2:ChristmasTree expenses:User2:ChristmasTree 40.00 income:User2:creditcard2 2010/07/23 User2:User1-Compensation expenses:User2:User1-Compensation 25.00 expenses:User1:User1-Compensation #+end_src #+RESULTS: compensated #+begin_example 170 expenses 85User1 80 Jacket 30 Pajama -25 User1-Compensation 85User2 40 ChristmasTree 20 Flowers 25 User1-Compensation -170 income -110User1:creditcard1 -60User2:creditcard2 0 #+end_example The question is can this be done automatically? By this I mean can 2010/07/23 User2:User1-Compensation expenses:User2:User1-Compensation 25.00 expenses:User1:User1-Compensation Somehow be generated automatically? smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] org-compat stops working [9.5 (release_9.5-194-gdb302d @ /home/oub/emacs/site-lisp/packages/org/)]
Uwe Brauer writes: > Out of a sudden, when starting emacs I obtain various errors that seem to be > conntected to try to load > > org-compat I obtain > > > > Debugger entered--Lisp error: (error "Don’t know how to make a localized > variable an alias") > defvaralias(org-descriptive-links org-link-descriptive nil) For future reference, the related discussion has moved to https://list.orgmode.org/87fsqcg839@mat.ucm.es/T/#t Best, Ihor
bug#52545: 29.0.50; Make org-babel-execute-buffer ignore irrelevant src blocks
On 25/12/2021 02:52, Berry, Charles wrote: For that case, setting buffer or heading properties, such as: #+begin_src org :PROPERTIES: :header-args: :eval yes :exports results :header-args:bibtex: :eval no :END: #+end_src resolves the issue. Chuck, is it expected that the following form to specify properties suppresses of evaluation during export but allows execution during processing of `org-babel-execute-buffer'? I am puzzled that behavior for property drawer is different. >8 #+property: header-args :eval yes :exports both #+property: header-args:elisp :eval no #+begin_src elisp (message "From elisp") #+end_src 8<
Re: [BUG] org-element-cache "rx '**' range error" [9.6 (9.6-??-8f50ea2d6 @ /home/samc/.emacs.d/.local/straight/build-27.2/org/)]
Hi Ihor, The hook that is going wrong is pdf-tools-enable-minor-modes. After digging into it, there seems to be a whole bunch of problematic minor modes. My methodology wasn't super rigorous, but what I found was > pdf-misc-context-menu-minor-mode > pdf-misc-size-indication-minor-mode > pdf-misc-menu-bar-minor-mode > pdf-misc-minor-mode cause problems every time the pdf is loaded, and > pdf-links-minor-mode > pdf-outline-minor-mode > pdf-annot-minor-mode cause problems every *other* time the pdf is loaded. I found a couple of workarounds: adding (org-reload) to my init.el (actually config.el as I'm running doom emacs) solves the problem, though it does add another second to my load time. Alternatively, I was able to load the first set of minor modes without issue by using doom's (after! pdf-tools ...). This didn't seem to work for the latter minor modes though. Cheers, Sam On Wed, 29 Dec 2021 at 05:01, Ihor Radchenko wrote: > Samuel Crawford writes: > > > Every time I try to open a particular pdf I'm inundated with "Org parser > > error"s, all looking like this: > > > >> Warning (org-element-cache): org-element--cache: Org parser error in > > thesis.pdf::316345. Resetting. > >> The error was: (error "rx ‘**’ range error") > > > > Is there any way I can disable org-element-cache on pdfs as a > > workaround? > > AFAIU, something is calling org-mode function outside of org-mode (which > is wrong, even though it could work by accident in earlier versions of > Org). Can you check your hooks ran when you load the problematic pdf? > > Best, > Ihor >
Re: [SOLVED]
Uwe Brauer writes: > So if I understand you correctly. I do load my org package too late for > org-real? I think so. My speculation: If the newest Org is not yet in load-path when you load org-real, org-real's (require 'org) will pull-in built-in version of org-compat. Later, when load-path points to the newest version of Org, you load org-persist (org-persist does not exist in built-in version of Org), which relies on org-file-name-concat to be defined in the newest version of org-compat. However, built-in version of org-compat is already loaded by emacs and (require 'org-compat) inside org-persist does not trigger loading. Hence, you are getting > Debugger entered--Lisp error: (void-function org-file-name-concat) Best, Ihor
Re: [SOLVED]
>>> "IR" == Ihor Radchenko writes: > Uwe Brauer writes: >>> Hmm. I suspect that org-real might not be the problem by itself. >>> Rather you may load it too early and pull-in built-in org. >> >> Well I don't load anything, that is all done by the package system. > I was just guessing. But do you really have init.el with no requires? I have a lot of requires in my init file, but non for org-real besides I have installed a lot of org addons from MELPA and none have caused me any problem. So if I understand you correctly. I do load my org package too late for org-real? Regards Uwe
