Re: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir

[gnuric]

Hi Max,

Thanks for your reply.

"Max Nikulin"  writes:

> On 26/02/2023 08:52, gnu...@pm.me wrote:
>> (basically similar to what #include
>> directive in C preprocessor would do, e.g.). As of now, the
>> above
>> s.org exports to s.html which has the file: link converted to
>>
>> file:///home/user/media/s/media/s01_image.png
>
> Doesn't cpp behave in a similar way?
>
> grep --include=*.h -r '' h-0.h include-1/
> h-0.h:
> h-0.h:#include "include-1/h-1.h"
> h-0.h:
> h-0.h:extern int h0;
> include-1/h-1.h:
> include-1/h-1.h:#include "include-2/h-2.h"
> include-1/h-1.h:
> include-1/h-1.h:extern int h1;
> include-1/include-2/h-2.h:
> include-1/include-2/h-2.h:extern int h2;
>
You have two #include directives in your example, which are
processed recursively according to the preprocessor rules. What I
had in mind was one #include preprocessor directive (similar to
one #+INCLUDE: 'directive' in Org) and a non-preprocessor
directive (`file:' in Org).
> cpp -nostdinc h-0.h
> # 1 "h-0.h"
> # 1 ""
> # 1 ""
> # 1 "h-0.h"
>
> # 1 "include-1/h-1.h" 1
>
> # 1 "include-1/include-2/h-2.h" 1
>
> extern int h2;
> # 3 "include-1/h-1.h" 2
>
> extern int h1;
> # 3 "h-0.h" 2
>
> extern int h0;
>
>
> So in a file residing in ./include-1/ reference to
> "include-2/h-2.h"
> means ./include-1/include-2/h-2.h, not ./include-2/h-2.h
Regards,
Omid

ox-beamer/latex questions

[Leo Butler]

Hello,

I have a couple questions about TODO items, cookies and export. I am
unable to find anything the manual that seems relevant. Please see the
attached.

TIA,
Leo

#+TITLE: ox-beamer/latex questions
#+AUTHOR: Leo Butler
#+OPTIONS: H:2 toc:t num:t tags:nil todo:nil
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+LATEX_COMPILER: lualatex
#+STARTUP: beamer

* TODO [0/1] Outline
** TODO [1/2] Questions
*** DONE:B_block:
:PROPERTIES:
:BEAMER_env: block
:END:
With =ox-beamer=, =TODO= markers mangle the output. That looks like a bug to me.

*** TODO Filter out cookies
:PROPERTIES:
:BEAMER_act: <2->
:END:
I would like to be able to remove the =TODO= cookies, =[1/2]= and =[0/1]=, on export.
How can I do that?


ox-beamer-q.pdf
Description: ox-beamer-q.pdf

Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)

[gnuric]

Hi Timothy,

Thanks for your reply.

"Timothy"  writes:

> Hi Ihor,
>
>> This sounds like a reasonable request.
>> What we may do here is allowing a new parameter :verbatim
>
> From a read of the original email, it sounds like a `:dir'
> parameter could also
> solve this use case, and allow for a bit more flexibility.
>
Is `:dir' a parameter to pass to `#+INCLUDE:'? I don't see it in
the manual:
https://orgmode.org/manual/Include-Files.html
> All the best,
> Timothy

Regards,
Omid

Re: How to produce an org-ref citation from ivy-bibtex

[John Kitchin]

You can try something like this

#+BEGIN_SRC emacs-lisp
(setq bibtex-completion-format-citation-functions
  '((org-mode  . (lambda (keys) (org-ref-insert-cite-keys keys) ""))
(latex-mode. bibtex-completion-format-citation-cite)
(markdown-mode . bibtex-completion-format-citation-pandoc-citeproc)
(default   . bibtex-completion-format-citation-default)))
#+END_SRC

it seems like ivy-bibtex at least expects some kind of string to be
returned, but org-ref-insert-cite-keys does the insertion for you.

On Sun, Feb 26, 2023 at 11:19 AM Sven Bretfeld 
wrote:

