[BUG] C-u C-u C-u TAB regression on master

[Allen Li]

There appears to be a regression in the behavior of C-u C-u C-u TAB on
master (at aea24b3feafb9c389dc5933005928462bb20c4f8).

C-u C-u C-u TAB is supposed to show everything including drawers, but on
this test file it does not show property drawers:

Make a file containing 2000 copies of the following:

* blah
:PROPERTIES:
:ID: blah
:END:
blah

This bug does not manifest on small files, e.g. containing one copy of
the above.

This is using (setq org-fold-core-style 'text-properties), the default.
The behavior does not happen with 'overlays.

Can anyone else reproduce?

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.17.6)
 of 2022-04-27
Package: Org mode version 9.5.3 (9.5.3-gca5c9f @ 
/home/ionasal/.emacs.d/straight/build/org/)

Re: Regarding arbitrary Org blocks

[Russell Adams]

On Wed, May 11, 2022 at 02:39:28PM -0700, Greg Minshall wrote:
> Russell, the behavior you describe, that used to work, sounds reasonable
> to me.  otoh, in case you haven't discovered =narrow-to-region= and
> friends, (which i only recently did), that might also give you some of
> what you want.  cheers, Greg


Check out org-tree-to-indirect-buffer ;]


--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: Regarding arbitrary Org blocks

[Greg Minshall]

Russell, the behavior you describe, that used to work, sounds reasonable
to me.  otoh, in case you haven't discovered =narrow-to-region= and
friends, (which i only recently did), that might also give you some of
what you want.  cheers, Greg

Re: How to stop results being hidden when using ":results drawer"?

[John Kitchin]

hm. what is xenops doing? That isn't a package I use, but my results
drawers are also closed when opening a file.

John

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



On Wed, May 11, 2022 at 4:16 PM Richard Stanton 
wrote:

