emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* Re: A simple Lua filter for Pandoc
  @ 2022-01-04 15:11 10%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-04 15:11 UTC (permalink / raw)
  To: orgmode

Hi Timothy:

Timothy writes:

> I’m quite interested in this, thanks for sharing. In fact, I’ll probably add
> this to <https://github.com/tecosaur/org-pandoc-import>.

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 


^ permalink raw reply	[relevance 10%]

* Re: A simple Lua filter for Pandoc
  2022-01-04 10:14  9% A simple Lua filter for Pandoc Juan Manuel Macías
  @ 2022-01-04 14:05  6% ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2022-01-04 14:05 UTC (permalink / raw)
  To: emacs-orgmode

On 04/01/2022 17:14, Juan Manuel Macías wrote:
> 
> Very often I need to convert docx documents to Org. ...
> 
>    local chars = {["/"] = "\\slash{}", ["*"] = "\\lowast{}", ["<"] = "\\lt{}",
> 	  [">"] = "\\gt{}", ["†"] = "\\dagger{}", [utf8.char(0x00A0)] = "\\nbsp{}"}
> ...
> pandoc -f markdown -t org --lua-filter=entities.lua <<< $str

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.




^ permalink raw reply	[relevance 6%]

* A simple Lua filter for Pandoc
@ 2022-01-04 10:14  9% Juan Manuel Macías
    2022-01-04 14:05  6% ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-04 10:14 UTC (permalink / raw)
  To: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-09 22:27 12%                                 ` Juan Manuel Macías
@ 2022-01-03 14:34  4%                                   ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2022-01-03 14:34 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

On 10/12/2021 05:27, Juan Manuel Macías wrote:
> 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?

I have no particular opinion concerning aliases, but certainly they 
should not work through string search and replace when parsed tree is 
available.

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

By the way, is there any problem with `replace-regexp-in-string'?

See the attached file for definitions of some helper functions. Final setup:

