Re: [BUG] Incorrect background color [9.5.4 (release_9.5.4-3-g6dc785 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Rudolf Adamkovič  writes:
>
>> The Org Babel R documentation at
>>
>> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html
>>
>> says that
>>
>>> the background color defaults to "transparent"
>>
>> but it defaults to white.
>
> Confirmed.
>
> WORG page is not accurate here. The truth is that ob-R.el does not provide
> any defaults for header args. Instead, R defaults are used. I suspect
> that defaults for background color changed in R since the WORG page has
> been written.

Jeremie, could you please take a look?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [O] Bug: org-agenda-category-filter-preset in org-agenda-custom-commands with org-agenda-sticky does not work [9.1.2 (release_9.1.2-99-g4d828b @ /home/cperl/git/org-mode/lisp/)]

[Ihor Radchenko]

Chris Perl  writes:

> When using org-agenda-custom-commands with
> org-agenda-category-filter-preset and org-agenda-sticky, it seems as
> though changes to org-agenda-category-filter are global, even though
> the variable is made buffer local.
>
> From the limited digging I've done, it seems that setting the
> :preset-filter property for org-agenda-category-filter affects all
> agenda buffers, not just one.

And... finally should be fixed.
See https://orgmode.org/list/87edvochb7@gmail.com.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] org-manual: Remove mention of print edition

[Gregor Zattler]

Hi Bastien,
* Bastien  [2022-10-16; 07:48 +02]:
> I think it is good to remember that Network Theory Ltd. was the
> original publisher of the printed manual, as people may find others
> options online now.

Yes, one can still buy the book used online.  But then
again: Version 7.3 was released 12 years how useful is this
manual now?

But I'm OK both ways.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Re: [O] inheritance of mutually exclusive tags

[Ihor Radchenko]

yanmcbe  writes:

> Org-mode allows marking a set of tags as mutually exclusive. It also allows
> the inheritance of tags.
>
> (from now on I am talking only about these mutually exclusive tags)
>
> When a tag is set in a parent, but also in a child, what I expect to happen
> is that the child is not included in searches/selections with the parent
> tag.
>
> In the example [0], a search for black (e.g. C-/ m black ) should not
> match poodle, because it is white.
>
> Now I realize that the mutually exclusive tag concept is probably only a
> convenience for adding tags with C-c. And it doesn't seem to have any other
> implications, but it would be nice to have. Do you think this is a
> possibility or that I could get this behaviour some other way?

It took many years, but I can still reproduce.
Confirmed.

And it is no easier to fix...

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX

[Max Nikulin]

On 16/10/2022 04:35, Juan Manuel Macías wrote:


To begin with, it is a particular solution
applied in a general way. This can have unexpected consequences, as has
happened in verse blocks.


In my opinion Org has to apply a general solution merely because a table 
may be result of evaluation of an org-babel code block. I may be wrong, 
but I suspect that some users do not care what is the intermediate 
format when they need a PDF file.



And finally, I think that applying a general solution to this problem is
something that should be done(IMHO) in LaTeX and not in Org,


Org has a bit more information concerning context of square brackets. 
They may be just text of a table cell or contents of an export snippet. 
In a LaTeX file they are just square brackets and there is no way to 
distinguish them.


I believe, it is a design flaw in LaTeX that the \\ command does not 
have a counterpart with no optional * and [] arguments. For humans \\ is 
enough, but it is fragile when LaTeX is used as an intermediate export 
format. A part of the problem is that all 3rd party packages should be 
adapted for the robust \\ sibling. Likely it may be solved by additional 
pass in the exporter code but it will significantly increase its 
complexity. I have no idea what is appropriate place to discuss such 
issue with LaTeX developers.


The following is irrelevant to the recent changes. I have tried

 >8 
text
#+begin_verse

a b
c d

e f
g h
#+end_verse
 8< 

With the fix Ihor committed today I have got

 >8 
text
\begin{verse}
\vspace*{1em}
a b\\\empty
c d\\\empty
\vspace*{1em}
e f\\\empty
g h\\\empty
\end{verse}
 8< 

My expectation was
 >8 
\begin{verse}
a b\\\empty
c d

e f\\\empty
g h
\end{verse}
 8< 

I am surprised that \vspace is added instead of empty line between 
stanzas. Is there a reason to override LaTeX defaults? If such reason 
exists would not it better to add


\parskip=1em plus 0.5em minus 0.25em\relax

before first verse line? Is hard coded rigid vertical space acceptable 
when high quality output is desired? \vspace before first line looks 
like a bug. Frankly speaking, nested calls of `replace-regexp-in-string' 
makes the code hard to read.


P.S. I have not found exact citation, but I noticed a mention: Lamport 
expected that verse environment would get negative feedback from poets.

Re: Best android app

[Max Nikulin]

On 16/10/2022 14:32, Jean Louis wrote:

* Max Nikulin [2022-10-16 08:28]:

I do not have strong opinion concerning proprietary application.
Requirements for worg section as driven by user content are not so strict as
for the main part of the Org site that must adhere to FSF rules. Perhaps it
is possible to separate non-free software by some discouraging
disclaimer.


If I am not mistaken, you propose or initiate discussing how to list
proprietary software on some websites.


You are mistaken. I do not care if such discussion will happen. However 
I do not mind to have a peer reviewed list somewhere. It may be helpful 
to figure out what features and what workflows have not covered by free 
software yet.


For me it is different to not endorse non-free software and to pretend 
that such applications do not exist at all.



GNU mailing lists are not for such discussions. GNU is project is
there to foster full free software.


Besides it is a GNU mailing list, I believed, it is dedicated to Org. To 
my surprise in this thread some lightening detector was suggested. The 
original question in this topic was about a *best* app, but a response 
was to search *existing* applications with no comments concerning 
particular ones:



Try these Org applications for Android:

https://search.f-droid.org/?q=org+mode=en


There were no details concerning usage patters in the original question, 
so it is hard give suitable suggestion without requesting more 
information, but such response due to lack of additional comments is 
quite close to "search yourself". So from my point of view, there are 
enough posts hardly relevant to the asked question.


To be clear, I think that the value of the FAQ entry is more than just 
links to other projects. I see nothing wrong that the proposal to extend 
the entry by ypuntot contained just links. My point is that when being 
added to FAQ, the links should be augmented by comments based on usage 
experience. Just extensive list of ever existed projects is hardly helpful.


P.S. Searching archives of this mailing list for particular applications 
indirectly mentioned in this thread may provide some user opinions.

[BUG] org-fold-hide-entry hide the first subtree under a heading if the heading has no content [9.5.5 (9.5.5-gcb1359 @ /home/user/meow-emacs/straight/build/org/)]

[k_foreign]

Hello everyone, I found if you org-fold-hide-entry on a heading without
content but with subtrees, the first subtree will be folded, for
example (>|< meas cursor):

* H>||

Re: Best android app

[Juan Manuel Macías]

Ihor Radchenko writes:

> Jean Louis  writes:
>
>> If I am not mistaken, you propose or initiate discussing how to list
>> proprietary software on some websites.
>>
>> GNU mailing lists are not for such discussions. GNU is project is
>> there to foster full free software. 
>
> Do you know where this rule is documented?

Documented or undocumented, it's common sense. This is a mailing list of
the GNU project, and it is hoped that this list will not recommend the
use of unethical software that does not comply with the GNU philosophy.

Verse block and separations (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)

[Juan Manuel Macías]

Max Nikulin writes:

> The following is irrelevant to the recent changes. I have tried
>
>  >8 
> text
>
> #+begin_verse
>
> a b
> c d
>
> e f
> g h
> #+end_verse
>
>  8< 
>
> With the fix Ihor committed today I have got
>
>  >8 
> text
> \begin{verse}
> \vspace*{1em}
> a b\\\empty
> c d\\\empty
> \vspace*{1em}
> e f\\\empty
> g h\\\empty
> \end{verse}
>  8< 
>
> My expectation was
>  >8 
> \begin{verse}
> a b\\\empty
> c d
>
> e f\\\empty
> g h
> \end{verse}
>  8< 
>
> I am surprised that \vspace is added instead of empty line between 
> stanzas. Is there a reason to override LaTeX defaults? If such reason 
> exists would not it better to add
>
>  \parskip=1em plus 0.5em minus 0.25em\relax
>
> before first verse line? Is hard coded rigid vertical space acceptable 
> when high quality output is desired? \vspace before first line looks 
> like a bug. Frankly speaking, nested calls of `replace-regexp-in-string' 
> makes the code hard to read.
>
> P.S. I have not found exact citation, but I noticed a mention: Lamport 
> expected that verse environment would get negative feedback from poets.

First of all, I'm afraid that in my previous post I mixed up two
different issues: the verse block bug and my personal opinions about the
new added constant. I should have separated these topics, sorry.

I answer here what you comment about the verse blocks and later I will
open a different thread for the other issue.

Yes, you're right: that \vspace is the normal behavior of the block when
exporting to LaTeX, and it is certainly not quite correct. In LaTeX,
both the out-of-the-box verse environment and the one provided by the
'verse' package (which, typographically speaking, is the correct way to
represent verses in LaTeX) do not add a \vspace between stanzas. In the
LaTeX input the separation between stanzas is expressed by an (at least)
empty line. In fact, that space can be controlled by the verse package
with the stanzaskip \length. I remember that I commented on this anomaly
here on the list, a long time ago, but I can't find the original
message...

In my init I have redefined the verse block like this, so that there is
a white line between stanzas, not \vspace (I have also added some things
for the verse package, so that the numbering of verses is not broken).
So your example would produce a white line under \begin{verse}, not the
current \vspace, which would be irrelevant to LaTeX. But this is only a
hack:

  (defun org-latex-verse-block (verse-block contents info)
"Transcode a VERSE-BLOCK element from Org to LaTeX.
  CONTENTS is verse block contents.  INFO is a plist holding
  contextual information."
(let*
((lin (org-export-read-attribute :attr_latex verse-block :lines))
 (latcode (org-export-read-attribute :attr_latex verse-block 
:latexcode))
 (cent (org-export-read-attribute :attr_latex verse-block :center))
 (attr (concat
(if cent "[\\versewidth]" "")
(if lin (format "\n\\poemlines{%s}" lin) "")
(if latcode (format "\n%s" latcode) "")))
 (versewidth (org-export-read-attribute :attr_latex verse-block 
:versewidth))
 (vwidth (if versewidth (format "\\settowidth{\\versewidth}{%s}\n" 
versewidth) ""))
 (linreset (if lin "\n\\poemlines{0}" "")))
  (org-latex--wrap-label
   verse-block
   ;; In a verse environment, add a line break to each newline
   ;; character and change each white space at beginning of a line
   ;; into a space of 1 em.  Also change each blank line with
   ;; a vertical space of 1 em.
   (format "%s\\begin{verse}%s\n%s\\end{verse}%s"
   vwidth
   attr
   (replace-regexp-in-string
"^[ \t]+" (lambda (m) (format "\\hspace*{%dem}" (length m)))
(replace-regexp-in-string
 "\\(\n\\)+\\([ \t]*\\)+" "\n"
 (replace-regexp-in-string
  "\\([ \t]*\\)?[ \t]*\n" "\n"
  (setq contents
(if lin
(replace-regexp-in-string "\\(\n\\)+\\([ 
\t]*\n\\)+" "!\n\n"
  contents)
  contents)) nil t) nil t) nil t) linreset)
   info)))

