Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[John Kitchin]

My current solution (which already differs from the last one I posted
here...) is here:

https://github.com/jkitchin/scimax/blob/master/scimax-org-src-blocks.el#L61

It is more selective, and only changes the syntax inside these src
blocks:

"jupyter-python" "python" "emacs-lisp"

and does not change the syntax if the character is in a string.

That way it still works with xml and html in strings, or in their own
blocks.

This might be the third iteration of fixing this issue, so I wouldn't
have the hubris to say it is the final solution yet.


Eric S Fraga  writes:

> I believe this has been mentioned in passing in this thread but I'll
> repeat just in case: Unless you are working with xml or HTML in your org
> documents, and even then, having these two lines in your org
> configuration (e.g. org-mode-hook):
>
> (modify-syntax-entry ?< ".")
> (modify-syntax-entry ?> ".")
>
> solves all the problems with languages that use these in an unbalanced
> manner (comparison, assignment).  I've had this configuration for years
> now and it just works (for me).


--
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: Internal link broken when publishing (was org-id with ox-html)

[chris]

On Tuesday, 24 August 2021 17:23:24 CEST Maxim Nikulin wrote:
> On 23/08/2021 03:42, inkbottle wrote:
> > Links between two different files, like
> > `[[id:e54113f9-2ad7-4a86-94be-68ffc696de0b][hello]]`, get broken when
> > publishing. (whatever the settings).
> > 
> > I haven't found any workaround.
> > 
> > Being able to move around entries, functionality provided by
> > `org-id-link-to- org-use-id`, is pivotal, IMO.
> 
>  From my point of view it looks like a bug.
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox.el#L4381

Thanks a lot for your help, I'm really struggling on this one. Sorry, I was 
afk for a few days.

I believe it's a bug, plain and simple.

With a unique org file, the `:ID: e54113f9-2ad7-4a86-94be-68ffc696de0b` are 
resolved to `orgfa9c151` consistently.

Which is the expected behavior: the translation table is consistent.

When there are multiple org files, in every example I've tried, every `org-id` 
based links was broken.

There is a patch here:
https://gist.github.com/jethrokuan/d6f80caaec7f49dedffac7c4fe41d132
but, as I understand it, the workaround consists in treating `:ID:` similarly 
as `:CUSTOM_ID:`, that is, exporting them "verbatim".

That method, would be different from the *upstream* way, consisting in creating 
a "translation table".

IMO the "patch" is more like a temporary workaround which can make the code 
confusing and difficult to maintain. Because a unique question is solved in 
different ways by different developers in different files.

I think that the fix should happen in
https://github.com/emacsmirror/org/blob/master/lisp/ox.el
where the translation table is created and used, but I failed to grasp how it 
works due to my insufficient understanding of emacs-lisp.

> checks for ID property.
> https://code.orgmode.org/bzg/org-mode/src/master/lisp/ox-html.el#L1659
> queries CUSTOM_ID only. I suppose, ID should be here as well. A subtle
> point is which one (ID or CUSTOM_ID) should be used if both are defined
> for some headers.

Yes, "ID should be here as well" => No.
That is the point I'm advocating above.
`:CUSTOM_ID:` are meant to be treated in a so-called "stable" way. That is to 
say, the `CUSTOM_ID` you see in your org-file, is what you get in your HTML 
file 
(also I've done some tests with that method, and I recall it wasn't working at 
all in a multiple org files setting).
On the other hand, `:ID:` are meant to be treated through a *translation 
table*, and should result in some `orgfa9c151` thing, on the HTML side.
Weaving the two methods together doesn't seem like "road to success".

> Maybe it is possible to create workaround as a custom config without
> touching of Org code. I guess, "nicer" ids may be replaced by values of
> ID property. Examples (I tried none of them):
> -
> https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading
> https://orgmode.org/list/e1jxajq-0004dk...@lists.gnu.org/ (TEC.
> [Interest] Determanistic Org IDs. Sun, 19 Jul 2020 22:27:31 +0800)
> -
> https://github.com/alphapapa/unpackaged.el#export-to-html-with-useful-anchor
> s
> https://orgmode.org/list/CA+G3_POCYTKR6M1K8XUPzUsg5EHd5Tv4FE4X-6MvadCSjSkHi
> a...@mail.gmail.com/ (Tom Gillespie. Tue, 8 Dec 2020 20:39:08 -0500, Re:
> stability of toc links) -
> https://github.com/zzamboni/dot-doom/blob/master/doom.org#capturing-and-crea
> ting-internal-org-links
> https://orgmode.org/list/CAGY83EcFExvco6TuTOQiywgdDO0cXE+db828LeiDdimxBroVs
> g...@mail.gmail.com/ (Diego Zamboni. Wed, 9 Dec 2020 09:45:52 +0100. Re:
> stability of toc links) -
> http://ivanmalison.github.io/dotfiles/#usemyowndefaultnamingschemefororghead
> ings
> https://orgmode.org/list/4698cfeb2e415f88bd25e71267f29...@isnotmyreal.name/
> (TRS-80. Sat, 12 Dec 2020 20:25:15 -0500. Re: Better heading links in
> org-mode exports)
> - https://writequit.org/articles/emacs-org-mode-generate-ids.html

