Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs
Hi, I understand better, thanks. Would be a good opportunity for me to (try to) contribute; this weekend I will check carefully the link you've sent. I'll keep you posted, your assistance would be more than welcome :) Best, MP Sent with Proton Mail secure email. --- Original Message --- On Tuesday, July 11th, 2023 at 10:14 PM, Ihor Radchenko wrote: > "M. Pger" mp...@protonmail.com writes: > > > Sorry for the possibly silly question, but by '+1', can I understand that > > you will implement this feature because you think it is worth it? > > > No, it just means that I think that this feature makes sense to be > implemented. Basically, upvote. > > Whether I am going to implement it myself depends on other users. > > I usually do not put agenda features high in my todo list because > org-agenda.el is a pain to work with due to obsolete code. But, I will > re-consider if other people also say that they want this feature. > > [ For context, I currently have 500 feature requests and ideas recorded in > my notes. And there are also bugs and general maintenance tasks... I have > to prioritize. ] > > Or maybe someone motivated enough can try to implement it and submit a > patch (see https://orgmode.org/worg/org-contribute.html). I will then > provide assistance. (Helping new and returning contributors is certainly > high in my todo list ;]) > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > > Support Org development at https://liberapay.com/org-mode, > > or support my work at https://liberapay.com/yantar92
Re: Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs
Hi, Sorry for the possibly silly question, but by '+1', can I understand that you will implement this feature because you think it is worth it? If this is case, thank you very much; if not, thank you anyway for your work with Org-mode! Note that I was suggesting setting an upper bound, but being able to truncate breadcrumbs from both sides would be even nicer^^ Best, MP --- Original Message --- On Tuesday, July 11th, 2023 at 11:30 AM, Ihor Radchenko wrote: > "M. Pger" mp...@protonmail.com writes: > > > Feature request: adjust ~org-agenda-format-item~ to let the user choose the > > first level included in breadcrumbs > > > +1 > > -- > Ihor Radchenko // yantar92, > Org mode contributor, > Learn more about Org mode at https://orgmode.org/. > > Support Org development at https://liberapay.com/org-mode, > > or support my work at https://liberapay.com/yantar92
Feature request: adjust ~org-agenda-format-item~ to let the user choose the first level included in breadcrumbs
Dear All, Including "%b" in the org agenda prefix formats (org-agenda-prefix-format) allows to display entries' outline paths, which is super useful to get project-oriented agenda views/todo-list. Consider a project 'Foobar Report'. In the agenda view/todo-list, it would look like the following: ``` PROJECT Foobar Report Foobar Report->TODO Task1 Foobar Report->Task1->TODO Subtask1.1 Foobar Report->Task1->TODO Subtask1.2 Foobar Report->TODO Task2 Foobar Report->Task2-> TODO Subtask2.1 Foobar Report->Task2-> TODO Subtask2.2 ``` In such a setting, having 'Foobar Report' at the beginning of each line is not really useful and can impair readability. To tell Org to only print breadcrumbs starting at e.g. level 2 (i.e. skipping the 'Foobar Report' part of the breadcrumbs), I followed the first part of https://list.orgmode.org/CAGEgU=hgnxj7tsgv6pvdsewfwp_ivwe8wru+uh8hjh_7nnr...@mail.gmail.com/ and modified the following part of org-agenda-format-item: ``` (when org-prefix-has-breadcrumbs (setq breadcrumbs (org-with-point-at (org-get-at-bol 'org-marker) (let ((s (org-format-outline-path (org-get-outline-path) (1- (frame-width)) nil org-agenda-breadcrumbs-separator))) (if (eq "" s) "" (concat s org-agenda-breadcrumbs-separator)) ``` by replacing (org-get-outline-path) with ``` (nthcdr (1- org-agenda-breadcrumbs-start-level) (org-get-outline-path)) ``` while setting a custom variable org-agenda-breadcrumbs-start-level to 2. It works well. Would the Org devs/active contributors be willing to implement such modification (maybe a cleaner version, with a better custom variable name?) in the next release of Org? Best, MP PS: Note that I tried to implement the same using advice-add, but miserably failed and decided to go for a complete redefinition of org-agenda-format-item (more lines, but less pain).
Re: error org export to pdf when latex letter class has been added to org-latex-classes
Hi,
Thank you for your answer.
> Are you including citations in your letter?
No, that's also why it is puzzling. You should be able to reproduce the issue
by creating a really minimalist init file including the following:
```
(with-eval-after-load 'ox-latex
(add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}"))
)
(setq org-latex-pdf-process (list "latexmk -shell-escape -f -pdf %f"))
```
As mentioned in my previous mail, the error also appears when using `pdflatex`
instead of `latexmk`.
Best,
M
--- Original Message ---
On Tuesday, September 13th, 2022 at 7:55 PM, Juan Manuel Macías
wrote:
> Hi,
>
> M. Pger writes:
>
> > (/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
> >
> > ! LaTeX Error: Environment thebibliography undefined.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type H for immediate help.
> > ...
> >
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ?
> > ! Emergency stop.
> > ...
> >
> > l.1063 \renewenvironment{thebibliography}
> > [1]{%
> > ! ==> Fatal error occurred, no output PDF file produced!
>
>
> Are you including citations in your letter? Maybe this is related:
> https://latex.org/forum/viewtopic.php?f=4=3359
>
> Best regards,
>
> Juan Manuel
>
> --
> --
> --
> Juan Manuel Macías
>
> https://juanmanuelmacias.com
>
> https://lunotipia.juanmanuelmacias.com
>
> https://gnutas.juanmanuelmacias.com
error org export to pdf when latex letter class has been added to org-latex-classes
Dear All,
I've told Org about the letter class with the following in my init file:
```
(with-eval-after-load 'ox-latex
(add-to-list 'org-latex-classes '("letter" "\\documentclass{letter}")) )
```
After that I can create a org document containing e.g.:
```
#+latex_class: letter
#+latex_header: \signature{M. Pger}#+latex_header: \address{42 My Street \\ My
Town}
#+latex: \begin{letter}{Org mailing-list \\ 42 GNU Street \\ GNU Town}
#+latex: \date{September 2022}#+latex: \opening{Dear Members of the Org
mailing-list,}
Here is the text of the letter.
#+latex: \closing{Yours faithfully,}
#+latex: \end{letter}
```
When I export it using C-c C-e l o, an error appears:
```
(/usr/share/texlive/texmf-dist/tex/latex/natbib/natbib.sty
! LaTeX Error: Environment thebibliography undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H for immediate help.
...
l.1063 \renewenvironment{thebibliography}
[1]{%
?
! Emergency stop.
...
l.1063 \renewenvironment{thebibliography}
[1]{%! ==> Fatal error occurred, no output PDF file produced!
```
In order to have a pdf output, I can use -interaction=nonstopmode in the
org-latex-pdf-process, but of course the error is still there (but now I have
a pdf, which is good). Exporting from org, the error is there whenever I use
latexmk (with pdflatex) or directly pdflatex.
However, there is no error when creating such a letter from a .tex file in
Auctex (which appears to also use pdflatex as the compiler).
Any thoughts?
Best,
M
Re: no syntax highlighting for code blocks with org-publish
Actually, using -nw implies that no theme is loaded, so the face colors 'extracted' by htmlize are the flashy default colors of Emacs in terminal. To have the colors associated with the theme I use, I had to load the theme through build.el and to change my bash script to: #!/bin/sh emacs -q --load=build.el --eval="(eval-buffer)" --eval="(save-buffers-kill-terminal)" The advantage is of course to have the desired face colors; the minor disadvantage is to see an Emacs frame appearing, loading the theme and then disappearing. Best, M --- Original Message --- On Wednesday, July 20th, 2022 at 1:14 AM, M. Pger wrote: > I solved the issue by creating the following bash script in my project folder: > > #!/bin/sh > TERM=xterm export TERM > emacs -q -nw --load=build.el --eval="(eval-buffer)" > --eval="(save-buffers-kill-terminal)" > > This avoid using --script (and thus batch) and thus allows font-lock to be > enabled when my publishing elisp script (build.el) is run. Thanks to > `TERM=xterm export TERM`, this bash script can be run from the Emacs shell > (otherwise problematic because of the -nw option). > > To have 'extended' syntax highlighting for R, note that I have to load ESS > from build.el. > > Hope this will help! Thanks again for your feedback and your insights. > > Best, > > M > > --- Original Message --- > On Wednesday, July 20th, 2022 at 12:33 AM, Tim Cross theophil...@gmail.com > wrote: > > > > > "M. Pger" mp...@protonmail.com writes: > > > > > I tried to publish using `M-x org-publish RET RET` as > > > you suggested, and > > > syntax highlighting was actually implemented, thanks. > > > > > > Actually the problem is coming from the fact that I use `emacs -Q > > > --script build.el` (as a > > > bash script) to publish the project. According to > > > https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/ > > > (rather old, but > > > apparently this has not changed), font-lock-mode is not enabled by > > > default in --batch > > > mode. Since `--script` "run Emacs in batch mode, like ‘--batch’, and then > > > read and execute > > > the Lisp code in file" (cf the doc), it seems that this is exactly my > > > problem. > > > > > > A workaround is suggested in > > > https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/, > > > but > > > unfortunately for me it does not work (yet). I am going to dig further > > > into that. > > > > I would be interested to hear how you go. I have a use case coming up > > where I need to publish a large number of org files using a batch job, > > so expect to run into the same issue. Right now, I'm still getting my > > head around how to best get a consistent style when the input comes from > > multiple org files from different sources and I want to minimise editing > > the sources, plus provide a simple way to update/change the styling > > later.
Re: no syntax highlighting for code blocks with org-publish
I solved the issue by creating the following bash script in my project folder: #!/bin/sh TERM=xterm export TERM emacs -q -nw --load=build.el --eval="(eval-buffer)" --eval="(save-buffers-kill-terminal)" This avoid using --script (and thus batch) and thus allows font-lock to be enabled when my publishing elisp script (build.el) is run. Thanks to `TERM=xterm export TERM`, this bash script can be run from the Emacs shell (otherwise problematic because of the -nw option). To have 'extended' syntax highlighting for R, note that I have to load ESS from build.el. Hope this will help! Thanks again for your feedback and your insights. Best, M --- Original Message --- On Wednesday, July 20th, 2022 at 12:33 AM, Tim Cross wrote: > "M. Pger" mp...@protonmail.com writes: > > > I tried to publish using `M-x org-publish RET RET` as you > > suggested, and > > syntax highlighting was actually implemented, thanks. > > > > Actually the problem is coming from the fact that I use `emacs -Q --script > > build.el` (as a > > bash script) to publish the project. According to > > https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/ > > (rather old, but > > apparently this has not changed), font-lock-mode is not enabled by default > > in --batch > > mode. Since `--script` "run Emacs in batch mode, like ‘--batch’, and then > > read and execute > > the Lisp code in file" (cf the doc), it seems that this is exactly my > > problem. > > > > A workaround is suggested in > > https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/, > > but > > unfortunately for me it does not work (yet). I am going to dig further into > > that. > > > I would be interested to hear how you go. I have a use case coming up > where I need to publish a large number of org files using a batch job, > so expect to run into the same issue. Right now, I'm still getting my > head around how to best get a consistent style when the input comes from > multiple org files from different sources and I want to minimise editing > the sources, plus provide a simple way to update/change the styling > later.
Re: no syntax highlighting for code blocks with org-publish
I tried to publish using `M-x org-publish RET RET` as you
suggested, and syntax highlighting was actually implemented, thanks.
Actually the problem is coming from the fact that I use `emacs -Q --script
build.el` (as a bash script) to publish the project. According to
https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/
(rather old, but apparently this has not changed), font-lock-mode is not
enabled by default in --batch mode. Since `--script` "run Emacs in batch mode,
like ‘--batch’, and then read and execute the Lisp code in file" (cf the doc),
it seems that this is exactly my problem.
A workaround is suggested in
https://list.orgmode.org/ae5693f1-f63d-4383-8840-0fd2dbaac...@gmail.com/, but
unfortunately for me it does not work (yet). I am going to dig further into
that.
Best,
M
Sent with Proton Mail secure email.
--- Original Message ---
On Tuesday, July 19th, 2022 at 9:51 AM, Tim Cross wrote:
> "M. Pger" mp...@protonmail.com writes:
>
> > Thanks for your suggestion. I added the following:
> >
> > #+begin_src elisp :eval no :exports code
> > (setq my-var "org mailing list")
> > (message "Hello, %s" my-var)
> > #+end_src
> >
> > When exported with ~C-c C-e h o~, syntax highlighting is implemented (with
> > colors). When
> > exported with org-publish interestingly I have no color, but =setq= is in
> > bold. Would it
> > be possible that ox-publish implements some kind of really basic builtin
> > syntax
> > highlighting and ignores htmlize?
>
>
> I tried both exporting an org file into html and publishing and didn't
> get any syntax highlighting for either case. Had a closer look and
> noticed it didn't look like htmlize was being loaded. Did a (require
> 'htmlize) and did both an export and publish, betting syntax
> highlighting for both.
>
> My suspicion is that for the publish option, htmlize wasn't loaded?
> Maybe worth doing an explicit require and then call org-publish directly
> and see if that makes any difference.
>
> Below is the basic publish alist setting I used. Doubt all the slots are
> relevant - it was just a snippet from another project I grabbed to get
> setup.
>
> I also run M-x org-publish orgfiles rather than the export menu.
>
>
> (setq org-publish-project-alist
> '(("orgfiles"
> :base-directory "~/playground/org/"
> :base-extension "org"
> :recursive t
> :publishing-directory "~/Public"
> :publishing-function org-html-publish-to-html
> :exclude "PrivatePage.org"
> :html-style-default ""
> :html-scripts ""
> :html-htmlize-output-type 'inline-css
> :html-doctype "html5"
> :html-html5-fancy t
> :html-validation-link nil
> )))
Re: no syntax highlighting for code blocks with org-publish
Thanks for your suggestion. I added the following:
#+begin_src elisp :eval no :exports code
(setq my-var "org mailing list")
(message "Hello, %s" my-var)
#+end_src
When exported with ~C-c C-e h o~, syntax highlighting is implemented (with
colors). When exported with org-publish interestingly I have no color, but
=setq= is in bold. Would it be possible that ox-publish implements some kind of
really basic builtin syntax highlighting and ignores htmlize?
--- Original Message ---
On Monday, July 18th, 2022 at 11:50 PM, Tim Cross wrote:
> "M. Pger" mp...@protonmail.com writes:
>
> > Thank you for your answer. Here it is:
> >
> > 1. Create the following directory structure (3 directories):
> > ~/test/
> > ├── content
> > ├── html
> > └── .packages
> >
> > 2. Create the .el script to build the website (=~/test/build.el=):
> >
> > #+begin_src elisp
> > ;; * Set the package installation directory (in order not to overwrite the
> > standard ~/emacs.d)
> > (require 'package)
> > (setq package-user-dir (expand-file-name "./.packages"))
> > (setq package-archives '(("melpa" . "https://melpa.org/packages/;)))
> > (add-to-list 'package-archives '("elpa" . "https://elpa.gnu.org/packages/;))
> >
> > ;; * Initialize the package system
> > (package-initialize)
> > (unless package-archive-contents
> > (package-refresh-contents))
> >
> > ;; * Install dependencies
> > ;; ** since org is builtin, by default Emacs does not try to install the
> > latest version from Elpa (9.5.4)
> > ;; the following solves the issue:
> > (defun mpger-ignore-builtin (pkg)
> > (assq-delete-all pkg package--builtins)
> > (assq-delete-all pkg package--builtin-versions))
> > (mpger-ignore-builtin 'org)
> > ;; ** install packages:
> > (package-install 'org)
> > (package-install 'htmlize)
> >
> > ;; * Load the publishing system:
> > (require 'org)
> > (require 'htmlize)
> > (require 'ox-publish)
> >
> > ;; * Define the project
> > (setq org-publish-project-alist
> > (list
> > (list "pages"
> > :recursive t
> > :htmlized-source t
> > :base-directory "./content/"
> > :base-extension "org"
> > :publishing-directory "./html/"
> > :publishing-function 'org-html-publish-to-html
> > :with-creator t
> > :with-toc t
> > :section-numbers nil
> > :time-stamp-file nil)
> > ))
> >
> > ;; * Generate the site output
> > (org-publish-all t)
> >
> > (message "Done!")
> > #+end_src
> >
> > 3. In =~/test/content/=, create a simple test.org file to be published as
> > html (=~/test/content/test.org=):
> >
> > #+begin_example
> > * Here's some text
> >
> > Lorem ipsum.
> >
> > * Here's some code
> >
> > #+begin_src R :results output :exports both
> > df <- mtcars ## a comment
> > library(parallel)
> > #+end_src
> >
> > #+end_example
> >
> > 4. Run =~/test/build.el= (e.g. with ~emacs -Q --script ~/test/build.el~)
> > and compare with
> > the output from ~C-c C-e h o~. The latter has syntax highlighting, the
> > former has not.
>
>
> Just a shot in the dark. Does syntax highlighting work if the source
> block is something like emacs-lisp rather than R?
>
> I know that syntax highlighting is based on the syntax highlighting from
> the mode used for a specific language. I'm wondering if your not getting
> syntax highlighting because in yhour publish script, R mode is not
> loaded, but when you open the org file and do a 'normal' export, R is
> loaded and so you get syntax highlighting. Therefore, I would try the
> same experiment, but instead of a source block of R code, I would try a
> source block of emacs-lisp code as we know that emacs-lisp mode will be
> loaded.
>
> Could be completely off track though!
Re: no syntax highlighting for code blocks with org-publish
Thank you for your answer. Here it is:
1. Create the following directory structure (3 directories):
~/test/
├── content
├── html
└── .packages
2. Create the .el script to build the website (=~/test/build.el=):
#+begin_src elisp
;; * Set the package installation directory (in order not to overwrite the
standard ~/emacs.d)
(require 'package)
(setq package-user-dir (expand-file-name "./.packages"))
(setq package-archives '(("melpa" . "https://melpa.org/packages/;)))
(add-to-list 'package-archives '("elpa" . "https://elpa.gnu.org/packages/;))
;; * Initialize the package system
(package-initialize)
(unless package-archive-contents
(package-refresh-contents))
;; * Install dependencies
;; ** since org is builtin, by default Emacs does not try to install the
latest version from Elpa (9.5.4)
;; the following solves the issue:
(defun mpger-ignore-builtin (pkg)
(assq-delete-all pkg package--builtins)
(assq-delete-all pkg package--builtin-versions))
(mpger-ignore-builtin 'org)
;; ** install packages:
(package-install 'org)
(package-install 'htmlize)
;; * Load the publishing system:
(require 'org)
(require 'htmlize)
(require 'ox-publish)
;; * Define the project
(setq org-publish-project-alist
(list
(list "pages"
:recursive t
:htmlized-source t
:base-directory "./content/"
:base-extension "org"
:publishing-directory "./html/"
:publishing-function 'org-html-publish-to-html
:with-creator t
:with-toc t
:section-numbers nil
:time-stamp-file nil)
))
;; * Generate the site output
(org-publish-all t)
(message "Done!")
#+end_src
3. In =~/test/content/=, create a simple test.org file to be published as html
(=~/test/content/test.org=):
#+begin_example
* Here's some text
Lorem ipsum.
* Here's some code
#+begin_src R :results output :exports both
df <- mtcars ## a comment
library(parallel)
#+end_src
#+end_example
4. Run =~/test/build.el= (e.g. with ~emacs -Q --script ~/test/build.el~) and
compare with the output from ~C-c C-e h o~. The latter has syntax highlighting,
the former has not.
Best,
M
--- Original Message ---
On Monday, July 18th, 2022 at 1:42 AM, Ihor Radchenko
wrote:
> "M. Pger" mp...@protonmail.com writes:
>
> > While syntax highlighting for code blocks is correctly implemented when I
> > export a Org document with M-x org-html-export-to-html, it does not work
> > when the same document is exported as part of an org-publish project
> > defined using org-publish-project-alist.
> >
> > Org-version: 9.5.4 (also tried with 9.5.2)
> > Htmlize-version: 1.57
> >
> > Note that including :htmlized-source t does not solve the problem.
> >
> > Any idea of what's happening?
>
>
> May you provide an example reproducer?
>
> Best,
> Ihor
no syntax highlighting for code blocks with org-publish
Dear All, While syntax highlighting for code blocks is correctly implemented when I export a Org document with M-x org-html-export-to-html, it does not work when the same document is exported as part of an org-publish project defined using org-publish-project-alist. Org-version: 9.5.4 (also tried with 9.5.2) Htmlize-version: 1.57 Note that including :htmlized-source t does not solve the problem. Any idea of what's happening? Best, MP
Re: org-cite: only last names and et al. for more than two coauthors
Hi, thx for your answer.
Sorry for my poor understanding of org-cite. I added
```
(require 'oc-natbib)
(setq org-cite-export-processors
'((latex natbib)
(t basic)))
```
to my init file and then it worked smoothly. I can even put
```
#+cite_export: natbib customstylefile.bst
```
in my org file to use an extraneous bibliography style file, which is pretty
nice.
A last question though: is it possible to set the 'round' option without having
to insert the latex header
```
#+LATEX_HEADER: \usepackage[round]{natbib}
```
?
Thanks a lot for your work with org-cite.
Best,
M
--- Original Message ---
On Monday, June 27th, 2022 at 12:56 PM, Bruce D'Arcus wrote:
> On Mon, Jun 27, 2022 at 1:13 AM M. Pger mp...@protonmail.com wrote:
>
> > I've recently tried to switch to org-cite, but I still have some problems
> > with the basics.
>
>
> First, org-cite is a framework for citations. When reporting issues
> related to it, you really need to identify what processor(s) you are
> seeing the behavior with.
>
> > Consider the following entry:
> >
> > @article{akey2022,
> > title = {This is the title},
> > shorttitle = {This is the short title},
> > author = {Surname1, Name1 and Surname2, Name2 and Surname3, Name3},
> > year = {2022},
> > (truncated)
> > }
> >
> > I want to have something like: "as shown by Surname1 et al. (2022), ...",
> > i.e. something one can get with natbib \citet command. With org-ref it
> > worked like a charm.
> >
> > I've tried the syntax presented in
> > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#more-exporting,
> > that is:
> > [cite/t/c:@akey2022]
> > but I ended with a 'wrong type argument' error.
> >
> > I then tried [cite/t:@akey2022]: exporting succeeds. However, I end up with
> > "as shown by Surname1, Name1 and Surname2, Name2 and Surname3, Name3
> > (2022), ...".
> >
> > How can I correctly specify the options mentioned above? Is there a
> > complete and updated tutorial available somewhere?
>
>
> [cite/t:@key] should work as you expect in natbib, biblatex, csl.
>
> Possible issues, depending on which of those you're using:
>
> - some error with the bib file; or a mismatch between the file and the
> bibtex dialect or something
> - the citation style
>
> A complete MWE would help.
>
> Bruce
org-cite: only last names and et al. for more than two coauthors
Hi,
I've recently tried to switch to org-cite, but I still have some problems with
the basics.
Consider the following entry:
@article{akey2022,
title = {This is the title},
shorttitle = {This is the short title},
author = {Surname1, Name1 and Surname2, Name2 and Surname3, Name3},
year = {2022},
(truncated)}
I want to have something like: "as shown by Surname1 et al. (2022), ...", i.e.
something one can get with natbib \citet command. With org-ref it worked like a
charm.
I've tried the syntax presented in
https://blog.tecosaur.com/tmio/2021-07-31-citations.html#more-exporting, that
is:
[cite/t/c:@akey2022]
but I ended with a 'wrong type argument' error.
I then tried [cite/t:@akey2022]: exporting succeeds. However, I end up with "as
shown by Surname1, Name1 and Surname2, Name2 and Surname3, Name3 (2022), ...".
How can I correctly specify the options mentioned above? Is there a complete
and updated tutorial available somewhere?
Thanks in advance.
Best,
Max
Re: citations: org-cite vs org-ref 3.0
On Wednesday, March 23rd, 2022 at 3:39 PM, Bruce D'Arcus wrote: > Have you actually looked at the table of existing mappings? See table 1 here > (which it seems we might want to add to the manual?): > > https://blog.tecosaur.com/tmio/2021-07-31-citations.html#cite-syntax Sorry for the late reaction to this. As an user I completely agree. IMO, having these mappings in the doc could clearly convince some org-ref users to give a try to org-cite. Some information about the possibility of using .bst bibliography style files would also be nice. Finally, some info about cross-ref could also be useful, so that users easily get an idea of what would imply a switch from org-ref to org-cite. For what it's worth, I think that Vanilla org becomes more and more amazing, thanks for that. Best, MP
Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)
Ok, thanks a lot for your suggestions. It seems that the problem comes from poly-org mode. I've followed the following steps (copy-paste from my notes, sorry for the wording): + I double-check the version of org (9.5.2, ok) and I check the function =org-latex-export-to-pdf=. This is ok since the fix is there: #+begin_example (let ((outfile (org-export-output-file-name ".tex" subtreep))) (org-export-to-file 'latex outfile async subtreep visible-only body-only ext-plist #'org-latex-compile))) #+end_example + Same error as before when trying to asynchronously export: the =*Org Export Process*= buffer still gives ~Invalid read syntax: "#"~ + However, I do these double-checks with my init file loaded. Contrary to ~emacs -Q~, when I use ~M-x toggle-debug-on-error~ no =*Backtrace*= buffer opens. I conclude that maybe something linked to my init file is interfering with the process, preventing the debugger to correctly capture the error. + I thus decide to remove everything from my init file (except ~(use-package org)~) and to try again. However, the issue is still there and the debugger does not detect it. I note that =poly-org= mode is still (automatically) loaded at startup, and I decide to use my other computer and to start with a brand new installation of emacs. + On this new emacs version, the only package I install is =org=, in order to get version 9.5.2. This time, it works: I am able to asynchronously export. + I have the impression that having =poly-org= mode installed could play a role in my problem. I thus decide to get the init file from my other computer and load it on my new installation of emacs, *except the =polymode= part*. And it actually works: I am able to asynchronously export. + As a final test, I include the =polymode= part of my init file, and restart Emacs. This time the asynchronous export process fails. What I conclude from that (correct me if I am wrong): the issue should come from =polymode= which, once installed, somehow modifies the standard org-export function/process. I am going to report this issue on the polymode github. Best, MP --- Original Message --- On Tuesday, March 8th, 2022 at 3:51 PM, Sébastien Miquel wrote: > M. Pger writes: > >> Thx for your answer. I've just upgraded org-mode (elpa way) and I am now >> using version 9.5.2. > > Version 9.5.2 should indeed contain the fix I had in mind : > > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c91271297dbbfc831874d7880343603881bdac9c > >> Unfortunately this does not work, I still end up with: >> >> Invalid read syntax: "#" > > Can you check that the right version of org-mode is picked-up, with > `describe-function` `org-latex-export-to-pdf`, find the function > definition by following the `ox-latex.el` link, and check that the > source contains the linked patch ? > >> I would like to try the alternative, i.e. disabling native-comp (for the >> export function I guess). Would you mind telling me how to do that? > > `describe-function` should also tell you whether the function is > native compiled. If it is, you can temporarily 'uncompile' by > evaluating its source code. By disabling native compilation I meant as > a compile flag, if you've built emacs from source. I cannot find an > easy way to prevent native compilation of a single package/function. > > -- > Sébastien Miquel
Re: Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)
Hi, Thx for your answer. I've just upgraded org-mode (elpa way) and I am now using version 9.5.2. Unfortunately this does not work, I still end up with: Invalid read syntax: "#" I would like to try the alternative, i.e. disabling native-comp (for the export function I guess). Would you mind telling me how to do that? Best, MP --- Original Message --- On Tuesday, March 8th, 2022 at 2:30 PM, Sébastien Miquel wrote: > Hi, > > M. Pger writes: > >> When trying to asynchronously export, I get the following error: "Process >> `org-export-process' exited abnormally". >> >> The *Org Export Process* buffer gives the following: Invalid read syntax: >> "#". > > A similar issue was fixed in master. Try the latest version of org-mode. > > Alternatively, disabling native-comp should also fix this. > > Regards, > > -- > Sébastien Miquel
Bug: asynchronous export (org-mode 9.4.4, emacs 27.2)
Dear All,
When trying to asynchronously export, I get the following error: "Process
`org-export-process' exited abnormally".
The *Org Export Process* buffer gives the following: Invalid read syntax: "#".
I tried setting org-export-async-init-file to a minimal init file, but the
problem remains. I also tried with a minimal .org file to export (no code
blocks, just some headings and some text), but this does not solve the problem.
I used emacs -Q to be sure that the problem was not coming from my init file. I
started the debugger, and here is the content of the backtrace buffer:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
make-process(:name "org-export-process" :buffer "*Org Export Process*" :command
("/usr/local/bin/emacs" "--batch" "-l" nil "-l"
"/tmp/org-export-processRMXAfq"))
apply(make-process (:name "org-export-process" :buffer "*Org Export Process*"
:command ("/usr/local/bin/emacs" "--batch" "-l" nil "-l"
"/tmp/org-export-processRMXAfq")))
start-process("org-export-process" "*Org Export Process*"
"/usr/local/bin/emacs" "--batch" "-l" nil "-l" "/tmp/org-export-processRMXAfq")
apply(start-process ("org-export-process" "*Org Export Process*"
"/usr/local/bin/emacs" "--batch" "-l" nil "-l" "/tmp/org-export-processRMXAfq"))
org-export-to-file(latex "bug_asynchronous_export.tex" t nil nil nil nil
#f(compiled-function (file) #