Line breaks and brackets in LaTeX export (was: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX)

[Juan Manuel Macías]

Max Nikulin writes:

> In my opinion Org has to apply a general solution merely because a table 
> may be result of evaluation of an org-babel code block. I may be wrong, 
> but I suspect that some users do not care what is the intermediate 
> format when they need a PDF file.
>
>> And finally, I think that applying a general solution to this problem is
>> something that should be done(IMHO) in LaTeX and not in Org,
>
> Org has a bit more information concerning context of square brackets. 
> They may be just text of a table cell or contents of an export snippet. 
> In a LaTeX file they are just square brackets and there is no way to 
> distinguish them.
>
> I believe, it is a design flaw in LaTeX that the \\ command does not 
> have a counterpart with no optional * and [] arguments. For humans \\ is 
> enough, but it is fragile when LaTeX is used as an intermediate export 
> format. A part of the problem is that all 3rd party packages should be 
> adapted for the robust \\ sibling. Likely it may be solved by additional 
> pass in the exporter code but it will significantly increase its 
> complexity. I have no idea what is appropriate place to discuss such 
> issue with LaTeX developers.

The solution of adding \relax or \empty is a good one. The problem is
when it is applied massively and indiscriminately, bearing in mind that
it is to prevent a problem that is, frankly, very rare. \empty is
unlikely to have any side effects, but still, I don't like Org making
these decisions for me and adding LaTeX code that I didn't ask for, in
form or quantity. Isn't it possible to be more selective, like Pandoc
does (I think), and add what needs to be added only when the problem is
present? I don't know if the Pandoc thing has already been mentioned in
past discussions, because these days I haven't been paying attention to
the list.

