Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Hello Nick!

Nick Dokos  writes:

> Jarmo Hurri  writes:
>
>> ...
>>
>> I would like ob-asymptote.el to be brought back. If there is something I
>> can do to help, I will be glad to do so.
>>
> All you have to do is volunteer to maintain it. Let Bastien know: he
> will assign you the maintenance of the file and all the asymptote
> users will owe you a debt of gratitude.

Thanks!

I have just posted another message into this group for this purpose.

All the best,

Jarmo

Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings.

I hereby volunteer to maintain ob-asymptote.el. This file has been moved
to org-contrib, but I would like it to be brought back into Org itself.

I strongly feel that Asymptote is way too valuable as a scientific tool
to be dropped out of Org.

All the best,

Jarmo

Re: [PATCH] oc-csl: Add support for sub-bibliographies

[András Simonyi]

Dear All,

On Sat, 16 Jul 2022 at 10:43, Ihor Radchenko  wrote:
any Lisp predicate as a filter.

> Thanks! LGTM!
>
> Can you please also document the new feature in the manual? Especially,
> the CLS-specific filter options. It is not clear what are they.

many thanks for looking into the patch! I've attached a rather
speculative patch documenting "PRINT_BIBLIOGRAPHY" options in the
manual including the ones added by my first patch. I'm unsure about a
lot of things (e.g., maybe it's too detailed about the CSL options),
but perhaps it's a useful starting point.

best wishes,
András
From c77494b8bff82433d4bf23631ab67e5ff3ece581 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A1s=20Simonyi?= 
Date: Wed, 20 Jul 2022 23:54:32 +0200
Subject: [PATCH] * doc/org-manual.org: Document "PRINT_BIBLIOGRAPHY" options

---
 doc/org-manual.org | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 26d18f533..c4f262dd0 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -16815,6 +16815,49 @@ should print.
 
 : #+print_bibliography:
 
+The "biblatex" and "csl" export processors support passing additional
+bibliography options through a property list attached to the
+=PRINT_BIBLIOGRAPHY= keyword.  E.g.,
+
+: #+print_bibliography: :type book :keyword algebra
+
+Values including spaces must be surrounded with double quotes.  If you
+need to use a key multiple times, you can separate its values with
+commas, but without any space in-between:
+
+: #+print_bibliography: :keyword algebra,logic :title "Primary Sources"
+
+A document may contain more than one =PRINT_BIBLIOGRAPHY= keywords
+with or without additional options.  The "biblatex" export processor
+accepts all options supported by BibLaTeX's ~\printbibliography~
+command, while the "csl" processor accepts the following ones:
+
+- =:keyword = :: Print only entries whose
+  keyword field contains all given keywords.
+
+- =:notkeyword = :: Print only entries whose
+  keyword field does not contain any of the given keywords.
+
+- =:type = :: Print only entries whose type is
+  ==.  Entry type is the BibTeX/BibLaTeX entry type if this
+  information is available (the entry was read from a BibTeX/BibLaTeX
+  bibliography) and the CSL entry type otherwise.
+
+- =:nottype = :: Print only entries whose
+  type is not among the given entry types.  Entry type is determined
+  as in the case of =:type=.
+
+- =:csltype = :: Print only entries whose CSL entry type
+  (possibly based on a conversion from BibTeX/BibLaTeX to CSL) is
+  ==.
+
+- =:notcsltype = :: Print only entries whose
+  CSL entry type (possibly based on a conversion from BibTeX/BibLaTeX
+  to CSL) is not among the listed entry types.
+
+- =:filter = :: Print only entries for which the given
+  Emacs Lisp predicate returns a non-~nil~ value.
+
 * Working with Source Code
 :PROPERTIES:
 :DESCRIPTION: Export, evaluate, and tangle code blocks.
-- 
2.25.1

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Max Nikulin writes:

>>> On the other hand I would consider adding babel by default without
>>> explicit header. To suppress loading users may add
>>> #+latex_header: % \usepackage{babel}
>> I don't understand this very well. What would happen, then, to users
>> who
>> prefer to use Polyglossia, or those who prefer to explicitly add babel
>> or polyglossia code?
>
> Certainly if polyglossia or explicit babel related commands are
> detected then default babel configuration is not added to preamble.
> The idea is to add babel if a user have not expressed her intentions
> explicitly.

Ah, I see. I think it's a nice idea. I guess a basic babel setup would
be added to preamble. Something like:

#+language: lang

--> \usepackage[lang]{babel}

But I think also users who use custom preamble templates included in
org-latex-classes or those who load the entire preamble via an external
file (a .sty or .tex file) will want to avoid this. Maybe it would be
nice to add a defcustom, with the following values:

- load babel with the value of #+language, when there is no explicit code from 
babel (default?)

- load polyglossia, idem but for polyglossia

- nil

- any other arbitrary string?

If the user loads babel or polyglossia explicitly, with AUTO and all
that, then the current rules in
org-latex-guess-babel/polyglossia-language would be applied.

WDYT?

Best regards,

Juan Manuel

Re: [PATCH] lisp/org.el: Fix `org-fill-paragraph' in lists when `mark-active'

[Renato Ferreira]

On Tue, 19 Jul 2022 19:36:35 +, Sébastien Miquel 
 said:

> This should be fixed on main. If not, please say so.

It's fixed. Thank you very much.

-- 
Att.,
Renato Ferreira

Re: The fate of ob-asymptote.el

[Nick Dokos]

Jarmo Hurri  writes:

> ...
>
> I would like ob-asymptote.el to be brought back. If there is something I
> can do to help, I will be glad to do so.
>
All you have to do is volunteer to maintain it. Let Bastien know: he will
assign you the maintenance of the file and all the asymptote users will owe
you a debt of gratitude.

See https://orgmode.org/worg/org-contribute.html, the bullet with the title
"Maintain an Org file".

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

[BUG] org-attach-id-ts-folder-format fails on customized IDs [9.6 (9.6-??-2e9999783)]

[Janek F]

When setting org-id-method to 'ts or 'org,
org-attach seems to use org-attach-id-ts-folder-format
to create its hierarchy.

However I tend to customize IDs for important files by hand,
causing any attempt to use org-attach on that file to fail
if the ID is shorter than six characters:

    org-attach-id-ts-folder-format: Args out of range: "ftt", 0, 6

This method should be adjusted to handle non-ts-ids just as well,
as org-id-method does not dictate the format of existing ids.

Regards,
Janek

[BUG] Markdown export broken without toc and with broken links [9.6 (9.6-??-e9da29b)]

[Janek F]

Hello,

With the following configuration (on top of vanilla Doom, but that doesn't seem 
to be related), when trying to export to Markdown an org-mode file with broken 
links, the export omits all content under headlines:

(setq org-export-with-toc nil
  org-export-with-broken-links 't)

For Example:

Test [[id:broken]]
* Headline
This is not exported

exports to:

Test

The position of the broken link does not matter, just that there is one.

Regards,
Janek

Re: org-ref 3 setup

[John Kitchin]

indeed, you should only use that before parsing hook for non-latex exports.

See the documentation for  org-export-before-parsing-hook. You need to
write a function that takes one argument and does nothing for latex, and
calls the csl processor otherwise.
perhaps something like this:

(defun org-ref-preprocessing (backend)
  (unless (eq backend 'latex)
(org-ref-csl-preprocess-buffer backend)))

(setq org-export-before-parsing-hook '(org-ref-preprocessing))


John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
https://kitchingroup.cheme.cmu.edu
https://pointbreezepubs.gumroad.com/ pycse bookstore



On Wed, Jul 20, 2022 at 10:48 AM Joseph Vidal-Rosset <
jos...@vidal-rosset.net> wrote:

>
> Le 20/07/2022 à 16:20, Joseph Vidal-Rosset a écrit :
> >
> >
> > Le 20/07/2022 à 15:38, John Kitchin a écrit :
> >
> >> (let  ((org-export-with-broken-links t)
> >>(org-latex-pdf-process
> >>  '("pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o %f"
> >>   "bibtex %b"
> >>   "makeindex %b"
> >>   "pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o %f"
> >>   "pdflatex -interaction nonstopmode -shell-escape
> >> -output-directory %o
> >> %f")))
> >> (org-open-file (org-latex-export-to-pdf)))
> >>
> >>
> >> this doesn't do anything in your init file to change anything. it only
> >> temporarily (let) defines some variables, and then tries to export the
> >> current buffer (an elisp file) to pdf and open it. that is a mistake
> >> to try.
> >
> > You are certainly right. I believe that these lines block a
> > configuration file that is responsible for the fact that the export via
> > pdflatex does not work correctly. This file is therefore loaded after
> > myorgexport.el, like mysnippets.el  that is not loaded, for example. It
> > is also possible that myorgexport.el itself is somewhere incorrect.
> >
> > I will go to make tests, I'll keep you informed.
>
> The BIG advantage of launching Emacs Prelude with emacs --daemon is that
> it is possible to identify (with your help in this case, John) the
> reason of  a problem in such or such setup, every personal setup being
> located in possible several small files  ~/.emacs.d/personal/myfile1.el,
>   ~/.emacs.d/personal/myfile2.el, etc.
> (I am really thankful to Bozhidar Batsov - hence this cc. to his email
> address - and to all the contributors of Prelude Emacs, and I recommend
> this nice starter kit for Emacs.)
>
> John, you kindly gave me a solution to get the bibliography in an html
> email exported via gnus and orgmode, and in my
> .emacs.d/personal/myorgmime.el I had this line of code:
>
> > (setq org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))
> ;; to get the bibliography in email (thanks to John Kitchin)
>
> Deactivated, the export in pdflatex works correctly for the
> bibliography... I now have to find a coherent way to get both exports of
> bibliography...
>
> Many thanks John for your so kind, so constant, and so patient help !
>
> All the best,
>
> Jo.
>
>

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Max Nikulin]

On 20/07/2022 02:31, Juan Manuel Macías wrote:

Max Nikulin writes:


On 19/07/2022 22:01, Juan Manuel Macías wrote:

+(replace-match
+ (mapconcat (lambda (option) (if (equal "AUTO" option) language
option))
+ (cond ((member language options) (delete "AUTO" options))
+ ((member "AUTO" options) options)
+ (t (append options (list language
+", ")


In my opinion this code should not attempt to be excessively clever.
If user skipped AUTO then do not append language. Test for duplicated
options is redundant as well. Such cases may still be a reason to
issue a warning (e.g. by `org-lint').


I completely agree. I've kept that old part of the code for backwards
compatibility and because, at the end of the day, it doesn't break
anything new.


I am sorry, I missed the old code below the added lines.


On the other hand I would consider adding babel by default without
explicit header. To suppress loading users may add
#+latex_header: % \usepackage{babel}


I don't understand this very well. What would happen, then, to users who
prefer to use Polyglossia, or those who prefer to explicitly add babel
or polyglossia code?


Certainly if polyglossia or explicit babel related commands are detected 
then default babel configuration is not added to preamble. The idea is 
to add babel if a user have not expressed her intentions explicitly.

Re: discovering export (and other) keywords?

[Max Nikulin]

On 18/07/2022 19:10, kevinbanjo wrote:


Also, for various elements (e.g. begin_src emacs-lisp, begin_export 
html, etc...) how do I discover what the acceptable keywords are, 
preferably without only having to go thru the manual pages?


For source blocks you may try `org-babel-view-src-block-info' (C-c C-v 
I, C-c C-v TAB).


org-contrib has org-eldoc.el that displays values of some header 
arguments when cursor is on a #+begin_src line. The code uses

(nth 2 (org-babel-get-src-block-info 'light))

Re: The fate of ob-asymptote.el

[Tory S. Anderson]

Not a major contributor to Org yet, but I have been using it faithfully for a 
decade. Asymptote looks to be incredibly useful in my research! Thanks for 
making me aware of it! https://asymptote.sourceforge.io/index.html

- Tory

The fate of ob-asymptote.el

[Jarmo Hurri]

Greetings.

Summary: I vote, very late, for the inclusion of ob-asymptote.el into
Org. In my opinion, Asymptote is far too valuable a tool to be excluded
by default.

Long version:

Either me or my system have been sleeping for quite a while, because
just today I woke up to the fact that ob-asymptote.el has been moved out
of Org and into org-contrib. According to org-contrib, this means that

Files in this repository receive little if no maintainance and there is
no guarantee that they are compatible with the Org stable version.

Not only is this a poor situation for me personally, but I also think it
is a bad decision for Org. I have been using the combination of Org and
Asymptote for all my work stuff for a long time now. The combo is simply
_superior_. I do not need to talk about Org, and will focus on Asymptote
only.

Asymptote is a _brilliant__ tool for drawing all sorts of (scientific)
diagrams, be those 2D or 3D (click on menu on left to view different
galleries):

https://asymptote.sourceforge.io/gallery/

Asymptote has been a stable programming language for quite a while:

https://asymptote.sourceforge.io/

It is being actively maintained and upgraded.

If ob-asymptote.el is kept external to Org, future users will have a
much higher threshold to use this combination.

I would like ob-asymptote.el to be brought back. If there is something I
can do to help, I will be glad to do so.

All the best,

Jarmo

Re: org-ref 3 setup

[Joseph Vidal-Rosset]

Le 20/07/2022 à 16:20, Joseph Vidal-Rosset a écrit :
>
>
> Le 20/07/2022 à 15:38, John Kitchin a écrit :
>
>>     (let  ((org-export-with-broken-links t)
>>        (org-latex-pdf-process
>>          '("pdflatex -interaction nonstopmode -shell-escape
>>     -output-directory %o %f"
>>           "bibtex %b"
>>           "makeindex %b"
>>           "pdflatex -interaction nonstopmode -shell-escape
>>     -output-directory %o %f"
>>           "pdflatex -interaction nonstopmode -shell-escape
>>     -output-directory %o
>>     %f")))
>>     (org-open-file (org-latex-export-to-pdf)))
>>
>>
>> this doesn't do anything in your init file to change anything. it only
>> temporarily (let) defines some variables, and then tries to export the
>> current buffer (an elisp file) to pdf and open it. that is a mistake
>> to try.
>
> You are certainly right. I believe that these lines block a
> configuration file that is responsible for the fact that the export via
> pdflatex does not work correctly. This file is therefore loaded after
> myorgexport.el, like mysnippets.el  that is not loaded, for example. It
> is also possible that myorgexport.el itself is somewhere incorrect.
>
> I will go to make tests, I'll keep you informed.

The BIG advantage of launching Emacs Prelude with emacs --daemon is that
it is possible to identify (with your help in this case, John) the
reason of  a problem in such or such setup, every personal setup being
located in possible several small files  ~/.emacs.d/personal/myfile1.el,
  ~/.emacs.d/personal/myfile2.el, etc.
(I am really thankful to Bozhidar Batsov - hence this cc. to his email
address - and to all the contributors of Prelude Emacs, and I recommend
this nice starter kit for Emacs.)

John, you kindly gave me a solution to get the bibliography in an html
email exported via gnus and orgmode, and in my
.emacs.d/personal/myorgmime.el I had this line of code:

> (setq org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer))  ;; to 
> get the bibliography in email (thanks to John Kitchin)

Deactivated, the export in pdflatex works correctly for the
bibliography... I now have to find a coherent way to get both exports of
bibliography...

Many thanks John for your so kind, so constant, and so patient help !

All the best,

Jo.

Re: [feature] Allow "," decimal point in table cells (was: org-table with different conventions: decimals)

[Christian Moe]

Ihor Radchenko writes:

> Uwe Brauer  writes:
>
>>> Uwe Brauer  writes:
>>
>>> Org tables use Emacs' calc under the hood by default.
>>> AFAIK, calc is unable to use "," as decimal point because it is reserved
>>> as a vector separator. Which is why you got the vector addition in your
>>> example.
>>
>> Thanks. I was afraid that the issue was with calc not with org-mode.
>
> Note that you can instead use Elisp formulas. See 3.5.3 Emacs Lisp forms
> as formulas. It is more flexible.
>
> Alternatively, we may implement the comma separators as a built-in
> feature. Org table formulas already support notations like
>
> | 3,5 | 4,2 | 7 |
> #+TBLFM: $3=$1+$2;N
>
> or
>
> #+TBLFM: $3=$1+$2;E
> #+TBLFM: $3=$1+$2;L
>
> (see 3.5.2 Formula syntax for Calc)
>
> we may as well implement something like ";Nc" that will interpret cells
> as numbers with "," as decimal point separator.
>
> Is there such a demand?
>
> Best,
> Ihor

That's interesting.

I remember an earlier discussion that settled on the recommendation to
keep the spreadsheet as it is and use export-hooks if one needs to
change the decimal separator upon export. My contribution to the
discussion also gave Carsten the idea of starting a Worg page called
org-madness.org. :-).

Thread started here:
https://lists.gnu.org/archive/html/emacs-orgmode/2011-05/msg00551.html

But I don't think we considered the possibility of a flag to make Org
translate dot-separated decimals into comma-separated ones for
Calc. That could offer more fine-grained control than export processing
when you need some dots to stay dots. And it would certainly be less
challenging for users who just want things to work without digging into
advanced export options!

Export processing (which has since become more fine-grained with the
introduction of filters) remains an option, though, and some backends
offer further possibilities.

Yours,
Christian

Re: [feature] Allow "," decimal point in table cells

[Ihor Radchenko]

Uwe Brauer  writes:

>> Note that you can instead use Elisp formulas. See 3.5.3 Emacs Lisp forms
>> as formulas. It is more flexible.
>
> Can you give me an example?

#+begin_src emacs-lisp
(defun yant/convert-cd (x)
  "Replace \",\" in X string with \".\" and return number."
  (string-to-number (replace-regexp-in-string "," "." x)))
(defun yant/convert-dc (x)
  "Replace \".\" in X number with \",\" and return string."
  (replace-regexp-in-string "\\." "," (format "%s" x)))
#+end_src

| 3,5 | 4,2 | 7,7 |
#+TBLFM: $3='(yant/convert-dc (apply '+ (mapcar #'yant/convert-cd (list $1 
$2

Yes, it is awkward. Yet possible.

>> Alternatively, we may implement the comma separators as a built-in
>> feature. Org table formulas already support notations like
>
>> | 3,5 | 4,2 | 7 |
>
>> #+TBLFM: $3=$1+$2;N
>
> Not sure I understand this 
>
> | 3,5 | 4,2 | 7 | (7, 7) | (7, 7) |
> | | |   |||
> #+TBLFM: $3=$1+$2;N::$4=$1+$2;E::$5=$1+$2;L

;N means "convert to number using string-to-number".
(string-to-number "3,5") ;; => 3
why? read the docstring (it ignores non-recognized trailing chars ",5")

L makes no sense in calc formulas (it has no effect).

E refers to dealing with empty field and has no effect here.

Best,
Ihor

Re: org-set-properties for various (all) headings

[Kaushal Modi]

On Wed, Jul 20, 2022 at 4:07 AM Uwe Brauer  wrote:

> 2. Second code
>
> (defun test/set-property-at-heading ()
>   "Function to be called at the beginning of an Org heading."
>   (interactive)
>   (let ((el (org-element-at-point)))
> ^el is defined but not used.
> (org-set-property "New" "[ ]")))
> (org-map-entries #'test/set-property-at-heading)
>

Correct. The el variable is not required here. It's a relic from the
previous version of that function.


> A.11 Using the Mapping API
> > A.10 Using the Property API
>
> Is this a reference to the manual?
>

Yes. You can access those from within Emacs as Info manuals:

- (org) Using the Mapping API - online

- (org) Using the Property API - online

Re: org-ref 3 setup

[Joseph Vidal-Rosset]

Le 20/07/2022 à 14:15, John Kitchin a écrit :
> I assume you are trying something new here?

Not really; my setup worked to export to pdf via latex with org-ref, but
it is no longer the case, and I do not know why.

> the problem is that block is executed and it should not be. That is a
> temporary bit of code for export within an org-file. the error comes
> from it trying to export an elisp file to pdf.
>
> The only correct thing you could do is this:
>
> (setq org-export-with-broken-links t
>        org-latex-pdf-process
>          '("pdflatex -interaction nonstopmode -shell-escape
> -output-directory %o %f"
>           "bibtex %b"
>           "makeindex %b"
>           "pdflatex -interaction nonstopmode -shell-escape
> -output-directory %o %f"
>           "pdflatex -interaction nonstopmode -shell-escape
> -output-directory %o
> %f"))

Thanks ! now emacs --deamon works smoothly, but unfortunately I get this
message when I try to export my org file via pdflatex:

> Wrote 
> /home/joseph/Dropbox/Mes_articles_soumis/jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.tex
> Processing LaTeX file 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.tex...
> This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
> (preloaded format=pdflatex)
>  \write18 enabled.
> **
> ! End of file on the terminal... why?
> /bin/bash: ligne 2: -output-directory : commande introuvable
> This is BibTeX, Version 0.99d (TeX Live 2020/Debian)
> The top-level auxiliary file: 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.aux
> The style file: smfplain.bst
> I found no \citation commands---while reading file 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.aux
> I found no \bibdata command---while reading file 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.aux
> (There were 2 error messages)
> Couldn't find input index file 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr nor 
> jvr-bivalence-futurs-contingents-intuitionnisme-smfart-fr.idx.
> Usage: makeindex [-ilqrcgLT] [-s sty] [-o ind] [-t log] [-p num] [idx0 idx1 
> ...]
> PDF file produced with errors.

The pdf file indeed is not what that could be expected.

:(

If I come back to

(let  ((org-export-with-broken-links t)
  (org-latex-pdf-process
'("pdflatex -interaction nonstopmode -shell-escape
-output-directory %o %f"
 "bibtex %b"
 "makeindex %b"
 "pdflatex -interaction nonstopmode -shell-escape -output-directory %o 
%f"
 "pdflatex -interaction nonstopmode -shell-escape -output-directory %o
%f")))
   (org-open-file (org-latex-export-to-pdf)))

in ~/.emacs.d/personal/myorgexport.el

then emacs --daemon protests, but the export works correctly...

All the best,

Jo.

Re: Confused about source code blocks evaluation when exporting

[Fraga, Eric]

On Wednesday, 20 Jul 2022 at 14:12, alain.coch...@unistra.fr wrote:
> At any rate, and as I already said, all this business became
> irrelevant for me once latexmk was installed: no need then to set
> org-latex-pdf-process.  This became only a matter of better
> understanding some of the org intricacies.

Maybe try this for your local variables (at the end of the org file):

# Local Variables:
# org-latex-pdf-process: ("lualatex %f" "bibtex %b" "lualatex %f" "lualatex %f")
# End:

as a test (adjusting as you see fit)?  This works for me.  No need to
use BIND.

-- 
: Eric S Fraga, with org release_9.5.4-648-gdf1814 in Emacs 29.0.50

[PATCH] org-manual: Document `org-babel-default-inline-header-args'

[Ihor Radchenko]

Hi,

In https://orgmode.org/list/87ee927emf.fsf@localhost I proposed to
document org-babel-default-inline-header-args in the manual.

Here is the patch.

WDYT?

Also, I noticed that org-babel-default-header-args has :hlines "no"
while org-babel-default-inline-header-args has :hlines "yes"

The "yes" value can cause errors as documented in the manual (16.6
Results of Evaluation). I am not sure if it is a good default. Also, the
commit introducing the change does not provide any details on why it was
there to start with:

c67e3cda1 default to preserving hlines in call lines
* lisp/ob-core.el (org-babel-default-inline-header-args):
  Added (:hlines "yes") to the default value.

Does anyone know any reason why "yes" value should be kept for inline
src blocks in contrast with "no" for normal src blocks?

I'd be better if we can explain this in the manual.

Best,
Ihor

>From 51b10e5ca5bb368e71655466a4be5267e6e99d0f Mon Sep 17 00:00:00 2001
Message-Id: <51b10e5ca5bb368e71655466a4be5267e6e99d0f.1658319102.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Wed, 20 Jul 2022 20:03:37 +0800
Subject: [PATCH] org-manual: Document `org-babel-default-inline-header-args'

* doc/org-manual.org (System-wide header arguments): Update the
default value of `org-babel-default-header-args'.  Document that
inline source blocks use a different set of the default arguments.
---
 doc/org-manual.org | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 26d18f533..7823fbd74 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17015,8 +17015,31 @@ *** System-wide header arguments
 :exports=> "code"
 :cache  => "no"
 :noweb  => "no"
+:hlines => "no"
+:tangle => "no"
 #+end_example
 
+#+vindex: org-babel-default-inline-header-args
+Inline source blocks (see [[*Structure of Code Blocks]]) use slightly
+different default header arguments defined in
+~org-babel-default-inline-header-args~:
+
+#+begin_example
+:session=> "none"
+:results=> "replace"
+:exports=> "results"
+:hlines => "yes"
+#+end_example
+
+The most notable difference between default header arguments for
+inline and normal source blocks is =:exports= argument.  For inline
+source blocks, results of evaluation are exported by default; not the
+code.
+
+Unlike the default values, header arguments set using Org mode
+properties (see [[*Header arguments in Org mode properties]]) do apply to
+both the normal source blocks and inline source blocks.
+
 The example below sets =:noweb= header arguments to =yes=, which makes
 Org expand =:noweb= references by default.
 
-- 
2.35.1

Re: Confused about source code blocks evaluation when exporting

[Alain . Cochard]

Fraga, Eric writes on Thu 14 Jul 2022 08:35:
 > On Thursday, 14 Jul 2022 at 10:09, alain.coch...@unistra.fr wrote:
 > > #+begin_src emacs-lisp
 > > (setq org-latex-pdf-process )
 > > #+end_src
 > >
 > > which I want to be evaluated during export but I want neither the code
 > > not its results to appear on the exported pdf file.
 > >
 > > Maybe there are smarter ways to achieve this goal, but it was an
 > > opportunity for me anyway to start understanding this evaluation
 > > business.
 > 
 > For this kind of setting, I use file local variables and #+bind:.
 > Evaluating this code snippet during the export process is probably not
 > what you want.  You want it set prior to exporting?

Thanks a lot.

I don't know if I want to set org-latex-pdf-process _during_ or
_prior_ exporting.  All I wanted to do is to _not_ set it in the emacs
init file, so as to be able to set a specific value depending on
whether I was going to use natbib or biblatex, without having to
restart emacs.

I tried doing something with what you suggest (using #+bind:), but
failed:

I put the following at the end of my org file (then visited the file
again):

# Local Variables:
# org-export-allow-bind-keywords: t
# End:

As I was not sure about the bind syntax for the complicated
org-latex-pdf-process variable, I tried this first test:

#+bind: org-latex-pdf-process "dummy"
# (I also tried without the quotes)
#+cite_export: natbib plainnat
#+bibliography: cite.bib
[cite:@chouet88] 

And then 'C-c C-e l o'.  There is no error but the generated pdf is
not correct, because (as mentioned some days ago)
org-latex-pdf-process does not have the proper value.

In other words, '#+bind:' does not work as expected.

(By contrast, if I use "my" method, using

#+begin_src emacs-lisp :exports results
(setq org-latex-pdf-process 'dummy)
#+end_src

then, after 'C-c C-e l o' I get "org-latex-compile: Wrong type
argument: sequencep, dummy".
)

This post

https://emacs.stackexchange.com/questions/47474/setting-variable-for-org-mode-html-export

looked promising, but it also points to this one

https://stackoverflow.com/questions/41964712/how-does-bind-really-works/42012392#42012392

which looks less so...


At any rate, and as I already said, all this business became
irrelevant for me once latexmk was installed: no need then to set
org-latex-pdf-process.  This became only a matter of better
understanding some of the org intricacies.

Thank you again for your time.



















-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 106]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: numbering src blocks in HTML export

[Juan Manuel Macías]

Ihor Radchenko writes:

> AFAIU, source block switches are never inherited.
>
> Dear All, may we should provide a normal header arg as an equivalent of
> switches? Honestly, this whole switch syntax sounds unnecessary and only
> over-complicates things.

I think that web pages or documents that contain several code examples
(tutorials, documentation, etc.) tend to unify the style in this regard:
either all examples are line-numbered or all examples are unnumbered;
therefore, if the first option is chosen, it would be good to have some
global setting, when there are many blocks. But I also think this can be
easily achieved with some function locally hooked to
org-export-before-processing-hook. Or even within the document on the
fly.

A global 'factory setting' would also have the extra complication that
there would be two global numbering versions (at least): a) a separate
numbering for each block; b) each block continuing the numbering of the
previous block. And there could be a subtype of b) where it is necessary
to restart the numbering when starting a new section. Or a) and b) could
be arbitrarily mixed in the same document. All this seems complicated
to implement...

But one thing that could be nice is to give an option (perhaps with a
prefix argument) for org-babel-demarcate-block (C-c C-v C-d) to inherit
the switches:

before:

#+begin_src emacs-lisp -n
a
a
a
a
a
a
#+end_src

after C-c C-v C-d

#+begin_src emacs-lisp -n
a
a
a
#+end_src

#+begin_src emacs-lisp +n
b
b
b
#+end_src


Best regards,

Juan Manuel 

size restriction on columnview?

[Uwe Brauer]

Hi

I have a document with around 110 headings
each heading has 

20 different properties, however there seems to be limit.

The following columnview will indeed display all the properties of all
the headings in table form.

#+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :hlines 1 :indent nil  
:format "%5TODO(Status) %SUMMARY(Sum)  %5NR(Nr) %5ITEM(Stuff) %5RG-Date(R-Date) 
%5Amount(Amount)  %5User1(User1){X/} %5User2(User2){X/} %5An_Company1(An 
Company1) %5An_Firm(An Firm) %5Von_Company1(Von Company1) %5Geld_Company1(EUR 
Company1) %5Von_Firm(Von Firm) %5Geld_Firm(EUR Firm) %5All(All) %5Author(Autor) 
%5Diff(Diff)"

However when I add *one* property more to the columnview format entry
then the resulting table will only show around 15 headings (that is the
table has only 15 rows).

Any comments? I am really puzzled.

-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

Re: @string abbreviation in bib file not honored in (basic) org-cite

[Joost Kremers]

On Tue, Jul 19 2022, Bruce D'Arcus wrote:
>> So does this mean there is no longer any reason to add parsebib to (Non-)GNU
>> ELPA?
>
> No, since parsebib is an important dependency for citeproc-el, and
> Ihor was suggesting Andras try to get that in ELPA.

Ok, thanks. Sending my copyright assignment now...

-- 
Joost Kremers
Life has its moments

Re: numbering src blocks in HTML export

[Fraga, Eric]

On Wednesday, 20 Jul 2022 at 11:58, Ihor Radchenko wrote:
> AFAIU, source block switches are never inherited.

Thank you for confirming.  It's easy enough for me to change all of my
src blocks with a single Emacs command.  And that's why "it's all text"
is so important! :-)

> may we should provide a normal header arg as an equivalent of
> switches?

Sounds like a reasonable idea.  I think they are possibly a holdover
from text blocks for examples, pre-babel?

-- 
: Eric S Fraga, with org release_9.5.4-643-g057df6 in Emacs 29.0.50

org-ref 3 setup

[Joseph Vidal-Rosset]

Hello John, (cc. list emacs-orgmode)

I have a problem with my emacs setup that is in relation with org-ref 3.

My emacs version is  29.0.50, via Prelude emacs, and my emacs is
launched with "emacs --daemon" .

Here is the error:

> Loading /home/joseph/.emacs.d/personal/myorgexport.el (source)...
> Output file:
> Warning (initialization): An error occurred while loading 
> ‘/home/joseph/.emacs.d/init.elc’:
>
> Wrong type argument: stringp, nil
>
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file.

With emacs --debug-init, emacs asks also an output file.

the following last lines of (i.e. the end of my orgexport.el)  are
necessary to org-ref :

(let  ((org-export-with-broken-links t)
  (org-latex-pdf-process
'("pdflatex -interaction nonstopmode -shell-escape
-output-directory %o %f"
 "bibtex %b"
 "makeindex %b"
 "pdflatex -interaction nonstopmode -shell-escape -output-directory %o 
%f"
 "pdflatex -interaction nonstopmode -shell-escape -output-directory %o
%f")))
   (org-open-file (org-latex-export-to-pdf)))

It also seems obvious that "org-open-file" is the cause of my (small)
problem.

Your help will be welcome.

All the best,

Jo.

heading with properties--> list?

[Uwe Brauer]

Hi

The following works nicely
#+begin_src 
* Over
  :PROPERTIES:
  :ID:   ef19f286-8769-4fe7-8f95-8167691257a0
  :COLUMNS:  %5TODO(Status) %5NR(Nr)
  :foo:  Over
  :NEW:  [0/3]
  :END:
** TODO Test
   :PROPERTIES:
   :Sent: [X]
   :New:  [ ]
   :END:

** WAIT Test2
   :PROPERTIES:
   :Sent: [X]
   :New:  [ ]
   :END:

** TODO Test3
   :PROPERTIES:
   :Sent: [ ]
   :New:  [ ]
   :END:




#+BEGIN: columnview :maxlevel 2 :skip-empty-rows t :hlines 1 :indent nil  
:format "%5TODO(Status) %5Sent(Sent){X/} %New(New){X/}"
| Status | Sent  | New   |
|+---+---|
|| [2/3] | [0/3] |
| TODO   | [X]   | [ ]   |
| WAIT   | [X]   | [ ]   |
| TODO   | [ ]   | [ ]   |
#+END:
#+end_src


However if I have very many Properties that table can get very wide.

Is there any function that would convert these headings into simple lists with 
sublist, such as

#+begin_src 
1. TODO Test
   1. [X] Sent
   2. [ ] New
2. TODO Test2
   1. [X] Sent
   2. [ ] New
3. TODO Test3
   1. [X] Sent
   2. [ ] New
#+end_src





-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 

Re: org-set-properties for various (all) headings

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> Two comments though
>> 
>> 1. It works, if the source block is at the beginning of the file 
>> 
>> 2. I confess I don't understand anymore the use of `(let ((el 
>> (org-element-at-point)))':
>> 
>> a. In your first version you used the defined «el», but know you
>> don't, hm just saying.

> That's because the first version used the actual headline title as a
> value of the property. That values had to be acquired somehow.
> org-element API was used.

I expressed myself rather badly 

1.  First code

(defun test/set-property-at-heading ()
  "Function to be called at the beginning of an Org heading."
(interactive)
  (let ((el (org-element-at-point)))
(org-set-property "foo" (org-element-property :title el
 ^el is used
(org-map-entries #'test/set-property-at-heading)


2. Second code

(defun test/set-property-at-heading ()
  "Function to be called at the beginning of an Org heading."
  (interactive)
  (let ((el (org-element-at-point)))
^el is defined but not used.
(org-set-property "New" "[ ]")))
(org-map-entries #'test/set-property-at-heading)







>> In any case thanks again for this very valuable advice. I suggest to
>> include it somehow in the documentation, since I believe that other
>> users have encountered similar situations.

> A.11 Using the Mapping API
> A.10 Using the Property API

Is this a reference to the manual?





smime.p7s
Description: S/MIME cryptographic signature

Re: org-set-properties for various (all) headings

[Ihor Radchenko]

Uwe Brauer  writes:

> Two comments though
>
> 1. It works, if the source block is at the beginning of the file 
>
> 2. I confess I don't understand anymore the use of `(let ((el 
> (org-element-at-point)))':
>
>a. In your first version you used the defined «el», but know you
>   don't, hm just saying.

That's because the first version used the actual headline title as a
value of the property. That values had to be acquired somehow.
org-element API was used.

> In any case thanks again for this very valuable advice. I suggest to
> include it somehow in the documentation, since I believe that other
> users have encountered similar situations.

A.11 Using the Mapping API
A.10 Using the Property API

:)

Best,
Ihor

Re: discovering export (and other) keywords?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> kevinbanjo writes on Mon 18 Jul 2022 05:10:
>  > this page:
>  > 
>  > 
> https://orgmode.org/manual/Macro-Replacement.html#index-macro-replacement_002c-during-export
>  > 
>  > says:
>  > 
>  > Org also recognizes macro references in keywords, such as ‘CAPTION’, 
> ‘TITLE’,
>  > ‘AUTHOR’, ‘DATE’, *and for some back-end specific export options.*
>  > 
>  > How do I discover what those back end specific options are?
>
> I am guessing it would be difficult to maintain a list of these
> options.  On the other hand it should be quick for you to check for a
> specific one.

We actually do. For example, "Beamer specific export settings" section
of the manual lists all the settings for ox-beamer. If something is
missing from the manual, let us know, and we will fix it.

Meanwhile, I think that we can clarify what "some back-end specific
export options" refer to:

Org also recognizes macro references in keywords, such as ‘CAPTION’,
‘TITLE’, ‘AUTHOR’, ‘DATE’, and for some back-end specific export
options (detailed in the relevant sections of the manual).

Will it be more clear?

Another possibility could be changing the format of options alist when
defining export backend. We may allow an optional (but recommended)
docstring field to be provided when defining a backend and its options.
Such docstring can then be used in hypothetical
org-export-describe-backend command that will generate something similar
to M-x describe-mode documentation. This new command cal also be added
to the export menu for easy access. WDYT?

>  > Also, for various elements (e.g. begin_src emacs-lisp, begin_export html,
>  > etc...) how do I discover what the acceptable keywords are, preferably
>  > without only having to go thru the manual pages?
>
> I don't think you can avoid going through the manual.  My experience
> is that it is painful anyway.  I would advise you to start from the
> few examples provided in the manual and try to adapt to your case;
> when an (as simple as possible) example does not work as you would
> expect, ask the list; there is a good chance that a good Samaritan
> will have pity for you and answer.

Because keywords may be specific to a backend and there are also
third-party backends, we cannot easily provide such information
on-the-fly - Org has no idea about the intended export backend when you
type in an Org document; not to mentioned that there may be multiple
intended backends.

Best,
Ihor

Re: [PATCH] Re: [BUG] Set org-format-latex-options in .dir-locals.el [9.5.1 (release_9.5.1-11-g96d91b @ emacs-28.0.90/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> The fix is attached.

Fixed.
Applied onto main via df1814b83.

Re: `org-capture' loads all the files in `org-directory'

[Ihor Radchenko]

Noel Errenil  writes:

> Currently, I'm happy with this behavior. I'll learn how to submit a
> feature request
> anyway in case in the future I feel a need to.

Feature request is nothing but an email with justification why some new
feature will be useful for many users.

> After your first reply earlier, I came to realize that the pop-up
> buffer in which I am
> able to select a template is indeed some kind of agenda view/mode. This can be
> confirmed by looking up the source code. So my original problem indeed had sth
> to do with agenda, not `org-capture'.

Nope. It's just that agenda and capture template selection use similar
menus. The reason why Org opened agenda files was solely related to
collection of all the tags and offering them in the completion dialogue
during capture.

> Then I found my setting of `org-agenda-files' was indeed wrong:
>
> Sth like:
> (setq org-agenda-files ("~/projects/org/agenda.org"))
>  ;; ^^
> empty file at the moment
> will actually make the whole ~/projects/org directory as the agenda source,
> hence all the files under it will be loaded once agenda function is activated.
>
> I did that, again, because I misunderstood the manual. I should use a
> list for agenda files
> or a plain text file in which I specify agenda files, one per line.

That's one option. Generally, you can check out about the possible
settings for a variable by examining the variable documentation:
 v variable-name 
In your case:
 v org-agenda-files 

Best,
Ihor