bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

[Lars Ingebrigtsen]

Ihor Radchenko  writes:

> The code above always skips a bibtex entry starting at bob.
> Hence, the provided example bibliography is parsed as empty, which is
> not expected by Org.

This should now be fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

[Ihor Radchenko]

Eli Zaretskii  writes:

>> From: Kaushal Modi 
>> Date: Mon, 9 May 2022 17:41:32 -0400
>> 
>> Exporting an Org file with citations on Emacs 29 now throws the error
>> "Wrong value for ENTRY-OR-KEY: nil". This error can be reproduced with
>> the Org version shipped with Emacs on the master branch.
>
> Shouldn't this be reported to Org developers first?

It has been.
However, part of the problem lies in the bibtex-map-entries:

  ;; If we have invalid entries, ensure that we have forward
  ;; progress so that we don't infloop.
  (if (= (point) prev)
  (forward-line 1)

The code above always skips a bibtex entry starting at bob.
Hence, the provided example bibliography is parsed as empty, which is
not expected by Org.

While handling empty bibfiles should be fixed on Org side, the current
behaviour of bibtex-map-entries should indeed be fixed on Emacs side.

Best,
Ihor

bug#55342: 29.0.50; org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

[Eli Zaretskii]

> From: Kaushal Modi 
> Date: Mon, 9 May 2022 17:41:32 -0400
> 
> Exporting an Org file with citations on Emacs 29 now throws the error
> "Wrong value for ENTRY-OR-KEY: nil". This error can be reproduced with
> the Org version shipped with Emacs on the master branch.

Shouldn't this be reported to Org developers first?

Thanks.

Re: [PATCH] New LaTeX code export option: engraved

[Timothy]

Hi Sebastien,

> I’m quite exited and impressed to see this alternative to minted,
> thank you.

That’s great to hear!

> I haven’t been able to test your patches to org, but I have tried
> engrave-faces.el. Here’s a couple issues I’ve run into.

Still helpful, thanks.

>  1. engrave-faces-generate-preset generates emacs colors such as
>     `:foreground “grey70”` which are not supported by
>     engrave-faces-latex-gen-preamble-line and co.

Ah. I’ve just found this snippet from `list-colors-print'
┌
│ (apply 'format "#%02x%02x%02x"
│(mapcar (lambda (c) (ash c -8))
│(color-values (car color
└

I’ll see if I can incorporate this into engrave-faces v0.3.1.

>  2. `minted` supports a `mathescape` option to render math content
>     inside code. `fvextra` supports the same option, but maths
>     characters are escaped by engrave-faces-latex-face-mapper.

I’l also take a look at this :)

Thanks for the comments Sebastien.

All the best,
Timothy

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

[Pride Allman]

Hello,

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

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.

So my theory was there is a discrepancy between the method used by
~org-latex-export-to-latex~ and the ~org-table-export~. And on browsing the
codes for those two I found this.

The code for ~org-latex-table-row~ used by latex export backend has this
line:

#+begin_src emacs-lisp :tangle yes
(booktabsp (if (plist-member attr :booktabs) (plist-get attr :booktabs)
 (plist-get info :latex-tables-booktabs)))
#+end_src

Shows that it also takes into account the ~info~ plist.


I couldn't find out what that info plist has, but I can assume it's the
information on the overall buffer or that table's context, and it has the
effect of using the booktabs from the config.

While the code for ~orgtbl-to-latex~ shows it only takes into account the
~booktabs~ parameter on latex table.

#+begin_src emacs-lisp :tangle yes
 :latex-tables-booktabs (plist-get params :booktabs)
#+end_src

So I tried changing the line in ~orgtbl-to-latex~ to

#+begin_src emacs-lisp :tangle yes
 :latex-tables-booktabs (if (plist-member params :booktabs) (plist-get
params :booktabs)
 org-latex-tables-booktabs)
#+end_src

So if there is ~booktabs~ parameter then it'll overwrite the settings but
if not it'll use the booktabs config.

There is probably a better way to use it, but this works for now so I tried
this.

Please find the attached patch with the fix.

Regards,
Gaurav
From 264fb8b7f2c5782c92c5beffe54ac18c97b4b685 Mon Sep 17 00:00:00 2001
From: Gaurav 
Date: Mon, 9 May 2022 18:05:52 -0400
Subject: [PATCH] lisp/org-table.el: Use booktabs on org-table-export

* lisp/org-table.el (orgtbl-to-latex): Read booktabs flag from
`org-latex-tables-booktabs' if `:booktabs' is not present in
table `params'.

Problem was 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 point, if you export the
whole buffer the table will be exported according to booktabs.  I
looked at the discrepancy between the method used by
~org-latex-export-to-latex~ and the ~org-table-export~ and did this to
fix it.

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

diff --git a/lisp/org-table.el b/lisp/org-table.el
index b160dc97c..46498f119 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -6000,7 +6000,9 @@ supported.  It is also possible to use the following ones:
 (list :backend 'latex
 	  :latex-default-table-mode 'table
 	  :latex-tables-centered nil
-	  :latex-tables-booktabs (plist-get params :booktabs)
+	  :latex-tables-booktabs (if (plist-member params :booktabs)
+ (plist-get params :booktabs)
+		  org-latex-tables-booktabs)
 	  :latex-table-scientific-notation nil
 	  :latex-default-table-environment
 	  (or (plist-get params :environment) "tabular"))
-- 
2.36.1

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]

[Kaushal Modi]

I have now sent this to Emacs bug tracking:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55342

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]

[Kaushal Modi]

On Mon, May 9, 2022 at 10:21 AM Kaushal Modi  wrote:
> Can someone using emacs
> built from master branch confirm that they see this same error when
> `org-cite-process-bibliography` is called? It should be reproducible
> without using ox-hugo too.


Alright I was able to confirm this possibly upstream bug on Emacs 29
after building it from source.

Here's a minimal test recipe:

=
#+title: "Wrong value for ENTRY-OR-KEY: nil" error on Emacs 29

#+bibliography: test.bib

#+begin_src bib :tangle test.bib
@article{Foo,
 author={Bar},
 journal={Zoo},
 title={Foo by Bar},
 year={2021}}
#+end_src

[cite:@Foo]

#+print_bibliography:

Evaluate the below code block.

#+begin_src emacs-lisp :results none
(org-babel-tangle)
(org-export-as 'ascii)
#+end_src
=

1. Open the above file in Emacs.
2. Run C-c C-c in that emacs-lisp code block

On Emacs 28: No error
On Emacs 29: org-cite-basic--get-field: Wrong value for ENTRY-OR-KEY: nil

Re: Concatenate properties

[Tyler Grinn]

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?

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?

Best,

Tyler

Re: [PATCH] New LaTeX code export option: engraved

[Sébastien Miquel]

Hi Timothy,

I'm quite exited and impressed to see this alternative to minted,
thank you.

I haven't been able to test your patches to org, but I have tried
engrave-faces.el. Here's a couple issues I've run into.

 1. engrave-faces-generate-preset generates emacs colors such as
    `:foreground "grey70"` which are not supported by
    engrave-faces-latex-gen-preamble-line and co.
 2. `minted` supports a `mathescape` option to render math content
    inside code. `fvextra` supports the same option, but maths
    characters are escaped by engrave-faces-latex-face-mapper.

Regards,

--
Sébastien Miquel

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

[Colin Baxter]

Hello Ihor,

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> Could more information perhaps be added to the doc string of
>> "org-agenda-clock-report-header"? And an example would be very
>> useful. As it stands at present, I haven't a clue as to what the
>> variable does and why it might be useful.

> It's literally a string inserted right before the table. There is
> nothing much to show there. See
> 
https://orgmode.org/list/CAJAdVc06_tj58Je=tn42jqfutkjamqbqdcvobqxeegars_m...@mail.gmail.com

> Is version in the attached patch more clear?

> Best, Ihor

> From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00
> 2001 Message-Id:
> 
<9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com>
> From: Ihor Radchenko  Date: Mon, 9 May 2022
> 20:34:38 +0800 Subject: [PATCH] org-agenda-clock-report-header:
> Update docstring

> See https://orgmode.org/list/87o808j6si@yandex.com ---
> lisp/org-agenda.el | 6 +++--- 1 file changed, 3 insertions(+), 3
> deletions(-)

> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index
> 0479a0e1f..9d38b889d 100644 --- a/lisp/org-agenda.el +++
> b/lisp/org-agenda.el @@ -1221,11 +1221,11 @@ (defcustom
> org-agenda-timegrid-use-ampm nil :type 'boolean)
 
>  (defcustom org-agenda-clock-report-header nil - "Header for org
> agenda clock report mode" + "Header inserted before the table in
> Org agenda clock report mode."  :group 'org-agenda :type '(choice
> - (string :tag "Header") - (const :tag "No header" nil)) + (string
> :tag "Header") + (const :tag "No header" nil)) :safe #'stringp
> :package-version '(Org . "9.6"))
 
> -- 2.35.1

Thank you for your reply and patch.

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?
 
Best wishes,

Colin Baxter.

[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/)]

[Marcin Borkowski]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


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:

(let* ((spec (nth (current-column) org-columns-current-fmt-compiled))
...) ...)

Since `org-columns-current-fmt-compiled' seems to contain one entry per
_table_ column and `current-column' returns the "horizontal position of
point" (i.e., the index of the _character_ column the point is in),
`spec' gets assigned nil unless the point happens to be no more
characters from the left margin than there are columns in the column
view, and even then it gets assigned the wrong thing.

I might be mistaken, though - I only skimmed through this code.

Here is an example file where this happens:

--8<---cut here---start->8---

* Test
** Entry A
:PROPERTIES:
:a:1
:b:2
:END:
** Entry B
:PROPERTIES:
:a:3
:b:4
:END:
* Config
#+COLUMNS: %4a %4b
--8<---cut here---end--->8---

Go to `* Test', press `C-c C-x C-c', then go to `2' and press `e 2 '.

I also saw this on emacs -Q, with the built-in Org-mode:
Org mode version 9.5.2 (release_9.5.2-22-g33543d @ 
/usr/local/share/emacs/29.0.50/lisp/org/)



Emacs  : GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, 
cairo version 1.17.4)
 of 2022-03-06
Package: Org mode version 9.5.3 (release_9.5.3-452-g407104 @ 
/home/mbork/others-works/emacs/org-mode/lisp/)

-- 
Marcin Borkowski
http://mbork.pl

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

[Justin Silverman]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See



Your bug report will be posted to the Org mailing list.


I am getting an error


org-screenshot-generate-file-name: Symbol’s function definition is void: incf

I am guessing this is a simple matter of requiring cl-lib or prefixing cl-* to 
the incf symbol in the code.

Justin

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

current state:
`'
(setq
 org-msg-attached-file-reference "see[  \n]\\(?:the[\n]\\)?\\(?:\\w+[   
\n]\\)\\{0,3\\}\\(?:attached\\|enclosed\\)\\|(\\(?:attached\\|enclosed\\))\\|\\(?:attached\\|enclosed\\)[
   \n]\\(?:for\\|is\\)[\n]"
 org-link-elisp-confirm-function 'yes-or-no-p
 org-directory "~/Dropbox/org"
 org-after-refile-insert-hook '(org-gcal--refile-post)
 org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-agenda-custom-commands '(("d" "Custom Day View"
   ((agenda ""
 ((org-agenda-span 'day)
  (org-agenda-skip-function
   '(lambda nil (interactive) (skip-tag 
"mail")))
  )
 )