> Hi everybody
>
> Is it at all possible to produce a correct org-ref citation format
> from ivy-bibtex (or helm-bibtex, I tried both)? What I mean by
> "correct" is the format: [[cite:]].
>
> The problem seems to come down to the question what has to be inserted
> in the 2nd line here:
>
> (setq bibtex-completion-format-citation-functions
>   '((org-mode  . ??)
> (latex-mode. bibtex-completion-format-citation-cite)
> (markdown-mode . bibtex-completion-format-citation-pandoc-citeproc)
> (default   . bibtex-completion-format-citation-default)))
>
> (A) Not setting the variable at all, defaults to producing an ebib
> link which is of no use to me at all.
>
> (B) Putting org-ref-helm-bibtex-insert-citation here (as found on
> reddit) does not work, since the function does not seem to exist
> anymore.
>
> (C) Putting org-ref-insert-cite-link here is obviously wrong. Choosing
> that from the list of ivy-bibtex-actions, just calls the function
> interactively, you have to search for the bib-entry again and the
> resulting link looks like: [[cite:]]^&. The terminating '^&'
> obviously makes subsequent LaTeX-exports fall.
>
> (D) Putting "bibtex-completion-format-citation-org-cite" here,
> produces standard org-links: [cite:@citekey]. These are not correctly
> exported to a tex file when the org-ref package is loaded.
>
> The only working solution I have found is to use org-ref's own cite
> function org-ref-insert-cite-link. I know that ivy-bibtex can be set
> as backend (require 'org-ref-ivy). But in this way ivy-bibtex's other
> actions (like opening an associated PDF or note file) are lost.
>
> It would be nice to be able to use a SINGLE key-binding to select a
> bib-entry and then decide what to do with it (insert org reference,
> insert tex reference, open pdf, etc.). This was possible earlier (I
> did that for years with older versions of org-ref-helm) but is
> apparently no longer possible now.
>
> Many thanks for help and suggestions,
>
> Sven
>
>

Broken org-persist-storage probably leads to ‘org-open-at-point’ ask for TAGS file

[Göktuğ Kayaalp]

Hello,

I have discovered a weird behaviour that I have tracked back to
org-persist and org-element-cache, where after some time, when I try to
follow a document internal link in org mode, whether to a headline or to
a =<>=, it would ask me to load a TAGS file, I think somewhat
like how xref might ask you to do when you call say
‘xref-find-definitions’.

This has been going on for a few weeks I think and I finally had a
chance to debug this, and it appears that some problem in the persistent
cache might be triggering this bug. I haven’t been able to fully debug
the problem because by the time I had discovered it had anything to do
with org-persist and where the storage files for the latter were, I had
reset the database. I do not have a backup of ‘org-persist-directory’ to
compare thus, or, for now, to reproduce the bug.

It appears that one thing that can trigger the error is Org mode parser
errors. For example, while trying to poke around ‘org-open-at-point’ a
bit, I noticed that eval’ing the call to ‘org-element-lineage’ in its
definition

(let* ((context
;; Only consider supported types, even if they are not the
;; closest one.
(org-element-lineage
 (org-element-context)
 '(citation citation-reference clock comment comment-block
footnote-definition footnote-reference headline
inline-src-block inlinetask keyword link node-property
planning src-block timestamp)
 t))

resulted in the following warning, which then implored me to send a bug
report:

⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
org.el.gz::333063. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
"  (backtrace-to-string nil)
  (org-element-at-point)
  (org-element-context)
  (org-element-lineage (org-element-context) '(citation citation-reference 
clock comment comment-block footnote-definition footnote-reference headline 
inline-src-block inlinetask keyword link node-property planning src-block 
timestamp) t)
  (progn (org-element-lineage (org-element-context) '(citation 
citation-reference clock comment comment-block footnote-definition 
footnote-reference headline inline-src-block inlinetask keyword link 
node-property planning src-block timestamp) t))
  (eval (progn (org-element-lineage (org-element-context) '(citation 
citation-reference clock comment comment-block footnote-definition 
footnote-reference headline inline-src-block inlinetask keyword link 
node-property planning src-block timestamp) t)) t)
  (elisp--eval-last-sexp nil)

after which the bug was triggered and I had become unable to use file
internal links in org mode.

In another instance an args out of range error in a ‘progn’ was
encountered while trying to store a link in a test buffer which only had
"\n\n\n<>" in it, which again triggered the bug.

I then tried to disable the cache which didn’t help, and to reset the
cache and then some other things, listed below, which didn’t either. But
after restarting Emacs (with the org element cache enabled), I was no
longer able to reproduce the bug.

  (setf org-element-use-cache t)
  M-x org-element-cache-reset
  (org-element-cache-reset t t)
  (org-element-cache-refresh (point))
  (setq-local org-element--cache nil)
  (setq-local org-element--headline-cache nil)
  (setq-local org-element--cache-hash-left nil
  org-element--cache-hash-right nil)

It is after this point that I debugged further and discovered
org-persist and its role. Sadly the default location of
‘org-persist-directory’ is not a location I include in my backups, so I
cannot reproduce the bug unless I accidentally recreate whatever
triggered it.

All this debugging occurred in the org mode package as it comes with
upstream emacs, built by me from commit
6c4abbab7999f55792a323e4bb1eb55ef5a7b990. In case it is helpful, below
are links to my org mode config and Emacs build script

