Re: BUG: (org-insert-subheading) fails when on true begin of line (first star) of heading

[Michael Dauer]

I understand that it's behavior is derived from org-insert-heading. But IMO
that does not make sense for this function, advice all that it is taking
the current indentation level as basis to devote the new heading as child
of the previous heading. It e.g. created a "orphan" grand child instead of
a child.

Not important for me, just strangely non-intuitive.

Ihor Radchenko  schrieb am Do., 11. Mai 2023, 12:11:

> Michael Dauer  writes:
>
> > Example
> > * h1
> > <>** h11
> >
> > brings:
> > * h1
> > *** <>
> > ** h11
>
> This is expected. `org-insert-subheading' inherits what
> `org-insert-heading' does:
>
> Insert a new heading or an item with the same depth at point.
>
> ***
> If point is at the beginning of a heading, insert a new heading
> or a new headline above the current one.  When at the beginning
> of a regular line of text, turn it into a heading.
> ***
>
> If point is in the middle of a line, split it and create a new
> headline with the text in the current line after point (see
> org-M-RET-may-split-line on how to modify this behavior).  As
> a special case, on a headline, splitting can only happen on the
> title itself.  E.g., this excludes breaking stars or tags.
>
> With a C-u prefix, set org-insert-heading-respect-content to
> a non-nil value for the duration of the command.  This forces the
> insertion of a heading after the current subtree, independently
> on the location of point.
>
> With a C-u C-u prefix, insert the heading at the end of the tree
> above the current heading.  For example, if point is within a
> 2nd-level heading, then it will insert a 2nd-level heading at
> the end of the 1st-level parent subtree.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Can `org-capture` templates be made to result in a sub-heading of the current heading?

[Ihor Radchenko]

Tim Visher  writes:

> Can `org-capture` templates be made to result in a sub-heading of the
> current heading?

Just use target `here' (as symbol).

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

Re: BUG: org-cycle does not unfold some subtrees

[Ihor Radchenko]

William Denton  writes:

>> What is the value of `isearch-mode-end-hook' in your Org buffers?
>
> (anzu--reset-mode-line org-fold-core--clear-isearch-overlays t)
> Local in buffer conforguration.org; global value is nil
>
> I checked in a few buffers, and it always says it's local in that buffer, 
> with 
> global value of nil, if that matters.

This looks right.

I am wondering how it could be that `isearch-mode-end-hook' does not get
called.

Have you experienced slowness of isearch? Did you abort it in any
special ways?

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

Re: [PATCH] org-babel-load-languages: load unbound scheme-mode

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> I think that I have seen Emacs complaining about unbound scheme-mode
> when playing with ob-scheme, but I cannot reproduce it.

Canceled.

Re: [ANN] lisp/ob-tangle-sync.el

[Ihor Radchenko]

Mehmet Tekman  writes:

>> It will be great if you could do it.
>> I have other things to work on.
>
> Of course! I'm just a little unfamiliar on how one coordinates active
> collaboration via mailing list :-)

Usually, we leave working on the patches to one person - whoever is the
most interested in the patch.

Maintainers and other interested users provide comments and suggestions.

> I've modified the `merge' function within `org-babel-merge-params' so
> that the main logic now accumulates a list of potential candidates that
> could be the :any keyword, and selects the last added candidate as the
> match.

I feel confused when reading the modified code.

> It all seems to be passing tests, though I would like to add my toy.org
> file to the org testing framework at some point.

I recommend trying various edge cases with your patch.
In particular:

1. Testing exclusive group inheritance when we inherit a header arg
   value that matches :any:

   #+PROPERTIES: header-args :tangle "foo.txt"
   #+begin_src ... :tangle no

   #+PROPERTIES: header-args :tangle no
   #+begin_src ... :tangle "foo.txt"

   #+PROPERTIES: header-args :tangle no
   * Heading
   :PROPERTIES:
   :header-args: :tangle "foo.txt"
   :END:
   #+begin_src ... :tangle yes

2. :tangle "file with spaces.txt"

I feel that the following code is not reliable when we inherit exact and
:any exclusive group members in alternations.