(todo "NEXT"
 ((org-agenda-sorting-strategy
   `(priority-down effort-down))
  (org-agenda-overriding-header "Next")
  (org-agenda-skip-function
   '(org-agenda-skip-entry-if 'timestamp))
  )
 )
(agenda ""
 ((org-agenda-span 'day)
  (org-agenda-overriding-header "Mail")
  (org-agenda-format-date "")
  (org-agenda-skip-function
   '(lambda nil (interactive) (skip-not-tag 
"mail")))
  )
 )
(tags-todo "REFILE"
 ((org-agenda-overriding-header "To Refile")
  (org-tags-match-list-sublevels nil))
 )
)
   )
  )
 org-agenda-skip-scheduled-if-done t
 org-agenda-files '("/home/jds6696/Dropbox/org/GTAM_hours.org"
"/home/jds6696/Dropbox/org/cal-gmail.org"
"/home/jds6696/Dropbox/org/cal-psu.org"
"/home/jds6696/Dropbox/org/calendar.org"
"/home/jds6696/Dropbox/org/inbox.org"
"/home/jds6696/Dropbox/org/inbox_mobile.org"
"/home/jds6696/Dropbox/org/mail.org"
"/home/jds6696/Dropbox/org/meetings_anarres.org"
"/home/jds6696/Dropbox/org/meetings_psu.org"
"/home/jds6696/Dropbox/org/notes.org"
"/home/jds6696/Dropbox/org/tasks.org")
 org-capture-templates '(("#" "used by gnus-icalendar-org" entry
  (file+olp "~/Dropbox/org/calendar.org" "Calendar") 
"%i"
  :immediate-finish t)
 ("t" "todo")
 ("ta" "todo with attachment" entry
  (file "~/Dropbox/org/inbox.org") "* TODO %?\n %U\n 
%a")
 ("te" "todo tweaks" entry
  (file+headline "~/Dropbox/org/tasks.org" "Emacs")
  "* TODO %? :TWEAKS:\n %U")
 ("tt" "plain todo" entry (file 
"~/Dropbox/org/inbox.org")
  "* TODO %?\n %U")
 ("m" "meetings")
 ("ma" "meeting anarres" entry
  (file "~/Dropbox/org/meetings_anarres.org")
  "* MEETING with %? :MEETING:\n %U" :jump-to-captured 
t)
 ("mp" "meeting psu" entry
  (file "~/Dropbox/org/meetings_psu.org")
  "* MEETING with %? :MEETING:\n %U" :jump-to-captured 
t)
 ("mP" "meeting specific person")
 ("mPm" "meeting Michelle" entry
  (file "~/Dropbox/org/meetings_psu.org")
  "* MEETING with Michelle :MEETING:w_michelle:\n  
%U\n** TRAM :p_tram:\n** Bacteremia 

Re: Bug in orgalist mode's advice on indent-according-to-mode

[Eric Abrahamsen]

Eric Abrahamsen  writes:

> Tim Cross  writes:
>
>> Eric Abrahamsen  writes:
>>
>>> In Emacs commit f596f0db82c0b1ff3fe8e8f1d8b07d2fe7504ab6, from Nov 2021,
>>> the function `indent-according-to-mode' was given an optional
>>> inhibit-widen argument. That argument being passed causes orgalist's
>>> advice to fail, as the lambda doesn't accept any additional arguments.
>>> One way to fix it would be like that:
>>>
>>>  (unless (advice-member-p 'orgalist-fix-bug:31361 'indent-according-to-mode)
>>>(advice-add 'indent-according-to-mode
>>>:around (lambda (old  inhibit-widen)
>>>  "Workaround bug#31361."
>>>  (or (orgalist--indent-line)
>>>  (let ((indent-line-function
>>> (advice--cd*r indent-line-function)))
>>>(funcall old inhibit-widen
>>>'((name . orgalist-fix-bug:31361)
>>>
>>> Or I suppose a more future-proof approach might be to use a  and
>>> then `apply' instead of `funcall'.
>>>
>>
>> A better solution would probably be to fix this without using
>> add-advice. While advice can be a useful escape hatch, it really is best
>> avoided, especially given that it doesn't always play nice with lexical
>> binding. I note this one is also calling an undocumented internal
>> function. 
>
> In principle I quite agree! But orgalist is basically built on top of
> add-function/advice-add, so I didn't think that was an option. And
> also assumed that, given what Orgalist is trying to do, there isn't a
> cleaner solution right now.

What do you think, Nicolas? Can I patch this to use  and `apply'?

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

[Kaushal Modi]

On Thu, Nov 25, 2021 at 6:21 AM juh  wrote:
> With cite_export: basic I get
>
> Wrong value for ENTRY-OR-KEY: nil

Hello,

I saw the ox-hugo CI fail with emacs master (29.0.50) over the past
few days with this backtrace, but this error is probably not related
to ox-hugo, and I need help confirming if that's the case.


=

  signal(error ("Wrong value for ENTRY-OR-KEY: nil"))
  error("Wrong value for ENTRY-OR-KEY: %S" nil)
  org-cite-basic--get-field(author nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block)) :options ((:with-toc nil "toc"
org-hugo-export-with-toc) (:section-numbers nil "num"
org-hugo-export-with-section-numbers) (:author "AUTHOR" nil
user-full-name newline) (:creator "CREATOR" nil
org-hugo-export-creator-string) (:with-smart-quotes nil "'" nil)
(:with-special-strings nil "-" nil) (:with-sub-superscript nil "^"
...) (:hugo-with-locale "HUGO_WITH_LOCALE" nil nil)
(:hugo-front-matter-format "HUGO_FRONT_MATTER_FORMAT" nil
org-hugo-front-matter-format) (:hugo-level-offset "HUGO_LEVEL_OFFSET"
nil "1") (:hugo-preserve-filling "HUGO_PRESERVE_FILLING" nil
org-hugo-preserve-filling) (:hugo-delete-trailing-ws
"HUGO_DELETE_TRAILING_WS" nil org-hugo-delete-trailing-ws)
(:hugo-section "HUGO_SECTION" nil org-hugo-section) (:hugo-bundle
"HUGO_BUNDLE" nil nil) (:hugo-base-dir "HUGO_BASE_DIR" nil
org-hugo-base-dir) (:hugo-goldmark "HUGO_GOLDMARK" nil
org-hugo-goldmark) (:hugo-code-fence "HUGO_CODE_FENCE" nil t)
(:hugo-use-code-for-kbd "HUGO_USE_CODE_FOR_KBD" nil
org-hugo-use-code-for-kbd) (:hugo-prefer-hyphen-in-tags
"HUGO_PREFER_HYPHEN_IN_TAGS" nil org-hugo-prefer-hyphen-in-tags)
(:hugo-allow-spaces-in-tags "HUGO_ALLOW_SPACES_IN_TAGS" nil
org-hugo-allow-spaces-in-tags) (:hugo-auto-set-lastmod
"HUGO_AUTO_SET_LASTMOD" nil org-hugo-auto-set-lastmod)
(:hugo-custom-front-matter "HUGO_CUSTOM_FRONT_MATTER" nil nil space)
(:hugo-blackfriday "HUGO_BLACKFRIDAY" nil nil space)
(:hugo-front-matter-key-replace "HUGO_FRONT_MATTER_KEY_REPLACE" nil
nil space) (:hugo-date-format "HUGO_DATE_FORMAT" nil
org-hugo-date-format) (:hugo-paired-shortcodes
"HUGO_PAIRED_SHORTCODES" nil org-hugo-paired-shortcodes space)
(:hugo-pandoc-citations "HUGO_PANDOC_CITATIONS" nil nil)
(:bibliography "BIBLIOGRAPHY" nil nil newline) (:html-container
"HTML_CONTAINER" nil org-hugo-container-element)
(:html-container-class "HTML_CONTAINER_CLASS" nil "") (:hugo-aliases
"HUGO_ALIASES" nil nil space) (:hugo-audio "HUGO_AUDIO" nil nil) ...)
:filters ((:filter-body . org-hugo-body-filter)) :blocks nil :menu (72
"Export to Hugo-compatible Markdo..." (... ... ... ... ... ...)))
:translate-alist ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . org-hugo-export-block)
(export-snippet . org-hugo-export-snippet) (headline .
org-hugo-heading) (inner-template . org-hugo-inner-template)
(inline-src-block . org-hugo-inline-src-block) (keyword .
org-hugo-keyword) (link . org-hugo-link) (paragraph .
org-hugo-paragraph) (src-block . org-hugo-src-block) (special-block .
org-hugo-special-block) (center-block . org-blackfriday-center-block)
(example-block . org-blackfriday-example-block) (fixed-width .
org-blackfriday-fixed-width) (footnote-reference .
org-blackfriday-footnote-reference) (inner-template .
org-blackfriday-inner-template) (italic . org-blackfriday-italic)
(item . org-blackfriday-item) (latex-environment .
org-blackfriday-latex-environment) (latex-fragment .
org-blackfriday-latex-fragment) (line-break . org-html-line-break)
(plain-list . org-blackfriday-plain-list) (plain-text .
org-blackfriday-plain-text) (quote-block .
org-blackfriday-quote-block) (radio-target .
org-blackfriday-radio-target) (special-block .
org-blackfriday-special-block) (src-block . org-blackfriday-src-block)
(strike-through . org-blackfriday-strike-through) (table-cell .
org-blackfriday-table-cell) (table-row . org-blackfriday-table-row)
(table . org-blackfriday-table) ...) :exported-data # :input-buffer "*Ox-hugo Pre-processed all-posts..."
:input-file "/home/runner/work/ox-hugo/ox-hug..." :with-toc nil
:section-numbers nil :author "" :creator "Emacs + Org mode + ox-hugo"
:with-smart-quotes nil :with-special-strings nil :with-sub-superscript
{} :hugo-with-locale nil :hugo-front-matter-format "toml"
:hugo-level-offset "1" ...))
  org-cite-basic--print-entry(nil nil (:export-options (subtree)
:back-end #s(org-export-backend :name hugo :parent blackfriday
:transcoders ((code . org-hugo-kbd-tags-maybe) (example-block .
org-hugo-example-block) (export-block . 

Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Eric S Fraga]

On Monday,  9 May 2022 at 14:01, Juan Manuel Macías wrote:
> Although ---as Eric says--- we can always use special blocks, a :wrap
> attribute would drastically lighten the readability of the document,

One advantage of special blocks is that they work across all
(some/most/?) export backends and are not tied to LaTeX.

-- 
: Eric S Fraga, with org release_9.5.3-478-g2a6f5c in Emacs 29.0.50

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

[Timothy]

Hi Ihor,

> Before merging, could you also try to implement tests at least for
> engraved feature? If I recall correctly, we do not currently have
> backend-specific tests. But it would certainly help if we did. You might
> as well write a small “nucleus” test for ox-latex.

Probably not a bad idea, I’m just not sure what/how I’d go about this.

> Also, unless I miss something, there is no support for coderefs in the
> patchset. Is it intentional?

I think you’ve missed something. It has the same coderefs support as minted.

> It appears that the code for caption-str is duplicated.  It could be
> also factored out.

It could, but I’m not sure this is actually a good idea as the duplication is
more the result of chance than a common dependency.

>> +  (format-spec custom-env
>> +   `((?s . ,formatted-src)
>> + (?c . ,caption)
>> + (?f . ,float)
>> + (?l . ,(org-latex–label src-block info))
>> + (?o . ,(or (plist-get attributes :options) “”)))
>
> I do not see a definition of `format-spec’ function. There is only
> `spec’ above in the code. Can you double check? Either I am missing
> something or something fishy is going on.

This code isn’t introduced by my patches, just relocated. FWIW `format-spec' is
provided by Emacs, and I don’t think is new.

>> +  (let ((code (org-element-property :value inline-src-block))
>> +(lang (org-element-property :language inline-src-block)))
>> +(pcase (plist-get info :latex-listings)
>> +  (’nil (org-latex–text-markup code ’code info))
>> +  (’minted (org-latex-inline-src-block–minted info code lang))
>> +  (_ (org-latex-inline-src-block–listings info code lang)
>
> Please use `nil and `minted.  Using ’ may create issues in older Emacs.

Done.

>> +% In case engrave-faces-latex-gen-preamble has not been run.
>> +\
>> +\
>
> What is the difference between EfD and EFD? EfD is also not documented.

Documentation added. EfD is the background colour.

>> +FVEXTRA-SETUP sets fvextra’s defaults according to
>> +`org-latex-engraved-options’, and LISTINGS-SETUP creates the
>> +listings environment and defines \.“
>
> It is unclear what listings environment does given that we use engraved
> package. Can you provide a bit more details in the docstring on what the
> user will get if [LISTINGS-SETUP] is present.
> It may catch users by surprise that deleting this will make captions
> disappear.

It does the same thing as minted’s `listings' environment, hence the choice of
name. Documentation added.

> Why not just
> (org-element-map (plist-get info :parse-tree)
> ’(src-block inline-src-block example-block 
> fixed-width) #’identity
> info t)

Ah, in my config I’m also using some engraved info for example/fixed-width
blocks. I’ll leave this out for now.

>>  (pcase (plist-get info :latex-listings)
>>(’nil (org-latex–text-markup code ’code info))
>>…
> Same comment about ` in pcase.

Done.

> What will happen if there is no [LISTINGS-SETUP]?

Captioned/Floating code blocks won’t work.

>> +(defcustom org-latex-engraved-theme nil
> Docstring does not explain what happens when set to nil.
> Also, does :type ’symbol allow t and nil?

I think so, `symbolp' says they’re symbols if nothing else.

> Will it work when engraved-theme is t?

Yes.

> What about example-block and fixed-width? I may be missing something,
> but earlier in the patchset you had conditionals of the type
> (or src-p fixedw-p). So, does engrave-faces do anything with fixedw-type
> elements?

Resolved earlier.

>> + (gen-theme-spec
>> +  (lambda (theme) …
>
> This appears to be not guarded by (require ’engrave-faces-latex nil t).

It is before it’s actually called.

>> -(defun org-latex-src–engrave-code (content lang)
>> -  “Engrave CONTENT to LaTeX in a LANG-mode buffer, and give the result.”
>> +(defun org-latex-src–engrave-code (content lang  theme options 
>> inline)
>> +  “Engrave CONTENT to LaTeX in a LANG-mode buffer, and give the result.
>> +When THEME is non-nil, it will be used.”
>
> You did not document the remaining two arguments. (this makes me ask a
> question whether you checked compile warnings). Also, consider running
> M-x checkdoc on ox-latex.el.

Now documented.

I have checked compile warnings (there are none), but checkdoc is currently a
bit dodgy on the Emacs commit I’m on.

>> -(insert content)
>> +(insert (string-trim-right content “”))
>
> As a theoretical possibility, what will happen if content has something
> like “%”?

Discussed in DMs. It just gets rid of trailing newlines, and it’s fine with
escaping.

All the best,
Timothy

Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Juan Manuel Macías]

Ihor Radchenko writes:

> I'd be happy to see a built-in solution for this.
> I feel that the ability to insert arbitrary LaTeX code near the
> begin/end of environment would be generally a useful feature to have in
> ox-latex. It could be done via #+attr_latex: :pre/:post
>
> Moreover, it would be useful to be able to wrap the whole chunk into
> custom environment:
> #+attr_latex: :wrap [options]environmant
>
> WDYT?

I think they are both great ideas, especially the second one. Although
---as Eric says--- we can always use special blocks, a :wrap attribute
would drastically lighten the readability of the document, and could be
very useful in those complex constructions where we need to enclose a
table or a figure in another environment (for example, with the
threeparttable package and others like it).

Best regards,

Juan Manuel 

Re: [BUG] orgtbl-toggle-comment hangs if table is in first line [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

matteo  writes:

> If in an org buffer there is a table, commented or not, starting from
> the first line of the buffer, the command orgtbl-toggle-comment hangs
> and must be terminated with C-g.

Thanks for reporting!
Fixed on main via 0b07b30de.

Best,
Ihor

Re: how to best correct exams (code matlab) using org mode (and tables)

[John Kitchin]

I guess the best thing to do would be some combination of
`htmlize-buffer' and adding tooltips to the markups.

I don't see a super clear path to that at the moment. The htmlize-buffer
is straightforward, and it would show where your remarks are. Getting
from marginalia.org to tooltips in the right place though is not as
straightforward.

htmlize-buffer is only necessary if you want to see the syntax in the
buffer. Here is some rough code that wraps the file in  and
makes the text you added remarks on have tooltips associated with your
remarks. You could then return the feedback.html file.


#+BEGIN_SRC emacs-lisp
(let* ((hls (sort (org-remark-highlights-get) (lambda (a b) (> (caadr a) (caadr 
b)
   (notes (cl-loop for (key (start . end) type) in hls
   collect
   (progn
 (with-current-buffer 
(org-remark-notes-buffer-get-or-create)
   (goto-char
(org-find-property org-remark-prop-id key))
   (save-restriction
 (org-narrow-to-subtree)
 (org-end-of-meta-data t)
 (buffer-substring (point) (point-max

  (with-temp-file "feedback.html"
(insert-file-contents "some-file")

(cl-loop for (key (start . end) type) in hls for note in notes
 do
 
 (cl--set-buffer-substring start end
   (format "%s"
   note
   (buffer-substring start end   
(goto-char (point-min))
(insert "")
(goto-char (point-max))
(insert ""))
  
  (browse-url "feedback.html"))
#+END_SRC

Uwe Brauer  writes:

> Hi 
>
> I came around 
> https://kitchingroup.cheme.cmu.edu/blog/2013/10/23/Writing-exams-in-org-mode/
>
> Which is a bit outdated.
>
> My use case are to correct of matlab files, so usually I have a single org 
> file with a table and insert the results. 
>
> However what I missing is that my comments, and observations are difficult to 
> track.
>
> I am now  experimenting with org-remark putting the remarks and marks in the 
> property sections of headers and use than
>
> columnview 
> like
>
> #+begin_src 
> #+BEGIN: columnview :maxlevel 2  :skip-empty-rows t :indent nil :hlines 2  
> :format "%5TODO(Status) %5Ap(Name) %5com(Comment) %5Ej1(Ej1/20) %5Ej2(Ej2/25) 
> %5Ej3(Ej3/55) %5Res(Result)" 
> #+END:
> #+end_src
>
> What do others use?
>
> Regards
>
> Uwe Brauer 


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

Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Ihor Radchenko]

Eric S Fraga  writes:

> On Monday,  9 May 2022 at 20:47, Ihor Radchenko wrote:
>> Moreover, it would be useful to be able to wrap the whole chunk into
>> custom environment:
>> #+attr_latex: :wrap [options]environmant
>
> This is already possible using special blocks?  I.e.
>
> #+begin_environment
> ... figure stuff
> #+end_environment
>
> unless you mean something different.

Nope. I meant exactly this. Time to re-read the manual again :)

Best,
Ihor

Re: [BUG] orgtbl-toggle-comment hangs if table is in first line [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

matteo  writes:

> If in an org buffer there is a table, commented or not, starting from
> the first line of the buffer, the command orgtbl-toggle-comment hangs
> and must be terminated with C-g.

Thanks for reporting!
Fixed on main via 0b07b30de.

Best,
Ihor

Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Eric S Fraga]

On Monday,  9 May 2022 at 20:47, Ihor Radchenko wrote:
> Moreover, it would be useful to be able to wrap the whole chunk into
> custom environment:
> #+attr_latex: :wrap [options]environmant

This is already possible using special blocks?  I.e.

#+begin_environment
... figure stuff
#+end_environment

unless you mean something different.

-- 
: Eric S Fraga, with org release_9.5.3-478-g2a6f5c in Emacs 29.0.50

Re: [tip] Insert arbitrary LaTeX code at the beginning of any float environment

[Ihor Radchenko]

Juan Manuel Macías  writes:

> If we want to introduce arbitrary LaTeX code at the very beginning of a
> float environment, apart from the usual tricks of putting the code in
> :caption or :placement, this solution I describe here is more from the
> LaTeX side. I thik its advantages are more control and consistency from
> the point of view of LaTeX, and the possibility of introducing code of a
> certain complexity.

I'd be happy to see a built-in solution for this.
I feel that the ability to insert arbitrary LaTeX code near the
begin/end of environment would be generally a useful feature to have in
ox-latex. It could be done via #+attr_latex: :pre/:post

Moreover, it would be useful to be able to wrap the whole chunk into
custom environment:
#+attr_latex: :wrap [options]environmant

WDYT?

Best,
Ihor

Re: org-fold problems

[Eric S Fraga]

On Sunday,  8 May 2022 at 15:25, Ihor Radchenko wrote:
> I suspect the same issue. If you try
> M-: (setq org-fold-core-first-unfold-functions nil)
> before doing ediff and it helps, then I will know the culprit.

It doesn't; sorry.  With this set to nil, all drawers are closed on
ediff although all normal content is visible.

This is with both emacs and org up to date from git as of a few minutes
ago.

> 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.

Thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.3-472-gd2a459 in Emacs 29.0.50

[PATCH] Re: [ISSUE] Re: [PATCH] lisp/org-agenda.el: Add header to agenda clock report table

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> I tested this commit, it should auto append a newline character after
> ~org-agenda-clock-report-header~. Otherwise the header line will in same line 
> with table first line.

Reasonable concern.
The attached patch should fix it.

Best,
Ihor

>From c918d5097af4ca82e381cc7a45efccebadf22e91 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Mon, 9 May 2022 20:35:18 +0800
Subject: [PATCH] org-agenda: Make sure that clock report header has trailing
 newline

* lisp/org-agenda.el (org-agenda-list): Add trailing newline to
`org-agenda-clock-report-header' if there is none.
---
 lisp/org-agenda.el | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 9d38b889d..3a795ef74 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4486,8 +4486,10 @@ (defun org-agenda-list ( arg start-day span with-hour)
 	  (setq p (plist-put p :tend clocktable-end))
 	  (setq p (plist-put p :scope 'agenda))
 	  (setq tbl (apply #'org-clock-get-clocktable p))
-(when org-agenda-clock-report-header
-  (insert (propertize org-agenda-clock-report-header 'face 'org-agenda-structure)))
+  (when org-agenda-clock-report-header
+(insert (propertize org-agenda-clock-report-header 'face 'org-agenda-structure))
+(unless (string-suffix-p "\n" org-agenda-clock-report-header)
+  (insert "\n")))
 	  (insert tbl)))
   (goto-char (point-min))
   (or org-agenda-multi (org-agenda-fit-window-to-buffer))
-- 
2.35.1

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

[Ihor Radchenko]

Colin Baxter  writes:

> Could more information perhaps be added to the doc string of
> "org-agenda-clock-report-header"? And an example would be very
> useful. As it stands at present, I haven't a clue as to what the
> variable does and why it might be useful.

It's literally a string inserted right before the table. There is
nothing much to show there. See
https://orgmode.org/list/CAJAdVc06_tj58Je=tn42jqfutkjamqbqdcvobqxeegars_m...@mail.gmail.com

Is version in the attached patch more clear?

Best,
Ihor

>From 9b5f5844aedfab9f36ba89ed8beca36651370c0a Mon Sep 17 00:00:00 2001
Message-Id: <9b5f5844aedfab9f36ba89ed8beca36651370c0a.1652099870.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Mon, 9 May 2022 20:34:38 +0800
Subject: [PATCH] org-agenda-clock-report-header: Update docstring

See https://orgmode.org/list/87o808j6si@yandex.com
---
 lisp/org-agenda.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 0479a0e1f..9d38b889d 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -1221,11 +1221,11 @@ (defcustom org-agenda-timegrid-use-ampm nil
   :type 'boolean)
 
 (defcustom org-agenda-clock-report-header nil
-  "Header for org agenda clock report mode"
+  "Header inserted before the table in Org agenda clock report mode."
   :group 'org-agenda
   :type '(choice
-(string :tag "Header")
-(const :tag "No header" nil))
+  (string :tag "Header")
+  (const :tag "No header" nil))
   :safe #'stringp
   :package-version '(Org . "9.6"))
 
-- 
2.35.1

Re: how to best correct exams (code matlab) using org mode (and tables)

[Ihor Radchenko]

Uwe Brauer  writes:

> I am now  experimenting with org-remark putting the remarks and marks in the 
> property sections of headers and use than
> What do others use?

I haven't tried org-remark yet, but I am using something somewhat
similar (but much simpler). Every time I add a note to a heading with
C-c C-z, the last note contents is saved to SUMMARY heading property.
See https://github.com/yantar92/emacs-config/blob/master/config.org#column-mode

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

Thanks!

Best,
Ihor

[BUG] orgtbl-toggle-comment hangs if table is in first line [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/local/share/emacs/28.1/lisp/org/)]

[matteo]

Hi to all.

If in an org buffer there is a table, commented or not, starting from
the first line of the buffer, the command orgtbl-toggle-comment hangs
and must be terminated with C-g.

Step to reproduce:

1) create an org buffer with the following content starting from line 1:
| table |
|   |
2) move the point in the table
3) execute M-x orgtbl-toggle-comment

Expected outcome:

the table gets commented like this
# | table |
# |   |

Actual outcome:

Emacs hangs, C-g make it responde again, but the table does not change.

Emacs  : GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
cairo version 1.16.0)
 of 2022-04-09
Package: Org mode version 9.5.2 (release_9.5.2-25-gaf6f12 @ 
/usr/local/share/emacs/28.1/lisp/org/)


Thanks
Matteo

`org-id-update-id-locations' should also scan the files listed in `org-id-locations-file'

[laslydone]

Since you can add to `org-id-locations-file' without having to put the
files in `org-id-locations' I think it would make more sense to also
scan `org-id-locations-file'.

Currently you can empty `org-id-locations-file' (".org-id-locations"):
  1. $ emacs -Q 
  2. C-x C-f ztest.org 
  3. C-RET heading 
  4. M-x org-id-get-create 
  5. C-x C-s
  6. C-x C-c
  7. $ emacs -Q 
  8. C-x C-f ztest.org 
  9. M-x org-id-update-id-locations 
  10. C-x C-c

[BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9.5.2/)]

[Moritz Schäfer]

Dear mailing list,

When exporting an org-file with org-id based links  to odt, I get the
error error "FIXME: Unable to resolve ", where  is the
filename, the org-id-link was pointing to.

Org-id links (example below) are the default for org-roam (v2).

[[id:5222a0dd-5084-41bd-b61d-21dcb3290187][Note title]]

The issue lies within ox-odt.el in the org-odt-link function. There, '
destination' takes the value of the file name of the id-link target.
Therefore, (org-element-type destination) gets evaluated to 'plain-text,
which is not resolvable by 'org-odt-link--infer-description', thus it
raises the error.

I worked around this issue by adding a check for plain-text, but would like
to raise this issue here to find proper ideas on how to fix this.

  (cond
  ;; workaround
 ((eq (org-element-type destination) 'plain-text)
  (format "%s"
   destination
   desc
   ))
   ;; workaround end
 ((not label-reference)
  (org-odt-link--infer-description destination info))


Thank you,
Moritz


Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.16.0)
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @
/home/moritz/.emacs.d/elpa/27.2/develop/org-9.5.2/)

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

[Ihor Radchenko]

Timothy  writes:

> I have a new set of patches (attached), which make use of a major new feature 
> in
> engrave-faces v0.3: engraved themes.

Thanks!

> Glad to hear you’ve been able to have a look over the patches. With the 
> feedback
> I’ve received here so far, if no issues come up in the next few days I’m
> inclined to merge this, add documentation, and see what feedback pops
> up.

Before merging, could you also try to implement tests at least for
engraved feature? If I recall correctly, we do not currently have
backend-specific tests. But it would certainly help if we did. You might
as well write a small "nucleus" test for ox-latex.

Also, unless I miss something, there is no support for coderefs in the
patchset. Is it intentional?

> +(defun org-latex-src-block--verbatim
> ...
> +  (let ((caption-str (org-latex--caption/label-string src-block info))

> +(defun org-latex-src-block--custom
> ...
> +  (let ((caption-str (org-latex--caption/label-string src-block info))
> +(formatted-src (org-export-format-code-default src-block info)))

It appears that the code for caption-str is duplicated.  It could be
also factored out.

> +  (format-spec custom-env
> +   `((?s . ,formatted-src)
> + (?c . ,caption)
> + (?f . ,float)
> + (?l . ,(org-latex--label src-block info))
> + (?o . ,(or (plist-get attributes :options) "")))

I do not see a definition of `format-spec' function. There is only
`spec' above in the code. Can you double check? Either I am missing
something or something fishy is going on.

> +  (let ((code (org-element-property :value inline-src-block))
> +(lang (org-element-property :language inline-src-block)))
> +(pcase (plist-get info :latex-listings)
> +  ('nil (org-latex--text-markup code 'code info))
> +  ('minted (org-latex-inline-src-block--minted info code lang))
> +  (_ (org-latex-inline-src-block--listings info code lang)

Please use `nil and `minted.  Using ' may create issues in older Emacs.

> +% In case engrave-faces-latex-gen-preamble has not been run.
> +\\providecolor{EfD}{HTML}{f7f7f7}
> +\\providecolor{EFD}{HTML}{28292e}

What is the difference between EfD and EFD? EfD is also not documented.


> +FVEXTRA-SETUP sets fvextra's defaults according to
> +`org-latex-engraved-options', and LISTINGS-SETUP creates the
> +listings environment and defines \\listoflistings."

It is unclear what listings environment does given that we use engraved
package. Can you provide a bit more details in the docstring on what the
user will get if [LISTINGS-SETUP] is present.
It may catch users by surprise that deleting this will make captions
disappear.

> @@ -1756,6 +1929,17 @@ (defun org-latex-template (contents info)
>   (let ((template (plist-get info :latex-hyperref-template)))
> (and (stringp template)
>  (format-spec template spec)))
> + ;; engrave-faces-latex preamble
> + (when (eq org-latex-listings 'engraved)
> +   (let ((src-p (org-element-map (plist-get info :parse-tree)
> +'(src-block inline-src-block) #'identity
> +info t))
> + (fixedw-p
> +  (org-element-map (plist-get info :parse-tree)
> +  '(example-block fixed-width) #'identity
> +  info t)))
> + (when (or src-p fixedw-p)
> +   (org-latex-generate-engraved-preamble info src-p

Why not just
(org-element-map (plist-get info :parse-tree)
'(src-block inline-src-block example-block fixed-width) 
#'identity
info t)
?

>  (pcase (plist-get info :latex-listings)
>('nil (org-latex--text-markup code 'code info))
>('minted (org-latex-inline-src-block--minted info code lang))
> +  ('engraved (org-latex-inline-src-block--engraved info code lang))
>(_ (org-latex-inline-src-block--listings info code lang)

Same comment about ` in pcase.
  
>  (defun org-latex-inline-src-block--listings (info code lang)
>"Transcode an inline src block's content from Org to LaTeX, using 
> lstlistings.
>  INFO, CODE, and LANG are provided by `org-latex-inline-src-block'."
> @@ -2323,6 +2513,7 @@ (defun org-latex-keyword (keyword _contents info)
> (cl-case (plist-get info :latex-listings)
>   ((nil) "\\listoffigures")
>   (minted "\\listoflistings")
> + (engraved "\\listoflistings")
>   (otherwise "\\lstlistoflistings")

What will happen if there is no [LISTINGS-SETUP]?

> +(defcustom org-latex-engraved-theme nil
> +  "The theme that should be used for engraved code, when non-nil.
> +This can be set to any theme defined in `engrave-faces-themes' or
> +loadable by Emacs.  When set to t, the current Emacs theme is
> +used."
> +  :group 'org-export-latex
> +  :type 'symbol)

Docstring does not explain what happens when set to nil.
Also,