https://codeberg.org/cadadr/personal-computing/src/commit/748803bb63d756e0a2ec75b00c34dfbd1f40cf0f/emacs.d/gk/gk-org.el
https://codeberg.org/cadadr/personal-computing/src/commit/748803bb63d756e0a2ec75b00c34dfbd1f40cf0f/emacs.d/bin/build-emacs.sh

‘org-version’ reports

Org mode version 9.6.1 (release_9.6.1-34-geea8da @ 
/home/cadadr/local/emacs/share/emacs/30.0.50/lisp/org/)

The org-persist storage verion currently seems to be 3.1 (exceprt from
=/home/cadadr/.cache/org-persist/index= below). I don’t know what it was
beforehand, but I usually build Emacs from git tip every Sunday, so that
might give a tip

 (:container
  ((index "3.1"))

Sadly I cannot do any further debugging, as I can’t reproduce the bug
anymore.

- Göktuğ.

P.S. Please keep me in CC if you want me to see your replies, I am not
subscribed to the list.

Re: [FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)

[Timothy]

Hi Ihor,

> This sounds like a reasonable request.
> What we may do here is allowing a new parameter :verbatim

>From a read of the original email, it sounds like a `:dir' parameter could also
solve this use case, and allow for a bit more flexibility.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir

[Max Nikulin]

On 26/02/2023 08:52, gnu...@pm.me wrote:

(basically similar to what #include
directive in C preprocessor would do, e.g.). As of now, the above
s.org exports to s.html which has the file: link converted to

file:///home/user/media/s/media/s01_image.png


Doesn't cpp behave in a similar way?

grep --include=*.h -r '' h-0.h include-1/
h-0.h:
h-0.h:#include "include-1/h-1.h"
h-0.h:
h-0.h:extern int h0;
include-1/h-1.h:
include-1/h-1.h:#include "include-2/h-2.h"
include-1/h-1.h:
include-1/h-1.h:extern int h1;
include-1/include-2/h-2.h:
include-1/include-2/h-2.h:extern int h2;

cpp -nostdinc h-0.h
# 1 "h-0.h"
# 1 ""
# 1 ""
# 1 "h-0.h"

# 1 "include-1/h-1.h" 1

# 1 "include-1/include-2/h-2.h" 1

extern int h2;
# 3 "include-1/h-1.h" 2

extern int h1;
# 3 "h-0.h" 2

extern int h0;


So in a file residing in ./include-1/ reference to "include-2/h-2.h" 
means ./include-1/include-2/h-2.h, not ./include-2/h-2.h

Re: [BUG] HTML-export citation suffix rendering with CSL [9.6 (9.6-??-bed47b437 @ /home/romeo/.emacs.d/.local/straight/build-28.2.50/org/)]

[András Simonyi]

Dear All,

On Wed, 25 Jan 2023 at 12:53, Ihor Radchenko  wrote:
> Confirmed, after replacing the .bib key with 
> abnarQuantifyingAttentionFlow2020a.
>
> András, may you take a look?

First of all, apologies for reacting that late, unfortunately, I've
had way less time to work on Org-mode and citeproc related problems
than I'd have wished or expected. I've managed to look into the issue
now and merged two PRs (#137 and #138) into citeproc-el's main branch
which should fix Problem 1.

As for the second problem, this is more difficult, because in this
case the behavior is along the expected lines:
the org-cite suffix ", Thm. 1" is further parsed by oc-csl into the
prefix ", Thm. " and the locator "1", with the implicit label "page".
If the used CSL style doesn't use a rendered label for pages (like
Chicago author-date) than an (admittedly ugly) workaround is to use an
explicit "page" label, that is,
[cite:@abnarQuantifyingAttentionFlow2020a page Thm. 1] is rendered as
(Abdar et al. 2021, Thm. 1) in Chicago.

We might want to change parsing to automatically parse everything as
CSL suffix if the org-cite suffix starts with a comma, but before
considering that I'd like to raise issue of treating Theorem/Thm. and
similar terms (Lemma etc.) as valid CSL locator labels in their own
right, which would be, I think, a more principled solution. I don't
know whether this was considered by CSL developers (CC-ing Bruce and
Denis).

best wishes,
András

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

Re: ox-rst still working?

[Angel de Vicente]

Hello,

just realized that it is ok if I open the file ox-rst.el and evaluate
the hole buffer.

I do have

(require 'ox-rst)

in my .emacs file and I have evaluated that a number of times, but for
some reason the rst backend is only registered with the Org dispatch
when evaluating the ox-rst.el buffer itself.

Any idea why this could be?
Thanks,
-- 
Ángel de Vicente
 Research Software Engineer (Supercomputing and BigData)
 Tel.: +34 922-605-747
 Web.: http://research.iac.es/proyecto/polmag/

 GPG: 0x8BDC390B69033F52


smime.p7s
Description: S/MIME cryptographic signature

Re: [DISCUSS] "same text-property competing" problem in external packages

[Ihor Radchenko]

stardiviner  writes:

> I got a problem when more than one Emacs package competing on setting
> text-property on same target from different packages.
>
> Here is the original problem and discussion link:
> https://github.com/nobiot/org-transclusion/issues/166
>
> Does anybody have a good idea to solve this problem?

I am not sure which property you are referring to.

There is a number of possible solutions you may use depending on what is
more appropriate for your specific use case:

1. Use overlays with 'priority property. That way, you can "overlay" the
   property above/below existing and Emacs will automatically restore
   the existing value upon removing your overlay. This is the most
   common approach.

2. You can utilize `char-property-alias-alist' and actually store your
   property value in a different property. This will make the priority
   of the existing property _strictly higher_ than yours. org-fold-core
   uses this approach.

3. You can store a "backup" of the existing property and restore it when
   your minor mode is disabled. isearch.el uses this approach.

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

Re: [PATCH] lisp/ob-screen.el: Support ~:var~ header args for babel blocks

[Ihor Radchenko]

Ken Mankoff  writes:

>> I noticed that ob-core besides org-babel-default-header-args:LANG uses
>> org-babel-header-args:LANG. The latter is not defined in ob-screen,
>> however I am unsure concerning its effect (completion?).
>
> I don't understand this either.

It defines the expected values of header arguments.
Used in completion and by org-lint.

It is a good idea to define it, but mostly for completeness.
If the header args can be anything anyway, it will not affect anything
other than the code style.

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

Re: inconsistency with :eval yes in orgmode.org and gnu.org manuals for org 9.6, 9.5?

[Ihor Radchenko]

Ihor Radchenko  writes:

> Subject: [PATCH] org-manual: Clarify that :eval yes obeys
>  `org-confirm-babel-evaluate'
>
> * doc/org-manual.org (Limit code block evaluation): Clarify :eval yes
> value.

Applied, onto bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?h=bugfix=911d6a1027784ab081cb41b40c08826e62066c73

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

[FR] Allow to #+include files verbatim without any processing (was: Have export treat file: paths in INCLUDED file relative to the INCLUDING file's dir)

[Ihor Radchenko]

gnu...@pm.me writes:

> I have a file s.org in ./ (current directory), which includes
> another file s0.org living under ./media/s/:
>
> ./s.org:
>
> #+TITLE: s
> #+INCLUDE: "./media/s/s0.org"
>
> ./media/s/s0.org:
>
> * s0
> ** s01
>file:media/s01_image.png
>
> I want the org export to html to treat the file: paths in
> ./media/s/s0.org with respect to the directory of the ./s.org
> file. In other words, I want export NOT TO TOUCH the file: paths
> as written included files and effectively just paste the text of
> s0.org verbatim in s.org (basically similar to what #include
> directive in C preprocessor would do, e.g.). As of now, the above
> s.org exports to s.html which has the file: link converted to

This sounds like a reasonable request.
What we may do here is allowing a new parameter :verbatim

#+include: "/path/to/file" :verbatim t

This will disable footnote and link processing in
`org-export--prepare-file-contents'.

Though I am not sure if it is good enough to provide disable all/enable
all switch. Maybe even more fine-grained? - Just footnotes or just
links.

I am also not sure about other things
`org-export--prepare-file-contents' does, like indentation handling.

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

Re: [BUG] Emacs-29.0.60: (setopt org-babel-load-languages ...) may cause warnings

[Bastien Guerry]

Ihor Radchenko  writes:

>> 1. I have assigned my copyright for Emacs stuff to the FSF
>
> Bastien, may you please confirm?

I do, sorry for the delay.

-- 
 Bastien Guerry

Re: bug#61546: [PATCH] Fix some org functionality breaking upon changing `calendar-buffer'

[Bastien Guerry]

Ihor Radchenko  writes:

>> That is a bit of an issue.  Do org contributions and emacs contributions
>> count towards the same 15 LoC limit?  

Yes.  Copyright-wise, contributions to Org are contributions to Emacs.

>> If so, I have already exhausted mine, so TINYCHANGE won't work.
>
> AFAIK, we count separately. Org mode is a separate project, despite
> being distributed together with Emacs. At least, we usually only
> consider LOCs contributed to Org.
>
> Let me CC Bastien (the Org maintainer) to clarify.

Hopefully done, thanks!

-- 
 Bastien Guerry

Re: [PATCH] Avoid crash in `org-file-contents' in case of network failure

[Bastien Guerry]

Ihor Radchenko  writes:

> Damien Cassou  writes:
>
>> I've signed the FSF copyright agreement in the context of my
>> contributions to Emacs. Do I need to do any more paperwork?
>
> No, you don't.
> Bastien, could you please check FSF records?

I confirm Damien's FSF record is in order.

-- 
 Bastien Guerry