> +   (if (member new-param exclusive-group)
> ...
> +;; Cancel any potential matches if it's 
> caught
> +matched-param t
> +potential-any-param nil)
> +;; If not a direct match, flag it as a potential
> +;; :any match This can happen multiple times for
> +;; each new-param, but only once for each
> +;; exclusive-group.
> +(if (and (not matched-param)
> + (member ":any" exclusive-group))

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

[PATCH] doc/org-manual.org: Document `org-latex-src-block-backend'

[Ihor Radchenko]

Attaching tentative manual patch that explains about
`org-latex-src-block-backend'. There was no explanation about different
ways to export colored source blocks in the past.

Please try to read and let me know if anything is confusing.

>From fb77ae66d4d9c01a350140481bcb0f030a45fb69 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Fri, 12 May 2023 15:21:59 +0200
Subject: [PATCH] doc/org-manual.org: Document `org-latex-src-block-backend'

* doc/org-manual.org (Source blocks in LaTeX export): Explain possible
LaTeX export options for source blocks.
---
 doc/org-manual.org | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ba9fdaf20..4e56a1e00 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -14181,6 +14181,37 @@ *** Source blocks in LaTeX export
 #+cindex: source blocks, in @LaTeX{} export
 #+cindex: @samp{ATTR_LATEX}, keyword
 
+#+vindex: org-latex-src-block-backend
+LaTeX export backend provides multiple ways to render src blocks in
+LaTeX, according to the value of ~org-latex-src-block-backend~:
+
+- =verbatim= (default) ::
+
+  Use =verbatim= LaTeX environment with no language-specific
+  fontification.
+
+- =listings= ::
+
+  Use =listings= environment provided by the corresponding LaTeX
+  package.  Org will not add the =listings= package to LaTeX preamble,
+  users need to customize ~org-latex-packages-alist~ or LaTeX headers
+  manually.
+
+- =minted= ::
+
+  Use more syntax-aware =minted= package.  Note that in addition to
+  customizing the LaTeX preamble, [[https://pygments.org][pygments]]
+  program should be installed and ~org-latex-pdf-process~ should pass
+  =-shell-escape= option to LaTeX executable.
+
+- =engraved= ::
+
+  Use =fvextra= LaTeX package and Emacs package
+  [[https://elpa.gnu.org/packages/engrave-faces][engrave-faces]]
+  available on GNU Elpa.  =engrave-faces= will use Emacs fontification
+  to colorize the source blocks in LaTeX output.
+
+
 The LaTeX export backend can make source code blocks into floating
 objects through the attributes =:float= and =:options=.  For =:float=:
 
-- 
2.40.0


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

Re: org code and error catching

[Ihor Radchenko]

Michael Heerdegen  writes:

> I had a hard time to debug some problem with the expansion of some
> capture template because org catched the error even when I had set
> `debug-on-error'.  Would it be possible to make some functions,
> e.g. `org-eval' in my case (probably some more?), use
> `condition-case-unless-debug' instead of `condition-case'?

This is a good idea, except that `condition-case-unless-debug' has
non-obvious side effects that interfere with ERT (Org testing system).

If someone familiar with error handling in Elisp can help with this, it
would be welcome.

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

Re: CVE-2023-28617 (was Re: [PATCH] Fix ob-latex.el command injection vulnerability.)

[Ihor Radchenko]

Max Nikulin  writes:

>> But this patch literally fixed the problem. What else should we do?
>
> Do you really think that it was the last unsafe shell command in the Org 
> code?

No, but I prefer concrete examples. The CVE you linked to refers to
an already fixed bug.

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-ditaa.el#n101
> and (shell-command pdf-cmd) below

The only unsafe part there is `java' that is taken from :java header
argument. I am unsure how to fix this issue without feature regression.

> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-lilypond.el#n194

May you provide a patch?

>>> I suppose, the issue has been received too much attention already:
>>>
>>> - https://security-tracker.debian.org/tracker/CVE-2023-28617
>>> - https://ubuntu.com/security/notices/USN-6003-1
>>> - https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2023-28617
>> 
>> These appear to be different issues.
>
> Linux distributions had to react to the CVE with formally high score and 
> updated Emacs packages applying 2 tiny patches from this thread.

Sure, but I have applied both the patches onto bugfix. That's why I
asked you what else we should do.

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

Re: Can `org-capture` templates be made to result in a sub-heading of the current heading?

[Tim Visher]

On Fri, May 12, 2023 at 8:05 AM Ihor Radchenko  wrote:

> Tim Visher  writes:
> > Can `org-capture` templates be made to result in a sub-heading of the
> > current heading?
>
> Just use target `here' (as symbol).
>

Thanks for the suggestion, Ihor.

Do you have an example of this actually working? I'm on `Org mode version
9.6.5` which looks to be the latest available from GNU ELPA and there seems
to be a dispute between `org-capture-set-target-location` which understands

that the result of `(org-capture-get :target)` can return a symbol rather
than a list vs. `org-capture` itself which assumes

that target will _always_ be a list.

My testing code:

```
(timvisher--comment
 ;; Context
 (defmacro timvisher--comment
 (&rest _)
   nil)

 (defmacro wcb (buffer &rest body)
   `(with-current-buffer ,buffer
  ,@body))

 ;; Demo code
 (setq org-capture-templates
   '(("1" "1" entry here "* 1")
 ("2" "2" entry (here) "* 2")))

 ;; Fails with `Capture template ‘1’: Wrong type argument: listp, here`
 ;; because of `… (car (org-capture-get :target)) …`
 (wcb "todo.org"
  (org-capture nil "1"))

 ;; Fails with `Invalid capture target specification: (here)` because
 ;; `(pcase (or target (org-capture-get :target)) …)` doesn't have a case
 ;; for `(here)`
 (wcb "todo.org"
  (org-capture nil "2"))
 )
```

[RFC/PATCH] naming src/bin files in ob-C.el

[Leo Butler]

Hello,

I am using ob-C.el to work with a c++ library (capd::dynsys). The
current behaviour creates a temporary src and bin file in
`org-babel-temporary-directory'. There is currently no option to have
these files named and put somewhere else.

This behaviour is not quite right, in my opinion. I would like to be
able to compile an executable and then be able to call this same
executable without needing to recompile from source.

Attached is a patch that uses the :file header to allow the naming of
the source and compiled binary files.

A test is included, too. All tests pass with this patch applied to HEAD
(except the expected failures, of course).

Comments?

Leo

ps: It might be better to use a custom header for this purpose,
something like :bin-file. I am open to suggestions.

diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 3a6e99623..76842acb6 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -128,16 +128,21 @@ This function is called by `org-babel-execute-src-block'."
   "Expand a block of C code with org-babel according to its header arguments."
   (let ((org-babel-c-variant 'c)) (org-babel-C-expand-C body params)))
 
+(defun org-babel-C-src/bin-file (params src?)
+  "Return the src or bin file name."
+  (let* ((f (cdr (assq :file params)))
+ (file (or f (if src? "C-src-" "C-bin-")))
+ (ext (if src? (pcase org-babel-c-variant
+	 (`c ".c") (`cpp ".cpp") (`d ".d")) org-babel-exeext)))
+(org-babel-process-file-name
+ (if f (concat file ext)
+   (org-babel-temp-file file ext)
+
 (defun org-babel-C-execute (body params)
   "This function should only be called by `org-babel-execute:C'
 or `org-babel-execute:C++' or `org-babel-execute:D'."
-  (let* ((tmp-src-file (org-babel-temp-file
-			"C-src-"
-			(pcase org-babel-c-variant
-			  (`c ".c") (`cpp ".cpp") (`d ".d"
-	 (tmp-bin-file			;not used for D
-	  (org-babel-process-file-name
-	   (org-babel-temp-file "C-bin-" org-babel-exeext)))
+  (let* ((tmp-src-file (org-babel-C-src/bin-file params t))
+	 (tmp-bin-file (org-babel-C-src/bin-file params nil)) ;not used for D
 	 (cmdline (cdr (assq :cmdline params)))
 	 (cmdline (if cmdline (concat " " cmdline) ""))
 	 (flags (cdr (assq :flags params)))
diff --git a/testing/examples/ob-C-test.org b/testing/examples/ob-C-test.org
index c7a96f665..1a104ae6a 100644
--- a/testing/examples/ob-C-test.org
+++ b/testing/examples/ob-C-test.org
@@ -174,3 +174,13 @@ std::cout << "\"line 1\"\n";
 std::cout << "\"line 2\"\n";
 std::cout << "\"line 3\"\n";
 #+end_src
+
+* File naming
+:PROPERTIES:
+:ID:   1a691f36-f9c1-4531-8fc0-ee7b21ef5975
+:END:
+
+#+source: file_naming
+#+begin_src cpp :includes  :results output raw drawer :file ./hello-world
+std::cout << "Hello World!\n";
+#+end_src
diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index b6dbed8e3..3d16d1ae5 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -192,5 +192,19 @@
"\"line 1\"\n\"line 2\"\n\"line 3\"\n"
(org-babel-execute-src-block))
 
+(ert-deftest ob-C/set-src+bin-file-name ()
+  "Set the name of the src and bin file names created by `org-babel-C-execute'."
+  (if (executable-find org-babel-C++-compiler)
+  (unwind-protect
+  (org-test-at-id "1a691f36-f9c1-4531-8fc0-ee7b21ef5975"
+(org-babel-next-src-block 1)
+(should (equal
+ "Hello World!\n"
+ (org-babel-execute-src-block)))
+(should (file-exists-p "./hello-world"))
+(should (file-exists-p "./hello-world.cpp")))
+(ignore-errors (delete-file "./hello-world"))
+(ignore-errors (delete-file "./hello-world.cpp")
+
 (provide 'test-ob-C)
 ;;; test-ob-C.el ends here

[PATCH] org-capture.el: Allow `(here)' as a template target

[Tim Visher]

Hi Everyone,

I think this should likely involve an update to the manual but I don't want
to bother doing that unless the basic approach is approved.

-

>From eccc3f8f805c38b1de55fc8ad60c67a87e2feea4 Mon Sep 17 00:00:00 2001
From: Tim Visher 
Date: Fri, 12 May 2023 11:32:21 -0400
Subject: [PATCH] org-capture.el: Allow `(here)' as a template target

* lisp/org-capture.el (org-capture-set-target-location): Allow `(here)' as
a template
target in addition to `here'.

Templates had no user accessible way to target the current location
directly from a capture template. Attempting to directly utilize the
behavior accessible through a 0 prefix arg exposed the inconsistent
treatment of the `:target` property in
`org-capture`. `org-capture-set-target-location` understood that it
could be both a symbol and a list, while `org-capture` itself required
it to be a list through its use of `car`.

This change opts to make `org-capture-set-target-location` more
liberal in what it accepts rather than making `org-capture` agree that
targets can be lists. This is because the manual implies, especially
in the `(clock)' entry, that targets are expected to be lists even if
they are meant as specific points.

TINYCHANGE
---
 lisp/org-capture.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index d4311dd20..f14e95c5c 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -991,7 +991,8 @@ Store them in the capture property list."
   (let ((target-entry-p t))
 (save-excursion
   (pcase (or target (org-capture-get :target))
- (`here
+ ((or `here
+ `(here))
  (org-capture-put :exact-position (point) :insert-here t))
  (`(file ,path)
  (set-buffer (org-capture-target-buffer path))
-- 
2.40.1


0001-org-capture.el-Allow-here-as-a-template-target.patch
Description: Binary data

Re: [RFC/PATCH] naming src/bin files in ob-C.el

[Leo Butler]

On Fri, May 12 2023, Leo Butler  wrote:

> Hello,
>
> I am using ob-C.el to work with a c++ library (capd::dynsys). The
> current behaviour creates a temporary src and bin file in
> `org-babel-temporary-directory'. There is currently no option to have
> these files named and put somewhere else.
>
> This behaviour is not quite right, in my opinion. I would like to be
> able to compile an executable and then be able to call this same
> executable without needing to recompile from source.
>
> Attached is a patch that uses the :file header to allow the naming of
> the source and compiled binary files.
>
> A test is included, too. All tests pass with this patch applied to HEAD
> (except the expected failures, of course).
>
> Comments?
>
> Leo
>
> ps: It might be better to use a custom header for this purpose,
> something like :bin-file. I am open to suggestions.

Replying to myself: it makes more sense to introduce a special-purpose
header argument for this special purpose, than to use :file with a
different meaning. Revised patch attached.

Leo

diff --git a/lisp/ob-C.el b/lisp/ob-C.el
index 3a6e99623..57633cc9f 100644
--- a/lisp/ob-C.el
+++ b/lisp/ob-C.el
@@ -53,7 +53,8 @@
 (main. :any)
 (flags   . :any)
 (cmdline . :any)
-(libs. :any))
+(libs. :any)
+(bin-file . :any))
   "C/C++-specific header arguments.")
 
 (defconst org-babel-header-args:C++
@@ -128,16 +129,21 @@ This function is called by `org-babel-execute-src-block'."
   "Expand a block of C code with org-babel according to its header arguments."
   (let ((org-babel-c-variant 'c)) (org-babel-C-expand-C body params)))
 
+(defun org-babel-C-src/bin-file (params src?)
+  "Return the src or bin file name."
+  (let* ((f (cdr (assq :bin-file params)))
+ (file (or f (if src? "C-src-" "C-bin-")))
+ (ext (if src? (pcase org-babel-c-variant
+	 (`c ".c") (`cpp ".cpp") (`d ".d")) org-babel-exeext)))
+(org-babel-process-file-name
+ (if f (concat file ext)
+   (org-babel-temp-file file ext)
+
 (defun org-babel-C-execute (body params)
   "This function should only be called by `org-babel-execute:C'
 or `org-babel-execute:C++' or `org-babel-execute:D'."
-  (let* ((tmp-src-file (org-babel-temp-file
-			"C-src-"
-			(pcase org-babel-c-variant
-			  (`c ".c") (`cpp ".cpp") (`d ".d"
-	 (tmp-bin-file			;not used for D
-	  (org-babel-process-file-name
-	   (org-babel-temp-file "C-bin-" org-babel-exeext)))
+  (let* ((tmp-src-file (org-babel-C-src/bin-file params t))
+	 (tmp-bin-file (org-babel-C-src/bin-file params nil)) ;not used for D
 	 (cmdline (cdr (assq :cmdline params)))
 	 (cmdline (if cmdline (concat " " cmdline) ""))
 	 (flags (cdr (assq :flags params)))
diff --git a/testing/examples/ob-C-test.org b/testing/examples/ob-C-test.org
index c7a96f665..57fa42cec 100644
--- a/testing/examples/ob-C-test.org
+++ b/testing/examples/ob-C-test.org
@@ -174,3 +174,13 @@ std::cout << "\"line 1\"\n";
 std::cout << "\"line 2\"\n";
 std::cout << "\"line 3\"\n";
 #+end_src
+
+* File naming
+:PROPERTIES:
+:ID:   1a691f36-f9c1-4531-8fc0-ee7b21ef5975
+:END:
+
+#+source: file_naming
+#+begin_src cpp :includes  :results output raw drawer :bin-file ./hello-world
+std::cout << "Hello World!\n";
+#+end_src
diff --git a/testing/lisp/test-ob-C.el b/testing/lisp/test-ob-C.el
index b6dbed8e3..3d16d1ae5 100644
--- a/testing/lisp/test-ob-C.el
+++ b/testing/lisp/test-ob-C.el
@@ -192,5 +192,19 @@
"\"line 1\"\n\"line 2\"\n\"line 3\"\n"
(org-babel-execute-src-block))
 
+(ert-deftest ob-C/set-src+bin-file-name ()
+  "Set the name of the src and bin file names created by `org-babel-C-execute'."
+  (if (executable-find org-babel-C++-compiler)
+  (unwind-protect
+  (org-test-at-id "1a691f36-f9c1-4531-8fc0-ee7b21ef5975"
+(org-babel-next-src-block 1)
+(should (equal
+ "Hello World!\n"
+ (org-babel-execute-src-block)))
+(should (file-exists-p "./hello-world"))
+(should (file-exists-p "./hello-world.cpp")))
+(ignore-errors (delete-file "./hello-world"))
+(ignore-errors (delete-file "./hello-world.cpp")
+
 (provide 'test-ob-C)
 ;;; test-ob-C.el ends here

Re: [PATCH] org-capture.el: Allow `(here)' as a template target

[Ihor Radchenko]

Tim Visher  writes:

> I think this should likely involve an update to the manual but I don't want
> to bother doing that unless the basic approach is approved.

LGTM.
We might also fix on the other side, not demanding (`car-safe') the target to 
be a list.

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

Re: [RFC/PATCH] naming src/bin files in ob-C.el

[Ihor Radchenko]

Leo Butler  writes:

>> Comments?
> ...
> Replying to myself: it makes more sense to introduce a special-purpose
> header argument for this special purpose, than to use :file with a
> different meaning. Revised patch attached.

IMHO, it will be more consistent with other backends to use :results file :file 
/path/to/executable

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

Re: [RFC/PATCH] naming src/bin files in ob-C.el

[Leo Butler]

On Fri, May 12 2023, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>>> Comments?
>> ...
>> Replying to myself: it makes more sense to introduce a special-purpose
>> header argument for this special purpose, than to use :file with a
>> different meaning. Revised patch attached.
>
> IMHO, it will be more consistent with other backends to use :results file 
> :file /path/to/executable

No, I don't think this is the way to do it. What happens in this
case is:

1. `org-babel-C-execute' creates a named source file, compiles it to the
   named binary file;
2. then executes that binary file, producing output;
3. that output is inserted into the named binary file, overwriting its
   contents.

I don't see how to accomplish my stated goal of saving the binary file
to a named location without introducing a separate header argument
(e.g. ":bin-file").

Leo

[FR] relative buffer-local path to bib for org-cite biblatex

[Panayotis Manganaris]

Hello, I just noticed that adding a local bibliography for use by the 
biblatex cite processor gets exported to latex as an absolute path.


`#+bibliography: main.bib`  exports to 
`\addbibresource{/home/me/etc/main.bib}`


I would like a setting to allow this to be a relative path if possible.

I usually generate a local bibliography when creating a manuscript 
repository intended to share. I'd rather have the local bib be defined 
relative to the main file in that case.


looking at `oc.el` I see no way to make this setting. but I image it'd 
be popular.


```elisp

(defun org-cite-list-bibliography-files ()
  "List all bibliography files defined in the buffer."
  (delete-dups
   (append (mapcar (lambda (value)
     (pcase value
       (`(,f . ,d)
    (expand-file-name (org-strip-quotes f) d
       (pcase (org-collect-keywords
   '("BIBLIOGRAPHY") nil '("BIBLIOGRAPHY"))
     (`(("BIBLIOGRAPHY" . ,pairs)) pairs)))
       org-cite-global-bibliography)))
```

I'll have to learn elisp soon. Thanks for maintaining my favorite tools! 
Best,


Panos

Re: [FR] relative buffer-local path to bib for org-cite biblatex

[Ihor Radchenko]

Panayotis Manganaris  writes:

> Hello, I just noticed that adding a local bibliography for use by the 
> biblatex cite processor gets exported to latex as an absolute path.
>
> `#+bibliography: main.bib`  exports to 
> `\addbibresource{/home/me/etc/main.bib}`
>
> I would like a setting to allow this to be a relative path if possible.

In the next release, the relative path will remain relative and
absolute path will remain absolute.

See 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5ec364a1ae327312da6f69766a2bec79bc7691e8

Handled.

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

Re: BUG: org-cycle does not unfold some subtrees

[William Denton]

On 12 May 2023, Ihor Radchenko wrote:


What is the value of `isearch-mode-end-hook' in your Org buffers?


(anzu--reset-mode-line org-fold-core--clear-isearch-overlays t)
Local in buffer conforguration.org; global value is nil

I checked in a few buffers, and it always says it's local in that buffer, with
global value of nil, if that matters.


This looks right.

I am wondering how it could be that `isearch-mode-end-hook' does not get
called.

Have you experienced slowness of isearch? Did you abort it in any
special ways?


No and no, but now that I'm thinking about searching, I remember I use Swiper 
(and Ivy and Counsel).¹  C-s runs =swiper=, which is =isearch-forward= "with an overview," as it 
describes itself.


If we've narrowed it down to searching, could it be connected to that?  To the 
other people with this problem: do you use Swiper?


Bill

¹ https://github.com/abo-abo/swiper

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada
CO₂: 423.90 ppm (Mauna Loa Observatory, 2023-05-11)

Re: BUG: org-cycle does not unfold some subtrees

[Ihor Radchenko]

William Denton  writes:

> No and no, but now that I'm thinking about searching, I remember I use Swiper 
> (and Ivy and Counsel).¹  C-s runs =swiper=, which is =isearch-forward= "with 
> an overview," as it 
> describes itself.
>
> If we've narrowed it down to searching, could it be connected to that?  To 
> the 
> other people with this problem: do you use Swiper?

I am looking at
https://github.com/abo-abo/swiper/blob/master/swiper.el#L980 and I note
that swiper calls `isearch-filter-predicate', but not
`isearch-mode-end-hook', which indeed explains why the isearch overlays
are not converted back to proper Org folds.

Does it help if you try the following variant of 
`org-fold-core--isearch-filter-predicate-overlays':

(defun org-fold-core--isearch-filter-predicate-overlays (beg end)
  "Return non-nil if text between BEG and END is deemed visible by isearch.
This function is intended to be used as `isearch-filter-predicate'."
  (when isearch-mode (org-fold-core--create-isearch-overlays beg end)) ;; trick 
isearch by creating overlays in place of invisible text
  (isearch-filter-visible beg end))

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

Re: BUG: org-cycle does not unfold some subtrees

[Thomas Dye]

Apologies. This message sent from my phone. Yes, I use swiper. My folding 
problems went away when I set org-fold-core-style to ‘overlay. Limited testing. 

Tom

> On May 13, 2023, at 6:14 AM, Ihor Radchenko  wrote:
> 
> William Denton  writes:
> 
>> No and no, but now that I'm thinking about searching, I remember I use 
>> Swiper 
>> (and Ivy and Counsel).¹  C-s runs =swiper=, which is =isearch-forward= "with 
>> an overview," as it 
>> describes itself.
>> 
>> If we've narrowed it down to searching, could it be connected to that?  To 
>> the 
>> other people with this problem: do you use Swiper?
> 
> I am looking at
> https://github.com/abo-abo/swiper/blob/master/swiper.el#L980 and I note
> that swiper calls `isearch-filter-predicate', but not
> `isearch-mode-end-hook', which indeed explains why the isearch overlays
> are not converted back to proper Org folds.
> 
> Does it help if you try the following variant of 
> `org-fold-core--isearch-filter-predicate-overlays':
> 
> (defun org-fold-core--isearch-filter-predicate-overlays (beg end)
>  "Return non-nil if text between BEG and END is deemed visible by isearch.
> This function is intended to be used as `isearch-filter-predicate'."
>  (when isearch-mode (org-fold-core--create-isearch-overlays beg end)) ;; 
> trick isearch by creating overlays in place of invisible text
>  (isearch-filter-visible beg end))
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
> 

Improve the performance of `org-set-tags-command` on large `org-tag-alist`

[stardiviner]

I have a large `org-tag-alist` value that contains about ~7000 tags.
When I press [C-c C-q] `org-set-tags-command`. Emacs suspends a long time.

Here are the profiler reports in the attachments.

I hope this can be improved the performance.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


cpu.profiler
Description: Binary data


memory.profiler
Description: Binary data