> It works fine when I use emacs -Q, so I did some hunting around and
> discovered that it’s a bad interaction with the xenops package. A shame, as
> this package does a great job of almost-real-time previewing of LaTeX
> equations, figure and tables.
>
>
> > On May 11, 2022, at 10:51 AM, Richard Stanton 
> wrote:
> >
> > I see that the same question was asked by John Kitchin in 2016. The
> accepted answer back then was either to put
> >
> > #+STARTUP: showeverything
> >
> > at the top of the org file or to use (setq org-startup-folded
> "showeverything”).
> >
> > I don’t know if something has changed in org since then, but neither of
> these seems to work for me at the moment. All of my :results: drawers start
> out and remain hidden until I click on them and press TAB.
> >
> >
> >> On May 11, 2022, at 9:52 AM, Richard Stanton 
> wrote:
> >>
> >> I’m creating documents where I run Python code blocks that create LaTeX
> mathematical output that I want to be able to export to either LaTeX/PDF or
> HTML.
> >>
> >> Using :wrap in the header works fine, except that LaTeX complains about
> the unknown environment “results” (it still compiles the file to PDF fine).
> >>
> >> Using :wrap export latex works fine for LaTeX export, but I can’t get
> HTML that way.
> >>
> >> The recommended method seems to be to use :results drawer. This works
> fine from an export perspective to both LaTeX/PDF and to HTML. However, it
> has one significant drawback when I’m actually creating the document: the
> results drawer starts out hidden and to see what’s there I have to click on
> it. This makes debugging the code in the first place a lot less convenient.
> >>
> >> Is there a way to use :results drawer and have the results NOT hidden
> by default?
> >>
> >> Thanks for any suggestions!
> >>
> >> Richard Stanton
> >>
> >>
> >
>
>
>

Re: How to stop results being hidden when using ":results drawer"?

[Richard Stanton]

It works fine when I use emacs -Q, so I did some hunting around and discovered 
that it’s a bad interaction with the xenops package. A shame, as this package 
does a great job of almost-real-time previewing of LaTeX equations, figure and 
tables.


> On May 11, 2022, at 10:51 AM, Richard Stanton  wrote:
> 
> I see that the same question was asked by John Kitchin in 2016. The accepted 
> answer back then was either to put
> 
> #+STARTUP: showeverything
> 
> at the top of the org file or to use (setq org-startup-folded 
> "showeverything”).
> 
> I don’t know if something has changed in org since then, but neither of these 
> seems to work for me at the moment. All of my :results: drawers start out and 
> remain hidden until I click on them and press TAB.
> 
> 
>> On May 11, 2022, at 9:52 AM, Richard Stanton  wrote:
>> 
>> I’m creating documents where I run Python code blocks that create LaTeX 
>> mathematical output that I want to be able to export to either LaTeX/PDF or 
>> HTML. 
>> 
>> Using :wrap in the header works fine, except that LaTeX complains about the 
>> unknown environment “results” (it still compiles the file to PDF fine).
>> 
>> Using :wrap export latex works fine for LaTeX export, but I can’t get HTML 
>> that way.
>> 
>> The recommended method seems to be to use :results drawer. This works fine 
>> from an export perspective to both LaTeX/PDF and to HTML. However, it has 
>> one significant drawback when I’m actually creating the document: the 
>> results drawer starts out hidden and to see what’s there I have to click on 
>> it. This makes debugging the code in the first place a lot less convenient.
>> 
>> Is there a way to use :results drawer and have the results NOT hidden by 
>> default?
>> 
>> Thanks for any suggestions!
>> 
>> Richard Stanton
>> 
>> 
> 

Re: Regarding arbitrary Org blocks

[Colin Baxter]

> Russell Adams  writes:

> On Wed, May 11, 2022 at 09:23:27PM +0300, Daniel Fleischer wrote:
>> Russell Adams [2022-05-11 Wed 18:14] wrote:
>> 
>> > Could I add some minor mode to say text-mode with
>> auto-fill-mode and > aspell somewhere when opening those blocks?
>> 
>> Hi! If you're editing text why do you need a special buffer? You
>> can edit them in the orgmode buffer and enjoy all its textual
>> features.

> First up, it's because it used to work and now it doesn't. ;]

> Second it can be very useful to work on a sub-buffer, or indirect
> buffer for some content. Why shouldn't I be able to edit the
> contents of that block inside an indirect buffer where my
> beginning-of-buffer, end-of-buffer, word wrap, or global find and
> replace are constrained to that block of text?

> This works for example blocks, but no longer for verse and quote
> blocks. These are native Org block types and not my fanciful made
> up ones. Why should the popup work for example blocks, but not the
> others? That borders on a bug, where my question was considered as
> a configuration question.

I very much support the idea that special and source blocks should be
treatable in the same way. I'd like to be able to edit example and quote
using C-c '.

Best wishes,

Colin Baxter.

Re: Org-ref not working when exporting to LaTeX

[Bruce D'Arcus]

This is an aside, but I recently learned about citeproc-lua, which adds CSL
processing directly to tex and latex.

https://github.com/zepinglee/citeproc-lua

Now included in texlive 2022.

As that evolves more (there are still missing features), it could be
another viable alternative.

On Wed, May 11, 2022 at 2:19 PM John Kitchin 
wrote:
>
> The regular export is preferred for LaTeX (C-c C-e l o) is preferred for
LaTeX export as it generates the LaTeX cite commands. The version in C-c
C-e r p uses CSL for the formatting, not LaTeX, and it allows you to get
nicely formatted results without using bibtex/biblatex as the citation
processor.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Wed, May 11, 2022 at 2:15 PM Daniel Fleischer 
wrote:
>>
>> Alessandro Bertulli [2022-05-11 Wed 19:41] wrote:
>>
>> > I'm going to post my setup in a minute. The
>> > point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF
file
>> > gets produced, but it doesn't process the citation keys. For example,
in
>> > my file (see below), I got the key "acm:code" literally printed on the
>> > PDF file, in a bold font.
>>
>> Hi, org-ref uses its own export engine which you call via (C-c C-e r p).
>> Please try that and report back if there are still issues.
>>
>> --
>>
>> Daniel Fleischer
>>

Re: Org-ref not working when exporting to LaTeX

[Daniel Fleischer]

John Kitchin [2022-05-11 Wed 14:17] wrote:

> The regular export is preferred for LaTeX (C-c C-e l o) is preferred for 
> LaTeX export as it generates the LaTeX cite
> commands. The version in C-c C-e r p uses CSL for the formatting, not LaTeX, 
> and it allows you to get nicely formatted
> results without using bibtex/biblatex as the citation processor.

Oops! Thanks for correcting my answer and mentioning the difference
between the CSL and bibtex engines. 

-- 

Daniel Fleischer

Re: [oc] multiple cite_export keywords for multiple export processors?

[Bruce D'Arcus]

On Wed, May 11, 2022 at 9:55 AM Ihor Radchenko  wrote:
>
> "Bruce D'Arcus"  writes:
>
> >> Emm. org-cite-export-processors?
> >
> > So I recognize I don't fully understand the org export system, but
> > that sets global defaults.
> >
> > What if I want to set a different style on a specific document?
>
> There is also #+cite_export: keyword, but it only sets global processor.
> You cannot choose per-export backend options. So, you can use #+bind to
> set org-exportprocessors explicitly in buffer.

OIC; that's the part I was missing.

So something like this?

#+bind: org-cite-export-processors ((latex biblatex "verbose"))

It doesn't seem to work though. Is there something wrong with my syntax?

Bruce

Re: Regarding arbitrary Org blocks

[Russell Adams]

On Wed, May 11, 2022 at 09:23:27PM +0300, Daniel Fleischer wrote:
> Russell Adams [2022-05-11 Wed 18:14] wrote:
>
> > Could I add some minor mode to say text-mode with auto-fill-mode and
> > aspell somewhere when opening those blocks?
>
> Hi! If you're editing text why do you need a special buffer? You can
> edit them in the orgmode buffer and enjoy all its textual features.

First up, it's because it used to work and now it doesn't. ;]

Second it can be very useful to work on a sub-buffer, or indirect
buffer for some content. Why shouldn't I be able to edit the contents
of that block inside an indirect buffer where my beginning-of-buffer,
end-of-buffer, word wrap, or global find and replace are constrained
to that block of text?

This works for example blocks, but no longer for verse and quote
blocks. These are native Org block types and not my fanciful made up
ones. Why should the popup work for example blocks, but not the
others? That borders on a bug, where my question was considered as a
configuration question.

Finally when you edit in the popup buffer, the results are indented
which makes the document more legible. Regular text tools do that
inconsistently.

> The special buffer is for major modes which are not orgmode such as
> programming languages or latex which use different
> completions/highlighting/minor-modes and editing them in orgmode is
> a hassle.

I think what I am using were once called "special blocks". You're
referring to source blocks. They have many more features but are
outside the question.

https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: Regarding arbitrary Org blocks

[Daniel Fleischer]

Russell Adams [2022-05-11 Wed 18:14] wrote:

> Could I add some minor mode to say text-mode with auto-fill-mode and
> aspell somewhere when opening those blocks?

Hi! If you're editing text why do you need a special buffer? You can
edit them in the orgmode buffer and enjoy all its textual features. The
special buffer is for major modes which are not orgmode such as
programming languages or latex which use different
completions/highlighting/minor-modes and editing them in orgmode is a
hassle. 

-- 

Daniel Fleischer

Re: Org-ref not working when exporting to LaTeX

[John Kitchin]

The regular export is preferred for LaTeX (C-c C-e l o) is preferred for
LaTeX export as it generates the LaTeX cite commands. The version in C-c
C-e r p uses CSL for the formatting, not LaTeX, and it allows you to get
nicely formatted results without using bibtex/biblatex as the citation
processor.

John

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



On Wed, May 11, 2022 at 2:15 PM Daniel Fleischer  wrote:

> Alessandro Bertulli [2022-05-11 Wed 19:41] wrote:
>
> > I'm going to post my setup in a minute. The
> > point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF file
> > gets produced, but it doesn't process the citation keys. For example, in
> > my file (see below), I got the key "acm:code" literally printed on the
> > PDF file, in a bold font.
>
> Hi, org-ref uses its own export engine which you call via (C-c C-e r p).
> Please try that and report back if there are still issues.
>
> --
>
> Daniel Fleischer
>
>

Re: Org-ref not working when exporting to LaTeX

[Daniel Fleischer]

Alessandro Bertulli [2022-05-11 Wed 19:41] wrote:

> I'm going to post my setup in a minute. The
> point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF file
> gets produced, but it doesn't process the citation keys. For example, in
> my file (see below), I got the key "acm:code" literally printed on the
> PDF file, in a bold font.

Hi, org-ref uses its own export engine which you call via (C-c C-e r p).
Please try that and report back if there are still issues. 

-- 

Daniel Fleischer

Re: How to stop results being hidden when using ":results drawer"?

[Richard Stanton]

I see that the same question was asked by John Kitchin in 2016. The accepted 
answer back then was either to put

#+STARTUP: showeverything

at the top of the org file or to use (setq org-startup-folded "showeverything”).

I don’t know if something has changed in org since then, but neither of these 
seems to work for me at the moment. All of my :results: drawers start out and 
remain hidden until I click on them and press TAB.


> On May 11, 2022, at 9:52 AM, Richard Stanton  wrote:
> 
> I’m creating documents where I run Python code blocks that create LaTeX 
> mathematical output that I want to be able to export to either LaTeX/PDF or 
> HTML. 
> 
> Using :wrap in the header works fine, except that LaTeX complains about the 
> unknown environment “results” (it still compiles the file to PDF fine).
> 
> Using :wrap export latex works fine for LaTeX export, but I can’t get HTML 
> that way.
> 
> The recommended method seems to be to use :results drawer. This works fine 
> from an export perspective to both LaTeX/PDF and to HTML. However, it has one 
> significant drawback when I’m actually creating the document: the results 
> drawer starts out hidden and to see what’s there I have to click on it. This 
> makes debugging the code in the first place a lot less convenient.
> 
> Is there a way to use :results drawer and have the results NOT hidden by 
> default?
> 
> Thanks for any suggestions!
> 
> Richard Stanton
> 
> 

[PATCH] Re: Concatenate properties

[Tyler Grinn]

Ihor Radchenko  writes:

> Tyler Grinn  writes:
>
>> Ihor Radchenko  writes:
>>
>>> Tyler Grinn  writes:
>>>

 Could you provide an example of what the value of that variable would be
 if, for instance, I wanted PROP_A and PROP_B to be joined with a single
 space and PROP_C and PROP_D to be concatenated? Or better yet, have the
 default be to join with a single space for any property and have only
 PROP_C and PROP_D concatenated?
>>>
>>> Say,
>>>
>>> '(("PROP_[CD]" . ""))
>>>
>>> or
>>>
>>> '(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))
>>>
>>> Best,
>>> Ihor
>>
>> I'm not sure forcing regular expressions for all use cases is ideal. Is
>> there a way to allow the option (I'm calling it org-property-separators)
>> to allow either regular expressions or exact matches, like
>> org-use-property-inheritance does?
>
> It's up to you. I merely suggested that the new option should work
> similarly to org-use-property-inheritance. It will not be the exact
> match since we also need to provide the separator string.
>
>> Other than that I'm mostly ready to send in my first patch. Should I
>> attach it in this thread or start a new one?
>
> Keeping the patch within this thread will be more reasonable for future
> readers. Just remember to prefix the subject line with [PATCH].
>
> Best,
> Ihor

OK, what I have now is that if the car of an alist item is a list, exact
matching will be done for each list item, but if it is a string, it will
be matched as a regular expression.

Best,

Tyler

>From c23b45dd5d0bc5a049b916a4b4003c6f55ce4b51 Mon Sep 17 00:00:00 2001
From: Tyler Grinn 
Date: Mon, 9 May 2022 15:52:58 -0400
Subject: [PATCH] lisp/org.el: Add org-property-separators option

* lisp/org.el (org-property-separators, org-property-get-separator):
Created.
(org-entry-get, org-entry-get-with-inheritance): Use new
org-property-get-separator function.

* testing/lisp/test-org.el (test-org/entry-get): Added tests for
combining properties with custom separators

org-property-separators is a customization option that allows for
properties to be combined using a separator other than the default (a
single space).  It is an alist with the car of each element being a
list of property names or regular expression and the cdr being the
separator string, like '((("EXPORT_FILE_NAME") . "/")).
---
 etc/ORG-NEWS | 21 
 lisp/org.el  | 43 
 testing/lisp/test-org.el | 30 +++-
 3 files changed, 85 insertions(+), 9 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 27de6da62..0297a9d49 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -141,6 +141,27 @@ discouraged when working with Org files.
 
 ** New features
 
+*** New customization option =org-property-separators=
+A new alist variable to control how properties are combined.
+
+If a property is specified multiple times with a =+=, like
+=:EXPORT_FILE_NAME+:=, the old behavior was to always combine them
+with a single space. For the new variable, the car of each item in the
+alist should be either a list of property names or a regular
+expression, while the cdr should be the separator to use when
+combining that property.
+
+The default value for the separator is a single space, if none of the
+provided items in the alist match a given property.
+
+For example, in order to combine =EXPORT_FILE_NAME= properties with a
+forward slash =/=, one can use
+
+#+begin_src emacs-lisp
+(setq org-use-property-inheritance '("EXPORT_FILE_NAME")
+  org-property-separators '((("EXPORT_FILE_NAME") . "/")))
+#+end_src
+
 *** New library =org-persist.el= implements variable persistence across Emacs sessions
 
 The library stores variable data in ~org-persist-directory~ (set to XDG
diff --git a/lisp/org.el b/lisp/org.el
index cab59b87c..a53505752 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2850,6 +2850,30 @@ in this variable)."
 (member-ignore-case property org-use-property-inheritance))
(t (error "Invalid setting of `org-use-property-inheritance'"
 
+(defcustom org-property-separators nil
+  "An alist to control how properties are combined.
+
+The car of each item should be either a list of property names or
+a regular expression, while the cdr should be the separator to
+use when combining that property.
+
+If an alist item cannot be found that matches a given property, a
+single space will be used as the separator."
+  :group 'org-properties
+  :type '(alist :key-type string :value-type sexp))
+
+(defun org-property-get-separator (property)
+  "Get the separator to use for combining PROPERTY."
+  (or
+   (catch 'separator
+ (dolist (spec org-property-separators)
+   (if (listp (car spec))
+   (if (member property (car spec))
+   (throw 'separator (cdr spec)))
+ (if (string-match-p (car spec) property)
+ (throw 'separator (cdr spec))
+   " "))
+
 (defcustom org-columns-default-format 

Org-ref not working when exporting to LaTeX

[Alessandro Bertulli]

Hi all!

I'm trying to set up an academic workflow, and being unsure about which
framework to use, I gave org-ref a try. However, I can't make it produce
a correct LaTeX PDF file.

I'm going to post my setup in a minute. The
point is: when exporting the org file to LaTeX (C-c C-e l o), a PDF file
gets produced, but it doesn't process the citation keys. For example, in
my file (see below), I got the key "acm:code" literally printed on the
PDF file, in a bold font.

What am I doing wrong?

This is my setup:

init.el 
(require 'org-ref)
(setq bibtex-completion-bibliography '("~/Library/debug.bib"))
(require 'org-ref-ivy)

(define-key org-mode-map (kbd "C-c ]") 'org-ref-insert-link-hydra/body)

(setq org-latex-pdf-process (list "latexmk -shell-escape -bibtex -f -pdf %f"))

(setq org-ref-insert-link-function 'org-ref-insert-link-hydra/body
  org-ref-insert-cite-function 'org-ref-cite-insert-ivy
  org-ref-insert-label-function 'org-ref-insert-label-link
  org-ref-insert-ref-function 'org-ref-insert-ref-link
  org-ref-cite-onclick-function (lambda (_) (org-ref-citation-hydra/body)))

org-ref-test-file.org 

#+title: Org-ref test file
#+bibliography:~/Library/debug.bib
#+latex_header: \usepackage[citestyle=authoryear-icomp,bibstyle=authoryear, 
hyperref=true,backref=true,maxcitenames=3,url=true,backend=biber,natbib=true] 
{biblatex}
#+latex_header: \addbibresource{~/Library/debug.bib}

* Introduction
Lorem ipsum dolor sit amet [[cite::code]], consectetur adipisci elit, sed 
do eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim 
veniam, quis nostrum exercitationem ullamco laboriosam, nisi ut aliquid ex ea 
commodi consequatur. Duis aute irure reprehenderit in voluptate velit esse 
cillum dolore eu fugiat nulla pariatur. Excepteur sint obcaecat cupiditat non 
proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

~/Library/debug.bib 

@book{acm:code,
  title = {{{ACM}} Code of Ethics and Professional Conduct. {{Affirming}} Our 
Obbligation to Use Our Skills to Benefit Society},
  editor = {{Association for Computing Machinery}},
  date = {2018},
  doi = {10.1145/3274591},
  url = 
{https://www.acm.org/binaries/content/assets/about/acm-code-of-ethics-booklet.pdf},
  shorteditor = {ACM}
}

@article{acm:teachingethics,
  title = {How to Teach Computer Ethics through Science Fiction},
  author = {Burton, Emanuelle and Goldsmith, Judy and Mattei, Nicholas},
  date = {2018-07},
  journaltitle = {Communications of The Acm},
  shortjournal = {Commun. ACM},
  volume = {61},
  number = {8},
  pages = {54--64},
  publisher = {{Association for Computing Machinery}},
  location = {{New York, NY, USA}},
  issn = {0001-0782},
  doi = {10.1145/3154485},
  url = {https://doi.org/10.1145/3154485},
  abstract = {Science fiction in particular offers students a way to cultivate 
their capacity for moral imagination.},
  issue_date = {August 2018},
  pagetotal = {11}
}

-

Thanks for your patience,

Alessandro Bertulli

Re: source block evaluation in #+DATE line

[Timothy]

Hi Andreas,

> how can I have a source block result in a #+Date line?

Short version: you can’t as `#+date' is not a [parsed keyword].

Individual export backends do limited processing, and IIRC you should be able to
use a macro.

All the best,
Timothy


[parsed keyword] 

Re: source block evaluation in #+DATE line

[Eric S Fraga]

On Wednesday, 11 May 2022 at 17:50, Eric S Fraga wrote:
> ⚠️ Caution: External sender
>
>
> On Wednesday, 11 May 2022 at 05:15, Andreas Leha wrote:
>> Thanks for the comments.  And sorry for the misleading example.  I do not
>> want to use source blocks to insert a date.  In fact I want to include
>> the current git commit hash on the title slide.
>
> I do this by:

[...] which I now realise uses a src block so probably not what you
want/need.

-- 
: Eric S Fraga, with org release_9.5.3-481-gaea24b in Emacs 29.0.50

Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export

[Pride Allman]

So basically, the export function is doing the overwrite for user options
but to reduce the number of inconsistency we can't use this patch for only
one such option.

Now you explained it I can't think of a way to solve it without rewriting
the whole thing. Or maybe I need to read the source code more deeply.

Would it be too much to hope for it to be integrated on the basis that
things like this can be added for other options in other export backend
too? Or somehow introduce the global settings there.

And considering the answer is no for the previous question; is there a
workaround for this? Something people use? Because having to manually edit
the table everytime I export is a bit too much for me.

Thank you.

On Wed, 11 May 2022, 08:19 Ihor Radchenko,  wrote:

> Pride Allman  writes:
>
> > This is my first patch so hopefully I followed the instructions
> correctly,
>
> Thanks for the patch! Patches are always welcome, though I do not fully
> agree with the approach you used in this particular one.
>
> > While using ~org-table-export~ on a table directly even with
> > ~org-latex-tables-booktabs~ set to ~t~, it exports a normal table instead
> > of booktabs table. But on the same situation, if you export the whole
> > buffer the table will be exported according to booktabs.
>
> I also find this discrepancy awkward.
>
> Normally, Org export options are chosen according to
> org-export-options-alist (see the docstring) and the equivalent
> variables in specific export backend (see org-export-define-backend
> 'latex in ox-latex.el).
>
> However, when you look into orgtbl-to-latex, orgtbl-to-html,
> orgtbl-to-texinfo, and orgtbl-to-unicode, they all overwrite certain
> export settings by force. Sometimes, even not leaving the user an option
> to choose. All those (list :option value ...) are force-overwriting the
> _global_ export defaults (see orgtbl-to-latex calling orgtbl-to-generic
> that calls org-export-get-environment with third argument) , including
> :latex-tables-booktabs. This is by design.
>
> While I do not like the current design, your patch will only create even
> more inconsistencies; The same problem will remain for other
> force-overwritten options.
>
> Best,
> Ihor
>

Re: source block evaluation in #+DATE line

[Eric S Fraga]

On Wednesday, 11 May 2022 at 05:15, Andreas Leha wrote:
> Thanks for the comments.  And sorry for the misleading example.  I do not
> want to use source blocks to insert a date.  In fact I want to include
> the current git commit hash on the title slide.

I do this by:

--8<---cut here---start->8---
#+NAME: mydateline
#+BEGIN_SRC emacs-lisp
(format "#+DATE: \\copyright{} %s\n" *this*) 
#+END_SRC

src_shell[:post mydateline() :results raw]{echo -n $(date +%Y) '@@latex:\\ 
\vspace*{0.1cm} \tiny \color{gray}@@' version $(git log --format=format:"%ad 
%h" --date=short | head -1 )} 
--8<---cut here---end--->8---

HTH,
eric
-- 
: Eric S Fraga, with org release_9.5.3-481-gaea24b in Emacs 29.0.50

How to stop results being hidden when using ":results drawer"?

[Richard Stanton]

I’m creating documents where I run Python code blocks that create LaTeX 
mathematical output that I want to be able to export to either LaTeX/PDF or 
HTML. 

Using :wrap in the header works fine, except that LaTeX complains about the 
unknown environment “results” (it still compiles the file to PDF fine).

Using :wrap export latex works fine for LaTeX export, but I can’t get HTML that 
way.

The recommended method seems to be to use :results drawer. This works fine from 
an export perspective to both LaTeX/PDF and to HTML. However, it has one 
significant drawback when I’m actually creating the document: the results 
drawer starts out hidden and to see what’s there I have to click on it. This 
makes debugging the code in the first place a lot less convenient.

Is there a way to use :results drawer and have the results NOT hidden by 
default?

Thanks for any suggestions!

Richard Stanton

Re: [PATCH] org-macs.el: Do not compare wall time and file modification time

[Paul Eggert]

The comments don't seem to match the code here.


+  (let* ((tangled-file (concat (file-name-sans-extension file) ".el"))
+ (file-mtime (file-attribute-modification-time
+  (file-attributes (file-truename file
+ (tangled-mtime (file-attribute-modification-time
+ (file-attributes (file-truename tangled-file)
+;; Tangle only if the Elisp file is older than the Org file.
+;; Filesystem may have coarse timestamp resolution (HFS+, FAT)
+;; so no need to update if timestamps are equal and thus
+;; `org-file-newer-than-p' can not be used here.
+(unless (and file-mtime
+ tangled-mtime
+ (not (time-less-p tangled-mtime file-mtime)))


Although this looks correct, there's no need to go to the work of 
computing file-mtime in the common case where tangled-mtime is nil.

Regarding arbitrary Org blocks

[Russell Adams]

I used to insert arbitrary blocks like:

#+BEGIN_IMPORTANT
yadda yadda
#+END_IMPORTANT

in my documents, and when I hit C-c ' to edit them it would give me a
basic buffer and I could edit the plain text within.

Some recent change instead now says "No special environment to edit
here". How can I get back that behavior?

I'm really just editing text blocks for Latex export, and the source
block type triggers some latex formatting. It's not source code
language, just plain text.

Could I add some minor mode to say text-mode with auto-fill-mode and
aspell somewhere when opening those blocks?

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: [PATCH] (v3) New LaTeX code export option: engraved

[Timothy]

Hi All,

I now have what I hope is the final set of patches[1].

Compared to v2 we have:
• a fix for % in captions (long standing bug)
• support for mathescaped code
• a news/manual entry for engraved
• a collection of tweaks based on Ihor’s lovely feedback 珞

I’ve also slipped in a patch to `org-latex--label' which adds the `lst:' prefix
(short for listings) to `\label's generated for source blocks. This seemed like 
a
decent idea while I was working on captions, if anyone thinks otherwise I’ll
happily leave it out.

Daniel, if you’re happy with these commits let me know and I’ll push them :)

All the best,
Timothy



Footnotes
─

[1] For getting this feature
into Org. I’m sure there will be tweaks in the future.
>From 18adbd0e1226cf3307090861e09e92bfa9cdfbf1 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Sun, 21 Nov 2021 14:35:34 +0800
Subject: [PATCH 01/13] ox-latex: Refactor `org-latex-src-block'

* lisp/ox-latex.el (org-latex-src-block): Extract the per-format logic
from `org-latex-src-block' into new dedicated functions:
+ `org-latex-src-block--verbatim'
+ `org-latex-src-block--custom'
+ `org-latex-src-block--minted'
+ `org-latex-src-block--listings'
This makes `org-latex-src-block' much less monolithic, taking it from
175 lines to 30, and I find also makes it easier to understand.
---
 lisp/ox-latex.el | 339 ++-
 1 file changed, 185 insertions(+), 154 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 841ad48bc..c2f728a1c 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2997,164 +2997,195 @@ (defun org-latex-src-block (src-block _contents info)
 	   (float (plist-get attributes :float))
 	   (listings (plist-get info :latex-listings)))
   (cond
-   ;; Case 1.  No source fontification.
((or (not lang) (not listings))
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
-(org-export-format-code-default src-block info
-  (cond ((string= "multicolumn" float)
- (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
- (plist-get info :latex-default-figure-position)
- (if caption-above-p caption-str "")
- verbatim
- (if caption-above-p "" caption-str)))
-(caption (concat
-  (if caption-above-p caption-str "")
-  verbatim
-  (if caption-above-p "" (concat "\n" caption-str
-(t verbatim
-   ;; Case 2.  Custom environment.
+(org-latex-src-block--verbatim src-block info lang caption caption-above-p label
+   num-start retain-labels attributes float))
(custom-env
-	(let ((caption-str (org-latex--caption/label-string src-block info))
-  (formatted-src (org-export-format-code-default src-block info)))
-  (if (string-match-p "\\`[a-zA-Z0-9]+\\'" custom-env)
-	  (format "\\begin{%s}\n%s\\end{%s}\n"
-		  custom-env
-		  (concat (and caption-above-p caption-str)
-			  formatted-src
-			  (and (not caption-above-p) caption-str))
-		  custom-env)
-	(format-spec custom-env
-			 `((?s . ,formatted-src)
-			   (?c . ,caption)
-			   (?f . ,float)
-			   (?l . ,(org-latex--label src-block info))
-			   (?o . ,(or (plist-get attributes :options) "")))
-   ;; Case 3.  Use minted package.
+(org-latex-src-block--custom src-block info lang caption caption-above-p label
+ num-start retain-labels attributes float custom-env))
((eq listings 'minted)
-	(let* ((caption-str (org-latex--caption/label-string src-block info))
-	   (placement (or (org-unbracket-string "[" "]" (plist-get attributes :placement))
-			  (plist-get info :latex-default-figure-position)))
-	   (float-env
-		(cond
-		 ((string= "multicolumn" float)
-		  (format "\\begin{listing*}[%s]\n%s%%s\n%s\\end{listing*}"
-			  placement
-			  (if caption-above-p caption-str "")
-			  (if caption-above-p "" caption-str)))
-		 (caption
-		  (format "\\begin{listing}[%s]\n%s%%s\n%s\\end{listing}"
-			  placement
-			  (if caption-above-p caption-str "")
-			  (if caption-above-p "" caption-str)))
-		 ((string= "t" float)
-		  (concat (format "\\begin{listing}[%s]\n"
-  placement)
-			  "%s\n\\end{listing}"))
-		 (t "%s")))
-	   (options (plist-get info :latex-minted-options))
-	   (body
-		(format
-		 "\\begin{minted}[%s]{%s}\n%s\\end{minted}"
-		 ;; Options.
-		 (concat
-		  (org-latex--make-option-string
-		   (if (or (not num-start) (assoc "linenos" options))
-		   options
-		 (append
-		  `(("linenos")
-			("firstnumber" ,(number-to-string (1+ num-start
-		  options)))
-		  (let ((local-options (plist-get attributes :options)))
-	

Re: [oc] multiple cite_export keywords for multiple export processors?

[Ihor Radchenko]

"Bruce D'Arcus"  writes:

>> Emm. org-cite-export-processors?
>
> So I recognize I don't fully understand the org export system, but
> that sets global defaults.
>
> What if I want to set a different style on a specific document?

There is also #+cite_export: keyword, but it only sets global processor.
You cannot choose per-export backend options. So, you can use #+bind to
set org-exportprocessors explicitly in buffer.

Best,
Ihor

Re: [how to joint column/rows of tables that are in different files (id?)]

[Uwe Brauer]

>>> "JK" == John Kitchin  writes:

> Can you make a temporary org-buffer that copies all those tables into
> one place, and then join them?

My workflow (in case anybody finds this helpful)
#+begin_src 

* Localisation of the program files

Each file you want to correct is located in a different easy to identify 
directory (folder).

* Correction of the program files

** Run the code
In case they are Matlab file, you can use emacs powerful matlab-mode and its 
corresponding shell to check the code

** Annotate your remarks 

I recommend using org-remark-mark (3rd party package) and org-remark-open
Put your comments, and qualification as Properties. They are saved in a file 
called marginalia.org in the same directory

Here is an example

#+begin_src 
** DONE The summary of all exercises
   :PROPERTIES:
   :Ap: Student1
   :Com1: E1: Bad formatted file, no explanation of the results
   :Com2: E2: Results are ok, again the results are not interpreted.
   :Com3: E3: Only one of the ODE has been solved.
   :org-remark-beg: 5498
   :Ej1: 15
   :Ej2: 20
   :Ej3: 35
   :org-remark-end: 5460
   :org-remark-id: 50040a36
   :org-remark-label: nil
   :org-remark-link: [[file:annu_examen_mayo_student1.m::176]]
   :END:

#+end_src

Then you generate a table via
** Table
   :PROPERTIES:
   :ID: student1
   :END:


#+BEGIN: columnview :maxlevel 2  :skip-empty-rows t :indent nil :hlines 2  
:format "%5TODO(Status) %5Ap(Name) %5Ej1(Ej1/20)  %5Ej2(Ej2/25)  %5Ej3(Ej3/55)  
%5Res(Result) %5Com1(Com1) %5Com2(Com2) %5Com3(Com3)" 
| Status | Name | Ej1/20 | Ej2/25 | Ej3/55 | Result | Com1  
 | Com2 
  | Com3 |
|+--+++++++--|
| DONE   | Student1 | 15 | 20 | 35 |  7 | E1: Bad formatted 
file, no explanation of the results | E2: Results are ok, again the results are 
not interpreted. | E3: Only one of the ODE has been solved. |
#+TBLFM: $6=vsum($3..$5)/10;
#+END

** Run =org-id-update-id-locations=

* The master file

Create a master file with the following content

| Status | Name | Ej1/20 | Ej2/25 | Ej3/55 | Result | Comment1  
 | Comment2 
  | Comment3 |
|+--+++++++--|
| DONE   | Student1 | 15 | 20 | 35 |  7 | E1: Bad formatted 
file, no explanation of the results | E2: Results are ok, again the results are 
not interpreted. | E3: Only one of the ODE has been solved. |
#+TBLFM: @2='(identity remote(student1,@>$$#));




#+end_src


smime.p7s
Description: S/MIME cryptographic signature

Re: how to transpose a table but not deleting the horizontal lines

[Uwe Brauer]

>>> "t" == tbanelwebmin   writes:

> The orgtbl-arggregate package (on Melpa and GitHub) does that.
> Horizontal lines are converted to empty columns.
> Transposing again recreates the original horizontal lines.

> Beware, as opposed to org-table-transpose-table-at-point, it does not modify 
> the source table, it creates a new transposed table.

> Type C-c C-x x in an empty space in the buffer
> Then answer "transpose", and follow the wizard.

Thanks
I will have a look!



smime.p7s
Description: S/MIME cryptographic signature

Re: [BUG] Org-cycle strange behaviour in Emacs 29.0.50 [9.5.3 (9.5.3-g0b07b3 @ /home/yaslam/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Yusef Aslam  writes:

> Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
> 3.24.31, cairo version 1.16.0)
>  of 2022-05-09
> Package: Org mode version 9.5.3 (9.5.3-g0b07b3 @ 
> /home/yaslam/.emacs.d/straight/build/org/)
>
> I have strange behaviour in Emacs 29.0.50 and the org-cycle function inside 
> org-mode, my config is normal and I haven't changed the behaviour for the TAB 
> key inside org-mode.
>
> When I am in an org-mode document, pressing TAB doesn't show subtrees, I 
> bound org-cycle to double click on the mouse and it works everytime, just 
> when pressing TAB on a heading, it doesn't show the content of that heading 
> until I unfocus and then refocus the Emacs window.
>
> I switched back to Emacs 27.2 and went into one of my files that are in 
> org-mode, and org-cycle works perfectly when pressing TAB everytime.

Thanks for the report! Are you able to reproduce the issue starting from
emacs -Q? See https://orgmode.org/manual/Feedback.html

Best,
Ihor

Re: ivy-done and "Unregistered buffer modifications detected"

[Ihor Radchenko]

William Denton  writes:

> I was fiddling with my init file and something with pdf-tools blew up and 
> initialization went wrong and I lost my desktop history list of buffers I 
> always 
> have open.  When I fixed the problem (by dropping pdf-tools, which I realized 
> I 
> never used), I had to load all the files I like to have open.  I opened four, 
> and for each one I got the same warning, as you can see below.  Further below 
> that is the full Org debug dump.
>
> I don't know if the ivy-done clue is enough to be helpful (maybe it just 
> means 
> there's something funny involving ivy), but if there's more I can do I'm glad 
> to 
> help.

Thanks for the report!

ivy-done does not appear to do anything with Org buffer. So, the warning
looks rather strange.

I am wondering if you can reproduce the problem using some minimal
config starting from emacs -Q. See
https://orgmode.org/manual/Feedback.html or
https://open.tube/videos/watch/4d819114-43bf-42df-af94-f94fc53dd0d9

Best,
Ihor

Re: [oc] multiple cite_export keywords for multiple export processors?

[Bruce D'Arcus]

On Wed, May 11, 2022 at 9:21 AM Ihor Radchenko  wrote:
>
> "Bruce D'Arcus"  writes:
>
> > I just saw a post on reddit that reminded me of this issue.
> >
> > User wants to use the oc-biblatex export processor for latex export,
> > but otherwise use oc-csl.
> >
> > They want to specify styles for each.
> >
> > This isn't possible currently; one has to modify the org source file
> > for each export target.
> >
> > Is there a relatively easy way to fix this?
>
> Emm. org-cite-export-processors?

So I recognize I don't fully understand the org export system, but
that sets global defaults.

What if I want to set a different style on a specific document?

Bruce

Re: org-agenda todos list sorted by earliest deadline first

[Ihor Radchenko]

Sébastien Gendre  writes:

> The only option I have to set is:
> ```
> (setq org-agenda-sorting-strategy '((agenda deadline-down time-up habit-up 
> priority-down timestamp-down category-keep)
>   (todo deadline-up priority-down 
> category-keep)
>   (tags priority-down category-keep)
>   (search category-keep)))
> ```
>
> Do the `deadline-up` option will apply to all todo lists in the agenda ?
> Even the ones in custom views ?

Yes. (setq org-agenda-sorting-strategy ...) is global setting.
However, you can also set it locally inside custom agenda command if you
wish. See the docstring of org-agenda-custom-commands:

>> settings  A list of option settings, similar to that in a let form, so like
>>  this: ((opt1 val1) (opt2 val2) ...).   The values will be
>>  evaluated at the moment of execution, so quote them when needed.

optN can be org-agenda-sort-strategy.

Best,
Ihor

Re: [oc] multiple cite_export keywords for multiple export processors?

[Ihor Radchenko]

"Bruce D'Arcus"  writes:

> I just saw a post on reddit that reminded me of this issue.
>
> User wants to use the oc-biblatex export processor for latex export,
> but otherwise use oc-csl.
>
> They want to specify styles for each.
>
> This isn't possible currently; one has to modify the org source file
> for each export target.
>
> Is there a relatively easy way to fix this?

Emm. org-cite-export-processors?

Best,
Ihor

Re: [PATCH v4] org-encode-time compatibility and convenience helper

[Ihor Radchenko]

Max Nikulin  writes:

>> +  (defmacro org-encode-time ( time)
>> +(pcase (length time) ; Emacs-29 since d75e2c12eb
>> +  (1 `(encode-time ,@time))
>> +  ((or 6 9) `(encode-time (list ,@time)))
>> +  (_ (error "`org-encode-time' may be called with 1, 6, or 9 
>> arguments but %d given"
>> +(length time)
>
> Should it be something like the following?
>
> (signal 'wrong-type-argument (list '(1 6 9) (length time)))
>
> or even
>
> (signal 'wrong-type-argument
>   (list '(lambda (n-args) (memq n-args) '(1 6 9)) (length time)))
>
> Usually "wrong type argument" errors give no clue even related to called 
> function til enabling enter debugger on error and realizing how to 
> reproduce the problem.

The current error is fine. I'd rather propose Emacs to change the "wrong
type argument" message to mention the function name.

>> +  ;; In Emacs-27 and Emacs-28 `encode-time' does not support 6 
>> elements
>> +  ;; list argument so `org-encode-time' can not be outside of 
>> `pcase'.
>> +  (pcase-let
>> +  ((`(,_ ,_ ,_ ,d ,m ,y ,dow . ,_) (decode-time start)))
>> +(pcase step
>> +  (`day (org-encode-time 0 0 org-extend-today-until (1+ d) 
>> m y))
>> +  (`week
>> +   (let ((offset (if (= dow week-start) 7
>> +   (mod (- week-start dow) 7
>> + (org-encode-time 0 0 org-extend-today-until (+ d 
>> offset) m y)))
>> +  (`semimonth (org-encode-time 0 0 0
>> +   (if (< d 16) 16 1)
>> +   (if (< d 16) m (1+ m)) y))
>> +  (`month (org-encode-time 0 0 0 month-start (1+ m) y))
>> +  (`year (org-encode-time 0 0 org-extend-today-until 1 1 
>> (1+ y))
>
> I do not like repeating of `org-encode-time' but do not see another way 
> till Emacs-29 will become the lowest supported version.

This is fine. AFAIK, other parts of time handling code is full of conds
and pcases.

>> +(org-encode-time
>> + (apply #'list
>> +(or (car time0) 0)
>> +(+ (if (eq timestamp? 'minute) n 0) (nth 1 time0))
>> +(+ (if (eq timestamp? 'hour) n 0)   (nth 2 time0))
>> +(+ (if (eq timestamp? 'day) n 0)(nth 3 time0))
>> +(+ (if (eq timestamp? 'month) n 0)  (nth 4 time0))
>> +(+ (if (eq timestamp? 'year) n 0)   (nth 5 time0))
>> +(nthcdr 6 time0
>>(when (and (memq timestamp? '(hour minute))
>>   extra
>>   (string-match "-\\([012][0-9]\\):\\([0-5][0-9]\\)" extra))
>
> I am tempting to write something like
>
>(let* ((ts (copy-sequence time0))
>(ord (memq timestamp? '(year month day hour minute)))
>(field (and ord (nthcdr (length ord) ts
>  (when field
>(setcar field (+ (car field) n)))
>  (org-encode-time ts))
>
> but I am afraid it will make the code rather obscure.

Yes, the second version is rather hard to understand. The proper
solution would be writing (or using) some high-level time handling
library and then using it in Org. Then, we would not need to deal with
low-level time representations so frequently.

>> +  (org-encode-time
>> +   (append '(0)
>> +   (mapcar
>> +(lambda (prop) (or (org-element-property prop timestamp) 0))
>> +(if end '(:minute-end :hour-end :day-end :month-end :year-end)
>> +  '(:minute-start :hour-start :day-start :month-start
>> +  :year-start)))
>> +   '(nil -1 nil
>>  
>>  (defun org-timestamp-has-time-p (timestamp)
>>"Non-nil when TIMESTAMP has a time specified."
>
> Hardly may be considered as an example of elegant code.

It is ok. You also could do it as

`(0 ,@(mapcar (lambda (prop) ...) (if ...)) nil -1 nil)

AFAIK, there is nothing much you can improve further without using
function composition from dash.el.

Best,
Ihor

Re: [BUG] org-babel-load-file can not compile file

[Ihor Radchenko]

Max Nikulin  writes:

> Actual result:
>> Compiling /home/ubuntu/examples/org/ex-ob-load-file.el...done
>> Wrote /home/ubuntu/examples/org/ex-ob-load-file.elc
>> progn: Cannot open load file: No such file or directory, ex-ob-load-file.el
>
> It seems, it is a regression caused by the Org commit 
> 0193b543e9ef84bfefe76d55e330d5b1cb842cef
>
>> -  (byte-compile-file tangled-file 'load)
>> +  (byte-compile-file tangled-file)
>> +  (load tangled-file)


What if you substitute the load call with
(load (byte-compile-dest-file tangled-file))?

Best,
Ihor

Re: [PATCH] org-macs.el: Do not compare wall time and file modification time

[Max Nikulin]

On 06/05/2022 23:56, Max Nikulin wrote:
Mark Barton to emacs-orgmode, emacs-devel. master 4a1f69ebca 2/2: Use 
(TICKS . HZ) for current-time etc. Tue, 26 Apr 2022 23:37:50 -0700. 
https://list.orgmode.org/bf5b9308-3fef-4dc6-98c9-bff36f19d...@gmail.com


The change also breaks org-file-newer-than-p function that triggered the
debugger while loading my init that uses org babel.


I think, it should be fixed in the bugfix Org branch.  The attached 
patch is a compromise to some degree, but I do not see a robust solution.


Thinking more I realized that `org-file-newer-than-p' should not be 
reused for `org-babel-load-file'. I am attaching an updated patch for 
which I do not see any real drawback.


The only change in behavior is that if a file had modification time in 
future and it is overwritten by `org-compile-time' to current time than 
the function reports failure. I consider such case as a rare and 
peculiar one.From e5f98dbc729904297bef529009ade96361dd4dd2 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Fri, 6 May 2022 23:34:52 +0700
Subject: [PATCH] org-macs.el: Do not compare wall time and file modification
 time

* lisp/org-macs.el (org-file-newer-than-p): Fix Emacs-29 problem with
changed representation of system clock timestamp.  Recommend passing
file modification time and do not truncate its precision.
(org-compile-file): Store file modification time instead of system clock
for later comparison by `org-file-newer-than-p'.
* lisp/org.el (org-babel-load-file): Do not use `org-file-newer-than-p'
to consider the .el file as up to date when its modification time is the
same as for the source .org file.

Unchanged timestamp of a file means failure of `org-compile-file' but in
`org-babel-load-file' the target may be considered up to date if its
timestamp is equal to the one for prerequisite.
So `org-file-newer-than-p' is not suitable for both cases.  The
difference matter for filesystems with coarse timestamp resolution, for
example HFS+.

Reported by Mark Barton 
https://list.orgmode.org/bf5b9308-3fef-4dc6-98c9-bff36f19d...@gmail.com

During discussion of the issue Paul Eggert 
suggested over variants of the changes in the same thread.
---
 lisp/org-macs.el | 32 +---
 lisp/org.el  | 18 --
 2 files changed, 33 insertions(+), 17 deletions(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index b10725bd5..556bf658d 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -256,16 +256,26 @@ ignored in this case."
 ;;; File
 
 (defun org-file-newer-than-p (file time)
-  "Non-nil if FILE is newer than TIME.
-FILE is a filename, as a string, TIME is a list of integers, as
-returned by, e.g., `current-time'."
-  (and (file-exists-p file)
-   ;; Only compare times up to whole seconds as some file-systems
-   ;; (e.g. HFS+) do not retain any finer granularity.  As
-   ;; a consequence, make sure we return non-nil when the two
-   ;; times are equal.
-   (not (time-less-p (cl-subseq (nth 5 (file-attributes file)) 0 2)
-			 (cl-subseq time 0 2)
+  "Non-nil if FILE modification time is greater than TIME.
+TIME should be obtained earlier for the same FILE name using
+
+  (file-attribute-modification-time (file-attributes file))
+
+If TIME is nil (file did not exist) then any existing FILE
+is considered as a newer one.  Some file systems have coarse
+timestamp resolution, for example 1 second on HFS+ or 2 seconds on FAT,
+so nil may be returned when file is updated twice within a short period
+of time.  File timestamp and system clock `current-time' may have
+different resolution, so attempts to compare them may give unexpected
+results.
+
+Attempt to check whether a derived file has been updated in
+response to modification of its source file may give unreliable
+result.  Equal timestamps in such case may mean that the derived
+file is up to date however this function returns nil assuming
+that the FILE is not modified."
+  (let ((mtime (file-attribute-modification-time (file-attributes file
+(and mtime (or (not time) (time-less-p time mtime)
 
 (defun org-compile-file (source process ext  err-msg log-buf spec)
   "Compile a SOURCE file using PROCESS.
@@ -299,7 +309,7 @@ it for output."
 	 (full-name (file-truename source))
 	 (out-dir (or (file-name-directory source) "./"))
 	 (output (expand-file-name (concat base-name "." ext) out-dir))
-	 (time (current-time))
+	 (time (file-attribute-modification-time (file-attributes output)))
 	 (err-msg (if (stringp err-msg) (concat ".  " err-msg) "")))
 (save-window-excursion
   (pcase process
diff --git a/lisp/org.el b/lisp/org.el
index 54350faee..c1ce57c4d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -232,12 +232,18 @@ and then loads the resulting file using `load-file'.  With
 optional prefix argument COMPILE, the tangled Emacs Lisp file is
 byte-compiled before it is loaded."
   (interactive "fFile to load: \nP")
-  (let ((tangled-file (concat (file-name-sans-extension 

Re: [PATCH] lisp/org-table.el: Use booktabs on org-table-export

[Ihor Radchenko]

Pride Allman  writes:

> This is my first patch so hopefully I followed the instructions correctly,

Thanks for the patch! Patches are always welcome, though I do not fully
agree with the approach you used in this particular one.

> While using ~org-table-export~ on a table directly even with
> ~org-latex-tables-booktabs~ set to ~t~, it exports a normal table instead
> of booktabs table. But on the same situation, if you export the whole
> buffer the table will be exported according to booktabs.

I also find this discrepancy awkward.

Normally, Org export options are chosen according to
org-export-options-alist (see the docstring) and the equivalent
variables in specific export backend (see org-export-define-backend
'latex in ox-latex.el).

However, when you look into orgtbl-to-latex, orgtbl-to-html,
orgtbl-to-texinfo, and orgtbl-to-unicode, they all overwrite certain
export settings by force. Sometimes, even not leaving the user an option
to choose. All those (list :option value ...) are force-overwriting the
_global_ export defaults (see orgtbl-to-latex calling orgtbl-to-generic
that calls org-export-get-environment with third argument) , including
:latex-tables-booktabs. This is by design.

While I do not like the current design, your patch will only create even
more inconsistencies; The same problem will remain for other
force-overwritten options.

Best,
Ihor

Re: citation biblatex fullcite

[Bruce D'Arcus]

On Wed, May 11, 2022 at 6:43 AM Andreas Leha
 wrote:
>
> "Bruce D'Arcus"  writes:
>
> > On Tue, May 10, 2022, 11:20 PM Andreas Leha
> >  wrote:
> >>
> >> Hi all,
> >>
> >> how can I use the (rather) new citation engine with the biblatex backend
> >> to export to \fullcite ?
> >
> > We should add a style for this that maps to biblatex fullcite and
> > natbib bibentry, and which ultimately would work as well in oc-csl.
> >
> > But in the meantime, you can create a custom one.
> >
> > (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
> >
>
> Dear Bruce and Dominik,
>
> Thanks for the swift reply!  I seem to be missing something:
>
> Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles)
>
> What am I missing?

That variable was added more recently, after org-cite was merged.

Perhaps you have an older version?

Bruce

Re: Concatenate properties

[Ihor Radchenko]

Tyler Grinn  writes:

> Ihor Radchenko  writes:
>
>> Tyler Grinn  writes:
>>
>>>
>>> Could you provide an example of what the value of that variable would be
>>> if, for instance, I wanted PROP_A and PROP_B to be joined with a single
>>> space and PROP_C and PROP_D to be concatenated? Or better yet, have the
>>> default be to join with a single space for any property and have only
>>> PROP_C and PROP_D concatenated?
>>
>> Say,
>>
>> '(("PROP_[CD]" . ""))
>>
>> or
>>
>> '(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))
>>
>> Best,
>> Ihor
>
> I'm not sure forcing regular expressions for all use cases is ideal. Is
> there a way to allow the option (I'm calling it org-property-separators)
> to allow either regular expressions or exact matches, like
> org-use-property-inheritance does?

It's up to you. I merely suggested that the new option should work
similarly to org-use-property-inheritance. It will not be the exact
match since we also need to provide the separator string.

> Other than that I'm mostly ready to send in my first patch. Should I
> attach it in this thread or start a new one?

Keeping the patch within this thread will be more reasonable for future
readers. Just remember to prefix the subject line with [PATCH].

Best,
Ihor

Re: [PATCH] Re: org-agenda-clock-report-header

[Ihor Radchenko]

Colin Baxter  writes:

> Unfortunately, I see no difference in my clock tables whether I have
> org-agenda-clock-report-header set to t, nil or something like
> "My-Heading", or if I put :Header: as a tag in the file headline that
> contains the clock table, or if I write :Header t in the #+BEGIN:
> clocktable line. You can see I'm ringing the changes in ignorant
> desperation. I'm pretty stupid so I'm obviously missing something
> fundamental here - but what?

Because your clock tables in Org _files_ have nothing to do with agenda.
There is no "Agenda clock report mode" when you create an ordinary clock
report in Org buffers.

Best,
Ihor

Re: [BUG] Error when editing properties in column view [9.5.3 (release_9.5.3-452-g407104 @ /home/mbork/others-works/emacs/org-mode/lisp/)]

[Ihor Radchenko]

Marcin Borkowski  writes:

> When I try to edit a property in column view, I get the following error 
> message:
>
> Invalid column specification format: nil
>
> This only seems to happen if the point is not too close to the left
> margin.  I did a bit of digging and found out that the culprit is most
> probably the `org-columns-update' function, which contains this:

Thanks for the report!
Confirmed.

This (or similar) issue also appears when you run make test using Emacs
master. AFAIK, it has been introduced in some of the Emacs master
commits a few months ago where Emacs changed its behaviour.

We probably need to bisect Emacs and figure out what exactly changed and
whether the problem is on Emacs or Org side.

Best,
Ihor

Re: [BUG] void function incf in org-screenshot [9.5.3 (9.5.3-ga3dac4 @ /home/jds6696/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Justin Silverman  writes:

> I am getting an error
>
>
> org-screenshot-generate-file-name: Symbol’s function definition is void: incf

Thanks for the report!
Note that org-screenshot is not a part of Org anymore. See the first
item in https://orgmode.org/Changes.html.

Nevertheless, this particular issue has been resolved in the new
repository holding org-contrib (https://git.sr.ht/~bzg/org-contrib).
Please, update your org-contrib to fix the error.

Best,
Ihor

Re: oc-basic "Wrong value for ENTRY-OR-KEY" error on emacs master (29.x) [Was: Bibliographies on export with ox-context and ox-epub]

[Ihor Radchenko]

Kaushal Modi  writes:

> On Mon, May 9, 2022 at 5:44 PM Kaushal Modi  wrote:
>>
>> I have now sent this to Emacs bug tracking:
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342
>
> Thanks for the debug[1] Ihor!
>
> This issue was quickly fixed on Emacs master in
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d221c02fa1db17e1275687f0bbce4ff1499119a1.
>
> [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342#11

Thanks for reporting back!

Note that apart from the problem on Emacs side, there appears to be a
problem with org-cite-basic-export-bibliography.

org-cite-basic-export-bibliography uses org-cite-basic--print-entry,
which fails to print keys, which are not in .bib files. As a result,
#+print_bibliography: appears to fail all the time when the document
contains invalid cite keys.

I consider this as a bug. At least org-cite-basic-export-bibliography
could provide a more useful error message. Or maybe even skip the
invalid keys. Or, similar to LaTeX, print ???. I am not sure which way
will be more canonical according to general oc.el design.

Best,
Ihor

Re: [PATCH] (v2) New LaTeX code export option: engraved

[Ihor Radchenko]

Timothy  writes:

Thanks for the replies. I consider all but one as resolved.

>> What will happen if there is no [LISTINGS-SETUP]?
>
> Captioned/Floating code blocks won’t work.

Can you also add this to the documentation of the preamble variable?
Otherwise, it may not be very clear what inclusion/removal of
[LISTINGS-SETUP] does.

Best,
Ihor

Re: org-fold problems

[Ihor Radchenko]

Eric S Fraga  writes:

>> Note that I tried to run ediff-buffers on Org buffers and everything
>> remains folded with stable Org 9.5 as well.
>
> That has not been my experience.  I think... but cannot verify.  I do
> use drawers a lot and differences are often in them for the type of
> document I was working on last week.
>
> With ediff, we need the documents being compared to be completely
> expanded in general.

I understand the issue. However, I do not fully understand why you get
the documents fully unfolded. Can you create a reproducible example that
shows how to compare to Org buffers/files and get them unfolded using an
earlier Org version from emacs -Q?

Best,
Ihor

Re: citation biblatex fullcite

[Andreas Leha]

"Bruce D'Arcus"  writes:

> On Tue, May 10, 2022, 11:20 PM Andreas Leha
>  wrote:
>>
>> Hi all,
>>
>> how can I use the (rather) new citation engine with the biblatex backend
>> to export to \fullcite ?
>
> We should add a style for this that maps to biblatex fullcite and
> natbib bibentry, and which ultimately would work as well in oc-csl.
>
> But in the meantime, you can create a custom one.
>
> (add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))
>

Dear Bruce and Dominik,

Thanks for the swift reply!  I seem to be missing something:

Debugger entered--Lisp error: (void-variable org-cite-biblatex-styles)

What am I missing?

Best,
Andreas



> Bruce
>
>> The use-case:
>> When creating (beamer) presentations I prefer to have the full citation
>> on the slide rather than an abbreviation.
>>
>> Thanks in advance!
>>
>> Best,
>> Andreas
>>
>>

Re: citation biblatex fullcite

[Bruce D'Arcus]

On Tue, May 10, 2022, 11:20 PM Andreas Leha
 wrote:
>
> Hi all,
>
> how can I use the (rather) new citation engine with the biblatex backend
> to export to \fullcite ?

We should add a style for this that maps to biblatex fullcite and
natbib bibentry, and which ultimately would work as well in oc-csl.

But in the meantime, you can create a custom one.

(add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

Bruce

> The use-case:
> When creating (beamer) presentations I prefer to have the full citation
> on the slide rather than an abbreviation.
>
> Thanks in advance!
>
> Best,
> Andreas
>
>

Re: citation biblatex fullcite

[Dominik Schrempf]

Hi Andreas,

thank you for asking this question. I had the same problem, and I think it
should be fixed.

A workaround is described here as part of a lengthy discussion:
https://list.orgmode.org/87r16vtpmp@gmail.com/

(add-to-list ’org-cite-biblatex-styles ’(“full” nil “fullcite” nil nil))

Then you should be able to use [cite/full:...]

Dominik

Andreas Leha  writes:

> Hi all,
>
> how can I use the (rather) new citation engine with the biblatex backend
> to export to \fullcite ?
>
> The use-case:
> When creating (beamer) presentations I prefer to have the full citation
> on the slide rather than an abbreviation.
>
> Thanks in advance!
>
> Best,
> Andreas

Re: [how to joint column/rows of tables that are in different files (id?)]

[Uwe Brauer]

>>> "JK" == John Kitchin  writes:

> Can you make a temporary org-buffer that copies all those tables into
> one place, and then join them?

Thanks, I think will use a different approach and only copy certain
rows, via the remote function as in

** The target Rows
| Nombre | Color | Level | Quantity |
| Monday | Red   |30 |   11 |
||   |   |  |
#+TBLFM: @1=remote(test,@2$$#)::@2=remote(test,@3$$#)


smime.p7s
Description: S/MIME cryptographic signature