[PATCH] org-refile: add missing version number
* org-refile.el: (define-obsolete-function-alias): Added missing version number, which is required since 32c6732d16385f242b1109517f25e9aefd6caa5c was merged into Emacs' master branch. org-copy was made obsolete in f636cf91b6cbe322eca56e23283f4614548c9d65, prior to the 9.4 release. --- lisp/org-refile.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-refile.el b/lisp/org-refile.el index a8a2ef2a6..eea896085 100644 --- a/lisp/org-refile.el +++ b/lisp/org-refile.el @@ -373,7 +373,7 @@ the *old* location.") (defvar org-refile-keep nil "Non-nil means `org-refile' will copy instead of refile.") -(define-obsolete-function-alias 'org-copy 'org-refile-copy) +(define-obsolete-function-alias 'org-copy 'org-refile-copy "9.4") ;;;###autoload (defun org-refile-copy () -- 2.29.2
Re: Generated graphic not included in exported TeX/PDF
Loris (& the list),
did you get this sorted? It seems that I am running into the same
problem now.
What seems to be happening is that the LaTeX file is created in
/tmp/babel-XX/latex-YY.tex but the log, aux, etc. files are
being created in the current directory (where the file with the LaTeX
src block is). Although the PDF file is created properly, it is not
where org would expect it to be (maybe)?
The LaTeX file in /tmp/ compiles perfectly fine when I compile it
manually. Attached is /tmp/ecm.org and here is a screenshot of my /tmp
directory:
Note that latex-iLJhcd.tex is in /tmp/babel-falBv7/ but the
{log,pdf,out} files are in /tmp/.
The backtrace on error is also attached.
This has been done with org from git updated a few minutes ago. Emacs
from a few days ago.
Thank you,
eric
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-179-g5b5c42
title: ECM
* black box model
This is a graphical representation of \(y=f(x)\):
#+header: :exports results
#+header: :results raw
#+header: :file blackboxmodel.png
#+header: :imagemagick yes :iminoptions -density 600 :imoutoptions -geometry 400
#+header: :fit yes
#+begin_src latex
\begin{tikzpicture}[node distance=2cm, shorten >=2pt, shorten <=2pt]
\node (x) {$x$};
\node[fill=yellow!10!black,draw=white] (box) [right of=x] {Model} edge [<-] (x);
\node (f) [right of=box] {$f(x)$} edge [<-] (box);
\end{tikzpicture}
#+end_src
Debugger entered--Lisp error: (error "File
\"/tmp/babel-falBv7/latex-iLJhcd.pdf\" wasn’t p...")
signal(error ("File \"/tmp/babel-falBv7/latex-iLJhcd.pdf\" wasn’t p..."))
error("File \"/tmp/babel-falBv7/latex-iLJhcd.pdf\" wasn't p...")
org-compile-file("/tmp/babel-falBv7/latex-iLJhcd.tex" ("pdflatex %f" "bibtex
%b" "pdflatex %f" "pdflatex %f") "pdf" "See \"*Org PDF LaTeX Output*\" for
details" # ((66 . "bibtex") (76 . "pdflatex")))
org-latex-compile("/tmp/babel-falBv7/latex-iLJhcd.tex")
org-babel-latex-tex-to-pdf("/tmp/babel-falBv7/latex-iLJhcd.tex")
org-babel-execute:latex("\\begin{tikzpicture}[node distance=2cm, shorten
>=2..." ((:colname-names) (:rowname-names) (:result-params "replace" "raw")
(:result-type . value) (:results . "replace raw") (:exports . "results")
(:session . "none") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle .
"no") (:fit . "yes") (:imagemagick . "yes") (:iminoptions . "-density 600")
(:imoutoptions . "-geometry 400") (:file . "blackboxmodel.png")))
org-babel-execute-src-block(nil ("latex" "\\begin{tikzpicture}[node
distance=2cm, shorten >=2..." ((:colname-names) (:rowname-names)
(:result-params "raw" "replace") (:result-type . value) (:results . "raw
replace") (:exports . "results") (:file . "blackboxmodel.png") (:imoutoptions .
"-geometry 400") (:iminoptions . "-density 600") (:imagemagick . "yes") (:fit .
"yes") (:tangle . "no") (:hlines . "no") (:noweb . "no") (:cache . "no")
(:session . "none")) "" nil 265 "(ref:%s)"))
org-ctrl-c-ctrl-c(nil)
funcall-interactively(org-ctrl-c-ctrl-c nil)
call-interactively(org-ctrl-c-ctrl-c nil nil)
command-execute(org-ctrl-c-ctrl-c)
Re: [PATCH] ob-java, a proposal on import improvement
On Fri, Jan 8, 2021 at 11:28 AM John Herrlin wrote:
> I would like to combine imports from header-args with imports from a
> source block.
> ...
> I didnt get the to work so I made a patch.
John, Sorry that wasn't working. Thanks for investigating and
submitting a fix. I think the problem was that I was missing static
imports, which you fixed in the first chunk of your patch. I don't
think the rest of the change is necessary. Could you revert the other
chunks and re-test?
This works for me using master, and your patch produces nearly the
same code (only import order differs):
#+begin_src java :results output :imports java.util.HashMap
import java.util.Map;
Map hash = new HashMap<>();
hash.put("one", 1);
hash.put("two", 2);
System.out.println(hash);
#+end_src
Re: [PATCH] ob-java, a proposal on import improvement
> I can’t give an informed opinion about the patch, but the example looks > great! I did not know that Java support in org-babel is that good. Thanks. Yes, ob-java got an update with org 9.4.
[PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/e
On 2021-01-03 16:27, TRS-80 wrote: Hello! I seem to have come across a bug today in org-footnote. I had just learned about the variable org-footnote-auto-adjust and set it to t. Then I tried to test it by invoking org-footnote-new in my Org file in between existing footnotes 2 and 3. N.B., my Footnotes heading, prior to doing above also had a CUSTOM_ID property set: #+begin_src org ,** Footnotes :PROPERTIES: :CUSTOM_ID:footnotes :END: [fn:1] original footnote 1 [fn:2] original footnote 2 [fn:3] original footnote 3 [fn:4] original footnote 4 #+end_src The new footnote seems to get inserted into correct place, however there appears to be a problem if there is a property drawer: #+begin_src org ,** Footnotes [fn:1] original footnote 1 [fn:2] original footnote 2 [fn:3] new footnote :PROPERTIES: :CUSTOM_ID:footnotes :END: [fn:4] original footnote 3 [fn:5] original footnote 4 #+end_src Since I was just studying the org-footnote code anyway, I will attempt to further diagnose the issue, and perhaps even send a patch. As I was filling out bug report I realized I am on slightly dated version of Orgmode. So I went ahead and cloned latest version and did a diff on org-footnote.el between my affected version here locally and latest, and the only change I saw was the copyright date. So with that out of the way, I will start digging and see what I can come up with. Cheers, TRS-80 Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20) of 2020-05-16, modified by Debian Package: Org mode version 9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs.d/elpa/org-plus-contrib-20200309/) Attached please find a very simple (one line) patch that I believe should fix this issue. This patch is of course based on latest git (not my personal outdated version) and also maint branch. I think I've got that right? However as it will be my first patch to Orgmode, any feedback would be welcomed. Cheers, TRS-80 From cf7111a87645262c68214a03ca88f72bb0710049 Mon Sep 17 00:00:00 2001 From: TRS-80 Date: Sat, 9 Jan 2021 11:50:50 -0500 Subject: [PATCH] org-footnote: fix inserting new footnote mangling drawers * org-footnote.el (org-footnote-create-definition): Replace `forward-line' with `org-end-of-meta-data' to skip over any properties and/or drawers that may be present on the `org-footnote-section' heading (default "Footnotes"). TINYCHANGE --- lisp/org-footnote.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-footnote.el b/lisp/org-footnote.el index 3d42421e0..47ad4aa04 100644 --- a/lisp/org-footnote.el +++ b/lisp/org-footnote.el @@ -704,7 +704,7 @@ function doesn't move point." (concat "^\\*+[ \t]+" (regexp-quote org-footnote-section) "[ \t]*$") nil t)) (goto-char (match-end 0)) - (forward-line) +(org-end-of-meta-data t) (unless (bolp) (insert "\n"))) (t (org-footnote--clear-footnote-section))) (when (zerop (org-back-over-empty-lines)) (insert "\n")) -- 2.29.2
Re: Possibility to copy text outside EMACS and send it to orgmode document
On 2021-01-07 01:29, Gerardo Moro wrote: Thanks. Then why is in https://orgmode.org/worg/org-contrib/org-protocol.html#installation this confusing bit? INSTALLATION * To load org-protocol.el add the following to your .emacs: (server-start) (add-to-list 'load-path "~/path/to/org/protocol/") (require 'org-protocol) El jue, 7 ene 2021 a las 8:17, Tom Gillespie () escribió: It is built into the core org distribution. Perhaps documentation should be updated? Cheers, TRS-80
Re: Org to ConTeXt exporter?
Hello, Jason, Jason Ross writes: > I recently had the same thought and I've started working on one. > You can see it here: > > https://github.com/Jason-S-Ross/ox-context/ > > It's no substitute for the LaTeX exporter but it implements a lot > of the basics. I'm deriving from the LaTeX exporter but I have > to override most of the transcoders so it may be better to start > from scratch. > > Disclaimer: I'm learning elisp as I go, so please excuse the > rough edges. That's great news! I've been testing it a bit and it works very good. Of course, I encourage you to keep up this excellent work. Regards, Juan Manuel > > Jason Ross > --
Bug: test-org-archive/datetree fails with German locale
Hello,
I've run across a test error on the current HEAD.
When I run "make test" on my system, then test-org-archive/datetree
fails.
The test fails because the expected output should contain "Sunday",
but with a German locale the generated text is "Sonntag" instead
(which is the German translation of "Sunday").
+v
Test test-org-archive/datetree condition:
(ert-test-failed
((should
(string-match-p
(regexp-quote "*** 2020-07-05 Sunday
a")
(org-test-with-temp-text-in-file "* a
" ...)))
:form
(string-match-p "\\*\\*\\* 2020-07-05 Sunday
\\*\\*\\*\\* a"
#("* 2020
** 2020-07 Juli
*** 2020-07-05 Sonntag
a
:PROPERTIES:
:ARCHIVE_TIME: 2020-07-05 So 00:00
:ARCHIVE_FILE: /tmp/tmp-orgtest/org-testogmzZy
:ARCHIVE_CATEGORY: org-testogmzZy
:END:
" 53 54
(org-category "org-testogmzZy")
214 215
(org-category "org-testogmzZy")))
:value nil))
FAILED 1/1 test-org-archive/datetree
-v
Running the tests with LANG=C or even just LC_TIME=C makes the test
pass again.
A simple fix for this would be to prepend LANG=C to $(EMACSQ) in
mk/default.mk so all tests run with a defined locale.
This would prevent other locale-related test failures in the future.
But on the other hand this would also hide real locale-related bugs in
the production code, as all tests only run with LANG=C from then on.
A less intrusive fix would be to replace the fixed string "Sunday" in
the test regexp by the localized weekday.
What do you think?
Best regards
Christian
--
Christian.Garbshttps://www.cgarbs.de
[BUG] org-bibtex-read requires that bibtex is properly initialized
Hi, When calling org-bibtex-read on a fresh emacs on a text which is not a .bib file, we get the following error: bibtex-parse-entry: Wrong type argument: stringp, nil This problem is solved if the (bibtex-set-dialect) function is called before. Note that this function is called automatically the first time a .bib file is opened, so many users may not have seen this problem. I don't know what the right fix would be though. For now I call (bibtex-set-dialect) in my init.el, but maybe org-bibtex-read should do it? Thank you for org-mode! Matthieu
Re: [PATCH] org-refile: add missing version number
David Duthie writes: > * org-refile.el: (define-obsolete-function-alias): Added missing version > number, [...] Thank you for the patch, but this was already addressed on Thursday by 248dfcd71.
