Re: export dispatch → change the default "Contents" string

[Juan Manuel Macías]

Hi, jean-Christophe,

Jean-Christophe Helary writes:

> What is the parameter to change the default "Contents" ToC string when 
> exporting to PDF ?

If I'm not wrong, I think there is no native Org way to change the
default string for LaTeX literals. But if you use babel (the LaTeX
package), you can add this command:

#+LaTeX_Header: \addto{\captionsenglish}{\renewcommand\contentsname{foo}}

That's the old way of doing it, and it still works. The latest Babel
versions also incorporate this other variant:

\setlocalecaption{language-name}{caption-name}{string}

for example:

\setlocalecaption{english}{contents}{Table of Contents}

NB: I strongly recommend using babel always for LaTeX, in any of its
flavors (pdfLaTeX, XeLaTeX, LuaLaTeX), instead of polyglossia, which is
a very buggy package. This package came up when babel didn't support
XeTeX and LuaTeX, years ago, but now it doesn't sense to use it.

Best regards,

Juan Manuel 

[Question] A single *-language-alist in ox-latex.el?

[Juan Manuel Macías]

Hi,

I have seen that `org-latex-polyglossia-language-alist' contains far
more languages than `org-latex-babel-language-alist'.

Well, if I'm not mistaken, the situation in the LaTeX ecosystem is this:
Polyglossia appeared as a babel replacement for XelaTeX and LuaLaTeX,
since babel, at that time, had no support for these two new Unicode
based TeX engines. I think those two separate lists in ox-latex.el
translate that situation. But the reality is different now: babel has
full support now for LuaTeX and XeTeX and supports more languages than
polyglossia (and also supports language variants. See
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf p.
20). In addition, babel is part of the LaTeX core and is, therefore,
better mantained.

Of course, anyone who wants to use polyglossia in their documents can
keep doing it without problems. But I think it does not make much sense
to mantain in ox-latex.el two separate lists today. Maybe, for
simplicity, it would be better to unify the two lists in a single db,
something like `org-latex-language-alist'. What do you think?

Best regards,

Juan Manuel

--
--
----------
Juan Manuel Macías

https://juanmanuelmacias.com/

Re: [Question] A single *-language-alist in ox-latex.el?

[Juan Manuel Macías]

Hi Stefan,

Stefan Nobis writes:

> And, as far as I remember, babel development had nearly ceased during
> that period.
>
> Since quite some years, the development has gained much more traction
> for babel and, as far as I read, babel is today as good or superior to
> polyglossia in many regards (but polyglossia is also in quite a good
> shape today). See for example:
>
> https://tex.stackexchange.com/questions/482396/decide-between-polyglossia-and-babel-for-lualatex-in-2019
>
> In short: Babel is a very good choice in almost all cases, maybe
> except for right-to-left texts set with XeLaTeX.

Indeed, Javier Bezos (who is also the author of very popular packages
like enumitem or titlesec/titletoc) is doing a great job with Babel (you can
see the latest news here: https://latex3.github.io/babel/). And he has
added a lot of powerful features, such as babel replacements (with Lua code)
or the possibility to load languages via ini files and define new
languages with \babelprovide

I've been doing some testing, and I think this hypothetical new
unified list could support two types of members:

1. A member with 2 elements:

("lang-id" "lang-name"),

i.e.: ("it" "italian")

2. A member with 4 elements (for variants):

("lang-id" "babel-lang-name" "polyglossia-lang-name" "polyglossia-variant")

i.e.: ("la-classic" "classiclatin" "latin" "classic")

And then it would be necessary to make some minor modifications in
org-latex-guess-polyglossia-language and org-latex-guess-babel-language.

I will try to write a patch (or at least a proof of concept) in the next days 
...

Best regards,

Juan Manuel 


-- 
--
--
Juan Manuel Macías

https://juanmanuelmacias.com/

[PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists

[Juan Manuel Macías]

Hi all,

I'm attaching a patch with a proposal to unify in a single constant
(named `org-latex-language-alist')
`org-latex-polyglossia-language-alist' and
`org-latex-babel-language-alist', along with some necessary (minor)
modifications in `org-latex-guess-polyglossia-language' and
`org-latex-guess-babel-language'