#+begin_src elisp :results silent
   (setq orgia-demo-alias-alist
	'((b . bold)
	  (i . italic)
	  (s . strike-through)
	  (_ . underline)))

   (defun orgia-demo-alias-post-filter (node &optional _children)
     (when (listp node)
       (let ((sym (and (symbolp (car node))
		      (assq (car node) orgia-demo-alias-alist))))
	(when sym
	  (setcar node (cdr sym)))))
     node)

   (defun orgia-demo-alias (tree)
     (orgia-transform-tree-deep tree nil #'orgia-demo-alias-post-filter))
#+end_src

#+begin_src elisp :results silent
   (require 'ox)
   (add-to-list 'org-export-filter-parse-tree-functions 
#'orgia-parse-tree-filter)
   (org-link-set-parameters "orgia")

   (require 'ob-org)
   (add-to-list 'orgia-transform-functions #'orgia-demo-alias)
#+end_src

And a bit modified your test sample:

#+begin_src org :results latex :results replace
   [[orgia:(i nil "The English versions of the " (b nil (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

[-- Attachment #2: orgia-draft.el --]
[-- Type: text/x-emacs-lisp, Size: 2080 bytes --]

(defvar orgia-transform-functions nil)

(defun orgia-default-pre-filter (node)
  "Returns (node . children)"
  (if (listp node)
      (cons node node)
    (cons node nil)))

(defun orgia-transform-tree-deep (tree &optional pre-filter post-filter)
  "Deep-first walk."
  ;; Queue items: ((node-cell . children) . next-list)
  (let* ((pre-filter (or pre-filter #'orgia-default-pre-filter))
	 (top (list tree))
	 (queue (list (cons (cons top top) top))))
    (while queue
      (let* ((item (pop queue))
	     (next-list (cdr item)))
	(if (not next-list)
	    ;; post; skip POST-FILTER for the list wrapping TREE
	    (when (and queue post-filter)
	      (let* ((node-cell-children (car item))
		     (children (cdr node-cell-children)))
		(setcar (car node-cell-children)
			(funcall post-filter
				 (caar node-cell-children)
				 children))))
	  ;; pre
	  (setcdr item (cdr next-list))
	  (push item queue)
	  (let* ((node-children
		  (funcall pre-filter (car next-list)))
		 (node (car node-children))
		 (children (cdr node-children)))
		(setcar next-list node)
		(push (cons (cons next-list children) children) queue)))))
    (car top)))

(defun orgia-element-replace (current new destructive?)
  (if (eq current new)
      current
    (let* ((lst? (and (listp new) (not (symbolp (car new)))))
	   (new-lst (if lst?
			(if destructive? (nconc new) (reverse new))
		      (list new))))
      (dolist (element new-lst)
	(org-element-insert-before element current)))
    (org-element-extract-element current)
    new))

(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))
	(let ((tree (read path)))
	  (dolist (f orgia-transform-functions tree)
	    (setq tree (funcall f tree))))))))

(defun orgia-parse-tree-filter (data _backend info)
  (org-element-map data 'link
    (lambda (data)
      (orgia-element-replace data (orgia--transform-link data) t))
    info nil nil t)
  data)

^ permalink raw reply	[relevance 4%]

* Re: [PATCH] Re: [BUG] Underlined text in parentheses is not exported correctly
  2021-12-31 14:43  4%     ` [PATCH] " Ihor Radchenko
@ 2022-01-01 11:28 10%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2022-01-01 11:28 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* [PATCH] Re: [BUG] Underlined text in parentheses is not exported correctly
  2021-12-31 11:31 10%   ` Juan Manuel Macías
@ 2021-12-31 14:43  4%     ` Ihor Radchenko
  2022-01-01 11:28 10%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-31 14:43 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

I agree with you. I think that the initial intention was to avoid
parsing things like (x+y)_1+x_2 as underline.

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.

Best,
Ihor


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-underline-parser-inside-parenthesis.patch --]
[-- Type: text/x-diff, Size: 2454 bytes --]

From 12272f1ea89c169dcbece009c3a227e354019366 Mon Sep 17 00:00:00 2001
Message-Id: <12272f1ea89c169dcbece009c3a227e354019366.1640961654.git.yantar92@gmail.com>
From: Ihor Radchenko <yantar92@gmail.com>
Date: Fri, 31 Dec 2021 22:39:03 +0800
Subject: [PATCH] Fix underline parser inside parenthesis

* lisp/org-element.el (org-element--object-lex): prioritise underline
parser over subscript.  `org-element-underline-parser' is more strict
compared to `org-element-subscript-parser'.
* testing/lisp/test-org-element.el (test-org-element/underline-parser):
Add test.

Fixes https://list.orgmode.org/87v8z52eom.fsf@posteo.net/T/#t
---
 lisp/org-element.el              |  8 ++++----
 testing/lisp/test-org-element.el | 11 ++++++++++-
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 45ddc79b7..c9d1d80bb 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4850,10 +4850,10 @@ (defun org-element--object-lex (restriction)
 		    (pcase (char-after)
 		      (?^ (and (memq 'superscript restriction)
 			       (org-element-superscript-parser)))
-		      (?_ (or (and (memq 'subscript restriction)
-				   (org-element-subscript-parser))
-			      (and (memq 'underline restriction)
-				   (org-element-underline-parser))))
+		      (?_ (or (and (memq 'underline restriction)
+				   (org-element-underline-parser))
+                              (and (memq 'subscript restriction)
+				   (org-element-subscript-parser))))
 		      (?* (and (memq 'bold restriction)
 			       (org-element-bold-parser)))
 		      (?/ (and (memq 'italic restriction)
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index 338204eab..b58d71c8c 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -2661,7 +2661,16 @@ (ert-deftest test-org-element/underline-parser ()
      (org-test-with-temp-text "_first line\nsecond line_"
        (org-element-map
 	   (org-element-parse-buffer) 'underline #'identity nil t)))
-    '("first line\nsecond line"))))
+    '("first line\nsecond line")))
+  ;; Starting after non-blank
+  (should
+   (eq 'underline
+       (org-test-with-temp-text "(_under<point>line_)"
+         (org-element-type (org-element-context)))))
+  (should-not
+   (eq 'underline
+       (org-test-with-temp-text "x_under<point>line_)"
+         (org-element-type (org-element-context))))))
 
 
 ;;;; Verbatim
-- 
2.32.0


^ permalink raw reply related	[relevance 4%]

* Re: [BUG] Underlined text in parentheses is not exported correctly
  2021-12-31 11:13  5% ` Ihor Radchenko
@ 2021-12-31 11:31 10%   ` Juan Manuel Macías
  2021-12-31 14:43  4%     ` [PATCH] " Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-31 11:31 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: [BUG] Underlined text in parentheses is not exported correctly
  2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
  2021-12-31 11:08 12% ` Juan Manuel Macías
@ 2021-12-31 11:13  5% ` Ihor Radchenko
  2021-12-31 11:31 10%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-31 11:13 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I don't know if this is a known issue...
>
> Consider the text:
>
> (_underline_)

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.

Unless Nicolas (the author of this code) sees anything wrong here, I
recommend you to use zero-width space in front of the first _ to make
sure that you obtain underline, not subscripts (see
https://orgmode.org/manual/Escape-Character.html#Escape-Character)

P.S.
Note that the fontification you observe in Org is wrong. It is not how
the actual exporter sees the text. I am sorry about this. Fixing the
fontification is a work-in-progress.

Best,
Ihor



^ permalink raw reply	[relevance 5%]

* Re: [BUG] Underlined text in parentheses is not exported correctly
  2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
@ 2021-12-31 11:08 12% ` Juan Manuel Macías
  2021-12-31 11:13  5% ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-31 11:08 UTC (permalink / raw)
  To: orgmode

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


^ permalink raw reply	[relevance 12%]

* [BUG] Underlined text in parentheses is not exported correctly
@ 2021-12-31 10:14 10% Juan Manuel Macías
  2021-12-31 11:08 12% ` Juan Manuel Macías
  2021-12-31 11:13  5% ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-31 10:14 UTC (permalink / raw)
  To: orgmode

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:

(<sub>underline</sub>_)

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 


^ permalink raw reply	[relevance 10%]

* Re: caption width in LateX export
  2021-12-27 17:16  6%       ` Sebastian P. Luque
@ 2021-12-27 19:28  5%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27 19:28 UTC (permalink / raw)
  To: orgmode

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


^ permalink raw reply	[relevance 5%]

* Re: caption width in LateX export
  2021-12-27 13:28  8%     ` Juan Manuel Macías
@ 2021-12-27 17:16  6%       ` Sebastian P. Luque
  2021-12-27 19:28  5%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Sebastian P. Luque @ 2021-12-27 17:16 UTC (permalink / raw)
  To: emacs-orgmode

On Mon, 27 Dec 2021 13:28:08 +0000,
Juan Manuel Macías <maciaschain@posteo.net> wrote:

> 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"))

I haven't tried this yet, but it's great to know latexmk can use LuaTex.


> 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\\1\\\\end{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,

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

Thank you,
-- 
Seb



^ permalink raw reply	[relevance 6%]

* Re: caption width in LateX export
  2021-12-27 12:53  6%   ` Sebastian P. Luque
@ 2021-12-27 13:28  8%     ` Juan Manuel Macías
  2021-12-27 17:16  6%       ` Sebastian P. Luque
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-27 13:28 UTC (permalink / raw)
  To: Sebastian P. Luque; +Cc: orgmode

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\\1\\\\end{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 


^ permalink raw reply	[relevance 8%]

* Re: caption width in LateX export
  2021-12-27  7:41 10% ` Juan Manuel Macías
  2021-12-27  9:09 12%   ` Juan Manuel Macías
@ 2021-12-27 12:53  6%   ` Sebastian P. Luque
  2021-12-27 13:28  8%     ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Sebastian P. Luque @ 2021-12-27 12:53 UTC (permalink / raw)
  To: emacs-orgmode

On Mon, 27 Dec 2021 07:41:59 +0000,
Juan Manuel Macías <maciaschain@posteo.net> wrote:

[...]

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

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:

#+LATEX_HEADER: \usepackage{caption}

See [[fig1]].

#+NAME: fig1
#+ATTR_LATEX: :caption \captionsetup{width=0.5\textwidth}\caption{Lorem ipsum dolor sit amet, consectetuer adipiscing elit}
[[file_path]]

leads to this (I compile with latexmk):

Latexmk: Summary of warnings from last run of *latex:
  Latex failed to resolve 1 reference(s)


-- 
Seb



^ permalink raw reply	[relevance 6%]

* Re: caption width in LateX export
  2021-12-27  7:41 10% ` Juan Manuel Macías
@ 2021-12-27  9:09 12%   ` Juan Manuel Macías
  2021-12-27 12:53  6%   ` Sebastian P. Luque
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27  9:09 UTC (permalink / raw)
  To: Seb; +Cc: orgmode

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: <<luacode>>
#+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]]


^ permalink raw reply	[relevance 12%]

* Re: caption width in LateX export
  @ 2021-12-27  7:41 10% ` Juan Manuel Macías
  2021-12-27  9:09 12%   ` Juan Manuel Macías
  2021-12-27 12:53  6%   ` Sebastian P. Luque
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-27  7:41 UTC (permalink / raw)
  To: Seb; +Cc: orgmode

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: looooooong 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 


^ permalink raw reply	[relevance 10%]

* Re: text after sub headings?
  2021-12-25 13:15  4%       ` Max Nikulin
@ 2021-12-26  9:17  8%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-26  9:17 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]

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 


[-- Attachment #2: tests.org --]
[-- Type: application/vnd.lotus-organizer, Size: 16218 bytes --]

^ permalink raw reply	[relevance 8%]

* Re: text after sub headings?
  2021-12-24 20:17  5%     ` Juan Manuel Macías
@ 2021-12-25 13:15  4%       ` Max Nikulin
  2021-12-26  9:17  8%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-25 13:15 UTC (permalink / raw)
  To: emacs-orgmode

On 25/12/2021 03:17, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> 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.

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.

This particular examples has internal structure:
http://algorithmics.lsi.upc.edu/docs/Dasgupta-Papadimitriou-Vazirani.pdf#page=135

Book reader on small phone screen might require a tap to show all 
additional material. On wide screen in may appear on margins and visible 
by default. In Org it migh remain collapsed when heading is expanded 
while text around is visible.

I have not worked with complex documents in DTP programs. In my opinion, 
LaTeX deals much better with figures (plots, drawings) in scientific 
papers than office software. When users complains that LaTeX puts at 
their figures and table at the end of the document it usually means that 
they copy-pasted markup explicitly forbidding most of usual places for 
floats (e.g. page completely filled with figures).

It is possible to create insets in Org Mode document, but it is not 
native support.

In a bit broader sense insets do not violates tree structure

- Branch: Section Heading
   - Leaf: section text
   - Branch: Inset section Heading
     - Leaf: inset section text
     - Branch: Inset Subsection Heading 1
       - Leaf: Inset subsection 1 text
     - Branch: Inset Subsection Heading 2
       - Leaf: Inset subsection 2 text
   - Leaf: section text continues

Another example when it is convenient to have text itermixed with 
headings is notes. Tree structure is too rigid, particular note may be 
appropriate to several topics. Important point that sometimes it is 
better to have particular order within some topic, if ordering is not 
required than all links may appear before subheadings. So not text is 
put to one topic, other ones contains links. Ideally it should appear like

* Topic 2
   some general notes
*** Note 2.1...
*** Note 2.2...
   [[#note_from_other_topic1]]
   contains some interesting details
*** Note 2.4...
   [[#note_from_other_topic2]]
   contains other interesting details
*** Note 2.6...

It would be nice to have links visually distinct from headings and there 
is no real reason to collapse link if description text is just a couple 
of line.

I do not ask to change anything. I admit that nobody has bright idea how 
to properly implement it. I am just against statements that Org is ideal 
in respect to sectioning and covers all use cases. My opinion that it is 
limitation, there are some workarounds and trade-offs for each 
particular case. Anyway there is no unambiguously better tool.



^ permalink raw reply	[relevance 4%]

* Re: text after sub headings?
  2021-12-24 16:51  4%   ` Max Nikulin
@ 2021-12-24 20:17  5%     ` Juan Manuel Macías
  2021-12-25 13:15  4%       ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-24 20:17 UTC (permalink / raw)
  To: orgmode

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.


^ permalink raw reply	[relevance 5%]

* Re: text after sub headings?
  2021-12-23 20:27  8% ` Juan Manuel Macías
@ 2021-12-24 16:51  4%   ` Max Nikulin
  2021-12-24 20:17  5%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-24 16:51 UTC (permalink / raw)
  To: emacs-orgmode

On 24/12/2021 03:27, Juan Manuel Macías wrote:
> 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.

While considered isolated, vim feature "set foldmethod=marker" with 
explicit open and closed markers ("{{{" and "}}}" by default) is more 
flexible. There are at least 2 problems with Org: performance penalty 
and rather reach lightweight markup, so a lot of marker variants are 
busy already.

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

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.

Export filter may solve the problem by treating specially marked 
headings as continuation of text.

Aside from export, it may be notes interspersed with deeper details 
(debug logs, etc.) It would be nice to be able to switch between 2 
reading modes: all details are collapsed to quickly skim through main 
steps and conclusions or all details are open (in particular subtree).

Plain list items, #+begin_/#+end_ blocks may be folded, drawers may be 
expanded but only individually. Besides list items, deeper nested 
substructure may be a problem, e.g. neither of them may contain 
headings. Using of such construct is not perfect but mostly bearable.

The following is not a feature request just some thoughts how to achieve 
convenient reading without heading closing syntax.

In addition to current heading visibility cycle, there may be commands 
increasing or decreasing "zoom level" for the whole document or for the 
current subtree. Headings may have a "lense" property that may change 
zoom level when such section becomes visible (absolute value or relative 
adjustment in respect to parent, positive or negative). So in response 
to "zoom in" command some headings are unfolded, some remains collapsed. 
Visibility effect to some extent is similar to explicit end of subheading.



^ permalink raw reply	[relevance 4%]

* Re: text after sub headings?
  2021-12-23 21:21  5% Robert Nikander
  2021-12-23 21:47  0% ` John Kitchin
@ 2021-12-23 22:10  6% ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-23 22:10 UTC (permalink / raw)
  To: Robert Nikander; +Cc: orgmode

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”




^ permalink raw reply	[relevance 6%]

* Re: text after sub headings?
  2021-12-23 21:21  5% Robert Nikander
@ 2021-12-23 21:47  0% ` John Kitchin
  2021-12-23 22:10  6% ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: John Kitchin @ 2021-12-23 21:47 UTC (permalink / raw)
  To: Robert Nikander; +Cc: org-mode-email

[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]

You can also use drawers (as an alternative to inline tasks) for
collapsible content.

Another potential is to use blocks. You can define your own kind of blocks,
or even just use an org block and it is collapsible.

John

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



On Thu, Dec 23, 2021 at 4:22 PM Robert Nikander <robert.nikander@icloud.com>
wrote:

> Max Nikulin wrote:
> > Have you seen the following and links therein?
> > https://orgmode.org/worg/org-faq.html#closing-outline-sections
>
> No, I hadn't found that. Thanks. Those links answer my question.
>
> Juan Manuel Macías wrote:
> > 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
> > […]
>
> I see your point.
>
> Maybe it depends on how you use org-mode and how you imagine the meaning
> of the "*" items. I see some disagreement about this in the old threads
> that Max linked to. No need to rehash it deeply here again; I was just
> curious.
>
> The way I'm using org-mode so far, I'm not exporting to other formats, and
> I can see a use for collapsible sections in the middle of a larger chunk of
> text. I can already kind of do it with a "-" list item, like this. (Or
> other things like code blocks, etc)
>
> * Heading
> Top Text
> Top Text
> - Sub
>   This can be hidden if I hit 'tab' key on "Sub".
> More Top Text
> More Top Text
>
> 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.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2809 bytes --]

^ permalink raw reply	[relevance 0%]

* Re: text after sub headings?
@ 2021-12-23 21:21  5% Robert Nikander
  2021-12-23 21:47  0% ` John Kitchin
  2021-12-23 22:10  6% ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Robert Nikander @ 2021-12-23 21:21 UTC (permalink / raw)
  To: emacs-orgmode

Max Nikulin wrote:
> Have you seen the following and links therein?
> https://orgmode.org/worg/org-faq.html#closing-outline-sections

No, I hadn't found that. Thanks. Those links answer my question.

Juan Manuel Macías wrote:
> 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
> […]

I see your point.

Maybe it depends on how you use org-mode and how you imagine the meaning of the "*" items. I see some disagreement about this in the old threads that Max linked to. No need to rehash it deeply here again; I was just curious. 

The way I'm using org-mode so far, I'm not exporting to other formats, and I can see a use for collapsible sections in the middle of a larger chunk of text. I can already kind of do it with a "-" list item, like this. (Or other things like code blocks, etc)

* Heading
Top Text
Top Text
- Sub
  This can be hidden if I hit 'tab' key on "Sub".
More Top Text
More Top Text

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. 




^ permalink raw reply	[relevance 5%]

* Re: text after sub headings?
  @ 2021-12-23 20:27  8% ` Juan Manuel Macías
  2021-12-24 16:51  4%   ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-23 20:27 UTC (permalink / raw)
  To: Robert Nikander; +Cc: orgmode

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 




^ permalink raw reply	[relevance 8%]

* Re: format/fill of text in a cell in tables
  @ 2021-12-18 11:09  8%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-18 11:09 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

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 





^ permalink raw reply	[relevance 8%]

* Re: format/fill of text in a cell in tables
  @ 2021-12-17 21:25  6%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-17 21:25 UTC (permalink / raw)
  To: tomas; +Cc: orgmode

tomas@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 


^ permalink raw reply	[relevance 6%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-09 16:11  6%                               ` Juan Manuel Macías
@ 2021-12-09 22:27 12%                                 ` Juan Manuel Macías
  2022-01-03 14:34  4%                                   ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09 22:27 UTC (permalink / raw)
  To: Maxim Nikulin; +Cc: orgmode

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 <orgia:(\"in\" (s:: \"ter\"))>word"
'odt t)
#+end_src

#+RESULTS:
: 
: <text:p text:style-name="Text_20_body">An in<text:span text:style-name="Strikethrough">ter</text:span>word</text:p>


#+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/



^ permalink raw reply	[relevance 12%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-09 14:56  5%                             ` Max Nikulin
@ 2021-12-09 16:11  6%                               ` Juan Manuel Macías
  2021-12-09 22:27 12%                                 ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09 16:11 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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


^ permalink raw reply	[relevance 6%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-09  7:01  5%                           ` Juan Manuel Macías
@ 2021-12-09 14:56  5%                             ` Max Nikulin
  2021-12-09 16:11  6%                               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-09 14:56 UTC (permalink / raw)
  To: emacs-orgmode

On 09/12/2021 14:01, Juan Manuel Macías wrote:
> 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.

Either I missed something or its purpose is completely different. It 
maps Org markup to Org markup. I am experimenting with fragments that 
should allow to get something that is really tricky or even impossible 
with established syntax, so it has to run immediately before exporters.

> 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

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.

#+begin_src elisp :results silent
   (defun orgia-element-replace (current new destructive?)
     (if (eq current new)
	current
       (let* ((lst? (and (listp new) (not (symbolp (car new)))))
	     (new-lst (if lst?
			  (if destructive? (nconc new) (reverse new))
			(list new))))
	(dolist (element new-lst)
	  (org-element-insert-before element current)))
       (org-element-extract-element current)
       new))

   (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 path)))))

   (defun orgia-parse-tree-filter (data _backend info)
     (org-element-map data 'link
       (lambda (data)
	(orgia-element-replace data (orgia--transform-link data) t))
       info nil nil t)
     data)
#+end_src

#+begin_src elisp :results silent
   (add-to-list 'org-export-filter-parse-tree-functions 
#'orgia-parse-tree-filter)

   (org-link-set-parameters "orgia")
#+end_src


#+begin_src elisp
   (org-export-string-as "An <orgia:(\"in\" (italic () \"ter\"))>word" 
'html t)
#+end_src

#+RESULTS:
: <p>
: An in<i>ter</i>word</p>



^ permalink raw reply	[relevance 5%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-08 23:35  6%                         ` John Kitchin
@ 2021-12-09  7:01  5%                           ` Juan Manuel Macías
  2021-12-09 14:56  5%                             ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-09  7:01 UTC (permalink / raw)
  To: John Kitchin; +Cc: Maxim Nikulin, orgmode

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}

<p>
<blockquote>
Publicamos nuestro libros
 para librarnos de ellos, para no pasar el resto de nuestras vidas
 corrigiendo borradores.
</blockquote>
</p>


<text:p text:style-name="Text_20_body">Publicamos nuestro libros
 para librarnos de ellos, para no pasar el resto de nuestras vidas
 corrigiendo borradores.</text:p>
#+end_example



^ permalink raw reply	[relevance 5%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-08 23:19  9%                       ` Juan Manuel Macías
@ 2021-12-08 23:35  6%                         ` John Kitchin
  2021-12-09  7:01  5%                           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-12-08 23:35 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, orgmode

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

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.

On Wed, Dec 8, 2021 at 6:20 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> 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 "<orgia:(verse-block ()
> \"Lorem\\nipsum\\ndolor\")>" 'html t)
> #+end_src
>
> #+RESULTS:
> : <p>
> : <p class="verse">
> : Lorem<br />
> : ipsum<br />
> : dolor</p>
> : </p>
>
> #+begin_src elisp
>   (org-export-string-as "<orgia:(quote-block (:attr_latex
>          (\":environment foreigndisplayquote :options {greek}\"))
>          \"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
>          Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" '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
>
-- 
John

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

[-- Attachment #2: Type: text/html, Size: 3121 bytes --]

^ permalink raw reply	[relevance 6%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-08 13:09  4%                     ` Max Nikulin
@ 2021-12-08 23:19  9%                       ` Juan Manuel Macías
  2021-12-08 23:35  6%                         ` John Kitchin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-08 23:19 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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 "<orgia:(verse-block () \"Lorem\\nipsum\\ndolor\")>" 'html t)
#+end_src

#+RESULTS:
: <p>
: <p class="verse">
: Lorem<br />
: ipsum<br />
: dolor</p>
: </p>

#+begin_src elisp
  (org-export-string-as "<orgia:(quote-block (:attr_latex
	 (\":environment foreigndisplayquote :options {greek}\"))
	 \"Δαρείου καὶ Παρυσάτιδος γίγνονται παῖδες δύο, πρεσβύτερος μὲν
	 Ἀρταξέρξης, νεώτερος δὲ Κῦρος·\")>" '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 

^ permalink raw reply	[relevance 9%]

* Re: Making a dictionary in Org
  2021-12-08 20:03 12% Making a dictionary in Org Juan Manuel Macías
@ 2021-12-08 23:13  6% ` Thomas S. Dye
  0 siblings, 0 replies; 200+ results
From: Thomas S. Dye @ 2021-12-08 23:13 UTC (permalink / raw)
  To: emacs-orgmode


Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Nice work!

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye


^ permalink raw reply	[relevance 6%]

* Making a dictionary in Org
@ 2021-12-08 20:03 12% Juan Manuel Macías
  2021-12-08 23:13  6% ` Thomas S. Dye
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-08 20:03 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

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/

[-- Attachment #2: dictionary.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1218 bytes --]

^ permalink raw reply	[relevance 12%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-06 15:45  8%                   ` Juan Manuel Macías
  2021-12-06 16:56 13%                     ` Juan Manuel Macías
@ 2021-12-08 13:09  4%                     ` Max Nikulin
  2021-12-08 23:19  9%                       ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-08 13:09 UTC (permalink / raw)
  To: emacs-orgmode

On 06/12/2021 22:45, Juan Manuel Macías wrote:
> 
> 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:

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

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:

#+begin_src elisp :results silent
   (defun orgia-link (link-data desc info)
     (let* ((backend-struct (plist-get info :back-end))
	   (backend-name (org-export-backend-name backend-struct)))
       (or
        (org-export-custom-protocol-maybe link-data desc backend-name info)
        (let* ((parent (org-export-backend-parent backend-struct))
	      (transcoders-alist (org-export-get-all-transcoders parent))
	      (link-transcoder (alist-get 'link transcoders-alist)))
	 (if link-transcoder
	     (funcall link-transcoder link-data desc info)
	   desc)))))

   (defun evilatex-emph (_emph content info)
     ;; I have no idea yet why newline is appended.
     (format "\\textit{%s}%%" content))

   (org-export-define-derived-backend 'evilatex 'latex
     :translate-alist '((emph . evilatex-emph)
		       (link . orgia-link)))
#+end_src

#+begin_src elisp
   (let ((org-export-with-broken-links 'mark))
     (org-export-string-as
      "An [[orgia:(italic () \"ex\")]]ample of <orgia:(emph () 
\"inter\")>word and [[http://te.st][link]] [[unknown:prefix][desc]]!"
      'evilatex t))
#+end_src

#+RESULTS:
: An \emph{ex}ample of \textit{inter}%
: word and \href{http://te.st}{link} [BROKEN LINK: unknown:prefix]!

Actually, I believe that something like orgia-link code should be added 
by `org-exprot-define-derived-backend' if "link" is missed in 
translate-alist. I suspect that `org-export-get-all-transcoders' may be 
avoided.

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

Sorry, I have not prepared better variant to solve comma in macro 
problem yet.




^ permalink raw reply	[relevance 4%]

* Re: Raw Org AST snippets for "impossible" markup
  2021-12-06 15:45  8%                   ` Juan Manuel Macías
@ 2021-12-06 16:56 13%                     ` Juan Manuel Macías
  2021-12-08 13:09  4%                     ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 16:56 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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 


^ permalink raw reply	[relevance 13%]

* Re: Raw Org AST snippets for "impossible" markup
  @ 2021-12-06 15:45  8%                   ` Juan Manuel Macías
  2021-12-06 16:56 13%                     ` Juan Manuel Macías
  2021-12-08 13:09  4%                     ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 15:45 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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 <orgia:((italic () "inter") "word")>
> links may be used. Certainly plain text may be outside:
>
> #+begin_src elisp
>    (org-export-string-as "A <orgia:(italic () \"inter\")>word" 'html t)
> #+end_src
>
> #+RESULTS:
> : <p>
> : A <i>inter</i>word</p>
>
> - 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:<em>@@" arg "@@html:</em>@@"))
	  ((org-export-derived-backend-p org-export-current-backend 'odt)
	   (concat "@@odt:<text:span text:style-name=\"Emphasis\">@@" arg "@@odt:</text:span>@@"))))

  (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 


^ permalink raw reply	[relevance 8%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  @ 2021-12-06 14:59  9%                     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-06 14:59 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  @ 2021-12-06  7:24  9%                 ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-06  7:24 UTC (permalink / raw)
  To: Timothy; +Cc: emacs-orgmode

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 






^ permalink raw reply	[relevance 9%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 23:24  4%           ` Russell Adams
@ 2021-12-06  5:57 10%             ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-06  5:57 UTC (permalink / raw)
  To: Russell Adams; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 18:59  7%         ` Juan Manuel Macías
@ 2021-12-05 23:24  4%           ` Russell Adams
  2021-12-06  5:57 10%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Russell Adams @ 2021-12-05 23:24 UTC (permalink / raw)
  To: emacs-orgmode

On Sun, Dec 05, 2021 at 06:59:20PM +0000, Juan Manuel Macías wrote:
> Frustration every time I want to recommend Org to many of my friends
> and colleagues, who don't even use Emacs.

I think this is the core of every interoperability argument: "Why do
we have to use Emacs to use Org?" It's called Emacs Org-mode for a
reason. Org-mode doesn't work outside of Emacs.

I've often told users that it's worth learning enough Emacs to use
Org, and have successfully moved several non-power users over to
Emacs. They know enough to consistently open their files, edit Org,
and quit. That's enough. They complain it's "ugly" compared to
"modern" GUI tools, but they can't deny the utility.

> I came to Org been an Emacs user already, so I was reasonably familiar
> with Emacs and Elisp, although what I used most was AUCTeX (and Markdown
> for my docs).

I'd have a hard time convincing users in Mordor to use a plain text
format, much less Org without Emacs.

> On the other hand, Org as a lightweight markup language is only
> a tiny part of Org. I don't think Org is better or worse as a markup
> language than Markdown, asciidoc or other similar formats.

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

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3


^ permalink raw reply	[relevance 4%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 12:08  3%       ` Ihor Radchenko
  2021-12-05 13:32  0%         ` Tim Cross
@ 2021-12-05 18:59  7%         ` Juan Manuel Macías
  2021-12-05 23:24  4%           ` Russell Adams
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-05 18:59 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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 room on one of the upper floors. In the
Org-room (including Org-Roam! :-) there is a lot of fun, great people,
great music. But whoever wants to get there must go through a series of
levels, intricate corridors that are like a kind of learning path. Emacs
is great, but you can't learn to use it in two days. It takes time to
adapt it to your needs, get to know it, even love it. Sorry to be so
metaphorical and poetic, but it is the only way I can find to explain
what is, in many ways, a personal learning process (even the init Emacs
file could be understood as a kind of autobiography...). I wish the entry
into Org was smoother and more direct, but being an Emacs mode, it is
necessary to go through Emacs. And this gets more crude for
non-technical, Humanities users, who I think could be very happy using
Org and not Word or other modern auto-torture methods :-)

I came to Org been an Emacs user already, so I was reasonably familiar
with Emacs and Elisp, although what I used most was AUCTeX (and Markdown
for my docs). I heard about Org but it never caught my attention, until
one day I read the Org compact guide and I was fascinated that such a
thing existed (and it was just the compact guide!).

TL; DR: I understand and share the maneuver of baiting new and potential
users. But I see it difficult. Users who have never used Emacs will have
to go through the Emacs learning process first, especially non-technical
users or those who come from the country of word processors, that is,
Mordor. On the other hand, Org as a lightweight markup language is only
a tiny part of Org. I don't think Org is better or worse as a markup
language than Markdown, asciidoc or other similar formats. I think the
important thing about Org here is the integration of a series of
resources: a whole that is more important than the sum of the parts
(https://en.wikipedia.org/wiki/Emergentism).

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 7%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 12:08  3%       ` Ihor Radchenko
@ 2021-12-05 13:32  0%         ` Tim Cross
  2021-12-05 18:59  7%         ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2021-12-05 13:32 UTC (permalink / raw)
  To: emacs-orgmode


Ihor Radchenko <yantar92@gmail.com> writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> 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.
>
> 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]).
>

I think your working off a false premise. Your view is that org mode
should be available in other editors/software so that others can realise
the power and benefits it provides. I can understand that position.

However, the FSF position would be exactly the opposite. They would
argue that orgmode is a powerful and flexible tool that is part of Emacs
and if you want that power and flexibility, you need to use Emacs. Org
mode has probably done more to bring new users to Emacs than any other
Emacs mode in the last 30 years. As a consequence, you will find not
only little support towards making it available in other editors, you
are likely to run into active resistance. As you say, org-mode can be
thought of as a brand name and that is a brand name owned by the FSF as
an official GNU project and a goal of the FSF is to convert people to
use GNU free software. Anything which has the potential to take the
power of org mode and make it available in non-free software (not simply
open source) is not going to be supported or welcomed.




^ permalink raw reply	[relevance 0%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05  9:16  9% ` Juan Manuel Macías
  2021-12-05 10:24  5%   ` Ihor Radchenko
@ 2021-12-05 13:06  4%   ` Tim Cross
  1 sibling, 0 replies; 200+ results
From: Tim Cross @ 2021-12-05 13:06 UTC (permalink / raw)
  To: emacs-orgmode


Juan Manuel Macías <maciaschain@posteo.net> writes:

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

There is another big issue which people are not considering.

Org mode is a GNU project and it is part of Emacs. This actually has
some consequences, most notably -

- It is not acceptable for the project to explicitly or implicitly
  recommend or appear to recommend any non-free solutions or provide
  support for non-free software. Products like Github and MS Visual Code
  fall squarely in the unacceptable bucket.

- It would not be possible to reference any 3rd party libraries or
  programs which are not free software in the proposed list of external
  tools

- The suggested org mode in a browser example is unlikely to be
  acceptable to the FSF (or RMS). The FSF is very much against cloud
  based computing services or any web service which uses non-free
  Javascript (which is most of them and one of the many reasons Github
  is discouraged by the FSF).

A number of the ideas proposed are good ideas for org mode generally -
for example, a repository of reference documents which could be used for
testing purposes would be extremely useful for org-mode development and
testing. Likewise, any effort to clarify the syntax and remove any
ambiguities is beneficial for org mode itself. However, the emphasis and
priority needs to remain focused on org mode as a mode for Emacs. The
use of org mode by other external programs is really outside (but
related) to the project.

As a consequence and to eliminate/remove potential conflicts with FSF
philosophy and goals, it may be worth considering spinning off a
separate project. which happens to use the same markup syntax, but is
not a GNU project (though it would be good to still be GPL'd). 

If you want ot get a feel for the sort of issues which could come up
when trying to develop/support 3rd party tools, have a look at the
recent thread on creating an LSP server for emacs-lisp. While I
personally disagree with most of the fears raised by some contributors
to that thread and disagree with RMS's view that such a server would not
be in the best interests of Emacs, the thread does give you a sample of
the sort of issues which could come up with efforts to support or
encourage 3rd party libraries for org markup, much of which could be
avoided if the work is clearly not part of, related to or supported by
the main org-mode project. 


^ permalink raw reply	[relevance 4%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 11:08  9%     ` Juan Manuel Macías
  2021-12-05 11:54  6%       ` Heinz Tuechler
@ 2021-12-05 12:08  3%       ` Ihor Radchenko
  2021-12-05 13:32  0%         ` Tim Cross
  2021-12-05 18:59  7%         ` Juan Manuel Macías
  1 sibling, 2 replies; 200+ results
From: Ihor Radchenko @ 2021-12-05 12:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

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

Best,
Ihor




^ permalink raw reply	[relevance 3%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 11:08  9%     ` Juan Manuel Macías
@ 2021-12-05 11:54  6%       ` Heinz Tuechler
  2021-12-05 12:08  3%       ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Heinz Tuechler @ 2021-12-05 11:54 UTC (permalink / raw)
  To: emacs-orgmode

Juan Manuel Macías wrote/hat geschrieben on/am 05.12.2021 12:08:
> 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
>
>

As a humble emacs and org-mode user I second this "simple and subjectiv
opinion".
Therefore I would first mention org as an emacs mode and secondly as a
file format.

best regards,

Heinz


^ permalink raw reply	[relevance 6%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05 10:24  5%   ` Ihor Radchenko
@ 2021-12-05 11:08  9%     ` Juan Manuel Macías
  2021-12-05 11:54  6%       ` Heinz Tuechler
  2021-12-05 12:08  3%       ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-05 11:08 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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 



^ permalink raw reply	[relevance 9%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  2021-12-05  9:16  9% ` Juan Manuel Macías
@ 2021-12-05 10:24  5%   ` Ihor Radchenko
  2021-12-05 11:08  9%     ` Juan Manuel Macías
  2021-12-05 13:06  4%   ` Tim Cross
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-05 10:24 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I am not at all in favor of separating the 'Org Mode' name from 'GNU
> Emacs'.

To clarify, I do not suggest to remove the linkage between Org mode and
GNU Emacs. Just change the emphasis. I had no intention to remove the
reference to Emacs from search result. It should be still there in the
short description of orgmode.org. See the second part of my suggestion
#1.

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

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

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

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.

Best,
Ihor



^ permalink raw reply	[relevance 5%]

* Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
  @ 2021-12-05  9:16  9% ` Juan Manuel Macías
  2021-12-05 10:24  5%   ` Ihor Radchenko
  2021-12-05 13:06  4%   ` Tim Cross
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-05  9:16 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-04 21:16  9%                 ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 21:16 UTC (permalink / raw)
  To: John Kitchin; +Cc: orgmode

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


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: emphasis and not English punctuation
  2021-12-04 13:07  5%             ` Org-syntax: emphasis and not English punctuation Max Nikulin
@ 2021-12-04 16:42  9%               ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04 16:42 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: emphasis and not English punctuation
  2021-12-02 19:09  9%           ` Juan Manuel Macías
@ 2021-12-04 13:07  5%             ` Max Nikulin
  2021-12-04 16:42  9%               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-12-04 13:07 UTC (permalink / raw)
  To: emacs-orgmode

On 03/12/2021 02:09, Juan Manuel Macías wrote:
> 
> 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

Maybe this issue should be considered independently of itra-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 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



^ permalink raw reply	[relevance 5%]

* Re: On zero width spaces and Org syntax
  2021-12-03 12:48  8% On zero width spaces and Org syntax Juan Manuel Macías
    2021-12-03 21:48  3% ` Tim Cross
@ 2021-12-04  6:43  5% ` Marcin Borkowski
  2 siblings, 0 replies; 200+ results
From: Marcin Borkowski @ 2021-12-04  6:43 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


On 2021-12-03, at 13:48, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> 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'),
> '&#x200B;' 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:

Hi all,

I've skimmed through this discussion.  FWIW, I also use zero-width
spaces in my Org files for this precise reason.  However, I agree that
extending syntax is dangerous.

How about a solution (or maybe it's only a "solution"...) where:

1. We take care to modify the "official" exporters to throw out the ZWSs.
Or even better, convert them to something reasonable, e.g. with LaTeX
they can be discarded or converted to some command – possibly even one
defined in the preamble – so that nothing is lost.  I'd even say that an
option deciding what to do with those could be nice.

2. We modify Emacs itself to somehow highlight the ZWS.  There is (kind
of) a precedent – a no-breaking space is already fontified with
=nobreak-space= face.  At the very least, make whitespace-mode somehow
show ZWSs (which it doesn't now, and I'd probably say it's a bug).

I know that my point 2. is a bit controversial, since it could lead to
alignment issues where a ZWS is displayed as something with a positive
width. OTOH, even now changing the face of a ZWS leads to a narrow
(1-pixel wide) line of a different color.  Is there a way to make it
a bit stronger?

Just some random ideas,

-- 
Marcin Borkowski
http://mbork.pl


^ permalink raw reply	[relevance 5%]

* Re: On zero width spaces and Org syntax
  @ 2021-12-04  5:29  5%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-04  5:29 UTC (permalink / raw)
  To: Tom Gillespie; +Cc: orgmode

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








^ permalink raw reply	[relevance 5%]

* Re: On zero width spaces and Org syntax
  2021-12-03 21:48  3% ` Tim Cross
@ 2021-12-04  1:26  6%   ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-04  1:26 UTC (permalink / raw)
  To: Tim Cross; +Cc: orgmode

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

Since I have been using Org I have been running into these little
inconsistencies. Any insurmountable, of course, nor I had to abandon the
use of Org for that minor issues. Fortunately, Org is more than just a
markup language, and it offers lots of alternative resources and
extensibility. Org is GNU Emacs. Org is not Markdown.

My proposal here also does not arise from an irrepressible desire to add
more complexity to the syntax. If it's recommended that the user, in
certain contexts, enter implicitly a zero-width space (which, I insist,
is a practice that should be avoided as much as possible in a plain text
document), why not at least offer a graphical alternative, a *real* mark
whose role is *exactly* the same as that of the zero-with space? Is that
adding more complexity??? Honestly I think that's exactly the opposite.

In any case, I have suggested that new mark as a possibility, in case it
is interesting to implement it, since a thread has emerged these days
about the topic of the intra-words syntax. Discussions and threads
arised about these questions and any other are perfectly legitimate and
natural and welcome. Please: there are no issues more 'important' than
others; no two users are the same in Org. What you do not find useful,
another user may perhaps finds it indispensable. And vice versa. And I
think no one is in willingness to state what the average Org user does
or does not want, given that we do not know even 1% of Org users.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 6%]

* Re: On zero width spaces and Org syntax
  2021-12-03 12:48  8% On zero width spaces and Org syntax Juan Manuel Macías
  @ 2021-12-03 21:48  3% ` Tim Cross
  2021-12-04  1:26  6%   ` Juan Manuel Macías
  2021-12-04  6:43  5% ` Marcin Borkowski
  2 siblings, 1 reply; 200+ results
From: Tim Cross @ 2021-12-03 21:48 UTC (permalink / raw)
  To: emacs-orgmode


Juan Manuel Macías <maciaschain@posteo.net> writes:

> 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'),
> '&#x200B;' 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 

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. 


^ permalink raw reply	[relevance 3%]

* Re: On zero width spaces and Org syntax
  @ 2021-12-03 20:30  9%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 20:30 UTC (permalink / raw)
  To: Greg Minshall; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-03 15:01  9%           ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 15:01 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

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 



^ permalink raw reply	[relevance 9%]

* On zero width spaces and Org syntax
@ 2021-12-03 12:48  8% Juan Manuel Macías
                     ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-03 12:48 UTC (permalink / raw)
  To: orgmode

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'),
'&#x200B;' 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 


^ permalink raw reply	[relevance 8%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 23:05  6%           ` Nicolas Goaziou
@ 2021-12-02 23:24  9%             ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 23:24 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: orgmode

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




^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 19:34  9%         ` Juan Manuel Macías
@ 2021-12-02 23:05  6%           ` Nicolas Goaziou
  2021-12-02 23:24  9%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-12-02 23:05 UTC (permalink / raw)
  To: Juan Manuel Macías
  Cc: Timothy, emacs-orgmode, Ihor Radchenko, Denis Maier

Hello,

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

We may be misunderstanding each other. 

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.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-02 19:34  9%         ` Juan Manuel Macías
  2021-12-02 23:05  6%           ` Nicolas Goaziou
    1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:34 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Denis Maier, emacs-orgmode, Ihor Radchenko, Timothy

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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-02 19:09  9%           ` Juan Manuel Macías
  2021-12-04 13:07  5%             ` Org-syntax: emphasis and not English punctuation Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 19:09 UTC (permalink / raw)
  To: Tom Gillespie; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 13:14  9%               ` Juan Manuel Macías
@ 2021-12-02 13:28  7%                 ` Denis Maier
  0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 13:28 UTC (permalink / raw)
  To: Juan Manuel Macías, Ihor Radchenko; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]

Am 02.12.2021 um 14:14 schrieb Juan Manuel Macías:
> Ihor Radchenko writes:
>
>> Denis Maier<denismaier@mailbox.org>  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

Thanks Juan Manuel. I should have tried that first. Hyphenation is the 
same for both /hyphen/​ation (with zero width sp) and 
\emph{hyphen}ation. (Maybe I can nudge Hans Hagen to add some low level 
trickery in context that removes the groups before doing the 
hyphenation... but that's a different story.) Anyway, as Juan Manuel 
shows there can be cases where zero width spaces cause problems.

Denis


[-- Attachment #2: Type: text/html, Size: 3801 bytes --]

^ permalink raw reply	[relevance 7%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-02 13:14  9%               ` Juan Manuel Macías
  2021-12-02 13:28  7%                 ` Denis Maier
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-02 13:14 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, denismaier

Ihor Radchenko writes:

> Denis Maier <denismaier@mailbox.org> 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 


^ permalink raw reply	[relevance 9%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 12:00  5%     ` Ihor Radchenko
@ 2021-12-02 12:28  0%       ` Denis Maier
  0 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 12:28 UTC (permalink / raw)
  To: Ihor Radchenko, Juan Manuel Macías; +Cc: orgmode



Am 02.12.2021 um 13:00 schrieb Ihor Radchenko:
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> intra-*word* works just fine for me.
>>>
>> 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.
> I see. We had a discussion about emphasis issues in
> https://orgmode.org/list/8735nnq73n.fsf@localhost
>
> The conclusion from there is that supporting such scenarios will
> introduce various edge cases. We would need to make the emaphsis parser
> more and more complex inevitably introducing errors.
Thanks, I'll try to read that thread in due time.
>
> An alternative may be some kind of "forced" emphasis syntax where Org
> does not have to guess about the emphasis using non-transparent rules.
> But it's what zero width space is for and it is what we recommend in the
> Org manual.
As for the forced syntax. What do you think about the asciidoc solution?

Denis



^ permalink raw reply	[relevance 0%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 11:30 10%   ` Juan Manuel Macías
  2021-12-02 11:36  7%     ` Denis Maier
  @ 2021-12-02 12:00  5%     ` Ihor Radchenko
  2021-12-02 12:28  0%       ` Denis Maier
  2 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2021-12-02 12:00 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Denis Maier

Juan Manuel Macías <maciaschain@posteo.net> writes:

>> intra-*word* works just fine for me.
>>
> 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.

I see. We had a discussion about emphasis issues in
https://orgmode.org/list/8735nnq73n.fsf@localhost

The conclusion from there is that supporting such scenarios will
introduce various edge cases. We would need to make the emaphsis parser
more and more complex inevitably introducing errors.

An alternative may be some kind of "forced" emphasis syntax where Org
does not have to guess about the emphasis using non-transparent rules.
But it's what zero width space is for and it is what we recommend in the
Org manual.

Best,
Ihor


^ permalink raw reply	[relevance 5%]

* Re: Org-syntax: Intra-word markup
  2021-12-02 11:30 10%   ` Juan Manuel Macías
@ 2021-12-02 11:36  7%     ` Denis Maier
    2021-12-02 12:00  5%     ` Ihor Radchenko
  2 siblings, 0 replies; 200+ results
From: Denis Maier @ 2021-12-02 11:36 UTC (permalink / raw)
  To: Juan Manuel Macías, Ihor Radchenko; +Cc: orgmode

Yes, Juan Manuel. That's it.

See for reference: 
https://stackoverflow.com/questions/1218238/how-to-make-part-of-a-word-bold-in-org-mode

Best,
Denis

Am 02.12.2021 um 12:30 schrieb Juan Manuel Macías:
> Hi Denis and Ihor,
>
> Ihor Radchenko writes:
>
>> Denis Maier <denismaier@mailbox.org> 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



^ permalink raw reply	[relevance 7%]

* Re: Org-syntax: Intra-word markup
  @ 2021-12-02 11:30 10%   ` Juan Manuel Macías
  2021-12-02 11:36  7%     ` Denis Maier
                       ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-02 11:30 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Denis Maier

Hi Denis and Ihor,

Ihor Radchenko writes:

> Denis Maier <denismaier@mailbox.org> 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 


^ permalink raw reply	[relevance 10%]

* Re: how to export red colored TeX to latex
  2021-12-01 15:00 10%     ` Juan Manuel Macías
@ 2021-12-01 15:02  6%       ` Eric S Fraga
  0 siblings, 0 replies; 200+ results
From: Eric S Fraga @ 2021-12-01 15:02 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Wednesday,  1 Dec 2021 at 15:00, Juan Manuel Macías wrote:
> Anyway, for format chunks of text in export I think
> org-link-set-parameters is a good alternative to macros.

I also have a few links defined (used to have one for citing but no
longer needed) but macros seem to be my first port-of-call and maybe
shouldn't be!

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096


^ permalink raw reply	[relevance 6%]

* Re: how to export red colored TeX to latex
  @ 2021-12-01 15:00 10%     ` Juan Manuel Macías
  2021-12-01 15:02  6%       ` Eric S Fraga
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-12-01 15:00 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: Orgdown: negative feedback & attempt of a root-cause analysis
  @ 2021-12-01  3:28  9%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-12-01  3:28 UTC (permalink / raw)
  To: Tom Gillespie; +Cc: orgmode

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, distill Org into a workable markup language outside Org
itself and GNU Emacs, is a task that seems impossible to me. Or at least
(for not being so radical), quite difficult. And, on the other hand,
what would be the point of doing that? I think Org and Markdown are the
antipodes, they are like water and oil, although they share certain
purposes. Just to make my current opinion clear.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: how to export red colored TeX to latex
  @ 2021-11-30 17:43 10%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-30 17:43 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: how to export red colored TeX to latex
  @ 2021-11-30 16:56  9% ` Juan Manuel Macías
      0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-30 16:56 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode, John Kitchin

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 "<span
                                       style=\"color:%s;\">%s</span>"
                                       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 


^ permalink raw reply	[relevance 9%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  2021-11-29 12:18  9%     ` Juan Manuel Macías
@ 2021-11-29 12:36  6%       ` Marcin Borkowski
  0 siblings, 0 replies; 200+ results
From: Marcin Borkowski @ 2021-11-29 12:36 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


On 2021-11-29, at 13:18, Juan Manuel Macías <maciaschain@posteo.net> wrote:

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

Agreed, I just wanted to say that the situation with TeX is more
complicated.  Especially that 92%* TeX users are novice/casual users.

* Number made up, but loosely based on anecdotal evidence;-).

-- 
Marcin Borkowski
http://mbork.pl


^ permalink raw reply	[relevance 6%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  2021-11-29  5:41  6%   ` Marcin Borkowski
@ 2021-11-29 12:18  9%     ` Juan Manuel Macías
  2021-11-29 12:36  6%       ` Marcin Borkowski
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-29 12:18 UTC (permalink / raw)
  To: Marcin Borkowski; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  2021-11-29  3:25 10%       ` Juan Manuel Macías
@ 2021-11-29  7:13  5%         ` Dr. Arne Babenhauserheide
  0 siblings, 0 replies; 200+ results
From: Dr. Arne Babenhauserheide @ 2021-11-29  7:13 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Joost Kremers, emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]


Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Org markup and Org syntax sound good, I think. I’m unsure which is
better to convey that this includes features — that org-mode is much
more than just a way to encode some information, but a way to interact
with documents and an implementation of the syntax should keep that in
mind.

One thing that is important to keep: Org Syntax or Org Markup is
implementation-defined. You cannot claim *full compatibility*, if you
are not fully compatible with org-mode. This includes a lot of Emacs
features, like linking to arbitrary files/buffers/things, extending
links, and so on.

The minimal syntax (missing a lot of features) would be outline markup
or outline syntax (from outline-mode, the ancestor of org-mode).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[relevance 5%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  2021-11-28 22:25  8% ` Juan Manuel Macías
  @ 2021-11-29  5:41  6%   ` Marcin Borkowski
  2021-11-29 12:18  9%     ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Marcin Borkowski @ 2021-11-29  5:41 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode


On 2021-11-28, at 23:25, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> Hi,
>
> [...] For example: there is TeX (the typographic engine) and TeX
> (the programming language for that engine). And there has never been any
> conflict.

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.

Just my 2 cents,

-- 
Marcin Borkowski
http://mbork.pl


^ permalink raw reply	[relevance 6%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  @ 2021-11-29  3:25 10%       ` Juan Manuel Macías
  2021-11-29  7:13  5%         ` Dr. Arne Babenhauserheide
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-29  3:25 UTC (permalink / raw)
  To: Joost Kremers; +Cc: orgmode

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


^ permalink raw reply	[relevance 10%]

* Re: "Orgdown", the new name for the syntax of Org-mode
  @ 2021-11-28 22:25  8% ` Juan Manuel Macías
    2021-11-29  5:41  6%   ` Marcin Borkowski
    1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-28 22:25 UTC (permalink / raw)
  To: orgmode

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 



^ permalink raw reply	[relevance 8%]

* Dired images in an Org buffer
@ 2021-11-23 16:52  9% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-23 16:52 UTC (permalink / raw)
  To: orgmode

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 


^ permalink raw reply	[relevance 9%]

* org-critical-edition (new version)
@ 2021-11-21 15:36 13% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-21 15:36 UTC (permalink / raw)
  To: orgmode

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/



^ permalink raw reply	[relevance 13%]

* Re: insert automatically a reference to a section header and a link
  2021-11-17 18:17 10%               ` Juan Manuel Macías
@ 2021-11-17 19:00  6%                 ` Stefan Nobis
  0 siblings, 0 replies; 200+ results
From: Stefan Nobis @ 2021-11-17 19:00 UTC (permalink / raw)
  To: emacs-orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> In Org 9.5 there is a new variable `org-latex-reference-command'.

Thanks for the reminder! I once read about it, but forgot to use it
after upgrading to 9.5. :)

-- 
Until the next mail...,
Stefan.


^ permalink raw reply	[relevance 6%]

* Re: insert automatically a reference to a section header and a link
  @ 2021-11-17 18:17 10%               ` Juan Manuel Macías
  2021-11-17 19:00  6%                 ` Stefan Nobis
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-17 18:17 UTC (permalink / raw)
  To: Stefan Nobis; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: insert automatically a reference to a section header and a link
  @ 2021-11-17 15:42 10%           ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-17 15:42 UTC (permalink / raw)
  To: Stefan Nobis; +Cc: Uwe Brauer, orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: Should be possible to export list items emphasized by default?
  @ 2021-11-17 13:33  9% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-17 13:33 UTC (permalink / raw)
  To: Ypo; +Cc: orgmode

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


^ permalink raw reply	[relevance 9%]

* Re: whitespace in org source files
  @ 2021-11-13 12:57 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-13 12:57 UTC (permalink / raw)
  To: excalamus; +Cc: Tim Cross, orgmode

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 


^ permalink raw reply	[relevance 10%]

* A function to include a PDF with LaTeX commands for specific pages
@ 2021-11-09 16:25  7% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-11-09 16:25 UTC (permalink / raw)
  To: orgmode

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 


^ permalink raw reply	[relevance 7%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-11-04 20:59  6%       ` Juan Manuel Macías
@ 2021-11-06 13:51  6%         ` Nicolas Goaziou
  0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-11-06 13:51 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Attached here the updated patch.

Applied. Thank you.

I added two spaces between sentences in org-manual.org.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-11-03 18:33  6%     ` Nicolas Goaziou
@ 2021-11-04 20:59  6%       ` Juan Manuel Macías
  2021-11-06 13:51  6%         ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-04 20:59 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

Hi Nicolas,

Nicolas Goaziou writes:

> Good idea. Thanks.

Attached here the updated patch.

Best regards,

Juan Manuel 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-options-latex-attribute-to-tables.patch --]
[-- Type: text/x-patch, Size: 5073 bytes --]

From fc9062caf43956ac68b72f16afbd5584ec84e687 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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 "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
 			    table-env
+                            (if opt (format "[%s]" opt) "")
 			    width
 			    alignment
 			    contents
-- 
2.33.1


^ permalink raw reply related	[relevance 6%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-11-03 17:38 10%   ` Juan Manuel Macías
@ 2021-11-03 18:33  6%     ` Nicolas Goaziou
  2021-11-04 20:59  6%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-11-03 18:33 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Good idea. Thanks.

Regards,


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-11-03 16:32  6% ` Nicolas Goaziou
@ 2021-11-03 17:38 10%   ` Juan Manuel Macías
  2021-11-03 18:33  6%     ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-11-03 17:38 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-10-26 16:05  9% [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
  @ 2021-11-03 16:32  6% ` Nicolas Goaziou
  2021-11-03 17:38 10%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Nicolas Goaziou @ 2021-11-03 16:32 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Vikas Rawal, orgmode

Hello,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> 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=DuaBB28nCsVqEA@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}

Thank you.

Could you also document it in the manual?

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Re: Introducing Org-transclusion
  2021-10-30 12:31 10% ` Juan Manuel Macías
@ 2021-11-01  9:17  6%   ` Noboru Ota
  0 siblings, 0 replies; 200+ results
From: Noboru Ota @ 2021-11-01  9:17 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: emacs-orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Thank you for your kind words. 


^ permalink raw reply	[relevance 6%]

* Re: Sub-figures in Org Mode
  2021-10-26 17:46  5%   ` Jason Ross
@ 2021-10-30 14:28 10%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-30 14:28 UTC (permalink / raw)
  To: Jason Ross; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: Introducing Org-transclusion
  @ 2021-10-30 12:31 10% ` Juan Manuel Macías
  2021-11-01  9:17  6%   ` Noboru Ota
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-30 12:31 UTC (permalink / raw)
  To: Noboru Ota; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  2021-10-28 18:02  6%       ` Juan Manuel Macías
@ 2021-10-28 19:39 13%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-28 19:39 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

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 


^ permalink raw reply	[relevance 13%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  @ 2021-10-28 18:02  6%       ` Juan Manuel Macías
  2021-10-28 19:39 13%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-28 18:02 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

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}


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox-latex.el: add `:options' LaTeX attribute to tables
  @ 2021-10-27 15:52  7%   ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-27 15:52 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

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 


^ permalink raw reply	[relevance 7%]

* Re: Sub-figures in Org Mode
  2021-10-23  0:00 10% ` Juan Manuel Macías
@ 2021-10-26 17:46  5%   ` Jason Ross
  2021-10-30 14:28 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Jason Ross @ 2021-10-26 17:46 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hi Juan,

On 10/22/21 5:00 PM, Juan Manuel Macías wrote:
> Hi Jason,
> 
> Jason Ross <jasonross1024@gmail.com> 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.fsf@posteo.net/
> 
> Best regards,
> 
> Juan Manuel
> 

Those are some really clever solutions. I hadn't considered using a
dsl for figure options.

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.

Here's what I'm messing with for the ConTeXt backend (this relies
on some changes to figure handling I haven't pushed yet):

#+begin_src elisp
(defun org-context--special-block-figure (orig-fun special-block 
contents info)
   (let ((type (org-element-property :type special-block)))
     (if (string= "figure" (downcase type))
         (let* ((attr (org-export-read-attribute :attr_context 
special-block))
                (links (org-element-map special-block 'link #'identity))
                (placefigure-options
                 (org-context--format-arguments
                  (org-context--get-placefigure-options special-block 
info)))
                (captionp
                 (mapcan
                  (lambda (link)
                    (let* ((parent (org-export-get-parent-element link))
                           (caption (org-string-nw-p 
(org-context--caption/label-string parent info))))
                      (and caption (list caption))))
                  links))
                (image-codes
                 (mapconcat
                  (lambda (link)
                    (let ((figure-string 
(org-context--get-link-figure-string link info)))
                      (if captionp
                        (let ((caption
                               (org-string-nw-p
                                (org-context--caption/label-string
                                 (org-export-get-parent-element link) 
info))))
                          (format "{%s}\n{%s}"
                                  figure-string (or caption "")))
                      (format "{%s}" figure-string)))

                    )
                  links
                  "\n"))
                (dimensions
                 (let* ((rows (plist-get attr :rows))
                        (cols (plist-get attr :cols))
                        (nlinks (length links)))
                   (if
                       (and rows cols)
                       (cons (string-to-number rows) (string-to-number 
cols))
                     (cons 1 nlinks))))
                combination-options)
           (if captionp
                (push (cons "alternative" "text") combination-options)
             (push (cons "alternative" "label") combination-options))
           (push (cons "nx" (format "%s" (cdr dimensions))) 
combination-options)
           (push (cons "ny" (format "%s" (car dimensions))) 
combination-options)
           (message (format "%S" combination-options))
           (format "\\startplacefigure[%s]
\\startcombination[%s]
%s
\\stopcombination
\\stopplacefigure"
                   placefigure-options
                   (org-context--format-arguments combination-options)
                   image-codes))
       (funcall orig-fun special-block contents info))))

(advice-add 'org-context-special-block :around 
#'org-context--special-block-figure)

#+end_src



^ permalink raw reply	[relevance 5%]

* [patch] ox-latex.el: add `:options' LaTeX attribute to tables
@ 2021-10-26 16:05  9% Juan Manuel Macías
    2021-11-03 16:32  6% ` Nicolas Goaziou
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-26 16:05 UTC (permalink / raw)
  To: orgmode; +Cc: Vikas Rawal

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

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=DuaBB28nCsVqEA@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-add-options-latex-attribute-to-tables.patch --]
[-- Type: text/x-patch, Size: 1495 bytes --]

From 9b51d999029f91adc93a6009bc3ddf56bba7ba4a Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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


^ permalink raw reply related	[relevance 9%]

* Re: Support for tabularray in LaTeX export
  2021-10-25 14:18 10%       ` Juan Manuel Macías
@ 2021-10-25 17:25  0%         ` Thomas Dye
  0 siblings, 0 replies; 200+ results
From: Thomas Dye @ 2021-10-25 17:25 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Vikas Rawal, orgmode


> On Oct 25, 2021, at 4:23 AM, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> 
> 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.fsf@posteo.net/)
> 
> Best regards,
> 
> Juan Manuel 
> 
+1

All the best,
Tom


^ permalink raw reply	[relevance 0%]

* Re: Support for tabularray in LaTeX export
  @ 2021-10-25 14:18 10%       ` Juan Manuel Macías
  2021-10-25 17:25  0%         ` Thomas Dye
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-25 14:18 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

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.fsf@posteo.net/)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: A quick LaTeX reference guide in Org
  2021-10-25 12:30  6%     ` Eric S Fraga
  2021-10-25 12:58  0%       ` John Hendy
@ 2021-10-25 14:10 10%       ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-25 14:10 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

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


^ permalink raw reply	[relevance 10%]

* Re: [PATCH] org-manual.org: List the languages supported by smart quotes feature
  2021-10-03 17:39  2% [PATCH] org-manual.org: List the languages supported by smart quotes feature Juan Manuel Macías
@ 2021-10-25 13:56  6% ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2021-10-25 13:56 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Looks useful. It is also a good idea to mention
org-export-smart-quotes-alist variable. Otherwise, we may forget to
update this footnote in future when new languages are supported.

Best,
Ihor


^ permalink raw reply	[relevance 6%]

* Re: A quick LaTeX reference guide in Org
  2021-10-25 12:30  6%     ` Eric S Fraga
@ 2021-10-25 12:58  0%       ` John Hendy
  2021-10-25 14:10 10%       ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: John Hendy @ 2021-10-25 12:58 UTC (permalink / raw)
  To: Juan Manuel Macías, Tim Cross, orgmode

On Mon, Oct 25, 2021 at 7:49 AM Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
>
> On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote:
> > 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.
>
> It's in CTAN, the official (?) LaTeX repository.

As an arch user, just confirming. For what it's worth, the way to find
the package's "home base" is in the  upstream url, which is as Eric
says.

https://aur.archlinux.org/packages/latex2e-help-texinfo/
"""
Upstream URL: https://ctan.org/pkg/latex2e-help-texinfo
"""
>
> --
> Professor Eric S Fraga
> Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812
> PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D
>
> Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432
>


^ permalink raw reply	[relevance 0%]

* Re: A quick LaTeX reference guide in Org
  2021-10-25 11:35 10%   ` Juan Manuel Macías
@ 2021-10-25 12:30  6%     ` Eric S Fraga
  2021-10-25 12:58  0%       ` John Hendy
  2021-10-25 14:10 10%       ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Eric S Fraga @ 2021-10-25 12:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Tim Cross, orgmode

On Monday, 25 Oct 2021 at 11:35, Juan Manuel Macías wrote:
> 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.

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

-- 
Professor Eric S Fraga 
Fresa: https://tinyurl.com/5t8t5auv & doi:10.5281/zenodo.5045812
PGP/GnuPG key: 8F5C 279D 3907 E14A 5C29  570D C891 93D8 FFFC F67D

Latest paper (10 Sep 2021): doi:10.1016/j.nucengdes.2021.111432


^ permalink raw reply	[relevance 6%]

* Re: A quick LaTeX reference guide in Org
  2021-10-24 20:18  6% ` Tim Cross
@ 2021-10-25 11:35 10%   ` Juan Manuel Macías
  2021-10-25 12:30  6%     ` Eric S Fraga
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-25 11:35 UTC (permalink / raw)
  To: Tim Cross; +Cc: orgmode

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 


^ permalink raw reply	[relevance 10%]

* Re: A quick LaTeX reference guide in Org
  2021-10-24 14:23  9% A quick LaTeX reference guide in Org Juan Manuel Macías
  2021-10-24 20:18  6% ` Tim Cross
@ 2021-10-25  0:42  7% ` Thomas S. Dye
  1 sibling, 0 replies; 200+ results
From: Thomas S. Dye @ 2021-10-25  0:42 UTC (permalink / raw)
  To: emacs-orgmode

Aloha Juan Manuel,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> 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 

Such a handy utility!  Thanks for sharing.

All the best,
Tom

-- 
Thomas S. Dye
https://tsdye.online/tsdye


^ permalink raw reply	[relevance 7%]

* Re: A quick LaTeX reference guide in Org
  2021-10-24 14:23  9% A quick LaTeX reference guide in Org Juan Manuel Macías
@ 2021-10-24 20:18  6% ` Tim Cross
  2021-10-25 11:35 10%   ` Juan Manuel Macías
  2021-10-25  0:42  7% ` Thomas S. Dye
  1 sibling, 1 reply; 200+ results
From: Tim Cross @ 2021-10-24 20:18 UTC (permalink / raw)
  To: emacs-orgmode


Juan Manuel Macías <maciaschain@posteo.net> writes:

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

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. 


^ permalink raw reply	[relevance 6%]

* A quick LaTeX reference guide in Org
@ 2021-10-24 14:23  9% Juan Manuel Macías
  2021-10-24 20:18  6% ` Tim Cross
  2021-10-25  0:42  7% ` Thomas S. Dye
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-24 14:23 UTC (permalink / raw)
  To: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: Sub-figures in Org Mode
  @ 2021-10-23  0:00 10% ` Juan Manuel Macías
  2021-10-26 17:46  5%   ` Jason Ross
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-23  0:00 UTC (permalink / raw)
  To: Jason Ross; +Cc: orgmode

Hi Jason,

Jason Ross <jasonross1024@gmail.com> 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.fsf@posteo.net/

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt)
@ 2021-10-22 15:01 10% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-22 15:01 UTC (permalink / raw)
  To: orgmode

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 "</text:p>" nil t)
                          (- (point) 9)))
                    (contents (buffer-substring-no-properties from to)))
               (delete-region (point-min) (point-max))
               (insert (concat
                        "<office:annotation loext:resolved=\"false\"><dc:creator>"
                        (car (plist-get info :author))
                        "</dc:creator><dc:date>"
                        ;; date in iso format
                        (org-odt--format-timestamp (plist-get info :date) nil t)
                        "</dc:date><text:p text:style-name=\"P5\"><text:span text:style-name=\"T1\">"
                        contents
                        "</text:span></text:p></office:annotation> "))
               (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/


^ permalink raw reply	[relevance 10%]

* Fancy underlines in Org to LaTeX
@ 2021-10-20 14:57 13% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-20 14:57 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

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/


[-- Attachment #2: soulpos-test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 4018 bytes --]

^ permalink raw reply	[relevance 13%]

* [mostly solved] Re: Unable to configure emacs 27.2 to use org 9.5
  2021-10-18 22:28 13% ` Juan Manuel Macías
@ 2021-10-19  8:32  5%   ` Detlef Steuer
  0 siblings, 0 replies; 200+ results
From: Detlef Steuer @ 2021-10-19  8:32 UTC (permalink / raw)
  To: emacs-orgmode

Am Mon, 18 Oct 2021 22:28:42 +0000
schrieb Juan Manuel Macías <maciaschain@posteo.net>:

> 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/?

Yes, it is there.

I now tried on a second machine and everything worked as expected,
after I removed org-plus-contrib from my elpa directory there.
On machine number one there is no such directory. I will try to
re-initialize everything elpa there and see what will happen.

So there is hope and nano may remain a desperate threat :-)

Thank you!

Detlef

> 
> Have you tried uninstalling Org and reinstalling it?
> 
> Best regards,
> 
> Juan Manuel 
> 



-- 
"Wozu leben wir, wenn nicht dazu, uns gegenseitig das Leben 
 einfacher zu machen. (George Eliot)" 

Dr. Detlef Steuer
Helmut-Schmidt-Universität
Fakultät WiSo
Holstenhofweg 85
22043 Hamburg

Tel:  040/6541-2819
mail: steuer@hsu-hh.de


^ permalink raw reply	[relevance 5%]

* Re: Unable to configure emacs 27.2 to use org 9.5
  @ 2021-10-18 22:28 13% ` Juan Manuel Macías
  2021-10-19  8:32  5%   ` [mostly solved] " Detlef Steuer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-18 22:28 UTC (permalink / raw)
  To: Detlef Steuer; +Cc: orgmode

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/



^ permalink raw reply	[relevance 13%]

* [minor tip] "TeXify" strings "TeX" and "LaTeX" when exporting to HTML
@ 2021-10-15 16:56  7% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-15 16:56 UTC (permalink / raw)
  To: orgmode

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 "<span style=\"font-family:serif;\">T<span
  style=\"vertical-align:-0.4ex;font-size:smaller;\">E</span>X</span>")
  
  (setq my/latex-html-string "<span style=\"font-family:serif;\">L<span
  style=\"vertical-align:0.5ex;font-size:smaller;margin-left:-0.3em;\">A</span>T<span
  style=\"vertical-align:-0.4ex;font-size:smaller;\">E</span>X</span>")
#+end_src

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

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

<img
src=\"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 


^ permalink raw reply	[relevance 7%]

* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
  @ 2021-10-10  2:52  7% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-10  2:52 UTC (permalink / raw)
  To: copropriete27ruemoret; +Cc: orgmode

copropriete27ruemoret@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 



^ permalink raw reply	[relevance 7%]

* [tip] Go to the org node from the attached directory
@ 2021-10-07 14:57  8% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 14:57 UTC (permalink / raw)
  To: orgmode

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 


^ permalink raw reply	[relevance 8%]

* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
  2021-10-07 12:28  0%   ` Uwe Brauer
  2021-10-07 12:58  9%     ` Juan Manuel Macías
@ 2021-10-07 12:59  0%     ` Peter Neilson
  1 sibling, 0 replies; 200+ results
From: Peter Neilson @ 2021-10-07 12:59 UTC (permalink / raw)
  To: emacs-orgmode

On Thu, 07 Oct 2021 08:28:03 -0400, Uwe Brauer <oub@mat.ucm.es> wrote:

>>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> 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)))
>
> Thanks, but it seems 11TeXpt-->10.95
>
> So it is not that different.

Sometimes that kind of difference can cause minor sessions of  
tearing-out-the-hair, like when the expected pagination is off, with just  
one word hanging off into the wilderness of another separate page. Manual  
typesetting, back in the dark ages of hand-set lead type, or even  
Linotype, encountered those problems, too. What did the stymied typesetter  
do? He'd leave out words! Yes, really!! "This sentence no verb."


^ permalink raw reply	[relevance 0%]

* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
  2021-10-07 12:28  0%   ` Uwe Brauer
@ 2021-10-07 12:58  9%     ` Juan Manuel Macías
  2021-10-07 12:59  0%     ` Peter Neilson
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-07 12:58 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

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 


^ permalink raw reply	[relevance 9%]

* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
  2021-10-07 11:24  9% ` Juan Manuel Macías
@ 2021-10-07 12:28  0%   ` Uwe Brauer
  2021-10-07 12:58  9%     ` Juan Manuel Macías
  2021-10-07 12:59  0%     ` Peter Neilson
  0 siblings, 2 replies; 200+ results
From: Uwe Brauer @ 2021-10-07 12:28 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:

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

Thanks, but it seems 11TeXpt-->10.95

So it is not that different.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

^ permalink raw reply	[relevance 0%]

* Re: how to export to odt with 11 or 10 pt fonts? Default font setting
  @ 2021-10-07 11:24  9% ` Juan Manuel Macías
  2021-10-07 12:28  0%   ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-07 11:24 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode, Eric S Fraga

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 


^ permalink raw reply	[relevance 9%]

* [patch] ox-html.el: add html attribute (verse numbers) to verse blocks
@ 2021-10-04 14:27  8% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-04 14:27 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

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 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-html.el-add-verse-numbers-html-attribute-to-verse.patch --]
[-- Type: text/x-patch, Size: 3032 bytes --]

From 9f1bbef52989532e16873a1f75331af0c7b0401f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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 "<p class=\"verse\">\n%s</p>"
-	  ;; Replace leading white spaces with non-breaking spaces.
-	  (replace-regexp-in-string
-	   "^[ \t]+" (lambda (m) (org-html--make-string (length m) "&#xa0;"))
-	   ;; 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 "<span class=\"versenum\">"
+						      (number-to-string
+						       (setf versenum (+ versenum seqverse)))
+						      "</span>"))))
+			   (buffer-string))
+		       contents)))
+      (format "<p class=\"verse\">\n%s</p>"
+	      ;; Replace leading white spaces with non-breaking spaces.
+	      (replace-regexp-in-string
+	       "^[ \t]+" (lambda (m) (org-html--make-string (length m) "&#xa0;"))
+	       ;; 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))))))
 
 \f
 ;;; Filter Functions
-- 
2.32.0


^ permalink raw reply related	[relevance 8%]

* [PATCH] org-manual.org: List the languages supported by smart quotes feature
@ 2021-10-03 17:39  2% Juan Manuel Macías
  2021-10-25 13:56  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-03 17:39 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 159 bytes --]

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


[-- Attachment #2: 0001-org-manual.org-List-the-languages-supported-by-smart.patch --]
[-- Type: text/x-patch, Size: 25508 bytes --]

From 26f799a5a53b35f7f3e6e3df10689855832dbebd Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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-bibtex-compiler~ to set the
-bibliography compiler[fn:133].
+bibliography compiler[fn:134].
 
 *** LaTeX specific export settings
 :PROPERTIES:
@@ -13779,7 +13779,7 @@ objects through the attributes =:float= and =:options=.  For =:float=:
 The LaTeX export back-end passes string values in =:options= to LaTeX
 packages for customization of that specific source block.  In the
 example below, the =:options= are set for Minted.  Minted is a source
-code highlighting LaTeX package with many configurable options[fn:134].
+code highlighting LaTeX package with many configurable options[fn:135].
 
 #+begin_example
 ,#+ATTR_LATEX: :options commentstyle=\bfseries
@@ -14030,7 +14030,7 @@ a limit to a level before the absolute limit (see [[*Export Settings]]).
 
 The ODT export back-end handles creating of OpenDocument Text (ODT)
 format.  Documents created by this exporter use the
-{{{cite(OpenDocument-v1.2 specification)}}}[fn:135] and are compatible
+{{{cite(OpenDocument-v1.2 specification)}}}[fn:136] and are compatible
 with LibreOffice 3.4.
 
 *** Pre-requisites for ODT export
@@ -14431,7 +14431,7 @@ document in one of the following ways:
   variables ~org-latex-to-mathml-convert-command~ and
   ~org-latex-to-mathml-jar-file~.
 
-  If you prefer to use MathToWeb[fn:136] as your converter, you can
+  If you prefer to use MathToWeb[fn:137] as your converter, you can
   configure the above variables as shown below.
 
   #+begin_src emacs-lisp
@@ -14442,7 +14442,7 @@ document in one of the following ways:
   #+end_src
 
   #+texinfo: @noindent
-  or, to use LaTeX​ML[fn:137] instead,
+  or, to use LaTeX​ML[fn:138] instead,
 
   #+begin_src emacs-lisp
   (setq org-latex-to-mathml-convert-command
@@ -14761,7 +14761,7 @@ with the =#+ATTR_ODT= line.  For a discussion on default formatting of
 tables, see [[*Tables in ODT export]].
 
 This feature closely mimics the way table templates are defined in the
-OpenDocument-v1.2 specification[fn:138].
+OpenDocument-v1.2 specification[fn:139].
 
 #+vindex: org-odt-table-styles
 For quick preview of this feature, install the settings below and export the
@@ -14795,7 +14795,7 @@ templates, define new styles there.
 
 To use this feature proceed as follows:
 
-1. Create a table template[fn:139].
+1. Create a table template[fn:140].
 
    A table template is set of =table-cell= and =paragraph= styles for
    each of the following table cell categories:
@@ -14834,7 +14834,7 @@ To use this feature proceed as follows:
    =</office:automatic-styles>= element of the content template file
    (see [[x-orgodtcontenttemplate-xml][Factory styles]]).
 
-2. Define a table style[fn:140].
+2. Define a table style[fn:141].
 
    #+vindex: org-odt-table-styles
    To define a table style, create an entry for the style in the
@@ -15948,7 +15948,7 @@ If you want to publish the Org file as an =.org= file but with
 ~org-org-publish-to-org~.  This produces =file.org= and puts it in the
 publishing directory.  If you want a htmlized version of this file,
 set the parameter ~:htmlized-source~ to ~t~.  It produces
-=file.org.html= in the publishing directory[fn:141].
+=file.org.html= in the publishing directory[fn:142].
 
 Other files like images only need to be copied to the publishing
 destination; for this you can use ~org-publish-attachment~.  For
@@ -17457,13 +17457,13 @@ See [[*Languages]] to enable other languages.
 #+kindex: C-c C-v e
 #+findex: org-babel-execute-src-block
 Org provides many ways to execute code blocks.  {{{kbd(C-c C-c)}}} or
-{{{kbd(C-c C-v e)}}} with the point on a code block[fn:142] calls the
+{{{kbd(C-c C-v e)}}} with the point on a code block[fn:143] calls the
 ~org-babel-execute-src-block~ function, which executes the code in the
 block, collects the results, and inserts them in the buffer.
 
 #+cindex: @samp{CALL}, keyword
 #+vindex: org-babel-inline-result-wrap
-By calling a named code block[fn:143] from an Org mode buffer or
+By calling a named code block[fn:144] from an Org mode buffer or
 a table.  Org can call the named code blocks from the current Org mode
 buffer or from the "Library of Babel" (see [[*Library of Babel]]).
 
@@ -17664,7 +17664,7 @@ they are mutually exclusive.
 
 - =value= ::
 
-  Default for most Babel libraries[fn:143].  Functional mode.  Org
+  Default for most Babel libraries[fn:144].  Functional mode.  Org
   gets the value by wrapping the code in a function definition in the
   language of the source block.  That is why when using =:results
   value=, code should execute like a function and return a value.  For
@@ -18352,7 +18352,7 @@ for Python and Emacs Lisp languages.
 
 #+cindex: @samp{noweb-ref}, header argument
 Source code blocks can include references to other source code blocks,
-using a noweb[fn:144] style syntax:
+using a noweb[fn:145] style syntax:
 
 : <<CODE-BLOCK-ID>>
 
@@ -18863,7 +18863,7 @@ Org Tempo expands snippets to structures defined in
 ~org-structure-template-alist~ and ~org-tempo-keywords-alist~.  For
 example, {{{kbd(< s TAB)}}} creates a code block.  Enable it by
 customizing ~org-modules~ or add =(require 'org-tempo)= to your Emacs
-init file[fn:145].
+init file[fn:146].
 
 #+attr_texinfo: :columns 0.1 0.9
 | {{{kbd(a)}}} | =#+BEGIN_EXPORT ascii= ... =#+END_EXPORT= |
@@ -18943,7 +18943,7 @@ in the desired amount with hard spaces and hiding leading stars.
 To display the buffer in the indented view, activate Org Indent minor
 mode, using {{{kbd(M-x org-indent-mode)}}}.  Text lines that are not
 headlines are prefixed with virtual spaces to vertically align with
-the headline text[fn:146].
+the headline text[fn:147].
 
 #+vindex: org-indent-indentation-per-level
 To make more horizontal space, the headlines are shifted by two
@@ -18971,9 +18971,9 @@ use =STARTUP= keyword as follows:
 
 It is possible to use hard spaces to achieve the indentation instead,
 if the bare ASCII file should have the indented look also outside
-Emacs[fn:147].  With Org's support, you have to indent all lines to
+Emacs[fn:148].  With Org's support, you have to indent all lines to
 line up with the outline headers.  You would use these
-settings[fn:148]:
+settings[fn:149]:
 
 #+begin_src emacs-lisp
 (setq org-adapt-indentation t
@@ -19244,7 +19244,7 @@ changes.
 
   #+vindex: org-startup-indented
   Dynamic virtual indentation is controlled by the variable
-  ~org-startup-indented~[fn:149].
+  ~org-startup-indented~[fn:150].
 
   | =indent=   | Start with Org Indent mode turned on.  |
   | =noindent= | Start with Org Indent mode turned off. |
@@ -20101,7 +20101,7 @@ Tags]]) only for those set in these variables.
 
 #+vindex: org-mobile-directory
 The mobile application needs access to a file directory on
-a server[fn:150] to interact with Emacs.  Pass its location through
+a server[fn:151] to interact with Emacs.  Pass its location through
 the ~org-mobile-directory~ variable.  If you can mount that directory
 locally just set the variable to point to that directory:
 
@@ -20122,7 +20122,7 @@ With a public server, consider encrypting the files.  Org also
 requires OpenSSL installed on the local computer.  To turn on
 encryption, set the same password in the mobile application and in
 Emacs.  Set the password in the variable
-~org-mobile-use-encryption~[fn:151].  Note that even after the mobile
+~org-mobile-use-encryption~[fn:152].  Note that even after the mobile
 application encrypts the file contents, the file name remains visible
 on the file systems of the local computer, the server, and the mobile
 device.
@@ -20138,15 +20138,15 @@ The command ~org-mobile-push~ copies files listed in
 ~org-mobile-files~ into the staging area.  Files include agenda files
 (as listed in ~org-agenda-files~).  Customize ~org-mobile-files~ to
 add other files.  File names are staged with paths relative to
-~org-directory~, so all files should be inside this directory[fn:152].
+~org-directory~, so all files should be inside this directory[fn:153].
 
 Push creates a special Org file =agendas.org= with custom agenda views
-defined by the user[fn:153].
+defined by the user[fn:154].
 
 Finally, Org writes the file =index.org=, containing links to other
 files.  The mobile application reads this file first from the server
 to determine what other files to download for agendas.  For faster
-downloads, it is expected to only read files whose checksums[fn:154]
+downloads, it is expected to only read files whose checksums[fn:155]
 have changed.
 
 *** Pulling from the mobile application
@@ -20163,7 +20163,7 @@ data in an inbox file format, through the following steps:
 
 1.
    #+vindex: org-mobile-inbox-for-pull
-   Org moves all entries found in =mobileorg.org=[fn:155] and appends
+   Org moves all entries found in =mobileorg.org=[fn:156] and appends
    them to the file pointed to by the variable
    ~org-mobile-inbox-for-pull~.  It should reside neither in the
    staging area nor on the server.  Each captured entry and each
@@ -20457,9 +20457,9 @@ of these strategies:
 #+cindex: @LaTeX{}, and Orgtbl mode
 
 To wrap a source table in LaTeX, use the =comment= environment
-provided by =comment.sty=[fn:156].  To activate it, put
+provided by =comment.sty=[fn:157].  To activate it, put
 ~\usepackage{comment}~ in the document header.  Orgtbl mode inserts
-a radio table skeleton[fn:157] with the command {{{kbd(M-x
+a radio table skeleton[fn:158] with the command {{{kbd(M-x
 orgtbl-insert-radio-table)}}}, which prompts for a table name.  For
 example, if =salesfigures= is the name, the template inserts:
 
@@ -20478,7 +20478,7 @@ The line =#+ORGTBL: SEND= tells Orgtbl mode to use the function
 ~orgtbl-to-latex~ to convert the table to LaTeX format, then insert
 the table at the target (receive) location named =salesfigures=.  Now
 the table is ready for data entry.  It can even use spreadsheet
-features[fn:158]:
+features[fn:159]:
 
 #+begin_example
 % BEGIN RECEIVE ORGTBL salesfigures
@@ -20694,7 +20694,7 @@ Dynamic blocks, like any other block, can be narrowed with
 #+vindex: org-agenda-skip-function
 #+vindex: org-agenda-skip-function-global
 Org provides a special hook to further limit items in agenda views:
-~agenda~, ~agenda*~[fn:159], ~todo~, ~alltodo~, ~tags~, ~tags-todo~,
+~agenda~, ~agenda*~[fn:160], ~todo~, ~alltodo~, ~tags~, ~tags-todo~,
 ~tags-tree~.  Specify a custom function that tests inclusion of every
 matched item in the view.  This function can also skip as much as is
 needed.
@@ -20737,7 +20737,7 @@ meaningful string suitable for the agenda view.
 #+vindex: org-agenda-skip-function
 Search for entries with a limit set on levels for the custom search.
 This is a general approach to creating custom searches in Org.  To
-include all levels, use =LEVEL>0=[fn:160].  Then to selectively pick
+include all levels, use =LEVEL>0=[fn:161].  Then to selectively pick
 the matched entries, use ~org-agenda-skip-function~, which also
 accepts Lisp forms, such as ~org-agenda-skip-entry-if~ and
 ~org-agenda-skip-subtree-if~.  For example:
@@ -22096,127 +22096,132 @@ this timestamp are exported.
 Beamer---, the =org-latex-package-alist= variable needs further
 configuration.  See [[LaTeX specific export settings]].
 
-[fn:124] At the moment, some export back-ends do not obey this
+[fn:124] Currently the following languages are supported for this
+feature: Arabic, Danish, English, French, German, Greek, Icelandic,
+Italian, Norsk, Nynorsk, Romanian, Russian, Slovenian, Spanish,
+Swedish.
+
+[fn:125] At the moment, some export back-ends do not obey this
 specification.  For example, LaTeX export excludes every unnumbered
 headline from the table of contents.
 
-[fn:125] Note that ~org-link-search-must-match-exact-headline~ is
+[fn:126] Note that ~org-link-search-must-match-exact-headline~ is
 locally bound to non-~nil~.  Therefore, ~org-link-search~ only matches
 headlines and named elements.
 
-[fn:126] Since commas separate the arguments, commas within arguments
+[fn:127] Since commas separate the arguments, commas within arguments
 have to be escaped with the backslash character.  So only those
 backslash characters before a comma need escaping with another
 backslash character.
 
-[fn:127] For a less drastic behavior, consider using a select tag (see
+[fn:128] For a less drastic behavior, consider using a select tag (see
 [[*Export Settings]]) instead.
 
-[fn:128] If =BEAMER_ENV= is set, Org export adds =B_environment= tag
+[fn:129] If =BEAMER_ENV= is set, Org export adds =B_environment= tag
 to make it visible.  The tag serves as a visual aid and has no
 semantic relevance.
 
-[fn:129] By default Org loads MathJax from [[https://cdnjs.com][cdnjs.com]] as recommended by
+[fn:130] By default Org loads MathJax from [[https://cdnjs.com][cdnjs.com]] as recommended by
 [[https://www.mathjax.org][MathJax]].
 
-[fn:130] Please note that exported formulas are part of an HTML
+[fn:131] Please note that exported formulas are part of an HTML
 document, and that signs such as =<=, =>=, or =&= have special
 meanings.  See [[http://docs.mathjax.org/en/latest/tex.html#tex-and-latex-in-html-documents][MathJax TeX and LaTeX support]].
 
-[fn:131] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
+[fn:132] See [[http://docs.mathjax.org/en/latest/tex.html#tex-extensions][TeX and LaTeX extensions]] in the [[http://docs.mathjax.org][MathJax manual]] to learn
 about extensions.
 
-[fn:132] If the classes on TODO keywords and tags lead to conflicts,
+[fn:133] If the classes on TODO keywords and tags lead to conflicts,
 use the variables ~org-html-todo-kwd-class-prefix~ and
 ~org-html-tag-class-prefix~ to make them unique.
 
-[fn:133] This does not allow setting different bibliography compilers
+[fn:134] This does not allow setting different bibliography compilers
 for different files.  However, "smart" LaTeX compilation systems, such
 as latexmk, can select the correct bibliography compiler.
 
-[fn:134] Minted uses an external Python package for code highlighting,
+[fn:135] Minted uses an external Python package for code highlighting,
 which requires the flag =-shell-escape= to be added to
 ~org-latex-pdf-process~.
 
-[fn:135] See [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][Open Document Format for Office Applications
+[fn:136] See [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][Open Document Format for Office Applications
 (OpenDocument) Version 1.2]].
 
-[fn:136] See [[http://www.mathtoweb.com/cgi-bin/mathtoweb_home.pl][MathToWeb]].
+[fn:137] See [[http://www.mathtoweb.com/cgi-bin/mathtoweb_home.pl][MathToWeb]].
 
-[fn:137] See [[http://dlmf.nist.gov/LaTeXML/]].
+[fn:138] See [[http://dlmf.nist.gov/LaTeXML/]].
 
-[fn:138] [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][OpenDocument-v1.2 Specification]]
+[fn:139] [[http://docs.oasis-open.org/office/v1.2/OpenDocument-v1.2.html][OpenDocument-v1.2 Specification]]
 
-[fn:139] See the =<table:table-template>= element of the
+[fn:140] See the =<table:table-template>= element of the
 OpenDocument-v1.2 specification.
 
-[fn:140] See the attributes =table:template-name=,
+[fn:141] See the attributes =table:template-name=,
 =table:use-first-row-styles=, =table:use-last-row-styles=,
 =table:use-first-column-styles=, =table:use-last-column-styles=,
 =table:use-banding-rows-styles=, and =table:use-banding-column-styles=
 of the =<table:table>= element in the OpenDocument-v1.2 specification.
 
-[fn:141] If the publishing directory is the same as the source
+[fn:142] If the publishing directory is the same as the source
 directory, =file.org= is exported as =file.org.org=, so you probably
 do not want to do this.
 
-[fn:142] The option ~org-babel-no-eval-on-ctrl-c-ctrl-c~ can be used
+[fn:143] The option ~org-babel-no-eval-on-ctrl-c-ctrl-c~ can be used
 to remove code evaluation from the {{{kbd(C-c C-c)}}} key binding.
 
-[fn:143] Actually, the constructs =call_<name>()= and =src_<lang>{}=
+[fn:144] Actually, the constructs =call_<name>()= and =src_<lang>{}=
 are not evaluated when they appear in a keyword (see [[*Summary of
 In-Buffer Settings]]).
 
-[fn:144] For noweb literate programming details, see
+[fn:145] For noweb literate programming details, see
 http://www.cs.tufts.edu/~nr/noweb/.
 
-[fn:145] For more information, please refer to the commentary section
+[fn:146] For more information, please refer to the commentary section
 in =org-tempo.el=.
 
-[fn:146] Org Indent mode also sets ~wrap-prefix~ correctly for
+[fn:147] Org Indent mode also sets ~wrap-prefix~ correctly for
 indenting and wrapping long lines of headlines or text.  This minor
 mode also handles Visual Line mode and directly applied settings
 through ~word-wrap~.
 
-[fn:147] This works, but requires extra effort.  Org Indent mode is
+[fn:148] This works, but requires extra effort.  Org Indent mode is
 more convenient for most applications.
 
-[fn:148] ~org-adapt-indentation~ can also be set to ='headline-data=,
+[fn:149] ~org-adapt-indentation~ can also be set to ='headline-data=,
 in which case only data lines below the headline will be indented.
 
-[fn:149] Note that Org Indent mode also sets the ~wrap-prefix~
+[fn:150] Note that Org Indent mode also sets the ~wrap-prefix~
 property, such that Visual Line mode (or purely setting ~word-wrap~)
 wraps long lines, including headlines, correctly indented.
 
-[fn:150] For a server to host files, consider using a WebDAV server,
+[fn:151] For a server to host files, consider using a WebDAV server,
 such as [[https://nextcloud.com][Nextcloud]].  Additional help is at this [[https://orgmode.org/worg/org-faq.html#mobileorg_webdav][FAQ entry]].
 
-[fn:151] If Emacs is configured for safe storing of passwords, then
+[fn:152] If Emacs is configured for safe storing of passwords, then
 configure the variable ~org-mobile-encryption-password~; please read
 the docstring of that variable.
 
-[fn:152] Symbolic links in ~org-directory~ need to have the same name
+[fn:153] Symbolic links in ~org-directory~ need to have the same name
 as their targets.
 
-[fn:153] While creating the agendas, Org mode forces =ID= properties
+[fn:154] While creating the agendas, Org mode forces =ID= properties
 on all referenced entries, so that these entries can be uniquely
 identified if Org Mobile flags them for further action.  To avoid
 setting properties configure the variable
 ~org-mobile-force-id-on-agenda-items~ to ~nil~.  Org mode then relies
 on outline paths, assuming they are unique.
 
-[fn:154] Checksums are stored automatically in the file
+[fn:155] Checksums are stored automatically in the file
 =checksums.dat=.
 
-[fn:155] The file will be empty after this operation.
+[fn:156] The file will be empty after this operation.
 
-[fn:156] https://www.ctan.org/pkg/comment
+[fn:157] https://www.ctan.org/pkg/comment
 
-[fn:157] By default this works only for LaTeX, HTML, and Texinfo.
+[fn:158] By default this works only for LaTeX, HTML, and Texinfo.
 Configure the variable ~orgtbl-radio-table-templates~ to install
 templates for other modes.
 
-[fn:158] If the =TBLFM= keyword contains an odd number of dollar
+[fn:159] If the =TBLFM= keyword contains an odd number of dollar
 characters, this may cause problems with Font Lock in LaTeX mode.  As
 shown in the example you can fix this by adding an extra line inside
 the =comment= environment that is used to balance the dollar
@@ -22224,9 +22229,9 @@ expressions.  If you are using AUCTeX with the font-latex library,
 a much better solution is to add the =comment= environment to the
 variable ~LaTeX-verbatim-environments~.
 
-[fn:159] The ~agenda*~ view is the same as ~agenda~ except that it
+[fn:160] The ~agenda*~ view is the same as ~agenda~ except that it
 only considers /appointments/, i.e., scheduled and deadline items that
 have a time specification =[h]h:mm= in their time-stamps.
 
-[fn:160] Note that, for ~org-odd-levels-only~, a level number
+[fn:161] Note that, for ~org-odd-levels-only~, a level number
 corresponds to order in the hierarchy, not to the number of stars.
-- 
2.32.0


^ permalink raw reply related	[relevance 2%]

* [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
@ 2021-10-03 15:28  5% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-03 15:28 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex.el-Unify-in-one-list-babel-and-polyglossia-.patch --]
[-- Type: text/x-patch, Size: 8021 bytes --]

From 389a4e43756a7c195c2c1f751b7dc9c03447526d Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
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 @@
 \f
 ;;; 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" "usmax")
     ("eo" "esperanto")
     ("es" "spanish")
+    ("es" "spanishmx" "spanish" "mexican")
     ("et" "estonian")
     ("eu" "basque")
     ("fa" "farsi")
     ("fi" "finnish")
     ("fr" "french")
-    ("fu" "friulan")
+    ("fr-ca" "canadien" "french" "canadian")
+    ("fur" "friulan")
     ("ga" "irish")
     ("gd" "scottish")
     ("gl" "galician")
     ("he" "hebrew")
     ("hi" "hindi")
     ("hr" "croatian")
-    ("hsb" "usorbian")
+    ("hsb" "uppersorbian" "sorbian" "upper")
     ("hu" "magyar")
-    ("hy" "armenian")
+    ("hy" "armenian" "*")
     ("ia" "interlingua")
-    ("id" "bahasai")
+    ("id" "bahasai" "*")
     ("is" "icelandic")
     ("it" "italian")
-    ("kn" "kannada")
-    ("la" "latin" "modern")
-    ("la-classic" "latin" "classic")
-    ("la-medieval" "latin" "medieval")
-    ("la-modern" "latin" "modern")
-    ("lo" "lao")
+    ("kn" "kannada" "*")
+    ("la" "latin")
+    ("la-classic" "classiclatin" "latin" "classic")
+    ("la-medieval" "medievallatin" "latin" "medieval")
+    ("la-ecclesiastic" "ecclesiasticlatin" "latin" "ecclesiastic")
+    ("lo" "lao" "*")
     ("lt" "lithuanian")
     ("lv" "latvian")
-    ("ml" "malayalam")
-    ("mr" "maranthi")
-    ("nb" "norsk")
-    ("nko" "nko")
+    ("ml" "malayalam" "*")
+    ("mr" "maranthi" "*")
+    ("nb" "norsk" "norwegian" "bokmal")
     ("nl" "dutch")
-    ("nn" "nynorsk")
+    ("nn" "nynorsk" "norwegian" "nynorsk")
     ("no" "norsk")
     ("oc" "occitan")
     ("pl" "polish")
     ("pms" "piedmontese")
     ("pt" "portuges")
     ("pt-br" "brazilian")
-    ("rm" "romansh")
+    ("rm" "romansh" "*")
     ("ro" "romanian")
     ("ru" "russian")
-    ("sa" "sanskrit")
-    ("se" "samin")
+    ("sa" "sanskrit" "*")
     ("sk" "slovak")
-    ("sl" "slovenian")
+    ("sl" "slovene")
     ("sq" "albanian")
     ("sr" "serbian")
     ("sv" "swedish")
-    ("syr" "syriac")
-    ("ta" "tamil")
-    ("te" "telugu")
+    ("syr" "syriac" "*")
+    ("ta" "tamil" "*")
+    ("te" "telugu" "*")
     ("th" "thai")
     ("tk" "turkmen")
     ("tr" "turkish")
     ("uk" "ukrainian")
-    ("ur" "urdu")
+    ("ur" "urdu" "*")
     ("vi" "vietnamese"))
-  "Alist between language code and corresponding Polyglossia option.")
+  "Alist between language code and corresponding Babel/Polyglossia option.
+
+For the names of the languages, the Babel nomenclature is
+preferred to that of Polyglossia, in those cases where both
+coincide.
+
+The alist supports three types of members:
+
+- Members with two elements: CODE BABEL/POLYGLOSSIA OPTION.
+
+- 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).
+
+- Members with four elements (for variants of languages): CODE
+BABEL-OPTION POLYGLOSSIA-OPTION POLYGLOSSIA-VARIANT")
 
 (defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
 					  ("qbordermatrix" . "\\cr")
@@ -1409,14 +1374,16 @@ Return the new header."
 	header
       (let ((options (save-match-data
 		       (org-split-string (match-string 1 header) ",[ \t]*")))
-	    (language (cdr (assoc-string language-code
-					 org-latex-babel-language-alist t))))
+	    (language (nth 1 (assoc language-code
+				    org-latex-language-alist))))
 	;; If LANGUAGE is already loaded, return header without AUTO.
 	;; Otherwise, replace AUTO with language or append language if
 	;; AUTO is not present.
 	(replace-match
 	 (mapconcat (lambda (option) (if (equal "AUTO" option) language option))
 		    (cond ((member language options) (delete "AUTO" options))
+			  ((let ((l (assoc language-code org-latex-language-alist)))
+			     (and (consp l) (= (length l) 3))) (delete "AUTO" options))
 			  ((member "AUTO" options) options)
 			  (t (append options (list language))))
 		    ", ")
@@ -1462,15 +1429,17 @@ Return the new header."
 	 (concat "\\usepackage{polyglossia}\n"
 		 (mapconcat
 		  (lambda (l)
-		    (let ((l (or (assoc l org-latex-polyglossia-language-alist)
+		    (let ((l (or (assoc l org-latex-language-alist)
 				 l)))
 		      (format (if main-language-set "\\setotherlanguage%s{%s}\n"
 				(setq main-language-set t)
 				"\\setmainlanguage%s{%s}\n")
-			      (if (and (consp l) (= (length l) 3))
-				  (format "[variant=%s]" (nth 2 l))
+			      (if (and (consp l) (= (length l) 4))
+				  (format "[variant=%s]" (nth 3 l))
 				"")
-			      (nth 1 l))))
+			      (if (and (consp l) (= (length l) 4))
+				  (nth 2 l)
+				(nth 1 l)))))
 		  languages
 		  ""))
 	 t t header 0)))))
-- 
2.32.0


[-- Attachment #3: test.org --]
[-- Type: application/vnd.lotus-organizer, Size: 1525 bytes --]

^ permalink raw reply related	[relevance 5%]

* Re: [Question] A single *-language-alist in ox-latex.el?
  2021-10-02 11:08  5% ` Stefan Nobis
@ 2021-10-02 19:20 12%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-10-02 19:20 UTC (permalink / raw)
  To: Stefan Nobis; +Cc: orgmode

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/


^ permalink raw reply	[relevance 12%]

* Re: [Question] A single *-language-alist in ox-latex.el?
  2021-10-02 10:48 12% [Question] A single *-language-alist in ox-latex.el? Juan Manuel Macías
@ 2021-10-02 11:08  5% ` Stefan Nobis
  2021-10-02 19:20 12%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Stefan Nobis @ 2021-10-02 11:08 UTC (permalink / raw)
  To: emacs-orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

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

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.

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

+1

-- 
Until the next mail...,
Stefan.


^ permalink raw reply	[relevance 5%]

* [Question] A single *-language-alist in ox-latex.el?
@ 2021-10-02 10:48 12% Juan Manuel Macías
  2021-10-02 11:08  5% ` Stefan Nobis
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-02 10:48 UTC (permalink / raw)
  To: orgmode

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/


^ permalink raw reply	[relevance 12%]

* Re: export dispatch → change the default "Contents" string
  2021-10-01 16:35  9% ` Juan Manuel Macías
@ 2021-10-01 16:45  1%   ` Jean-Christophe Helary
  0 siblings, 0 replies; 200+ results
From: Jean-Christophe Helary @ 2021-10-01 16:45 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Thank you Juan.

It does not seem to work as I expected, but that's OK, I just removed the ToC.

Jean-Christophe 

> On Oct 2, 2021, at 1:35, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> 
> 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 
> 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/



^ permalink raw reply	[relevance 1%]

* Re: export dispatch → change the default "Contents" string
  @ 2021-10-01 16:35  9% ` Juan Manuel Macías
  2021-10-01 16:45  1%   ` Jean-Christophe Helary
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-10-01 16:35 UTC (permalink / raw)
  To: Jean-Christophe Helary; +Cc: orgmode

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 



^ permalink raw reply	[relevance 9%]

* Re: Grabbing the link to a message on the archive
  @ 2021-10-01 15:07  4%     ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2021-10-01 15:07 UTC (permalink / raw)
  To: emacs-orgmode

On 30/09/2021 12:18, Timothy wrote:
> Hi Greg,
> 
>> i love the searching on list.orgmode.org, but i have this recurrent
>> dream: that some day each e-mail message will come with a header listing
>> the URL for that message on <https://list.orgmode.org>.  (though i also
>> worry this might open us up to some sort of spam, or other, attack?)
>>
>> and, i’ll add my thanks and congratulations on 9.5!
>>
>> cheers, Greg
> 
> If you use mu4e, the following may be of some interest:
> ┌────
> │ (defun +mu4e-ml-message-link (msg)
> │   (cond
> │    ((string= "emacs-orgmode.gnu.org" (mu4e-message-field msg :mailing-list))
> │     (message "Link %s copied to clipboard" (gui-select-text (format "https://list.orgmode.org/%s" (mu4e-message-field msg :message-id)))))
> │    (t (user-error "Mailing list %s not supported" (mu4e-message-field msg :mailing-list)))))
> │ (add-to-list 'mu4e-view-actions (cons "link to message ML" #'+mu4e-ml-message-link t))
> └────
> 
> I expect this could be adapted to other clients (notmuch, gnus, etc.)
> without much trouble :)

lists.gnu.org allows to map Message-ID to URL as well:

https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=%2Bmessage-id%3A87tuolhyl7.fsf%40posteo.net&idxname=emacs-orgmode

Unfortunately I have no idea how to get Message-ID having a link to 
particular message on lists.gnu.org without search by e.g. subject and 
author.

I had an impression that mailman mangles links like
https://list.orgmode.org/87tuolhyl7.fsf@posteo.net
since they resemble email addresses, so should be protected from 
spammers. I do not have links to prove it for mailman but debbugs 
certainly does it. In this sense links to lists.gnu.org are safer:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00133.html
A cheat for debbugs maybe the following: replace "@" to "%40" 
https://list.orgmode.org/87tuolhyl7.fsf%40posteo.net/T/#u
(Message that I used in these examples: Juan Manuel Macías. [tip] search 
this mailing list with helm-surfraw. 2021-04-05  9:25 UTC)

list.orgmode.org (public inbox) is an ordinary subscriber just as you, 
so it can not add any link to messages delivered to you. There is a 
dedicated header Archived-At that mail list may add, unfortunately 
mailman does not know URL at the time of message processing, so it adds 
only a link to whole archive as List-Archive.

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/rfc-2369.html#archive-headers

Curiously news.gmane.io still adds Archived-At despite web interface was 
disabled years ago.



^ permalink raw reply	[relevance 4%]

* Re: [PATCH] Fix some typos
  2021-09-24 12:23  7%             ` Juan Manuel Macías
  2021-09-25 11:08  6%               ` Marco Wahl
  2021-09-25 11:47  6%               ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
@ 2021-09-29 11:14  6%               ` Bastien
  2 siblings, 0 replies; 200+ results
From: Bastien @ 2021-09-29 11:14 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Marco Wahl, Loris Bennett, orgmode, Max Nikulin

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I also removed a spurious phrase that I put in that patch
> (Org-News).

Applied too!  Thanks.

-- 
 Bastien


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Fix some typos
  2021-09-29 10:34  7%                 ` Max Nikulin
  2021-09-29 11:09  0%                   ` Marco Wahl
@ 2021-09-29 11:11  0%                   ` Bastien Guerry
  1 sibling, 0 replies; 200+ results
From: Bastien Guerry @ 2021-09-29 11:11 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Juan Manuel Macías, Marco Wahl, orgmode

Hi Max,

Max Nikulin <manikulin@gmail.com> writes:

> A message in this thread
> https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org

Thanks for bringing this to my attention: I've now applied Juan's
change in the main branch.

-- 
 Bastien


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] Fix some typos
  2021-09-29 10:34  7%                 ` Max Nikulin
@ 2021-09-29 11:09  0%                   ` Marco Wahl
  2021-09-29 11:11  0%                   ` Bastien Guerry
  1 sibling, 0 replies; 200+ results
From: Marco Wahl @ 2021-09-29 11:09 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Bastien, Juan Manuel Macías, orgmode

Max Nikulin <manikulin@gmail.com> writes:

> Bastien,
>
> A message in this thread
> https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel
> Macías, Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a
> Shakespeare's sonnet in org-manual.org
>
> Due to updated ORG-NEWS file, it could not be applied directly. I had
> it applied after
>
> commit d74a82448bc28dd9be7b57611038bbb4c7172bce
> Author: Sébastien Miquel <sebastien.miquel@posteo.eu>
> Date:   Fri May 28 21:14:22 2021 +0200
>
> and in such form it could be rebased to main. Alternatively ORG-NEWS
> part could be just dropped (and applied later).
>
> The story is the following:
> - 91373e15c8 doc/org-manual.org    13905 (Juan Manuel Macías
>   2021-05-15 15:44:36 +0200 13906)
> a documentation for verse formatting was added with a strange variant
> (spread over net though)
> - 215d80d02b doc/org-manual.org    13907 (Stefan Kangas 2021-09-16
>  14:40:12 -0700 13909)
> besides other typos, one in this verse was fixed
> - 4271f228db doc/org-manual.org    13909 (Marco Wahl 2021-09-20
>  12:09:31 +0200 13909)
> reverted one edit by Stefan likely assuming old English spelling.
>
> Nobody has an idea concerning origin of current variant (particular
> edition of Shakespeare's book), so Juan Manuel created the patch with
> variant published in recent books.
>
> In https://orgmode.org/list/sin28h$ufv$1@ciao.gmane.io/
> I tried to add the following header
> X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and
> another typo
> but the patch is not tracked currently on updates.orgmode.org
>
> On 25/09/2021 18:08, Marco Wahl wrote:
>> Juan Manuel Macías writes:
>> 
>>> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
>>> replaced by the version included in Wikipedia (Shakespeare, William.
>>> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
>>> p. 113). I also removed a spurious phrase that I put in that patch
>>> (Org-News).
>> Thanks for the fix of the ORGNEWS entry.  Nitpick: I'd prefer the
>> fix of
>> the ORGNEWS in a further patch for a little bit of more clarity.
>
> I agree with such remark, however I still suppose that the patch could
> be applied even in current variant.

Please go ahead with the patches as you like!  That nitpick is meant as
a hint for commits to come!


Regards,
-- 
Marco


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] Fix some typos
  2021-09-25 11:08  6%               ` Marco Wahl
@ 2021-09-29 10:34  7%                 ` Max Nikulin
  2021-09-29 11:09  0%                   ` Marco Wahl
  2021-09-29 11:11  0%                   ` Bastien Guerry
  0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2021-09-29 10:34 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: Juan Manuel Macías, Marco Wahl

Bastien,

A message in this thread
https://orgmode.org/list/87tuiaxivh.fsf@posteo.net/ (Juan Manuel Macías, 
Fri, 24 Sep 2021 12:23:14 +0000) contains a patch that fixes a 
Shakespeare's sonnet in org-manual.org

Due to updated ORG-NEWS file, it could not be applied directly. I had it 
applied after

commit d74a82448bc28dd9be7b57611038bbb4c7172bce
Author: Sébastien Miquel <sebastien.miquel@posteo.eu>
Date:   Fri May 28 21:14:22 2021 +0200

and in such form it could be rebased to main. Alternatively ORG-NEWS 
part could be just dropped (and applied later).

The story is the following:
- 91373e15c8 doc/org-manual.org    13905 (Juan Manuel Macías 
2021-05-15 15:44:36 +0200 13906)
a documentation for verse formatting was added with a strange variant 
(spread over net though)
- 215d80d02b doc/org-manual.org    13907 (Stefan Kangas 
2021-09-16 14:40:12 -0700 13909)
besides other typos, one in this verse was fixed
- 4271f228db doc/org-manual.org    13909 (Marco Wahl 
2021-09-20 12:09:31 +0200 13909)
reverted one edit by Stefan likely assuming old English spelling.

Nobody has an idea concerning origin of current variant (particular 
edition of Shakespeare's book), so Juan Manuel created the patch with 
variant published in recent books.

In https://orgmode.org/list/sin28h$ufv$1@ciao.gmane.io/
I tried to add the following header
X-Woof-Patch: org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and 
another typo
but the patch is not tracked currently on updates.orgmode.org

On 25/09/2021 18:08, Marco Wahl wrote:
> Juan Manuel Macías writes:
> 
>> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
>> replaced by the version included in Wikipedia (Shakespeare, William.
>> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
>> p. 113). I also removed a spurious phrase that I put in that patch
>> (Org-News).
> 
> Thanks for the fix of the ORGNEWS entry.  Nitpick: I'd prefer the fix of
> the ORGNEWS in a further patch for a little bit of more clarity.

I agree with such remark, however I still suppose that the patch could 
be applied even in current variant.



^ permalink raw reply	[relevance 7%]

* Re: how to export checkboxes to odt?
  2021-09-28 20:47 10% ` Juan Manuel Macías
@ 2021-09-29  6:29  1%   ` Uwe Brauer
  0 siblings, 0 replies; 200+ results
From: Uwe Brauer @ 2021-09-29  6:29 UTC (permalink / raw)
  To: emacs-orgmode


[-- Attachment #1.1: Type: text/plain, Size: 1383 bytes --]

>>> "JMM" == Juan Manuel Macías <maciaschain@posteo.net> writes:

Hi Juan,

> Hi Uwe,
> Uwe Brauer writes:

>> Any idea how to export checkboxes to odt?
>> 
>> I mean not just simply having [ ] in the odt document but having them translated as actual boxes.

> You can try:

> (defun my/org-odt--checkbox (item)
>   "Return check-box string associated to ITEM."
>   (let ((checkbox (org-element-property :checkbox item)))
>     (if (not checkbox) ""
>       (format "<text:span text:style-name=\"%s\">%s</text:span>"
> 	      "OrgCode" (cl-case checkbox
> 			  (on "\u2611 ") ; CHECK MARK
> 			  (off "\u2610 ")
> 			  (trans "[-] ")))))) ;; I don't know which character to choose here...

> (advice-add 'org-odt--checkbox :override  #'my/org-odt--checkbox)

Thanks very much, I saw it too late to respond yesterday. A couple of remarks

    1. (on "\u2611 ") ; CHECK MARK: I rather prefer 2612 but this is a
       question of taste

    2. It seems not to work, I loaded the function and Executed the
       advice, but 

When I tried to export this minimal example

* Check the conversion of checkboxes


    1. Latex $\boxtimes$

    2. UTF8 ☒,   ▢ □

    3. Org   [ ] and   [X]

    4. Org [] [-]

I obtained a odt file in which 3 and 4 were *not* converted to UTF8. I
attach the file. What do I miss?

Regards

Uwe 


[-- Attachment #1.2: checkbox.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 12057 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: how to export checkboxes to odt?
  @ 2021-09-28 20:47 10% ` Juan Manuel Macías
  2021-09-29  6:29  1%   ` Uwe Brauer
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-28 20:47 UTC (permalink / raw)
  To: Uwe Brauer; +Cc: orgmode

Hi Uwe,

Uwe Brauer writes:

> Any idea how to export checkboxes to odt?
>
> I mean not just simply having [ ] in the odt document but having them translated as actual boxes.

You can try:

(defun my/org-odt--checkbox (item)
  "Return check-box string associated to ITEM."
  (let ((checkbox (org-element-property :checkbox item)))
    (if (not checkbox) ""
      (format "<text:span text:style-name=\"%s\">%s</text:span>"
	      "OrgCode" (cl-case checkbox
			  (on "\u2611 ") ; CHECK MARK
			  (off "\u2610 ")
			  (trans "[-] ")))))) ;; I don't know which character to choose here...

(advice-add 'org-odt--checkbox :override  #'my/org-odt--checkbox)

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Possible bug? Combine emphasis marker faces?
  @ 2021-09-28 16:54 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-28 16:54 UTC (permalink / raw)
  To: Protesilaos Stavrou; +Cc: orgmode

Hi Protesilaos,

Protesilaos Stavrou writes:

> Is there a way to get composite styles?  Such as bold and italic or
> verbatim and underline, etc.?

A somewhat dirty solution (without patching the code) could be
evaluating highlight-regexp, for example as a local variable:

#+begin_src emacs-lisp
  (defface my/org-it-bold
    '((t :slant italic :bold t))
    "")

(highlight-regexp "\\([-[:space:]('\"{]\\|^\\)\\(\\([*/_+]\\)\\([*/_+]\\)\\([^[:space:]]\\|[^[:space:]].*?\\(?:
.*?\\)\\{0,15\\}[^[:space:]]\\)\\3\\)\\([-[:space:].,:!?;'\")}\\[]\\|$\\)" 'my/org-it-bold)
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: LaTeX export: grffile is a stub package
  @ 2021-09-27 17:00  9% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-27 17:00 UTC (permalink / raw)
  To: meedstrom; +Cc: orgmode

Hi,

meedstrom@teknik.io writes:

> According to https://ctan.org/pkg/grffile, since 2019-11-08, grffile
> is a stub that just loads graphicx, part of texlive-latex-graphics,
> part of texlive-base. My system (Guix) doesn't have a package for
> grffile, so I can't generate a PDF, which is silly because it's a stub
> anyway.
>
> Suggest fixing by removing \usepackage{grffile} in LaTeX export.
>
> A caveat: some distributions seem to still package an old TeXLive full
> distribution, going by Guix which provides a three-gigabyte "texlive"
> package from 2019-04-10. I'm not sure what sort of deprecation time we
> allow.

grffile is a deprecated LaTeX package, but it is included in TeX live
2021 (Arch). The Arch version of TeXlive is identical to the official
version (except that it does not include the documentation, which must
be installed using an AUR package). My recommendation: unless you are in
Arch or one of its derivatives, it is better to always install *the
official and lastest version* of TeX live (with its own installer and
its own package manager); the versions included in the repositories of
many distros (except for Arch and very few others) are usually outdated
or incomplete, and it is better to avoid them. The current version of
TeXlive is TeXlive 2021. There is, by tradition, a version per year and
in each one many things are modified and quite bugs fixed.

Best regards,

Juan Manuel



^ permalink raw reply	[relevance 9%]

* Re: [BUG] Conflict between org-emphasis and org-latex
  2021-09-26 16:57  7%   ` Léo Ackermann
@ 2021-09-26 18:29  9%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-26 18:29 UTC (permalink / raw)
  To: Léo Ackermann, Timothy; +Cc: orgmode

Hi Léo and Timothy,

Léo Ackermann writes:

> [...]
> I think that this bug has been introduced recently (I
> never noticed it before)

I don't know if I'm pointing in the right direction, or I am missing
something, but I would say that this is a problem (or consequence) of
`org-emphasis-regexp-components'. According to the docstring, it is a list
with five parts:

("-[:space:]('\"{"
"-[:space:].,:!?;'\")}\\["
"[:space:]"
"."  ;; <<====
15)

where part 4, body-regexp, is: "A regexp like "." to match a body
character. Don’t use non-shy groups here, and don’t allow
newline here".

Therefore, the segment "} and {" is fontized here as emphasis

For a LaTeX fragment I think you can do:

(setq org-highlight-latex-and-related 'script)

According to the docstrip:

Non-nil means highlight LaTeX related syntax in the buffer.
When non-nil, the value should be a list containing any of the
following symbols:
  ‘native’   Highlight LaTeX snippets and environments natively.
  ‘latex’    Highlight LaTeX snippets and environments.
  ‘script’   Highlight subscript and superscript.
  ‘entities’ Highlight entities.

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 9%]

* Re: [BUG] Conflict between org-emphasis and org-latex
  2021-09-26 12:57 10% ` Juan Manuel Macías
@ 2021-09-26 16:57  7%   ` Léo Ackermann
  2021-09-26 18:29  9%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Léo Ackermann @ 2021-09-26 16:57 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

Hi Juan Manuel,

I agree that some tricks exist in order to prevent this behavior.
Nevertheless, I think that this bug has been introduced recently (I never
noticed it before) and has to be corrected properly (as this is a really
basic use of org-mode).
Unfortunately, I can barely understand elisp... so writing a patch is far
away from what I can do :/

Best,
Leo

Le dim. 26 sept. 2021 à 14:57, Juan Manuel Macías <maciaschain@posteo.net>
a écrit :

> Hi Léo,
>
> Léo Ackermann writes:
>
> > Hi!
> > I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> > following happens:
> > When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> > two stars match together, causing "and" to appear in bold case.
> >
> > Any idea to fix this unwanted behavior ?
>
> You can insert a zero width space character (U+200B), to prevent that
> segment is fontified as emphasis [see the Manual in the section `Escape
> Character']. It is enough with insert the character after one of the
> asterisks: M-x insert-char RET 200b RET. I also recommend that you look
> at this section on Timothy's blog `This Month in Org':
> https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width
>
> Best regards,
>
> Juan Manuel
>

[-- Attachment #2: Type: text/html, Size: 1816 bytes --]

^ permalink raw reply	[relevance 7%]

* Re: [BUG] Conflict between org-emphasis and org-latex
  @ 2021-09-26 12:57 10% ` Juan Manuel Macías
  2021-09-26 16:57  7%   ` Léo Ackermann
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-26 12:57 UTC (permalink / raw)
  To: Léo Ackermann; +Cc: orgmode

Hi Léo,

Léo Ackermann writes:

> Hi!
> I noticed that in org@888aaa97c0ce331097787333d0d712dd6e4d078f, the
> following happens:
> When writing `Consider $a^{*}$ and $b^{*}$` in an org-mode buffer, the
> two stars match together, causing "and" to appear in bold case. 
>
> Any idea to fix this unwanted behavior ?

You can insert a zero width space character (U+200B), to prevent that
segment is fontified as emphasis [see the Manual in the section `Escape
Character']. It is enough with insert the character after one of the
asterisks: M-x insert-char RET 200b RET. I also recommend that you look
at this section on Timothy's blog `This Month in Org':
https://blog.tecosaur.com/tmio/2021-05-31-async.html#easy-zero-width

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
  2021-09-26 11:35 10%         ` Juan Manuel Macías
@ 2021-09-26 12:49  6%           ` Bastien
  0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-09-26 12:49 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I have consulted the log, and the patch was already applied by Nicololas
> in commit

Oops, sorry for the noise and thanks for confirming!

-- 
 Bastien


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
  2021-09-26  6:08  6%       ` Bastien
@ 2021-09-26 11:35 10%         ` Juan Manuel Macías
  2021-09-26 12:49  6%           ` Bastien
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-26 11:35 UTC (permalink / raw)
  To: Bastien; +Cc: orgmode

Hi Bastien, thank you for your message,

Bastien writes:

> I could not apply the patch in the bugfix or main branch.  Is it still
> relevant?  If the bug is still here, feel free to send an updated patch.

I have consulted the log, and the patch was already applied by Nicololas
in commit:

40a20136d * | | Prevent partial fontification when a link is displayed full

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [PATCH] org.el: use only link descriptions in indirect buffer names
  @ 2021-09-26  7:40  6%     ` Bastien
  0 siblings, 0 replies; 200+ results
From: Bastien @ 2021-09-26  7:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> (new patch attached)

I see this patch has been applied, thanks to both of you.

I'm marking it as applied for updates.orgmode.org.

-- 
 Bastien


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.)
  @ 2021-09-26  6:08  6%       ` Bastien
  2021-09-26 11:35 10%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Bastien @ 2021-09-26  6:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hi Juan,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> As a possible solution I'm attaching this patch (little tested).

I could not apply the patch in the bugfix or main branch.  Is it still
relevant?  If the bug is still here, feel free to send an updated patch.

Thanks!

-- 
 Bastien


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-23 17:17  8%           ` Juan Manuel Macías
@ 2021-09-25 19:56  7%             ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-25 19:56 UTC (permalink / raw)
  To: orgmode; +Cc: Max Nikulin

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

Hi again,

I am attaching a new version of the patch, with some typos fixed and a
explanatory note in the commit message on the choice of the character
U+201C as Greek second-level opening quotes.

In case anyone is interested in what Yanis Haralambous answered me in a
recent mail, I reproduce here (with his permission) a fragment of the
message:

#+begin_quote
[...] to answer your question, the average Greek writer would use
U+201C. For those that seek Greek typographic tradition, there should be
a substitution [...], but it would be more appropriate to do it
on the glyph level. From a grapholinguistic point of view there is
absolutely no need of using U+201F, the difference should be on the
alllographic level, the grapheme should only carry the information
"CLOSING DOUBLE SECOND-LEVEL QUOTATION MARK" and U+201C is a good choice
for representing that grapheme since it is used in most countries of the
world…
#+end_quote

Therefore, if someone wishes to use the historical character [in a
LuaTeX or XeTeX document] (represented by U+201F), I agree with Yannis
that it is better to use that symbol at the glyph level and not at the
character level. For this scenario a GSUB opentype feature would work
very well, since it is a historical character (as in the case of
historical ligatures, alternate glyphs, etc.). 

Best regards,

Juan Manuel


[-- Attachment #2: 0001-ox.el-add-smart-quotes-for-greek.patch --]
[-- Type: text/x-patch, Size: 2062 bytes --]

From 86edfd424d01a08cc277540644e0cdc7df075b72 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 25 Sep 2021 20:41:43 +0200
Subject: [PATCH] ox.el: add smart quotes for greek

* lisp/ox.el (org-export-smart-quotes-alist): The correct quotes for
Greek have been established with the help of Protesilaos Stavrou, who
has contributed a style guide for the European institutions:
http://publications.europa.eu/code/el/el-4100107el.htmq On the correct
character for Greek second-level opening quotes, according to Yannis
Haralambous (`From Unicode to Typography, a Case Study: the Greek
Script' (1999, p. 20), a symbol equivalent to the Unicode character
U+201F is historically attested. But it seems that the current trend
in Greece is to apply the character U+201C, more commonly used in
other languages. Haralambous himself, in a recent consultation,
states: `[...] U+201C is a good choice for representing that grapheme
since it is used in most countries of the world...'
---
 lisp/ox.el | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 18b13a326..89a3ff5f1 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5437,6 +5437,16 @@ transcoding it."
      (secondary-closing
       :utf-8 "‘" :html "&lsquo;" :latex "\\grq{}" :texinfo "@quoteleft{}")
      (apostrophe :utf-8 "’" :html "&rsquo;"))
+    ("el"
+     (primary-opening
+      :utf-8 "«" :html "&laquo;" :latex "\\guillemotleft{}"
+      :texinfo "@guillemetleft{}")
+     (primary-closing
+      :utf-8 "»" :html "&raquo;" :latex "\\guillemotright{}"
+      :texinfo "@guillemetright{}")
+     (secondary-opening :utf-8 "“" :html "&ldquo;" :latex "``" :texinfo "``")
+     (secondary-closing :utf-8 "”" :html "&rdquo;" :latex "''" :texinfo "''")
+     (apostrophe :utf-8 "’" :html "&rsquo;"))
     ("en"
      (primary-opening :utf-8 "“" :html "&ldquo;" :latex "``" :texinfo "``")
      (primary-closing :utf-8 "”" :html "&rdquo;" :latex "''" :texinfo "''")
-- 
2.33.0


^ permalink raw reply related	[relevance 7%]

* Re: [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo
  2021-09-24 12:23  7%             ` Juan Manuel Macías
  2021-09-25 11:08  6%               ` Marco Wahl
@ 2021-09-25 11:47  6%               ` Max Nikulin
  2021-09-29 11:14  6%               ` [PATCH] Fix some typos Bastien
  2 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2021-09-25 11:47 UTC (permalink / raw)
  To: emacs-orgmode

On 24/09/2021 19:23, Juan Manuel Macías wrote:
> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
> replaced by the version included in Wikipedia (Shakespeare, William.
> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
> p. 113).

Thank you, Juan Manuel. With you patch the text becomes almost identical to
- Shakespeare's Sonnets  (1883) William Shakespeare, edited by William 
J. Rolfe 
https://en.wikisource.org/wiki/Shakespeare%27s_Sonnets_(1883)/Sonnet_1
- Shakespeare's Sonnets  (1923) William Shakespeare, edited by Edward 
Bliss Reed 
https://en.wikisource.org/wiki/Shakespeare%27s_Sonnets_(1923)_Yale/Text/Sonnet_1

I think, variations are not significant: "niggardly" / "niggarding" and 
a few more commas in the older editions.

I hope, Unicode single comma apostrophe U+2019 (right single quotation 
mark) is not a problem (vs. \x27 ASCII character). Anyway it is used in 
the current variant and nobody complains.

I think, the patch should be applied to avoid proliferation of a variant 
with strange spelling in the web.



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Fix some typos
  2021-09-24 12:23  7%             ` Juan Manuel Macías
@ 2021-09-25 11:08  6%               ` Marco Wahl
  2021-09-29 10:34  7%                 ` Max Nikulin
  2021-09-25 11:47  6%               ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
  2021-09-29 11:14  6%               ` [PATCH] Fix some typos Bastien
  2 siblings, 1 reply; 200+ results
From: Marco Wahl @ 2021-09-25 11:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Loris Bennett, orgmode, Max Nikulin

Please don't top post!  Hopefully there is consent about using the
bottom posting style on this list.

Juan Manuel Macías <maciaschain@posteo.net> writes:

> I attach a patch with Shakespeare's sonnet completely fixed: the poem is
> replaced by the version included in Wikipedia (Shakespeare, William.
> Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
> p. 113). I also removed a spurious phrase that I put in that patch
> (Org-News).

Thanks for the patch!

I agree to change the Shakespeare part to have a reference and be
corrected accordingly.

Thanks for the fix of the ORGNEWS entry.  Nitpick: I'd prefer the fix of
the ORGNEWS in a further patch for a little bit of more clarity.

AFAICS thy patch mught apply!





^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Fix some typos
  2021-09-24  6:03  0%           ` Loris Bennett
@ 2021-09-24 12:23  7%             ` Juan Manuel Macías
  2021-09-25 11:08  6%               ` Marco Wahl
                                 ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2021-09-24 12:23 UTC (permalink / raw)
  To: Loris Bennett, Max Nikulin, Marco Wahl; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

I attach a patch with Shakespeare's sonnet completely fixed: the poem is
replaced by the version included in Wikipedia (Shakespeare, William.
Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden 2010.
p. 113). I also removed a spurious phrase that I put in that patch
(Org-News).

Best regards,

Juan Manuel

Loris Bennett writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 23/09/2021 03:18, Juan Manuel Macías wrote:
>>> Max Nikulin writes:
>>>
>>>> However there is namely "memory" in the "1609 Quarto", see e.g.
>>>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>>>> as in the Org manual do not mention the source (particular edition). I
>>>> hope, I just do not know what is considered as the canonical variant
>>>> for not so old language.
>>>
>>> I am not an expert on Shakespeare's poetry either, but as the author of
>>> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
>>> (sorry). At least I didn't use that word intentionally. I don't know if
>>> there is any textual variant 'memeory', but in my case it is nothing
>>> more than a simple typo :-).
>>
>> Then "mught" should be another typo.
>>
>> "His tender heire might beare his memory:" - 1609 Quatro
>
> I think "Quatro" is another typo and should be "Quarto" (unless there
> is a typo in the date and it is a line from little-know song by Suzi ...)
>
>> "His tender heir might bear his memory:" - Wikipedia citing Shakespeare,
>> William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden
>> 2010. p. 113 ISBN 9781408017975
>>
>> "His tender heir mught bear his memeory:" - some web pages and Org manual.
>>
>>


[-- Attachment #2: 0001-org-manual.org-ORG-NEWS-fix-Shakespeare-sonnet-and-a.patch --]
[-- Type: text/x-patch, Size: 3153 bytes --]

From f2e09b5e50a08b409e5f48df59dffbb36e9677ac Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Fri, 24 Sep 2021 13:58:30 +0200
Subject: [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another
 typo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* doc/org-manual.org (Verse blocks in LaTeX export): The previous
version of Shakespeare's sonnet is replaced by the version included in
Wikipedia (Shakespeare, William. Duncan-Jones, Katherine. Shakespeare’s
Sonnets. Bloomsbury Arden 2010. p. 113)
* etc/ORG-NEWS (Support verse blocks in LaTeX export): The last
sentence is superfluous. There is no explanation below.
---
 doc/org-manual.org | 17 +++++++++--------
 etc/ORG-NEWS       |  3 +--
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index b5de85cc9..ba396e205 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13897,24 +13897,25 @@ explained below.
 - =:latexcode= :: It accepts any arbitrary LaTeX code that can be
   included within a LaTeX =verse= environment.
 
-A complete example with Shakespeare's first sonnet:
+A complete example with Shakespeare's first sonnet (source:
+[[https://en.wikipedia.org/wiki/Sonnet_1]]):
 
 #+begin_src org
 ,#+ATTR_LATEX: :center t :latexcode \color{red} :lines 5
-,#+ATTR_LATEX: :versewidth Feed’st thy light’st flame with self-substantial fuel,
+,#+ATTR_LATEX: :versewidth Feed’st thy light’s flame with self-substantial fuel,
 ,#+BEGIN_VERSE
 From fairest creatures we desire increase,
 That thereby beauty’s rose might never die,
-But as the riper should by time decrease,
-His tender heir mught bear his memeory:
+But as the riper should by time decease
+His tender heir might bear his memory:
 But thou, contracted to thine own bright eyes,
-Feed’st thy light’st flame with self-substantial fuel,
+Feed’st thy light’s flame with self-substantial fuel,
 Making a famine where abundance lies,
 Thyself thy foe, to thy sweet self too cruel.
-Thou that art now the world’s fresh ornament
+Thou that art now the world’s fresh ornament,
 And only herald to the gaudy spring,
-Within thine own bud buriest thy content
-And, tender churl, makest waste in niggarding.
+Within thine own bud buriest thy content,
+And, tender churl, mak’st waste in niggardly.
 Pity the world, or else this glutton be,
 To eat the world’s due, by the grave and thee.
 ,#+END_VERSE
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7a46e825b..9a674cc04 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -254,8 +254,7 @@ that Org mode configures LaTeX to process any new float type.
 The LaTeX export back-end accepts four attributes for verse blocks:
 =:lines=, =:center=, =:versewidth= and =:latexcode=. The three first
 require the external LaTeX package =verse.sty=, which is an extension
-of the standard LaTeX environment. The purpose of these attributes is
-explained below.
+of the standard LaTeX environment.
 
 *** Support quote blocks in LaTeX export
 
-- 
2.32.0


^ permalink raw reply related	[relevance 7%]

* Re: [PATCH] Fix some typos
  2021-09-23 14:49  6%         ` Max Nikulin
@ 2021-09-24  6:03  0%           ` Loris Bennett
  2021-09-24 12:23  7%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Loris Bennett @ 2021-09-24  6:03 UTC (permalink / raw)
  To: emacs-orgmode

Max Nikulin <manikulin@gmail.com> writes:

> On 23/09/2021 03:18, Juan Manuel Macías wrote:
>> Max Nikulin writes:
>>
>>> However there is namely "memory" in the "1609 Quarto", see e.g.
>>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>>> as in the Org manual do not mention the source (particular edition). I
>>> hope, I just do not know what is considered as the canonical variant
>>> for not so old language.
>>
>> I am not an expert on Shakespeare's poetry either, but as the author of
>> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
>> (sorry). At least I didn't use that word intentionally. I don't know if
>> there is any textual variant 'memeory', but in my case it is nothing
>> more than a simple typo :-).
>
> Then "mught" should be another typo.
>
> "His tender heire might beare his memory:" - 1609 Quatro

I think "Quatro" is another typo and should be "Quarto" (unless there
is a typo in the date and it is a line from little-know song by Suzi ...)

> "His tender heir might bear his memory:" - Wikipedia citing Shakespeare,
> William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury Arden
> 2010. p. 113 ISBN 9781408017975
>
> "His tender heir mught bear his memeory:" - some web pages and Org manual.
>
>
-- 
This signature is currently under construction.



^ permalink raw reply	[relevance 0%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-23 16:10  6%         ` Max Nikulin
@ 2021-09-23 17:17  8%           ` Juan Manuel Macías
  2021-09-25 19:56  7%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-23 17:17 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Hi Maxim,

Max Nikulin writes:

> Juan Manuel, I feel some misunderstanding. I am not asking for more
> arguments in support of current variant of patch. CLDR entry, EU 
> recommendations, the mail from Protesilaos, absence of named HTML
> entity, complications with pdfTeX are more than enough.

I completely agree with what you say, but I think I have explained wrong
in my previous mail. I said about consulting YH because his article is
something old (90s), and his current opinion on "the state of the
question" could help me compose my little explanatory note. And in any
case, I think everyone here agrees that the character that he proposed
in his paper is unfeasible in Org, for all the reasons you have
summarized. On the other hand, the orthographic norms are not sacred
norms; rather, they are determined by use and customs. For example, here
in Spain the manuals and treatises tend to disagree on certain issues.
In my opinion, many times it is better to talk about trends more than
norms[1], and trends that more or less end imposing, almost by mere
natural selection (another matter is that sometimes bad habits are also
imposed, for using inappropriate software, but this is not the case
where we are).

[1] For example, in Spanish of Spain, the quotation marks are «“ ”»,
But in Mexican Spanish they use “‘’” as in English. In fact the
csquotes LaTeX package includes both styles.

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-22 19:55  8%       ` Juan Manuel Macías
@ 2021-09-23 16:10  6%         ` Max Nikulin
  2021-09-23 17:17  8%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-23 16:10 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: orgmode

On 23/09/2021 02:55, Juan Manuel Macías wrote:
> 
> Before uploading a corrected version of the patch (with a small
> explanatory note), I could consult Haralambous himself by mail, and ask
> him what he thinks of this question...

Juan Manuel, I feel some misunderstanding. I am not asking for more 
arguments in support of current variant of patch. CLDR entry, EU 
recommendations, the mail from Protesilaos, absence of named HTML 
entity, complications with pdfTeX are more than enough.

Some degree of uncertainty during software development is unavoidable, 
so it is perfectly OK to proceed with the variant you have proposed. It 
is better to address other issues.

I suggest just to document the decision, to mention pros and cons. There 
is a little chance that the decision might be reconsidered later and it 
is not a problem. It would be nice to provide useful hints for 
participants of future discussion. Even information that another 
language was added not just for completeness and with guessed values 
might be helpful.



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Fix some typos
  2021-09-22 20:18 10%       ` Juan Manuel Macías
@ 2021-09-23 14:49  6%         ` Max Nikulin
  2021-09-24  6:03  0%           ` Loris Bennett
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-23 14:49 UTC (permalink / raw)
  To: Juan Manuel Macías, Marco Wahl; +Cc: orgmode

On 23/09/2021 03:18, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> However there is namely "memory" in the "1609 Quarto", see e.g.
>> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant
>> as in the Org manual do not mention the source (particular edition). I
>> hope, I just do not know what is considered as the canonical variant
>> for not so old language.
> 
> I am not an expert on Shakespeare's poetry either, but as the author of
> the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
> (sorry). At least I didn't use that word intentionally. I don't know if
> there is any textual variant 'memeory', but in my case it is nothing
> more than a simple typo :-).

Then "mught" should be another typo.

"His tender heire might beare his memory:" - 1609 Quatro

"His tender heir might bear his memory:" - Wikipedia citing Shakespeare, 
William. Duncan-Jones, Katherine. Shakespeare’s Sonnets. Bloomsbury 
Arden 2010. p. 113 ISBN 9781408017975

"His tender heir mught bear his memeory:" - some web pages and Org manual.


^ permalink raw reply	[relevance 6%]

* Re: [ANN] org-ql 0.6 released
  2021-09-22 12:10 10% ` Juan Manuel Macías
@ 2021-09-22 22:41  6%   ` Adam Porter
  0 siblings, 0 replies; 200+ results
From: Adam Porter @ 2021-09-22 22:41 UTC (permalink / raw)
  To: emacs-orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Hi Adam,
>
> Thank you very much for this great package. I could no longer live without
> org-ql/helm-org-ql :-)

Hi Juan,

Thanks for the kind words.  I'm glad it's useful to you.  :)



^ permalink raw reply	[relevance 6%]

* Re: [PATCH] Fix some typos
  @ 2021-09-22 20:18 10%       ` Juan Manuel Macías
  2021-09-23 14:49  6%         ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 20:18 UTC (permalink / raw)
  To: Max Nikulin, Marco Wahl; +Cc: orgmode

Hi all:

Max Nikulin writes:

> Please, forgive my ignorance of Shakespeare's poetry.
>
> On 17/09/2021 17:05, Marco Wahl wrote:
>>> On 17/09/2021 04:40, Stefan Kangas wrote:
>> 
>>>> Please find attached another clean-up patch that fixes a small
>>>> number of typos. > > Thou shall not change "memeory" to "memory" tho
> I think, a bit more is required to avoid recurring attempts to change
> spelling if you would like to see such variant. Static code analyzers 
> usually have a feature that allows to ignore specific warning at a
> particular line, see e.g. 
> https://flake8.pycqa.org/en/latest/user/violations.html#in-line-ignoring-errors
> for Python's flake8.
>
> Maybe "LocalWords:" could do a similar trick for ispell.el at least
> for the whole file. Unsure if it is possible to add an exception for
> the quote only.
>
> However there is namely "memory" in the "1609 Quarto", see e.g.
> https://en.wikipedia.org/wiki/Sonnet_1 Web pages with the same variant 
> as in the Org manual do not mention the source (particular edition). I
> hope, I just do not know what is considered as the canonical variant
> for not so old language.

I am not an expert on Shakespeare's poetry either, but as the author of
the patch where Sonnet 1 is included, I can say that 'memeory' is a typo
(sorry). At least I didn't use that word intentionally. I don't know if
there is any textual variant 'memeory', but in my case it is nothing
more than a simple typo :-).

Best regards,

Juan Manuel 






^ permalink raw reply	[relevance 10%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-22 17:19  5%     ` Max Nikulin
@ 2021-09-22 19:55  8%       ` Juan Manuel Macías
  2021-09-23 16:10  6%         ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 19:55 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> I believe, the patch is an improvement. It would be nice to have a
> comment clarifying the choice of secondary opening quote mark, but it
> is not required. It seems there is no recommendations or established 
> practice for documenting of such decisions. I have not tested the
> patch though.

Since it's a "orthotypographical" addition, where there is a reasonable
doubt in one of the characters, I agree that a minimal explanatory note
in the commit message would be desirable. But it would have (IMHO) to be
something very brief.

>> -`org-export-smart-quotes-alist' and `org-export-dictionary'.
>> +`org-export-smart-quotes-' and `org-export-dictionary'.
>
> It it intentional change? I have not found other variables having the
> same prefix.

Oh, sorry. It's a horrible typo: I modified that part involuntarily, and
I didn't see it :-(.

> That character could get better support in future. I know, such chance
> is almost improbable, but imagine, a person familiar with the paper of 
> Haralambous would consider change of the quote mark in question
> believing that Org developers were not aware of the "right" symbol. A 
> comment in the source code may provide a hint that the choice was conscious.
>
> I forgot to mention it in my message from 2020-08-15 that I did not
> find the U+201F character in TeX pre-unicode LG* encodings for Greek.

In fact, the character is only problematic in pdfTeX. In XeTeX and
LuaTeX there is no problem, and you can also use the csquotes package.
But in pdfTeX you can't even get it with the
\usepackage[utf8x]{inputenc} option, which is to be expected, since
Unicode support of imputenc is very limited. LuaTeX is the natural
replacement for pdfTeX, but at the moment we have to maintain backward
compatibility and I can't find a way to represent that character in
pdfTeX. This second level quotes issue is not mentioned by Apostolos
Syropoulos in the babel greek documentation:
(https://www.ctan.org/pkg/babel-greek). There is probably no support for
this character in babel-greek.

Before uploading a corrected version of the patch (with a small
explanatory note), I could consult Haralambous himself by mail, and ask
him what he thinks of this question...

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 8%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-21 20:20  8%   ` Juan Manuel Macías
@ 2021-09-22 17:19  5%     ` Max Nikulin
  2021-09-22 19:55  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-22 17:19 UTC (permalink / raw)
  To: emacs-orgmode

I believe, the patch is an improvement. It would be nice to have a 
comment clarifying the choice of secondary opening quote mark, but it is 
not required. It seems there is no recommendations or established 
practice for documenting of such decisions. I have not tested the patch 
though.

> -`org-export-smart-quotes-alist' and `org-export-dictionary'.
> +`org-export-smart-quotes-' and `org-export-dictionary'.

It it intentional change? I have not found other variables having the 
same prefix.

On 22/09/2021 03:20, Juan Manuel Macías wrote:
>> [...]
>> Possible options:
>> - Add the note directly to the .el file. I am afraid, as inline
>>    comment it could be considered too long.
>> - To a file in the "doc" directory dedicated to such decisions (there
>>    is no such file yet however) with a reference from the .el file.
>> - Commit message. It is acceptable but not apparent for a person who
>>    reads the code that git log may provide detailed explanation of
>> particular choice.
> ...
> Haralambous is a great TeX guru, and a great scholar and theorist of
> Greek typography, but... I would say that in this case his mind is more
> focused on a historical tradition probably abandoned before the digital
> age.

That character could get better support in future. I know, such chance 
is almost improbable, but imagine, a person familiar with the paper of 
Haralambous would consider change of the quote mark in question 
believing that Org developers were not aware of the "right" symbol. A 
comment in the source code may provide a hint that the choice was conscious.

I forgot to mention it in my message from 2020-08-15 that I did not find 
the U+201F character in TeX pre-unicode LG* encodings for Greek.



^ permalink raw reply	[relevance 5%]

* Re: [ANN] org-ql 0.6 released
  @ 2021-09-22 12:10 10% ` Juan Manuel Macías
  2021-09-22 22:41  6%   ` Adam Porter
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-22 12:10 UTC (permalink / raw)
  To: Adam Porter; +Cc: orgmode

Hi Adam,

Thank you very much for this great package. I could no longer live without
org-ql/helm-org-ql :-)

Best regards,

Juan Manuel 

Adam Porter writes:

> Hi friends,
>
> FYI, I just released version 0.6 of org-ql.  Please see the changelog
> here:
>
> https://github.com/alphapapa/org-ql#06



^ permalink raw reply	[relevance 10%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-20 14:54  4% ` Max Nikulin
@ 2021-09-21 20:20  8%   ` Juan Manuel Macías
  2021-09-22 17:19  5%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-21 20:20 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Hi Maxim,

Max Nikulin writes:

> [...]
> Possible options:
> - Add the note directly to the .el file. I am afraid, as inline
>   comment it could be considered too long.
> - To a file in the "doc" directory dedicated to such decisions (there
>   is no such file yet however) with a reference from the .el file.
> - Commit message. It is acceptable but not apparent for a person who
>   reads the code that git log may provide detailed explanation of 
> particular choice.

Thanks for your suggestions. Maybe I could add a link to the Haralambous
paper in the commit message, along with a very short note... In any
case, the only issue is with the second level opening quotes.
Haralambous asserts that the (pretty rare) character U+201F must be
used, and not the character U+201C, which is the one used in English
(among many other languages) and in Spanish second level quotes, and the
one that I have applied (proposed by Protesilaos) to the patch.
Haralambous is a great TeX guru, and a great scholar and theorist of
Greek typography, but... I would say that in this case his mind is more
focused on a historical tradition probably abandoned before the digital
age. I really don't know. Moreover, it is difficult to find specimens of
the use of second-level quotation marks. I have looked in Greek books
printed in the early and middle of the last century, and I have not
found anything. My suspicion is that in Greek nowadays the character
U+201C (common in other languages ---as I said before--- and therefore
better known) has ended up standardizing for second level opening
quotes. Maybe all the above could be summarized in less than one line
inside the commit message ;-). A quick search, by the way, of the term
'εισαγωγικά' (= 'quotation marks') on www.greek-language.gr returns this
result, where it is seen clearly the character U+201C:

... (« » ή “ ”) ...

https://www.greek-language.gr/greekLang/modern_greek/tools/lexica/search.html?lq=%CE%B5%CE%B9%CF%83%CE%B1%CE%B3%CF%89%CE%B3%CE%B9%CE%BA%CE%AC

Best regards,

Juan Manuel 





^ permalink raw reply	[relevance 8%]

* Re: [PATCH] ox.el: add smart quotes for Greek
  2021-09-19 16:30  9% [PATCH] ox.el: add smart quotes for Greek Juan Manuel Macías
@ 2021-09-20 14:54  4% ` Max Nikulin
  2021-09-21 20:20  8%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2021-09-20 14:54 UTC (permalink / raw)
  To: orgmode; +Cc: Juan Manuel Macías

On 19/09/2021 23:30, Juan Manuel Macías wrote:
> 
> I attach here a tiny patch to add Greek smart quotes. Finally, I apply
> the second level quotation marks that Protesilaos Stavrou proposed in this
> previous thread:
> https://orgmode.org/list/87o89yv1mz.fsf@cnu407c2zx.nsn-intra.net/#r

Since the choice of secondary opening quote character was uncertain at 
first, I suppose, it would be nice to have this decision documented 
somewhere in Org source repository for the case that it might be 
revisited later. (Disclaimer: unsure that Org developers have the same 
opinion.)

I mean the citation and the reference to the paper by Yannis Haralambous 
to make clear that such variant was considered, the title of EU 
recommendations since nobody has provided more authoritative reference 
of Greek typography traditions.

Possible options:
- Add the note directly to the .el file. I am afraid, as inline comment 
it could be considered too long.
- To a file in the "doc" directory dedicated to such decisions (there is 
no such file yet however) with a reference from the .el file.
- Commit message. It is acceptable but not apparent for a person who 
reads the code that git log may provide detailed explanation of 
particular choice.

Mail archives are not permanent, e.g. web interface to Gmane was shut 
down due to some problems, the same might happen with public inbox 
mirrors. That is why, I think, a more detailed note should be added to 
Org sources.

By the way, Common Locale Data Repository https://cldr.unicode.org/
defines U+201C (&#8220;) and U+201D (&#8221;) characters as well

ag quotation common/main/el*
common/main/el.xml
1224:		<quotationStart>«</quotationStart>
1225:		<quotationEnd>»</quotationEnd>
1226:		<alternateQuotationStart>“</alternateQuotationStart>
1227:		<alternateQuotationEnd>”</alternateQuotationEnd>

Unfortunately this part of Unicode databases is not available form Emacs.


^ permalink raw reply	[relevance 4%]

* [PATCH] ox.el: add smart quotes for Greek
@ 2021-09-19 16:30  9% Juan Manuel Macías
  2021-09-20 14:54  4% ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-19 16:30 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

Hi,

I attach here a tiny patch to add Greek smart quotes. Finally, I apply
the second level quotation marks that Protesilaos Stavrou proposed in this
previous thread:
https://orgmode.org/list/87o89yv1mz.fsf@cnu407c2zx.nsn-intra.net/#r

So the quotation marks setting for Greek is exactly the same as in the
case of quotation marks for Spanish.

Thanks a lot to Protesilaos, Michalis and Maxim Nikulin for their suggestions on
that thread (Maxim, sorry I did not reply to your message in the thread,
but and I didn't see it until a few days ago :-()

Best regards,

Juan Manuel

---------------------
https://juanmanuelmacias.com


[-- Attachment #2: 0001-ox.el-add-smart-quotes-for-greek.patch --]
[-- Type: text/x-patch, Size: 1843 bytes --]

From 3deb65be3d59e2ae35bd6dc9bb38b138dee926f8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sun, 19 Sep 2021 17:58:51 +0200
Subject: [PATCH] ox.el: add smart quotes for greek

* lisp/ox.el (org-export-smart-quotes-alist): The correct quotes for Greek have been established with the help of Protesilaos Stavrou
---
 lisp/ox.el | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 5fe894569..a8014d401 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -524,7 +524,7 @@ e.g. \"H:2\"."
   "The default language for export and clocktable translations, as a string.
 This may have an association in
 `org-clock-clocktable-language-setup',
-`org-export-smart-quotes-alist' and `org-export-dictionary'.
+`org-export-smart-quotes-' and `org-export-dictionary'.
 This option can also be set with the LANGUAGE keyword."
   :group 'org-export-general
   :type '(string :tag "Language")
@@ -5437,6 +5437,16 @@ transcoding it."
      (secondary-closing
       :utf-8 "‘" :html "&lsquo;" :latex "\\grq{}" :texinfo "@quoteleft{}")
      (apostrophe :utf-8 "’" :html "&rsquo;"))
+    ("el"
+     (primary-opening
+      :utf-8 "«" :html "&laquo;" :latex "\\guillemotleft{}"
+      :texinfo "@guillemetleft{}")
+     (primary-closing
+      :utf-8 "»" :html "&raquo;" :latex "\\guillemotright{}"
+      :texinfo "@guillemetright{}")
+     (secondary-opening :utf-8 "“" :html "&ldquo;" :latex "``" :texinfo "``")
+     (secondary-closing :utf-8 "”" :html "&rdquo;" :latex "''" :texinfo "''")
+     (apostrophe :utf-8 "’" :html "&rsquo;"))
     ("en"
      (primary-opening :utf-8 "“" :html "&ldquo;" :latex "``" :texinfo "``")
      (primary-closing :utf-8 "”" :html "&rdquo;" :latex "''" :texinfo "''")
-- 
2.32.0


^ permalink raw reply related	[relevance 9%]

* Re: Overlining troubles
  @ 2021-09-18 17:51  0%     ` Ypo
  0 siblings, 0 replies; 200+ results
From: Ypo @ 2021-09-18 17:51 UTC (permalink / raw)
  To: Timothy; +Cc: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 3793 bytes --]

Hi!

I use orgmode to read and study directly but I am not able to set up 
LaTeX preview. So I need something "direct", but I can't renounce to 
exporting it.


So that you have an idea of what I'm dealing with, I am able to set up 
LaTeX exporting on my home computer, but I can't make it work at my work 
computer. LaTeX preview is almost a dream to me.

Best regards

El 18/09/2021 a las 19:32, Timothy escribió:
>
> Hi Ypo,
>
> If you’re thinking of maths, why not just write inline LaTeX, e.g. 
> \(\bar{x}\) ?
>
> All the best,
> *Timothy*
>
> *From*: Ypo <mailto:"Ypo" <ypuntot@gmail.com>>
> *Subject*: Re: Overlining troubles
> *To*: emacs-orgmode@gnu.org <mailto:"emacs-orgmode@gnu.org" 
> <emacs-orgmode@gnu.org>>
> *Date*: Sun, 19 Sep 2021 01:14:52 +0800
>
> Thanks, Timothy and Max. I'll try to explain myself better.
>
> Overlining is quite useful in math expressions, for example I needed 
> it to represent the arithmetic mean.
>
> I need to be able to overline text and to export it overlined. The 
> only dirty solution I found was to change the =verbatim= mark, but now 
> I can't use verbatim on orgmode, and the overlined text isn't 
> exported, so unsustainable "solution".
>
> The perfect solution? To be able to add a new marker to overline text 
> that can be exported overlined.
>
> Best regards
>
> :-)
>
> El 18/09/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
>> Message: 7 Date: Sat, 18 Sep 2021 20:48:36 +0800 From: Timothy 
>> <tecosaur@gmail.com> To: Ypo <ypuntot@gmail.com> Cc: 
>> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID: 
>> <87ee9mdp5i.fsf@gmail.com> Content-Type: text/plain; charset="utf-8" 
>> Hi Ypo, You’ll likely want to override `org-html-verbatim' and 
>> `org-latex-verbatim' to produce overlines in exports. All the best, 
>> Timothy -------------- next part -------------- An HTML attachment 
>> was scrubbed... URL: 
>> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20210918/78086bf1/attachment.html> 
>> ------------------------------ Message: 8 Date: Sat, 18 Sep 2021 
>> 19:50:31 +0700 From: Max Nikulin <manikulin@gmail.com> To: 
>> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID: 
>> <si4naq$47d$1@ciao.gmane.io> Content-Type: text/plain; charset=utf-8; 
>> format=flowed On 18/09/2021 15:14, Ypo wrote:
>>> I have tried many times in different ways to "overline" text. I am able
>>> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve
>>> it), but it doesn't export overlined (nor HTML, nor LaTeX).
>>>
>>> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
>>>
>>> Is it possible to add overlining and to export it?
>> Just to avoid confusion, `org-emphasis-alist' is not designed to change
>> or to*add*  new markers:
>>
>> https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/  (Nicolas
>> Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the
>> inline code delimeter?)
>>
>> If you wish to export =verbatim= text as text with line above, perhaps,
>> you can define custom "verbatim" export filter
>> "info (org) Advanced Export Configuration"
>> https://orgmode.org/manual/Advanced-Export-Configuration.html
>>
>> A macro expanded with markup for particular backend (e.g. @@latex:
>> ...@@) may be a better option
>> "info (org) Macro Replacement"
>> https://orgmode.org/manual/Macro-Replacement.html
>>
>> Some people experimenting with custom link types with associated
>> handlers for particular export backends:
>> https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/  (Juan Manuel Macías,
>> Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).
>>
>> Unfortunately you described what you have tried in too general words to
>> suggest something more specific.
>>
>>

[-- Attachment #2: Type: text/html, Size: 9516 bytes --]

^ permalink raw reply	[relevance 0%]

* Re: Overlining troubles
       [not found]     <mailman.33.1631980810.21752.emacs-orgmode@gnu.org>
@ 2021-09-18 17:14  0% ` Ypo
    0 siblings, 1 reply; 200+ results
From: Ypo @ 2021-09-18 17:14 UTC (permalink / raw)
  To: emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 2945 bytes --]

Thanks, Timothy and Max. I'll try to explain myself better.

Overlining is quite useful in math expressions, for example I needed it 
to represent the arithmetic mean.

I need to be able to overline text and to export it overlined. The only 
dirty solution I found was to change the =verbatim= mark, but now I 
can't use verbatim on orgmode, and the overlined text isn't exported, so 
unsustainable "solution".

The perfect solution? To be able to add a new marker to overline text 
that can be exported overlined.

Best regards

:-)

El 18/09/2021 a las 18:00, emacs-orgmode-request@gnu.org escribió:
> Message: 7 Date: Sat, 18 Sep 2021 20:48:36 +0800 From: Timothy 
> <tecosaur@gmail.com> To: Ypo <ypuntot@gmail.com> Cc: 
> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID: 
> <87ee9mdp5i.fsf@gmail.com> Content-Type: text/plain; charset="utf-8" 
> Hi Ypo, You’ll likely want to override `org-html-verbatim' and 
> `org-latex-verbatim' to produce overlines in exports. All the best, 
> Timothy -------------- next part -------------- An HTML attachment was 
> scrubbed... URL: 
> <https://lists.gnu.org/archive/html/emacs-orgmode/attachments/20210918/78086bf1/attachment.html> 
> ------------------------------ Message: 8 Date: Sat, 18 Sep 2021 
> 19:50:31 +0700 From: Max Nikulin <manikulin@gmail.com> To: 
> emacs-orgmode@gnu.org Subject: Re: Overlining troubles Message-ID: 
> <si4naq$47d$1@ciao.gmane.io> Content-Type: text/plain; charset=utf-8; 
> format=flowed On 18/09/2021 15:14, Ypo wrote:
>> I have tried many times in different ways to "overline" text. I am able
>> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve
>> it), but it doesn't export overlined (nor HTML, nor LaTeX).
>>
>> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
>>
>> Is it possible to add overlining and to export it?
> Just to avoid confusion, `org-emphasis-alist' is not designed to change
> or to*add*  new markers:
>
> https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/  (Nicolas
> Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the
> inline code delimeter?)
>
> If you wish to export =verbatim= text as text with line above, perhaps,
> you can define custom "verbatim" export filter
> "info (org) Advanced Export Configuration"
> https://orgmode.org/manual/Advanced-Export-Configuration.html
>
> A macro expanded with markup for particular backend (e.g. @@latex:
> ...@@) may be a better option
> "info (org) Macro Replacement"
> https://orgmode.org/manual/Macro-Replacement.html
>
> Some people experimenting with custom link types with associated
> handlers for particular export backends:
> https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/  (Juan Manuel Macías,
> Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).
>
> Unfortunately you described what you have tried in too general words to
> suggest something more specific.
>
>

[-- Attachment #2: Type: text/html, Size: 5077 bytes --]

^ permalink raw reply	[relevance 0%]

* Re: Overlining troubles
  @ 2021-09-18 12:50  5% ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2021-09-18 12:50 UTC (permalink / raw)
  To: emacs-orgmode

On 18/09/2021 15:14, Ypo wrote:
> 
> I have tried many times in different ways to "overline" text. I am able 
> to overline it on orgmode (I sacrificed the =verbatim= marker to achieve 
> it), but it doesn't export overlined (nor HTML, nor LaTeX).
> 
> I tried in the past to add it to "Org Emphasis Alist" but it didn't work.
> 
> Is it possible to add overlining and to export it?

Just to avoid confusion, `org-emphasis-alist' is not designed to change 
or to *add* new markers:

https://orgmode.org/list/87blatodir.fsf@nicolasgoaziou.fr/ (Nicolas 
Goaziou, Mon, 05 Apr 2021 01:06:52 +0200, Re: Using backticks for the 
inline code delimeter?)

If you wish to export =verbatim= text as text with line above, perhaps, 
you can define custom "verbatim" export filter
"info (org) Advanced Export Configuration"
https://orgmode.org/manual/Advanced-Export-Configuration.html

A macro expanded with markup for particular backend (e.g. @@latex: 
...@@) may be a better option
"info (org) Macro Replacement"
https://orgmode.org/manual/Macro-Replacement.html

Some people experimenting with custom link types with associated 
handlers for particular export backends:
https://orgmode.org/list/87mtq9zatr.fsf@posteo.net/ (Juan Manuel Macías, 
Mon, 26 Jul 2021 09:25:04 +0000, Multilingual quotes inside paragraphs).

Unfortunately you described what you have tried in too general words to 
suggest something more specific.



^ permalink raw reply	[relevance 5%]

* Re: Support for tabularray in LaTeX export
  2021-09-02  8:36  8% ` Juan Manuel Macías
@ 2021-09-02 10:08  7%   ` Vikas Rawal
    0 siblings, 1 reply; 200+ results
From: Vikas Rawal @ 2021-09-02 10:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

[-- Attachment #1: Type: text/plain, Size: 3992 bytes --]

This is perfect. Thank you, Juan Manuel.

Vikas

On Thu, 2 Sept 2021 at 14:06, Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Hi Vikas,
>
> You can define a modified version of `org-latex--org-table',
> adding a new LaTeX attribute `:options'. Something like this:
>
> #+begin_src emacs-lisp
> (defun my/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))
>          (opt (org-export-read-attribute :attr_latex table :options))
>          (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
>                             (if opt opt "")
>                             width
>                             alignment
>                             contents
>                             table-env)))
>         (org-latex--decorate-table output attr caption above? info))))))
>
> (advice-add 'org-latex--org-table :override #'my/org-latex--org-table)
> #+end_src
>
> and then:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align <align-options>
> #+ATTR_LATEX: :booktabs t
> #+ATTR_LaTeX: :options [<options>]
>
> Best regards,
>
> Juan Manuel
>
> Vikas Rawal writes:
>
> > tabularray (CTAN: Package tabularray) provides longtblr environment
> > that is called as
> >
> > ---
> > \begin{longtblr}[various-table-options]{column and row specifications}
> >
> > \end{longtblr}
> > ---
> >
> > Adding something like the following to orgmode tables makes them
> > export nicely as longtblr
> >
> > ---
> > #+ATTR_LATEX: :environment longtblr
> > #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> > [r,bg=gray9]}
> > #+ATTR_LATEX: :booktabs t
> > ---
> >
> > Everything seems to work very well with orgmode except that I cannot
> > figure out how to pass [various table options] from orgmode. These
> > table options include, most importantly, table notes.
> >
> > I normally use threeparttable for table notes, but longtblr does not
> > seem to work with threeparttable and has its own syntax for table
> > notes.
> >
> > Any advice on how to pass [table-options] to longtblr environment?
> >
> > Vikas
> >
>

[-- Attachment #2: Type: text/html, Size: 5197 bytes --]

^ permalink raw reply	[relevance 7%]

* Re: Support for tabularray in LaTeX export
  @ 2021-09-02  8:36  8% ` Juan Manuel Macías
  2021-09-02 10:08  7%   ` Vikas Rawal
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-09-02  8:36 UTC (permalink / raw)
  To: Vikas Rawal; +Cc: orgmode

Hi Vikas,

You can define a modified version of `org-latex--org-table',
adding a new LaTeX attribute `:options'. Something like this:

#+begin_src emacs-lisp
(defun my/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))
         (opt (org-export-read-attribute :attr_latex table :options))
         (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
                            (if opt opt "")
                            width
                            alignment
                            contents
                            table-env)))
        (org-latex--decorate-table output attr caption above? info))))))

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

and then:

#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align <align-options>
#+ATTR_LATEX: :booktabs t
#+ATTR_LaTeX: :options [<options>]

Best regards,

Juan Manuel

Vikas Rawal writes:

> tabularray (CTAN: Package tabularray) provides longtblr environment
> that is called as
>
> ---
> \begin{longtblr}[various-table-options]{column and row specifications}
>
> \end{longtblr}
> ---
>
> Adding something like the following to orgmode tables makes them
> export nicely as longtblr
>
> ---
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> [r,bg=gray9]}
> #+ATTR_LATEX: :booktabs t
> ---
>
> Everything seems to work very well with orgmode except that I cannot
> figure out how to pass [various table options] from orgmode. These
> table options include, most importantly, table notes.
>
> I normally use threeparttable for table notes, but longtblr does not
> seem to work with threeparttable and has its own syntax for table
> notes.
>
> Any advice on how to pass [table-options] to longtblr environment?
>
> Vikas
>


^ permalink raw reply	[relevance 8%]

* Re: Smart quotes for Greek (questions for a possible patch)
  2021-08-27 16:23  3%   ` Protesilaos Stavrou
@ 2021-08-31 11:11  9%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-31 11:11 UTC (permalink / raw)
  To: Protesilaos Stavrou, mvar; +Cc: orgmode

Hello Protesilaos and Michalis,

Thank you very much, Protesilaos, for the valuable information. It can
be confirmed, then, that the quotation marks rules for current Greek are
identical to the rules for Spanish, so it will be enough to copy the
existing configuration for Spanish in `org-export-smart-quotes-alist'.

It seems that the character U+201F as the first second level quotes
(instead of U+201C), which Yannis Haralambous comments in the article
cited in my first message, although historically attested, has been
abandoned...

Soon I will propose here a patch to support small quotes to
Greek.

Best regards,

Juan Manuel

Protesilaos Stavrou writes:

> Hello Michalis, Juan Manuel,
>
> [ I had no access to a computer and could not get to you sooner.  Expect
>   timely replies from now on. ]
>
> The first level quotes are indeed «».  For the other two, I have to rely
> on what I have encountered before, namely, that the second level is
> denoted with double curly quotes “” and third with single curly quotes
> ‘’.
>
> I have come across those in EU documents.  There is a style guide for
> the European Institutions.[1][2][3]
>
> I do not know latex notation to help you with the technicalities.
> Here are the unicode points:
>
>     | « | U+00AB |
>     | » | U+00BB |
>     | “ | U+201C |
>     | ” | U+201D |
>     | ‘ | U+2018 |
>     | ’ | U+2019 |
>
> All the best,
> Protesilaos
>
> [1] Quotes: <http://publications.europa.eu/code/el/el-4100107el.htm>.
> [2] General info: <http://publications.europa.eu/code/el/el-4100000.htm>.
> [3] Main portal: <http://publications.europa.eu/code/el/el-000100.htm>.



^ permalink raw reply	[relevance 9%]

* Re: Smart quotes for Greek (questions for a possible patch)
  2021-08-15 21:28  6% ` mvar
  2021-08-16 13:57  8%   ` Juan Manuel Macías
@ 2021-08-27 16:23  3%   ` Protesilaos Stavrou
  2021-08-31 11:11  9%     ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Protesilaos Stavrou @ 2021-08-27 16:23 UTC (permalink / raw)
  To: mvar, Juan Manuel Macías; +Cc: orgmode

On 2021-08-16, 00:28 +0300, mvar <mvar.40k@gmail.com> wrote:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Hi,
>>
>> I would like to submit a patch to add smart quotes for Greek in
>> `org-export-smart-quotes-alist', but I have a couple of questions.
>>
>> First of all, I am not a native speaker of Greek but of Spanish, so I
>> would also like to have the opinion of some Greek native speaker, to see
>> if my solutions are correct.
>>
>> The second question concerns the second-level quotation marks for Greek.
>> The first level ones are the same as the Spanish or French quotes
>> (without the extra space of French): «», so no problem. I follow here
>> the rule that Yannis Haralambous explains in "From Unicode to
>> Typography, a Case Study: the Greek Script" (1999, p. 20:
>> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
>>
>> According to Haralambous, on the second-level quotation marks (the
>> emphases are mine):
>>
>> #+begin_quote
>>
>> Also interesting is the case of the second level quotes. Here, quotes of
>> the size and shape of the English ones are used, but the opening quotes
>> are inverted, similar in form to raised small round guillemets [...].
>> Fortunately these quotes are provided by the Unicode standard (*U+201F*
>> and U+201D, the latter being the same closing double quotes as in
>> English); *the author knows no other language in which this combination
>> of double quotes might be used*.
>>
>> #+end_quote
>>
>>
>> So the problem is in the character U+201F (assuming Haralambous is
>> right). For the keywords `:utf8' and `html' no problem. But I don't know
>> what to put in `:latex' or in `:texinfo':
>>
>> #+begin_src emacs-lisp
>> (secondary-opening :utf-8 "‟" :html "&#8223;;" :latex "??" :texinfo "??")
>> #+end_src
>>
>> In fact, I think latex2e has no command or shorthand predefined for this
>> character (see https://ibb.co/ZBGmwYP). There would be no problem with
>> LuaTeX and XeTeX. But this character would be difficult to obtain in
>> pdfTeX even using inputenc with the utf8 option.
>>
>> Best regards,
>>
>> Juan Manuel
>
> hi Juan,
>
> i can confirm the «» characters are the proper ones for the first level
> of quoting..Now about second level, personally i haven't seen such nesting in
> ages but IIRC they should be the ones (or *very* similar) in the linked image you posted ->
> \textquotedblleft and \textquotedblright. I've no idea how these
> translate to UTF. Note that the standard greek keyboards & keymaps do not have
> any of these characters mapped by default (not even «» ), most people use the standard
> english double/single quotes, at least in electronic writing (articles,
> daily communication etc).
> Protesilaos (cc) might have a better view on this matter.
>
> cheers,
> Michalis

Hello Michalis, Juan Manuel,

[ I had no access to a computer and could not get to you sooner.  Expect
  timely replies from now on. ]

The first level quotes are indeed «».  For the other two, I have to rely
on what I have encountered before, namely, that the second level is
denoted with double curly quotes “” and third with single curly quotes
‘’.

I have come across those in EU documents.  There is a style guide for
the European Institutions.[1][2][3]

I do not know latex notation to help you with the technicalities.
Here are the unicode points:

    | « | U+00AB |
    | » | U+00BB |
    | “ | U+201C |
    | ” | U+201D |
    | ‘ | U+2018 |
    | ’ | U+2019 |

All the best,
Protesilaos

[1] Quotes: <http://publications.europa.eu/code/el/el-4100107el.htm>.
[2] General info: <http://publications.europa.eu/code/el/el-4100000.htm>.
[3] Main portal: <http://publications.europa.eu/code/el/el-000100.htm>.


-- 
Protesilaos Stavrou
https://protesilaos.com

^ permalink raw reply	[relevance 3%]

* Re: pygments support
  @ 2021-08-27 13:49 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-27 13:49 UTC (permalink / raw)
  To: Yuchen Pei; +Cc: orgmode

Hi Yuchen,

I only know this one, but haven't tried it:

https://github.com/or/pygments-orgmode-lexer

Best regards,

Juan Manuel

Yuchen Pei writes:

> Hello,
>
> I was playing with my cgit setup when I noticed that pygments does not
> support org mode syntax highlighting[1].
>
> Just wondering if anyone has worked on it, or if there's any
> "unofficial" org mode component (lexer?), before I go ahead and 
> try to write my own.
>
> [1]: https://pygments.org/languages/



^ permalink raw reply	[relevance 10%]

* Re: how to get multi-line author in ODT export?
  2021-08-26 18:34  6%       ` John Kitchin
@ 2021-08-27  1:46 10%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-27  1:46 UTC (permalink / raw)
  To: John Kitchin; +Cc: orgmode, Eric S Fraga

Hi John,

you're welcome. I realized that in these lines of the meta.xml file:

<dc:creator> ... </dc:creator>
<meta:initial-creator> ... </meta:initial-creator>

line breaks can be achieved simply by adding a new line without marks (as
discussed in this thread:
https://stackoverflow.com/questions/10917555/adding-a-new-line-break-tag-in-xml/10923392)

Best regards,

Juan Manuel

John Kitchin writes:

> That is really nice, thanks for sharing it!
> John
>
> -----------------------------------
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
> On Thu, Aug 26, 2021 at 12:55 PM Juan Manuel Macías
> <maciaschain@posteo.net> wrote:
>
>     Hi again,
>
>     Another simpler approach, with a filter:
>
>     #+TITLE: The kessel run in 12 parsecs
>     #+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
>
>     #+BIND: org-export-filter-plain-text-functions (author-lb-filter)
>     #+begin_src emacs-lisp :exports results :results none
>       (defun author-lb-filter (text backend info)
>         (cond ((org-export-derived-backend-p backend 'odt)
>                (replace-regexp-in-string "!!!" "\n" text))
>               ((org-export-derived-backend-p backend 'latex)
>                (replace-regexp-in-string "!!!" "\\\\\\\\" text))))
>     #+end_src
>
>     Content...
>
>     Best regards,
>
>     Juan Manuel
>
>     Juan Manuel Macías writes:
>
>     > Hi Eric,
>     >
>     > I think the problem is in this two lines of `org-odt-template',
>     that
>     > creates the meta.xml file inside the odt file:
>     >
>     > (format "<dc:creator>%s</dc:creator>\n" author)
>     > (format "<meta:initial-creator>%s</meta:initial-creator>\n"
>     author)
>     >
>     > Perhaps, modifying them like this:
>     >
>     > (format "<dc:creator><![CDATA[%s]]></dc:creator>\n"
>     (replace-regexp-in-string "\\\\\\\\" "\n" author))
>     > (format "<meta:initial-creator><![CDATA
>     [%s]]></meta:initial-creator>\n" (replace-regexp-in-string
>     "\\\\\\\\" "\n" author))
>     >
>     > We could do this in our documents:
>     >
>     > #+AUTHOR: Han Solo \\ Chewbacca
>     >
>     > (little tested)
>     >
>     > Best regards,
>     >
>     > Juan Manuel
>     >
>     > Eric S Fraga writes:
>     >
>     >> So, as usual, I answer my own question, sort of.
>     >>
>     >> The problem is that org exports the author text enclosed within
>     a
>     >> special directives, specifically:
>     >>
>     >>  (format "<text:initial-creator>%s</text:initial-creator>"
>     author))
>     >>
>     >> New line directives are not allowed within this declaration, it
>     >> seems.  Removing (manually) the initial-creator directive then
>     works.
>     >>
>     >> So, my question would be: is this text:initial-creator tagging
>     >> necessary?  If not, can we remove it?  The OpenDocument schema
>     is vague
>     >> about whether this is necessary.  If we cannot remove it, i.e
>     if
>     >> initial-creator is required in the document, could it be put in
>     >> separately (as a meta:initial-creator tag) so that the author
>     field can
>     >> be more general?
>     >>
>     >> I am *not* an ODT expert of any sort.  But it is my route to
>     Word
>     >> documents when the need arises (which is luckily seldom).
>     >>
>     >> Anyway, no panic: I can simply manually edit the odt file just
>     before
>     >> the final processing...
>     >>
>     >> Thank you,
>     >> eric
>     >
>     >
>


^ permalink raw reply	[relevance 10%]

* Re: how to get multi-line author in ODT export?
  2021-08-26 16:54 13%     ` Juan Manuel Macías
@ 2021-08-26 18:34  6%       ` John Kitchin
  2021-08-27  1:46 10%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: John Kitchin @ 2021-08-26 18:34 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Eric S Fraga

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

That is really nice, thanks for sharing it!
John

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



On Thu, Aug 26, 2021 at 12:55 PM Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Hi again,
>
> Another simpler approach, with a filter:
>
> #+TITLE: The kessel run in 12 parsecs
> #+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian
>
> #+BIND: org-export-filter-plain-text-functions (author-lb-filter)
> #+begin_src emacs-lisp :exports results :results none
>   (defun author-lb-filter (text backend info)
>     (cond ((org-export-derived-backend-p backend 'odt)
>            (replace-regexp-in-string "!!!" "\n" text))
>           ((org-export-derived-backend-p backend 'latex)
>            (replace-regexp-in-string "!!!" "\\\\\\\\" text))))
> #+end_src
>
> Content...
>
> Best regards,
>
> Juan Manuel
>
> Juan Manuel Macías writes:
>
> > Hi Eric,
> >
> > I think the problem is in this two lines of `org-odt-template', that
> > creates the meta.xml file inside the odt file:
> >
> > (format "<dc:creator>%s</dc:creator>\n" author)
> > (format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
> >
> > Perhaps, modifying them like this:
> >
> > (format "<dc:creator><![CDATA[%s]]></dc:creator>\n"
> (replace-regexp-in-string "\\\\\\\\" "\n" author))
> > (format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n"
> (replace-regexp-in-string "\\\\\\\\" "\n" author))
> >
> > We could do this in our documents:
> >
> > #+AUTHOR: Han Solo \\ Chewbacca
> >
> > (little tested)
> >
> > Best regards,
> >
> > Juan Manuel
> >
> > Eric S Fraga writes:
> >
> >> So, as usual, I answer my own question, sort of.
> >>
> >> The problem is that org exports the author text enclosed within a
> >> special directives, specifically:
> >>
> >>  (format "<text:initial-creator>%s</text:initial-creator>" author))
> >>
> >> New line directives are not allowed within this declaration, it
> >> seems.  Removing (manually) the initial-creator directive then works.
> >>
> >> So, my question would be: is this text:initial-creator tagging
> >> necessary?  If not, can we remove it?  The OpenDocument schema is vague
> >> about whether this is necessary.  If we cannot remove it, i.e if
> >> initial-creator is required in the document, could it be put in
> >> separately (as a meta:initial-creator tag) so that the author field can
> >> be more general?
> >>
> >> I am *not* an ODT expert of any sort.  But it is my route to Word
> >> documents when the need arises (which is luckily seldom).
> >>
> >> Anyway, no panic: I can simply manually edit the odt file just before
> >> the final processing...
> >>
> >> Thank you,
> >> eric
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4111 bytes --]

^ permalink raw reply	[relevance 6%]

* Re: how to get multi-line author in ODT export?
  2021-08-26 16:05 10%   ` Juan Manuel Macías
@ 2021-08-26 16:54 13%     ` Juan Manuel Macías
  2021-08-26 18:34  6%       ` John Kitchin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-26 16:54 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Hi again,

Another simpler approach, with a filter:

#+TITLE: The kessel run in 12 parsecs
#+AUTHOR: Han Solo !!! Chewbacca !!! Lando Calrissian

#+BIND: org-export-filter-plain-text-functions (author-lb-filter)
#+begin_src emacs-lisp :exports results :results none
  (defun author-lb-filter (text backend info)
    (cond ((org-export-derived-backend-p backend 'odt)
           (replace-regexp-in-string "!!!" "\n" text))
          ((org-export-derived-backend-p backend 'latex)
           (replace-regexp-in-string "!!!" "\\\\\\\\" text))))
#+end_src

Content...

Best regards,

Juan Manuel

Juan Manuel Macías writes:

> Hi Eric,
>
> I think the problem is in this two lines of `org-odt-template', that
> creates the meta.xml file inside the odt file:
>
> (format "<dc:creator>%s</dc:creator>\n" author)
> (format "<meta:initial-creator>%s</meta:initial-creator>\n" author)
>
> Perhaps, modifying them like this:
>
> (format "<dc:creator><![CDATA[%s]]></dc:creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
> (format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
>
> We could do this in our documents:
>
> #+AUTHOR: Han Solo \\ Chewbacca
>
> (little tested)
>
> Best regards,
>
> Juan Manuel
>
> Eric S Fraga writes:
>
>> So, as usual, I answer my own question, sort of.
>>
>> The problem is that org exports the author text enclosed within a
>> special directives, specifically:
>>
>>  (format "<text:initial-creator>%s</text:initial-creator>" author))
>>
>> New line directives are not allowed within this declaration, it
>> seems.  Removing (manually) the initial-creator directive then works.
>>
>> So, my question would be: is this text:initial-creator tagging
>> necessary?  If not, can we remove it?  The OpenDocument schema is vague
>> about whether this is necessary.  If we cannot remove it, i.e if
>> initial-creator is required in the document, could it be put in
>> separately (as a meta:initial-creator tag) so that the author field can
>> be more general?
>>
>> I am *not* an ODT expert of any sort.  But it is my route to Word
>> documents when the need arises (which is luckily seldom).
>>
>> Anyway, no panic: I can simply manually edit the odt file just before
>> the final processing...
>>
>> Thank you,
>> eric
>
>


^ permalink raw reply	[relevance 13%]

* Re: how to get multi-line author in ODT export?
  @ 2021-08-26 16:05 10%   ` Juan Manuel Macías
  2021-08-26 16:54 13%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-26 16:05 UTC (permalink / raw)
  To: Eric S Fraga; +Cc: orgmode

Hi Eric,

I think the problem is in this two lines of `org-odt-template', that
creates the meta.xml file inside the odt file:

(format "<dc:creator>%s</dc:creator>\n" author)
(format "<meta:initial-creator>%s</meta:initial-creator>\n" author)

Perhaps, modifying them like this:

(format "<dc:creator><![CDATA[%s]]></dc:creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))
(format "<meta:initial-creator><![CDATA[%s]]></meta:initial-creator>\n" (replace-regexp-in-string "\\\\\\\\" "\n" author))

We could do this in our documents:

#+AUTHOR: Han Solo \\ Chewbacca

(little tested)

Best regards,

Juan Manuel 

Eric S Fraga writes:

> So, as usual, I answer my own question, sort of.
>
> The problem is that org exports the author text enclosed within a
> special directives, specifically:
>
>  (format "<text:initial-creator>%s</text:initial-creator>" author))
>  
> New line directives are not allowed within this declaration, it
> seems.  Removing (manually) the initial-creator directive then works.
>
> So, my question would be: is this text:initial-creator tagging
> necessary?  If not, can we remove it?  The OpenDocument schema is vague
> about whether this is necessary.  If we cannot remove it, i.e if
> initial-creator is required in the document, could it be put in
> separately (as a meta:initial-creator tag) so that the author field can
> be more general?
>
> I am *not* an ODT expert of any sort.  But it is my route to Word
> documents when the need arises (which is luckily seldom).
>
> Anyway, no panic: I can simply manually edit the odt file just before
> the final processing...
>
> Thank you,
> eric



^ permalink raw reply	[relevance 10%]

* Re: Smart quotes for Greek (questions for a possible patch)
  2021-08-14 15:06  7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
  2021-08-15 15:59  5% ` Maxim Nikulin
@ 2021-08-15 21:28  6% ` mvar
  2021-08-16 13:57  8%   ` Juan Manuel Macías
  2021-08-27 16:23  3%   ` Protesilaos Stavrou
  1 sibling, 2 replies; 200+ results
From: mvar @ 2021-08-15 21:28 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: public, orgmode

Juan Manuel Macías <maciaschain@posteo.net> writes:

> Hi,
>
> I would like to submit a patch to add smart quotes for Greek in
> `org-export-smart-quotes-alist', but I have a couple of questions.
>
> First of all, I am not a native speaker of Greek but of Spanish, so I
> would also like to have the opinion of some Greek native speaker, to see
> if my solutions are correct.
>
> The second question concerns the second-level quotation marks for Greek.
> The first level ones are the same as the Spanish or French quotes
> (without the extra space of French): «», so no problem. I follow here
> the rule that Yannis Haralambous explains in "From Unicode to
> Typography, a Case Study: the Greek Script" (1999, p. 20:
> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
>
> According to Haralambous, on the second-level quotation marks (the
> emphases are mine):
>
> #+begin_quote
>
> Also interesting is the case of the second level quotes. Here, quotes of
> the size and shape of the English ones are used, but the opening quotes
> are inverted, similar in form to raised small round guillemets [...].
> Fortunately these quotes are provided by the Unicode standard (*U+201F*
> and U+201D, the latter being the same closing double quotes as in
> English); *the author knows no other language in which this combination
> of double quotes might be used*.
>
> #+end_quote
>
>
> So the problem is in the character U+201F (assuming Haralambous is
> right). For the keywords `:utf8' and `html' no problem. But I don't know
> what to put in `:latex' or in `:texinfo':
>
> #+begin_src emacs-lisp
> (secondary-opening :utf-8 "‟" :html "&#8223;;" :latex "??" :texinfo "??")
> #+end_src
>
> In fact, I think latex2e has no command or shorthand predefined for this
> character (see https://ibb.co/ZBGmwYP). There would be no problem with
> LuaTeX and XeTeX. But this character would be difficult to obtain in
> pdfTeX even using inputenc with the utf8 option.
>
> Best regards,
>
> Juan Manuel

hi Juan,

i can confirm the «» characters are the proper ones for the first level
of quoting..Now about second level, personally i haven't seen such nesting in
ages but IIRC they should be the ones (or *very* similar) in the linked image you posted ->
\textquotedblleft and \textquotedblright. I've no idea how these
translate to UTF. Note that the standard greek keyboards & keymaps do not have
any of these characters mapped by default (not even «» ), most people use the standard
english double/single quotes, at least in electronic writing (articles,
daily communication etc).
Protesilaos (cc) might have a better view on this matter.

cheers,
Michalis


^ permalink raw reply	[relevance 6%]

* Search in descriptive plain lists
@ 2021-08-19 11:04  8% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-19 11:04 UTC (permalink / raw)
  To: orgmode

Hi all,

For my translation (work in progress) of Homer's Odyssey I am writing a long descriptive
plain list which is a glossary of Homeric formulas (in Homer a 'formula' is a passage that
is repeated exactly the same, or with slight variations, throughout the work: a very
typical resource of traditional poems). This glossary helps me remember how I have
translated a certain formula before. But it was a bit awkward for me having to query the
list every time so I wrote a function which returns as a message the item searched after
writing or marking a few words. I have redone a bit the code to give it a more general
use, and I share it here, in case someone found useful or perhaps would like to improve
it. The idea is to search in descriptive lists within sections containing the tag :makealist:
(one list per section). And has more sense when the descriptive lists work as a kind of
glossary.

#+begin_src emacs-lisp
  (setq my-org/desc-plainlist-alist nil)
  
  (defun my-org/search-desc-plainlist ()
    (interactive)
    (org-map-entries
     (lambda ()
       (save-restriction
	 (org-narrow-to-subtree)
	 (when
	     (re-search-forward "^- " nil t)
	   (beginning-of-line)
	   (mapc (lambda (el)
		   (add-to-list 'my-org/desc-plainlist-alist el))
		 (cdr (org-list-to-lisp))))))
     "makealist")
    (let ((element-re (if (region-active-p)
			  (buffer-substring-no-properties (region-beginning) (region-end))
			(read-from-minibuffer "Search in descriptive lists: "))))
      (setq my-org/desc-plainlist-candidate
	    (assoc-if
	     (lambda (x)
	       (string-match-p element-re x))
	     my-org/desc-plainlist-alist))
      (message
       (mapconcat 'identity
		  my-org/desc-plainlist-candidate ""))))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Smart quotes for Greek (questions for a possible patch)
  2021-08-15 21:28  6% ` mvar
@ 2021-08-16 13:57  8%   ` Juan Manuel Macías
  2021-08-27 16:23  3%   ` Protesilaos Stavrou
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-16 13:57 UTC (permalink / raw)
  To: mvar; +Cc: public, orgmode

Hi Michalis. Thank you for your comments.

mvar writes:

> i can confirm the «» characters are the proper ones for the first level
> of quoting..Now about second level, personally i haven't seen such nesting in
> ages but IIRC they should be the ones (or *very* similar) in the linked image you posted ->
> \textquotedblleft and \textquotedblright. I've no idea how these
> translate to UTF. Note that the standard greek keyboards & keymaps do not have
> any of these characters mapped by default (not even «» ), most people use the standard
> english double/single quotes, at least in electronic writing (articles,
> daily communication etc).
> Protesilaos (cc) might have a better view on this matter.

Yes, I think \textquotedblleft and \textquotedblright could be a good
solution. Those are the first level quotes for English and other
languages, and the second level quotes for Spanish, so in this case the
Spanish settings in `org-export-smart-quotes-alist' could be copied for
Greek. In Unicode they are equivalent to

“ LEFT DOUBLE QUOTATION MARK U+201C 

and

” RIGHT DOUBLE QUOTATION MARK U+201D 

In fact, the second quotes, U+201D, would be the correct ones for Greek
(always, according to Haralambous). The only difference is for the
opening quotes: in this case Greek would use (again, according to
Haralambous) the character U+201F: ‟ (DOUBLE HIGH-REVERSED-9 QUOTATION
MARK), which is like the U+201C char, but upside down. In LuaTeX and
XeTeX (and in HTML) there is no problem to represent that character,
because these two TeX engines are based on Unicode. The problem would be
the backward compatibility with pdfTeX. I haven't managed to get this
character in pdfTeX using inputenc with the utf8 option.

Therefore, we could leave for the second-level quotation marks the
tandem U+201C/201D, as the lesser evil. Let's see what Protesilaos
thinks.

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 8%]

* Re: Smart quotes for Greek (questions for a possible patch)
  2021-08-14 15:06  7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
@ 2021-08-15 15:59  5% ` Maxim Nikulin
  2021-08-15 21:28  6% ` mvar
  1 sibling, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-08-15 15:59 UTC (permalink / raw)
  To: emacs-orgmode

On 14/08/2021 22:06, Juan Manuel Macías wrote:
> 
> I would like to submit a patch to add smart quotes for Greek in
> `org-export-smart-quotes-alist', but I have a couple of questions.
> 
> First of all, I am not a native speaker of Greek

Disclaimer: I am not a Greek speaker at all.

> Yannis Haralambous explains in "From Unicode to
> Typography, a Case Study: the Greek Script" (1999, p. 20:
> http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).
> 
> Fortunately these quotes are provided by the Unicode standard (*U+201F*
> and U+201D, the latter being the same closing double quotes as in
> English);

There is no Greek page for
https://en.wikipedia.org/wiki/Quotation_mark
As to English page, notice
https://en.wikipedia.org/wiki/Quotation_mark#Summary_table
https://en.wikipedia.org/wiki/Quotation_mark#Greek
sections. It cites
http://publications.europa.eu/code/el/el-4100107el.htm
that uses “ U+0201C (&#8220;, &lquo;, or &lquot;) and ” U+0201D (&#8221, 
&rquo;, or &rquot;) as inner quotes. If it is acceptable to use this 
pair, LaTeX commands likely may be \textquotedblleft and 
\textquotedblright (or simply `` and ''). I have not noticed anything 
more appropriate in "The Comprehensive LATEX Symbol List". Even
https://www.ctan.org/pkg/babel-greek does not suggest proper way for 
inner quotes.

Even if precise variant is uncertain, maybe any reasonable choice is 
better than currently used defaults. Anyway it may be corrected later.

> #+begin_src emacs-lisp
> (secondary-opening :utf-8 "‟" :html "&#8223;;" :latex "??" :texinfo "??")
> #+end_src

It seems, there is no named entity for U+0201F
https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references

For some unclear reason (there is a badge requesting references), 
Russian page
https://ru.wikipedia.org/wiki/Кавычки
mentions
- «…» as usually used outer,
- ‹…› as usually used inner,
- “…” as alternative outer,
- ‘…’ as alternative inner
quotes. Perhaps, it is just a mistake.



^ permalink raw reply	[relevance 5%]

* Smart quotes for Greek (questions for a possible patch)
@ 2021-08-14 15:06  7% Juan Manuel Macías
  2021-08-15 15:59  5% ` Maxim Nikulin
  2021-08-15 21:28  6% ` mvar
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-14 15:06 UTC (permalink / raw)
  To: orgmode

Hi,

I would like to submit a patch to add smart quotes for Greek in
`org-export-smart-quotes-alist', but I have a couple of questions.

First of all, I am not a native speaker of Greek but of Spanish, so I
would also like to have the opinion of some Greek native speaker, to see
if my solutions are correct.

The second question concerns the second-level quotation marks for Greek.
The first level ones are the same as the Spanish or French quotes
(without the extra space of French): «», so no problem. I follow here
the rule that Yannis Haralambous explains in "From Unicode to
Typography, a Case Study: the Greek Script" (1999, p. 20:
http://web.archive.org/web/20120229131933/http://omega.enstb.org/yannis/pdf/boston99.pdf).

According to Haralambous, on the second-level quotation marks (the
emphases are mine):

#+begin_quote

Also interesting is the case of the second level quotes. Here, quotes of
the size and shape of the English ones are used, but the opening quotes
are inverted, similar in form to raised small round guillemets [...].
Fortunately these quotes are provided by the Unicode standard (*U+201F*
and U+201D, the latter being the same closing double quotes as in
English); *the author knows no other language in which this combination
of double quotes might be used*.

#+end_quote

So the problem is in the character U+201F (assuming Haralambous is
right). For the keywords `:utf8' and `html' no problem. But I don't know
what to put in `:latex' or in `:texinfo':

#+begin_src emacs-lisp
(secondary-opening :utf-8 "‟" :html "&#8223;;" :latex "??" :texinfo "??")
#+end_src

In fact, I think latex2e has no command or shorthand predefined for this
character (see https://ibb.co/ZBGmwYP). There would be no problem with
LuaTeX and XeTeX. But this character would be difficult to obtain in
pdfTeX even using inputenc with the utf8 option.

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 7%]

* Re: return column from table as a column
  2021-08-13 17:12 10%     ` Juan Manuel Macías
@ 2021-08-14 10:30  6%       ` Roger Mason
  0 siblings, 0 replies; 200+ results
From: Roger Mason @ 2021-08-14 10:30 UTC (permalink / raw)
  To: orgmode

Hello Juan,

Juan Manuel Macías writes:

> You're welcome. Just a minor fix: although the code works fine,
> naturally the asterisk in `let' was unnecessary. This is a new version
> with the code explained, in case you find it useful:
>
> #+begin_src emacs-lisp :var data=s1 col=3
>   (let* (
> 	 ;; return a list from elemens in column number `col'
> 	 (list-from-column (mapcar (lambda (r) (format "%s" (nth col r))) data))
> 	 ;; make a list of lists = a new table that contains one single column
> 	 (new-table (mapcar 'list list-from-column)))
>     new-table)
> #+end_src

Many thanks for this.  A looong time ago I was capable of programming in
emacs-lisp.  Alas I have not maintained my skills.

Best wishes,
Roger


^ permalink raw reply	[relevance 6%]

* Re: Custom function for killing the thing at point
  @ 2021-08-13 22:46 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 22:46 UTC (permalink / raw)
  To: Rodrigo Morales; +Cc: orgmode

Hi Rodrigo,

Thanks for sharing, it seems interesting and useful. But I think this
function is missing in your post: `my/kill-new'.

Best regards,

Juan Manuel 

Rodrigo Morales writes:

> I just created this function for copying the thing under the cursor (it
> works for some #+BEGIN blocks and links). I think it would be useful for
> others, so I'm creating this post for getting feedback on the Elisp code
> and sharing it to those interested.
>
> #+BEGIN_SRC elisp
> (defun my/org-kill-thing-at-point ()
>   "Kill the thing at point.
>
> The following things are currently supported
>
> - #+BEGIN_SRC <<any>>
> - #+BEGIN_EXPORT <<any>>
> - #+BEGIN_EXAMPLE <<any>>
> - #+BEGIN_COMMENT
> - Org links (the description is not copied)"
>   (interactive)
>   (let* (content
>          (element (org-element-context))
>          (type (org-element-type element)))
>     (cond ((or (eq type 'src-block)
>                (eq type 'export-block)
>                (eq type 'example-block)
>                (eq type 'comment-block))
>            (setq content (plist-get (cadr element) :value)))
>           ((eq type 'link)
>            (setq content (plist-get (cadr element) :raw-link)))
>           (t
>            (error "The element at point couldn't be copied.")))
>     (my/kill-new content)))
> #+END_SRC
>
> #+BEGIN_SRC elisp
> (define-key org-mode-map (kbd "C-c c") 'my/org-kill-thing-at-point)
> #+END_SRC
>




^ permalink raw reply	[relevance 10%]

* Re: Org + git branches for derived files
  @ 2021-08-13 20:53 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 20:53 UTC (permalink / raw)
  To: Ken Mankoff; +Cc: orgmode

Hi Ken,

Ken Mankoff writes:

> I'd like to keep derivative products (the LaTeX output, the final PDF,
> etc.) available in Git, but not commit those changes each time I
> change the Org file. Perhaps git-annex as appropriate for this, but
> seems over-kill.
>
> Is there some way to mostly-seamlessly commit the LaTeX and/or PDF
> and/or other files to their own git branches but in a way that
> overwrites the history of that branch, so that a small Org file that
> generates a big binary PDF does not pollute the git tree?

There are probably better solutions, but maybe this could help you:
use org-publish (which also works when the output is LaTeX/PDF, and
not only with HTML). See https://orgmode.org/manual/Publishing.html

You should have to define a new publishing project and declare a
directory for the PDFs derivatives, applying a value to
:publishing-directory, and configure in this directory a second git
repository, only for PDFs. The value of :publishing-function keyword
should be `org-latex-publish-to-pdf'.

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 10%]

* Re: return column from table as a column
  2021-08-13 16:32  6%   ` Roger Mason
@ 2021-08-13 17:12 10%     ` Juan Manuel Macías
  2021-08-14 10:30  6%       ` Roger Mason
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-13 17:12 UTC (permalink / raw)
  To: Roger Mason; +Cc: orgmode

Hello Roger,

Roger Mason writes:

> Thank you, I think I may be able to get this to work.

You're welcome. Just a minor fix: although the code works fine,
naturally the asterisk in `let' was unnecessary. This is a new version
with the code explained, in case you find it useful:

#+begin_src emacs-lisp :var data=s1 col=3
  (let* (
	 ;; return a list from elemens in column number `col'
	 (list-from-column (mapcar (lambda (r) (format "%s" (nth col r))) data))
	 ;; make a list of lists = a new table that contains one single column
	 (new-table (mapcar 'list list-from-column)))
    new-table)
#+end_src

Regards,

Juan Manuel 



^ permalink raw reply	[relevance 10%]

* Re: return column from table as a column
  2021-08-13 14:47 10% ` Juan Manuel Macías
@ 2021-08-13 16:32  6%   ` Roger Mason
  2021-08-13 17:12 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Roger Mason @ 2021-08-13 16:32 UTC (permalink / raw)
  To: orgmode


Hello Juan,

Juan Manuel Macías writes:

> #+name: s1
> | scale |  scale1 |   scale3 |  jid |
> | -     | 1.00402 | 0.952329 | 1632 |
> | -     | 1.00402 | 0.962247 | 1633 |
>
> #+begin_src emacs-lisp :var data=s1 col=3
>     (let* ((column (mapcar (lambda (r) (format "%s" (nth col r))) data)))
> 	   (mapcar 'list column))
> #+end_src
>
> #+RESULTS:
> |  jid |
> | 1632 |
> | 1633 |

Thank you, I think I may be able to get this to work.

Roger


^ permalink raw reply	[relevance 6%]

* Re: return column from table as a column
  @ 2021-08-13 14:47 10% ` Juan Manuel Macías
  2021-08-13 16:32  6%   ` Roger Mason
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-13 14:47 UTC (permalink / raw)
  To: Roger Mason; +Cc: orgmode

Hi Roger,

It's a dirty solution, but you can try:

#+name: s1
| scale |  scale1 |   scale3 |  jid |
| -     | 1.00402 | 0.952329 | 1632 |
| -     | 1.00402 | 0.962247 | 1633 |

#+begin_src emacs-lisp :var data=s1 col=3
    (let* ((column (mapcar (lambda (r) (format "%s" (nth col r))) data)))
	   (mapcar 'list column))
#+end_src

#+RESULTS:
|  jid |
| 1632 |
| 1633 |

Best regards,

Juan Manuel 

Roger Mason writes:

> Hello,
>
> I need to extract a column from a table to use as input to a source
> block.  I want the extracted column to be returned as a column but it is
> returned as a row.  The following illustrates the problem:
>
> #+name: s1
> | scale |  scale1 |   scale3 |  jid |
>
> | -     | 1.00402 | 0.952329 | 1632 |
> | -     | 1.00402 | 0.962247 | 1633 |
>
> #+begin_src emacs-lisp :var data=s1[,3]
> data
> #+end_src
>
> #+RESULTS:
> | jid | 1632 | 1633 |
>
> I want:
>
> |  jid |
> | 1632 |
> | 1633 |
>
> Is there some means of changing 'data=s1[,3]' to accomplish this?
>
> Thanks,
> Roger
>
> GNU Emacs 27.2 (build 1, amd64-portbld-freebsd11.4, X toolkit, cairo
> version 1.16.0, Xaw3d scroll bars)
>
> Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @
> /home/rmason/.emacs.d/org-git/lisp/)
>



^ permalink raw reply	[relevance 10%]

* [tip] get the verse number at point inside a verse block
@ 2021-08-13 13:45  8% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-13 13:45 UTC (permalink / raw)
  To: orgmode

Hi,

We're highly unlikely to feel in our life the strange need to know the
verse number at point within a verse block (verse numbers are not equal
to line numbers).

However, in my translation of Homer's Odyssey (work in progress), I
often need to get (at point) both the verse number and the book number,
so that it can be canonically cited in many references I include in the
prologue and footnotes. For example: Od. 2.125 (book + verse). So I
wrote this little code:

First, you get the verse number at point:

#+begin_src emacs-lisp
(defun verse-num-at-point ()
  "Return the verse number at point inside a `verse' block"
  (save-excursion
    (end-of-line)
    (save-restriction
      (org-narrow-to-block)
      (narrow-to-region (point-min) (point))
      (goto-char (point-min))
      (end-of-line)
      (let
          ((versenum 0))
        (save-excursion
          (while
              (re-search-forward "^." nil t)
            (setf versenum (+ versenum 1)))
          (setq verse-at-point versenum)))))
  verse-at-point)
#+end_src

And, with this function, you get the canonical citation (taking into
account that book number is a property named `:book:'):

#+begin_src emacs-lisp
(defun locate-odyssey ()
  (interactive)
  (let ((book (org-entry-get nil "book"))
        (verse (verse-num-at-point)))
    (message "Od. %s.%s" book verse)
    (kill-new (format "Od. %s.%s" book verse))))
#+end_src

Bonus track: I also wrote this little package to display verse numbers
at margin: https://gitlab.com/maciaschain/org-verse-num

Best regards,

Juan Manuel


^ permalink raw reply	[relevance 8%]

* Re: [PATCH] ox.el: fix spanish translation for `footnotes'
  2021-08-03 10:47 10% [PATCH] ox.el: fix spanish translation for `footnotes' Juan Manuel Macías
@ 2021-08-07 20:10  6% ` Nicolas Goaziou
  0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-08-07 20:10 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

Hello,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> The Spanish translation for "Footnotes" in `org-export-dictionary' is
> "Nota al pie de página" ("Nota"[="Note"], in the singular form). I think
> it would be more correct "Notas", in the plural form. Attached a small
> patch.

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* "Continuous Integration and TeX with Org-Mode", by Rohit Goswani (TUG 2021)
@ 2021-08-06 10:33  9% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-06 10:33 UTC (permalink / raw)
  To: orgmode

Hi all,

I share here the announcement of this presentation by Rohit Goswani
entitled "Continuous Integration and TeX with Org-Mode", scheduled for
Saturday, 7 Aug, within TUG 2021:

----
Sat, 7 Aug – 10:30 AM | Rohit Goswami Continuous Integration and TeX
with Org-Mode

In this talk I would like to introduce the usage of TeX and templates
along with generating ad-hoc class and style files for working with
orgmode. In particular, I will highlight also the process by which
literate programming practices can be implemented with babel. This
allows for a more native and flexible alternative to vendor locked in
systems like Jupyterlab which rely on JS based inelegant approaches
towards TeX typesetting. Alternative pdf generating backends consuming
TeX like Sphinx will also be covered. Finally, I would like to go into
how to leverage CI methods for TeX workflows augmented with git.
---

More info: https://tug.org/tug2021/sched.html

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: ConTeXt exporter for Org Mode
  2021-08-04 19:43 10% ` Juan Manuel Macías
@ 2021-08-05 10:23  6%   ` András Simonyi
  0 siblings, 0 replies; 200+ results
From: András Simonyi @ 2021-08-05 10:23 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Jason Ross

Dear Jason,

this is excellent news, thanks for your work! I always wondered why
there is no Org exporter for ConTeXt which seemed such an obvious
target --  can't wait to try it out!

best regards,
András

On Wed, 4 Aug 2021 at 21:44, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>
> Hi Jason,
>
> Jason Ross writes:
>
> > Hello,
> >
> > I have developed a ConTeXt exporter for Org Mode. It is available at
> > https://github.com/Jason-S-Ross/ox-context
> >
> > The exporter provides custom environments for each document element
> > in an effort to make customization easier, in contrast to the Pandoc
> > exporter which uses built-in environments for document elements.
> >
> > I welcome any feedback.
>
> Congratulations on your excellent work. I am not a daily ConTeXt user, and I'm
> afraid I can't help much. But I think a native exporter to ConTeXt
> could be an important addition to Org. It could be interesting for users
> who want to discover this powerful alternative to LaTeX (within the TeX
> ecosystem), as well as for users who want high-quality pdf output without
> the need for get caught up in the complexity of LaTeX packages, since
> ConTeXt has a more monolithic conception than LaTeX.
>
> Very interesting and promising, in any case.
>
> Best regards,
>
> Juan Manuel
>
>
>


^ permalink raw reply	[relevance 6%]

* Re: ConTeXt exporter for Org Mode
  @ 2021-08-04 19:43 10% ` Juan Manuel Macías
  2021-08-05 10:23  6%   ` András Simonyi
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-04 19:43 UTC (permalink / raw)
  To: Jason Ross; +Cc: orgmode

Hi Jason,

Jason Ross writes:

> Hello,
>
> I have developed a ConTeXt exporter for Org Mode. It is available at
> https://github.com/Jason-S-Ross/ox-context
>
> The exporter provides custom environments for each document element
> in an effort to make customization easier, in contrast to the Pandoc
> exporter which uses built-in environments for document elements.
>
> I welcome any feedback.

Congratulations on your excellent work. I am not a daily ConTeXt user, and I'm
afraid I can't help much. But I think a native exporter to ConTeXt 
could be an important addition to Org. It could be interesting for users
who want to discover this powerful alternative to LaTeX (within the TeX
ecosystem), as well as for users who want high-quality pdf output without
the need for get caught up in the complexity of LaTeX packages, since
ConTeXt has a more monolithic conception than LaTeX.

Very interesting and promising, in any case.

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 10%]

* [PATCH] ox.el: fix spanish translation for `footnotes'
@ 2021-08-03 10:47 10% Juan Manuel Macías
  2021-08-07 20:10  6% ` Nicolas Goaziou
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-08-03 10:47 UTC (permalink / raw)
  To: orgmode

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Hi,

The Spanish translation for "Footnotes" in `org-export-dictionary' is
"Nota al pie de página" ("Nota"[="Note"], in the singular form). I think
it would be more correct "Notas", in the plural form. Attached a small
patch.

Best regards,

Juan Manuel


[-- Attachment #2: 0001-ox.el-fix-spanish-translation-for-footnotes.patch --]
[-- Type: text/x-patch, Size: 1063 bytes --]

From 4109c6f2bc38d56b0a67c482afc3feeddfcf3084 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 3 Aug 2021 12:31:02 +0200
Subject: [PATCH] ox.el: fix spanish translation for `footnotes'

* lisp/ox.el (org-export-dictionary): tiny fix in spanish translation (plural instead of singular)
---
 lisp/ox.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 16b87a7ed..418c680b0 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5928,7 +5928,7 @@ them."
      ("da" :default "Fodnoter")
      ("de" :html "Fu&szlig;noten" :default "Fußnoten")
      ("eo" :default "Piednotoj")
-     ("es" :ascii "Nota al pie de pagina" :html "Nota al pie de p&aacute;gina" :default "Nota al pie de página")
+     ("es" :ascii "Notas al pie de pagina" :html "Notas al pie de p&aacute;gina" :default "Notas al pie de página")
      ("et" :html "Allm&#228;rkused" :utf-8 "Allmärkused")
      ("fi" :default "Alaviitteet")
      ("fr" :default "Notes de bas de page")
-- 
2.32.0


^ permalink raw reply related	[relevance 10%]

* Re: TMIO July Post: Introducing Citations
  @ 2021-08-02  7:23 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-08-02  7:23 UTC (permalink / raw)
  To: Timothy; +Cc: orgmode

Hi Timothy,

Timothy writes:

> Hi Everyone,
>
> Just letting you know that on my blog TMIO (This Month In Org) I've just
> published the July post. I've decided to focus entirely on citations
> this time :)
>
> Should this be of interest, here it is:
> https://blog.tecosaur.com/tmio/2021-07-31-citations.html

Thank you very much for this comprehensive and very useful post: the
best way to start my summer vacation! :-)

And many thanks to those who have developed this interesting and
promising new Org feature.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Multilingual quotes inside paragraphs
  2021-07-28 13:49  8%   ` Juan Manuel Macías
@ 2021-08-01 16:02  5%     ` Maxim Nikulin
  0 siblings, 0 replies; 200+ results
From: Maxim Nikulin @ 2021-08-01 16:02 UTC (permalink / raw)
  To: emacs-orgmode

On 28/07/2021 20:49, Juan Manuel Macías wrote:
> Links (or macros) are a good user-level solution to solve certain
> specific cases, IMHO. At a native level (in case Org someday implement
> consistent and native multilingual support), I don't know what would be
> the best solution for multilingual chunks of text inside paragraphs.
> Maybe some kind of inline `quote' block?

My personal impression is that lightweight Org markup is suitable for 
simple documents. Problems grow as a snowball as soon as a document 
becomes more complex. If syntax were extended too much, Org would loose 
its simplicity that is one of its advantage. Complex documents require 
more strict and flexible thus more verbose markup format.

It seems, your have tried all possible variants for inline quotes
https://orgmode.org/worg/dev/org-syntax.html#Objects
macros, src_org{}, even links and nothing is perfect
https://orgmode.org/list/875yzwce28.fsf@posteo.net
Code for any approach may be polished to some extent, but some 
limitations will remain.



^ permalink raw reply	[relevance 5%]

* Re: Multilingual quotes inside paragraphs
  2021-07-28 12:13  5% ` Maxim Nikulin
@ 2021-07-28 13:49  8%   ` Juan Manuel Macías
  2021-08-01 16:02  5%     ` Maxim Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-28 13:49 UTC (permalink / raw)
  To: Maxim Nikulin; +Cc: orgmode

Hi Maxim, thank you for your comments.

Maxim Nikulin writes:
> Are you intentionally avoiding macros {{{lang(ru, текст)}}}?

Yes. Precisely, these experiments are just an attempt to find an
alternative to macros (I use macros a lot). In scenarios like these
(chunks of text) is where the issue of the comma as a escape character
in macros becomes more evident (this comma issue has been discussed in a
past thread, and some interesting proposals were made). Links and
macros, of course, have their pros and cons.

> It seems, you are abusing links a bit.

I'm afraid it's true :-). Anyway I think the links have a great
potential. I have tried exploring other "eccentric" uses of links, for
example here (to export subfigures to LaTeX and HTML):
https://orgmode.org/list/87mty1an66.fsf@posteo.net/ or also in my
org-critical-edition package, to work on (philological) critical
editions from Org: https://gitlab.com/maciaschain/org-critical-edition

> [...]
> Another issue is that someone will almost immediately want to put such
> quote inside link or vice versa to make some fragment of a quote a
> regular link.

Yes, that issue you describe would be one of the biggest drawbacks for
the use of links in these contexts.

Links (or macros) are a good user-level solution to solve certain
specific cases, IMHO. At a native level (in case Org someday implement
consistent and native multilingual support), I don't know what would be
the best solution for multilingual chunks of text inside paragraphs.
Maybe some kind of inline `quote' block?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: Multilingual quotes inside paragraphs
  2021-07-26  9:25  7% Multilingual quotes inside paragraphs Juan Manuel Macías
@ 2021-07-28 12:13  5% ` Maxim Nikulin
  2021-07-28 13:49  8%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-28 12:13 UTC (permalink / raw)
  To: emacs-orgmode

On 26/07/2021 16:25, Juan Manuel Macías wrote:
> 
> I'm experimenting with `org-link-set-parameters' to create multilingual
> quotes (chunks of text) inside paragraphs. Although I focus mainly on
> the export to LaTeX with babel and csquotes packages, I also want extend
> support for HTML and odt output. I leave here some sketches.

Are you intentionally avoiding macros {{{lang(ru, текст)}}}? It seems, 
you are abusing links a bit. Though it allows to hide "target" part and 
thus to reduce "noise" in the text. On the other hand, links may be 
broadly considered as customizable element ("interactive" property is 
not necessary for such snippets) since there are no other similar 
objects in Org syntax. One problem is support in 3rd party tools: 
pandoc, various renderers, e.g. (ruby?) on github.

Another issue is that someone will almost immediately want to put such 
quote inside link or vice versa to make some fragment of a quote a 
regular link. A workaround is possible: 
lang:de?href=https%3A%2F%2Forgmode.org%2F with some code for handling of 
unescaped target. I expect complains that it is not user-friendly to 
require splitting fragment at the borders of inner link. Org does not 
support nested objects of the same type.

> or explicitly preceded by
> a "!": "!german" (the reason for the latter is that in babel we can
> define new languages):

Unsure that ODT and HTML allows to define languages. I would consider 
some lisp structures describing mapping of customizable languages codes 
to some set of properties.




^ permalink raw reply	[relevance 5%]

* Re: [PATCH] [BUG] Bad fontification in full displayed links
  @ 2021-07-27 20:02  6%     ` Nicolas Goaziou
  0 siblings, 0 replies; 200+ results
From: Nicolas Goaziou @ 2021-07-27 20:02 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Ihor Radchenko

Hello,

Juan Manuel Macías <maciaschain@posteo.net> writes:

> You are right, I think that solution is much simpler. I attach a
> new patch and I have included your name in the commit message, for the
> suggestion. Thanks!

Applied. Thank you.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[relevance 6%]

* Multilingual quotes inside paragraphs
@ 2021-07-26  9:25  7% Juan Manuel Macías
  2021-07-28 12:13  5% ` Maxim Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2021-07-26  9:25 UTC (permalink / raw)
  To: orgmode

Hi all,

I'm experimenting with `org-link-set-parameters' to create multilingual
quotes (chunks of text) inside paragraphs. Although I focus mainly on
the export to LaTeX with babel and csquotes packages, I also want extend
support for HTML and odt output. I leave here some sketches.

For the `:face' parameter I use for laziness a face already defined in
Magit :-). `:display' with the value 'full can be removed.

First, we have the LaTeX babel command \foreignlanguage{lang}{chunk of
text}. The language can be expressed by abbreviation ("de" for German;
here I reuse `org-latex-babel-language-alist') or explicitly preceded by
a "!": "!german" (the reason for the latter is that in babel we can
define new languages):

[[lang:de][some text in German]]

or

[[lang:!german][some text in German]]

The code:

(org-link-set-parameters "lang"
			   :display 'full
			   :face 'magit-header-line-key
			   :export (lambda (target desc format)
				     (cond
				      ((eq format 'latex)
				       (let ((langs org-latex-babel-language-alist))
					 (concat
					  "\\foreignlanguage{"
					  (if (string-match-p "!" target)
					      (replace-regexp-in-string "!" "" target)
					    (cdr (assoc target langs)))
					  "}{" desc "}")))
                                          ;; TODO
				      ((or (eq format 'html)
					   (eq format 'odt))
				       (format "%s" desc)))))

We also have this command from the csquotes package for foreign quoted
texts (loads only the hyphenation rules for the language and sets the
text between quotation marks): \hyphentextquote{lang}{quoted text}. For
this I have defined a new link "qlang":

  (org-link-set-parameters "qlang"
			   :display 'full
			   :face 'magit-header-line-key
			   :export (lambda (target desc format)
				     (cond
				      ((eq format 'latex)
				       (let ((langs org-latex-babel-language-alist))
					 (concat
					  "\\hyphentextquote{"
					  (if (string-match-p "!" target)
					      (replace-regexp-in-string "!" "" target)
					    (cdr (assoc target langs)))
					  "}{" desc "}")))
				      ((or (eq format 'html)
					   (eq format 'odt))
				       ;; TODO (use here the proper quotes)
				       (format "«%s»" desc)))))

We can even make the citations come out in color when we are in draft
mode, thanks to the LaTeX ifdraft package:

(org-link-set-parameters "qlang"
			 :display 'full
			 :face 'magit-header-line-key
			 :export (lambda (target desc format)
				   (cond
				    ((eq format 'latex)
				     (let ((langs org-latex-babel-language-alist))
				       (concat
					"{\\ifdraft{\\color{teal}}{}\\hyphentextquote{"
					(if (string-match-p "!" target)
					    (replace-regexp-in-string "!" "" target)
					  (cdr (assoc target langs)))
					"}{"
					desc "}}")))
				    ((or (eq format 'html)
					 (eq format 'odt))
				     ;; TODO
				     (format "«%s»" desc)))))


Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 7%]

* Re: org-mode export to (latex) PDF
  2021-07-17 12:35  4%                       ` Maxim Nikulin
@ 2021-07-17 14:27  7%                         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2021-07-17 14:27 UTC (permalink / raw)
  To: Maxim Nikulin; +Cc: orgmode

Hi Maxim,

I think the problem is not the fact that I may be inclined towards book
typesetting but that TeX itself and its workflow is inclined towards
book typesetting. This fact is something that must be taken into account
and that many LaTeX users sometimes forget. The concept of a 'fallback
font' is still something exotic for the TeX working method, despite that
LuaTeX can access TeX primitives using scripting in lua and can achieve
things like that, at the cost of resources. For example, the fontspec
package provides the conditional \IfFontExists{font}{True code}{False
code} which consumes a lot of resources.

Anyway, I would dare to recommend these two possibilities:

a) If you want to define a list of fallback fonts for the LaTeX
process, IMHO should be done org-centric with Elisp (something for
pdfTeX, XeTeX and LuaTeX. I'm afraid this would be a lot of work and too
much cholesterol for Org Mode, though).

b) However, my preference is something that has already been comented in
this thread: add to the documentation (or to Worg web site) a (not too
long) list of recommended fonts for different languages: of course,
fonts that are freely licensed and accessible to everyone. In any
collaborative work in LaTeX I find it's much more simple to share an
easily accessible and free (as in freedom) font than to add a list of
fallback fonts to the documents via code (a true bloat for TeX). The
LaTeX Font Catalogue includes lots of very good quality fonts. For
example, TeX Live includes an excellent font with support for Greek,
Cyrillic and Linguistics: Old Standard, originally designed by prof.
Alexey Kryukov and currently maintained by Robert Alessi:
https://www.ctan.org/pkg/oldstandard (I don't work on Cyrillic and I can
not comment on that aspect: I use this font more for Greek; but it is
often said that Old Standard is one of the best and most documented
options to represent Cyrillic).

Best regards,

Juan Manuel 

Maxim Nikulin writes:

> On 17/07/2021 01:34, Juan Manuel Macías wrote:
>> Maxim Nikulin writes:
>> 
>>> I think that low level implementation in browser or in some underlying
>>> library is much faster
>>>
>>>      <dl>
>>>        <dt>LM Roman 12</dt>
>>>        <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
>>>        <dt>LM Roman 12, CMU Serif</dt>
>>>        <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
>>>      </dl>
>> They are two different scenarios: web publishing and book
>> typesetting
>
> Juan Manuel, it seems you are too inclined to book typesetting. It is
> important case and it should be supported by org. I have repeated two 
> times in this thread that there is another case, namely routine quick
> notes. Such documents have another balance concerning time required to 
> get acceptable result. TeX takes responsibility for a lot of defaults
> such as what spaces should be added around "=" and what ones around 
> right angle bracket. Users do not need to make decisions concerning
> such design details to get accurately typeset equations.
>
> At the age of custom charsets (often 8bit) and encodings the problem
> of multilingual texts was obvious. Unicode and UTF-8 alleviate many
> issues. It happened that Cyrillic is an edge case for Unicode TeX
> engines. Since ~2000 it works out of the box for LaTeX and PdfLaTeX.
> Last years I did not need to adjust config files and regenerate
> formats. Hyphenation, default fonts (OK, "apt install cm-super" to
> avoid rasterized fonts is a bit behind defaults though no manual
> config is required) just work. Each document needs a few universal
> lines to setup Russian. Some users may have specific style files but
> generally source documents are quite portable.
>
> Default fonts for LuaTeX and XeTeX do not include Cyrillic any more.
> Every user have to do a decision which fonts should be used even if
> one does not care concerning particular fonts. It increases
> probability to get a file with font configuration that is specific to
> Mac or Windows.
>
> I do not actively use characters from other Unicode planes, however
> sometimes I do it for fun. Getting them completely missing is less 
> preferred than displaying them with low quality font. Specifying all
> fonts requires lengthy config, probably different for LuaTeX and
> XeTeX. At first it is necessary to realize which fonts are available
> for particular glyph. Finally it makes *source* document less
> portable.
>
> "font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of
> what I consider relatively high-level config for routine documents
> that do not need to be handcrafted. Unavailable glyph or even font is
> not an error, it just causes lookup of candidates in the following
> items. For TeX maybe it is reasonable to consider fallback to complete
> set of fonts at ones (roman + mono + math) if such combination is
> available.
>
>> If I want to use the GFS Porson as italics from
>> another font, a Didot typeface for example, I can do this:
>
> If it is not a book or at the stage of early draft another scenario is
> possible. Text should just appear in the compiled document, particular 
> font does not matter, its choice is postponed since text content has
> higher priority. Minimal setup in invaluable.
>
> At least with minimal examples I faced another issue: characters
> silently disappears, no warning is generated. Adding babel changes it, 
> but I still believe that especially for documents with carefully
> chosen fonts. It is a serious hidden error to get "invalid char glyph"
> instead of all missed characters.
>
>> [1] If you want to have fallback fonts, you can also do it in
>> LuaTeX by adding some Lua code:
>> https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex
>
> Would you recommend such code as default for Org? Let's assume that
> some information concerning system fonts are available. I suspect, the 
> accepted answer is not fool-proof. In addition, XeLaTeX requires
> something different.
>
> luaotfload provides fallback feature close to what I expect, however
> it is necessary to explicitly specify script that I would prefer to
> avoid. Moreover it significantly increases compilation time. Sometimes
> LuaLaTeX starts to eat CPU with no progress, emoji does not work for
> some reason.
> I am unsure concerning particular "Noto Sans CJK" since several ones
> are available.
>
> \documentclass{article}
> \usepackage{fontspec}
> \usepackage{unicode-math}
> \directlua{luaotfload.add_fallback
>   ("seriffallback",
>     {
>       "Noto Serif CJK SC:mode=harf;script=sc;",
>       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
>     })
> }
> % TwemojiMozilla is not shown by viewers, visible in pdftotext
>       %"Noto Color Emoji:mode=harf;"
> % or
>       %"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
> % </usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
> % ! error:  (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf)
>     (ttf): loca
> % table not found
> % !  ==> Fatal error occurred, no output PDF file produced!
> \setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]
>
> \directlua{luaotfload.add_fallback
>   ("sansfallback",
>     {
>       "Noto Sans CJK SC:mode=harf;script=sc;",
>       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
>     })
> }
> \setsansfont{CMU Sans Serif}[RawFeature={fallback=sansfallback}]
>
> \directlua{luaotfload.add_fallback
>   ("monofallback",
>     {
>       "Noto Sans Mono CJK SC:mode=harf;script=sc;",
>       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
>     })
> }
> \setmonofont{CMU Typewriter Text}[RawFeature={fallback=monofallback}]
> \begin{document}
> Test¹ of superscript and ½ fraction.
>
> \textbf{«Теорема».} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.
>
> \verb=Катет= и \textsf{гипотенуза}.
>
> Åå. Text Greek α.
>
> Text utf8x ≠ utf8 and math $utf8x ≠ utf8$.
>
> Randomly chosen examples: "日本", "多喝水", "📞".
>
> \verb=Randomly chosen examples: "日本", "多喝水", "📞".=
> \end{document}
>
>



^ permalink raw reply	[relevance 7%]

* Re: org-mode export to (latex) PDF
  @ 2021-07-17 12:35  4%                       ` Maxim Nikulin
  2021-07-17 14:27  7%                         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Maxim Nikulin @ 2021-07-17 12:35 UTC (permalink / raw)
  To: emacs-orgmode

On 17/07/2021 01:34, Juan Manuel Macías wrote:
> Maxim Nikulin writes:
> 
>> I think that low level implementation in browser or in some underlying
>> library is much faster
>>
>>      <dl>
>>        <dt>LM Roman 12</dt>
>>        <dd style="font-family: 'LM Roman 12'">abc абв…с</dd>
>>        <dt>LM Roman 12, CMU Serif</dt>
>>        <dd style="font-family: 'LM Roman 12', 'CMU Serif'">abc абв…с</dd>
>>      </dl>
> 
> They are two different scenarios: web publishing and book typesetting

Juan Manuel, it seems you are too inclined to book typesetting. It is 
important case and it should be supported by org. I have repeated two 
times in this thread that there is another case, namely routine quick 
notes. Such documents have another balance concerning time required to 
get acceptable result. TeX takes responsibility for a lot of defaults 
such as what spaces should be added around "=" and what ones around 
right angle bracket. Users do not need to make decisions concerning such 
design details to get accurately typeset equations.

At the age of custom charsets (often 8bit) and encodings the problem of 
multilingual texts was obvious. Unicode and UTF-8 alleviate many issues. 
It happened that Cyrillic is an edge case for Unicode TeX engines. Since 
~2000 it works out of the box for LaTeX and PdfLaTeX. Last years I did 
not need to adjust config files and regenerate formats. Hyphenation, 
default fonts (OK, "apt install cm-super" to avoid rasterized fonts is a 
bit behind defaults though no manual config is required) just work. Each 
document needs a few universal lines to setup Russian. Some users may 
have specific style files but generally source documents are quite portable.

Default fonts for LuaTeX and XeTeX do not include Cyrillic any more. 
Every user have to do a decision which fonts should be used even if one 
does not care concerning particular fonts. It increases probability to 
get a file with font configuration that is specific to Mac or Windows.

I do not actively use characters from other Unicode planes, however 
sometimes I do it for fun. Getting them completely missing is less 
preferred than displaying them with low quality font. Specifying all 
fonts requires lengthy config, probably different for LuaTeX and XeTeX. 
At first it is necessary to realize which fonts are available for 
particular glyph. Finally it makes *source* document less portable.

"font-family: 'LM Roman 12', 'CMU Serif'" above is a dumb example of 
what I consider relatively high-level config for routine documents that 
do not need to be handcrafted. Unavailable glyph or even font is not an 
error, it just causes lookup of candidates in the following items. For 
TeX maybe it is reasonable to consider fallback to complete set of fonts 
at ones (roman + mono + math) if such combination is available.

> If I want to use the GFS Porson as italics from
> another font, a Didot typeface for example, I can do this:

If it is not a book or at the stage of early draft another scenario is 
possible. Text should just appear in the compiled document, particular 
font does not matter, its choice is postponed since text content has 
higher priority. Minimal setup in invaluable.

At least with minimal examples I faced another issue: characters 
silently disappears, no warning is generated. Adding babel changes it, 
but I still believe that especially for documents with carefully chosen 
fonts. It is a serious hidden error to get "invalid char glyph" instead 
of all missed characters.

> [1] If you want to have fallback fonts, you can also do it in
> LuaTeX by adding some Lua code:
> https://tex.stackexchange.com/questions/514940/define-fallback-font-for-missing-glyphs-in-lualatex

Would you recommend such code as default for Org? Let's assume that some 
information concerning system fonts are available. I suspect, the 
accepted answer is not fool-proof. In addition, XeLaTeX requires 
something different.

luaotfload provides fallback feature close to what I expect, however it 
is necessary to explicitly specify script that I would prefer to avoid. 
Moreover it significantly increases compilation time. Sometimes LuaLaTeX 
starts to eat CPU with no progress, emoji does not work for some reason.
I am unsure concerning particular "Noto Sans CJK" since several ones are 
available.

\documentclass{article}
\usepackage{fontspec}
\usepackage{unicode-math}
\directlua{luaotfload.add_fallback
   ("seriffallback",
     {
       "Noto Serif CJK SC:mode=harf;script=sc;",
       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
     })
}
% TwemojiMozilla is not shown by viewers, visible in pdftotext
       %"Noto Color Emoji:mode=harf;"
% or
       %"file:/usr/share/fonts/truetype/noto/NotoColorEmoji.ttf:mode=harf;"
% </usr/share/fonts/truetype/noto/NotoColorEmoji.ttf
% ! error:  (file /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf) 
(ttf): loca
% table not found
% !  ==> Fatal error occurred, no output PDF file produced!
\setmainfont{CMU Serif}[RawFeature={fallback=seriffallback}]

\directlua{luaotfload.add_fallback
   ("sansfallback",
     {
       "Noto Sans CJK SC:mode=harf;script=sc;",
       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
     })
}
\setsansfont{CMU Sans Serif}[RawFeature={fallback=sansfallback}]

\directlua{luaotfload.add_fallback
   ("monofallback",
     {
       "Noto Sans Mono CJK SC:mode=harf;script=sc;",
       "file:/usr/lib/firefox/fonts/TwemojiMozilla.ttf:mode=harf;"
     })
}
\setmonofont{CMU Typewriter Text}[RawFeature={fallback=monofallback}]
\begin{document}
Test¹ of superscript and ½ fraction.

\textbf{«Теорема».} \emph{Пусть} $α → ∞$ и $\beta \to \infty$.

\verb=Катет= и \textsf{гипотенуза}.

Åå. Text Greek α.

Text utf8x ≠ utf8 and math $utf8x ≠ utf8$.

Randomly chosen examples: "日本", "多喝水", "📞".

\verb=Randomly chosen examples: "日本", "多喝水", "📞".=
\end{document}



^ permalink raw reply	[relevance 4%]

Results 1001-1200 of ~1600   |  | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-05-22 14:12     [PATCH] org.el: use only link descriptions in indirect buffer names Juan Manuel Macías
2021-05-23 10:41     ` Ihor Radchenko
2021-05-23 11:25       ` Juan Manuel Macías
2021-09-26  7:40  6%     ` Bastien
2021-06-03 21:11     [bug?] org-link-set-parameters: when `:display 'full', link face is applied only in description part Juan Manuel Macías
2021-06-04 11:31     ` Juan Manuel Macías
2021-06-06 22:34       ` Juan Manuel Macías
2021-06-08  0:24         ` [PATCH] org.el: prevent partial fontification when a link is full displayed (was org-link-set-parameters: when :display full, etc.) Juan Manuel Macías
2021-09-26  6:08  6%       ` Bastien
2021-09-26 11:35 10%         ` Juan Manuel Macías
2021-09-26 12:49  6%           ` Bastien
2021-07-09  9:15     [PATCH] [BUG] Bad fontification in full displayed links Juan Manuel Macías
2021-07-10  1:50     ` Ihor Radchenko
2021-07-10 12:12       ` Juan Manuel Macías
2021-07-27 20:02  6%     ` Nicolas Goaziou
2021-07-10 13:42     org-mode export to (latex) PDF Jean-Christophe Helary
2021-07-10 13:52     ` Juan Manuel Macías
2021-07-10 16:13       ` Maxim Nikulin
2021-07-10 16:44         ` Stefan Nobis
2021-07-13 16:53           ` Maxim Nikulin
2021-07-14  6:44             ` Stefan Nobis
2021-07-14 17:30               ` Maxim Nikulin
2021-07-14 19:05                 ` Stefan Nobis
2021-07-15 17:10                   ` Maxim Nikulin
2021-07-15 19:40                     ` Juan Manuel Macías
2021-07-16 16:56                       ` Maxim Nikulin
2021-07-16 18:34                         ` Juan Manuel Macías
2021-07-17 12:35  4%                       ` Maxim Nikulin
2021-07-17 14:27  7%                         ` Juan Manuel Macías
2021-07-26  9:25  7% Multilingual quotes inside paragraphs Juan Manuel Macías
2021-07-28 12:13  5% ` Maxim Nikulin
2021-07-28 13:49  8%   ` Juan Manuel Macías
2021-08-01 16:02  5%     ` Maxim Nikulin
2021-08-01 20:29     TMIO July Post: Introducing Citations Timothy
2021-08-02  7:23 10% ` Juan Manuel Macías
2021-08-03 10:47 10% [PATCH] ox.el: fix spanish translation for `footnotes' Juan Manuel Macías
2021-08-07 20:10  6% ` Nicolas Goaziou
2021-08-04 16:01     ConTeXt exporter for Org Mode Jason Ross
2021-08-04 19:43 10% ` Juan Manuel Macías
2021-08-05 10:23  6%   ` András Simonyi
2021-08-06 10:33  9% "Continuous Integration and TeX with Org-Mode", by Rohit Goswani (TUG 2021) Juan Manuel Macías
2021-08-13 13:45  8% [tip] get the verse number at point inside a verse block Juan Manuel Macías
2021-08-13 14:17     return column from table as a column Roger Mason
2021-08-13 14:47 10% ` Juan Manuel Macías
2021-08-13 16:32  6%   ` Roger Mason
2021-08-13 17:12 10%     ` Juan Manuel Macías
2021-08-14 10:30  6%       ` Roger Mason
2021-08-13 18:40     Org + git branches for derived files Ken Mankoff
2021-08-13 20:53 10% ` Juan Manuel Macías
2021-08-13 22:29     Custom function for killing the thing at point Rodrigo Morales
2021-08-13 22:46 10% ` Juan Manuel Macías
2021-08-14 15:06  7% Smart quotes for Greek (questions for a possible patch) Juan Manuel Macías
2021-08-15 15:59  5% ` Maxim Nikulin
2021-08-15 21:28  6% ` mvar
2021-08-16 13:57  8%   ` Juan Manuel Macías
2021-08-27 16:23  3%   ` Protesilaos Stavrou
2021-08-31 11:11  9%     ` Juan Manuel Macías
2021-08-19 11:04  8% Search in descriptive plain lists Juan Manuel Macías
2021-08-26 13:43     how to get multi-line author in ODT export? Eric S Fraga
2021-08-26 14:24     ` Eric S Fraga
2021-08-26 16:05 10%   ` Juan Manuel Macías
2021-08-26 16:54 13%     ` Juan Manuel Macías
2021-08-26 18:34  6%       ` John Kitchin
2021-08-27  1:46 10%         ` Juan Manuel Macías
2021-08-27 13:29     pygments support Yuchen Pei
2021-08-27 13:49 10% ` Juan Manuel Macías
2021-09-02  0:42     Support for tabularray in LaTeX export Vikas Rawal
2021-09-02  8:36  8% ` Juan Manuel Macías
2021-09-02 10:08  7%   ` Vikas Rawal
2021-10-25 14:04         ` Vikas Rawal
2021-10-25 14:18 10%       ` Juan Manuel Macías
2021-10-25 17:25  0%         ` Thomas Dye
2021-09-16 21:40     [PATCH] Fix some typos Stefan Kangas
2021-09-17  9:03     ` Timothy
2021-09-17 10:05       ` Marco Wahl
2021-09-22 16:47         ` Max Nikulin
2021-09-22 20:18 10%       ` Juan Manuel Macías
2021-09-23 14:49  6%         ` Max Nikulin
2021-09-24  6:03  0%           ` Loris Bennett
2021-09-24 12:23  7%             ` Juan Manuel Macías
2021-09-25 11:08  6%               ` Marco Wahl
2021-09-29 10:34  7%                 ` Max Nikulin
2021-09-29 11:09  0%                   ` Marco Wahl
2021-09-29 11:11  0%                   ` Bastien Guerry
2021-09-25 11:47  6%               ` [PATCH] org-manual.org, ORG-NEWS: fix Shakespeare' sonnet and another, typo Max Nikulin
2021-09-29 11:14  6%               ` [PATCH] Fix some typos Bastien
2021-09-18  8:14     Overlining troubles Ypo
2021-09-18 12:50  5% ` Max Nikulin
     [not found]     <mailman.33.1631980810.21752.emacs-orgmode@gnu.org>
2021-09-18 17:14  0% ` Ypo
2021-09-18 17:32       ` Timothy
2021-09-18 17:51  0%     ` Ypo
2021-09-19 16:30  9% [PATCH] ox.el: add smart quotes for Greek Juan Manuel Macías
2021-09-20 14:54  4% ` Max Nikulin
2021-09-21 20:20  8%   ` Juan Manuel Macías
2021-09-22 17:19  5%     ` Max Nikulin
2021-09-22 19:55  8%       ` Juan Manuel Macías
2021-09-23 16:10  6%         ` Max Nikulin
2021-09-23 17:17  8%           ` Juan Manuel Macías
2021-09-25 19:56  7%             ` Juan Manuel Macías
2021-09-22  6:26     [ANN] org-ql 0.6 released Adam Porter
2021-09-22 12:10 10% ` Juan Manuel Macías
2021-09-22 22:41  6%   ` Adam Porter
2021-09-26 12:24     [BUG] Conflict between org-emphasis and org-latex Léo Ackermann
2021-09-26 12:57 10% ` Juan Manuel Macías
2021-09-26 16:57  7%   ` Léo Ackermann
2021-09-26 18:29  9%     ` Juan Manuel Macías
2021-09-27 12:07     LaTeX export: grffile is a stub package meedstrom
2021-09-27 17:00  9% ` Juan Manuel Macías
2021-09-28 15:14     Possible bug? Combine emphasis marker faces? Protesilaos Stavrou
2021-09-28 16:54 10% ` Juan Manuel Macías
2021-09-28 16:46     how to export checkboxes to odt? Uwe Brauer
2021-09-28 20:47 10% ` Juan Manuel Macías
2021-09-29  6:29  1%   ` Uwe Brauer
2021-09-29 20:18     orgmode.org setup Bastien
2021-09-30  4:00     ` Greg Minshall
2021-09-30  5:18       ` Grabbing the link to a message on the archive Timothy
2021-10-01 15:07  4%     ` Max Nikulin
2021-10-01 15:59     export dispatch → change the default "Contents" string Jean-Christophe Helary
2021-10-01 16:35  9% ` Juan Manuel Macías
2021-10-01 16:45  1%   ` Jean-Christophe Helary
2021-10-02 10:48 12% [Question] A single *-language-alist in ox-latex.el? Juan Manuel Macías
2021-10-02 11:08  5% ` Stefan Nobis
2021-10-02 19:20 12%   ` Juan Manuel Macías
2021-10-03 15:28  5% [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists Juan Manuel Macías
2021-10-03 17:39  2% [PATCH] org-manual.org: List the languages supported by smart quotes feature Juan Manuel Macías
2021-10-25 13:56  6% ` Ihor Radchenko
2021-10-04 14:27  8% [patch] ox-html.el: add html attribute (verse numbers) to verse blocks Juan Manuel Macías
2021-10-06 15:18     how to export to odt with 11 or 10 pt fonts? Default font setting Uwe Brauer
2021-10-07 11:24  9% ` Juan Manuel Macías
2021-10-07 12:28  0%   ` Uwe Brauer
2021-10-07 12:58  9%     ` Juan Manuel Macías
2021-10-07 12:59  0%     ` Peter Neilson
2021-10-07 14:57  8% [tip] Go to the org node from the attached directory Juan Manuel Macías
2021-10-09 21:17     how to export to odt with 11 or 10 pt fonts? Default font setting copropriete27ruemoret
2021-10-10  2:52  7% ` Juan Manuel Macías
2021-10-15 16:56  7% [minor tip] "TeXify" strings "TeX" and "LaTeX" when exporting to HTML Juan Manuel Macías
2021-10-18 20:37     Unable to configure emacs 27.2 to use org 9.5 Detlef Steuer
2021-10-18 22:28 13% ` Juan Manuel Macías
2021-10-19  8:32  5%   ` [mostly solved] " Detlef Steuer
2021-10-20 14:57 13% Fancy underlines in Org to LaTeX Juan Manuel Macías
2021-10-22 15:01 10% [tip] Export some footnotes as pdf annotations (LaTeX) or comments (odt) Juan Manuel Macías
2021-10-22 23:27     Sub-figures in Org Mode Jason Ross
2021-10-23  0:00 10% ` Juan Manuel Macías
2021-10-26 17:46  5%   ` Jason Ross
2021-10-30 14:28 10%     ` Juan Manuel Macías
2021-10-24 14:23  9% A quick LaTeX reference guide in Org Juan Manuel Macías
2021-10-24 20:18  6% ` Tim Cross
2021-10-25 11:35 10%   ` Juan Manuel Macías
2021-10-25 12:30  6%     ` Eric S Fraga
2021-10-25 12:58  0%       ` John Hendy
2021-10-25 14:10 10%       ` Juan Manuel Macías
2021-10-25  0:42  7% ` Thomas S. Dye
2021-10-26 16:05  9% [patch] ox-latex.el: add `:options' LaTeX attribute to tables Juan Manuel Macías
2021-10-27  3:44     ` Vikas Rawal
2021-10-27 15:52  7%   ` Juan Manuel Macías
2021-10-28 16:10         ` Vikas Rawal
2021-10-28 18:02  6%       ` Juan Manuel Macías
2021-10-28 19:39 13%         ` Juan Manuel Macías
2021-11-03 16:32  6% ` Nicolas Goaziou
2021-11-03 17:38 10%   ` Juan Manuel Macías
2021-11-03 18:33  6%     ` Nicolas Goaziou
2021-11-04 20:59  6%       ` Juan Manuel Macías
2021-11-06 13:51  6%         ` Nicolas Goaziou
2021-10-30 11:51     Introducing Org-transclusion Noboru Ota
2021-10-30 12:31 10% ` Juan Manuel Macías
2021-11-01  9:17  6%   ` Noboru Ota
2021-11-09 16:25  7% A function to include a PDF with LaTeX commands for specific pages Juan Manuel Macías
2021-11-12 22:35     whitespace in org source files excalamus--- via General discussions about Org-mode.
2021-11-13 12:57 10% ` Juan Manuel Macías
2021-11-14 17:08     Should be possible to export list items emphasized by default? Ypo
2021-11-17 13:33  9% ` Juan Manuel Macías
2021-11-17  7:36     insert automatically a reference to a section header and a link Uwe Brauer
2021-11-17 10:04     ` Eric S Fraga
2021-11-17 13:58       ` Uwe Brauer
2021-11-17 14:06         ` John Kitchin
2021-11-17 14:15           ` Uwe Brauer
2021-11-17 14:59             ` Stefan Nobis
2021-11-17 15:42 10%           ` Juan Manuel Macías
2021-11-17 15:55               ` Uwe Brauer
2021-11-17 16:29                 ` Stefan Nobis
2021-11-17 18:17 10%               ` Juan Manuel Macías
2021-11-17 19:00  6%                 ` Stefan Nobis
2021-11-21 15:36 13% org-critical-edition (new version) Juan Manuel Macías
2021-11-23 16:52  9% Dired images in an Org buffer Juan Manuel Macías
2021-11-28 19:46     "Orgdown", the new name for the syntax of Org-mode Karl Voit
2021-11-28 22:25  8% ` Juan Manuel Macías
2021-11-28 22:57       ` Tom Gillespie
2021-11-28 23:16         ` Joost Kremers
2021-11-29  3:25 10%       ` Juan Manuel Macías
2021-11-29  7:13  5%         ` Dr. Arne Babenhauserheide
2021-11-29  5:41  6%   ` Marcin Borkowski
2021-11-29 12:18  9%     ` Juan Manuel Macías
2021-11-29 12:36  6%       ` Marcin Borkowski
2021-11-28 22:42     ` Tim Cross
2021-11-29 13:19       ` Karl Voit
2021-11-29 18:27         ` M. ‘quintus’ Gülker
2021-11-30 20:44           ` Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode) Karl Voit
2021-12-01  0:41             ` Tom Gillespie
2021-12-01  3:28  9%           ` Orgdown: negative feedback & attempt of a root-cause analysis Juan Manuel Macías
2021-11-30 16:28     how to export red colored TeX to latex Uwe Brauer
2021-11-30 16:56  9% ` Juan Manuel Macías
2021-11-30 17:11       ` Uwe Brauer
2021-11-30 17:43 10%     ` Juan Manuel Macías
2021-12-01  6:28       ` Eric S Fraga
2021-12-01 15:00 10%     ` Juan Manuel Macías
2021-12-01 15:02  6%       ` Eric S Fraga
2021-12-02 10:50     Org-syntax: Intra-word markup Denis Maier
2021-12-02 11:18     ` Ihor Radchenko
2021-12-02 11:30 10%   ` Juan Manuel Macías
2021-12-02 11:36  7%     ` Denis Maier
2021-12-02 11:42         ` Marco Wahl
2021-12-02 11:50           ` Denis Maier
2021-12-02 12:10             ` Ihor Radchenko
2021-12-02 12:40               ` Denis Maier
2021-12-02 12:54                 ` Ihor Radchenko
2021-12-02 13:14  9%               ` Juan Manuel Macías
2021-12-02 13:28  7%                 ` Denis Maier
2021-12-02 12:00  5%     ` Ihor Radchenko
2021-12-02 12:28  0%       ` Denis Maier
2021-12-02 11:58     ` Timothy
2021-12-02 12:26       ` Denis Maier
2021-12-02 13:07         ` Ihor Radchenko
2021-12-02 15:51           ` Max Nikulin
2021-12-02 18:11             ` Tom Gillespie
2021-12-02 19:09  9%           ` Juan Manuel Macías
2021-12-04 13:07  5%             ` Org-syntax: emphasis and not English punctuation Max Nikulin
2021-12-04 16:42  9%               ` Juan Manuel Macías
2021-12-02 19:03           ` Org-syntax: Intra-word markup Nicolas Goaziou
2021-12-02 19:34  9%         ` Juan Manuel Macías
2021-12-02 23:05  6%           ` Nicolas Goaziou
2021-12-02 23:24  9%             ` Juan Manuel Macías
2021-12-03 14:24             ` Max Nikulin
2021-12-03 15:01  9%           ` Juan Manuel Macías
2021-12-04 15:57               ` Denis Maier
2021-12-04 17:53                 ` Tom Gillespie
2021-12-04 18:37                   ` John Kitchin
2021-12-04 21:16  9%                 ` Juan Manuel Macías
2021-12-06 10:57                     ` Raw Org AST snippets for "impossible" markup Max Nikulin
2021-12-06 15:45  8%                   ` Juan Manuel Macías
2021-12-06 16:56 13%                     ` Juan Manuel Macías
2021-12-08 13:09  4%                     ` Max Nikulin
2021-12-08 23:19  9%                       ` Juan Manuel Macías
2021-12-08 23:35  6%                         ` John Kitchin
2021-12-09  7:01  5%                           ` Juan Manuel Macías
2021-12-09 14:56  5%                             ` Max Nikulin
2021-12-09 16:11  6%                               ` Juan Manuel Macías
2021-12-09 22:27 12%                                 ` Juan Manuel Macías
2022-01-03 14:34  4%                                   ` Max Nikulin
2021-12-03 12:48  8% On zero width spaces and Org syntax Juan Manuel Macías
2021-12-03 19:03     ` Greg Minshall
2021-12-03 20:30  9%   ` Juan Manuel Macías
2021-12-03 21:48  3% ` Tim Cross
2021-12-04  1:26  6%   ` Juan Manuel Macías
2021-12-04  4:04         ` Tom Gillespie
2021-12-04  5:29  5%       ` Juan Manuel Macías
2021-12-04  6:43  5% ` Marcin Borkowski
2021-12-05  7:35     Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal Ihor Radchenko
2021-12-05  9:16  9% ` Juan Manuel Macías
2021-12-05 10:24  5%   ` Ihor Radchenko
2021-12-05 11:08  9%     ` Juan Manuel Macías
2021-12-05 11:54  6%       ` Heinz Tuechler
2021-12-05 12:08  3%       ` Ihor Radchenko
2021-12-05 13:32  0%         ` Tim Cross
2021-12-05 18:59  7%         ` Juan Manuel Macías
2021-12-05 23:24  4%           ` Russell Adams
2021-12-06  5:57 10%             ` Juan Manuel Macías
2021-12-06  6:02                   ` Timothy
2021-12-06  7:24  9%                 ` Juan Manuel Macías
2021-12-06 10:04                       ` Greg Minshall
2021-12-06 14:59  9%                     ` Juan Manuel Macías
2021-12-05 13:06  4%   ` Tim Cross
2021-12-08 20:03 12% Making a dictionary in Org Juan Manuel Macías
2021-12-08 23:13  6% ` Thomas S. Dye
2021-12-16  5:16     format/fill of text in a cell in tables George Michaelson
2021-12-16  9:45     ` Ihor Radchenko
2021-12-16 21:51       ` Tim Cross
2021-12-17  8:23         ` tomas
2021-12-17 12:11           ` Tim Cross
2021-12-17 18:46             ` tomas
2021-12-17 21:25  6%           ` Juan Manuel Macías
2021-12-18  7:27         ` Uwe Brauer
2021-12-18 11:09  8%       ` Juan Manuel Macías
2021-12-23 16:11     text after sub headings? Robert Nikander
2021-12-23 20:27  8% ` Juan Manuel Macías
2021-12-24 16:51  4%   ` Max Nikulin
2021-12-24 20:17  5%     ` Juan Manuel Macías
2021-12-25 13:15  4%       ` Max Nikulin
2021-12-26  9:17  8%         ` Juan Manuel Macías
2021-12-23 21:21  5% Robert Nikander
2021-12-23 21:47  0% ` John Kitchin
2021-12-23 22:10  6% ` Juan Manuel Macías
2021-12-27  1:22     caption width in LateX export Seb
2021-12-27  7:41 10% ` Juan Manuel Macías
2021-12-27  9:09 12%   ` Juan Manuel Macías
2021-12-27 12:53  6%   ` Sebastian P. Luque
2021-12-27 13:28  8%     ` Juan Manuel Macías
2021-12-27 17:16  6%       ` Sebastian P. Luque
2021-12-27 19:28  5%         ` Juan Manuel Macías
2021-12-31 10:14 10% [BUG] Underlined text in parentheses is not exported correctly Juan Manuel Macías
2021-12-31 11:08 12% ` Juan Manuel Macías
2021-12-31 11:13  5% ` Ihor Radchenko
2021-12-31 11:31 10%   ` Juan Manuel Macías
2021-12-31 14:43  4%     ` [PATCH] " Ihor Radchenko
2022-01-01 11:28 10%       ` Juan Manuel Macías
2022-01-04 10:14  9% A simple Lua filter for Pandoc Juan Manuel Macías
2022-01-04 11:26     ` Timothy
2022-01-04 15:11 10%   ` Juan Manuel Macías
2022-01-04 14:05  6% ` Max Nikulin

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).