The methods above are, as I understand it, all about making more beautiful 
links to export to HTML.
Not about the "translation table" devised in `ox.el` being broken when working 
with multiple org-files.
org-id is creating a neat framework for navigating between multiple org-files.
Also, if I remember correctly, when using `CUSTOM_ID` with several org-files, 
you have to specify the file, contrary to how org-id work, using a database to 
find all by itself, the correct file to jump to.

Re: Org table: numeric locale

[Max Nikulin]

On 05/09/2021 18:08, Jarmo Hurri wrote:

Maxim Nikulin writes:

On 28/08/2021 14:07, Jarmo Hurri wrote:



Emacs documentation says that Emacs uses the value of LC_NUMERIC:
https://www.gnu.org/software/emacs/manual/html_node/emacs/General-Variables.html


It is a confusing statement, see:
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645
   #29645 Feature Request: Locale aware formatting

...

I see. I am surprised by the disparity between documentation and
reality, given the quality I have learned to associate with emacs.


You may report a documentation-related bug to debbugs.gnu.org. Far in 
the past there were some changes in the code, maybe update of 
documentation was forgotten.


src/ChangeLog.6

1996-04-08  Richard Stallman  
(x_term_init): Restore LC_TIME as well as LC_NUMERIC.
1995-07-16  Richard Stallman  
(x_term_init) [HAVE_X11XTR6]: Set LC_NUMERIC and LC_TIME back to C.

Git archeology may provide more detailed info, though I have not tried.

Re: [PATCH] ox-latex: Allow percent sign in 'src-block' caption

[Timothy]

Hi Maxim,

> I have decided that it is better to provide a partial fix than to leave
> the problem as is.  This patch covers only plain verbatim environment,
> more advanced formatting using listings or minted should be addressed
> by another change (Anybody?).  Do not close the bug after applying
> this patch.
>
> [2. text/x-patch; 
> 0001-ox-latex-Allow-percent-sign-in-src-block-caption.patch]…

Thanks for the patch. At a glance it looks good, and it’s great to see you’ve
gone to the effort of writing some tests for it too! That’s something we should
probably do more of 😅. Hopefully someone else will get around to giving your
work a closer look and maybe merge it soon-ish :)

All the best,
Timothy

[PATCH] ox-latex: Allow percent sign in 'src-block' caption

[Maxim Nikulin]

On 03/09/2021 19:17, Maxim Nikulin wrote:
> On 30/07/2021 22:00, Charest, Luc wrote:
>>
>> org-latex-src-block: Not enough arguments for format string
> 
> Confirmed
> 
> User input is combined with format string in `org-latex-src-block'
> so percent character in caption is treated as a format specifier.> Maybe 
> emacs versions newer than 26 does not throw an error
> on extra specifier with missed argument. =:latex-cation-above nil=
> might still cause corrupted LaTeX code.

I have decided that it is better to provide a partial fix than to leave
the problem as is.  This patch covers only plain verbatim environment,
more advanced formatting using listings or minted should be addressed
by another change (Anybody?).  Do not close the bug after applying
this patch.
>From 5e6930e3c3d30f13e6e33a6fc504b445cacc579d Mon Sep 17 00:00:00 2001
In-Reply-To: 
References: 
From: Max Nikulin 
Date: Tue, 7 Sep 2021 19:01:11 +0700
Subject: [PATCH] ox-latex: Allow percent sign in 'src-block' caption

* lisp/ox-latex.el (org-latex-src-block): Prevent leak of percent sign
from caption to `format' first argument causing export failure due to
insufficient argument number.  The fix covers only the case of verbatim
environment.
* testing/lisp/test-ox.el
(test-org-export/latex-src-block-verbatim-caption): New test for src
block LaTeX export with cases of various formatting of caption and
verbatim environment.  Check that percent signs in caption and source
block body do not lead to errors.

Reported-by: Charest, Luc 