In any case, I would prefer: a) a selective solution; and if a) is not
possible, at least b) a defcustom.

This is an example I came up with of how it could be fixed selectively
in LaTeX (big, big caveat: it's just a proof of concept and likely to
produce errors in other contexts. I think if a LaTeX package to fix this
isn't already out, it is either because the problem is very rare and the
solution for particular cases is known, or because there are drawbacks
inherent to LaTeX that I can't figure out right now):

\makeatletter

\def\my@protectlbrack{
  \@ifnextchar{[}{\relax}{}
  \@ifnextchar{*}{\relax}{}
}

\let\old@break\\
\def\\{%
  \old@break\my@protectlbrack}

%% for tables

\let\old@tabularcr\@tabularcr
\def\@tabularcr{%
  \old@tabularcr\my@protectlbrack}

% for use the old commands

\newcommand\oldbreak{\old@break}
\newcommand\oldbreakt{\old@tabularcr}

\makeatother

\begin{document}

lorem\\
[ipsum]

lorem\\
*ipsum

\begin{tabular}{}
a & a & a & a \\
[a] & a & a & a \\
*a & a & a & a \\
\end{tabular}


\end{document}

Re: Org babel Python and R, table not transformed when :var is called ?

[Ihor Radchenko]

Sébastien Rey-Coyrehourcq 
writes:

> Perhaps it's a bug, or something i don't understand, i post on reddit 
> (https://www.reddit.com/r/emacs/comments/r5yt4a/r_talking_with_python_using_orgtable_not_work/)
>  
> to see if people on org community know the problem.
>
> I cross post here to see if it's a know bug or somethings ?
>
> There is something i don't understand,
> a difference between behavior of org-babel and org-mode when you use org 
> table to pass data using or not using :var.
>
> |#+NAME:mypythoncode #+begin_src python :results value raw :output 
> :return tabulate(df, headers=df.columns, tablefmt='orgtbl')

AFAIU, your tabulate call returns string, not a python table. So, :var
assignment indeed assigns a string. The returned string also happens to
use Org table format, which is why results block is an Org table.

By putting #+NAME to results block, you will be referring to its Org
syntax, which is then converted from Org table to R table, in contrast
to from Python result string to R string.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Best android app

[Juan Manuel Macías]

Ihor Radchenko writes:

> Clarification: I was actually referring to Jean's email. (I did not look
> at the sender and just now realized that you are not Jean)
>
> Having said that, my judgment may be still poor. I'd be happy to hear
> that I am wrong from Jean.

Apologies for the misunderstanding. But in any case, I agree with what
Jean says. A GNU list is not the place to discuss whether proprietary
software should be recommended here or anywhere else. And I don't think
that affirming this (which is obvious) means aborting any possible
discussion. It is simply a reminder that such discussions should not
take place here. I don't think this is documented anywhere, but I insist
that it seems like common sense to me.

Re: Markdown export is non-deterministic?

[Dominique Dumont]

On Saturday, 8 October 2022 00:31:00 CEST Matias Eyzaguirre wrote:
> I’m using org-mode to generate a markdown README for a project that is
> under version control. I’ve noticed that the anchor tags used for the
> table of contents seem to be annoyingly random and change from export
> to export. Is it possible to make the generated ids deterministic?

The function shown in this blog helps a lot:

https://amitp.blogspot.com/2021/04/automatically-generate-ids-for-emacs.html

This works quite well for my org files.

HTH

Dod

Re: [BUG] columnview cannot deal with more than 100 headings [N/A (N/A @ /home/oub/emacs/site-lisp/packages/org/)]

[Uwe Brauer]

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

> Uwe Brauer  writes:
>> I attach a file that hopefully explains the problem.
>> 
>> That file contains 109 heading, each heading has 17 different properties 
>> when all of them are included in the 
>> #+BEGIN: columnview
>> #+END:
>> 
>> Block then not all headings are included. It seems to work with 15 
>> properties but not for all 17.

> I tried your file on the latest main, but I do not see anything
> obviously wrong. Could you please clarify what you expect to see?

Ok then, I will pull and install the latest master/main.

BTW, you send me some time ago (the <2022-07-30>) a patch that allowed
edit-comment-blk: support COMMENT blocks

Is this now in master/main? It is very convenient for my workflow

For you convenience I attach the patch below

Regards



-- 
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. 
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 478fcf95c..0bc3fa638 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -141,6 +141,14 @@ discouraged when working with Org files.
 
 ** New features
 
+*** Interactive commands now support escaping text inside comment blocks
+
+~org-edit-special~ and ~org-insert-structure-template~ now handle
+comment blocks.
+
+See [[*New command ~org-edit-comment-block~ to edit comment block at
+point]].
+
 *** New customization option =org-property-separators=
 A new alist variable to control how properties are combined.
 
@@ -253,6 +261,16 @@ instance,
 includes all available items in the printed bibliography.
 ** New functions and changes in function arguments
 
+*** New command ~org-edit-comment-block~ to edit comment block at point
+
+As the contents of comments blocks is not parsed as Org markup, the
+headlines and keywords inside should be escaped, similar to src
+blocks, example blocks, and export blocks.  This in inconvenient to do
+manually and ~org-edit-special~ is usually advised to edit text in
+such kind of blocks.
+
+Now, comment block editing is also supported via this new function.
+
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
 
 When element cache is enabled, the new function provides the best
@@ -266,7 +284,6 @@ to ~org-element--cache-map-statistics~ and
 ~org-element--cache-map-statistics-threshold~.
 
 ~org-scan-tags~ and tag views in agenda utilise the new function.
-
 *** New function ~org-element-at-point-no-context~
 
 This function is like ~org-element-at-point~, but it does not try to
diff --git a/lisp/org-src.el b/lisp/org-src.el
index b7e0af50e..0249af60b 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -384,7 +384,7 @@ (defun org-src--contents-area (datum)
(let ((beg (org-element-property :contents-begin datum))
 	 (end (org-element-property :contents-end datum)))
 	 (list beg end (buffer-substring-no-properties beg end
-  ((memq type '(example-block export-block src-block))
+  ((memq type '(example-block export-block src-block comment-block))
(list (progn (goto-char (org-element-property :post-affiliated datum))
 		(line-beginning-position 2))
 	 (progn (goto-char (org-element-property :end datum))
@@ -1161,6 +1161,29 @@ (defun org-edit-export-block ()
(lambda () (org-escape-code-in-region (point-min) (point-max)
 t))
 
+(defun org-edit-comment-block ()
+  "Edit comment block at point.
+\\
+A new buffer is created and the block is copied into it, and the
+buffer is switched into Org mode.
+
+When done, exit with `\\[org-edit-src-exit]'.  The edited text \
+will then replace the area in the Org mode buffer.
+
+Throw an error when not at a comment block."
+  (interactive)
+  (let ((element (org-element-at-point)))
+(unless (and (eq (org-element-type element) 'comment-block)
+		 (org-src--on-datum-p element))
+  (user-error "Not in a comment block"))
+(org-src--edit-element
+ element
+ (org-src--construct-edit-buffer-name (buffer-name) "org")
+ 'org-mode
+ (lambda () (org-escape-code-in-region (point-min) (point-max)))
+ (org-unescape-code-in-string (org-element-property :value element)))
+t))
+
 (defun org-edit-src-code ( code edit-buffer-name)
   "Edit the source or example block at point.
 \\
diff --git a/lisp/org.el b/lisp/org.el
index 937892ef3..d75894590 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8869,7 +8869,8 @@ (defun org-insert-structure-template (type)
 	 (region-end (and region? (copy-marker (region-end
 	 (extended? (string-match-p "\\`\\(src\\|export\\)\\'" type))
 	 (verbatim? (string-match-p
-		 (concat "\\`" (regexp-opt '("example" "export" "src")))
+		 (concat "\\`" (regexp-opt '("example" "export"
+"src" "comment")))
 		 type))
  (upcase? (string= (car (split-string type))
(upcase (car (split-string 

Re: [O] Bug: Multiple bulk actions on the same task fails [9.0.5 (9.0.5-elpaplus @ /Users/links_world/.emacs.d/elpa/org-plus-contrib-20170210/)]

[Ihor Radchenko]

Adrian Bradd  writes:

> Using the following agenda file as an MWE:
>
> * Incoming
> ** TODO Testing1
> ** TODO Testing2
> ** TODO Testing3
>
> I ran org-agenda and pressed 't' to list all todo items. In the agenda
> buffer I marked the task 'Testing1' with 'm' and performed a bulk action with 
> 'B' and
> added a tag with '+'. This completed successfully. If I mark "Testing1'
> again with 'm' and use 'B' to perform a bulk action I receive an error:
>
> user-error: Marker # for bulk 
> command is invalid

For record, this is not reproducible on the latest main.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Best android app

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> Jean Louis  writes:
>>
>>> If I am not mistaken, you propose or initiate discussing how to list
>>> proprietary software on some websites.
>>>
>>> GNU mailing lists are not for such discussions. GNU is project is
>>> there to foster full free software. 
>>
>> Do you know where this rule is documented?
>
> Documented or undocumented, it's common sense. This is a mailing list of
> the GNU project, and it is hoped that this list will not recommend the
> use of unethical software that does not comply with the GNU philosophy.

Discussing and recommending are two different things.

Consider Windows. We do not recommend it. Yet, we do support it, and we
do discuss it.

WRT the Org apps, we are discussing things, and you are
trying to put stop on this discussion. I find it a bit too aggressive.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[bug] Macro in citation not expanded

[M . ‘quintus’ Gülker]

Dear list,

it turns out that macros in citation commands are not expanded. Minimal
working example:

/tmp/mwe.org:

#+TITLE: Test
#+LANGUAGE: de
#+bibliography: /tmp/mwe.bib
#+cite_export: csl /tmp/juristische-schulung.csl
#+MACRO: name @@latex:\textsc{$1}@@

Dies {{{name(Foo)}}}  ist ein Test. [cite:@doe2022nothing p. 55,, zum 
vorgenannten Argument {{{name(Doe)}}} aaO.]

/tmp/mwe.bib is:

@Book{doe2022nothing,
author   = {John Doe},
title= {Nothing Important},
year  = {2022},
edition   = {2},
publisher = {Some Publisher},
location  = {Nowhere},
langid= {english}}

/tmp/juristische-schulung.csl is 
.

Exporting this to LaTeX yields:

Dies \textsc{Foo}  ist ein Test.\footnote{\textit{Doe}, Nothing important, 
2. Aufl. (2022), 55, zum vorgenannten Argument \{\{\{name(Doe)\}\}\} aaO.}

This replaces the first call to the `name' macro properly, but it does
not replace the call to the `name' macro inside the `cite:' construct.
Instead, it copies the macro construct verbatim into the LaTeX footnote.
The correct output should have been:

Dies \textsc{Foo}  ist ein Test.\footnote{\textit{Doe}, Nothing important, 
2. Aufl. (2022), 55, zum vorgenannten Argument \textsc{Doe} aaO.}

Version information:

Org mode version 9.6-pre (release_9.5-1162-g15b3aa @ 
/home/quintus/.emacs.d/org-mode/lisp/)
citeproc.el @ ba49516265fa24b138346c4918d39d19b4de8a62
GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.31, cairo 
version 1.16.0)

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

[PATCH] Add light argument to org-babel-lob-get-info

[Ferdinand Pieper]

Similar to ~org-babel-get-src-block-info~ it is sometimes useful to disable 
evaluation of lisp parameters when getting the info of a lob call. This patch 
adds an argument for that.

Better name for the argument could be ~no-eval~, but I decided to stick with 
the naming in ~org-babel-get-src-block-info~. To be completely consistent with 
~org-babel-get-src-block-info~ the argument order could be swapped, but this 
would break existing function calls. 

What do you think?

Best,
Ferdinand

>From ba8069a3b83489ee1de8c4eeba059883809d0ea7 Mon Sep 17 00:00:00 2001
From: fpi 
Date: Sun, 16 Oct 2022 13:17:40 +0200
Subject: [PATCH] org-babel-lob-get-info: Add light argument

* lisp/ob-lob.el (org-babel-lob-get-info): Add light argument to
prevent recursive evaluation of lisp values in parameters.
---
 lisp/ob-exp.el |  2 +-
 lisp/ob-lob.el | 13 +
 lisp/ob-ref.el |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index e9b304b86..83dd5fc74 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -25,7 +25,7 @@
 ;;; Code:
 (require 'ob-core)
 
-(declare-function org-babel-lob-get-info "ob-lob" ( datum))
+(declare-function org-babel-lob-get-info "ob-lob" ( datum light))
 (declare-function org-element-at-point "org-element" ())
 (declare-function org-element-context "org-element" ( element))
 (declare-function org-element-property "org-element" (property element))
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index 903dabfbd..3043ff647 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -114,11 +114,16 @@ after REF in the Library of Babel."
 	(cdr (assoc-string ref org-babel-library-of-babel
 
 ;;;###autoload
-(defun org-babel-lob-get-info ( datum)
+(defun org-babel-lob-get-info ( datum light)
   "Return internal representation for Library of Babel function call.
 
 Consider DATUM, when provided, or element at point otherwise.
 
+When optional argument LIGHT is non-nil, Babel does not resolve
+remote variable references; a process which could likely result
+in the execution of other code blocks, and do not evaluate Lisp
+values in parameters.
+
 Return nil when not on an appropriate location.  Otherwise return
 a list compatible with `org-babel-get-src-block-info', which
 see."
@@ -139,16 +144,16 @@ see."
 			org-babel-default-lob-header-args
 			(append
 			 (org-with-point-at begin
-			   (org-babel-params-from-properties language))
+			   (org-babel-params-from-properties language light))
 			 (list
 			  (org-babel-parse-header-arguments
-			   (org-element-property :inside-header context))
+			   (org-element-property :inside-header context) light)
 			  (let ((args (org-element-property :arguments context)))
 			(and args
  (mapcar (lambda (ref) (cons :var ref))
 	 (org-babel-ref-split-args args
 			  (org-babel-parse-header-arguments
-			   (org-element-property :end-header context)
+			   (org-element-property :end-header context) light
 		 nil
 		 (org-element-property :name context)
 		 begin
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index a7ab299b2..a7cdb22e1 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -53,7 +53,7 @@
 (require 'org-macs)
 (require 'cl-lib)
 
-(declare-function org-babel-lob-get-info "ob-lob" ( datum))
+(declare-function org-babel-lob-get-info "ob-lob" ( datum light))
 (declare-function org-element-at-point "org-element" ())
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-type "org-element" (element))
-- 
2.20.1

Re: Bug: DPI error when HTML publish latex block images [9.4.4 (release_9.4.4 @ /Applications/emacs/lisp/org/)]

[Ihor Radchenko]

Daniel Guimaraes  writes:

>   I am trying to export a latex tikzpicture, like the following to html:
> ```
> #+begin_src latex :exports results :results raw file :file ex.png 
> :output-dir ../img/
> \begin{tikzpicture}
> \draw node[circle, draw] (a) {$a$}
> node[circle, draw, right of = a] (b) {$b$}
> node[circle, draw, below of = a] (c) {$c$}
> node[circle, draw, below of = b] (d) {$d$};
> \end{tikzpicture}
> #+end_src
> ```
> If I export with `org-export-dispatch` to HTML file, I flawlessly obtain 
> the desired html. If I however, `org-html-publish-to-html` with:
>
> ```
> emacs -Q --script build-site.el
> ```
> Then I obtain the following error:
> ```
> Debugger entered--Lisp error: (error "Attempt to calculate the dpi of a 
> non-graphic disp...")

Thanks for reporting!
Fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d972cfac89ccb9003a91636701625bb142f1b6cf

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Best android app

[Juan Manuel Macías]

Ihor Radchenko writes:

> WRT the Org apps, we are discussing things, and you are
> trying to put stop on this discussion. I find it a bit too aggressive.

What I have done is simply to remind that a specific application is not
free and should not be recommended here (the user who has cited that
application in good faith does not have to know it). That's exactly
discussing things.

Of course, I know the difference between discussing something and
recommending it.

And no, I do not intend what I have said to put stop a discussion. You
have added that by making a rather poor and out of place judgment of
intentions.

Re: Best android app

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Ihor Radchenko writes:
>
>> WRT the Org apps, we are discussing things, and you are
>> trying to put stop on this discussion. I find it a bit too aggressive.
>
> What I have done is simply to remind that a specific application is not
> free and should not be recommended here (the user who has cited that
> application in good faith does not have to know it). That's exactly
> discussing things.
>
> Of course, I know the difference between discussing something and
> recommending it.

> And no, I do not intend what I have said to put stop a discussion. You
> have added that by making a rather poor and out of place judgment of
> intentions.

Clarification: I was actually referring to Jean's email. (I did not look
at the sender and just now realized that you are not Jean)

Having said that, my judgment may be still poor. I'd be happy to hear
that I am wrong from Jean.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org-mode: how to change field

[Ihor Radchenko]

Renato Pontefice  writes:

> I’m trying to change the field value, but I cannot edit this file. If I try 
> to erase some character (with backspace), it’s not possible:or it does not 
> start to erase or (if I press for log time) it erase all the field.
>
> How can I edit it?

Could you please elaborate about what "field" you are talking about? And
which file?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [bug] Macro in citation not expanded

[Ihor Radchenko]

M. ‘quintus’ Gülker  writes:

> it turns out that macros in citation commands are not expanded.

Confirmed.

They are not.
Only bold, code, entity, italic, latex-fragment, strike-through,
subscript, superscript, underline, and verbatim objects are allowed
inside citations.
This is hard-coded inside `org-element-object-restrictions'.

It sounds reasonable to allow macros inside citation references.
Maybe we also want to allow other things. Maybe simply allow all objects
but other citations, line-breaks, and table-cells?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] fix `org-agenda-new-marker`

[Ihor Radchenko]

Hu Lucius  writes:

> In some cases, `org-agenda-buffer` is killed while the symbol itself
> is still non-nil. `org-agena-new-marker` and anything calls it would
> ends in a message of "Selecting deleted buffer".
>
> This commit simply added an additional test that
>
> (buffer-live-p org-agenda-buffer)
>
> should also be true.

Thanks and sorry for the late reply!
I applied equivalent patch with the syntactically correct condition onto
main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=87c294c7b6419e4b262fbcd6ecd1d535a8496af5

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-latex preview on Windows

[Ihor Radchenko]

Jeremie Juste  writes:

> Hello everyone,
>
> I have had difficulties using  org-latex-preview to run properly on Windows.
> The main issue seems to be that the user name on windows gets abbreviated
> with ~. As far as I understand this generate problems as the temporary
> folder cannot be found.
>
> see for instance these posts
> https://emacs.stackexchange.com/a/70119
>
> and an old post from Vincente Vera
> https://list.orgmode.org/CAMfbzvDPLS1eqXJ=7tzh1035z3vq4q4-yjmqsvbcgxzp8kd...@mail.gmail.com/

Isn't it Emacs upstream bug? temporary-file-directory is supposed to
return a reachable path.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX

[Juan Manuel Macías]

Ihor Radchenko writes:

>> And finally, I think that applying a general solution to this problem is
>> something that should be done(IMHO) in LaTeX and not in Org, for
>> example, with some new package that would protect certain signs or
>> through ad hoc LaTeX/Lua code.
>
> Either way, we will need to use the new package in ox-latex.el. And our
> current approach is somewhat better because users can still use direct
> LaTeX @@latex:\\@@ if they want to get "\\" exactly.

I'm afraid we differ completely on what Org's priorities are at this
point. The way I see it, Org shouldn't try to solve LaTeX problems,
because Org isn't proficient in LaTeX. This is a known issue in LaTeX,
where a leading bracket can be confused with the optional argument of a
preceding macro (such as \\ or \linebreak). And it doesn't just happen
in this context. It can also happen with environments that have optional
arguments, although the case of \\ is the most common and the case of
environments depends on how the environment is defined. For this
problem, LaTeX has been recommending various *specific* solutions
(because the probability of it appearing is very low, luckily), such as
enclosing the brackets in two {} or putting a \relax before .

In this case Org intends to solve the LaTeX problem, and it does it, in
my opinion, poorly, by generalizing a particular solution for what is
even an extremely rare problem. This is the typical case that can be
easily solved by the user with a macro or an export filter, as I have
been doing for a long time, and at no time have I needed anything else.

Org must worry about exporting well and offering the necessary tools for
that to happen, as it has been doing until now. And the duty of the
users is to know reasonably the language to which they export, to the
extent of what they want to obtain when they export. Org should not be a
substitute for LaTeX: whoever wants to get special things in LaTeX, must
know LaTeX. It's that easy. If Org is going to start trying to solve at
its own risk all the *specific* problems that can appear in the typical
compilation of a LaTeX document, then I prefer to stop using Org and use
pure LaTeX from the beginning.

And as for the ox-latex.el file, in its current state it is completely
unusable for me. At least the user could be offered the possibility of
choosing.

Re: Best android app

[Ihor Radchenko]

Jean Louis  writes:

> If I am not mistaken, you propose or initiate discussing how to list
> proprietary software on some websites.
>
> GNU mailing lists are not for such discussions. GNU is project is
> there to foster full free software. 

Do you know where this rule is documented?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Markdown export is non-deterministic?

[Ihor Radchenko]

Dominique Dumont  writes:

> The function shown in this blog helps a lot:
>
> https://amitp.blogspot.com/2021/04/automatically-generate-ids-for-emacs.html
>
> This works quite well for my org files.

Feel free to help with https://orgmode.org/list/87fsfutwin.fsf@localhost

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org-mode: how to change field

[Ihor Radchenko]

[I am adding Org mailing list back to CC. Please use Reply All when
participating in public lists]

Renato Pontefice  writes:

> * TODO things to do today <2022-10-16 Sun 11:48>
>
> On this statement if I press the back space  (having the cursor at right of 
> the > symbol) I cannot go with cursor over the 11:48 or date text to change 
> it. It is like if it is blocked. I cannot edit like normal text.

I can certainly delete freely doing what you describe.
What happens if you open the file starting from emacs -Q?

>> Il giorno 16 ott 2022, alle ore 11:46, Ihor Radchenko  
>> ha scritto:
>> 
>> Renato Pontefice  writes:
>> 
>>> Ok, I call “field” the text formed by date + time ( <2022-10-23 Sun 11:08>) 
>>> that I obtain pushing C-u .
>>> When inserted, I cannot edit it
>> 
>> I can certainly edit it on my side.
>> Can you please provide more details (like example file and what exactly
>> you did)? See https://orgmode.org/manual/Feedback.html#Feedback
>> 
>> -- 
>> Ihor Radchenko // yantar92,
>> Org mode contributor,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
>

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Error during PDF export but the PDF file is exported

[Ihor Radchenko]

Pascal Quesseveur  writes:

> From time to time I work on files mounted from a remote host which is
> late compared to my pc.  Then I encounter errors when producing files
> from Org:
>
> File xxx wasn't produced
>
> But the file is produced and is up-to-date. The error message comes
> from org-compile-file. In that function the test is to compare the
> date at the start of function with the date of the produced file. I
> don't know if it's still the case in recent versions, but I think it
> could be changed. For example, instead of using the date at the start
> of the function, we could use the date of the file if it already
> exists
>
> (time (if (file-exists-p output)
> (file-attribute-modification-time (file-attributes output))
>   '(0 0 0 0)))

Confirmed.

Sorry for the late reply.
This kind of use-case is indeed not considered by our code.
However, your suggestion will only provide a partial fix - when an older
file already exists in the remote folder.

May be there a way to get time on remote server?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: reference cards missing

[Ihor Radchenko]

Cédric Martínez Campos  writes:

> There is explicit reference at https://orgmode.org/worg/#learn to reference
> cards in PDF and ASCII format. The links are broken and the linked files do
> not exist in the git repo. This seems to be a new TODO.

Thanks for reporting, and sorry for the late reply.
This has been fixed recently. See 
https://orgmode.org/list/87v8olbkq0@gnu.org

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Bug: clocktable :inherit-props does not respect global property setting [9.4.6 (9.4.6-12-gdcc3a8-elpa @ /home/jet/.config/emacs/elpa/org-20210823/)]

[Ihor Radchenko]

Jeff Trull  writes:

> :inherit-props seems to not consider global properties.
>
> Testcase:

I am unable to reproduce on the latest main.
The inherited properties are displayed as expected on my side.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Some links in online manual do not work

[Tim Landscheidt]

Bastien Guerry  wrote:

>> More:

> Fixed, thanks!

> https://git.sr.ht/~bzg/worg/commit/408f05a0

Thanks to everyone involved, works for me now!

Tim

[ANN] We are now regularily testing Org main branch against Emacs 26, 27, 28

[Bastien]

Hi all,

thanks to joint efforts by Christian Köstlin and Ihor, we are running
the Org test suite from the Org main branch against Emacs 26, 27, 28.

Every three hours, a script from the orgmode.org server checks if the
Org main branch changed.

If yes, we run the Org test suite against Emacs 26, 27 and 28.

If a test fails, a failure report is sent to a new mailing list:
https://lists.sr.ht/~bzg/org-build-failures and we can inspect what
did go wrong.

If a test fails again (i.e. there was a failure, then the repo was
updated, then there is a failure again for the same test), reports are
sent to Ihor, Christian and me, not to the dedicated list.

Tests are performed by running builds on sr.ht.  You can read the
builds in this new repository: https://git.sr.ht/~bzg/org-mode-tests

We are now testing this setup: if it useful enough, we will redirect
failure reports to the Org mailing list, while using the new one for
repeated failures, so as to not spam the list.

In the future, resources at https://git.sr.ht/~bzg/org-mode-tests
will also perhaps help contributors defining new ways on how to run
tests, beyond the current way ("make test").

Patch submitters are required to run the tests themselves before
submitting a patch: we don't rely on this new setup to test patches,
only to catch errors that may inadvertently slip through the cracks.

Thanks again to Christian and Ihor for setting this up!

-- 
 Bastien

Re: Best android app

[Jean Louis]

* Max Nikulin  [2022-10-16 08:28]:
> On 16/10/2022 01:31, ypuntot wrote:
> > Could these be added there?
> > 
> > https://github.com/DanielDe/org-web
> > https://easyorgmode.com/
> > https://github.com/amake/orgro
> > https://logseq.com/
> 
> At least some brief description of real advantages from actual users is
> necessary. Copy-paste from the project site sometimes is not the best
> option.
> 
> Awesome lists is an interesting initiative trying to emphasize strong sides
> of various projects, but particular lists varies in quality. Example:
> https://github.com/emacs-tw/awesome-emacs#readme
> 
> I do not have strong opinion concerning proprietary application.
> Requirements for worg section as driven by user content are not so strict as
> for the main part of the Org site that must adhere to FSF rules. Perhaps it
> is possible to separate non-free software by some discouraging
> disclaimer.

If I am not mistaken, you propose or initiate discussing how to list
proprietary software on some websites.

GNU mailing lists are not for such discussions. GNU is project is
there to foster full free software. 

Free software is not an ethical issue, its a user right issue:
https://neritam.wordpress.com/2019/10/12/free-software-is-not-an-ethical-issue-its-a-user-right-issue/

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: [BUG] Test failure: testing/lisp/test-ob-octave.el is missing a `provide'

[Ihor Radchenko]

Nick Dokos  writes:

> That stopped the `make test' cold with a backtrace. Bug fix attached.

For record, a patch from different email has been applied.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: yanking into body text ends up after the entry

[Ihor Radchenko]

Samuel Wales  writes:

> imagine this
>
> * to yank
> a
> b
> c
> * x
> ^sadfsadf
> ^^*** y
>
> if i kill the to yank entry, then paste at ^,it ends up at ^^ instead.
> this is logical in that to yank would swallow the body text, but i am
> wondering when this behavior started.

I am unable to reproduce.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] columnview cannot deal with more than 100 headings [N/A (N/A @ /home/oub/emacs/site-lisp/packages/org/)]

[Ihor Radchenko]

Uwe Brauer  writes:

> I attach a file that hopefully explains the problem.
>
> That file contains 109 heading, each heading has 17 different properties when 
> all of them are included in the 
> #+BEGIN: columnview
> #+END:
>
> Block then not all headings are included. It seems to work with 15 properties 
> but not for all 17.

I tried your file on the latest main, but I do not see anything
obviously wrong. Could you please clarify what you expect to see?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Doubts about a function for my org-capture template

[Ihor Radchenko]

Juan Manuel Macías  writes:

> The function works fine from eww, but it doesn't work with org-protocol
> + qutebrowser, as the value of :initial in org-capture-plist seems to be
> nil.

Would you mind providing exact steps needed to reproduce the problem?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at