The new list, which is not exhaustive, is built taking as a reference
the documentation of Babel and Polyglossia in their latest versions
within TeX live 2021. It also assumes the latest improvements in the
babel package (on the current state of the art regarding the babel and
polyglossia packages, see this previous thread:
https://list.orgmode.org/87wnmv4s87@posteo.net/). I have also
corrected some minor inconsistencies in the previous two lists.

This new alist supports three types of members:

- Members with two elements: CODE BABEL/POLYGLOSSIA-OPTION.

i.e.: ("ar" "arabic")

- Members with three elements: CODE BABEL/POLYGLOSSIA-OPTION ASTERISK
(the presence of the asterisk indicates that this language is not loaded
in Babel using the old method of ldf files but using ini files. If Babel
is loaded in an Org document with these languages, the \"AUTO \"
argument is just removed, to avoid compilation errors. The new babel
method with ini files  is not supported, for backward
compatibility with 'old' ldf method).

i.e. ("bo" "tibetan" "*")

- Members with four elements (for variants of languages): CODE
BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT

i.e. ("es" "spanishmx" "spanish" "mexican")

==> babel:

\usepackage[mexican]{babel}

==> polyglossia:

\usepackage{polyglossia}
\setmainlanguage[variant=mexican]{spanish}

I also attach an Org document for testing.

Best regards,

Juan Manuel

>From 389a4e43756a7c195c2c1f751b7dc9c03447526d Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 16:55:31 +0200
Subject: [PATCH] ox-latex.el: Unify in one list babel and polyglossia language
 alists

* lisp/ox-latex.el (org-latex-language-alist): Unify in a single list `org-latex-polyglossia-language-alist' and `org-latex-babel-language-alist'
---
 lisp/ox-latex.el | 167 +++
 1 file changed, 68 insertions(+), 99 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..de03470fa 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -160,144 +160,109 @@
 
 ;;; Internal Variables
 
-(defconst org-latex-babel-language-alist
-  '(("af" . "afrikaans")
-("bg" . "bulgarian")
-("ca" . "catalan")
-("cs" . "czech")
-("cy" . "welsh")
-("da" . "danish")
-("de" . "germanb")
-("de-at" . "naustrian")
-("de-de" . "ngerman")
-("el" . "greek")
-("en" . "english")
-("en-au" . "australian")
-("en-ca" . "canadian")
-("en-gb" . "british")
-("en-ie" . "irish")
-("en-nz" . "newzealand")
-("en-us" . "american")
-("es" . "spanish")
-("et" . "estonian")
-("eu" . "basque")
-("fi" . "finnish")
-("fr" . "french")
-("fr-ca" . "canadien")
-("gl" . "galician")
-("hr" . "croatian")
-("hu" . "hungarian")
-("id" . "indonesian")
-("is" . "icelandic")
-("it" . "italian")
-("la" . "latin")
-("ms" . "malay")
-("nl" . "dutch")
-("nb" . "norsk")
-("nn" . "nynorsk")
-("no" . "norsk")
-("pl" . "polish")
-("pt" . "portuguese")
-("pt-br" . "brazilian")
-("ro" . "romanian")
-("ru" . "russian")
-("sa" . "sanskrit")
-("sb" . "uppersorbian")
-("sk" . "slovak")
-("sl" . "slovene")
-("sq" . "albanian")
-("sr" . "serbian")
-("sv" . "swedish")
-("ta" . "tamil")
-("tr" . "turkish")
-("uk" . "ukrainian"))
-  "Alist between language code and corresponding Babel option.")
-
-(defconst org-latex-polyglossia-language-alist
-  '(("am" "amharic")
+(defconst org-latex-language-alist
+  '(("am" "amharic" "*")
 ("ar" "arabic")
-("ast" "asturian")
+("ast" "asturian" "*")
 ("bg" "bulgarian")
-("bn" "bengali")
-("bo" "tibetan")
+("bn" "bengali" "*")
+("bo" "tibetan" "*")
 ("br" "breton")
 ("ca" "catalan")
-("cop" "coptic")
+("cop" "coptic" "*")
 ("cs" "czech")
 ("cy" "welsh")
 ("da" "danish")
-("de" "german" "german")
-("de-at" "german" "austrian")
-("de-de" "german" "german")
-("dsb" "lsorbian")
-("dv" "divehi")
+("de" "ngerman" "german" "german")
+("de-at" "naustrian" "german" "austrian")
+("dsb" "lsorbian" "*")
+("dv" "divehi" "*")
 ("el" "greek")
-("en" "english" "usmax")
-("en-au" "english" "australian")
-("en-gb" "english" "uk")
-("en-nz" "english" "newzealand")
-("en-us" "english" "usmax")
+("el-polyton" "polutonikogreek" "greek" "polytonic")
+("en" "american" "english" "usmax")
+("en-au" "australian" "english" "australian")
+("en-gb" "british" "english" "uk")
+("en-nz" "newzealand" "english" "newzealand")
+("en-us" "american" "english" "

[PATCH] org-manual.org: List the languages supported by smart quotes feature

[Juan Manuel Macías]

Hi,

I think a footnote with a list of (currently) supported languages could
be helpful for users who want to apply this feature.

Best regards,

Juan Manuel

>From 26f799a5a53b35f7f3e6e3df10689855832dbebd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 19:11:48 +0200
Subject: [PATCH] org-manual.org: List the languages supported by smart quotes
 feature

* doc/org-manual.org (Export Settings): A footnote is added.
---
 doc/org-manual.org | 159 +++--
 1 file changed, 82 insertions(+), 77 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b25da7889..195ed1d46 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11637,9 +11637,9 @@ following arguments.
 
   #+vindex: org-export-with-smart-quotes
   Toggle smart quotes (~org-export-with-smart-quotes~).  Depending on
-  the language used, when activated, Org treats pairs of double quotes
-  as primary quotes, pairs of single quotes as secondary quotes, and
-  single quote marks as apostrophes.
+  the language used[fn:124], when activated, Org treats pairs of
+  double quotes as primary quotes, pairs of single quotes as secondary
+  quotes, and single quote marks as apostrophes.
 
 - ~*~ ::
 
@@ -11869,7 +11869,7 @@ keyword:
 #+cindex: excluding entries from table of contents
 #+cindex: table of contents, exclude entries
 Org includes both numbered and unnumbered headlines in the table of
-contents[fn:124].  If you need to exclude an unnumbered headline,
+contents[fn:125].  If you need to exclude an unnumbered headline,
 along with all its children, set the =UNNUMBERED= property to =notoc=
 value.
 
@@ -11988,7 +11988,7 @@ be omitted to use the obvious defaults.
 | =#+INCLUDE: "~/.emacs" :lines "10-"=  | Include lines from 10 to EOF   |
 
 Inclusions may specify a file-link to extract an object matched by
-~org-link-search~[fn:125] (see [[*Search Options in File Links]]).  The
+~org-link-search~[fn:126] (see [[*Search Options in File Links]]).  The
 ranges for =:lines= keyword are relative to the requested element.
 Therefore,
 
@@ -12028,7 +12028,7 @@ following syntax:
 : #+MACRO: name   replacement text; $1, $2 are arguments
 
 #+texinfo: @noindent
-which can be referenced using ={{{name(arg1, arg2)}}}=[fn:126].  For
+which can be referenced using ={{{name(arg1, arg2)}}}=[fn:127].  For
 example
 
 #+begin_example
@@ -12147,7 +12147,7 @@ are not exported.
 Finally, a =COMMENT= keyword at the beginning of an entry, but after
 any other keyword or priority cookie, comments out the entire subtree.
 In this case, the subtree is not exported and no code block within it
-is executed either[fn:127].  The command below helps changing the
+is executed either[fn:128].  The command below helps changing the
 comment status of a headline.
 
 - {{{kbd(C-c ;)}}} (~org-toggle-comment~) ::
@@ -12419,7 +12419,7 @@ should in principle be exportable as a Beamer presentation.
 
 - Org exports a Beamer frame's objects as block environments.  Org can
   enforce wrapping in special block types when =BEAMER_ENV= property
-  is set[fn:128].  For valid values see
+  is set[fn:129].  For valid values see
   ~org-beamer-environments-default~.  To add more values, see
   ~org-beamer-environments-extra~.
   #+vindex: org-beamer-environments-default
@@ -13007,7 +13007,7 @@ as-is.
 #+vindex: org-html-mathjax-options~
 LaTeX math snippets (see [[*LaTeX fragments]]) can be displayed in two
 different ways on HTML pages.  The default is to use the [[https://www.mathjax.org][MathJax]],
-which should work out of the box with Org[fn:129][fn:130].  Some MathJax
+which should work out of the box with Org[fn:130][fn:131].  Some MathJax
 display options can be configured via ~org-html-mathjax-options~, or
 in the buffer.  For example, with the following settings,
 
@@ -13019,7 +13019,7 @@ in the buffer.  For example, with the following settings,
 #+texinfo: @noindent
 equation labels are displayed on the left margin and equations are
 five em from the left margin.  In addition, it loads the two MathJax
-extensions =cancel.js= and =noErrors.js=[fn:131].
+extensions =cancel.js= and =noErrors.js=[fn:132].
 
 #+vindex: org-html-mathjax-template
 See the docstring of ~org-html-mathjax-options~ for all supported
@@ -13082,7 +13082,7 @@ line.
 #+vindex: org-export-html-todo-kwd-class-prefix
 #+vindex: org-export-html-tag-class-prefix
 You can modify the CSS style definitions for the exported file.  The
-HTML exporter assigns the following special CSS classes[fn:132] to
+HTML exporter assigns the following special CSS classes[fn:133] to
 appropriate parts of the document---your style specifications may
 change these, in addition to any of the standard classes like for
 headlines, tables, etc.
@@ -13319,7 +13319,7 @@ LaTeX export back-end finds the compiler version to use from
 Org file.  See the docstring for the
 ~org-latex-default-packages-alist~ for loading packages with certain
 compilers.  Also see ~org-latex

[patch] ox-html.el: add html attribute (verse numbers) to verse blocks

[Juan Manuel Macías]

Hi all,

I believe that an html attribute to display marginal verse numbers in
sequence could be useful for certain content, as philological texts
(like here:
https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I)

The `lines' property must be a digit that is equivalent to the verse
numbers sequence:

#+ATTR_HTML: :lines 5
#+begin_verse
some verses...
#+end_verse

Best regards,

Juan Manuel 

>From 9f1bbef52989532e16873a1f75331af0c7b0401f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 22:12:44 +0200
Subject: [PATCH] ox-html.el: add verse numbers html attribute to verse blocks

* lisp/ox-html.el (org-html-verse-block): add `lines' html attribute
---
 lisp/ox-html.el | 45 +++--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index a150b1fdb..4889bbe45 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -281,6 +281,7 @@ property on the headline itself.")
   .underline { text-decoration: underline; }
   #postamble p, #preamble p { font-size: 90%; margin: .2em; }
   p.verse { margin-left: 3%; }
+  .versenum {float:right;}
   pre {
 border: 1px solid #e6e6e6;
 border-radius: 3px;
@@ -3754,20 +3755,36 @@ information."
 
  Verse Block
 
-(defun org-html-verse-block (_verse-block contents info)
-  "Transcode a VERSE-BLOCK element from Org to HTML.
-CONTENTS is verse block contents.  INFO is a plist holding
-contextual information."
-  (format "\n%s"
-	  ;; Replace leading white spaces with non-breaking spaces.
-	  (replace-regexp-in-string
-	   "^[ \t]+" (lambda (m) (org-html--make-string (length m) " "))
-	   ;; Replace each newline character with line break.  Also
-	   ;; remove any trailing "br" close-tag so as to avoid
-	   ;; duplicates.
-	   (let* ((br (org-html-close-tag "br" nil info))
-		  (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br
-	 (replace-regexp-in-string re (concat br "\n") contents)
+(defun org-html-verse-block (verse-block contents info)
+"Transcode a VERSE-BLOCK element from Org to HTML.
+CONTENTS is verse block contents.  INFO is a plist holding
+contextual information."
+(let* ((lin (org-export-read-attribute :attr_html verse-block :lines))
+	   (versenum (if lin 0 ""))
+	   (seqverse (if lin (string-to-number lin) ""))
+	   (contents (if lin
+			 (with-temp-buffer
+			   (insert contents)
+			   (save-excursion
+			 (goto-char (point-min))
+			 (while (re-search-forward "^.+" nil t seqverse)
+			   (re-search-forward "$" nil t)
+			   (replace-match (concat ""
+		  (number-to-string
+		   (setf versenum (+ versenum seqverse)))
+		  ""
+			   (buffer-string))
+		   contents)))
+  (format "\n%s"
+	  ;; Replace leading white spaces with non-breaking spaces.
+	  (replace-regexp-in-string
+	   "^[ \t]+" (lambda (m) (org-html--make-string (length m) " "))
+	   ;; Replace each newline character with line break.  Also
+	   ;; remove any trailing "br" close-tag so as to avoid
+	   ;; duplicates.
+	   (let* ((br (org-html-close-tag "br" nil info))
+		  (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br
+		 (replace-regexp-in-string re (concat br "\n") contents))
 
 
 ;;; Filter Functions
-- 
2.32.0

Re: how to export to odt with 11 or 10 pt fonts? Default font setting

[Juan Manuel Macías]

Uwe Brauer writes:

> I searched about google, but it seems that the only way to have a 10 or
> 11 pt font size is, again, by using styles. Am I right?

Yes, you are right. Word processors handle paragraph and character
styles. Anything that is not styled is applied by direct formatting,
manually, which is often bad practice.

Fun fact: 11pt (for example) in libreoffice or M$ Word is not the same
as 11pt in LaTeX. The reason is that TeX uses by default the classic
point "pt", traditionally used in English-speaking countries. 12pt=1pc
(pica). Word processors and DTP programs like InDesign or QuarkXpress
use the postscript point, which is somewhat higher. In TeX the
postscript point is called 'big point' (bp). There is also the didot
point, which in TeX is called "dd" (12dd = 1 cicero). See:
https://github.com/tweh/tex-units

With the calc-units package you can easily convert between these TeX
units in Elisp. For instance:

(require 'calc-units)

(calc-eval (math-convert-units (calc-eval "11texpt" 'raw) (calc-eval
"texbp" 'raw)))

Best regards,

Juan Manuel 

Re: how to export to odt with 11 or 10 pt fonts? Default font setting

[Juan Manuel Macías]

Uwe Brauer writes:

> Thanks, but it seems 11TeXpt-->10.95
>
> So it is not that different.

In typography it's a significant difference. It's not dramatic, but it
can produce different results in a book using the same body text and the
same line spacing, same margins, page dims. etc. Also TeX uses more
decimals. It all depends on more factors, of course: the font or the
microtype properties of pdfTeX and LuaTeX, especially horizontal
scaling, which can also have a significant influence, when activated, on
the appearance of text and pagination.

In any case, what I said was nothing more than a fun typographic fact,
since most people think that there is only one type of point.

Best regards,

Juan Manuel 

[tip] Go to the org node from the attached directory

[Juan Manuel Macías]

Hi,

I often come across the following use case:

helm-locate leads me to a file named (for example) document.pdf, which
is in an attached folder of an Org node. I open the document and then I
would like to jump from there to the Org node. I don't know if anyone
has found any solutions for this or if there is any specific package. I
have come up with this poor man's solution: add a local variable to the
attached directory, which should contain the org node ID.

The function that adds the variable after I run org-attach:

#+begin_src emacs-lisp
  (defun my-org-attach/add-dir-variable (&rest _ignore)
(let* ((dir (org-attach-dir))
   (id (org-id-get-create))
   (default-directory dir))
  (unless (file-exists-p (concat dir "/" ".dir-locals.el"))
(save-window-excursion
  (add-dir-local-variable nil 'node-id id)
  (save-buffer)
  (read (current-buffer))
  (kill-buffer)
#+end_src

and then:

#+begin_src emacs-lisp
  (advice-add 'org-attach :after  #'my-org-attach/add-dir-variable)
#+end_src

and the function to jump from the attached folder to the org node:

#+begin_src emacs-lisp
  (defun my-org-attach/goto-node ()
(interactive)
(org-id-goto node-id))
#+end_src

(of course this only works if there is only one attached directory per
node).

Best regards,

Juan Manuel 

Re: how to export to odt with 11 or 10 pt fonts? Default font setting

[Juan Manuel Macías]

copropriete27ruemo...@gmail.com writes:

> Unless you insist on using Computer Modern with a word processing
> programm (yes, it can be done, at least with the OTF versions of these
> fonts), or Times New Roman/Cambria with LaTeX (again possible thanks to
> their OTF incarnation) and slaving to force LaTeX choices on Word (or
> Word choices on LaTeX, much harder and probably abysmally stupid), your
> resulting documents will vary for much larger reasons : floats
> handling, table structures, layout structure, different ligatures,
> different kernings, etc...

It is not enough to use the same font nor the same font technology
(otf). In my previous post I referred to microtypegraphical processes
that influence drastically the formal aspect, regardless of the font and
the 'glyph level', layout, and other macro typographycal elements. Word
processors do not have the TeX line breaking algorithm, for example, nor
the horizontal scaling and optical margin alignment properties that were
first implemented in pdfTeX (these properties are based on the theories
of Herman Zapf on the Gutenberg Bible and were implemented for the first
time in an experimental software older than TeX called hz-program). That
is why I always recommend that documents made in a word processor are
never fully justified: word processors *do not know how to justify*
(HTML also does not know how to do it) and the result is usually bad and
full of rivers. And there is the fact also that word processors work on
postscript points. As I said in the previous message, there are many
more factors, but these merely physical (and 'invisible') factors are
important.

Even software like Adobe InDesign, which implements the TeX algorithm
and the microtype properties of Zapf (in a rather sloppy way, since it
does so with generic values applied to the character and not to the
glyph) does not achieve the precision of TeX; therefore, there may be
variations.

In any case, I am talking about processes at the lowest level
(microtypographical). Generally speaking, word processors cannot imitate
TeX. But TeX can imitate word: just disable TeX algorithm (\sloppypar)
and use postscript points values. But, except as an experiment, it
doesn't make much sense...

> BTW: since most of what is typeset nowadays will be used as PDF, HTML
> and/or epub (and paper-printed only for archival purposes), it is high
> time to revisit typography funamentals (currently based on more than 5
> centuries of use of the *physics* of the "paper" medium) to adapt them
> to the physics of computer display and the physiology of human reading
> of this new medium (which is *not* the same as "paper" reading).

The PDF format has evolved a lot since the 90s, but it is still, in
essence, 'printed paper that you can see on screen', device independent.
Paradoxically, it was a revolution in printing, and it was of crucial
importance in the extinction of the old photomechanical printing
methods, which were complex and extremely expensive. As for the
relationship of typography with digital media, or new media, that is a
long topic. But, in any possible medium, I think that what Stanley
Morison (author of Times Roman) said will always prevail in good
typography:

#+begin_quote
Typography is the efficient means to an essentially
utilitarian and only accidentally aesthetic end, for the enjoyment of
patterns is rarely the reader’s chief aim. Therefore, any disposition of
printing material which, whatever the intention, has the effect of
coming between the author and the reader is wrong.
#+end_quote

Best regards,

Juan Manuel 

[minor tip] "TeXify" strings "TeX" and "LaTeX" when exporting to HTML

[Juan Manuel Macías]

Hi all,

I wrote this simple filter for my blogs, which formats "TeX" and "LaTeX"
strings in the TeX 'typographic' style (or something similar).

First, these variables:

#+begin_src emacs-lisp
  (setq my/tex-html-string "TEX")
  
  (setq my/latex-html-string "LATEX")
#+end_src

Of course, the strings can be improved. Another alternative would be to use the 
wikipedia images:

https://wikimedia.org/api/rest_v1/media/math/render/svg/45c5b62b0f454f4ed8caa486d6d3cd0e0c065232\";
style=\"vertical-align: -1.005ex; width:5.094ex; height:2.843ex;\"
alt=\"TeX\"/>

https://wikimedia.org/api/rest_v1/media/math/render/svg/fa952935eafe23237c5a52922460c192fde88435\";
style=\"vertical-align: -1.005ex; width:7.107ex; height:2.843ex;\"
alt=\"LaTeX\"/>

The function:

#+begin_src emacs-lisp
  (defun my/latex-string-html-filter (text backend info)
(interactive)
(when (org-export-derived-backend-p backend 'html)
  (let ((case-fold-search nil))
(with-temp-buffer
  (insert text)
  (save-excursion
(goto-char (point-min))
(while (re-search-forward "\\([^La]\\)TeX" nil t)
  (replace-match (concat "\\1" my/tex-html-string
  (save-excursion
(goto-char (point-min))
(while (re-search-forward "LaTeX" nil t)
  (replace-match my/latex-html-string)))
  (setq text (buffer-string))
#+end_src

And, finally:

#+begin_src emacs-lisp
  (add-to-list 'org-export-filter-plain-text-functions 
#'my/latex-string-html-filter)
#+end_src

Fun fact. Donald Knuth explains in the first chapter of his /TeX book/,
"The Name of the Game", the origin of the term TeX, and why it is
formatted that way:

#+begin_quote
English words like `technology' stem from a Greek root beginning with
the letters τεχ...; and this same Greek word means /art/ as well as
technology.

[...]

Insiders pronounce the χ of TeX as a Greek chi, not as an `x', so that
TeX rhymes with the word blecchhh. It's the `ch' sound in Scottish words
like /loch/ or German words like /ach/; it's a Spanish `j' and a Russian
`kh'. 

[...]

On the other hand, it's important to notice another thing about TeX's
name: The `E' is out of kilter. This logo displaced `E' is a reminder
that TeX is about typesetting, and it distinguishes TeX from other
system names. [...] The correct way to refer to TeX in a computer file,
or when using some other medium that doesn't allow lowering of the `E',
is to type `TeX'. Then there will be no confusion with similar names,
and people will be primed to pronounce everything properly.
#+end_quote

Best regards,

Juan Manuel 

Re: Unable to configure emacs 27.2 to use org 9.5

[Juan Manuel Macías]

Hi Detlef,

Detlef Steuer writes:

> I have installed 9.5 with package-install in a clean emacs session,
> it is shown as installed, too, but whatever I try, my org-version is
> shown as 9.4.6, which is included in 27.2.
> (I assume, and therefore citeproc unavailable)

Have you looked in your elpa directory if you see this path: .../elpa/org-9.5/?

Have you tried uninstalling Org and reinstalling it?

Best regards,

Juan Manuel 

-- 
--
------
Juan Manuel Macías 

https://juanmanuelmacias.com/

Fancy underlines in Org to LaTeX

[Juan Manuel Macías]

Hi,

A very interesting LaTeX package, soulpos (by Javier Bezos), has
recently been uploaded to CTAN, which allows you to define personalized
underlining styles in a very free way:

https://www.ctan.org/pkg/soulpos

I have tried to adapt its use to Org, so I am attaching a small test
document here. In the preamble I have defined a command \myuline (with
the xparse syntax), with five different values for \uline:

- \myuline the default value, a single underline,

- \myuline[ul1], \myuline[ul2], \myuline[ul3] and \myuline[ul4], four
different underline styles, taken from the examples in the soulpos
documentation.

See this screenshot: https://i.imgur.com/UK6W8sl.png

Best regards,

Juan Manuel

--
--
--
Juan Manuel Macías

https://juanmanuelmacias.com/



soulpos-test.org
Description: Lotus Organizer

[tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt)

[Juan Manuel Macías]

Hi,

Sometimes I need to export an Org document with certain "meta-comments",
so I wrote this export filter to export those footnotes that start with
the string "!annot" to:

- [LaTeX] PDF annotations (requires the pdfcomment LaTeX package),

- [odt] Comments.

#+BIND: org-export-filter-footnote-reference-functions 
(my-custom-filters/export-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
  (defun my-custom-filters/export-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!annot" text))
   (replace-regexp-in-string "footnote{\s*!annot\s*"
 
"pdfcomment[icon=Note,opacity=0.4,color=gray,date]{"
 text))
  ((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!annot" text))
   (with-temp-buffer
 (insert text)
 (let* ((from (save-excursion
(goto-char (point-min))
(re-search-forward "!annot" nil t)
(point)))
(to (save-excursion
  (goto-char from)
  (re-search-forward "" nil t)
  (- (point) 9)))
(contents (buffer-substring-no-properties from to)))
   (delete-region (point-min) (point-max))
   (insert (concat
""
(car (plist-get info :author))
""
;; date in iso format
(org-odt--format-timestamp (plist-get info :date) nil t)
""
contents
" "))
   (setq text (buffer-string)))
#+end_src

Example:

Lorem[fn:1] ipsum dolor sit amet,

[fn:1] !annot This note will be exported as an annotation...

And this other filter does not export the notes that start with the
string "!noannot" (although it could be merged with the previous
filter):

#+BIND: org-export-filter-footnote-reference-functions 
(my-custom-filters/disable-footnote-as-annotation)
#+begin_src emacs-lisp :exports results :results none
  (defun my-custom-filters/disable-footnote-as-annotation (text backend info)
(interactive)
(cond ((and (org-export-derived-backend-p backend 'latex)
(string-match-p "!noannot" text))
   (replace-regexp-in-string ".+"
 ""
 text))
  ((and (org-export-derived-backend-p backend 'odt)
(string-match-p "!noannot" text))
   (replace-regexp-in-string ".+"
 ""
 text
#+end_src

Best regards,

Juan Manuel

--
--
--
Juan Manuel Macías --

https://juanmanuelmacias.com/

Re: Sub-figures in Org Mode

[Juan Manuel Macías]

Hi Jason,

Jason Ross  writes:

> Are there any workarounds people use to create subfigures in Org Mode
> when exporting to LaTeX? Example output:

In this thread I explain a procedure to export images as subfigures
using org links: https://list.orgmode.org/87mty1an66@posteo.net/

Best regards,

Juan Manuel 

A quick LaTeX reference guide in Org

[Juan Manuel Macías]

Hi,

The TeXstudio editor includes a comprehensive LaTeX reference guide in
HTML
(https://github.com/texstudio-org/texstudio/blob/master/utilities/latexhelp.html).
I have converted it to Org with Pandoc (and then cleaned it up and fixed
some broken links). It can be downloaded here:
https://cloud.disroot.org/s/krGSf7TmFZRiyZL

I think it may be useful for a quick LaTeX query. You could even use
org-ql and define a function like this:

(require 'org-ql)
(defun my-latex-apropos ()
  (interactive)
  (let ((regexp (if (not (current-word t t))
(read-from-minibuffer "Find (regexp): ")
  (read-from-minibuffer "Find: " (current-word t t)
(org-ql-search
  "/path-to/latexreference.org"
  `(regexp ,regexp

Best regards,

Juan Manuel 

Re: A quick LaTeX reference guide in Org

[Juan Manuel Macías]

Tim Cross writes:

> There is also a latex2e.info package 'out there'. I have it installed
> from my Linux distro and find being able to run (info)Latex very useful
> as a basic reference. 

Thank you very much for this information, I did not know it. I just saw
that there is a `latex2e-help-texinfo' package in my distro (Arch), not in
the official repositories but in the AUR. Very useful.

Best regards,

Juan Manuel 

Re: A quick LaTeX reference guide in Org

[Juan Manuel Macías]

Eric S Fraga writes:

> It's in CTAN, the official (?) LaTeX repository.

I just saw it now there. CTAN is an infinite bazaar :-)

By the way, in CTAN there is also the /TeX for the Impatient/ book (I
love that title), which is a very good manual for programming at low
level in TeX/plainTeX: https://www.ctan.org/pkg/impatient (it's more
concise than Knuth's /TeX book/, which I bought on paper a long time
ago, for 'historical' reasons...)

Best regards,

Juan Manuel

Re: Support for tabularray in LaTeX export

[Juan Manuel Macías]

Vikas Rawal writes:

>>
>> Hi Vikas,
>>
>> You can define a modified version of `org-latex--org-table',
>> adding a new LaTeX attribute `:options'. Something like this:
>
> Is there a case for incorporating this in orgmode itself? There is some 
> general utility for this in my view.

I can prepare a patch based on that code, if you consider it useful
(https://list.orgmode.org/87ilzjgyqg@posteo.net/)

Best regards,

Juan Manuel 

[patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Hi,

The `:options' attr. allows adding an optional argument with various
table options (between brackets in LaTeX export), since certain tabular
environments, such as `longtblr' of the `tabularray' LaTeX package,
provides this structure (see:
https://list.orgmode.org/CALtzAB1yM+uG_xHghCxTLRX5mgbzNvT5+PO=duabb28ncsv...@mail.gmail.com/#r)

Example:

#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
#+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}

==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet}]{colspec = 
{XXX}, width = 0.85\linewidth}

Best regards,

Juan Manuel

>From 9b51d999029f91adc93a6009bc3ddf56bba7ba4a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Tue, 26 Oct 2021 12:29:55 +0200
Subject: [PATCH] ox-latex.el: add `options' latex attribute to tables

* lisp/ox-latex.el (org-latex--org-table): The `:options' LaTeX
attribute allows adding an optional argument (\begin{env}[opt]), since
certain tabular environments, such as longtblr, accept optional
arguments.
---
 lisp/ox-latex.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..409d92164 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3314,6 +3314,7 @@ This function assumes TABLE has `org' as its `:type' property and
 `table' as its `:mode' attribute."
   (let* ((attr (org-export-read-attribute :attr_latex table))
 	 (alignment (org-latex--align-string table info))
+ (opt (org-export-read-attribute :attr_latex table :options))
 	 (table-env (or (plist-get attr :environment)
 			(plist-get info :latex-default-table-environment)))
 	 (width
@@ -3343,8 +3344,9 @@ This function assumes TABLE has `org' as its `:type' property and
 		(format "\\end{%s}" table-env)
 		(and fontsize "}"
  (t
-  (let ((output (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
+  (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
 			table-env
+(if opt (format "[%s]" opt) "")
 			width
 			alignment
 			contents
-- 
2.33.0

Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Hi Vikas,

Vikas Rawal writes:

> This is excellent. There is only one improvement that I would like you to 
> consider. Is it possible to allow multiple ":options " lines that are 
> appended when exported to
> +latex? Something like this:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align colspec = {XXX}, width = 0.85\linewidth
> #+ATTR_LATEX: :options remark{Note} = {Lorem ipsum dolor sit amet}
> #+ATTR_LATEX: :options remark{Source} = {The source of data}
>
>  ==> \begin{longtblr}[remark{Note} = {Lorem ipsum dolor sit amet},
>   remark{Source} = {The source of data}]{colspec = {XXX}, 
> width = 0.85\linewidth}
>
> This would be more elegant since table notes can be elaborate and putting 
> them all in one line would make them unwieldy.
>
> At the moment, only the last ":options" line is considered.

The normal behavior is that you cannot put more than one property
`:foo', because in that case only the value of the last one is added
when exporting to LaTeX (ther is a property list where each property has
a string value).

I can think of a somewhat tricky solution, in case you want to adapt it
to your use case:

First, you need to convert a plist to an alist (source:
https://caiorss.github.io/Emacs-Elisp-Programming/Elisp_Programming.html#sec-1-8-4):

#+begin_src emacs-lisp
(defun plist->alist (plist)
  (if (null plist)
  '()
(cons
 (list (car plist) (cadr plist))
 (plist->alist (cddr plist)
#+end_src

And this would be the modified function:

#+begin_src emacs-lisp
(defun org-latex--org-table (table contents info)
  "Return appropriate LaTeX code for an Org table.

TABLE is the table type element to transcode.  CONTENTS is its
contents, as a string.  INFO is a plist used as a communication
channel.

This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
  (let* ((attr (org-export-read-attribute :attr_latex table))
 (alignment (org-latex--align-string table info))
 ;; various `:options' props  <== modified from here
 (attr-alist (plist->alist attr))
 (options-list)
 (options-str (progn
(mapc (lambda (m)
(when (eq (car m) :options)
  (add-to-list 'options-list (cdr m
  attr-alist)
(mapconcat (lambda (x) (mapconcat 'identity x "")) 
options-list " ")))
  < == to here
 (table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
 (width
  (let ((w (plist-get attr :width)))
(cond ((not w) "")
  ((member table-env '("tabular" "longtable")) "")
  ((member table-env '("tabu" "longtabu"))
   (format (if (plist-get attr :spread) " spread %s "
 " to %s ")
   w))
  (t (format "{%s}" w)
 (caption (org-latex--caption/label-string table info))
 (above? (org-latex--caption-above-p table info)))
(cond
 ((member table-env '("longtable" "longtabu"))
  (let ((fontsize (let ((font (plist-get attr :font)))
(and font (concat font "\n")
(concat (and fontsize (concat "{" fontsize))
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
 (org-string-nw-p caption)
 (concat caption "\n"))
contents
(and (not above?)
 (org-string-nw-p caption)
 (concat caption "\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"
 (t
  (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
;; modified here
(if options-list (format "[%s]" options-str) "")
width
alignment
contents
table-env)))
(org-latex--decorate-table output attr caption above? info))
#+end_src

Pleas tell me if it works for you.

Best regards,

Juan Manuel 

Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Vikas Rawal writes:

> This still seems to exporting the second "options" value only.

Do you still keep this line in your init:

(advice-add 'org-latex--org-table :override #'my/org-latex--org-table) ?

If so, rename the function from my previous email as
`my/org-latex-org-table' and re-evaluate it. And comment the old
`my/org-latex-org-table'.

The new function works well for me. E.g. this:

#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align align
#+ATTR_LATEX: :options options 1
#+ATTR_LATEX: :options options 2
#+ATTR_LATEX: :options options 3
#+ATTR_LATEX: :options options 4
| lorem | lorem | lorem | lorem | lorem |
|---+---+---+---+---|
| ipsum | ipsum | ipsum | ipsum | ipsum |

produces in LaTeX this:

\begin{longtblr}[options 1 options 2 options 3 options 4]{align}
lorem & lorem & lorem & lorem & lorem\\
\hline
ipsum & ipsum & ipsum & ipsum & ipsum\\
\end{longtblr}

Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Juan Manuel Macías writes:

> \begin{longtblr}[options 1 options 2 options 3 options 4]{align}

PS: I think the options should be separated by commas. In this
case, it's necessary to replace the line:

(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list " ")))

by this line:

(mapconcat (lambda (x) (mapconcat 'identity x "")) options-list ",")))

Best regards,

Juan Manuel 

Re: Introducing Org-transclusion

[Juan Manuel Macías]

Hi Noboru,

Noboru Ota writes:

> I would like to introduce an add-on package I have been developing for
> about one year and ask for discussion / advice.
>
> The package is named "Org-transclusion", and is available on GitHub at
> https://github.com/nobiot/org-transclusion.  Simply put, it lets you
> insert a copy of text content via a file link or ID link within an Org
> file.  The GitHub repository contains links short video presentations
> and documentation in detail.

I installed your package a few months ago and I have to say that it
works quite well, although I have not had, at the moment, the
opportunity to make intensive use of it. What I can say is that the
concept seems very interesting to me. Very nice package.

Best regards,

Juan Manuel 

Re: Sub-figures in Org Mode

[Juan Manuel Macías]

Hi Jason, sorry for the late reply.

Jason Ross writes:

> I'm looking at declaring a "figure" block the way you are, but
> `org-element-map'ing over the links inside the block and processing them
> with the "normal" link-handling machinery. That way, image options work
> the same way in a subfigure as they do normally.

I really like your idea, and it's more consistent with the Org syntax,
since (as you say) the images behave like images and it is not necessary
to enter the options via marks within the link description, which is somewhat
hacky. I think your idea could also be adapted to LaTeX (and HTML)
backends... 

Best regards,

Juan Manuel 

Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Hi Nicolas,

Nicolas Goaziou writes:

> Thank you.
>
> Could you also document it in the manual?

Of course, tomorrow I will upload an updated version of the patch with
the documentation in the manual. Should I also add an entry in ORG-NEWS,
in "Version 9.6" node?

Best regards,

Juan Manuel 

Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables

[Juan Manuel Macías]

Hi Nicolas,

Nicolas Goaziou writes:

> Good idea. Thanks.

Attached here the updated patch.

Best regards,

Juan Manuel 
>From fc9062caf43956ac68b72f16afbd5584ec84e687 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Thu, 4 Nov 2021 21:38:26 +0100
Subject: [PATCH] ox-latex.el: add `options' latex attribute to tables

* lisp/ox-latex.el (org-latex--org-table): The `:options' LaTeX
attribute allows adding an optional argument (`\begin{env}[opt]'),
since certain tabular environments, such as `longtblr', accept optional
arguments.
* doc/org-manual.org (Tables in LaTeX export): this feature in the manual.
* etc/ORG-NEWS (New :options attribute when exporting tables to
LaTeX): this feature in `ORG-NEWS'.
---
 doc/org-manual.org |  9 +
 etc/ORG-NEWS   | 14 ++
 lisp/ox-latex.el   |  4 +++-
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index af88b8506..50cdb9101 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13572,6 +13572,14 @@ include:
   The LaTeX export back-end uses these attributes for regular tables
   to set their alignments, fonts, and widths.
 
+- =:options= ::
+
+  The =:options= attribute allows adding an optional argument with a
+  list of various table options (between brackets in LaTeX export),
+  since certain tabular environments, such as =longtblr= of the
+  =tabularray= LaTeX package, provides this structure. For example:
+  =:options remark{Note}={note},remark{Source}={source}=.
+
 - =:spread= ::
 
   When =:spread= is non-~nil~, the LaTeX export back-end spreads or
@@ -19770,6 +19778,7 @@ moves across a special context.
   (add-to-list 'org-tab-first-hook 'yas/org-very-safe-expand)
   (define-key yas/keymap [tab] 'yas/next-field)))
   #+end_src
+
 ** Using Org on a TTY
 :PROPERTIES:
 :DESCRIPTION: Using Org on a tty.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index d73d0d3c3..626e19335 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -53,6 +53,13 @@ structures is supported.  Storing references between different
 variables is also supported (see =:inherit= key in
 ~org-persist-register~).
 
+*** New :options attribute when exporting tables to LaTeX 
+
+The =:options= attribute allows adding an optional argument with a
+list of various table options (between brackets in LaTeX export),
+since certain tabular environments, such as =longtblr= of the
+=tabularray= LaTeX package, provides this structure.
+
 ** New functions and changes in function arguments
 
 *** New function ~org-element-cache-map~ for quick mapping across Org elements
@@ -1555,6 +1562,7 @@ the headline to use for making the table of contents.
 ,* Another section
 ,#+TOC: headlines 1 :target "#TargetSection"
 #+end_example
+
 ** New functions
 *** ~org-dynamic-block-insert-dblock~
 
@@ -1845,6 +1853,7 @@ CIDER version which has not =sesman= integrated, only has
 (dissoc Clojure 'JVM)
 (conj clojurists "stardiviner")
 #+end_src
+
 *** Add ~:results link~ support for Babel
 
 With this output format, create a link to the file specified in
@@ -1863,14 +1872,17 @@ wget -c "https://ben.akrin.com/crackzor/crackzor_1.0.c.gz";
 #+begin_src js :session "*Javascript REPL*"
 console.log("stardiviner")
 #+end_src
+
 *** Add ~:session~ support of ob-js for Indium
 #+begin_src js :session "*JS REPL*"
 console.log("stardiviner")
 #+end_src
+
 *** Add ~:session~ support of ob-js for skewer-mode
 #+begin_src js :session "*skewer-repl*"
 console.log("stardiviner")
 #+end_src
+
 *** Add support for links to LaTeX equations in HTML export
 Use MathJax links when enabled (by ~org-html-with-latex~), otherwise
 add a label to the rendered equation.
@@ -1957,6 +1969,7 @@ you should expect to see something like:
 #+BEGIN_EXAMPLE
   ,#+STARTUP: shrink
 #+END_EXAMPLE
+
 *** Allow to filter by tags/property when capturing colview
 
 You can now use =:match= to filter entries using a todo/tags/properties
@@ -2339,6 +2352,7 @@ To use =vertica= in an sql =SRC_BLK= set the =:engine= like this:
   SELECT * FROM nodes;
   ,#+END_SRC
 #+END_EXAMPLE
+
  C++: New header ~:namespaces~
 
 The new ~:namespaces~ export option can be used to specify namespaces
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3e3967033..409d92164 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3314,6 +3314,7 @@ This function assumes TABLE has `org' as its `:type' property and
 `table' as its `:mode' attribute."
   (let* ((attr (org-export-read-attribute :attr_latex table))
 	 (alignment (org-latex--align-string table info))
+ (opt (org-export-read-attribute :attr_latex table :options))
 	 (table-env (or (plist-get attr :environment)
 			(plist-get info :latex-default-table-environment)))
 	 (width
@@ -3343,8 +3344,9 @@ This function assumes TABLE has `org' as its `:type' property and
 		(format "\\end{%s}" table-env)
 		(and fontsize "}"
  (t
-  (let ((output (format "\\begin{%s}%s{%s}\n%s\\end{%s}"
+  (let ((output (format "

A function to include a PDF with LaTeX commands for specific pages

[Juan Manuel Macías]

Hi,

Sometimes I need to include a pre-compiled PDF in my main document. Of
course, this can be done simply with the `pdfpages' LaTeX package. If we
want to insert a complete PDF, it would be enough to add:

#+latex: 
\includepdf[pages=-,noautoscale=true,page-command={\thispagestyle(plain}]{file.pdf}

But the 'problem' arises when we want to add multiple page-commands such
as \label{...} and \index{...} to specific pages of the PDF. It would
have to be done explicitly by putting multiple lines of \includepdf{etc},
which can be a bit monotonous. To simplify that scenario it occurred to
me to write this function:

(my-org/insert-pdfpages PDF &optional PAGE-COMMANDS-ALL PAGE-COMMANDS-PER-PAGE)

PAGE-COMMANDS-ALL is the command that should be applied to all pages;
PAGE-COMMANDS-PER-PAGE must be a list, with the page number and the
commands for that page (a possible improvement could be to allow adding
page ranges...). For example:

#+LaTeX_Header: \usepackage{pdfpages}

#+begin_src emacs-lisp :exports results :results latex
  (my-org/insert-pdfpages "file.pdf" "\\thispagestyle{plain}" '((2 
"\\label{label1}")
(3 
"\\label{label2}\\index{index1}")
(7 
"\\label{label3}\\index{index2}")
(12 
"\\index{index3}")))
#+end_src

Only tested on GNU/Linux; mupdf-tools is required, to be able to get the
number of pages of the PDF. And the function:

#+begin_src emacs-lisp
  (defun my-org/insert-pdfpages (pdf &optional page-commands-all 
page-commands-per-page)
(let ((pdfpages-result))
  (setq pdfpages-result
(with-temp-buffer
  (let ((counter 0)
(pags-pdf (shell-command-to-string
   (format "mutool info %s | grep '^Pages' | cut -d 
' ' -f 2"
   pdf
(dotimes (num (string-to-number pags-pdf))
  (insert (concat
   "\n\\includepdf[pages={"
   (number-to-string
(setf counter (+ counter 1)))
   "},"
   "noautoscale=true,"
   (if page-commands-all
   (format "pagecommand={%s}" page-commands-all) "")
   "]{"
   pdf
   "}"
  (if page-commands-per-page
  (mapc (lambda (x)
  (let ((pag (number-to-string (car x)))
(str (cadr x)))
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward (concat "pages={" pag 
"}") nil t)
(if (re-search-forward "\\(pagecommand={\\)")
(replace-match (concat "\\1" "\\" str ","))
  (re-search-forward "\\(\\[\\)" nil t)
  (replace-match (concat "\\1" "pagecommand={" 
"\\" str "},")))
page-commands-per-page)
"")
  (buffer-string)))
  pdfpages-result))
#+end_src

Best regards,

Juan Manuel 

Re: whitespace in org source files

[Juan Manuel Macías]

Hi,

excalamus--- via "General discussions about Org-mode." writes:

> I've not used the email contribution style before and have had
> whitespace issues in the past with GitHub PRs.  I typically run
> whitespace-cleanup with the before-save-hook which changes tabs to
> spaces.

I agree with Tim that running whitespace-cleanup is usually a bad idea
within a Git repository. I also have, like you, whitespace-cleanup
hooked to before-save-hook, like a relic of my first Emacs setups. In
case it helps, I have added to my init this function:

(defun my-whitespace-cleanup-no-git ()
(let ((buf (buffer-file-name)))
  (when (not (vc-git-responsible-p buf))
(whitespace-cleanup

and then:

(add-hook 'before-save-hook 'my-whitespace-cleanup-no-git)

Best regards,

Juan Manuel 

Re: Should be possible to export list items emphasized by default?

[Juan Manuel Macías]

Ypo writes:

> /1. Introduction/
>
> It doesn't work as a list item
>
> 1. /Introduction/
>
> It works as a list item but, when exporting, it doesn't export the
> whole item emphasized.

If I have understood correctly, you want to export the label emphasized
as well, not just the item content... It does not make much sense to
emphasize a label within a list by direct formatting: the style of the
labels must be homogeneous and consistent. On the other hand, the style
for a list environment must be modified in LaTeX globally. The easy way
is to use the enumitem package. For example, if you want all labels in
italics:

#+LaTeX_Header: \usepackage{enumitem}

#+ATTR_LaTeX: :options [label=\emph{\arabic*}.]
1. /foo/
2. /bar/
3. /baz/

The :options attribute pass an optional argument to the `enumerate'
environment, with all the options for the environment (a list of comma
separated keyval values):

\begin{enumerate}[label=\emph{\arabic*}.]
\item \emph{foo}
\item \emph{bar}
\item \emph{baz}
\end{enumerate}

See: https://www.ctan.org/pkg/enumitem

Best regards,

Juan Manuel

Re: insert automatically a reference to a section header and a link

[Juan Manuel Macías]

Stefan Nobis writes:

> Hmmm... for me, the default way to link to headings is just fine, I
> seldom need more control over the generated labels:
>
> #+begin_src org
>   ,* Intro
>
>   Lorem ipsum dolor sit amet...
>
>   ,* Another section
>
>   As seen in [[*Intro]] there is not much to say.
> #+end_src

Completely agree. I also tend to use `org-super-link'
(https://github.com/toshism/org-super-links). It can be run with
helm-org-ql, so if there are a lot of headings in the document, I just
have to navigate through them using helm-org-ql, and insert a link at
point to the chosen candidate. And in the destination header a back link
is also inserted.

Best regards,

Juan Manuel 

Re: insert automatically a reference to a section header and a link

[Juan Manuel Macías]

Stefan Nobis writes:

> #+begin_src emacs-lisp
>   (defun sn/ox-latex-filter-special-ref-vref (text backend info)
> (when (org-export-derived-backend-p backend 'latex)
>   (replace-regexp-in-string "ref{" "vref{" text)))
>   
>   (add-to-list 'org-export-filter-link-functions 
> #'sn/ox-latex-filter-special-ref-vref)
> #+end_src

In Org 9.5 there is a new variable `org-latex-reference-command'. You
can do something like:

(setq org-latex-reference-command "\\vref{%s}")

Best regards,

Juan Manuel 

org-critical-edition (new version)

[Juan Manuel Macías]

Hi all,

For philologists who might be interested, I have uploaded a new version
of my package `org-critical-edition', with some new features, such as the
ability to use multi-level nested critical notes:

https://gitlab.com/maciaschain/org-critical-edition

It occurred to me to write org-critical-edition as a sort of org-centric
alternative to TEI-XML for the semantic markup of literary texts. My
idea is for a more scholar-friendly, human-readable tool.

Here's a screenshot of a LaTeX/reledmac export sample:
https://i.imgur.com/S9MXzIA.png

Feedback welcome.

Best regards,

Juan Manuel 

-- 
--
--
Juan Manuel Macías 

https://juanmanuelmacias.com/

Dired images in an Org buffer

[Juan Manuel Macías]

Hi,

I don't like image-dired thumbnails, so I wrote this function to preview all
images in a directory in an Org buffer. I share it here, in case it is
useful to someone:

#+begin_src emacs-lisp
  (defun my-org-img-dired-preview ()
(interactive)
(if (not (derived-mode-p 'dired-mode))
(error "not in dired")
  (let* ((dir-name default-directory)
 (buf (concat "*" dir-name "--images *")))
(setq my-img-dired-list nil)
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward "\\.png\\|\\.jpg\\|\\.tif" nil t)
(let* ((img-path (dired-get-filename)))
  (add-to-list 'my-img-dired-list img-path t
(when (get-buffer buf)
  (kill-buffer buf))
(get-buffer-create buf)
(set-buffer buf)
(org-mode)
(let ((img-list (mapconcat (lambda (el)
 (let ((link (concat "[[file:" el "]]")))
   link))
   my-img-dired-list
   "\n\n"))
  (img-num (number-to-string
(length my-img-dired-list
  (insert (concat "* Images in " dir-name "\n\n"))
  (insert (concat img-num " files:\n\n"))
  (insert img-list)
  (org-toggle-inline-images))
(pop-to-buffer buf)
(beginning-of-buffer

  (with-eval-after-load 'dired
(define-key dired-mode-map (kbd "P") 'my-org-img-dired-preview))
#+end_src

Best regards,

Juan Manuel 

Re: "Orgdown", the new name for the syntax of Org-mode

[Juan Manuel Macías]

Hi,

I believe (IMHO) that it does not make much sense to separately name the
Org Mode syntax (as a markup language). That would only generate
confusion among users. Furthermore, 'Org Mode', as a whole, is already a
sufficiently recognized and popular name, even outside the GNU Emacs
community. A single name is best remembered. More than one name means
atomization. For example: there is TeX (the typographic engine) and TeX
(the programming language for that engine). And there has never been any
conflict.

On the other hand, drawing a dividing line between Org (a lightweight
markup language) and Org (a GNU Emacs major mode) as if both things
could exist separately is an illusory exercise. I mean, that the
Org's global experience is the fusion of both things. 

I migrated from Markdown to Org Mode a long time ago not because I was
looking for a new and best lightweight markup language but because Org
provides me with a complete and quite sophisticated and productive work
environment. An environment that includes, yes, its own syntax, but all
within Emacs, which is where makes sense. I do not know if it is an
emergent quality, but I see Org, in many ways (and with all its
synapses) as an interface for Emacs.

Best regards,

Juan Manuel 

Re: "Orgdown", the new name for the syntax of Org-mode

[Juan Manuel Macías]

Joost Kremers writes:

> Why not just use the term "Org markup"?  It's descriptive and should be
> understandable to people familiar with the concept of markup languages.

This. 'Org markup language' and 'Org Syntax' are obvious and natural
terms that can easily be inferred from the Org manual. Honestly I don't
see much point in coming up with new names for a concept which is
already transparent and self-explanatory. It is something I find
unnecessary and baroque.

Best regards,

Juan Manuel

Re: "Orgdown", the new name for the syntax of Org-mode

[Juan Manuel Macías]

Marcin Borkowski writes:

> Quite the contrary.  The amount of confusion between TeX (engine)/TeX
> (language)/TeX (distro)/TeX-aware text editor/LaTeX (whatever) among
> novice/casual users has always been terrible.

It's natural when those novice/casual users approach something that is
new to them, but nothing invincible when they want to learn. The "TeX"
ecosystem is not trivial, but I think that all, or almost all of us,
understand each other when things like 'TeX/LaTeX code', 'TeX engine',
'LaTeX format', etc. are said. If the TeX language were somewhat
self-contained and widely used outside of TeX, I would see OK that the
language had its own name. But, since the TeX language is something that
almost only TeX understands (roughly said), I think the economy wins
here (IMHO). I don't see how we could improve everything by having half
a dozen more exotic names.

Best regards,

Juan Manuel 

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Hi,

Uwe Brauer writes:

> Hi
>
> I want to obtain a latex file that contains
>
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
>
> However when I add 
> \textcolor{red}{$\delta \phi = \frac{2 m}{R}$}
>
> To an org file and export it as Latex, the construct ends up like this
>
>
> \textcolor{red}\{\(\delta \phi = \frac{2 m}{R}\)\}
>
> Which is wrong.
>
> Any ideas how to obtain the correctly exported expression?

Not exactly related, but if it helps, I have defined this custom link
for colored text segments:

(NB: I apply two colors for `:face', because normally I use two themes,
one clear for the day and another dark for the night hours: when my dark
theme is active, apply a background color. But you can simplify that part to
your liking):

(org-link-set-parameters "color"
  ;; :display 'full
   :face (lambda (path) (when path
  (if (string= (face-attribute 
'default :background) "#282c34")
  `(:foreground ,path 
:background "#F5f5f5")
`(:foreground ,path
   :export (lambda (path desc format)
 (cond
  ((eq format 'latex)
   (concat
"\\textcolor{"
path
"}{" desc "}"))
  ((eq format 'html)
   (format "%s"
   path desc)

The link would then look like this, adapting John's solution using a
LaTeX export snippet:

[[color:red][@@latex:$\delta \phi = \frac{2 m}{R}$@@]]

Best regards,

Juan Manuel 

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Uwe Brauer writes:

> Thanks, right now, I don't need links but it is good to know that there is a 
> way to use them.

It's just a way of using links to produce different strings, depending
on the export format (LaTeX, HTML...). I use them quite a bit for text
segments as \foreignlanguage{}{}, \textcolor{}{}, etc. Anyway, that
specific link does not have any associated link action.

Best regards,

Juan Manuel 

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Juan Manuel Macías]

Tom Gillespie writes:

> Karl,
>The exact naming of a thing is nearly always the most contentious
> step in trying to promulgate it. In my own field we can easily get all
> parties to agree on a definition, but they refuse to budge on a name.
> As others have said, I wouldn't worry about kibitizing over the name.
>
> I would however worry about the larger negative reaction. From my
> perspective I think the issue is that there are many efforts working
> toward a formalized specification for Org syntax and Org mode
> functionality, and some of those stakeholders who have invested
> significant effort may feel blindsided by a public declaration
> announcing Orgdown because they were not consulted and not
> made aware that you were working on it.
>
> I appreciate the amount of work that you have put in, I have devoted
> hundreds of hours to working on an alternate implementation of org
> in Racket that uses a formal ebfn in hopes that others will be able
> to use it as a guide and as a way to talk formally about how Org
> parsers and implementations should behave.
>
> It would thus be easy for me to say that your approach has put the
> cart before the horse, because there are countless nuances in the
> specification for Org syntax which must be addressed before any
> levels of org compliance can be specified, otherwise the behavior
> between levels will be inconsistent.
>
> If I were to say this, it would not be fair to you at all. The ideas
> and motivation for Orgdown are vital and important. You have put
> in enormous thought and effort, all because you care about Org
> and want to see it succeed.
>
> The issue is that any shared specification for Org syntax is
> fundamentally about how to coordinate as a community.
> The way that Orgdown was presented to the community feels
> (to me) like it is being imposed top down or coming from an
> individual source, not from an open and visible community
> process (the subject of your original email reads as a declaration
> in english, and thus can be quite off putting, though I know that
> was not the intention).
>
> I personally haven't bothered with promulgation because I think
> that we are not technically ready as a community to approach
> outreach to other developers in a way that we can succeed.
>
> The good news is that all of this can co-exist if we want it to,
> but we need to be clear about our objectives as a community.
>
> To me these objectives are as follows (and I would love
> to hear from others about additional or alternate objectives).
>
> 1. To never fracture Org syntax so as to avoid the nightmare
> of markdown flavors. (This means being able to say clearly
> as a community that a parser is out of compliance and that
> it is up to the user to fix their files. The ruby org parser used
> by Github is a major issue here.)
> 2. To provide a clear specification for what graceful degradation
> looks like when parsing Org syntax if a parser does not support
> some portion of that syntax (e.g. should property drawer lines
> be excluded or rendered as plain text?).
> 3. Provide a solid basis on which further formal specification
> can be built. (My interests in particular are around providing
> consistent semantics for org-babel blocks across languages
> so that babel implementations can clearly communicate what
> runtime features they support.)
>
> The approach for Orgdown can absolutely meet all three of
> these objectives, however in its current form Orgdown1 is not
> sufficiently well specified to avoid fracturing the syntax.
> This is because Org syntax is extremely complex (even the
> elisp implementation of Org mode is internally inconsistent)
> and there are edge cases where behavior will diverge if parsing
> of even the simplest elements is not fully specified.
>
> There are many ways to remedy this, however they require
> a more formal approach. A number of us are working to build
> technical foundations for such a formal approach, but I do not
> think that any of those projects are ready to be used to
> specify discrete levels of Org syntax parsing compliance.
>
> If I may, I would suggest that an Orgdown0 is something that
> could be well specified, but it would avoid parsing of markup
> altogether and only deal with the major element types. Parsing
> paragraphs and all the org objects is not something that can
> be done piecemeal. There are too many interactions between
> different parts of the syntax, and in some cases the existing
> specification desperately needs to be revisited due to the
> complexity that it induces or because it is underspecified.
> Of course this would make Orgdown0 fairly useless as a
> replacement for markdown, but at least it would be a start.

Everything you comment here seems very sensible to me.

Anyway I have to say that, in my case, the name 'orgdown' is not the
issue, but the underlying idea under the naming, whatever the name is.
IMHO, reduce Org to a markup language or, to put it somewhat
metaphorically

Re: how to export red colored TeX to latex

[Juan Manuel Macías]

Hi Eric,

Eric S Fraga writes:

> Very nice Juan!  I would find this use of links quite useful.

Thank you. Yes, org-link-set-parameters is quite productive, and
addictive in occasions! :-): I also have link types defined for somewhat
extravagant things, such as linking videos and music from the dlna
server of my raspberry...

Anyway, for format chunks of text in export I think
org-link-set-parameters is a good alternative to macros.

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi Denis and Ihor,

Ihor Radchenko writes:

> Denis Maier  writes:
>
>> Currently, org syntax doesn't officially seem to support intra-word 
>> emphasis. Am I missing something?
>
> intra-*word* works just fine for me.
>
> Best,
> Ihor

I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Ihor Radchenko writes:

> Denis Maier  writes:
>
>>> Can you create an example of such scenario and post it as a bug?
>>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>>> level.
>> To be clear: That's not an org bug. It's just that latex won't be able 
>> such a word. If | is a zero width space, the word "hyphen|ation" is not 
>> the same as "hyphenation".
>> 1. hyphenation
>> 2. hyphen|ation
>
> You are right for your example, but if we force the user to put
> *hyphen*|ation to create bold emphasis, it should not be any different
> compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the *hyphen*|ation
> gets exported as \textbf{hyphen}|ation keeping the zero width space.

-- 
I would say that they are very random cases, and therefore difficult to
reproduce. In the 'hyphenation' example, if we load the package
showhypehns, you see that:

/hyphen/​ation (with zero width sp)

and

\emph{hyphen}ation

they are cut in the same way. But differently from

hyphenation (without emphasis)

(compiled with LuaTeX).

Anyway, I have come across some curious cases. For example, a long time
ago I had defined a macro for text in other languages:

#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 
'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 
"\u200B" "@@latex:}@@") $2))

I needed to add before and after a zero width space, but doing so, the
shape of the text was altered. That can be reproduced with this example:

#+LaTeX_Header: \usepackage{showhyphens}
#+LaTeX_Header:\usepackage{lipsum,multicol}
#+LaTeX_Header:\usepackage[spanish]{babel}
#+LaTeX_Header: \def\example{\lipsum[1]}
#+LaTeX_Header: \def\zwsp{\char"200B{}}
#+OPTIONS: toc:nil

@@latex:\begin{multicols}{2}@@
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@
@@latex:\foreignlanguage{italian}​{\example}@@
@@latex:\end{multicols}@@

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Tom Gillespie writes:

> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane way to parse something
> like *hello world*/hrm/oh no*. The other issue is that this will
> degrade parsing performance because almost every
> character could precede the start of a markup section.
>
> I recommend anyone suggesting solutions try to implement
> something that can parse the markup unambiguously with
> lots of nasty test cases. You will likely find that it is impossible
> to consistently tokenize markup, and that you have to hand
> write a whole bunch of heuristics, making Org syntax even
> harder to implement correctly.
>
> Any solution that suggests extending how =/*~+_  can be
> used gets a hard no from me. I could see teaching other
> exporters how to interpret \emph{hello}world, but trying for
> to have any sane behavior for something like
> why *hello*world oh no a wild askterisk*
> is not worth it.

I believe, that emphasis marks are a part of Org that can be very
shocking to new users. I mean, there is a series of behaviors that seem
obvious and trivial in the emphasized text, but that in Org are not
possible out of the box, unless you configure
`org-emphasis-regexp-components'. Three quick examples. This in Org is
not possible out of the box:

#+begin_example
[/emphasis/]
¡/emphasis/!
¿/Emphasis/?
#+end_example

Nor is it possible ---out of the box--- to extend emphasis beyond a
certain number of lines. New users who come from other forms of markup
maybe expect the obvious to be something like:

some-text begin-emphasis whatever-is-in-between end-emphasis more-text

Over time one ends up seeing these things more as a feature than as a
bug :-) But those little inconsistencies make the Org syntax a bit ugly,
IMHO. I can't think of how to improve that, though.

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi Nicolas and all,

Nicolas Goaziou writes:

> I find zero-with spaces solution much more elegant. It also doesn't
> change current syntax, which is a big advantage.

I agree that zero width spaces work fine as a solution, but I think they
should not be understood as part of the syntax but as a punctual
(temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
zero width spaces can produce unexpected effects and modify the final
form of the text (at least in luatex). I also don't know if it would be
useful to remove all zero width spaces in the export process, because in
some cases the user may want to keep them, as I think Maxim commented in
a previous message.

As for the solution of using complementary marks ("//...//", etc.), I
think it would undermine consistency, as those marks would only be to
fix exceptions.

It's a tricky subject...

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Nicolas Goaziou writes:

> I'm suggesting to remove zero-width spaces contiguous to emphasis
> markers only. Therefore LaTeX process would npot see them. Other zero
> width spaces, e.g., inserted by user, are kept. AFAICT, the two last
> points you mention are not relevant with my proposal.
>
> Besides, they already part of the syntax, in some way. So that ship has
> sailed long ago.

I understand that it is too late to change certain things, but that is
not an impediment for me to continue to think that using the character
U+200B as a part (at least /de facto/) of the syntax is still shocking
and weird.

On the other hand, what was expected in Org would have been to have the
emphasis marks and at the same time have a universal escape character
for those emphasis marks. In the same way as I can write in markdown:
*foo* AND \*foo\*. In Org we have the emphasis marks but not the escape
character. That was probably the cause of many issues that are being
discussed here. But that means also entering the realm of assumptions.
Still, I wanted to leave an opinion on this question in particular.

Best regards,

Juan Manuel

On zero width spaces and Org syntax

[Juan Manuel Macías]

Hi all,

It is usually recommended, as you know, to insert a zero width space
character (Unicode U+200B) as a sort of delimiter mark to solve the
scenarios of emphasis within a word (for example, =/meta/literature=)
and others contexts where emphasis marks are not recognized (for example
=[/literature/]=). I believe that as a puntual workaround it is not bad;
however, I find it problematic that this character is part, more or less
de facto, of the Org syntax. For two main reasons:

1. It is an invisible character, and therefore it is difficult to
control and manage. I think it is not good practice to introduce this
type of characters implicitly in a plain text document.

2. It is more natural that this type of space characters are part of the
'output' and not of the 'input'. In the input it is better to introduce
them not implicitly but through their representation. For example, in
LaTeX (with LuaTeX) using the command '\char"200B{}' (or '200b'),
'​' in HTML, etc.

In any case, as an implicit character, I do not see it appropriate for
the syntax of a markup language. The marks should be simply ascii
characters, IMHO. So what if Org had a specific delimiter mark for the
scenarios described above? For example, something like that:

#+begin_example

/meta/''literature

*meta*''literature

[''*literature*'']

#+end_example

WDYT?

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi Maxim,

Max Nikulin writes:

> More explicit markup leaves less room for ambiguities, and I like the
> idea due to this reason. On the other hand it diverges from principle
> of lightweight markup. The almost only special character in TeX is
> "\", HTML has three ones "&<>" with simple escape rules. Org uses many 
> special characters to avoid verbosity and requires some tricks to
> escape them. Markers like "\{" make Org more verbose but do not make
> it more strict, a lot of things still rely on heuristics.

Excellent explanation. Thanks for the clarification. 

> I have an idea what can be done when some special markup is required
> that is not fit into current syntax. Unfortunately some new constructs 
> should be introduced anyway: inline objects and multiline elements
> that represent simplified result of parsed Org structures:
>
> ((italic "intra") "word")
>
> wrapped with some markup. It should satisfy any special needs (and
> even should allow to create invalid impossible constructs). Maybe idea
> of combination of lightweight markup and low-level blocks better suits
> for some other project with more expressive internal representation.
> In Org it may become the most hated feature.

I really would like a solution in this direction. In LaTeX there is a
command called \protect (which has nothing to do with this topic and is
used for other things, but I like the 'protection' concept); we could
perhaps think of a type of mark to protect the 'usual' marks when syntax
consistency is compromised in some way by the context. Maybe something
like enclosing the normal marks between two double single quotes ''...''
---or a single set of single quotes before the leading marker--- as I
proposed in another thread:

#+begin_example
''*protected emphasis*''
#+end_example

Best regards,

Juan Manuel 

Re: On zero width spaces and Org syntax

[Juan Manuel Macías]

Hi Greg, thank you for your comment,

Greg Minshall writes:

> in fact, i am always queasy when i enter ZWNBSP in a .org (or any other)
> file.  some sort of "visible" sequence would be great.  backwards
> compatibility might be a problem.

Yes I agree. I think that in this case, a new mark would not compromise
backward compatibility, as this presumed new mark would do the same
function as zero width space: i.e. delimit to preserve emphasis. Of
course one could go on using a zero-width space, though I keep thinking
that this is rather a puntual workaround and should not form part of the
syntax.

> your last example
>
> : [''*literature*'']
>
> seems a bit of sleight-of-hand, though.  iiuc, text inside square
> brackets isn't highlighted currently, and ZWNBSP doesn't (afaict) turn
> on highlighting.  (maybe there's been recent discussion, modifications
> of this?)

The idea would be to use a kind of 'protection mark', to allow something
in a context where it is not allowed: a passport ;-). As the emphasis
marks are recognized before and after a single quote, I thought that
maybe a sequence of two single quotes could function here as a
protection mark (screenshot: https://i.imgur.com/cPIH9qa.png). For
example:

#+begin_example
| Some examples where emphasis marks are not allowed | Protected emphasis marks 
|
|+--|
| /meta/literature   | /meta/''literature   
|
| [/literature/] | [''/literature/'']   
|
| <*literature*> | <''*literature*''>   
|
| meta/*literature*  | meta/''*literature*  
|
#+end_example

With the protection marks we get (in LaTeX for example):

\emph{meta}literature
[\emph{literature}]
<\textbf{literature}>
meta/\textbf{literature}

Best regards,

Juan Manuel 

Re: On zero width spaces and Org syntax

[Juan Manuel Macías]

Tim Cross writes:

> I think I am in agreement regarding most of your points about the use of
> the zero-width character. I see it as a type of escape hatch which
> provides a solution in some less frequent situations. It is a somewhat
> clever kludge to enable markup in some situations not supported by the
> basic markup syntax I'm happy with its status as a kludge and would not
> want to see it become an official part of the syntax. Where we may
> differ is in whether we actually want to add inner word markup support
> at all. 
>
> I'm somewhat surprised and more than a little concerned at how much
> interest and focus on modifying the markup syntax of org the question of
> inner word markup has generated. This seems to be a symptom of a more
> general trend towards adding and extending org mode to meet the needs of
> everyone and I'm concerned this is overlooking the key strength of org
> mode - simplicity.
>
> Consider how many times we have had requests for inner word markup in
> the last 18 years. I've seen such requests only a very few times.
> Certainly not frequently enough to consider modification of the markup
> syntax to accommodate such a requirement.
>
> A key philosophy of org mode is simplicity - it makes the easy stuff
> simple and the hard stuff possible. The thing about simple solutions is
> that they will inevitably have limitations. If you don't want those
> limitations, then you use a more complex feature rich markup, such as
> Latex, HTML, XML etc. Ideally, your system will provide some escape
> hatches to allow you to do things not supported by the base markup
> syntax. Those escape hatches will usually be less convenient and often
> look quite ugly, but that is fine because they are an escape hatch
> which is used infrequently. Better still is if the system provides some
> way to make a specific escape hatch easier to use in a document (such as
> via a macro). The basic org markup syntax has worked remarkably well for
> 18 years. Nearly all the proposed additions or alterations to support
> inner word markup with complicate the syntax or introduce potential new
> ambiguities and/or complexity in processing to support a feature which
> has been rarely asked for and which has other, less convenient and often
> ugly, solutions which work.
>
> One of org's strengths has been the ability to export documents to
> multiple formats. One way this has been made possible is by keeping the
> markup syntax simple - a basic markup which is well supported by all
> export back ends. Once you start adding more complex markup support, you
> see a blow out of complexity in the export back ends. Worse yet, you get
> results which are surprising to the end user or which simply don't work
> correctly with some formats. to avoid this, it is critical to keep the
> markup syntax as simple and straight-forward as possible, even if that
> means some limitations on what can be done with the markup. 
>
> My vote is to simply maintain the status quo. Don't modify the syntax,
> don't make the zero space character somewhat special or processed in any
> special way during export. In short, accept that inner word markup has
> only limited support and if that is a requirement which is critical to
> your use case, accept that org mode may not be the right solution for
> your requirements. 

Thank you very much for the detailed and precise exposition of your
point of view. I appreciate it.

First of all, a point that I consider important and essential in this
and other debates that are generated here, is that there is no single
conception of Org that should prevail as (say) "the canon". Org is so
polyhedral and so multifaceted that there are as many conceptions of Org
as there are users of Org. Well, what I have said is in itself one more
conception of Org. But I assume that other users may think that Org is
not all the things that I say it is. At the end of the day, what matters
is only one thing, for on top of theories and doctrines: if Org is
useful to you and helps you to do your work, so great. A few months ago
(and I think I already shared it here) I finished the typesetting and
layout of a dictionary of almost 1000 pages, and I did it using a
workflow that I have developed which is a merge between Org/Org-Publish
and LuaTeX. And now, using the same method, I am working on an
ancient-Greek/Spanish bilingual critical edition. So I believe I'm not
suspicious of thinking that Org doesn't cover the needs of my workflow.

As for the matter of emphasis marks between words. I believe that this
is not the underlying problem, but rather the (little) inconsistency of
the markup on certain contexts. Think, for example, of a text where you
have to put many words in italics, enclosed between brackets. I don't
care if that type of text is 'typical' or 'non-typical', 'majority' or
'non-majority'. It is simply a kind of scenario absolutely legitimate
and feasible, and right now I could quote you more than a type of text
in that

Re: On zero width spaces and Org syntax

[Juan Manuel Macías]

Tom Gillespie writes:

> I don't mean to be dismissive of the suggestion, but a lot of
> time is spent on this list walking back ideas that have not
> had sufficient time put into understanding what the
> unintended consequences would be, so I wouldn't say
> that it is irresponsible, I would say instead that it lacks
> sufficient rigor and depth to be seriously considered. If you
> can add those to this proposal (e.g. in the form of a patch)
> then I suspect it would get a much warmer reception.

I am afraid that I am explaining myself wrong, and it is not my
intention that this matter becomes entangled to infinity.

I have no intention of proposing any patch on this. I'm not strongly
requesting this feature be included, and I am not interested in starting
a crusade to defend this (and as for lack of rigor and depth, well, it's your
subjective opinion). But it's more simple. Since a thread on these
questions came up recently, it occurred to me to suggest this idea as a
*possibility*, in case anyone could find it interesting and would like
to explore it. Nothing more. In fact, I don't think I was going to use
this probable feature much, if it was implemented, because for these
scenarios I prefer to use Org macros or other resources that I have
implemented for my workflow. But maybe users would prefer this to insert
a zero-whith space character (which is a tricky and quite ugly
workaround and should not be recommended). Or maybe not. I really don't
know. I don't know all Org users in the world, do you know them?

Anyway, I want to point out one thing, again. The scenarios and contexts
that are being described here are far from "very narrow use case". And I
don't think it's very appropriate to hide the lack of something with the
excuse that no one is going to need it. Intra-word emphasis is used (for
example) a lot in linguistics books and texts, grammars, etc. That you
*ignore* this fact does not mean that does not exist.

regards,

jm

Re: Org-syntax: emphasis and not English punctuation

[Juan Manuel Macías]

Max Nikulin writes:

> Maybe this issue should be considered independently of itra-word emphasis.

Yes I agree. Apologies for mixing up this topic in the discussion about
intra-word emphasis...

> Second and third examples looks like they should be supported. Ihor
> mentioned treating punctuation in a more general way. It requires rich 
> test set to estimate changes in heuristics. I suspect some problems
> since start and end patterns are not symmetric and I have not found a 
> way to specify in regexp only punctuation marks that normally appears
> in front of words. Square brackets likely should be excluded somehow
> as well since they are part of Org syntax. I am unsure if it is
> possible to use just regexp without additional checks of candidates.

Ihor's idea seems interesting to me, although I understand the possible
problems you mention. By the way, I'm afraid of initial inverted
punctuation (¡¿) are only used in Castilian Spanish and other languages
of Spain, such as Galician or Asturian, due to the Castilian influence
(we go backwards from the rest of the world ;-):
https://en.wikipedia.org/wiki/Inverted_question_and_exclamation_marks

> Ihor Radchenko. [PATCH] Re: c47b535bb origin/main org-element: Remove
> dependency on ‘org-emphasis-regexp-components’
> Sun, 21 Nov 2021 17:28:57 +0800.
> https://list.orgmode.org/87v90lzwkm.fsf@localhost

I see. I believe it's a sensible decision to get rid of the dependency
on org-emphasis-regexp-components. I understand that now everything
related to the structure of emphases is the competence of org-element?

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi John,

John Kitchin writes:

> Along these lines (and combining the s-exp suggestion from Max) , you
> can achieve something like this with links. 

I like this idea of merging the Maxim's proposal with the power of links.

In any case, this and other workarounds provided here make it clear that
in Org we do not lack of good and useful resources. I usually use macros
(taking advantage of the fact that macros expand soon). For example
(only in this case with the LaTeX backend):

#+MACRO: emph (eval (when (org-export-derived-backend-p 
org-export-current-backend 'latex) (concat "@@latex:\\emph{@@" $1 
"@@latex:}@@")))

Defined the macro this way, it allows me also to introduce nested
emphases by both ways:

#+begin_src example
{{{emph(lorem *ipsum* /dolor/ {{{emph(sit)}}} amet)}}}
#+end_src

==> \emph{lorem \textbf{ipsum} \emph{dolor} \emph{sit} amet}

Best regards,

Juan Manuel

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> The website title is "Org mode for Emacs", repelling users who _do
>not want_ to use Org inside Emacs. Maybe we can do better? Something
>with less accent on Emacs like "Org mode: your life in plain text"

I am not at all in favor of separating the 'Org Mode' name from 'GNU Emacs'.
In any case, regardless of my opinion, I see here two problems:

1. "Org mode: your life in plain text". The word "mode" remains orphan:
mode of what? It is clear that it is an Emacs mode, therefore it doesn't
make much sense to hide Emacs and then suggest it.

2. One possibility: "Org: your life in plain text". But here what
remains orphaned is "Org", too generic name. Unless "Org Mode" is a
lexicalized construct, without reference to any emacs mode.

(In any case, I would be extremely saddened if the reference to GNU Emacs
disappears in the title, just to please a minority).

Best regards,

Juan Manuel 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> I view "Org Mode" as a "brand name". Something uniquely identifying Org
> mode and serving as a search term.

Yes, it makes sense.

> Is it your principal position about the title specifically? Do you think
> that just referring to Emacs in the website description is not
> sufficient?

> Note that my suggestion #1 has nothing to do with actual orgmode.org
> front page. Just about how it appears in search results.

Yes, sorry for not explaining myself well: I was also referring to
search results, not the title in the web site...

But the question is: what need is there to remove the reference to Emacs
in the search result? I think the emphasis is necessary. As we say in
spanish, it's like putting the bandage on before the wound. If there are
people who think that Org Mode can 'live' in some way outside of Emacs
(a respectable opinion, but that I do not share, at least 100%), I think
the burden of the work falls on them and not on us, the users of
Emacs-Org-Mode. Anyway it is my simple and subjetive opinion, and it is
not my intention to initiate a controversy with it.

Best regards,

Juan Manuel 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Ihor Radchenko writes:

> Ok. Let me explain my thought process.
>
> First of all, there is no burden on users of Org mode in making edits to
> orgmode.org. It is a burden on Org contributors.
>
> One of the aims of my proposal is reducing this burden by involving
> non-emacs users to provide contributions to Org (e.g. by making more
> tests for Org-element parser). To do it, we need to make the
> contribution process for non-emacs developers easier. Ideally, without
> too much effort on our side.
>
> The idea of involving non-emacs users does have a potential because we
> do know that third-party tools are already using Org. The problem is the
> disconnect between those tools and Org mode proper.
>
> The sources of the disconnect are (1) lack of technical "blueprints" for
> Org that do not require knowing Elisp; (2) lack of discovereability of
> Org mode as something that can live outside narrow field of Emacs. In
> this branch of our discussion, I am going to talk about the second
> point.
>
> People simply do not expect to see a markup language when they encounter
> a link with "Org mode for Emacs" title. Someone looking for Org mode
> markup to be used in, say, websites will think that "Org mode for Emacs"
> is limited to Emacs. Someone just interested in plain text markup will
> find no relevance at all.
>
> Title is important. If we care at all about orgmode.org website
> appearing in search results, we want the title and the summary to have 2
> main properties: (1) Provide search keywords to make it searchable by
> potentially interested people; (2) Provide a title that immediately
> signal that our website contains the information people are looking for.
>
> Now, we need to understand what kind of people may be looking to
> orgmode.org website.
>
> 1. Existing emacs users
>
>If a Emacs user is faced with "Org mode for Emacs", the word "Emacs"
>is indeed recognisable. On the other hand, the word "Org mode" does
>not provide much further info, except that it is a major (or maybe
>minor?) mode for "Org"??
>
>Now, consider "Org mode: your life in plain text".
>For emacs users, "Org mode" is not just a strange phrase, but a very
>clear indication that we are talking about Emacs.
>The "your life in plain text" provides extra information about what
>"Org mode" refers to. Clearly, text documents and "your life in plain
>text" should resonate with every Emacs user's soul.
>
>We can change the second variant of the title to contain "Emacs", but
>will it add much value? I am not convinced. On the other hand, making
>title too long or too complex _is_ bad. Long titles tend to be
>skipped (there was even formal research on this!)
>
> 2. Non-emacs users interested in plain text markup
>
>These users know nothing about Emacs and "Org mode" has no meaning
>for them as is. So, we do need something more descriptive.
>Adding "Emacs" may be fine, but it will serve no purpose for people
>not familiar with emacs. Just another unknown term making the title
>longer.
>
> 3. Non-emacs users interested in GTD/project management, etc
>"Org mode: your life in plain text" is somewhat relevant when people
>are looking to manage "life" (typically true for GTD enthusiasts).
>
>Though we can probably do better for this category.
>Maybe "Org mode: manage your life and notes in plain text"?
>Though it makes the title less relevant to group #2.
>
> 4. Researchers looking for ipython-like environment
>
>Not covered, except by reading my proposed site summary. I am not
>sure how we can improve title for this audience.
>
> 5. ??? (Suggestions are welcome)
>
> Of course, better suggestions for the title are welcome. I just wanted
> to make it clear the reasoning I do not like the current title and how
> the proposed alternative is better (though not ideal).
>
> Finally, I want to emphasise that our aim for search engines is not
> advertising Emacs (we already do it by trapping users inside Org and
> making them switch to Emacs by force :evil_laughter:). The aim is
> encouraging people to use and contribute to Org mode in useful ways
> (even unrelated to writing Elisp or, really, any code at all).
>
> Search result is just an entrance for users to be curious about the new
> beast of "Org mode". The website front page is the means to make users
> try. And the Org mode itself is the way to make users fall in love with
> Org in one way or another (even unrelated to Emacs [at least
> initially]).

Ihor, thank you very much for explaining your motivation in detail. I
think I understand it and (on the important points) I share it. In my
case, as an Org Mode user I often feel a mixture of happiness and
frustration. Happiness on using Org. Frustration every time I want to
recommend Org to many of my friends and colleagues, who don't even use
Emacs. GNU Emacs is a great, labyrinthine, fascinating building. Almost
like a city. And Org is a roo

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Russell Adams writes:

> What makes Org dramatically different is the editing experience in
> Emacs. Collapsing the outline, filtering on metadata, exports, agenda,
> etc. Those are Emacs features, not specific to the actual markup
> format.
>
> My impression is we already have stretched our resources thin trying
> to maintain Org. Pushing to provide compatibility with non-Emacs tools
> seems a poor use of their time, and rude to ask of them.
>
> If non-Emacs users and coders want to use Org formatted files, they
> are free to spend their time customizing their tools to make it
> work. If the Org project owes anything to anyone, it's a consistent
> experience for the users who have used Org for years. Not changes to
> satisfy potential users or follow trendy fads.
>
> My experience has been that Org's markup is so simple and could be
> summarized in a few lines. Anything more complex enters the territory
> of Emacs only features (ie: drawers. exports, view control, source
> blocks, reporting). Those are unlikely to be portable, so we're back
> to "use Emacs".

I think that I cannot agree more with this. Org Mode is GNU Emacs, and
the magic of Org Mode is the magic of GNU Emacs. That's why I insist
that going to Org means going to Emacs.

Best regards,

Juan Manuel 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Hi Timohy,

Timothy writes:

> I don’t think Ihor is suggesting we stop indicating that org-mode is part of
> Emacs.

Of course, I am convinced that Ihor is not saying that Org is not part
of Emacs, and I have to make it clear, that I have never suggested such
a thing. What's more, I understand and applaud his conciliatory effort
on this issue, since since a series of debates and noise have arisen
here on these matters.

What worries me are the consequences of insisting here on these debates.
That is why I have underlined what Russell has commented, as I think he
is right.

On the other hand, we must not forget that Org, as part of Emacs, is
part of GNU, and this is a mailing list from the GNU project. I think
everything related to the (possible) extension of GNU Org Mode outside
of GNU Emacs (even in software incompatible with the ethics and
philosophy of the GNU project) should be considered offtopic here and be
discussed in other forums. Otherwise it would only create confusion
among users.

Best regards,

Juan Manuel 

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Juan Manuel Macías]

Hi Greg,

Greg Minshall writes:

> i hope we don't adopt such an "official policy" regarding discussions on
> this list.  i don't think we've had any problems where non-FSF/GNU
> topics have somehow swamped our discussions.

Not that I want to put on a censor hat, far from it :-). But this is
still an 'official' list. It's not reddit or anything like that. I think
it is necessary for the user to know what to expect here and what not to
expect. And I think there is a border between offtopic and explicitly
discussing extending Org beyond its natural limits or even flirting with
applications and software that do not respect user freedom and are
outside of GNU ethics and philosophy. And for the record, I am not
talking about Ihor's specific proposals in this thread --- which, as I
have already said, seems to me to be a commendable conciliatory effort,
although I do not share some points--- but rather from the previous
debate on the "new" name of the Org syntax, and other such things. I
think things like the 'orgdown' topic, which are not productive here,
should have their own place and forums outside here.

Best regards,

Juan Manuel 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Max Nikulin writes:

> John, thank you for the reminding me of Juan Manuel's idea that
> everything missed in Org may be polyfilled (ab)using links.
> It is enough for proof of concept, special markers may be introduced
> later. After some time spent exercising in monkey-typing,
> I have got some code that illustrates my idea.
>
> So the goal is to mitigate demand to extend current syntax.
> While simple cases should be easy,
> special cases should not be impossible.
>
> - Raw AST snippets should be processed without ~eval~ to give
>other tools such as =pandoc= a chance to support the feature.
>If you desperately need ~eval~ then you can use source blocks.
> - The idea is to use existing backends by passing structures
>similar to ones generated by ~org-element~ parser.
> - I would prefer to avoid "@@" for link prefix since such sequences
>are already a part of Org syntax. In the following example
>export snippet is preliminary terminated by such link:
>
>#+begin_src elisp :results pp
>  (org-element-parse-secondary-string
>   "@@latex:[[@@:(italics \"i\")]]@@"
>   (org-element-restriction 'paragraph))
>#+end_src
>
>
>#+RESULTS:
>: ((export-snippet
>:   (:back-end "latex" :value "[[" :begin 1 :end 13 :post-blank 0 
> :parent #0))
>:  #(":(italics \"i\")]]@@" 0 18
>:(:parent #0)))
>
> Let's take some link prefix that makes it clear that the proposal
> is a draft and a sane variant will be chosen later when agreement
> concerning details of such feature is achieved. Till that moment
> it is named "orgia".
>
> #+begin_src elisp :results silent
>(defun orgia-export (path desc backend)
>  (if (not (eq ?\( (aref path 0)))
>   path
>(let ((tree (read path))
>   (info (org-export-get-environment backend nil nil)))
>   (org-no-properties
>(org-export-data-with-backend tree backend info)
>
>(org-link-set-parameters
> "orgia"
> :export #'orgia-export)
> #+end_src
>
>
> Either [[orgia:("inter" (bold () "word"))]]
> or 
> links may be used. Certainly plain text may be outside:
>
> #+begin_src elisp
>(org-export-string-as "A word" 'html t)
> #+end_src
>
> #+RESULTS:
> : 
> : A interword
>
> - Error handling is required.
> - Elements (blocks) should be considered as an error
>in object (inline) context.
> - Passed tree should be preprocessed to glue strings split to
>avoid interpreting them as terminating outer construct or link itself
>(=]]= =][= should be ="]" "]"= ="]" "["= inside bracket links).
>It is especially important for property values.
> - For convenience =parse= element may be added to parse a string
>accordingly to Org markup.
> - There should be a similar element (block-level markup structure).
> - Symbols and structures used by ~org-element~ becomes a part of
>public API, but they are already are since they are used
>by export backends.
> - ~org-cite~ is likely will be a problem.

Hi Maxim,

I understand that with this method the emphases could be nested, which
it seems also very productive. I like it.

I would suggest, however, not to use the term 'italics', since is a
'typographic' term, but a term that is agnostic of format and
typography, something like as 'emphasis' or 'emph'. For example, in a
format agnostic environment like Org, which is concerned only with
structure, an emphasis is always an emphasis. But in a typographic
environment that emphasis may or may not be be in italics. That is why
in LaTeX you can write constructions like:

#+begin_src latex
\emph{The Making Off of \emph{Star Wars}}
#+end_src

In this context 'Star Wars' would appear in upright font. Naturally,
these things are only possible in LaTeX, but it's nice to keep in Org a
typographic agnosticism.

Anyway, I find all this very interesting as proof of concept, although
in my workflow I prefer to use macros for these types of scenarios (yes,
a rare case where I don't use links! :-D):

#+begin_src emacs-lisp
  (defun my-macro-emph (arg)
(cond ((org-export-derived-backend-p org-export-current-backend 'latex)
   (concat "@@latex:\\emph{@@" arg "@@latex:}@@"))
  ((org-export-derived-backend-p org-export-current-backend 'html)
   (concat "@@html:@@" arg "@@html:@@"))
  ((org-export-derived-backend-p org-export-current-backend 'odt)
   (concat "@@odt:@@" arg 
"@@odt:@@"

  (setq org-export-global-macros
'(("emph" . "(eval (my-macro-emph $1))")))
#+end_src

{{{emph(The Making Off of {{{emph(Star Wars)}}})}}}

Best regards,

Juan Manuel 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Juan Manuel Macías writes:

> I would suggest, however, not to use the term 'italics [...blah blah...]'

Sorry for the noise! I think I messed myself up...

Naturally, 'italic' (or 'bold') is required: (italic () \"inter\")

Best regards,

Juan Manuel 

Making a dictionary in Org

[Juan Manuel Macías]

Hi,

How to create a 'dictionary style' PDF document from Org, with two
columns and with dynamic page headers[1]: here I share (attached) an Org
file, in case it is useful to someone, with the (simplified) LaTeX code
I used to define the styles of the entries and the dynamic page headers
in the typesetting of the /Hispanic Dictionary of Classical Tradition/.

I produced this dictionary (828 pp.) using Org and Org-Publish, with
output to LuaLaTeX. Some images:
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc5.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc3.png
https://maciaschain.gitlab.io/lunotipia/images/muestras-dhtc4.png

[1] If a page contains multiple entries, the first and the last entries
are collected, both separated by an en dash; if the page contains a
single entry, or a continuation of the previous page/entry, it is
collected that entry only.

Best regards,

Juan Manuel


--
Juan Manuel Macías 

https://juanmanuelmacias.com/


dictionary.org
Description: Lotus Organizer

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Max Nikulin writes:

> As you have guessed, It is not my choice, it is interface of ox.el and 
> org-element.el.

Indeed. Sorry for my haste: it's the consequences of not read the code
carefully :-)

Of course, your orgia-link-procedure could be extended to more org elements.
I can't think of what kind of scenario that might fit in, but as a proof
of concept I find it really stimulating. E.g:

#+begin_src elisp
  (org-export-string-as "" 
'html t)
#+end_src

#+RESULTS:
: 
: 
: Lorem
: ipsum
: dolor
: 

#+begin_src elisp
  (org-export-string-as "" 'latex t)
#+end_src

#+RESULTS:
: \begin{foreigndisplayquote}{greek}
: Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲνἈρταξέρξης, 
νεώτερος δὲ Κῦρος·
: \end{foreigndisplayquote}


> However if you strongly want to use proper terminology in markup, you 
> may try to trade it for +your soul+ compatibility and portability 
> issues. The following almost works:

Interesting, thank you.

Yes, it is strange the new line added in `evilatex-emph' ... I have no
idea why that happens.

Best regards,

Juan Manuel 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

John Kitchin writes:

> Have you seen 
> https://github.com/tj64/org-dp? It seems to do a lot with creating and
> manipulating org elements. It might either be handy or lead to some
> inspiration. 

Interesting package. Thanks for sharing.

It gave me an idea, also borrowing part of Maxim's code, but evaluating
in this case the path. To continue playing with links... The goal is
to obtain a link with this structure `[[quote-lang:lang][quote]]':

#+BEGIN_SRC emacs-lisp :results silent
  (org-link-set-parameters
   "quote-lang"
   :display 'full
   :export (lambda (path desc bck)
 (let* ((bck org-export-current-backend)
(attr (list (format
 ":environment foreigndisplayquote :options 
{%s}"
 path)))
(info (org-export-get-environment
   bck nil nil)))
   (org-no-properties
(org-export-data-with-backend
 `(quote-block (:attr_latex ,attr)
   ,desc)
 bck info)
#+END_SRC

#+begin_src emacs-lisp 
  (setq backends '(latex html odt))
  (setq results nil)
  (mapc (lambda (backend)
  (add-to-list 'results
   (org-export-string-as 
"[[quote-lang:spanish][Publicamos nuestro libros
   para librarnos de ellos, para no pasar el resto de nuestras vidas
   corrigiendo borradores.]]" backend t) t))
backends)
  (mapconcat 'identity results "\n")
#+end_src

#+RESULTS:
#+begin_example
\begin{foreigndisplayquote}{spanish}
Publicamos nuestro libros
 para librarnos de ellos, para no pasar el resto de nuestras vidas
 corrigiendo borradores.
\end{foreigndisplayquote}



Publicamos nuestro libros
 para librarnos de ellos, para no pasar el resto de nuestras vidas
 corrigiendo borradores.




Publicamos nuestro libros
 para librarnos de ellos, para no pasar el resto de nuestras vidas
 corrigiendo borradores.
#+end_example

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Max Nikulin writes:

> Looking into your code I have realized that it should be implemented 
> using filter, not through :export property of links. Maybe without 
> working proof of concept with link exporters, this session of 
> monkey-typing would not be successful.

Jumping into the "real world", how about these two examples of nested emphasis?

#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (italic () "Iliad") " and the 
" (italic () "Odyssey"))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \emph{Iliad} and the \emph{Odyssey}}
#+end_export

This one more complex:

#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (bold () (italic () "Iliad")) 
" and the " (bold () (italic () "Odyssey")))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the 
\textbf{\emph{Odyssey}}}
#+end_export

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Juan Manuel Macías writes:

> Jumping into the "real world", how about these two examples of nested 
> emphasis?

By the way, what do you think about allowing the use of some kind of
aliases, so that the aspect is less verbose? Maybe something like "(i::"
instead of "(italic () ..."? I came up with this hasty sketch over your
latest code, *just* to see how it looks (I don't know if I prefer it to
stay verbose):

#+begin_src emacs-lisp :results silent
 (setq orgia-alias-alist '(("i" "italic")
   ("b" "bold")
   ("u" "underline")
   ("s" "strike-through")))

  (defun orgia-replace (before after)
(interactive)
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward before nil t)
(replace-match after t nil

  (defun orgia--transform-path (path)
(with-temp-buffer
  (insert path)
  (mapc (lambda (el)
  (orgia-replace (concat "(" (car el) "::") (concat "(" (cadr el) " 
() ")))
orgia-alias-alist)
  (buffer-string)))

  (defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
  (let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
  (read (orgia--transform-path path)) ;; <
;;
 #+end_src

#+begin_src elisp
   (org-export-string-as "An word"
'odt t)
#+end_src

#+RESULTS:
: 
: An interword


#+begin_src org :results latex :results replace
  [[orgia:(i:: "The English versions of the " (b:: (i:: "Iliad")) " and the " 
(b:: (i::
  "Odyssey")))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the 
\textbf{\emph{Odyssey}}}
#+end_export


--
Juan Manuel Macías 

https://juanmanuelmacias.com/

Re: format/fill of text in a cell in tables

[Juan Manuel Macías]

to...@tuxteam.de writes:

> This reminds me of people advocating "semantic backup" (e.g. use
> "emphasis" instead of "italics", until one realises that you just
> managed to peel off one layer of the sematic onion. The onion just got
> smaller (some literature perhaps might want to play with the ambiguity
> of italics?), and if you continue, you end up with no onion at all.

There is a lot of confusion between the terms 'emphasis' and
'italics/cursive'. The second term is strictly typographic-calligraphic.
There are entire codices that are wrote in Byzantine cursive. And you
have the Porson typeface, from the Oxford editions of Ancient Greek
texts, which is a cursive, but which is used as a normal font. In an
ancient text there is no notion for 'emphasis': how do we know when
Homer or Sappho wanted to emphasize a phrase? Typography has
historically used italics as a resource for emphasis (not in all
languages, some use the separation of letters to emphasize; there are
also writing systems where the concept of 'italics' or 'cursive' does
not make sense), but it uses the italic also for more varied purposes:
depends on the era, fashion and trends. Consider also the avant-garde
poetry of the early last century, which had a great typographical
dependency, as a sort of game. In addition, there is the maremagnum of
graphic design, which is not strictly typography (although both terms
are also confused), but use the typography for expressive purposes:
advertising, etc.

I remember that a long time ago I use to wrote in a typewriter, and
there was a common convention in typed texts, which consisted of marking
the emphases like this: _emphasis_. WYSIWYG word processors imposed a
form quite unnatural to write, by confusing format and content. And they
force authors to have typographical concerns at the most inopportune
moment, which is the creation of content (as if Hemingway used a
monotype instead of a typewriter). The proof is that hardly any of the
Word users use Word styles or apply them consistently. The normal thing,
with rare exceptions, is to degrade the documents using direct format,
which is the great plague.

I believe that a text whose main purpose is not to produce a visual
impact (advertising, ritual, magic, etc.) but to transmit a thought and
a content, it must have a structure. And then there will be time for
that structure can be translated to other supports. Typography, in its
most basic and utilitarian sense (not visual) is nothing more than a
language to translate that structure, offering the maximum possible
readability, through a series of techniques. And every type of
content, for example a 'table' (in Org terms not typographic terms), can
have many possible typographic translations, even translations that
don't consist of a 'table', in typographical terms. But typography is not
the only possible language to translate a content: think of texts
written to be heard, or texts written for absolutely personal use.
That's why I believe the least unhealthy way to put content in writing
is within a environment as agnostic as possible of the format. In that
environment is where the term 'emphasis' makes sense.

Best regards,

Juan Manuel 

Re: format/fill of text in a cell in tables

[Juan Manuel Macías]

Uwe Brauer writes:

> I think, one attempt could be to use org-edit-special, to edit a cell,
> type the text in a temporary buffer, fill it and then return to the table. 
>
> That seems so obvious that I think there might be technical problems,
> because otherwise it would have been implemented already.

I proposed that here the last time a similar discussion came up, but now
I don't think it's a good idea. I believe the root problem is that the
visual representation of the tables in Org is line oriented. Cells with
a lot of content (paragraphs, for example) should be shrunken, because
the content is a single line; when editing each cell in its special
buffer, that content would have to be converted into paragraphs, and
when saving the edition buffer, convert it back to a single line again.
I tried to write something similar for my personal use, but it is very
tricky. Maybe such an implementation would work better for AUCTeX, since
tables in LaTeX are not line oriented.

About a possible solution for Org regarding the topic of 'complex'
tables, I have ended up giving up. I think it is better to create the
complex tables in raw LaTeX. To export them to HTML you could perhaps
think of a LaTeX block that would return the results compiling with
tex4ht (https://ctan.org/pkg/tex4ht?lang=en) instead of LaTeX. But I
don't know if it would work. The point is that anything other than a
simple and clean table (visually speaking) in Org, is to enter the land
of the tricks.

Best regards,

Juan Manuel 

Re: text after sub headings?

[Juan Manuel Macías]

Hi Robert,

Robert Nikander writes:

> I see why this is not possible, given the text format of an org file.
> But I am curious if people think it would be useful. This is a bit
> off-topic maybe, but I’m imagining what I would do if I created
> something like org-mode using another underlying format.
>
> Example: 
>
> * Top
>   Some text under “Top”
>   ** A level-2 heading 
> Text under level-2 heading
>   ** Another level-2 heading
> Text under the second level-2 heading
>   More text under “Top”
>   So if the level-2 headings were collapsed we would still see this.
>   ** Could have more sub-headings here
>   More top level text, etc.

It is an interesting question; however, I would say that this is not a
useful or realistic structure. Regardless of the Org trees/subtrees and
their folding ability (indicating that each thing is at a certain
level), I think that a content will be more useful and intelligible if
it is easy and obvious to extract a table of contents (with headings and
levels) from that content. Let's imagine not we are in Org but writing a
novel on a typewriter. It could be a two-voice novel, with a main
narrator and a "secondary" narrator. The first structure could be:

Part I (Narrator A)
Some text under Part I (Narrator A)
 Chaper 1
 Text under Chapter 1 (Narrator B)
 Chapter 2
 Text under Chapter 2 (Narrator B)
?? More text under Part I (Narrator A)
 More chapters (Narrator B)
?? More Part I text, etc. (Narrator A)
(...)

Although we feel that our structure is very clear, our publisher will
probably force us to include some kind of division into the texts marked
with "??". I mean, it's not that easy to escape from the (graphical)
levels, parts and chapters, even if it is by editorial imposition or for
not confuse our readers. We can, for example, call Part II "Interlude",
or add the first text marked with "??" after a graphic separation (some
dashes, for example: --). Although the literary structure is
complex, its graphical representation always has limits:

Part I (Narrator A)
Some text under Part I (Narrator A)
 Chaper 1
 Text under Chapter 1 (Narrator B <= Narrator A)
 Chapter 2
 Text under Chapter 2 (Narrator B <= Narrator A)
 Division 1 (forced by the publishing house = Part II?)
 More text under Part II (Narrator A)
 More chapters (Narrator B)
(...)

Best regards,

Juan Manuel 

Re: text after sub headings?

[Juan Manuel Macías]

Robert Nikander writes:

> If you view a "*" item as "book section", it's confusing. But if you
> view a "*" item as "collapsible thing", then it makes more sense.

I understand your use case. But I think in that context Org headings
would still be useful (at least they remind us at what level we're). For
example, some headings could be used for those parts with a tag
:not_a_heading:. I sometimes use something like that, and then I remove
those tagged headings on export or convert them to another type of
separator, it depends on the case:

* Top
  Some text under “Top”
  ** A level-2 heading 
Text under level-2 heading
  ** Another level-2 heading
Text under the second level-2 heading
* Some descriptive title :not_a_heading:
More text under “Top”

Re: text after sub headings?

[Juan Manuel Macías]

Max Nikulin writes:

> Text books and magazines may contain insets (side notes), sometimes
> even page-long ones. They present independent material that may be 
> interesting or useful in particular context or may be just skipped
> when a reader is concentrated on main material. Such inset may be
> considered as a heading that is inserted in the middle of another
> section. It may have larger margins, smaller font, distinct font face,
> another background color, box around or just rule at some side, so
> readers have clear notion where it ends and main material continues.

This is complex layout, something that DTP programs (InDesign, Quark,
Scribus) do very well as they work on the concept of multiple threads of
connected text boxes. [offtopic: in LaTeX there is an attempt to emulate
that with the flowfram package, with obvious limitations. And the Sile
typesetting system is very interesting and promising, which tries to
combine the WYSIWYM style of TeX and the linked text boxes of DTP
programs: https://sile-typesetter.org/]. But --- returning to the
topic---, even so, there is always an underlying notion of hierarchy,
levels and dependency, which is what I was referring to: there is a
skeleton. I think that Org's system of trees and nodes, agnostic of any
typographic format, is enough to maintain that hierarchy. In fact, I
have some works with a very complex output starting simply from Org
(right now I'm with a trilingual edition, using flowfram: for example,
certain Org nodes are exported as flowfram boxes). Obviously, that can
also be done from XML (an example of a combination of xml and LuaTeX:
https://www.speedata.de/en/). But I think, perhaps in a somewhat
quixotic way, that Org has tremendous potential and can play very well
in that league. XML is more accurate; but Org is a great compendium of
resources.

Re: text after sub headings?

[Juan Manuel Macías]

Max Nikulin writes:

> It is not necessary complex layout. It is a decoration similar to
> pictures in fiction books. Unlike figures such additions are not 
> strictly important to understand material. In printed form it is like
> figures however. Insets are appropriate in particular places, but 
> tolerate some shift due to paging.

Generally, any scenario where graphic and textual content must be
distributed and managed is already complex layout. Although there are
several levels of complexity, and in many cases visual control is
necessary. In any case, TeX is not intended for (stricto sensu) layout
but for typesetting, which is where DTP programs often fail. This does
not mean that highly complex pages cannot be achieved in TeX, but the
strong point of TeX is the automation of processes and repeated
structures, while the strong point of DTP programs is visual layout
design, more focused on magazines, newspapers, posters, etc. There are
"intermediate places", and in TeX there are still unresolved issues. For
example: the possibility of working with independent text flows (for
example, create two parallel TeX processes: one for even pages and
another for odd pages) or grid typesetting (in LaTeX it is almost impossible
and in ConTeXt some advances have been made) although I am very critical
of the grid composition, which has become a plague lately.

Anyway, in order not to get too off the topic, here are a couple of
examples that I made (one of them with flowfram), exporting an inline
task to LaTeX through an ad hoc filter:

https://i.imgur.com/8ERXNWp.png

https://i.imgur.com/mpFRL9h.png

(code attached)

Best regards,

Juan Manuel 



tests.org
Description: Lotus Organizer

Re: caption width in LateX export

[Juan Manuel Macías]

Hi Seb

Seb writes:

> When exporting to LaTeX, is there a mechanism to make the figure
> captions as wide as the figure?  In pure LaTeX, this can be easily
> accomplished by placing the figure inside a minipage environment.
> Using a special block, as in:
>
> \begin{minipage}{0.7\textwidth}
>
> #+CAPTION: looong caption.
> [[file_path]]
>
> \end{minipage}
>
> fails, as it seems impossible to pass arguments to the special block.
> Any tips welcome.

If you use the caption package (https://www.ctan.org/pkg/caption), you
can indicate in each figure the width of the caption. In this case, you
would have to introduce the code using raw latex via the `:caption'
property:

#+LaTeX_Header: \usepackage{caption}

#+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum 
dolor sit amet, consectetuer adipiscing elit}
#+ATTR_LaTeX: :width .3\linewidth
[[file_path]]

Best regards,

Juan Manuel 

Re: caption width in LateX export

[Juan Manuel Macías]

P.S.: I have come up with another possibility, more automatic, on the
LaTeX side, if you compile with LuaTeX. This thread
(https://tex.stackexchange.com/questions/202046/width-of-the-caption-of-a-figure),
where someone proposes to use a \savebox for concrete images, gave me
the idea. We can automate that through a simple function in Lua, and add
it to the `process_input_buffer' callback, in order to the caption
*always* has the width of each image:

You can put this in your Org document:

#+NAME: luacode
#+begin_src latex :exports none
\usepackage{luacode}

\begin{luacode*}
  function caption_width ( text )
  text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
  text = string.gsub ( text, "(\\caption{.+})", 
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
  return text
  end
\end{luacode*}

\newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback
( "process_input_buffer" , caption_width , "caption_width" )}}

\AtBeginDocument{\CaptionAutoWidth}
#+end_src

#+begin_src latex :noweb yes :results raw
,#+LaTeX_HEADER: <>
#+end_src

And then:

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit
#+ATTR_LaTeX: :width .3\linewidth
[[img]]

Best regards,

Juan Manuel 

Juan Manuel Macías writes:

> If you use the caption package (https://www.ctan.org/pkg/caption), you
> can indicate in each figure the width of the caption. In this case, you
> would have to introduce the code using raw latex via the `:caption'
> property:
>
> #+LaTeX_Header: \usepackage{caption}
>
> #+ATTR_LaTeX: :caption \captionsetup{width=.3\linewidth}\caption{Lorem ipsum 
> dolor sit amet, consectetuer adipiscing elit}
> #+ATTR_LaTeX: :width .3\linewidth
> [[file_path]]

Re: caption width in LateX export

[Juan Manuel Macías]

Sebastian P. Luque writes:

> Thank you, Juan.  Unfortunately, there is a price for this solution as
> it is now impossible to name and refer to this segment as usual:

I see. Have you tried the option with LuaTeX that I put in my other
message? You can compile with LuaTeX also using latexmk:

(setq org-latex-pdf-process
  '("latexmk -lualatex -e '$lualatex=q/lualatex %%O -shell-escape %%S/' 
%f"))

In any case, since this is a simple substitution, you can use also a
function in Elisp as a final output filter[1]:

#+BIND: org-export-filter-final-output-functions (caption-auto-width)
#+begin_src emacs-lisp :exports results :results none
  (defun caption-auto-width (text backend info)
(when (org-export-derived-backend-p backend 'latex)
  (with-temp-buffer
(insert text)
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward "\\(includegraphics.+\\)" nil t)
(replace-match "sbox0{\\1}" t nil)))
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward "\\(caption.+\\)" nil t)
(replace-match 
"begin{minipage}{wd0}usebox0\\1end{minipage}" t nil)))
(setq text (buffer-string)
#+end_src

Vid. [[fig:1]] 

#+NAME: fig:1
#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus. Donec pretium posuere tellus
#+ATTR_LaTeX: :width .3\linewidth
[[my-image.jpg]]

[1] You need to set this variable as non-nil, in order to use bind
keywords: (setq org-export-allow-bind-keywords t)

Hope this works,

Best regards,

Juan Manuel 

Re: caption width in LateX export

[Juan Manuel Macías]

Sebastian P. Luque writes:

> This is great, and very interesting to learn about the BIND keyword.
>
> Thank you,

You're welcome. Of course, if you use the filter very often, it is not
necessary to include it in a document or use the bind keyword. It
would be enough to add the function to your init and the line:

(add-to-list 'org-export-filter-final-output-functions #'caption-auto-width)

In a case like this, however, I would prefer to use the other function
in Lua within LuaTeX, since two commands could be defined: one to enable
the automatic caption width and one to disable it, throughout the
document. E.g.:

#+begin_src latex
  \usepackage{luacode}

  \begin{luacode*}
function caption_width ( text )
  text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}")
  text = string.gsub ( text, "(\\caption.+)", 
"\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}")
  return text
end
  \end{luacode*}

\newcommand\CaptionAutoWidthOn{\directlua{luatexbase.add_to_callback
  ( "process_input_buffer" , caption_width , "caption_width" )}}

\newcommand\CaptionAutoWidthOff{\directlua{luatexbase.remove_from_callback
  ( "process_input_buffer" , "caption_width" )}}
#+end_src

\CaptionAutoWidthOn

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus 
#+ATTR_LaTeX: :width .3\linewidth
[[img.jpg]]

\CaptionAutoWidthOff

#+CAPTION: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec 
hendrerit tempor tellus
#+ATTR_LaTeX: :width .1\linewidth
[[img.jpg]]

[BUG] Underlined text in parentheses is not exported correctly

[Juan Manuel Macías]

Hi all,

I don't know if this is a known issue...

Consider the text:

(_underline_)

When exported to LaTeX we get:

(\textsubscript{underline}\_)

And to HTML:

(underline_)

The same result with:

(_underline_ text)

LaTeX:

(\textsubscript{underline}\_ text)

But this:

(this word is _underline_)

is exported correctly:

(this word is \uline{underline})

If I do M-! (occur org-match-substring-regexp)

I get:

 10:(_underline_)
 22:(_underline_ text)

Best regards, and happy New Year,

Juan Manuel 

Re: [BUG] Underlined text in parentheses is not exported correctly

[Juan Manuel Macías]

Juan Manuel Macías writes:

> If I do M-! (occur org-match-substring-regexp)
>
> I get:
>
>  10:(_underline_)
>  22:(_underline_ text)

Well, in my case the temporary workaround was to force super/subscripts
with braces:

#+begin_src emacs-lisp
  (defun my-org-element-subscript-with-braces-parser ()
(save-excursion
  (unless (bolp) (backward-char))
  (when (looking-at org-match-substring-with-braces-regexp)
(let ((bracketsp (match-beginning 4))
  (begin (match-beginning 2))
  (contents-begin (or (match-beginning 4)
  (match-beginning 3)))
  (contents-end (or (match-end 4) (match-end 3)))
  (post-blank (progn (goto-char (match-end 0))
 (skip-chars-forward " \t")))
  (end (point)))
  (list 'subscript
(list :begin begin
  :end end
  :use-brackets-p bracketsp
  :contents-begin contents-begin
  :contents-end contents-end
  :post-blank post-blank))

(advice-add 'org-element-subscript-parser :override 
#'my-org-element-subscript-with-braces-parser)
#+end_src

Re: [BUG] Underlined text in parentheses is not exported correctly

[Juan Manuel Macías]

Ihor Radchenko writes:

> I am not sure if  it is an actual issue.
>
> Note that (_u can be interpreted as a subscript.
> Org prioritises subscript over underline.
>
> Looking at the code:
>
> (?_ (or (and (memq 'subscript restriction)
>  (org-element-subscript-parser))
>   (and (memq 'underline restriction)
>  (org-element-underline-parser
>
> The priority appears to be intentional.

I see. But then the compatibility with the rest of the emphasis is
broken. I mean, the user would expect things like (_underline_) will be
exported as (\uline{underline}), in the same way that (/emphasis/) is
exported as (\emph{emphasis}). I would say there is a slight
inconsistency in the syntax here.

Anyway, in my case I have solved it by always forcing the
super/sub-scripts with brackets overriding `org-element-subscript-parser'
(I never use them without brackets), as I mentioned in my previous
message.

Best regards,

Juan Manuel 

Re: [PATCH] Re: [BUG] Underlined text in parentheses is not exported correctly

[Juan Manuel Macías]

Ihor Radchenko writes:

> However, thinking about it more, I feel that prioritising underline
> should work better. The underline parser recently got changed into a
> stricter version. Now, only underlines starting after spaces,-,(,',",
> and { are recognised as an underlines.
>
> So, the attached patch is changing the priority of the parsing.
> Maybe Nicolas knows some tricky cases when the patch makes things wrong,
> but those cases are certainly not covered by tests.

Great! I vote for this patch, I think it is a necessary addition. In my
case I have not found any error.

Best regards,

Juan Manuel 

A simple Lua filter for Pandoc

[Juan Manuel Macías]

Hi,

Very often I need to convert docx documents to Org. There are a series
of characters that I prefer to be passed to Org as Org entities and not
literally, so I have written this little filter in Lua for Pandoc. I
share it here in case it could be useful to someone. Of course, the
associative table can be expanded with more replacement cases:

#+begin_src lua :tangle entities.lua
  local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
  [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = 
"\\nbsp{}"}

  function Str (elem)
 x = elem.text:match 'http[^%s]'
 if not x then
for i in pairs(chars) do
   elem = pandoc.Str(elem.text:gsub (i, chars[i]))
end
return elem
 end
  end
#+end_src

And a quick test:

#+begin_src sh :results org
str="/ † * < > http://foo.es  "
pandoc -f markdown -t org --lua-filter=entities.lua <<< $str
#+end_src

#+RESULTS:
#+begin_src org
\slash{} \dagger{} \lowast{} \lt{} \gt{} http://foo.es \nbsp{}
#+end_src

Best regards,

Juan Manuel 

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Hi Timothy:

Timothy writes:

> I’m quite interested in this, thanks for sharing. In fact, I’ll probably add
> this to .

Interesting package. Until now I used a number of homemade functions to
convert docx/odt files from Dired, but I think your package will be very
useful to me ;-)

Best regards,

Juan Manuel 

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Max Nikulin writes:

> Ideally it should be done pandoc and only if it causes incorrect
> parsing of org markup. NBSP, probably, should be replaced by some
> exporters, I do not think, it is a problem e.g. in HTML files.

The reason for this filter is my own comfort. Linguistics texts contains
a lot of certain characters such as "/" or "*", and they are often
italicized or bold. So, in order not to be more confused than necessary,
I prefer that they pass as entities. In general, there are certain
characters that I am more comfortable working with as entities than as
literal characters (for example, a lot of zero-width combining
diacritics that are used a lot in linguistics or epigraphy (and there
are no fonts that include the NFC normalized version of all possible
combinations: in fact, they are not in Unicode, and would have to go to
the private use area). Summarizing, I prefer that these characters have
their actual typographic representation only with LuaTeX. A very typical
example is the character U+0323 (COMBINING DOT BELOW). It is very
uncomfortable to work /in situ/, although there are fonts that usually
render it well (with the 'mark' otf tag).

(Naturally, I have to do, inside Org, a lot of corrections in italics
later, due to the bad habit that Word users have of applying direct
formatting. Interestingly only the pandoc docx reader trims the emphasis
before exporting to Org or Markdown, so as not to produce things like
"/ foo /". But the odt reader doesn't. I don't know if I'm missing
something.

Re: Tool to compare and choose fonts

[Juan Manuel Macías]

Ypo writes:

> Was a tool to compare fonts presented in this list some time ago? 
>
> I lost it, I thought I discovered it on Reddit, but now I am thinking
> I found it here. 
>
> It was a script that presented on emacs every font in the computer, in
> pairs; so the user chose one font each time, like if it were a
> "championship" between fonts. 

https://github.com/alphapapa/unpackaged.el#font-compare

Outside of Emacs there are many tools for auditing fonts. In TeX live
you have the otfinfo script, for example, very useful. And recently the
Unicode Font Table package has been uploaded to CTAN, to represent
character tables in (Lua/Xe)LaTeX:

https://www.ctan.org/pkg/unicodefonttable

(an example that I have done inside Org, using LaTeX blocks:
https://i.imgur.com/eiiAUlB.png)

Best regards,

Juan Manuel 

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Max Nikulin writes:

> It seems, lightweight markup is more annoyance than advantage for you. 
> Tom posted some thoughts on more rigorous syntax in the following message:

It's generally the opposite: working in Org is a pleasant journey for
me... except when there are dozens of "/" and "*" in a document, and
they placed in 'unhappy' positions. For example, in phonetics the
"/ ... /" notation is used a lot, and there may be cases like:

#+begin_example
/foo/ /bar/ /baz/
#+end_example

In grammar the asterisk is also used a lot, to designate that a term is
not attested or to indicate that it is ungrammatical:

#+begin_example
*foo *bar *baz
#+end_example

And we can even have the combination of both:

#+begin_example
/*foo/ /*bar/ /*baz/
#+end_example

And in certain cases, they are usually expressed in italics. With these
landscapes, it's worth having a few entities rather than working from
pure LaTeX, which is more accurate, but horribly more verbose.

This is a page from a book I typesetted a couple of years ago (when the
pandemic started), entirely from Org:

https://i.imgur.com/f6X7qLs.png

Best regards,

Juan Manuel 

Re: Way to mark contents of an Org special block as verbatim?

[Juan Manuel Macías]

Hi Kaushal,

Kaushal Modi writes:

> I would like to treat that block /like/ how Org treats the latex
> environment blocks, but it needs to be a special block as
> begin_katex/end_katex here is special and it could be a different
> equation rendering backend for another user.
>
> So is that a header switch or arg that can be passed on to this
> special block that enables the verbatim mode (prevent Org from
> replacing the Org entities, do the sub/superscript expansion, etc.)?

I think one possibility would be using a parse tree export filter:

#+BIND: org-export-filter-parse-tree-functions (katex-verbatim)
#+begin_src emacs-lisp :exports results :results none
  (defun katex-verbatim (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
  (org-element-map tree 'special-block
(lambda (block)
  (when (equal "katex" (org-element-property :type block))
(let ((cont (org-element-interpret-data (org-element-contents 
block)))
  (create-export-snippet ;; idea from Nicolas Goaziou
   (lambda (v)
 (org-element-create 'export-snippet (list :back-end 
"latex" :value v)
  (apply #'org-element-set-contents
 block
 (list (funcall create-export-snippet cont))
info)
  tree))
#+end_src

#+begin_katex
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_katex

==>

\begin{katex}
E = -J \sum_{i=1}^N s_i s_{i+1}
\end{katex}

Best regards,

Juan Manuel 

Re: Way to mark contents of an Org special block as verbatim?

[Juan Manuel Macías]

Kaushal Modi writes:

> Wow, thanks for that complete code. I didn't know about the parse tree
> functions.
>
> I was thinking if below is possible as any user running my exporter
> would need to use this feature easily.
>
> #+begin_katex :verbatim t
> E = -J \sum_{i=1}^N s_i s_{i+1}
> #+end_katex

I just realized that there is a much simpler solution for your katex
environment :-)

You can use an example block, and define your custom environment using
the attribute :environment

#+ATTR_LaTeX: :environment katex
#+begin_example
E = -J \sum_{i=1}^N s_i s_{i+1}
#+end_example

Filter to put decorative initial letters

[Juan Manuel Macías]

Hi,

These past holidays I've been experimenting with some little useful, but
fun stuff. This is an export filter to put a decorative initial letter
in the first paragraphs of the first level sections, using the LaTeX
package lettrine (https://www.ctan.org/pkg/lettrine).

A screenshot: https://i.imgur.com/mLQVHFC.png

#+BIND: org-export-filter-parse-tree-functions (lettrine)

#+begin_src emacs-lisp :exports results :results none
  (defun lettrine (tree backend info)
(when (org-export-derived-backend-p backend 'latex)
  (org-element-map tree 'headline
(lambda (section)
  (when (eq 1 (org-element-property :level section))
(let* ((contents (org-element-interpret-data (org-element-contents 
section)))
   (lettrine-opt (org-export-get-node-property 
:LETTRINE_OPTIONS section t))
   (contents-lettrine (with-temp-buffer
(insert contents)
(save-excursion
  (goto-char (point-min))
  (re-search-forward 
"\\(\\b.\\)\\([^\s]+\\b\\)" nil t)
  (replace-match (concat "lettrine"
 (if 
lettrine-opt (format "[%s]"

  lettrine-opt) "")
 "{" "\\1" "}" 
"{" "\\2" "}")
 t nil)
  (org-element-parse-buffer)
  (apply #'org-element-set-contents
 section
 (list contents-lettrine)
info)
  tree))
#+end_src

Best regards,

Juan Manuel 

Re: A simple Lua filter for Pandoc

[Juan Manuel Macías]

Max Nikulin writes:

> Form my point of view it is not worse than "\slash{}" entities.

Yes, I also use macros a lot, especially for more complex constructions.
Macros, entities and other tricks have their pros and cons, but they
allow me to have a certain group of characters under control.

>> https://i.imgur.com/f6X7qLs.png
>
> In this example there is no need to replace "<" by entity since it can 
> not be confused with  links.

As I have already said, this comes from a desire to keep a series of
characters under control, because they can be confused with the Org
marks or because I can get confused when working with the text,
especially if it is an imported text. In the case of "<" and ">", many
authors usually use them for various contexts in philology (instead of
the correct characters for some of those contexts, such as
RIGHT-POINTING ANGLE BRACKET and LEFT-POINTING ANGLE BRACKET: in that
case, I have to replace with the correct symbol). In general, I am
calmer if I have, in one way or another, all those symbols conveniently
"delimited", because even if Org is not wrong, I can get confused.

Anyway, regardless of the idiosyncrasy of my workflow, the origin of
this thread (the function in Lua) was in case someone wants to adapt it
to their own workflow, and needs to substitute some strings for others
when importing from docx or odt.

Best regards,

Juan Manuel 

[tip] Inline tasks as anonymous sections

[Juan Manuel Macías]

Hi,

I think that a very efficient way to take advantage of inline tasks (in
the framework of document authoring and exporting) is to treat them as
anonymous sections, that is, those sections that do not have a title and
are normally separated in books by some special symbol: three asterisks
(a dinkus: https://en.wikipedia.org/wiki/Dinkus), an asterism (three
asterisks forming a triangle), or any other fancy symbol. Users can
associate their own export functions with the variables
`org-latex-format-inlinetask-function',
`org-odt-format-inlinetask-function', etc. Well, you can always add the
separation symbol directly in your text, but the advantage of using
inline task is that we can conveniently have those sections delimited,
as real sections (with properties, todo states, etc).

If anyone wants to explore this possibility, I am attaching a test org
document. I have defined two LaTeX commands: \anonsectionbreak and
\anonsectionmark; and the 'anonsection' environment[1].

[1] The Memoir class includes code for these types of divisions (see
section 6.7 FANCY ANONYMOUS BREAKS in Memoir documentation).

Best regards,

Juan Manuel



anon-sec-test.org
Description: Lotus Organizer

Preview fonts from Dired with org-latex-preview (and test opentype features)

[Juan Manuel Macías]

Hi,

I have written for my personal use this code (still quite crude) that
allows me to preview with org-latex-preview small text strings in a font
marked in dired, and test open type features too. The preview is
compiled with LuaLaTeX, since LuaTeX allows to load fonts that are not
installed in the system.

When a font is selected, the list of opentype features included in the
font are extracted (using the otfinfo command), and they are arranged in
the preview buffer as buttons. By clicking on each button we can
activate in the preview the corresponding opentype feature. For example,
if the font includes the 'smcp' feature, clicking on the button 'smcp'
the text will be displayed in small caps.

We can enter the text strings literally or through Unicode code: each
character separated by a space; the separation between words is marked
with a vertical bar. For example, this code:

0063 006f 0064 0065 | 0068 0065 0072 0065

returns the string "code here".

As a third option, a complete specimen can be displayed from a file.

Here is a demo video: https://cloud.disroot.org/s/aHXKiof36fTSZGB

As I said, my function is still pretty crude, and while it works well,
it's now more of a proof of concept than a finished thing. But if anyone
wants to try it, I attach the code here in an org document.

Best regards,

Juan Manuel



font-preview.org
Description: Lotus Organizer

Re: Filter to put decorative initial letters

[Juan Manuel Macías]

Hi William,

William Denton writes:

> This is beautiful, and a nice Org hack.  I appreciate the
> typographical and design examples you send, and have learned a lot
> from them.  Thank you.
>
> Bill

Thanks for your kind words, I'm glad you found that code useful.

Best regards,

Juan Manuel 

Re: puzzled about :fit for LaTeX src block

[Juan Manuel Macías]

Hi Eric,

Eric S Fraga writes:

> I have a LaTeX src block which creates an image using tikz.  In a book
> I'm writing, the image, when created as a png, does not get shrunk but
> is instead a full page (with the actual diagram in the top left corner).
> If I create a PDF, instead, it works fine.

Testing two possibilities:

What (latex) code produces that image in the output *tex file of your book?

and

C-h v RET org-format-latex-header RET: what value?

Best regards,

Juan Manuel 

Re: puzzled about :fit for LaTeX src block

[Juan Manuel Macías]

Hi Eric,

Eric S Fraga writes:

> Both the same and the default value from org.

I'm not sure, but maybe the problem comes from the
\documentclass{article} in org-format-latex-header. Can you try
replacing that with "\\documentclass[varwidth]{standalone}"?

Another possibility: please try adding the header arg. :imagemagick yes

Best regards,

Juan Manuel

Re: puzzled about :fit for LaTeX src block

[Juan Manuel Macías]

Eric S Fraga writes:

> This did it!  Thank you.  I am curious now to find out what tool was
> used instead... something for later today!

Well, it seems that if you use ":imagemagick yes", the image is created
with the `org-babel-latex-convert-pdf' function. I almost always use this
to create images from latex blocks, for example:

#+begin_src latex: imagemagick yes :iminoptions -density 600
\bfseries Hello world!
#+end_src

":fit" crop the image, but you can also put in your "org-format-latex-header" 
"\\documentclass[varwidth]{standalone}"

On the contrary, without :imagemagick, but with results to *.png file,
`org-create-formula-image' is used, which depends on
"org-preview-latex-process-alist" and
"org-preview-latex-default-process". Since I only use LuaTeX for
everything, I have this in my init, in order to preview LaTeX fragments:

(setq luamagick
  '(luamagick
:programs ("lualatex" "convert")
:description "pdf > png"
:message "you need to install lualatex and imagemagick."
:use-xcolor t
:image-input-type "pdf"
:image-output-type "png"
:image-size-adjust (1.0 . 1.0)
:latex-compiler ("lualatex -interaction nonstopmode -output-directory 
%o %f")
:image-converter ("convert -density %D -trim -antialias %f -quality 100 
%O")))

(add-to-list 'org-preview-latex-process-alist luamagick)

(setq org-preview-latex-default-process 'luamagick)

Note that the -trim option for the "convert" program (last line) allows
you to crop the image from the pdf page.

Best regards,

Juan Manuel 

Re: Playing down the text in org-mode

[Juan Manuel Macías]

Hi,

fatiparty--- via "General discussions about Org-mode." writes:

> Is there anything to perform the opposite, playing down the text?

Are you referring to nested emphasis, something like in LaTeX

\emph{foo \emph{bar} baz}

= foo...baz in italic; bar in normal font?

Best regards,

Juan Manuel 

Re: Playing down the text in org-mode

[Juan Manuel Macías]

John Kitchin writes:

> It depends on what you mean. I can't think of a standard markup for
> de-emphasis. You could imply it with color perhaps, e.g. some shade of
> grey, or size  by making it smaller. At least for LaTex/HTML, both of
> those can be done. You would either need to use something like a
> macro, or a link for something like that I think.

The problem is that the concept of nested emphasis only works in LaTeX.
I agree that a macro would be a good solution, putting the argument in
'normal' text. An approximation could be:

#+begin_src emacs-lisp
  (defun macro-no-emph (arg)
(let* ((backend org-export-current-backend))
  (cond ((eq org-export-current-backend 'latex)
 (concat "@@latex:{\\normalfont @@" arg "@@latex:}@@"))
((eq org-export-current-backend 'html)
 (concat "@@html:@@" arg 
"@@html:@@"))
((eq org-export-current-backend 'odt)
 ;; a character style `normal' must be definded for odt
 (concat "@@odt:@@" arg 
"@@odt:@@")

  (setq org-export-global-macros
'(("noemph" . "(eval (mi-macro-emph $1))")))
#+end_src

/foo {{{noemph(bar)}}} baz/

Re: Playing down the text in org-mode

[Juan Manuel Macías]

fatiparty--- via "General discussions about Org-mode." writes:

> _a geographical region that corresponds to present-day Israel and Palestine_

In any case, from a strictly (ortho)typographical point of view this is a
matter of nesting emphasis. If what you want to do is highlight a word
within another emphasis (an underline), the correct typographical
procedure is to italicize or bold that word:

_a /geographical/ region that corresponds to present-day Israel and
Palestine_

==>

\uline{a \emph{geographical} region that corresponds to present-day
Israel and Palestine}

What you can't do in Org is nest emphases of the same order:

#+begin_example
/The translators of the /Odyssey/ in the Hispanic tradiction/
#+end_example

It does not produce in LaTeX:

#+begin_src latex
  \emph{The translators of the \emph{Odyssey} in the Hispanic tradiction}
#+end_src

It is not a matter of a passage being de-emphasized (it doesn't work
that way), but rather that it is emphasized within another emphasis
text. In the above case, the way to emphasize Odyssey in a text already
emphasized in italics is with a normal font or with an underline (the
correct thing is with a normal font).

There are two separate questions here: how that is represented in Org
and how it should be exported.

Re: Playing down the text in org-mode

[Juan Manuel Macías]

fatipa...@tutanota.com writes:

> I am discussing something slightly different.
>
> Here is normal text within -which there is some understated text- before 
> continuing with normal text.

Yes, it seems that I have understood you horribly wrong, sorry for the
noise (it must be the effects of the third modern vaccine that they gave
me yesterday :-)

In short, what you want is that a part of the text is "obscured" in some
way with respect to the main body text, and you would like Org to have
some marks for it. I see an important basic problem: there are many
procedures to reduce the reading importance of a text: simply pass that
text to a footnote, use dashes, parentheses or brackets, put the text in
a smaller size (which is the usual when these passages are isolated
paragraphs). I think it is better to define all these questions in the
output formats, through post-processing, and in Org use macros, custom
links, special blocks, the procedure that John has shared here, etc. But a
"universal" no-emphasis mark doesn't seem viable to me, IMHO.

Best regards,

Juan Manuel 

Re: Playing down the text in org-mode

[Juan Manuel Macías]

fatipa...@tutanota.com writes:

> If I do something in emacs-lisp I would still need some form of
> containment characters.

I think a custom link would suffice for text within the paragraph. A
quick example:

#+begin_src emacs-lisp 
  (defface smaller
  '((t :foreground "#8D8D84" :height 0.9))
  "")

  (org-link-set-parameters "smaller"
   :face 'smaller
   :export (lambda (path desc format)
 (cond
  ((eq format 'latex)
   (format "{\\small %s}" desc)
#+end_src

This text is important, [[smaller:x][but this one is not so important]]

A screenshot:

https://i.imgur.com/11KbJHQ.png

if you want finer tuning and more control over the format, John's
scimax-editmarks package seems like a very interesting option (although
I think Org should remain as format-agnostic as possible...)

Best regards,

Juan Manuel