---
 lisp/ox-latex.el| 30 ++---
 testing/lisp/test-ox.el | 97 +
 2 files changed, 111 insertions(+), 16 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 99076f8b9..b325b8892 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2994,22 +2994,20 @@ contextual information."
   (cond
;; Case 1.  No source fontification.
((or (not lang) (not listings))
-	(let* ((caption-str (org-latex--caption/label-string src-block info))
-	   (float-env
-		(cond ((string= "multicolumn" float)
-		   (format "\\begin{figure*}[%s]\n%s%%s\n%s\\end{figure*}"
-			   (plist-get info :latex-default-figure-position)
-			   (if caption-above-p caption-str "")
-			   (if caption-above-p "" caption-str)))
-		  (caption (concat
-(if caption-above-p caption-str "")
-"%s"
-(if caption-above-p "" (concat "\n" caption-str
-		  (t "%s"
-	  (format
-	   float-env
-	   (concat (format "\\begin{verbatim}\n%s\\end{verbatim}"
-			   (org-export-format-code-default src-block info))
+	(let ((caption-str (org-latex--caption/label-string src-block info))
+  (verbatim (format "\\begin{verbatim}\n%s\\end{verbatim}"
+(org-export-format-code-default src-block info
+  (cond ((string= "multicolumn" float)
+ (format "\\begin{figure*}[%s]\n%s%s\n%s\\end{figure*}"
+ (plist-get info :latex-default-figure-position)
+ (if caption-above-p caption-str "")
+ verbatim
+ (if caption-above-p "" caption-str)))
+(caption (concat
+  (if caption-above-p caption-str "")
+  verbatim
+  (if caption-above-p "" (concat "\n" caption-str
+(t verbatim
;; Case 2.  Custom environment.
(custom-env
 	(let ((caption-str (org-latex--caption/label-string src-block info))
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 3f39645af..54558041b 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -3907,6 +3907,103 @@ Another text. (ref:text)
 	  (org-export-format-code-default
 	   (org-element-map tree 'src-block #'identity info t) info))
 
+(ert-deftest test-org-export/latex-src-block-verbatim-caption ()
+  "Test `org-latex-src-block' caption for verbatim environment.
+Check that percent sign does not become a part of format.
+This test does not cover listings and custom environments."
+  (let ((export
+	 (lambda (buffer-text)
+	   (org-test-with-parsed-data
+	   buffer-text
+	 (let* ((backend (org-export-get-backend 'latex))
+		(info (org-combine-plists
+			   (org-export--get-export-attributes backend)
+			   (org-export-get-environment backend)))
+		(result (org-latex-src-block
+			 (org-element-map tree 'src-block #'identity info t)
+			 t info)))
+	   ;; Remove properties to make failure reports more clear.
+	   (set-text-properties 0 (length result) nil result)
+	   result)
+
+(should (equal
+	 "\
+\\begin{verbatim}
+\"No float, no listings, 20%S\"
+\\end{verbatim}
+\\captionof{figure}{Caption of verbatim is below, 20\\%s}
+"
+	 (funcall export
+		  "\
+#+CAPTION: Caption of verbatim

Re: Bug Re: Greater than, less than bug in emacs-lisp source block

[Eric S Fraga]

I believe this has been mentioned in passing in this thread but I'll
repeat just in case: Unless you are working with xml or HTML in your org
documents, and even then, having these two lines in your org
configuration (e.g. org-mode-hook):

(modify-syntax-entry ?< ".")
(modify-syntax-entry ?> ".")

solves all the problems with languages that use these in an unbalanced
manner (comparison, assignment).  I've had this configuration for years
now and it just works (for me).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-628-g366444
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

[Elias Bounatirou]

Just to clarify the BUG:
Citations in a footnote in the following environment are not exported to
LaTeX: when the footnote follows two or more citations, of which one has a
suffix, i.e. for instance in

Body text with a citation: [cite:@low2001; @mcneill2011 with a
suffix][fn:3].

Am Mo., 6. Sept. 2021 um 17:45 Uhr schrieb Bruce D'Arcus :

> It does seems there's a little bug with this; for in-footnote citation
> outputs, but the second not.
>
> Body text with a citation: [cite:@mcneill2011 with a suffix][fn:2].
>
> Body text with a citation: [cite:@low2001; @mcneill2011; with a
> suffix][fn:3].
>
> On Mon, Sep 6, 2021 at 7:50 AM Bruce D'Arcus  wrote:
> >
> > This works fine for me:
> >
> > #+bibliography: test.bib
> > #+cite_export: biblatex verbose
> >
> > Body text with a citation: [cite:@mcneill2011].
> >
> > Footnote: [fn:1]
> >
> > #+print_bibliography:
> >
> > * Footnotes
> >
> > [fn:1] A commentary, and then a citation: [cite:@low2001].
> >
> > Results for the end is:
> >
> > Body text with a citation: \autocite{mcneill2011}.
> >
> > Footnote: \footnote{A commentary, and then a citation:
> \autocite{low2001}.}
> >
> > On Mon, Sep 6, 2021 at 6:04 AM Elias Bounatirou
> >  wrote:
> > >
> > > Hello,
> > > I tried to insert a citation in a footnote using Org-ref-cite.
> Unfortunately, when exporting to  LaTeX, the citation is ignored, i.e., it
> is left out and does not appear in the LaTeX output. Is there a way to make
> references appear in the footnotes or is there at least a work around? The
> footnote itself in my case was created by C-c C-x f.
> > > I am writing to the list, following John Kitchin's advice, who
> supposes that the problem might be a limitation in Org-cite, see also my
> github issue https://github.com/jkitchin/org-ref-cite/issues/22.
> > > I am using Org-mode to write a book on a linguistic subject and I
> absolutely (desperately!) need footnotes with references in them.
> Therefore, if the functionality in question does not exist, my mail is also
> a feature request to create it.
> > > Many thanks for your help.
> > >
> > > Elias
> > >
> > > (org-version)
> > > "9.4.6"
> > > (emacs-version)
> > > "GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20,
> cairo version 1.16.0)
> > >  of 2021-06-04"
>