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: inline-special-block: export rules
  2024-03-21 10:26  5%                                       ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
@ 2024-03-26 16:56  6%                                         ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2024-03-26 16:56 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: emacs-orgmode

On 21/03/2024 17:26, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> I am afraid that :export will cause confusion with :exports for source
>> code blocks. Its name differs by just "s" but possible values have
>> nothing common.
> 
> I agree. At the moment two alternative names come to mind: :backends or
> :export-rules

I find :export-rules too abstract. Unless a better name is proposed, I 
prefer :backends.

> :export [or whatever new name we give it] ==> normal behavior, overwrites the values
> :export+ ==> adds the new values to the values defined in the alias

Vim for options allowing list of values has several options
:set opt=value1,value2 " assign new value
:set opt+=value " add to list
:set opt-=value " remove from list if it is there
:set opt& " reset to default value
I am unsure whether all variants should be implemented.

> This syntax could also be extended to other cases. Perhaps we want
> attributes like :prelatex, :postlatex, or :html to support accumulating
> values.

Certainly :export (:backends) is not the only property that should 
accumulate values.



^ permalink raw reply	[relevance 6%]

* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
  2024-03-23 15:42  6%       ` Juan Manuel Macías
@ 2024-03-24  9:55  6%         ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-03-24  9:55 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Anyway, I think a) your patch could be a major improvement;

Applied, onto main, after fixing another edge case with quotes spanning
across multiple markup objects.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=33503445e

> ... b) perhaps a
> brief note in the manual (I can send a tiny patch) should be added to
> warn of possible ambiguities, and possible solutions.

Yes, a patch clarifying what to do to force apostrophe would be welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
  2024-03-23 13:49  6%     ` Ihor Radchenko
@ 2024-03-23 15:42  6%       ` Juan Manuel Macías
  2024-03-24  9:55  6%         ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-23 15:42 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> We may introduce \apostrophe entity.
>
> "two articles: 'my friends\apostrophe party' and 'the students\apostrophe papers'"
>
> "A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"

It's not a bad idea to use entities. I just discovered that an \rsquo
entity already exists. Right single quotation mark is the Unicode
recommended character for the apostrophe, and it is also the character
used in org-export-smart-quotes-alist[1].

Anyway, I think a) your patch could be a major improvement; b) perhaps a
brief note in the manual (I can send a tiny patch) should be added to
warn of possible ambiguities, and possible solutions.

[1] Although there are arguments against this Unicode recommendation,
see: https://en.wikipedia.org/wiki/Right_single_quotation_mark


^ permalink raw reply	[relevance 6%]

* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
  2024-03-23 13:41  6%   ` Juan Manuel Macías
@ 2024-03-23 13:49  6%     ` Ihor Radchenko
  2024-03-23 15:42  6%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-03-23 13:49 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> The patch works fine, and I think it can prevent a lot of cases. But
> false positives can still appear. Consider (second level quotes open
> after the colon):
>
> "two articles: 'my friends' party' and 'the students' papers'"
>
> "A Greek folk song says: 'να 'ρθώ το βράδυ'"
>
> ==>
>
> \guillemotleft{}two articles: ``my friends'' party' and ``the students'' papers'\guillemotright{}
>
> \guillemotleft{}A Greek folk song says: 'να ``ρθώ το βράδυ''\guillemotright{}

These are not false-positives, but ambiguity. There is no deterministic
way in this scenario to distinguish between apostrophe and smart quotes.

> I think the only solution here would be to introduce a Unicode
> apostrophe (’). Or allow an optional, alternative character for
> second-level quotes:
>
> "... `my friends' party` ..."

We may introduce \apostrophe entity.

"two articles: 'my friends\apostrophe party' and 'the students\apostrophe papers'"

"A Greek folk song says: \apostrophe{}να \apostrophe{}ρθώ το βράδυ'"

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
  2024-03-23 11:38  5% ` Ihor Radchenko
@ 2024-03-23 13:41  6%   ` Juan Manuel Macías
  2024-03-23 13:49  6%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-23 13:41 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>>   #+OPTIONS: ':t
>>   #+language:es
>>
>>   "my friends' party and the students' papers"
>>   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>>
>> the above produces in LaTeX:
>>
>>   \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
>> ...
>> Perhaps a possible solution would be to allow the use of a specific,
>> customizable character, other than an apostrophe, for second-level
>> quotes. Or at least add some brief warning in the manual: in certain
>> contexts it is safer to use a explicit Unicode character for the
>> apostrophe.
>
> I think that we can address examples like this simply by not replacing
> unbalanced quotes. There is already some effort in the code towards such
> treatment, but it is not complete.
>
> Can you try the attached patch?

Hi, Ihor,

The patch works fine, and I think it can prevent a lot of cases. But
false positives can still appear. Consider (second level quotes open
after the colon):

"two articles: 'my friends' party' and 'the students' papers'"

"A Greek folk song says: 'να 'ρθώ το βράδυ'"

==>

\guillemotleft{}two articles: ``my friends'' party' and ``the students'' papers'\guillemotright{}

\guillemotleft{}A Greek folk song says: 'να ``ρθώ το βράδυ''\guillemotright{}

I think the only solution here would be to introduce a Unicode
apostrophe (’). Or allow an optional, alternative character for
second-level quotes:

"... `my friends' party` ..."

^ permalink raw reply	[relevance 6%]

* Re: [bug] Smart quotes: confusion of apostrophe with second level quotes
  2024-03-22  1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes Juan Manuel Macías
@ 2024-03-23 11:38  5% ` Ihor Radchenko
  2024-03-23 13:41  6%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-03-23 11:38 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

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

>   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>   #+OPTIONS: ':t
>   #+language:es
>
>   "my friends' party and the students' papers"
>   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
> the above produces in LaTeX:
>
>   \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}
> ...
> Perhaps a possible solution would be to allow the use of a specific,
> customizable character, other than an apostrophe, for second-level
> quotes. Or at least add some brief warning in the manual: in certain
> contexts it is safer to use a explicit Unicode character for the
> apostrophe.

I think that we can address examples like this simply by not replacing
unbalanced quotes. There is already some effort in the code towards such
treatment, but it is not complete.

Can you try the attached patch?


[-- Attachment #2: 0001-org-export-Do-not-treat-unpaired-and-as-smart-quotes.patch --]
[-- Type: text/x-patch, Size: 5726 bytes --]

From 4a034fbb0029ca7e635f629810a6179df4ca24d9 Mon Sep 17 00:00:00 2001
Message-ID: <4a034fbb0029ca7e635f629810a6179df4ca24d9.1711193777.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sat, 23 Mar 2024 14:34:06 +0300
Subject: [PATCH] org-export: Do not treat unpaired ' and " as smart quotes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox.el (org-export--smart-quote-status): When quotes are not
balanced, treat " literally and ' as apostrophes.
* testing/lisp/test-ox.el (test-org-export/activate-smart-quotes): Fix
test with unbalanced " and add new tests for unbalanced quotes.

Reported-by: Juan Manuel Macías <maciaschain@posteo.net>
Link: https://list.orgmode.org/orgmode/875xxfqdpt.fsf@posteo.net/
---
 lisp/ox.el              | 45 +++++++++++++++++++++++++++++++++++++++++
 testing/lisp/test-ox.el | 29 ++++++++++++++++++++++++--
 2 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 929b306dc..539d31d9d 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5942,6 +5942,51 @@ (defun org-export--smart-quote-status (s info)
 	      (when current-status
 		(push (cons text (nreverse current-status)) full-status))))
 	  info nil org-element-recursive-objects)
+        ;; When quotes are not balanced, threat them as apostrophes.
+        (setq full-status (nreverse full-status))
+        (let (primary-openings secondary-openings)
+          (dolist (substatus full-status)
+            (let ((status (cdr substatus)))
+              (while status
+                (pcase (car status)
+                  (`apostrophe nil)
+                  (`primary-opening
+                   (push status primary-openings))
+                  (`secondary-opening
+                   (push status secondary-openings))
+                  (`secondary-closing
+                   (if secondary-openings
+                       ;; Remove matched opening.
+                       (pop secondary-openings)
+                     ;; No matching openings for a given closing.  Replace
+                     ;; it with apostrophe.
+                     (setcar status 'apostrophe)))
+                  (`primary-closing
+                   (when secondary-openings
+                     ;; Some secondary opening quotes are not closed
+                     ;; within "...".  Replace them all with apostrophes.
+                     (dolist (opening secondary-openings)
+                       (setcar opening 'apostrophe))
+                     (setq secondary-openings nil))
+                   (if primary-openings
+                       ;; Remove matched opening.
+                       (pop primary-openings)
+                     ;; No matching openings for a given closing.
+                     (error "This should no happen"))))
+                (setq status (cdr status)))))
+          (when primary-openings
+            ;; Trailing unclosed "
+            (unless (= 1 (length primary-openings))
+              (error "This should not happen"))
+            ;; Mark for not replacing.
+            (setcar (car primary-openings) nil)
+            ;; Mark all the secondary openings and closings after
+            ;; trailing unclosed " as apostrophes.
+            (let ((tail (car primary-openings)))
+              (while tail
+                (when (memq (car tail) '(secondary-opening secondary-closing))
+                  (setcar tail 'apostrophe))
+                (setq tail (cdr tail))))))
 	(puthash (cons parent (org-element-secondary-p s)) full-status cache)
 	(cdr (assq s full-status))))))
 
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 01e082c9b..16e81c64b 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -4134,9 +4134,9 @@ (ert-deftest test-org-export/activate-smart-quotes ()
   ;; Opening quotes: at the beginning of a paragraph.
   (should
    (equal
-    '("&ldquo;begin")
+    '("&ldquo;begin&rdquo;")
     (let ((org-export-default-language "en"))
-      (org-test-with-parsed-data "\"begin"
+      (org-test-with-parsed-data "\"begin\""
 	(org-element-map tree 'plain-text
 	  (lambda (s) (org-export-activate-smart-quotes s :html info))
 	  info)))))
@@ -4267,6 +4267,31 @@ (ert-deftest test-org-export/activate-smart-quotes ()
 	    (org-test-with-parsed-data "*\"foo\"*"
 	      (org-element-map tree 'plain-text
 		(lambda (s) (org-export-activate-smart-quotes s :html info))
+		info nil nil t)))))
+  ;; Unmatched quotes.
+  (should
+   (equal '("\\guillemotleft{}my friends' party and the students' papers\\guillemotright{} \\guillemotleft{}``mothers''\\guillemotright{}")
+	  (let ((org-export-default-language "es"))
+	    (org-test-with-parsed-data
+                "\"my friends' party and the students' papers\" \"'mothers'\""
+	      (org-element-map tree 'plain-text
+		(lambda (s) (org-export-activate-smart-quotes s :latex info))
+		info nil nil t)))))
+  (should
+   (equal '("\"'mothers'")
+	  (let ((org-export-default-language "es"))
+	    (org-test-with-parsed-data
+                "\"'mothers'"
+	      (org-element-map tree 'plain-text
+		(lambda (s) (org-export-activate-smart-quotes s :latex info))
+		info nil nil t)))))
+  (should
+   (equal '("\\guillemotleft{}να 'ρθώ το βράδυ\\guillemotright{}")
+	  (let ((org-export-default-language "el"))
+	    (org-test-with-parsed-data
+                "\"να 'ρθώ το βράδυ\""
+	      (org-element-map tree 'plain-text
+		(lambda (s) (org-export-activate-smart-quotes s :latex info))
 		info nil nil t))))))
 
 
-- 
2.44.0


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

^ permalink raw reply related	[relevance 5%]

* [bug] Smart quotes: confusion of apostrophe with second level quotes
@ 2024-03-22  1:04 11% Juan Manuel Macías
  2024-03-23 11:38  5% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-22  1:04 UTC (permalink / raw)
  To: orgmode

Hi,

I don't know if this is a known issue, but I haven't been able to find
any mention of it. I think this is partly because in English it can go
perfectly unnoticed, since for English the values of secondary-closing
and apostrophe are identical:

  (secondary-closing :utf-8 "’" :html "&rsquo;" :latex "'" :texinfo "'")
  (apostrophe :utf-8 "’" :html "&rsquo;")

However, consider the following example:

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  #+OPTIONS: ':t
  #+language:es

  "my friends' party and the students' papers"
  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

the above produces in LaTeX:

  \guillemotleft{}my friends'' party and the students'' papers\guillemotright{}

In Spanish, as in other similar cases, the issue is easier to reproduce
because:

  (secondary-closing :utf-8 "”" :html "&rdquo;" :latex "''" :texinfo "''")
  (apostrophe :utf-8 "’" :html "&rsquo;")

I don't know whether to consider this a bug or a limitation in the
current implementation, originating from how Org interprets an
apostrophe. Although I suspect it has a difficult solution: how to
differentiate an apostrophe from a second-level quote in certain
scenarios, when the approach seems to be essentially heuristic? Let us
also consider cases in which the apostrophe can be placed at the
beginning of a word, as in Greek:

  "να 'ρθώ το βράδυ"

(Org would confuse the apostrophe in the word 'ρθώ with second-level
opening quotes)

Perhaps a possible solution would be to allow the use of a specific,
customizable character, other than an apostrophe, for second-level
quotes. Or at least add some brief warning in the manual: in certain
contexts it is safer to use a explicit Unicode character for the
apostrophe.

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 11%]

* inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks)
  2024-03-19 14:54  3%                                     ` Max Nikulin
  2024-03-19 17:47  6%                                       ` Juan Manuel Macías
@ 2024-03-21 10:26  5%                                       ` Juan Manuel Macías
  2024-03-26 16:56  6%                                         ` inline-special-block: export rules Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-21 10:26 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> I am afraid that :export will cause confusion with :exports for source 
> code blocks. Its name differs by just "s" but possible values have 
> nothing common.

I agree. At the moment two alternative names come to mind: :backends or
:export-rules

> Another issue is more general and should apply e.g. to HTML attributes 
> as well. Consider
>
> --- 8< ---
>
> #+options: inline-special-block-aliases:(("kbd" :export "html*" 
> :html-tag kbd))
>
> @kbd{Default} and @kbd[:export "latex*"]{LaTeX}
> --- >8 ---
>
> It exports to
>
>      <p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>
>
> I would expect that "html*" is inherited from the parent declaration and 
> "latex*" does not override it, so
>
>      <p>\nDefault and LaTeX</p>

But it is the expected result in all attributes. If an attribute of the
same type as the one declared in the alias is added, the value is
overwritten.

In any case, since in this case the attribute allows cumulative values,
I think the approach should be at the level of the attribute name itself
and not the code to manage the export rules. For example:

:export [or whatever new name we give it] ==> normal behavior, overwrites the values

:export+ ==> adds the new values to the values defined in the alias

This syntax could also be extended to other cases. Perhaps we want
attributes like :prelatex, :postlatex, or :html to support accumulating
values. It could be easily solved from the functions of each backend. In
other cases, of course, it wouldn't make sense (a block can't have two
languages at the same time), but in that scenario, if someone puts
:lang+, it simply wouldn't be taken into account. Wdyt?



^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-19 14:54  3%                                     ` Max Nikulin
@ 2024-03-19 17:47  6%                                       ` Juan Manuel Macías
  2024-03-21 10:26  5%                                       ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-19 17:47 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> Would you mind against new thread as an umbrella for next bunch of 
> topics? Current one becomes too large from my point of view.

Ok, I agree. I suggest that from now any new thread related to the new
object have as subject:

"inline-special-block: specific topic to discuss".

Tomorrow I will try to answer all the latest questions related to the
export rules.


^ permalink raw reply	[relevance 6%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-18 19:42  6%                                   ` Juan Manuel Macías
@ 2024-03-19 14:54  3%                                     ` Max Nikulin
  2024-03-19 17:47  6%                                       ` Juan Manuel Macías
  2024-03-21 10:26  5%                                       ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2024-03-19 14:54 UTC (permalink / raw)
  To: emacs-orgmode

On 19/03/2024 02:42, Juan Manuel Macías wrote:
> As I mentioned in a past email, these days I will be somewhat busy, but
> I will try to keep up to date with your comments. Although it may take a
> while to respond.

Would you mind against new thread as an umbrella for next bunch of 
topics? Current one becomes too large from my point of view.

For a while a couple of questions related to :export to think on.

I am afraid that :export will cause confusion with :exports for source 
code blocks. Its name differs by just "s" but possible values have 
nothing common.

Another issue is more general and should apply e.g. to HTML attributes 
as well. Consider

--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*" 
:html-tag kbd))
@kbd{Default} and @kbd[:export "latex*"]{LaTeX}
--- >8 ---

It exports to

     <p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>

I would expect that "html*" is inherited from the parent declaration and 
"latex*" does not override it, so

     <p>\nDefault and LaTeX</p>

On the other hand it should be possible to specify that declared earlier 
rules should be taken into consideration. E.g. "#" might stop further 
processing:

--- 8< ---
#+options: inline-special-block-aliases:(("kbd" :export "html*" 
:html-tag kbd))
@kbd{Default} and @kbd[:export "latex* #"]{LaTeX}
--- >8 ---

makes

     <p>\nDefault and <kbd class="kbd">LaTeX</kbd></p>

result valid.

In the meanwhile I have realized that there is no point in the list of 
parsed rules. You may consider code organized in a bit different way. I 
hope, just a single extra line in these helpers is required to support "#".

(defun org-export--parse-export-rule
     (spec)
   (and (string-match
 
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
         spec)
        (let ((name (match-string 1 spec))
              (inherit (or (match-string 3 spec)
                           (match-string 4 spec)))
              (what (or (match-string 2 spec)
                        (match-string 5 spec))))
	 (cons
           (if (string-equal "" name) '@ (intern name))
           (cons (or (not inherit) (string-equal inherit "="))
                 (pcase (and what (string-to-char what))
                   ((or ?+ (pred null)) 'full)
                   (?* 'content)
                   (?/ nil)))))))
;; (org-export--parse-export-rule "html+=")

(defun org-export--backend-hierarchy (backend)
   "Result may be cached in INFO."
   (let ((hierarchy))
     (when (not (symbolp backend))
       (setq backend (org-export-backend-name backend)))
     (while backend
       (push backend hierarchy)
       (setq backend (org-export-backend-parent
                      (org-export-get-backend backend))))
     hierarchy))
;; (org-export--backend-hierarchy 'md)

(defun org-export--inline-special-block-export-decision
     (spec-list hierarchy &optional default-rule)
   "Returns (backend inherit . what).
so use `cddr' to get decision."
   (let ((decision '(@ t . full))
         (hierarchy (cons '@ hierarchy)))
     (while (and hierarchy spec-list)
       (let* ((rule (org-export--parse-export-rule (pop spec-list)))
              (tail (and rule (memq (car rule) hierarchy))))
         (if (not rule)
	    (message "invalid :export specification %S" (car spec-list)))
         (when (and tail
                    (or (not (cdr tail)) ; Current backend.
                        (cadr rule))) ; Inherits.
           (setq hierarchy (cdr tail))
           (setq decision rule))))
     (if (and default-rule (memq (car default-rule) hierarchy))
         default-rule
       decision)))

----

(ignore
  (pp
   (let ((rules (org-split-string "latex/ html./ html+= ascii+ *")))
     (mapcar (lambda (backend)
               (let ((hierarchy
                      (org-export--backend-hierarchy backend)))
                 (list backend
                       (cddr
                        (org-export--inline-special-block-export-decision
                         rules hierarchy)))))
             '(odt latex beamer html md ascii)))))

((odt content)
  (latex nil)
  (beamer nil)
  (html nil)
  (md full)
  (ascii full))




^ permalink raw reply	[relevance 3%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-16 14:07  4%                                 ` Max Nikulin
@ 2024-03-18 19:42  6%                                   ` Juan Manuel Macías
  2024-03-19 14:54  3%                                     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-18 19:42 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> An update with a couple of bugs fixed. Now it is possible to specify
> different export rules for a backend and all its derivatives:

I have implemented your code in the last commit. I think it is a great
improvement, thanks a lot.

As I mentioned in a past email, these days I will be somewhat busy, but
I will try to keep up to date with your comments. Although it may take a
while to respond.


^ permalink raw reply	[relevance 6%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-15 16:26 12%                               ` Juan Manuel Macías
@ 2024-03-16 14:07  4%                                 ` Max Nikulin
  2024-03-18 19:42  6%                                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-16 14:07 UTC (permalink / raw)
  To: emacs-orgmode

On 15/03/2024 23:26, Juan Manuel Macías wrote:
> Tomorrow I will make a new commit with your code.

An update with a couple of bugs fixed. Now it is possible to specify 
different export rules for a backend and all its derivatives:

(ignore
  (pp
   (let ((rules
          (org-export--inline-special-block-make-backend-list
           (org-split-string "latex/ html./ html+= ascii+ *"))))
     (mapcar (lambda (backend)
               (let ((hierarchy
                      (org-export--backend-hierarchy backend)))
                 (list backend
                       (org-export--inline-special-block-export-decision
                        rules hierarchy))))
             '(odt latex beamer html md ascii)))))

((odt content)
  (latex nil)
  (beamer nil)
  (html nil)
  (md full)
  (ascii full))

----

(defun org-export--inline-special-block-make-backend-list
     (rules)
   (let (result)
     (dolist (spec rules)
       (if (string-match
 
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\([=.]\\)?\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
            spec)
           (let ((name (match-string 1 spec))
                 (inherit (or (match-string 3 spec)
                              (match-string 4 spec)))
                 (what (or (match-string 2 spec)
                           (match-string 5 spec))))
	    (push (cons
                    (if (string-equal "" name) '@ (intern name))
                    (cons (or (not inherit) (string-equal inherit "="))
                          (if what (string-to-char what) ?+)))
		  result))
	(message "invalid :export specification %S" spec)))
     (nreverse result)))

(defun org-export--backend-hierarchy (backend)
   "Result may be cached in INFO."
   (let ((hierarchy))
     (when (not (symbolp backend))
       (setq backend (org-export-backend-name backend)))
     (while backend
       (push backend hierarchy)
       (setq backend (org-export-backend-parent
                      (org-export-get-backend backend))))
     hierarchy))

(defun org-export--inline-special-block-export-decision
     (rule-list hierarchy)
   (let ((hierarchy (cons '@ hierarchy))
         (decision ?+))
     (while (and hierarchy rule-list)
       (let* ((rule (pop rule-list))
              (tail (memq (car rule) hierarchy)))
         (when (and tail
                    (or (not (cdr tail)) ; Current backend.
                        (cadr rule))) ; Inherits.
           (setq hierarchy (cdr tail))
           (setq decision (cddr rule)))))
     (pcase decision
       (?+ 'full)
       (?* 'content)
       (?/ nil)
       (_ 'full))))




^ permalink raw reply	[relevance 4%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-15 13:10  5%                               ` Juan Manuel Macías
@ 2024-03-15 17:21  5%                                 ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2024-03-15 17:21 UTC (permalink / raw)
  To: emacs-orgmode

On 15/03/2024 20:10, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>
>> 1. "-" is a valid backend name and valid last character of backend name
> 
> I had not thought of it. Can + also be a valid character?

https://orgmode.org/worg/org-syntax.html#Affiliated_Keywords
BACKEND
     A string consisting of alphanumeric characters, hyphens, or 
underscores (-_).

>> 2. From the description it is not clear to me what is effect of "rest"
>> specified for more than one backend.
> 
> 'rest' (=) is equivalent to the rest of the backends that have not been
> explicitly set. What happens is that, with my current approach, if you
> want to export only one backend, you must enter:
> 
> :export backend =- (that is, export this backend and not the rest)

At first I thought it may be used as [:export backend=-] and it is the 
reason why I was confused. However I still do not see difference between 
[:export backend -] and [:export backend =-].

> This is not ideal. It should be enough to just put:
> 
> :export backend
> 
> but I am not able to achieve it.

I agree, it is intuitive, but it makes formal rules more complicated.

>    = full, this and derived backends (default)

I would prefer to modify code to handle
[:export latex.+ latex=/]
to apply first declaration (content only) to latex and second one (skip) 
to derived backends. Anyway the code requires optimization. Walk through 
parent backends is likely inefficient.

> These days I'm going to be a little short on time, due to work, and I
> don't know if I'll be able to attend to the list.

Then I will postpone other questions (mostly unrelated to :export).



^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-15 10:52  4%                             ` Max Nikulin
  2024-03-15 13:10  5%                               ` Juan Manuel Macías
@ 2024-03-15 16:26 12%                               ` Juan Manuel Macías
  2024-03-16 14:07  4%                                 ` Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-15 16:26 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> (ignore
>  (pp
>   (let ((rules
>          (org-export--inline-special-block-make-backend-alist
>           (org-split-string "latex/ html./ ascii+ *"))))
>     (mapcar (lambda (backend)
>               (list backend
>                     (org-export--inline-special-block-export-decision
>                     rules backend)))
>             '(odt latex beamer html md ascii)))))
>
> Gives
>
> ((odt content)
>  (latex nil)
>  (beamer nil)
>  (html nil)
>  (md content)
>  (ascii full))
>
> Function definitions:
>
> (defun org-export--inline-special-block-make-backend-alist
>     (rules)
>   (nconc
>    (let (result)
>      (dolist (spec rules)
>        (if (string-match
>
> "\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
>             spec)
>            (let ((name (match-string 1 spec))
>                  (inherit (match-string 3 spec))
>                  (what (or (match-string 2 spec)
>                            (match-string 4 spec))))
> 	     (push (cons
>                     (if (string-equal "" name) '@ (intern name))
>                     (cons (or (not inherit) (string-equal inherit "="))
>                           (if what (string-to-char what) ?+)))
> 		   result))
> 	 (message "invalid :export specification %S" spec)))
>      result)))
>
> (defun org-export--inline-special-block-export-decision
>     (rules-alist backend)
>   (when (symbolp backend)
>     (setq backend (org-export-get-backend backend)))
>   (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
> 	 (decision (and rule (cddr rule))))
>     (while (and (not decision)
> 		(setq backend (org-export-backend-parent backend)))
>       (setq backend (org-export-get-backend backend))
>       (when (and (setq rule (assq (org-export-backend-name backend)
>       rules-alist))
>                  rule
>                  (cadr rule))
>         (setq decision (cddr rule))))
>     (unless decision
>       (setq rule  (assq '@ rules-alist))
>       (setq decision (and rule (cddr rule))))
>     (pcase decision
>       (?+ 'full)
>       (?* 'content)
>       (?/ nil)
>       (_ 'full))))

I've been testing your code and it works very well. It is certainly
finer than the current approach. I think it could be implemented, and we
are testing that.

Tomorrow I will make a new commit with your code.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-15 10:52  4%                             ` Max Nikulin
@ 2024-03-15 13:10  5%                               ` Juan Manuel Macías
  2024-03-15 17:21  5%                                 ` Max Nikulin
  2024-03-15 16:26 12%                               ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-15 13:10 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Thank you for your comments.

Max Nikulin writes:

> On 15/03/2024 09:19, Juan Manuel Macías wrote:
>> The attribute supports one or more elements separated by a space. Each
>> element can be any of the following signs: "*" (export only the
>> content), "-" (do not export), "=" (export the rest normally), "=*"
>> (export the rest, but only the content), "=-" (do not export the rest).
>> Additionally, backend names can be given explicitly, alone or
>> accompanied by the "*" or "-" signs, that is (where "backend" equals the
>> name of the backend):
>
> 1. "-" is a valid backend name and valid last character of backend name

I had not thought of it. Can + also be a valid character? 

> 2. From the description it is not clear to me what is effect of "rest"
> specified for more than one backend.

'rest' (=) is equivalent to the rest of the backends that have not been
explicitly set. What happens is that, with my current approach, if you
want to export only one backend, you must enter:

:export backend =- (that is, export this backend and not the rest)

This is not ideal. It should be enough to just put:

:export backend

but I am not able to achieve it.

> I have had into the code. I would expect something like the following
> (characters may be changed, the code is not heavily tested). Two
> characters from the following groups may be appended to backend name:
>
> + full (default)
> * content
> / skip
> (these ones may be used without backed name to specify fallback action)
>
> = this and derived backends (default)
> . this, but not derived backends
> Perhaps it is necessary to add possibility that
> these rules may coexist (use loop instead of assoc)

OK. How about the following?

- Single characters (they affect everything, if backend name is not
  specified, or the rest, if backend name is specified:
  
  * content
  / skip
  . never export derived backends
  = full, this and derived backends (default)

- And in combination with backend names (some examples):

  :export latex* > content to LaTeX, normal to the rest
  
  :export latex/ > do not export to LaTeX

  :export latex. > do not export to LaTeX derived backends

  :export latex . > export normally to LaTeX but do not export the derived backends in the rest of the cases

  etc.

These days I'm going to be a little short on time, due to work, and I
don't know if I'll be able to attend to the list. I want to calmly take
a look at the code you share.


^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-15  2:19  5%                           ` Juan Manuel Macías
@ 2024-03-15 10:52  4%                             ` Max Nikulin
  2024-03-15 13:10  5%                               ` Juan Manuel Macías
  2024-03-15 16:26 12%                               ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2024-03-15 10:52 UTC (permalink / raw)
  To: emacs-orgmode

On 15/03/2024 09:19, Juan Manuel Macías wrote:
> The attribute supports one or more elements separated by a space. Each
> element can be any of the following signs: "*" (export only the
> content), "-" (do not export), "=" (export the rest normally), "=*"
> (export the rest, but only the content), "=-" (do not export the rest).
> Additionally, backend names can be given explicitly, alone or
> accompanied by the "*" or "-" signs, that is (where "backend" equals the
> name of the backend):

1. "-" is a valid backend name and valid last character of backend name
2. From the description it is not clear to me what is effect of "rest" 
specified for more than one backend.

I have had into the code. I would expect something like the following 
(characters may be changed, the code is not heavily tested). Two 
characters from the following groups may be appended to backend name:

+ full (default)
* content
/ skip
(these ones may be used without backed name to specify fallback action)

= this and derived backends (default)
. this, but not derived backends
Perhaps it is necessary to add possibility that
these rules may coexist (use loop instead of assoc)

(ignore
  (pp
   (let ((rules
          (org-export--inline-special-block-make-backend-alist
           (org-split-string "latex/ html./ ascii+ *"))))
     (mapcar (lambda (backend)
               (list backend
                     (org-export--inline-special-block-export-decision 
rules backend)))
             '(odt latex beamer html md ascii)))))

Gives

((odt content)
  (latex nil)
  (beamer nil)
  (html nil)
  (md content)
  (ascii full))

Function definitions:

(defun org-export--inline-special-block-make-backend-alist
     (rules)
   (nconc
    (let (result)
      (dolist (spec rules)
        (if (string-match
 
"\\`\\([-_a-zA-Z0-9]*\\)\\(?:\\([/+*]\\)\\|\\([=.]\\)\\([/+*]\\)?\\)?\\'"
             spec)
            (let ((name (match-string 1 spec))
                  (inherit (match-string 3 spec))
                  (what (or (match-string 2 spec)
                            (match-string 4 spec))))
	     (push (cons
                     (if (string-equal "" name) '@ (intern name))
                     (cons (or (not inherit) (string-equal inherit "="))
                           (if what (string-to-char what) ?+)))
		   result))
	 (message "invalid :export specification %S" spec)))
      result)))

(defun org-export--inline-special-block-export-decision
     (rules-alist backend)
   (when (symbolp backend)
     (setq backend (org-export-get-backend backend)))
   (let* ((rule (assoc (org-export-backend-name backend) rules-alist))
	 (decision (and rule (cddr rule))))
     (while (and (not decision)
		(setq backend (org-export-backend-parent backend)))
       (setq backend (org-export-get-backend backend))
       (when (and (setq rule (assq (org-export-backend-name backend) 
rules-alist))
                  rule
                  (cadr rule))
         (setq decision (cddr rule))))
     (unless decision
       (setq rule  (assq '@ rules-alist))
       (setq decision (and rule (cddr rule))))
     (pcase decision
       (?+ 'full)
       (?* 'content)
       (?/ nil)
       (_ 'full))))



^ permalink raw reply	[relevance 4%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-13 17:16 14%                         ` Juan Manuel Macías
@ 2024-03-15  2:19  5%                           ` Juan Manuel Macías
  2024-03-15 10:52  4%                             ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-15  2:19 UTC (permalink / raw)
  To: orgmode

To summarize the latest improvements and modifications to the `:export'
attribute...

The attribute supports one or more elements separated by a space. Each
element can be any of the following signs: "*" (export only the
content), "-" (do not export), "=" (export the rest normally), "=*"
(export the rest, but only the content), "=-" (do not export the rest).
Additionally, backend names can be given explicitly, alone or
accompanied by the "*" or "-" signs, that is (where "backend" equals the
name of the backend):

  backend: export normally for that backend and its derived backends;

  backend-: do not export for that backend or its derived backends.

  backend*: export only the content for that backend and its derived
  backends.

Some examples with valid combinations:

@foo[:export *]{lorem ipsum}

==> export only the content

@foo[:export -]{lorem ipsum}

==> do not export

@foo[:export latex-]{lorem ipsum}

==> do not export to LaTeX

@foo[:export latex- html* =]{lorem ipsum}

==> do not export to LaTeX, export only the content to html and export the
rest normally.

@foo[:export latex =*]{lorem ipsum}

==> export normally to LaTeX but export only the content to the rest

@foo[:export latex =-]{lorem ipsum}

==> export normally to LaTeX and not export to the rest

And below is a complete example based on a possible use case that Max
had exposed:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 To see a demo of the Fairlight CMI, watch @@[:export html =-]{this
 video} @@[:export
 html-]{[[https://www.youtube.com/watch?v=am0GBuS_7cE][this video]]}
 with Peter Vogel.
 
 #+begin_export html
 <iframe width="560" height="315"
 src="https://www.youtube.com/embed/am0GBuS_7cE?si=X7pghJhtdfOT1hby"
 title="YouTube video player"
 frameborder="0"
 allow="accelerometer;
 autoplay; clipboard-write; encrypted-media; gyroscope;
 picture-in-picture; web-share"
 allowfullscreen></iframe>
 #+end_export
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-13 16:48 12%                       ` Juan Manuel Macías
@ 2024-03-13 17:16 14%                         ` Juan Manuel Macías
  2024-03-15  2:19  5%                           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-13 17:16 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Juan Manuel Macías writes:

> It was necessary with the previous implementation, which excessively
> abused regexp. Not now (I want to do a few more tests and I'll make a
> new commit with the changes). With the new implementation, now:
>
> -  do not export
>
> *  export only the content
>
> = rest (full)
>
> =* rest (contents only)
>
> backend- do not export this backend (and the backends derived from it)
>
> backend+ (or, perhaps, just "backend") export this backend (idem)
>
> backend* export this backend (contents only) (idem)
>
> I think your example with the video link would also be possible with the
> new implementation.

Please try the latest commit:

@@[:export html-]{Watch [[https://youtube.com/...][Org mode in action demo]] video.}

#+begin_export html
<iframe src="https://youtube.com/embed/..."
  title="Org mode in action demo"
  width="..." height="..."></iframe>
#+end_export

It would not be exported to html or its derived backends.

(In your example you used `-html' instead of `html-'. I have no
preference for one variant or another).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 14%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-13 16:08  5%                     ` Max Nikulin
@ 2024-03-13 16:48 12%                       ` Juan Manuel Macías
  2024-03-13 17:16 14%                         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-13 16:48 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

>> how about the following:
>> - "--" :: do not export
>> - "**" :: export only the content
>> - "==" :: rest (full)
>> - "=*" :: rest (only the content)
>> - "!backend-name+ :: export this backend (full)
>> - "!backend-name*" :: export this backend (only the content)
>> - "!backend-name- :: do not export this backend
>
> I do not see why operator should be duplicated for backends that are not 
> specified explicitly. Single "+" (default) or "-" should be enough. I 
> have not got your idea with leading "!". From my point of view it is 
> redundant.

It was necessary with the previous implementation, which excessively
abused regexp. Not now (I want to do a few more tests and I'll make a
new commit with the changes). With the new implementation, now:

-  do not export

*  export only the content

= rest (full)

=* rest (contents only)

backend- do not export this backend (and the backends derived from it)

backend+ (or, perhaps, just "backend") export this backend (idem)

backend* export this backend (contents only) (idem)

I think your example with the video link would also be possible with the
new implementation.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-12 17:41 12%                   ` Juan Manuel Macías
@ 2024-03-13 16:08  5%                     ` Max Nikulin
  2024-03-13 16:48 12%                       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-13 16:08 UTC (permalink / raw)
  To: emacs-orgmode

On 13/03/2024 00:41, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> It is not clear for me how to achieve the following. Add a link
>>
>> [[https://youtube.com/...][Org mode in action demo (video)]]
>>
>> for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
>> there is an #+export_html block with player embedded using an iframe.
> 
> Sorry, I don't quite understand this. Could you please elaborate?

--- 8< ---
&_[:exports -html]{Watch [[https://youtube.com/...][Org mode in action 
demo]] video.}

#+begin_export html
<iframe src="https://youtube.com/embed/..."
  title="Org mode in action demo"
  width="..." height="..."></iframe>
#+end_export
--- >8 ---

should be exported to HTML without the sentence with the link
--- 8< ---
<iframe src="https://youtube.com/embed/..."
  title="Org mode in action demo"
  width="..." height="..."></iframe>
--- >8 ---

however only the sentence with the link is exported to LaTeX or any 
other format
--- 8< ---
Watch \href{https://youtube.com/...}{Org mode in action demo} video.
--- >8 ---

>> Instead of "noexport" and "rest" that may be confused with backend
>> names I would consider "+" and "*" without any name. I would consider
>> some characters like "-", "_", "!", "~" to express "do not export to
>> this and derived backends" and "do not export for specified backend
>> only".
> 
> how about the following:
> - "--" :: do not export
> - "**" :: export only the content
> - "==" :: rest (full)
> - "=*" :: rest (only the content)
> - "!backend-name+ :: export this backend (full)
> - "!backend-name*" :: export this backend (only the content)
> - "!backend-name- :: do not export this backend

I do not see why operator should be duplicated for backends that are not 
specified explicitly. Single "+" (default) or "-" should be enough. I 
have not got your idea with leading "!". From my point of view it is 
redundant.




^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-12 16:20  5%                 ` Max Nikulin
@ 2024-03-12 17:41 12%                   ` Juan Manuel Macías
  2024-03-13 16:08  5%                     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-12 17:41 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> It is not clear for me how to achieve the following. Add a link
>
> [[https://youtube.com/...][Org mode in action demo (video)]]
>
> for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because
> there is an #+export_html block with player embedded using an iframe.

Sorry, I don't quite understand this. Could you please elaborate?

> Instead of "noexport" and "rest" that may be confused with backend
> names I would consider "+" and "*" without any name. I would consider
> some characters like "-", "_", "!", "~" to express "do not export to
> this and derived backends" and "do not export for specified backend
> only".

how about the following:

- "--" :: do not export

- "**" :: export only the content

- "==" :: rest (full)

- "=*" :: rest (only the content)

- "!backend-name+ :: export this backend (full)

- "!backend-name*" :: export this backend (only the content)

- "!backend-name- :: do not export this backend

?

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-12 13:45 11%               ` Juan Manuel Macías
@ 2024-03-12 16:20  5%                 ` Max Nikulin
  2024-03-12 17:41 12%                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-12 16:20 UTC (permalink / raw)
  To: emacs-orgmode

On 12/03/2024 20:45, Juan Manuel Macías wrote:
> 
> backend-name = full export
> backend-name* = only contents
> And the "rest" option is introduced, with the same syntax as before.
> 
> Examples:

It is not clear for me how to achieve the following. Add a link

[[https://youtube.com/...][Org mode in action demo (video)]]

for all backends (EPUB, LaTeX, ODT, text, etc.) besides HTML because 
there is an #+export_html block with player embedded using an iframe.

Instead of "noexport" and "rest" that may be confused with backend names 
I would consider "+" and "*" without any name. I would consider some 
characters like "-", "_", "!", "~" to express "do not export to this and 
derived backends" and "do not export for specified backend only".




^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-12  8:32  6%             ` Stefan Nobis
@ 2024-03-12 13:45 11%               ` Juan Manuel Macías
  2024-03-12 16:20  5%                 ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-12 13:45 UTC (permalink / raw)
  To: emacs-orgmode; +Cc: Max Nikulin, Stefan Nobis

In the last commit I have introduced some changes. Now this new feature
is no longer hardcoded in each backend but is controlled by an external
function in ox.el. I think this can simplify the implementation for
other backends.

As Stefan Nobis proposed, the "+" sign is now not necessary:

backend-name = full export

backend-name* = only contents

And the "rest" option is introduced, with the same syntax as before.

Examples:

@foo[:export noexport]{lorem ipsum dolor}

==> does not export anything

@foo[:export contents]{lorem ipsum dolor}

==> only contents

@foo[:export latex]{lorem ipsum dolor}

==> exports only to LaTeX

@foo[:export latex odt* html*]{lorem ipsum dolor}

==> exports everything to LaTeX, but to odt and HTML only the content

@foo[:export latex* rest]{lorem ipsum dolor}

==> content to LaTeX but full export to the rest of the backends

@foo[:export latex rest*]{lorem ipsum dolor}

==> the opposite of the above.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-11 20:19 11%           ` Juan Manuel Macías
@ 2024-03-12  8:32  6%             ` Stefan Nobis
  2024-03-12 13:45 11%               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Stefan Nobis @ 2024-03-12  8:32 UTC (permalink / raw)
  To: emacs-orgmode

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

>>> :export "latex+ html+ rest*"

>> "rest" might be a valid backend name.

> I will try to implement the "rest" option.

What about "others" or even ":others" as a placeholder for any not
explicitly mentioned export backend?

Another quick thought crossing my mind: May make "+" the default (so
"latex" means "latex+" and only use a marker char like '*' for
"content only")?

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


^ permalink raw reply	[relevance 6%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-11 17:01  6%         ` Max Nikulin
@ 2024-03-11 20:19 11%           ` Juan Manuel Macías
  2024-03-12  8:32  6%             ` Stefan Nobis
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-11 20:19 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> Your example uses a closed list of backends while "not (html or
> latex)" may be applicable to ascii, rst, some wiki dialects, etc.

Makes sense.

> Backend-specific markup may be more complex and content of fallback
> option may be different from text used in export snippets. Perhaps I
> shouldn't give so simple example.

I think I have understood the essentials, but perhaps it would be good
to see a slightly more complex scenario.

> Side note: I expect that the new object will be more convenient than
> export snippets in most cases.

I think so. In any case, although this object is proving pleasantly
versatile for us, I think we should not lose sight of the fact that its
main purpose is to be an inline text container with export properties.
Exports snippets are more for literal code inclusion. There can be
border uses between both objects, as there can also be with macros and
links. I suppose the ideal is to always choose the feature that best
suits a given context. One can put, for example @esindex[:export
latex+]{some word}, but in this case it would be more comfortable to put
@@latex:\esindex{some word}@@ or even use a macro.

>> :export "latex+ html+ rest*"
>
> "rest" might be a valid backend name.

I will try to implement the "rest" option.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-11 13:59 11%       ` Juan Manuel Macías
@ 2024-03-11 17:01  6%         ` Max Nikulin
  2024-03-11 20:19 11%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-11 17:01 UTC (permalink / raw)
  To: emacs-orgmode

On 11/03/2024 20:59, Juan Manuel Macías wrote:
>>
>> I have a bit different expectations in respect to export predicates.
>> It should be possible to express that some content should be exported
>> by all backend except the given list. The use case is fallback for
>> backends not covered by export snippets:
>>
>>      @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
>>      formatting</strong>@@@[...]{*for other backends}
> 
> I think that in your example (if I understand the intentions correctly)
> it would not even be necessary to use export snippets:
> 
> #+options: inline-special-block-aliases:(("strong" :latex-command textbf
> :html-tag strong :export "latex+ html+ odt*" ))

Your example uses a closed list of backends while "not (html or latex)" 
may be applicable to ascii, rst, some wiki dialects, etc. 
Backend-specific markup may be more complex and content of fallback 
option may be different from text used in export snippets. Perhaps I 
shouldn't give so simple example.

Side note: I expect that the new object will be more convenient than 
export snippets in most cases.

> :export "latex+ html+ rest*"

"rest" might be a valid backend name.




^ permalink raw reply	[relevance 6%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-11 10:27  5%     ` Max Nikulin
@ 2024-03-11 13:59 11%       ` Juan Manuel Macías
  2024-03-11 17:01  6%         ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-11 13:59 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> On 10/03/2024 09:08, Juan Manuel Macías wrote:
>> I'm thinking about adding a new global attribute, `:export', that
>> would granularly control whether or not to export the object and how to
>> export it.
>
> I have a bit different expectations in respect to export predicates.
> It should be possible to express that some content should be exported
> by all backend except the given list. The use case is fallback for
> backends not covered by export snippets:
>
>     @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML
>     formatting</strong>@@@[...]{*for other backends}

I think that in your example (if I understand the intentions correctly)
it would not even be necessary to use export snippets:

#+options: inline-special-block-aliases:(("strong" :latex-command textbf
:html-tag strong :export "latex+ html+ odt*" ))

@strong{formatting}

or even:

@strong{@@latex:\latex{}: @@@@html:HTML: @@ formatting}

As defined, it is exported to LaTeX and HTML with all the formatting,
but only the content is exported to odt. The rest are not exported.
Maybe an "rest" option could be added, to avoid verbosity:

:export "latex+ html+ rest*"

(the complete format is exported to LaTeX and html and only the content to the rest).

However, I think that exporting this object to 'format-agnostic' backends,
such as plain text, would have to be implemented in a way that always
exports the content.

> Earlier I raised this issue during discussion of @@:...@@ syntax extension:
> Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022
> 21:52:17 +0700.
> https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982fcf@gmail.com
>
> Another case for backend predicates is whether it should be applicable
> to derived backends or just to explicitly specified ones.

I don't have a definite opinion. Maybe it would be nice to also take
into account derived backends...

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: Footnotes on line and not raised
  @ 2024-03-11 11:03 12%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-11 11:03 UTC (permalink / raw)
  To: Colin Baxter; +Cc: emacs-orgmode

Colin Baxter writes:

> Perhaps it's not possible because I see that .footref in css support is
> always <sup>.

You can modify <sup> a little so that it does not alter the paragraph
line spacing so much. In this example, with a value of 0em, it is
positioned on the baseline:

#+HTML_HEAD: <style> sup {vertical-align: baseline;position: relative;bottom: 0em;} </style>

Another slightly dirtier way is with an export filter in your document.
The sub tag is removed and the reference number is enclosed in square
brackets, separated by a space from the previous word:

#+BIND: org-export-filter-footnote-reference-functions (footnote-sup-filter)
#+begin_src emacs-lisp :exports results :results none
  (defun footnote-sup-filter (text backend info)
    (when (org-export-derived-backend-p backend 'html)
(replace-regexp-in-string "<a" " <a"
(replace-regexp-in-string "\\([[:digit:]]+\\)\\(</a\\)" "[\\1]\\2"
      (replace-regexp-in-string "</?sup>" "" text)))))
#+end_src

screenshot:

https://i.ibb.co/CBRnfXG/pantallazo-79248380551244229p8.png

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-10  2:08 10%   ` `:export' attribute?: " Juan Manuel Macías
  2024-03-10 13:54 13%     ` Juan Manuel Macías
@ 2024-03-11 10:27  5%     ` Max Nikulin
  2024-03-11 13:59 11%       ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-11 10:27 UTC (permalink / raw)
  To: emacs-orgmode

On 10/03/2024 09:08, Juan Manuel Macías wrote:
> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.

I have a bit different expectations in respect to export predicates. It 
should be possible to express that some content should be exported by 
all backend except the given list. The use case is fallback for backends 
not covered by export snippets:

     @@latex:\textbf{\LaTeX() formatting}@@@@html:<strong>HTML 
formatting</strong>@@@[...]{*for other backends}

Earlier I raised this issue during discussion of @@:...@@ syntax extension:
Max Nikulin. Re: Org-syntax: Intra-word markup. Fri, 28 Jan 2022 
21:52:17 +0700. 
https://list.orgmode.org/868df76e-69e0-1d14-ae8a-13b746982fcf@gmail.com

Another case for backend predicates is whether it should be applicable 
to derived backends or just to explicitly specified ones.



^ permalink raw reply	[relevance 5%]

* Re: `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-10  2:08 10%   ` `:export' attribute?: " Juan Manuel Macías
@ 2024-03-10 13:54 13%     ` Juan Manuel Macías
  2024-03-11 10:27  5%     ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-10 13:54 UTC (permalink / raw)
  To: orgmode

Juan Manuel Macías writes:

> I'm thinking about adding a new global attribute, `:export', that
> would granularly control whether or not to export the object and how to
> export it.
>
> Possible values: "noexport", "contents" (it would export only the content)
> or the backends to which you want to export, separated by spaces. Each
> backend should be followed by a "+" sign (= export all) or "*" (export
> content only). For example:
>
> @foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}
>
> This means that "lorem ipsum dolor" would be exported with color format
> to LaTeX, but only the content would be exported to odt and html.

I have implemented the new :export attribute in the last commit, to
experiment (in any case, it can always be reverted). The syntax and
usage are as described in the previous message. An example, where we
define an alias for inline comments and another for highlighted text: It
will only be exported as highlighted text to LaTeX (using the lua-ul
package for LuaLaTeX); only the content will be exported to HTML; and it
will not be exported to the rest of the backends.

#+options: inline-special-block-aliases:(("comment" :export "noexport")("hl" :export "latex+ html*" :latex-command "highLight"))
#+latex_header: \usepackage{xcolor,luacolor,lua-ul}
#+latex_compiler: lualatex

@hl{this is highlighted text, only in LaTeX} @comment{this is a comment}

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía




^ permalink raw reply	[relevance 13%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-09 15:24 14%                             ` Juan Manuel Macías
@ 2024-03-10  7:11  7%                               ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2024-03-10  7:11 UTC (permalink / raw)
  To: emacs-orgmode

On 09/03/2024 22:24, Juan Manuel Macías wrote:
> Well, I hope that in the last commit the two bugs that you mentioned
> have been fixed. Please check:
> 
> Albha@Beta[
> 
> @sp@n{lorem ipsum}
> 
> @@@@{lorem ipsum}

Thanks, Juan Manuel. I do not see issues any more.

I would still consider unit tests to not break these cases later.




^ permalink raw reply	[relevance 7%]

* `:export' attribute?: Re: Experimental public branch for inline special blocks
  2024-03-03 20:29  9% ` Juan Manuel Macías
@ 2024-03-10  2:08 10%   ` Juan Manuel Macías
  2024-03-10 13:54 13%     ` Juan Manuel Macías
  2024-03-11 10:27  5%     ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-10  2:08 UTC (permalink / raw)
  To: orgmode

I'm thinking about adding a new global attribute, `:export', that
would granularly control whether or not to export the object and how to
export it.

Possible values: "noexport", "contents" (it would export only the content)
or the backends to which you want to export, separated by spaces. Each
backend should be followed by a "+" sign (= export all) or "*" (export
content only). For example:

@foo[:color red :export latex+ odt* html*]{lorem ipsum dolor}

This means that "lorem ipsum dolor" would be exported with color format
to LaTeX, but only the content would be exported to odt and html.

Wdyt?

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 10%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-09 11:48 12%                           ` Juan Manuel Macías
@ 2024-03-09 15:24 14%                             ` Juan Manuel Macías
  2024-03-10  7:11  7%                               ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-09 15:24 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Juan Manuel Macías writes:

> Max Nikulin writes:
>
>> However it is still gives
>>
>>   (org-export-string-as "Alpha@Beta["
>>               'html
>>               '(:export-options (body-only)))
>>   Debugger entered--Lisp error: (wrong-type-argument
>>   number-or-marker-p nil)
>
> I think the problem is the contents-begin variable. When it is nil it
> produces that error. I will make a new commit to fix the bug.
>
> Thanks for all the tests you're doing!

Well, I hope that in the last commit the two bugs that you mentioned
have been fixed. Please check:

Albha@Beta[

@sp@n{lorem ipsum}

@@@@{lorem ipsum}

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 14%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-09 11:10  6%                         ` Max Nikulin
@ 2024-03-09 11:48 12%                           ` Juan Manuel Macías
  2024-03-09 15:24 14%                             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-09 11:48 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> However it is still gives
>
>   (org-export-string-as "Alpha@Beta["
>               'html
>               '(:export-options (body-only)))
>   Debugger entered--Lisp error: (wrong-type-argument
>   number-or-marker-p nil)

I think the problem is the contents-begin variable. When it is nil it
produces that error. I will make a new commit to fix the bug.

Thanks for all the tests you're doing!

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 18:57 14%                       ` Juan Manuel Macías
@ 2024-03-09 11:10  6%                         ` Max Nikulin
  2024-03-09 11:48 12%                           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-09 11:10 UTC (permalink / raw)
  To: emacs-orgmode

On 09/03/2024 01:57, Juan Manuel Macías wrote:
> 
>> Ok, I think you and Maxim are right. This is a clear bug. I hope it
>> was fixed in the last commit.
> 
>    (org-export-string-as "Alpha@Beta{" 'latex t))
> 
> ==> Alpha@Beta\{
> 
>    (org-export-string-as "Alpha@Beta{gamma}" 'latex t))
> 
> ==> Alpha\Beta{gamma}

However it is still gives

   (org-export-string-as "Alpha@Beta["
               'html
               '(:export-options (body-only)))
   Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p 
nil)

Moreover I am unsure if "@" should be allowed in any position of elements

     (org-export-string-as "@sp@n{}"
               'html
               '(:export-options (body-only)))
   "<p>\n<span class=\"sp@n\">nil</span></p>\n"

   (org-export-string-as "@@@@{}"
               'latex
               '(:export-options (body-only)))
   "\\@@@{nil}\n"




^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 18:44 12%                     ` Juan Manuel Macías
@ 2024-03-08 18:57 14%                       ` Juan Manuel Macías
  2024-03-09 11:10  6%                         ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-08 18:57 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

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

> Ok, I think you and Maxim are right. This is a clear bug. I hope it
> was fixed in the last commit.

Now:

  (org-export-string-as "Alpha@Beta{" 'latex t))

==> Alpha@Beta\{

  (org-export-string-as "Alpha@Beta{gamma}" 'latex t))

==> Alpha\Beta{gamma}

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 14%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 16:15  6%                   ` Ihor Radchenko
@ 2024-03-08 18:44 12%                     ` Juan Manuel Macías
  2024-03-08 18:57 14%                       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-08 18:44 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>>   Debugger entered--Lisp error: (wrong-type-argument
>>>   number-or-marker-p nil)
>>
>> Maybe in that case you could add a zero width space character.
>>
>> In any case, if someone has reasons to write "Alpha@Beta{" they may also
>> have reasons to write "Alpha_Beta":
>
> 1. Parser must not throw errors on text files. Ever. Any text file is a
>    valid Org file.
> 2. We should demand paired {...}, as we do for latex fragments,
>    emphasis, inline export snippets, and all other container objects.

Ok, I think you and Maxim are right. This is a clear bug. I hope it
was fixed in the last commit.


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 15:44 12%                 ` Juan Manuel Macías
  2024-03-08 16:04  6%                   ` Max Nikulin
@ 2024-03-08 16:15  6%                   ` Ihor Radchenko
  2024-03-08 18:44 12%                     ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-03-08 16:15 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

>>   Debugger entered--Lisp error: (wrong-type-argument
>>   number-or-marker-p nil)
>
> Maybe in that case you could add a zero width space character.
>
> In any case, if someone has reasons to write "Alpha@Beta{" they may also
> have reasons to write "Alpha_Beta":

1. Parser must not throw errors on text files. Ever. Any text file is a
   valid Org file.
2. We should demand paired {...}, as we do for latex fragments,
   emphasis, inline export snippets, and all other container objects.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 15:44 12%                 ` Juan Manuel Macías
@ 2024-03-08 16:04  6%                   ` Max Nikulin
  2024-03-08 16:15  6%                   ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2024-03-08 16:04 UTC (permalink / raw)
  To: emacs-orgmode

On 08/03/2024 22:44, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>>    (org-export-string-as "Alpha@Beta{"
>>                'html
>>                '(:export-options (body-only)))
>>    "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
>>
>>    (org-export-string-as "Alpha@Beta["
>>                'html
>>                '(:export-options (body-only)))
>>    Debugger entered--Lisp error: (wrong-type-argument
>>    number-or-marker-p nil)
> 
> Maybe in that case you could add a zero width space character.
> 
> In any case, if someone has reasons to write "Alpha@Beta{" they may also
> have reasons to write "Alpha_Beta":
> 
> (org-export-string-as "Alpha_beta"
>                'html
>                '(:export-options (body-only)))
> <p>
> Alpha<sub>beta</sub></p>

 From my point of view it is a pitfall with Org syntax, but parser works 
as it should.

On the other hand if there is no closing bracket then it is not an 
inline special block, so this part of document should be considered as 
text (unless some other objects are recognized).

Currently Org parser does not signal errors even for invalid input.



^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-08 13:58  6%               ` Max Nikulin
@ 2024-03-08 15:44 12%                 ` Juan Manuel Macías
  2024-03-08 16:04  6%                   ` Max Nikulin
  2024-03-08 16:15  6%                   ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-08 15:44 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

>   (org-export-string-as "Alpha@Beta{"
>               'html
>               '(:export-options (body-only)))
>   "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"
>
>   (org-export-string-as "Alpha@Beta["
>               'html
>               '(:export-options (body-only)))
>   Debugger entered--Lisp error: (wrong-type-argument
>   number-or-marker-p nil)

Maybe in that case you could add a zero width space character.

In any case, if someone has reasons to write "Alpha@Beta{" they may also
have reasons to write "Alpha_Beta":

(org-export-string-as "Alpha_beta"
              'html
              '(:export-options (body-only)))

<p>
Alpha<sub>beta</sub></p>


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 18:21 12%             ` Juan Manuel Macías
@ 2024-03-08 13:58  6%               ` Max Nikulin
  2024-03-08 15:44 12%                 ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-08 13:58 UTC (permalink / raw)
  To: emacs-orgmode

On 08/03/2024 01:21, Juan Manuel Macías wrote:
>> Ihor Radchenko escribió:
>>
>>> I am wondering if @@[...]{...} would be better than @_...
>>> It should be slightly easier to type.
> 
> Anyway, in the last commit I replaced _ with @. Let's see how it goes...
> Now the anonymous variant is @@[...]{...}.

Unfortunately the issue, I have reported, has not fixed. I admit, the 
examples have become more contrived

   (org-export-string-as "Alpha@Beta{"
               'html
               '(:export-options (body-only)))
   "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"

   (org-export-string-as "Alpha@Beta["
               'html
               '(:export-options (body-only)))
   Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p 
nil)



^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 16:57 12%           ` Juan Manuel Macías
@ 2024-03-07 18:21 12%             ` Juan Manuel Macías
  2024-03-08 13:58  6%               ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 18:21 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Juan Manuel Macías writes:

> Ihor Radchenko <yantar92@posteo.net> escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any special preference, although @@ visually reminds me a
> bit of the export snippet).

Anyway, in the last commit I replaced _ with @. Let's see how it goes...
Now the anonymous variant is @@[...]{...}.


^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 16:09  6%         ` Ihor Radchenko
@ 2024-03-07 16:57 12%           ` Juan Manuel Macías
  2024-03-07 18:21 12%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 16:57 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko <yantar92@posteo.net> escribió:

> I am wondering if @@[...]{...} would be better than @_...
> It should be slightly easier to type.

Another possibility would be @:[...]{...}, which is somewhat shorter.

(I don't have any special preference, although @@ visually reminds me a
bit of the export snippet).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 15:53 12%       ` Juan Manuel Macías
@ 2024-03-07 16:09  6%         ` Ihor Radchenko
  2024-03-07 16:57 12%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-03-07 16:09 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

> I have modified the syntax in the last commit. Now:
>
> @type[...]{...} (or @_[...]{...})

I am wondering if @@[...]{...} would be better than @_...
It should be slightly easier to type.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 11:18  6%     ` Ihor Radchenko
  2024-03-07 11:19  6%       ` Juan Manuel Macías
@ 2024-03-07 15:53 12%       ` Juan Manuel Macías
  2024-03-07 16:09  6%         ` Ihor Radchenko
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 15:53 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.) 

I have modified the syntax in the last commit. Now:

@type[...]{...} (or @_[...]{...})

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 11:18  6%     ` Ihor Radchenko
@ 2024-03-07 11:19  6%       ` Juan Manuel Macías
  2024-03-07 15:53 12%       ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-07 11:19 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>>   (org-export-string-as "Alpha&Beta{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
>>
>> Perhaps we should think about a structure less prone to ambiguities. For
>> example:
>>
>> &:type[attrs]{text} / &:_[attrs]{text}
>
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.) 

+1

(one character is always better than two)


^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 11:06 12%   ` Juan Manuel Macías
@ 2024-03-07 11:18  6%     ` Ihor Radchenko
  2024-03-07 11:19  6%       ` Juan Manuel Macías
  2024-03-07 15:53 12%       ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-03-07 11:18 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

>>   (org-export-string-as "Alpha&Beta{"
> ...
> mmm, right. And there may also be a problem with the subscripts: &_{subscript}...
>
> Perhaps we should think about a structure less prone to ambiguities. For
> example:
>
> &:type[attrs]{text} / &:_[attrs]{text}

I suggest @type[...]{...}. Akin Texinfo constructs.

(Texinfo because of
previous RMS' request to implement better support for markup used in
software manuals - keeping things close to Texinfo syntax will make life
easier if we ever reach the point when Org mode is used as standard
documentation format.) 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: false positives: Re: Experimental public branch for inline special blocks
  2024-03-07 10:57  6% ` false positives: " Max Nikulin
@ 2024-03-07 11:06 12%   ` Juan Manuel Macías
  2024-03-07 11:18  6%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-07 11:06 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> It seems the parser finds new objects where syntactical constructs are
> incomplete:
>
>   (org-export-string-as "Alpha&Beta{"
> 		      'html
> 		      '(:export-options (body-only)))
>   "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"

mmm, right. And there may also be a problem with the subscripts: &_{subscript}...

Perhaps we should think about a structure less prone to ambiguities. For
example:

&:type[attrs]{text} / &:_[attrs]{text}

(I think someone had suggested something like this in a past message,
but I can't find it, apologies).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* false positives: Re: Experimental public branch for inline special blocks
  2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
                   ` (4 preceding siblings ...)
  2024-03-06 16:53  7% ` To avoid zero width space: " Max Nikulin
@ 2024-03-07 10:57  6% ` Max Nikulin
  2024-03-07 11:06 12%   ` Juan Manuel Macías
  5 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-07 10:57 UTC (permalink / raw)
  To: emacs-orgmode

On 02/03/2024 03:34, Juan Manuel Macías wrote:
> 
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
> 
> <https://gitlab.com/maciaschain/org-mode.git>

It seems the parser finds new objects where syntactical constructs are 
incomplete:

   (org-export-string-as "Alpha&Beta{"
		      'html
		      '(:export-options (body-only)))
   "<p>\nAlpha<span class=\"Beta\"></span>{</p>\n"

My expectation is

   "<p>\nAlpha&amp;Beta{</p>\n"

Even worse

   (org-export-string-as "Alpha&Beta["
		      'html
		      '(:export-options (body-only)))

    Debugger entered--Lisp error: (wrong-type-argument 
number-or-marker-p nil)

I think, this particular case deserves a unit test despite it is too 
early for extensive test suite.



^ permalink raw reply	[relevance 6%]

* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
  2024-03-06 16:53  7% ` To avoid zero width space: " Max Nikulin
  2024-03-06 18:27 12%   ` Juan Manuel Macías
@ 2024-03-06 21:13 12%   ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 21:13 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "

With the latest commit now the anonymous variant without attributes
simply returns the content (in LaTeX, HTML and odt). You can try:

&_{/lorem/}&_{*ipsum*}&_{_dolor_}

==> LaTeX: \emph{lorem}\textbf{ipsum}\uline{dolor}

==> HTML <i>lorem</i><b>ipsum</b><span class="underline">dolor</span>

==> ODT <text:span text:style-name="Emphasis">lorem</text:span><text:span text:style-name="Bold">ipsum</text:span><text:span text:style-name="Underline">dolor</text:span>


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: To avoid zero width space: Re: Experimental public branch for inline special blocks
  2024-03-06 16:53  7% ` To avoid zero width space: " Max Nikulin
@ 2024-03-06 18:27 12%   ` Juan Manuel Macías
  2024-03-06 21:13 12%   ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 18:27 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> However to produce clean export result <span> elements should not be
> added if no attributes are specified. My expectation is
>
> "<p>
> Example of <b>intra</b><i>word</i> markup</p>
> "

It seems like a good idea to me. Currently, in LaTeX:

&_{lorem ipsum dolor} ==> LaTeX ==> lorem ipsum dolor

It can also be extended to html, odt and the rest of the backends.

That is, by default, the anonymous variant without attributes simply
returns the content.

Another possibility (with the current implementation):

#+options: inline-special-block-aliases:(("b" :html-tag "b")("i" :html-tag "i"))

&b{intra}&i{word}

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 12%]

* To avoid zero width space: Re: Experimental public branch for inline special blocks
  2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
                   ` (3 preceding siblings ...)
  2024-03-05 16:47  5% ` smallcaps: " Max Nikulin
@ 2024-03-06 16:53  7% ` Max Nikulin
  2024-03-06 18:27 12%   ` Juan Manuel Macías
  2024-03-06 21:13 12%   ` Juan Manuel Macías
  2024-03-07 10:57  6% ` false positives: " Max Nikulin
  5 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2024-03-06 16:53 UTC (permalink / raw)
  To: emacs-orgmode

On 02/03/2024 03:34, Juan Manuel Macías wrote:
> 
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:
> 
> <https://gitlab.com/maciaschain/org-mode.git>

The new feature is promising as an alternative for U+200B zero width 
space as an escape character (info "(org) Escape Character"). It may 
adjusted to allow really plain text markup instead of a character 
invisible by default:

(org-export-string-as "Example of &_{*intra*}&_{/word/} markup"
		      'html
		      '(:export-options (body-only)))
"<p>
Example of <span><b>intra</b></span><span><i>word</i></span> markup</p>
"

However to produce clean export result <span> elements should not be 
added if no attributes are specified. My expectation is

"<p>
Example of <b>intra</b><i>word</i> markup</p>
"

Earlier discussions:

- Denis Maier. Org-syntax: Intra-word markup. Thu, 2 Dec 2021 11:50:32 
+0100. 
https://list.orgmode.org/4897bc60-b74f-ccfd-e13e-9b89a1194fdf@mailbox.org
- Juan Manuel Macías. On zero width spaces and Org syntax. Fri, 03 Dec 
2021 12:48:16 +0000. https://list.orgmode.org/87ilw5yhv3.fsf@posteo.net
- Vincent Belaïche. RE: [RFC] Creole-style / Support for 
**emphasis**__within__**a word** Mon, 24 Jan 2022 10:50:10 +0000. 
https://list.orgmode.org/PAXPR06MB809350C21E7C75A2A110C529845E9@PAXPR06MB8093.eurprd06.prod.outlook.com




^ permalink raw reply	[relevance 7%]

* Re: smallcaps: Re: Experimental public branch for inline special blocks
  2024-03-06 10:55  5%     ` Max Nikulin
@ 2024-03-06 15:21 11%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-06 15:21 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
>    #+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
>    &definition{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
>    <span style="font-variant:small-caps;">Example</span>
>    or <span style="font-variant:small-caps;">ad-hoc</span>
>
> or as
>
>    <span class="definition">Example</span>
>    or <span class="small-caps">ad-hoc</span>
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
>    .definition, .small-capps { font-variant: small-caps; }

With the current implementation this:

#+options: inline-special-block-aliases:(("definition" :smallcaps t))

&definition{Example}

produces:

<span style="font-variant:small-caps;" class="definition">Example</span>

:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).

I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 11%]

* Re: smallcaps: Re: Experimental public branch for inline special blocks
  2024-03-05 17:28 10%   ` Juan Manuel Macías
@ 2024-03-06 10:55  5%     ` Max Nikulin
  2024-03-06 15:21 11%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-06 10:55 UTC (permalink / raw)
  To: emacs-orgmode

On 06/03/2024 00:28, Juan Manuel Macías wrote:
> Max Nikulin escribió:
> I think that the current implementation is very flexible and gives rise
> to many possible variations, and the combination of direct formatting
> and styles to suit the user.

OK, just consider it as my dissenting opinion. I believe that it should 
be possible for the same Org document

   #+options: inline-special-block-aliases:(("definition" :smallcaps t))

   &definition{Example} or &_[:smallcaps t]{ad-hoc}

to export it as

   <span style="font-variant:small-caps;">Example</span>
   or <span style="font-variant:small-caps;">ad-hoc</span>

or as

   <span class="definition">Example</span>
   or <span class="small-caps">ad-hoc</span>

by adjusting of global settings. The former one be suitable for a CMS 
that does not allow user CSS and the latter one is preferable for a site 
under full user control and having CSS

   .definition, .small-capps { font-variant: small-caps; }



^ permalink raw reply	[relevance 5%]

* Re: smallcaps: Re: Experimental public branch for inline special blocks
  2024-03-05 16:47  5% ` smallcaps: " Max Nikulin
@ 2024-03-05 17:28 10%   ` Juan Manuel Macías
  2024-03-06 10:55  5%     ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-05 17:28 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin <manikulin@gmail.com> escribió:

> If some type is used through the document multiple times then it is 
> better to avoid style="font-variant:small-caps" and use a CSS class 
> instead. Even for LaTeX it may be better to define a dedicated command 
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type 
> may be typed in small caps in LaTeX, but in HTML it may use regular font 
> and some color.

The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.

If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:

&_[:html style="color:red;" :prelatex \scshape{}]{text}

And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.

I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 10%]

* smallcaps: Re: Experimental public branch for inline special blocks
  2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
                   ` (2 preceding siblings ...)
  2024-03-04 17:13  5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
@ 2024-03-05 16:47  5% ` Max Nikulin
  2024-03-05 17:28 10%   ` Juan Manuel Macías
  2024-03-06 16:53  7% ` To avoid zero width space: " Max Nikulin
  2024-03-07 10:57  6% ` false positives: " Max Nikulin
  5 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-05 16:47 UTC (permalink / raw)
  To: emacs-orgmode

On 02/03/2024 03:34, Juan Manuel Macías wrote:
> │ Caesar's famous quote: &latin![:smallcaps t :color blue]{Alea iacta est}
> ==> LaTeX:
> │ Caesar's famous quote: {\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
> == HTML:
> │ Caesar's famous quote: <em style="color:blue;font-variant:small-caps;" lang="la" class="latin">Alea iacta est</em>

I am in doubts if smallcaps should be hardcoded. From my point of view, 
current implementation is unnecessary rigid. In this particular example 
:smallcaps is an ad-hoc property. I would expect its usage through an 
alias definition, e.g.

#+options: inline-special-block-aliases:(("definition" :smallcaps t))

If some type is used through the document multiple times then it is 
better to avoid style="font-variant:small-caps" and use a CSS class 
instead. Even for LaTeX it may be better to define a dedicated command 
to be closer to semantic markup.

Moreover different decorations may be used in LaTeX and HTML. Some type 
may be typed in small caps in LaTeX, but in HTML it may use regular font 
and some color.

Perhaps an e.g. user-configurable and extensible alist of types with 
per-backend properties should be used instead.

A portion of wisdom how to represent small caps for each export backend 
may be handy, but accessing it should be more flexible.



^ permalink raw reply	[relevance 5%]

* Re: naming: Re: Experimental public branch for inline special blocks
  2024-03-05 10:53  6%       ` Max Nikulin
@ 2024-03-05 15:16 11%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-05 15:16 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Ihor Radchenko, orgmode

Max Nikulin writes:

> Special blocks are really block-level elements. I see similarity,
> however with a better term we could avoid "inline" specifier. I think,
> the new beast may serve in some cases currently handled by macros.
> LaTeX snippets are named "fragments" in the manual.
>
> Custom fragment?

I think "custom" is an important part of defining the new object. Unlike
other elements/objects, such as emphasis marks, this one does not add
any (let's say) "logical or semantic" information. I mean, emphasis
marks (to continue with the example) are useful when reading an Org
document as it is. But the new object is rather a segment of text that
must be exported in a certain way to LaTeX, odt, HTML, etc. Something
like "&foo{some text}" does not provide any information to the reader,
but rather to the exporters and the output format. So, how about
something like:

- Custom Export Fragment

- Custom Export Span

- Custom Export "Whatever"

- ...

?

(I especially like "span" because of the similarity with html and family.
Pandoc uses the term bracketed spans for its custom markdown).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: naming: Re: Experimental public branch for inline special blocks
  2024-03-04 17:49 12%     ` Juan Manuel Macías
@ 2024-03-05 10:53  6%       ` Max Nikulin
  2024-03-05 15:16 11%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-03-05 10:53 UTC (permalink / raw)
  To: emacs-orgmode

On 05/03/2024 00:49, Juan Manuel Macías wrote:
> Ihor Radchenko writes:
>> Max Nikulin writes:
>>
>>> Does anybody have an idea of a better name for a feature? Maybe
>>> something like inline custom objects, snippets. "Objects" are used to
>>> describe syntax, but not used in the manual though.
>>
>> Custom inline markup.
> 
> Custom span?
> 
> I chose "inline special block" because special blocks, and because of
> the parallelism inline code block/code block.

Special blocks are really block-level elements. I see similarity, 
however with a better term we could avoid "inline" specifier. I think, 
the new beast may serve in some cases currently handled by macros. LaTeX 
snippets are named "fragments" in the manual.

Custom fragment?




^ permalink raw reply	[relevance 6%]

* [tip] Export to PDF with latexmk 'continuous preview' option
@ 2024-03-05  0:58  9% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-05  0:58 UTC (permalink / raw)
  To: orgmode

A little-known (and sometimes very useful) latexmk option is the -pvc
option. According to the latexmk manual:

      [...] The second previewing option is the powerful -pvc option
      (mnemonic: "preview continuously"). In this case, latexmk
      runs continuously, regularly monitoring all the source files
      to see if any have changed. Every time a change is detected,
      latexmk runs all the programs necessary to generate a new
      version of the document. A good previewer will then
      automatically update its display. Thus the user can simply
      edit a file and, when the changes are written to disk,
      latexmk completely automates the cycle of updating the .dvi
      (and/or the .ps and .pdf) file, and refreshing the
      previewer's display. It's not quite WYSIWYG, but usefully
      close.

In order to use this option from Org, I have defined a simple minor mode
that runs latexmk with the -pvc option and creates a buffer to monitor
the process. Every time the document, or any file involved, is saved,
the PDF is updated. We can define in our `latexmkrc' our favorite
external PDF viewer (Atril, Okular, Evince, etc.). I have this line:

┌────
│ $pdf_previewer = "atril %O %S > /dev/null 2>&1 &";
└────

And here's the code (for documents that are long, complex, or take a
while to export, it may be better to use the asynchronous version of
`org-latex-export-to-latex'):

┌────
│ (defun my-org-compile-latexmk-interactive ()
│   (let* ((tex-file (org-export-output-file-name ".tex")))
│     (start-process-shell-command
│      "latexmk"
│      (format "*%s-latexmk-process*" (file-name-sans-extension tex-file))
│      (concat
│       "latexmk -f -pvc -lualatex -e '$lualatex=q/lualatex %O -shell-escape %S/' "
│       tex-file))))
│
│ (define-minor-mode org-interactive-compile-pdf-mode
│   "TODO"
│   :lighter " OrgInteractivePDF"
│   (if org-interactive-compile-pdf-mode
│       (progn
│       (my-org-compile-latexmk-interactive)
│       (add-hook 'after-save-hook #'org-latex-export-to-latex nil t))
│     (remove-hook 'after-save-hook #'org-latex-export-to-latex t)
│     (when (equal (process-status "latexmk") 'run)
│       (kill-process "latexmk"))))
└────

And a screencast:

<https://cloud.disroot.org/s/ztFfa27kdsnNkGc>

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 9%]

* Re: naming: Re: Experimental public branch for inline special blocks
  2024-03-04 22:17  5%     ` Samuel Wales
@ 2024-03-04 22:18  0%       ` Samuel Wales
  0 siblings, 0 replies; 200+ results
From: Samuel Wales @ 2024-03-04 22:18 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

[i did not aim that at any particular person!]

On 3/4/24, Samuel Wales <samologist@gmail.com> wrote:
> If language is not correct, then what is said is
> not what is meant; if what is said is not what is meant,
> then what must be done remains undone; if this remains
> undone, morals and art will deteriorate; if justice goes
> astray, the people will stand about in helpless
> confusion. Hence there must be no arbitrariness in what is
> said. This matters above everything.  --- analects
>
> On 3/4/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
>> Max Nikulin writes:
>>
>>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>>> within paragraphs are named objects. I admit that for org-element
>>> everything is element.
>>
>> In my initial message I used 'element' loosely. Note that
>> inline-special-block is included in org-element-all-objects, where
>> inline-src-block is also.
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com


^ permalink raw reply	[relevance 0%]

* Re: naming: Re: Experimental public branch for inline special blocks
  2024-03-04 18:07  6%   ` Juan Manuel Macías
@ 2024-03-04 22:17  5%     ` Samuel Wales
  2024-03-04 22:18  0%       ` Samuel Wales
  0 siblings, 1 reply; 200+ results
From: Samuel Wales @ 2024-03-04 22:17 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

If language is not correct, then what is said is
not what is meant; if what is said is not what is meant,
then what must be done remains undone; if this remains
undone, morals and art will deteriorate; if justice goes
astray, the people will stand about in helpless
confusion. Hence there must be no arbitrariness in what is
said. This matters above everything.  --- analects

On 3/4/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Max Nikulin writes:
>
>> In Org syntax, "elements" are paragraphs and larger parts, while parts
>> within paragraphs are named objects. I admit that for org-element
>> everything is element.
>
> In my initial message I used 'element' loosely. Note that
> inline-special-block is included in org-element-all-objects, where
> inline-src-block is also.
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com


^ permalink raw reply	[relevance 5%]

* Re: naming: Re: Experimental public branch for inline special blocks
  2024-03-04 17:13  5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
  @ 2024-03-04 18:07  6%   ` Juan Manuel Macías
  2024-03-04 22:17  5%     ` Samuel Wales
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-04 18:07 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

> In Org syntax, "elements" are paragraphs and larger parts, while parts
> within paragraphs are named objects. I admit that for org-element
> everything is element.

In my initial message I used 'element' loosely. Note that
inline-special-block is included in org-element-all-objects, where
inline-src-block is also.


^ permalink raw reply	[relevance 6%]

* Re: naming: Re: Experimental public branch for inline special blocks
  @ 2024-03-04 17:49 12%     ` Juan Manuel Macías
  2024-03-05 10:53  6%       ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-04 17:49 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>> Does anybody have an idea of a better name for a feature? Maybe 
>> something like inline custom objects, snippets. "Objects" are used to 
>> describe syntax, but not used in the manual though.
>
> Custom inline markup.

Custom span?

I chose "inline special block" because special blocks, and because of
the parallelism inline code block/code block.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* naming: Re: Experimental public branch for inline special blocks
  2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
    2024-03-03 20:29  9% ` Juan Manuel Macías
@ 2024-03-04 17:13  5% ` Max Nikulin
    2024-03-04 18:07  6%   ` Juan Manuel Macías
  2024-03-05 16:47  5% ` smallcaps: " Max Nikulin
                   ` (2 subsequent siblings)
  5 siblings, 2 replies; 200+ results
From: Max Nikulin @ 2024-03-04 17:13 UTC (permalink / raw)
  To: emacs-orgmode

On 02/03/2024 03:34, Juan Manuel Macías wrote:
> 
> Finally, I have made public on GitLab my experimental branch for the new
> (possible) inline-special-block element:

I find the feature name confusing, however I am unsure if others share 
my opinion.

In Org syntax, "elements" are paragraphs and larger parts, while parts 
within paragraphs are named objects. I admit that for org-element 
everything is element.

In CSS "display: inline block" makes an HTML element a rectangular block 
inside a paragraph while new feature is mostly intended for normal text 
flow. I admit that &parbox[...]{...} may be used to create an instance 
similar to inline block and that "inline source blocks" are already 
described in the manual.

Does anybody have an idea of a better name for a feature? Maybe 
something like inline custom objects, snippets. "Objects" are used to 
describe syntax, but not used in the manual though.




^ permalink raw reply	[relevance 5%]

* Re: Experimental public branch for inline special blocks
  2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
  @ 2024-03-03 20:29  9% ` Juan Manuel Macías
  2024-03-10  2:08 10%   ` `:export' attribute?: " Juan Manuel Macías
  2024-03-04 17:13  5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-03-03 20:29 UTC (permalink / raw)
  To: orgmode

Hi again,

The odt backend is now complete with the `org-odt-inline-special-block'
function. Some particularities of exporting to odt:

- The only specific attribute is :odt-style, which overrides the default
  style. Example:

&foo{lorem ipsum} ==> the style is "foo"

&foo[:odt-style bar]{lorem ipsum} ==> the style is "bar". Same with the
anonymous variant &_[:odt-style bar]{lorem ipsum}.

- The three global attributes supported in the LaTeX and HTML backends
  are also supported in odt: `:lang', `:color' and `:smallcaps'. I have
  learned that these direct format elements are in odt "automatic
  styles", which must be declared before the body. I haven't thought of
  any other way to do it than using a list of automatic styles that is
  inserted inside `org-odt-template', with each export. Some examples with
  various combinations:

&foo[:color magenta :odt-style Bold]{this is magenta and bold}

&foo[:color red :odt-style Emphasis]{this is red and emphasis}

&Underline[:color green]{this is green and underline}

&foo[:color blue]{this is blue with &_[:smallcaps t]{smallcaps}}

And a screenshot: https://i.imgur.com/KNhYQrv.png

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: Experimental public branch for inline special blocks
  @ 2024-03-02 10:57 13%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-02 10:57 UTC (permalink / raw)
  To: emacs-orgmode

Hi, Stefan,

Stefan Nobis writes:

> first of all: Thank you for your great work. Looks really good.

You're welcome! :-)

> Just out of curiosity: Why a special syntax for alias expansion?
>
> From a syntax and user point of view, I think I would prefer a simpler
> syntax. So
>
>     &alias{text}
>
> would check if an alias is registered and if yes use it. This way it
> would be easier to change/add options later on without the need for
> changing all the inline-block commands and add a "!" (not a big deal,
> just two rather simple replace commands).

I think you're right. I have removed the need for "!" in the last
commit.

Now the syntax is:

&alias{text}

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Experimental public branch for inline special blocks
@ 2024-03-01 20:34  9% Juan Manuel Macías
                     ` (5 more replies)
  0 siblings, 6 replies; 200+ results
From: Juan Manuel Macías @ 2024-03-01 20:34 UTC (permalink / raw)
  To: orgmode

Hi,

Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:

<https://gitlab.com/maciaschain/org-mode.git>

The code incorporates fixes and modifications and I have also added some
ideas from Maxim Nikulin. The LaTeX and HTML backends are complete,
although of course it can still be perfected. Recapitulating the
necessary information:

The new element can be nested and supports other elements such as links,
macros, emphasis marks, etc.

The basic syntax:

┌────
│ &foo{lorem ipsum dolor}
└────

produces in LaTeX:

┌────
│ \foo{lorem ipsum dolor}
└────

and in HTML:

┌────
│ <span class="foo">lorem ipsum dolor</span>
└────

There is also an anonymous variant:

┌────
│ &_{lorem ipsum dolor}
└────

Optional attributes in square brackets are supported. There are a series
of 'universal' attributes, common to each backend. At the moment:
`:lang', `:color' and `:smallcaps'. Example:

┌────
│ &foo[:color red :smallcaps t :lang it]{lorem ipsum dolor}
└────

Specific to the LaTeX backend we have the `:prelatex' and `:postlatex'
attributes (which introduce arbitrary code before and after the content)
and `:latex-command', which overrides the exported command.
`:latex-command nocommand' does not export a command flag. Examples:

┌────
│ &foo[:prelatex [bar] :postlatex {baz} :lang it :latex-command blah]{lorem ipsum dolor}
└────

==>

┌────
│ \foreignlanguage{italian}{\blah[bar]{lorem ipsum dolor}{baz}}
└────

┌────
│ &_[:prelatex \foo{bar} :color red]{lorem ipsum dolor}
└────

==>

┌────
│ {\color{red}\foo{bar}lorem ipsum dolor}
└────

Likewise, for HTML we have the `:html-tag' and `:html-class' attributes
(which override the tags and the class name) and another one, more
generic, `:html', which introduces arbitrary code, such as
`style="..."'.

We can group lists of attributes as aliases. The syntax waould be:

┌────
│ &alias!{text}
└────

and we can also combine aliases with more single attributes:

┌────
│ &alias![more-attributes]{text}
└────

An example: let's imagine that we want a specific block for short quotes
in Latin and italics (it is normative in some typographical traditions
that quotes in classical Latin are put in italics instead of quotation
marks):

┌────
│ #+options: inline-special-block-aliases:(("latin" :lang "la" :latex-command "textit" :html-tag "em"))
│ 
│ Caesar's famous quote: &latin!{Alea iacta est}
│ 
│ Caesar's famous quote: &latin![:smallcaps t :color blue]{Alea iacta est}
└────

==> LaTeX:

┌────
│ Caesar's famous quote: \foreignlanguage{latin}{\textit{Alea iacta est}}
│ 
│ Caesar's famous quote: {\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
└────

== HTML:

┌────
│ Caesar's famous quote: <em lang="la" class="latin">Alea iacta est</em>
│ 
│ Caesar's famous quote: <em style="color:blue;font-variant:small-caps;" lang="la" class="latin">Alea iacta est</em>
└────


Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 9%]

* Re: [proof of concept] inline language blocks
  2024-02-29 12:05  5%                               ` Max Nikulin
@ 2024-02-29 12:50 10%                                 ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-29 12:50 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

>> Anyway, I think your example only makes sense in HTML, or at least I
>> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
>> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
>> does seem sensible to me that someone would want to change the tags.
>> Maybe with a :html-tag, or something like that.
>
> Consider a document aimed to be exported to different formats. It is
> unlikely that names of commands, elements, classes, etc. match for all
> of them.

It makes sense, although I have never encountered a case like this.
Usually (and returning to the example of the large special blocks), if
in org I put something like:

#+begin_foo
...
#+end_foo

I try to ensure that there is a "foo" environment in LaTeX, a "foo" class
in html or a "foo" style in odt (now I don't remember if the odt exporter
produces paragraph styles from special blocks. I don't think so).

In any case, on second thought, maybe someone wants to reuse a LaTeX
preamble, css style sheets or any odt templates. I see no problem, then,
in there being attributes like :latex-command, :html-tag, :odt-style :html-attribute,
etc., which override the default values.

>> As for :latex-command, if I understand it correctly, I don't quite see
>> how useful this could be:
>> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
>> when it is simpler to put:
>> &bar{text}
>
> Command may require additional arguments and it should be convenient
> to define shortcuts to the same command with different arguments:
>
> &la{text} => \foreignlanguage{latin}{text}
> &es{text} => \foreinglanguage{spanish}{text}

With the current implementation:

#+options: inline-special-block-aliases:(("bar" :prelatex [bar]) ("baz" :prelatex [baz]))

&foo[@bar@]{lorem ipsum} ==> \foo[bar]{lorem ipsum}
&foo[@baz@]{lorem ipsum} ==> \foo[baz]{lorem ipsum}

Your example is less verbose, but with this implementation you can do combinations, it's
more granular, I think:

&foo[@bar@ :smallcaps t]{lorem ipsum} ==> {\scshape\foo[bar]{lorem ipsum}}
&foo[@baz@ :lang it]{lorem ipsum} ==> \foo[baz]{\foreignlanguage{italian}{lorem ipsum}}

I think this is quite flexible and leaves a great deal of freedom to the user.

>> The same thing happens with the anonymous variant:
>> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
>> which is identical to putting &foo{text}
>> The anonymous variant would be equivalent in LaTeX to a
>> \begingroup...\endgroup, or rather to {...}. One could add all the
>> commands one wants within the group simply with :prelatex:
>> &_[:prelatex \foo\bar\vaz\blah{}]{text}
>> ==> {\foo\bar\vaz\blah{}text}
>
> The idea is to not add \begingroup and \endgroup if LaTeX command is
> specified (or to control it by a dedicated attribute). Again, consider
> a document suitable for multiple export formats.

Indeed, if the :latex-command attr is implemented should work in both
variants. In such a way, perhaps:

&_[:latex-command foo]{lorem} ==> \foo{lorem}

> I think, flexibility in respect to underlying
> commands/classes/elements allows to minimize changes in documents
> later. Sometimes it is necessary to switch to another LaTeX package,
> CSS framework, etc. It allows usage semantic names within Org
> documents despite they may be exported to the same command.
>
>> In any case, I think that my implementation leaves open the possibility
>> of extending it with everything you mentioned, or anything else.
>
> The question is proper balance of built-in features, flexibility,
> implementation complexity. It would be unfortunate if most of users
> will have to create custom backends even for basic documents.

We can continue the discussion when I publish my experimental branch and
share the link. I'm a little late because I want to make some
corrections to the code first.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía




^ permalink raw reply	[relevance 10%]

* Re: [proof of concept] inline language blocks
  2024-02-29 10:41 10%                             ` Juan Manuel Macías
@ 2024-02-29 12:05  5%                               ` Max Nikulin
  2024-02-29 12:50 10%                                 ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-02-29 12:05 UTC (permalink / raw)
  To: emacs-orgmode

On 29/02/2024 17:41, Juan Manuel Macías wrote:
> Max Nikulin writes:
>>
>> I do not try to dispute \foo and class="foo" as default behavior. I
>> suggest to implement possibility to override default behavior of
>> &foo{text} to \bar{text} and <bar>text</bar>. The same is applicable
>> for anonymous objects
>>
>>       &_[:latex_command bar :html_element bar]{text}
> 
> Maxim, I insist that I follow the logic of the "large" special blocks.

Export of special blocks may be extended as well.

> Anyway, I think your example only makes sense in HTML, or at least I
> can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
> passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
> does seem sensible to me that someone would want to change the tags.
> Maybe with a :html-tag, or something like that.

Consider a document aimed to be exported to different formats. It is 
unlikely that names of commands, elements, classes, etc. match for all 
of them.

> As for :latex-command, if I understand it correctly, I don't quite see
> how useful this could be:
> 
> &foo[:latex-command bar]{text} == LaTeX ==> \bar{text}
> 
> when it is simpler to put:
> 
> &bar{text}

Command may require additional arguments and it should be convenient to 
define shortcuts to the same command with different arguments:

&la{text} => \foreignlanguage{latin}{text}
&es{text} => \foreinglanguage{spanish}{text}

> The same thing happens with the anonymous variant:
> 
> &_[:latex-command foo]{text} == LaTeX ==> \foo{text}
> 
> which is identical to putting &foo{text}
> 
> The anonymous variant would be equivalent in LaTeX to a
> \begingroup...\endgroup, or rather to {...}. One could add all the
> commands one wants within the group simply with :prelatex:
> 
> &_[:prelatex \foo\bar\vaz\blah{}]{text}
> 
> ==> {\foo\bar\vaz\blah{}text}

The idea is to not add \begingroup and \endgroup if LaTeX command is 
specified (or to control it by a dedicated attribute). Again, consider a 
document suitable for multiple export formats.

I think, flexibility in respect to underlying commands/classes/elements 
allows to minimize changes in documents later. Sometimes it is necessary 
to switch to another LaTeX package, CSS framework, etc. It allows usage 
semantic names within Org documents despite they may be exported to the 
same command.

> In any case, I think that my implementation leaves open the possibility
> of extending it with everything you mentioned, or anything else.

The question is proper balance of built-in features, flexibility, 
implementation complexity. It would be unfortunate if most of users will 
have to create custom backends even for basic documents.



^ permalink raw reply	[relevance 5%]

* Re: [proof of concept] inline language blocks
  2024-02-29  7:05  6%                           ` Max Nikulin
@ 2024-02-29 10:41 10%                             ` Juan Manuel Macías
  2024-02-29 12:05  5%                               ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-29 10:41 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin writes:

>> the user should expect something like &foo{...} to produce \foo{...} or
>> <span class=foo>...</span>, etc. The only difference is that there would
>> be an anonymous variant &_{...}.
>
> I do not try to dispute \foo and class="foo" as default behavior. I
> suggest to implement possibility to override default behavior of
> &foo{text} to \bar{text} and <bar>text</bar>. The same is applicable
> for anonymous objects
>
>      &_[:latex_command bar :html_element bar]{text}

Maxim, I insist that I follow the logic of the "large" special blocks.

Anyway, I think your example only makes sense in HTML, or at least I
can't make sense of it in LaTeX. Why would anyone want &foo{text} to be
passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it
does seem sensible to me that someone would want to change the tags.
Maybe with a :html-tag, or something like that.

As for :latex-command, if I understand it correctly, I don't quite see
how useful this could be:

&foo[:latex-command bar]{text} == LaTeX ==> \bar{text}

when it is simpler to put:

&bar{text}

The same thing happens with the anonymous variant:

&_[:latex-command foo]{text} == LaTeX ==> \foo{text}

which is identical to putting &foo{text}

The anonymous variant would be equivalent in LaTeX to a
\begingroup...\endgroup, or rather to {...}. One could add all the
commands one wants within the group simply with :prelatex:

&_[:prelatex \foo\bar\vaz\blah{}]{text}

==> {\foo\bar\vaz\blah{}text}

I'm not opposed to your ideas, I just can't find a use case for it. In
LaTeX, I mean. In the case of HTML I find it useful, indeed, to have
more control over the tags: <foo></foo>, <bar></bar>, etc.

In any case, I think that my implementation leaves open the possibility
of extending it with everything you mentioned, or anything else. 


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 10%]

* Re: [proof of concept] inline language blocks
  2024-02-28 23:42  4%                         ` Juan Manuel Macías
@ 2024-02-29  7:05  6%                           ` Max Nikulin
  2024-02-29 10:41 10%                             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-02-29  7:05 UTC (permalink / raw)
  To: emacs-orgmode

Juan Manuel,

I am not against optional arguments. The idea is to make the feature 
more flexible and convenient for domain-specific documents. I did not 
use square brackets in my example to concentrate on the use case of 
concise and clear markup.

On 29/02/2024 06:42, Juan Manuel Macías wrote:
> Max Nikulin writes:
> 
>> #+options: custom-object(:type la :latex_element foreignlanguage
>> :latex_pre "{latin}")
> 
> mmm, I see it as not very flexible and perhaps too complicated for the user.

Do not concentrate on \foreignlanguage. I am using it just because the 
thread was started from markup suitable for mixed-language texts.

> the user should expect something like &foo{...} to produce \foo{...} or
> <span class=foo>...</span>, etc. The only difference is that there would
> be an anonymous variant &_{...}.

I do not try to dispute \foo and class="foo" as default behavior. I 
suggest to implement possibility to override default behavior of
&foo{text} to \bar{text} and <bar>text</bar>. The same is applicable for 
anonymous objects

      &_[:latex_command bar :html_element bar]{text}

> class in HTML

HTML has a number of elements for semantic markup, e.g. <kbd>, <var>, 
<abbr>, etc. I hope, they can be supported in addition to default <span>.




^ permalink raw reply	[relevance 6%]

* Re: [proof of concept] inline language blocks
  2024-02-28 17:21  6%                       ` Max Nikulin
@ 2024-02-28 23:42  4%                         ` Juan Manuel Macías
  2024-02-29  7:05  6%                           ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-28 23:42 UTC (permalink / raw)
  To: orgmode

Max Nikulin writes:

> #+options: custom-object(:type la :latex_element foreignlanguage 
> :latex_pre "{latin}")

mmm, I see it as not very flexible and perhaps too complicated for the user.

My idea with the concept of inline-special-block is that it is like the
inline version of its older brother. If something like

#+begin_foo
...
#+end_foo

produces things like

\begin{foo}
...
\end{foo}

or

<div class="foo">
...
</div>

the user should expect something like &foo{...} to produce \foo{...} or
<span class=foo>...</span>, etc. The only difference is that there would
be an anonymous variant &_{...}.

The attributes syntax (in square brackets) adds verbosity, but I
understand that it is also very flexible and granular. It doesn't need
to be used always, but at least it's there when you need to use it.
Furthermore, the user can always define lists of attributes (styles or
aliases: I would have preferred the term "style", instead of "alias",
but I fear that it will be confused with the HTML attribute of the same
name). Furthermore, these lists of attributes can also be used in
combination with other single attributes, giving rise to a great
possibility of combinations. The fact that there are a number of
universal attributes such as :lang, :color, :smallcaps prevents the user
from having to figure out which code to use on each backend to produce
colored text, small caps or the correct language selector. ":lang ru",
for example, will always produce in LaTeX \foreignlanguage{russian}{}
(which, in addition, is a command shared by babel and polyglossia) and
in HTML lang="ru".

And ultimately you could also think about some kind of folding for the
attributes part.

I believe that this possible new element would solve the need for a
native, multipurpose inline text container with properties[1], which
until now could only be achieved through macros or links, with the
limitations of both elements.

Additionally, I think this approach is more flexible than having
specific purpose blocks (for languages, colors, etc.).

Of course, it would be best not to abuse the attributes. If in a
long document one needs to put a single sentence in red, I don't think
it is a verbosity problem to put something like &_[:color red]{lorem
ipsum dolor}. If you need to put a lot of sentences in red or any other
color, it may be a better idea to define some command in LaTeX
(\redtext), a class in HTML or a character style in odt. And then it
would be enough to use &redtext{lorem ipsum dolor}.

[1] Pandoc has the "bracketed spans". According to pandoc manual:

#+begin_quote

A bracketed sequence of inlines, as one would use to begin
a link, will be treated as a Span with attributes if it is followed
immediately by attributes:

[This is *some text*]{.class key="val"}

#+end_quote




^ permalink raw reply	[relevance 4%]

* Re: [proof of concept] inline language blocks
  2024-02-28 13:15  4%                     ` Juan Manuel Macías
@ 2024-02-28 17:21  6%                       ` Max Nikulin
  2024-02-28 23:42  4%                         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-02-28 17:21 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 28/02/2024 20:15, Juan Manuel Macías wrote:
> #+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))
> 
> This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.

It is more verbose than &la{lorem ipsum dolor sit amet}. My idea is to 
allow latex commands other than object type ("la" this case). Something like

#+options: custom-object(:type la :latex_element foreignlanguage 
:latex_pre "{latin}")



^ permalink raw reply	[relevance 6%]

* Re: [proof of concept] inline language blocks
  2024-02-28 10:29  7%                   ` Max Nikulin
@ 2024-02-28 13:15  4%                     ` Juan Manuel Macías
  2024-02-28 17:21  6%                       ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-28 13:15 UTC (permalink / raw)
  To: Max Nikulin; +Cc: orgmode

Max Nikulin writes:

> Juan Manuel your ":fr{}" and similar objects is a domain-specific
> language that is quite different from a generic element proposed by
> Samuel. Do you think it makes sense to modify your inline special
> block patch to allow creation of concise DSL?
>
> Juan Manuel Macías. [testing patch] inline-special-block with full
> implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +0000.
> https://list.orgmode.org/87ttlyloyr.fsf@posteo.net
>
> I mean &fr{bonjour} defined using "#+options:" or some new keyword or
> a special block. A definition of "fr" may be (using a bit different
> names)
>
> :latex_element "foreignlanguage" :latex_prefix "french"
> :html_element "span" :html_attr (:lang "fr")
>
> &fr{} is no heavier than :fr{}. The only drawback is necessity to
> define elements for each language used in the document. I do not
> think, even a dozen of declarations is a significant burden.

Hi, Maxim,

In the end I abandoned the concept of inline language block to the
detriment of the more general concept of inline special block (as,
rightly, proposed Ihor). I feel that at the beginning both concepts
overlapped. The patch you mention deals exclusively with the inline
special block concept, as well as the experimental branch that I hope to
publish shortly.

The syntax of my approach, summarized, would be:

-basic form: &foo[optional attributes]{lorem ipsum dolor}

==> LaTeX \foo{lorem ipsum dolor} ; ==> HTML <span class="foo">lorem
ipsum dolor</span>

- anonymous variant: &_{lorem ipsum dolor}

Common to all backends (so far I have only implemented LaTeX and HTML)
are a series of universal attributes. At the moment I have thought about
the following: :lang, :smallcaps and :color. For example:

&foo[:lang el :color blue :smallcaps t]{contents}

==> LaTeX:

{\scshape\color{blue}\foreignlanguage{greek}{\foo{contents}}}

==> HTML

<span class="foo" lang="el" style="color:blue;font-variant:small-caps;">contents</span>

There is also the :html attribute and for LaTeX the :prelatex and
:postlatex attributes. Groups of attributes can also be defined, as if
they were styles, and combined with single attributes:

#+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))

This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.

This is an example of Latin text with small caps: &_[@latin@ :smallcaps t]{lorem ipsum dolor sit amet}.

==> LaTeX:

This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.

This is an example of Latin text with small caps: {\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}

==> HTML:

This is an example of Latin text: <span style="color:blue;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.

This is an example of Latin text with small caps: <span style="color:blue;font-variant:small-caps;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.




^ permalink raw reply	[relevance 4%]

* Re: [proof of concept] inline language blocks
  2024-02-21 23:02 10%                 ` Juan Manuel Macías
@ 2024-02-28 10:29  7%                   ` Max Nikulin
  2024-02-28 13:15  4%                     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Max Nikulin @ 2024-02-28 10:29 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 22/02/2024 06:02, Juan Manuel Macías wrote:
> Samuel Wales writes:
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
> 
> To expand a little more... Another problem I see in your example is
> nesting. In my proposal, the blocks can be nested:
> 
> :fr{text in French and :it{text in Italian}}
> 
> But I would find this difficult to read:
> 
> $[lang :fr "text in French and $[lang :it "text in italian"]"]

Juan Manuel your ":fr{}" and similar objects is a domain-specific 
language that is quite different from a generic element proposed by 
Samuel. Do you think it makes sense to modify your inline special block 
patch to allow creation of concise DSL?

Juan Manuel Macías. [testing patch] inline-special-block with full 
implementation for LaTeX backend. Fri, 23 Feb 2024 23:50:52 +0000. 
https://list.orgmode.org/87ttlyloyr.fsf@posteo.net

I mean &fr{bonjour} defined using "#+options:" or some new keyword or a 
special block. A definition of "fr" may be (using a bit different names)

:latex_element "foreignlanguage" :latex_prefix "french"
:html_element "span" :html_attr (:lang "fr")

&fr{} is no heavier than :fr{}. The only drawback is necessity to define 
elements for each language used in the document. I do not think, even a 
dozen of declarations is a significant burden.


^ permalink raw reply	[relevance 7%]

* Re: A question about local/experimental branches
  @ 2024-02-27  9:57 10%         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-27  9:57 UTC (permalink / raw)
  To: Bastien Guerry; +Cc: Ihor Radchenko, orgmode

Hi, Bastien,

Bastien Guerry writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> AFAIU, Juan does not have write access to savannah.
>> Should we give it? Of course, if he is willing to use savannah. Any
>> other public repo is also fine.
>
> Juan, let me know if you need access:
> https://orgmode.org/worg/org-contribute.html#devs

Thank you! I think for the moment I will use GitLab to publish my
experimental branch, if it is not essential to do it in savannah (I am
more used to gitlab). As soon as I publish it, I'll share the
link.

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 10%]

* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
  2024-02-26 10:32 13% ` Juan Manuel Macías
  2024-02-26 11:03  5%   ` Ihor Radchenko
@ 2024-02-26 12:58  6%   ` Bastien Guerry
  1 sibling, 0 replies; 200+ results
From: Bastien Guerry @ 2024-02-26 12:58 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: emacs-orgmode

Hi Juan,

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

> Great! Just one question: can articles be shared in languages other than
> English? In that case, would it be necessary to add some more
> prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?

Yes, you can use "[BLOG] [Spanish] ..." so that people adapt their
filters, but the second prefix won't have any effect on Woof.

But because the language for discussing on this list is english, I
believe the summary should be in english - then people can use i18n
tools to get to the contents.

How does this sound?

-- 
 Bastien Guerry


^ permalink raw reply	[relevance 6%]

* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
  2024-02-26 10:32 13% ` Juan Manuel Macías
@ 2024-02-26 11:03  5%   ` Ihor Radchenko
  2024-02-26 12:58  6%   ` Bastien Guerry
  1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-02-26 11:03 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Bastien, emacs-orgmode

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

> Great! Just one question: can articles be shared in languages other than
> English? In that case, would it be necessary to add some more
> prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?
>
> (If I shared something in Spanish, I could translate the article in the
> body of the message).

In Sacha Chua's news non-English blog posts are just shared as is:
2023年のorg-mode活用と今後の抱負 - takeokunn's blog (@kaneuchi@mstdn.jp)
(from https://sachachua.com/blog/2024/01/2024-01-29-emacs-news/)

As long as the fraction of non-English posts is small, I do not think
that it matters too much. (Of course, having a translation would be
helpful, but we cannot demand such thing.)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix
  @ 2024-02-26 10:32 13% ` Juan Manuel Macías
  2024-02-26 11:03  5%   ` Ihor Radchenko
  2024-02-26 12:58  6%   ` Bastien Guerry
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-26 10:32 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

Bastien writes:

> Adding [BLOG] or [TIP] in the subject prefix allows for such messages
> to be referenced on https://tracker.orgmode.org/news (along with [ANN]
> messages). 
>
> It will then be possible to include these posts in the orgmode.org
> homepage, using e.g. https://tracker.orgmode.org/news.rss.
>
> This is experimental, let's see if this helps spread the word about
> useful blogs.

Great! Just one question: can articles be shared in languages other than
English? In that case, would it be necessary to add some more
prefixes, such as "Spanish", "French", "Italian", "Greek", etc.?

(If I shared something in Spanish, I could translate the article in the
body of the message).

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: A question about local/experimental branches
  2024-02-25 14:05  6% ` Ihor Radchenko
@ 2024-02-25 15:10 12%   ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-25 15:10 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Bastien, orgmode

Ihor Radchenko writes:

> P.S. Juan, I will need some time to review previous discussions on
> inline special blocks before I can comment on your work in depth.

No problem, Ihor. These days I had enough free time to develop my idea,
translate it into code and get something usable from which it could be
discussed. As I mentioned, the export to HTML and LaTeX is complete and
works fine, but I'll probably stop there for a long time. I mean, I
won't go any further and I will dedicate myself to continuing testing
the code already written and fixing possible bugs. Partly because I
don't have enough knowledge of odt to work on this backend, which would
be the next step.

Thanks for the info!

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 12%]

* Re: A question about local/experimental branches
  2024-02-25 13:53 11% A question about local/experimental branches Juan Manuel Macías
@ 2024-02-25 14:05  6% ` Ihor Radchenko
  2024-02-25 15:10 12%   ` Juan Manuel Macías
    0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-02-25 14:05 UTC (permalink / raw)
  To: Juan Manuel Macías, Bastien; +Cc: orgmode

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

> I've noticed that the code for my implementation of the new
> 'inline-special-block' experimental element is growing. In addition, I
> introduce modifications and improvements daily. So I think it might be a
> good idea to make my local branch public, in case someone wants to try
> it or contribute to the project.
>
> My question is if there is any set of good practices to do this, or is
> it enough to publish the local branch 'as is'.

See https://orgmode.org/worg/org-contribute.html#orgfd0d3cb
You can just share the link to your branch.

I am not sure if experimental branches can go directly to our savannah,
like what Emacs does.
Bastien, WDYT?

P.S. Juan, I will need some time to review previous discussions on
inline special blocks before I can comment on your work in depth.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* A question about local/experimental branches
@ 2024-02-25 13:53 11% Juan Manuel Macías
  2024-02-25 14:05  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-25 13:53 UTC (permalink / raw)
  To: orgmode

Hi,

I've noticed that the code for my implementation of the new
'inline-special-block' experimental element is growing. In addition, I
introduce modifications and improvements daily. So I think it might be a
good idea to make my local branch public, in case someone wants to try
it or contribute to the project.

My question is if there is any set of good practices to do this, or is
it enough to publish the local branch 'as is'.

Currently I have completed, and are perfectly usable, the export to
LaTeX and HTML. I have also improved the syntax. Now, if aliases are
used for group optional attributes, it is not necessary to put :alias
foo, but @foo@. Example:

  #+options: inline-special-block-aliases:(("latin" :lang "la" :color blue :prelatex "\\itshape " :html "style=\"font-style:italic;\""))

  This is an example of Latin text: &_[@latin@]{lorem ipsum dolor sit amet}.

  This is an example of Latin text with small caps: &_[@latin@ :smallcaps t]{lorem ipsum dolor sit amet}.

LaTeX ==>

  This is an example of Latin text: {\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}.

  This is an example of Latin text with small caps: {\scshape{}\color{blue}\foreignlanguage{latin}{\itshape lorem ipsum dolor sit amet}}

HTML ==>

  This is an example of Latin text: <span style="color:blue;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.

  This is an example of Latin text with small caps: <span style="color:blue;font-variant:small-caps;font-style:italic;" lang="la">lorem ipsum dolor sit amet</span>.


Related: https://list.orgmode.org/87ttlyloyr.fsf@posteo.net/

Best regards,

Juan Manuel

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com



^ permalink raw reply	[relevance 11%]

* [testing patch] inline-special-block with full implementation for LaTeX backend
@ 2024-02-23 23:50  4% Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-23 23:50 UTC (permalink / raw)
  To: orgmode

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

This patch is for testing purposes only, although the implementation for
LaTeX backend is perfectly usable.

The basic syntax of the new element is:

&foo{lorem ipsum dolor}

=> LaTeX: \foo{lorem ipsum dolor}

Nested elements are possible, as well as the inclusion of other elements
such as macros, links or emphasis marks.

The element also supports a list of optional arguments. For the LaTeX
backend there are two specific arguments: :prelatex and :postlatex.
Example:

&foo[:prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}

=> LaTeX: \foo[bar]{lorem ipsum dolor}{baz}

Additionally, there are a number of universal arguments that should be
equivalent between backends where it makes sense to use them (LaTeX,
HTML, odt...). At the moment you can use: :color, :lang and :smallcaps.
Example:

&foo[:color red :smallcaps t :lang french :prelatex [bar] :postlatex {baz}]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{red}\foreignlanguage{french}{\foo[bar]{lorem ipsum dolor}{baz}}}

The element also has an anonymous variant that only accepts universal
arguments. If set without arguments it simply returns the content
string. Example:

&_[:color blue :lang italian]{lorem ipsum dolor}

=> LaTeX: {\color{blue}\foreignlanguage{italian}{lorem ipsum dolor}}

We can define in the document a list of aliases that group several arguments:

#+options: inline-special-block-aliases:(("myalias" :color "magenta" :lang "klingon") ("myalias2" :smallcaps t :color "blue" :prelatex "{2345}")) 

&_[:alias myalias :smallcaps t]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{magenta}\foreignlanguage{klingon}{lorem ipsum dolor}}

&foo[:alias myalias2]{lorem ipsum dolor}

=> LaTeX: {\scshape{}\color{blue}\foo{2345}{lorem ipsum dolor}}

There can only be one alias per element, but an alias can be combined
with other attributes. It is the closest thing to using styles,
and perhaps the most appropriate term would be ":style". But you can get
confused with the html "style" attribute.

Best regards,

Juan Manuel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-element.el-New-element-Inline-Special-Block.patch --]
[-- Type: text/x-patch, Size: 9498 bytes --]

From d211bf601db0dd5c01a3edda74cd1b37f1f9448c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block.

* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
* lisp/ox.el (org-export-read-inline-special-block-attributes): read
optional attributes.
* lisp/ox.el (org-export-inline-special-block-aliases): aliases for grouped attributes.
---
 lisp/org-element.el | 55 ++++++++++++++++++++++++++++++++++++++++++++-
 lisp/ox-latex.el    | 36 +++++++++++++++++++++++++++++
 lisp/ox.el          | 30 +++++++++++++++++++++++++
 3 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..c430d934b 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
 			       "\\|"))
 		      ;; Objects starting with "@": export snippets.
 		      "@@"
+                      ;; Objects starting with "&": inline-special-blocks.
+                      "&"
 		      ;; Objects starting with "{": macro.
 		      "{{{"
 		      ;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
   "List of recursive element types aka Greater Elements.")
 
 (defconst org-element-all-objects
-  '(bold citation citation-reference code entity export-snippet
+  '(bold citation citation-reference code entity export-snippet inline-special-block
 	 footnote-reference inline-babel-call inline-src-block italic line-break
 	 latex-fragment link macro radio-target statistics-cookie strike-through
 	 subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
       ;; Ignore inline babel call and inline source block as formulas
       ;; are possible.  Also ignore line breaks and statistics
       ;; cookies.
+      (inline-special-block ,@standard-set)
       (table-cell citation export-snippet footnote-reference link macro
                   radio-target target timestamp ,@minimal-set)
       (table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
 	  (org-element-property :name entity)
 	  (when (org-element-property :use-brackets-p entity) "{}")))
 
+;;;; inline special block
+
+(defun org-element-inline-special-block-parser ()
+  "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties.  Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+  (save-excursion
+    (when (looking-at "&\\([_A-Za-z]+\\)[{[]")
+      (goto-char (- (match-end 0) 1))
+      (let* ((begin (match-beginning 0))
+             (parameters
+              (let ((p (org-element--parse-paired-brackets ?\[)))
+                (and (org-string-nw-p p)
+                     (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)))))
+             (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+             (type (org-element--get-cached-string
+                    (match-string-no-properties 1)))
+             (contents-end
+              (progn
+                (goto-char (- contents-begin 1))
+                (org-element--parse-paired-brackets ?\{)
+                (- (point) 1)))
+             (post-blank (skip-chars-forward " \t"))
+             (end (point)))
+        (when contents-end
+          (org-element-create
+           'inline-special-block
+           (list :type type
+                 :parameters parameters
+                 :contents-begin contents-begin
+                 :contents-end contents-end
+                 :begin begin
+                 :end end
+                 :post-blank post-blank)))))))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+  "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+  (let ((type (org-element-property :type inline-special-block))
+        (opts (org-element-property :parameters inline-special-block)))
+    (format "&%s%s{%s}"
+            type
+            (if opts (format "[%s]" opts) "")
+            contents)))
 
 ;;;; Export Snippet
 
@@ -5260,6 +5311,8 @@ to an appropriate container (e.g., a paragraph)."
 			          (org-element-strike-through-parser)))
 		         (?@ (and (memq 'export-snippet restriction)
 			          (org-element-export-snippet-parser)))
+                         (?& (and (memq 'inline-special-block restriction)
+                                  (org-element-inline-special-block-parser)))
 		         (?{ (and (memq 'macro restriction)
 			          (org-element-macro-parser)))
 		         (?$ (and (memq 'latex-fragment restriction)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..c0161716b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -101,6 +101,7 @@
     (underline . org-latex-underline)
     (verbatim . org-latex-verbatim)
     (verse-block . org-latex-verse-block)
+    (inline-special-block . org-latex-inline-special-block)
     ;; Pseudo objects and elements.
     (latex-math-block . org-latex-math-block)
     (latex-matrices . org-latex-matrices))
@@ -2095,6 +2096,41 @@ holding contextual information."
    center-block (format "\\begin{center}\n%s\\end{center}" contents) info))
 
 
+;;;; Inline Special Block
+
+(defun org-latex-inline-special-block (inline-special-block contents info)
+  "Transcode an INLINE SPECIAL BLOCK element from Org to LaTeX.
+CONTENTS holds the contents of the block.  INFO is a plist
+holding contextual information."
+  (let* ((type (org-element-property :type inline-special-block))
+         (type-is-anon (string= "_" type))
+	 (parameters (org-element-property :parameters inline-special-block))
+	 (attributes (org-export-read-inline-special-block-attributes parameters))
+         (alias (plist-get attributes :alias))
+         (alias-plist (when alias (cdr (or (assoc alias (plist-get info :inline-special-block-aliases))
+					   (assoc alias org-export-inline-special-block-aliases)))))
+	 (basic-format (if type-is-anon
+                           (format "%s" contents)
+                         (format "\\%s{%s}" type contents))))
+    (if (not attributes)
+        basic-format
+      (let* ((attr-final (if alias-plist (append attributes alias-plist) attributes))
+             (prelatex (plist-get attr-final :prelatex))
+	     (postlatex (plist-get attr-final :postlatex))
+	     (color (plist-get attr-final :color))
+	     (smallcaps (plist-get attr-final :smallcaps))
+	     (lang (plist-get attr-final :lang)))
+        (concat
+         (when (or color smallcaps type-is-anon) "{")
+         (when smallcaps "\\scshape{}")
+         (when color (format "\\color{%s}" color))
+         (when lang (format "\\foreignlanguage{%s}{" lang))
+         (if (not (or prelatex postlatex))
+	     basic-format
+	   (concat "\\" type prelatex "{" contents "}" postlatex))
+         (when lang "}")
+         (when (or color smallcaps type-is-anon) "}"))))))
+
 ;;;; Clock
 
 (defun org-latex-clock (clock _contents info)
diff --git a/lisp/ox.el b/lisp/ox.el
index 5bf55ec3b..cbb6a8dcd 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -149,6 +149,7 @@
     (:with-tasks nil "tasks" org-export-with-tasks)
     (:with-timestamps nil "<" org-export-with-timestamps)
     (:with-title nil "title" org-export-with-title)
+    (:inline-special-block-aliases nil "inline-special-block-aliases" org-export-inline-special-block-aliases)
     (:with-todo-keywords nil "todo" org-export-with-todo-keywords)
     ;; Citations processing.
     (:cite-export "CITE_EXPORT" nil org-cite-export-processors))
@@ -528,6 +529,11 @@ This option can also be set with the LANGUAGE keyword."
   :type '(string :tag "Language")
   :safe #'stringp)
 
+(defcustom org-export-inline-special-block-aliases nil
+  "TODO"
+  :group 'org-export-general
+  :type '(alist :value-type (group plist)))
+
 (defcustom org-export-preserve-breaks nil
   "Non-nil means preserve all line breaks when exporting.
 This option can also be set with the OPTIONS keyword,
@@ -3789,6 +3795,30 @@ will become the empty string."
 		(cdr (nreverse (cons (funcall prepare-value s) result))))))))
     (if property (plist-get attributes property) attributes)))
 
+(defun org-export-read-inline-special-block-attributes (attributes)
+  "TODO"
+  (let* ((prepare-value
+	  (lambda (str)
+	    (save-match-data
+	      (cond ((member str '(nil "" "nil")) nil)
+		    ((string-match "^\"\\(\"+\\)?\"$" str)
+		     (or (match-string 1 str) ""))
+		    (t str)))))
+	 (attributes
+	  (let ((value (list attributes)))
+	    (when value
+	      (let ((s (mapconcat #'identity value " ")) result)
+		(while (string-match
+			"\\(?:^\\|[ \t]+\\)\\(:[-a-zA-Z0-9_]+\\)\\([ \t]+\\|$\\)"
+			s)
+		  (let ((value (substring s 0 (match-beginning 0))))
+		    (push (funcall prepare-value value) result))
+		  (push (intern (match-string 1 s)) result)
+		  (setq s (substring s (match-end 0))))
+		;; Ignore any string before first property with `cdr'.
+		(cdr (nreverse (cons (funcall prepare-value s) result))))))))
+    attributes))
+
 (defun org-export-get-caption (element &optional short)
   "Return caption from ELEMENT as a secondary string.
 
-- 
2.43.2


^ permalink raw reply related	[relevance 4%]

* Re: [proof of concept] inline-special-block
  2024-02-21 20:32  8%             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
  2024-02-21 23:29 12%               ` [proof of concept] inline-special-block Juan Manuel Macías
@ 2024-02-22 22:03 13%               ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-22 22:03 UTC (permalink / raw)
  To: orgmode

Juan Manuel Macías writes:

> Regarding the "optional parameters", there is nothing defined, although
> I think they should be adapted to each backend. A possible use that
> occurs to me:
>
> &foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}
>
> This should produce in LaTeX:
>
> \foo[lorem]{blah blah}{ipsum}
>
> and in HTML:
>
> <span class="foo" style="color:red;">blah blah</span>

Just to add some more ideas about parameters, I can also think of an
"anonymous" variant that only supports "universal" arguments, independent of
the backend and previously defined (and extensible by the user). For
example:

&_[:color red :smallcaps t :lang it :size small]{Lorem ipsum dolor}

Aliases could also be defined for a set of arguments:

#+OPTIONS: inlineblocks:(("myblock" :smallcaps t :color "red" :lang "fr"))

&_[:myblock t]{Lorem ipsum dolor} etc.

==> latex: {\color{red}\scshape\foreignlanguage{french}{Lorem ipsum dolor}}

Universal arguments can also be added to a normal block along with each
backend's own arguments:

&foo[:color red :prelatex [bar]]{lorem ipsum dolor}

==> latex: {\color{red}\foo[bar]{lorem ipsum dolor}}

and, of course, aliases could be combined with single arguments:

&foo[:myblock t :prelatex [bar]]{lorem ipsum dolor}

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: [proof of concept] inline language blocks
  2024-02-21 12:53 10%       ` Juan Manuel Macías
  2024-02-21 13:10  5%         ` Ihor Radchenko
@ 2024-02-21 23:33  6%         ` Suhail Singh
  1 sibling, 0 replies; 200+ results
From: Suhail Singh @ 2024-02-21 23:33 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

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

> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block &type{text}

Why not &:lang{text} (and/or &:lang[options]{text}) instead?  In fact,
it might help (in that it may reduce the need for escaping within the
"text") if the syntax was &:type{text} with "lang" being one of the
possible type (as opposed to the type being ":lang").

-- 
Suhail


^ permalink raw reply	[relevance 6%]

* Re: [proof of concept] inline-special-block
  2024-02-21 20:32  8%             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
@ 2024-02-21 23:29 12%               ` Juan Manuel Macías
  2024-02-22 22:03 13%               ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 23:29 UTC (permalink / raw)
  To: orgmode

Juan Manuel Macías writes:

> Syntax:
>
> &[optional parameters]{contents}

Correction:

&type[optional parameters]{contents}


^ permalink raw reply	[relevance 12%]

* Re: [proof of concept] inline language blocks
  2024-02-21 22:28 13%               ` Juan Manuel Macías
  2024-02-21 22:55  6%                 ` Samuel Wales
@ 2024-02-21 23:02 10%                 ` Juan Manuel Macías
  2024-02-28 10:29  7%                   ` Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-21 23:02 UTC (permalink / raw)
  To: Samuel Wales; +Cc: Ihor Radchenko, orgmode

Samuel Wales writes:

> for language feature, there are various options here which range from e.g.

> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]
>

To expand a little more... Another problem I see in your example is
nesting. In my proposal, the blocks can be nested:

:fr{text in French and :it{text in Italian}}

But I would find this difficult to read:

$[lang :fr "text in French and $[lang :it "text in italian"]"]

On the other hand, the structure that I have chosen is in part inspired
by the inline code block, which is the only case of "inline block" that
we have in Org.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [proof of concept] inline language blocks
  2024-02-21 22:28 13%               ` Juan Manuel Macías
@ 2024-02-21 22:55  6%                 ` Samuel Wales
  2024-02-21 23:02 10%                 ` Juan Manuel Macías
  1 sibling, 0 replies; 200+ results
From: Samuel Wales @ 2024-02-21 22:55 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

yes as i said emphasis is convenient.

On 2/21/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Samuel Wales writes:
>
>> for language feature, there are various options here which range from
>> e.g.
>>
>> :fr{some text in French}
>>
>> being expressed as
>>
>> $[lang :fr "bonjour"]
>
> Thanks for your interesting comment. However, your example still seems
> too verbose to me. There are two elements that, in my opinion, get in
> the way: 'lang' and "bonjour" quotes. Imagine something like this for
> emphasis (mutatis mutandis):
>
> $[emphasis :italic "text in italic"]
>
> instead of
>
> /text in italic/.
>
> That simplicity is what I intend to look for with this type of elements
> inside the paragraph.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com


^ permalink raw reply	[relevance 6%]

* Re: [proof of concept] inline language blocks
  2024-02-21 22:11  4%             ` [proof of concept] inline language blocks Samuel Wales
@ 2024-02-21 22:28 13%               ` Juan Manuel Macías
  2024-02-21 22:55  6%                 ` Samuel Wales
  2024-02-21 23:02 10%                 ` Juan Manuel Macías
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 22:28 UTC (permalink / raw)
  To: Samuel Wales; +Cc: Ihor Radchenko, orgmode

Samuel Wales writes:

> for language feature, there are various options here which range from e.g.
>
> :fr{some text in French}
>
> being expressed as
>
> $[lang :fr "bonjour"]

Thanks for your interesting comment. However, your example still seems
too verbose to me. There are two elements that, in my opinion, get in
the way: 'lang' and "bonjour" quotes. Imagine something like this for
emphasis (mutatis mutandis):

$[emphasis :italic "text in italic"]

instead of

/text in italic/.

That simplicity is what I intend to look for with this type of elements
inside the paragraph.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía




^ permalink raw reply	[relevance 13%]

* Re: [proof of concept] inline language blocks
  2024-02-21 14:13 12%           ` Juan Manuel Macías
  2024-02-21 20:32  8%             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
@ 2024-02-21 22:11  4%             ` Samuel Wales
  2024-02-21 22:28 13%               ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Samuel Wales @ 2024-02-21 22:11 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

at risk of being like a broken record [over many years]: i still like
cl lambda lists e.g. $[thing arg :kw value :kw value] or %(thing ...)
for allowing generality to basically all new syntax of most types,
extensibility, user-defined major ["thing"] and minor [":kw"] features
if desired to support, reduced parsing risk, ability to control
display and export and visibility and folding and other stuff like
locale or whatever, nestability, escaping/quoting, and familiar
defined syntax, all applicable to new features without having to
change anything.  also, you won't have to look up how to use it much
when you use a new feature.

i'm not expressing this as well as i have in unpublished posts or
previous posts.

i might be in the minority, and it was once said that it is too
verbose.  if so, i value desiderata like the above higher.

i feel org has proliferated different syntaxes and special cases a bit
too much.  it's hard to have to look up what's needed, detect errors
manually etc.  some of the more basic  things are good with special
syntax, such as emphasis and \\.  but we contend with invisible space,
variant quoting, ....

there is a school of thought that more types of syntax are usually
good; in most cases, i do not agree with that school of thought.

it's a bit like the old conflict between lisp vs. the original perl.
i never agreed with larry wall on arguments like [paraphrased,
possibly not correctly] "english is not orthogonal; lisp is, which is
bad; perl is not orthogonal; it shouldn't be because english isn't [or
perhaps for the [unspecified] reasons english isn't]".  plenty of
human languages are orthogonal in places where english isn't, and i
believe they work well in those places because of, not in spite of,
that convenient orthogonality.  you can know how to get the transitive
if you have the intransitve, for example.  i say this despite being a
huge fan of english.


for language feature, there are various options here which range from e.g.

:fr{some text in French}

being expressed as

$[lang :fr "bonjour"]

which i think is pretty straightforward and not much more verbose,

to a more block style like this

$[lang :fr :start]
bonjour
$[lang :fr end]

and of course that "lang" can be replaced with any other new feature
we dream up, having nothing to do with languages.  all the
meta-features like parsing, quoting, invisibility, folding,
nestability, extensibility will already have been worked out, and will
apply to new features and sub-features.


On 2/21/24, Juan Manuel Macías <maciaschain@posteo.net> wrote:
> Ihor Radchenko writes:
>
>> Juan Manuel Macías <maciaschain@posteo.net> writes:
>>
>>>> We need to finalize inline special block syntax first, and then talk
>>>> about special cases like inline language markup you propose.
>>>
>>> As I already said, in my local branch I have both elements created,
>>> based on the same syntax:
>>>
>>> - language block: :lang{text}
>>>
>>> - special block &type{text}
>>>
>>> the latter would be exported, for example, to html as <span
>>> class="type">text</span> or to LaTeX as \type{text}
>>>
>>> I like the syntax because it is minimalist and not verbose at all. That
>>> could serve as a basis (at least it is good to have a starting point,
>>> because otherwise everything will be diluted in discussions). Then we
>>> can start thinking about whether to add options and how to add them.
>>
>> We do not need to design the inline special block markup fully to
>> introduce it. However, we do need to make sure that whatever simple
>> version of inline markup we introduce does not prevent further planned
>> extensions.
>
> My proposed syntax could be:
>
> &type[options]{content}
>
>> My main concern is the possibility to introduce multi-argument markup.
>> Like @abbrev{EA}{example abbreviation}. This will be necessary to
>> achieve parity with Texinfo markup.
>> However, it is not yet clear about the best syntax to pass multiple
>> arguments.
>
> I imagine multiple arguments would depend on each backend, right?
> Because I don't quite see much sense in html, for example. However, it
> occurs to me to reuse content, and add some separator character:
>
> &type[options]{arg1::arg2::etc}
>
> or better:
>
> &type[options and aditional args]{content}
>
> to maintain a certain parallelism with the large blocks.
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
> editorial y ortotipografía
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com


^ permalink raw reply	[relevance 4%]

* [proof of concept] inline-special-block (was: [proof of concept] inline language blocks)
  2024-02-21 14:13 12%           ` Juan Manuel Macías
@ 2024-02-21 20:32  8%             ` Juan Manuel Macías
  2024-02-21 23:29 12%               ` [proof of concept] inline-special-block Juan Manuel Macías
  2024-02-22 22:03 13%               ` Juan Manuel Macías
  2024-02-21 22:11  4%             ` [proof of concept] inline language blocks Samuel Wales
  1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 20:32 UTC (permalink / raw)
  To: orgmode

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

I am attaching a patch in case anyone wants to try this proposal. A
function for ox-latex is included.

Syntax:

&[optional parameters]{contents}

With this patch, something like &foo{lorem ipsum dolor} is exported to
LaTeX as \foo{lorem ipsum dolor}.

Blocks can be nested, e.g.: &foo{lorem ipsum &bar{dolor}}.

Regarding the "optional parameters", there is nothing defined, although
I think they should be adapted to each backend. A possible use that
occurs to me:

&foo[prelatex: [lorem] postlatex: {ipsum} html: style="color:red;"]{blah blah}

This should produce in LaTeX:

\foo[lorem]{blah blah}{ipsum}

and in HTML:

<span class="foo" style="color:red;">blah blah</span>

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-element.el-New-element-Inline-Special-Block-proo.patch --]
[-- Type: text/x-patch, Size: 5762 bytes --]

From 587e77feb1c4e6881d527d1fd3a6e541efb596d4 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Wed, 21 Feb 2024 20:44:58 +0100
Subject: [PATCH] org-element.el: New element: Inline Special Block (proof of
 concept).

* lisp/ox-latex.el (org-latex-inline-special-block): A possible
function for the LaTeX backend.
---
 lisp/org-element.el | 55 ++++++++++++++++++++++++++++++++++++++++++++-
 lisp/ox-latex.el    | 10 +++++++++
 2 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6691ea44e..2f9436df2 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -272,6 +272,8 @@ specially in `org-element--object-lex'.")
 			       "\\|"))
 		      ;; Objects starting with "@": export snippets.
 		      "@@"
+                      ;; Objects starting with "&": inline-special-blocks.
+                      "&"
 		      ;; Objects starting with "{": macro.
 		      "{{{"
 		      ;; Objects starting with "<" : timestamp
@@ -313,7 +315,7 @@ specially in `org-element--object-lex'.")
   "List of recursive element types aka Greater Elements.")
 
 (defconst org-element-all-objects
-  '(bold citation citation-reference code entity export-snippet
+  '(bold citation citation-reference code entity export-snippet inline-special-block
 	 footnote-reference inline-babel-call inline-src-block italic line-break
 	 latex-fragment link macro radio-target statistics-cookie strike-through
 	 subscript superscript table-cell target timestamp underline verbatim)
@@ -440,6 +442,7 @@ Don't modify it, set `org-element-affiliated-keywords' instead.")
       ;; Ignore inline babel call and inline source block as formulas
       ;; are possible.  Also ignore line breaks and statistics
       ;; cookies.
+      (inline-special-block ,@standard-set)
       (table-cell citation export-snippet footnote-reference link macro
                   radio-target target timestamp ,@minimal-set)
       (table-row table-cell)
@@ -3535,6 +3538,54 @@ Assume point is at the beginning of the entity."
 	  (org-element-property :name entity)
 	  (when (org-element-property :use-brackets-p entity) "{}")))
 
+;;;; inline special block
+
+(defun org-element-inline-special-block-parser ()
+  "Parse inline special block at point.
+
+When at an inline special block, return a new syntax node of
+`inline-special-block' type containing `:begin', `:end', `:type',
+`:parameters', `:contents-begin', `:contents-end' and
+`:post-blank' as properties.  Otherwise, return nil.
+
+Assume point is at the beginning of the block."
+  (save-excursion
+    (when (looking-at "&\\([A-Za-z]+\\)[{[]")
+      (goto-char (- (match-end 0) 1))
+      (let* ((begin (match-beginning 0))
+             (parameters
+              (let ((p (org-element--parse-paired-brackets ?\[)))
+                (and (org-string-nw-p p)
+                     (replace-regexp-in-string "\n[ \t]*" " " (org-trim p)))))
+             (contents-begin (when (looking-at-p "{") (+ (point) 1)))
+             (type (org-element--get-cached-string
+                    (match-string-no-properties 1)))
+             (contents-end
+              (progn
+                (goto-char (- contents-begin 1))
+                (org-element--parse-paired-brackets ?\{)
+                (- (point) 1)))
+             (post-blank (skip-chars-forward " \t"))
+             (end (point)))
+        (when contents-end
+          (org-element-create
+           'inline-special-block
+           (list :type type
+                 :parameters parameters
+                 :contents-begin contents-begin
+                 :contents-end contents-end
+                 :begin begin
+                 :end end
+                 :post-blank post-blank)))))))
+
+(defun org-element-inline-special-block-interpreter (inline-special-block contents)
+  "Interpret INLINE SPECIAL BLOCK object as Org syntax."
+  (let ((type (org-element-property :type inline-special-block))
+        (opts (org-element-property :parameters inline-special-block)))
+    (format "&%s%s{%s}"
+            type
+            (if opts (format "[%s]" opts) "")
+            contents)))
 
 ;;;; Export Snippet
 
@@ -5260,6 +5311,8 @@ to an appropriate container (e.g., a paragraph)."
 			          (org-element-strike-through-parser)))
 		         (?@ (and (memq 'export-snippet restriction)
 			          (org-element-export-snippet-parser)))
+                         (?& (and (memq 'inline-special-block restriction)
+                                  (org-element-inline-special-block-parser)))
 		         (?{ (and (memq 'macro restriction)
 			          (org-element-macro-parser)))
 		         (?$ (and (memq 'latex-fragment restriction)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..a303d54a6 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -101,6 +101,7 @@
     (underline . org-latex-underline)
     (verbatim . org-latex-verbatim)
     (verse-block . org-latex-verse-block)
+    (inline-special-block . org-latex-inline-special-block)
     ;; Pseudo objects and elements.
     (latex-math-block . org-latex-math-block)
     (latex-matrices . org-latex-matrices))
@@ -2095,6 +2096,15 @@ holding contextual information."
    center-block (format "\\begin{center}\n%s\\end{center}" contents) info))
 
 
+;;;; Inline Special Block
+
+(defun org-latex-inline-special-block (inline-special-block contents info)
+  "Transcode an INLINE SPECIAL BLOCK element from Org to LaTeX.
+CONTENTS holds the contents of the block.  INFO is a plist
+holding contextual information."
+  (let ((type (org-element-property :type inline-special-block)))
+    (format "\\%s{%s}" type contents)))
+
 ;;;; Clock
 
 (defun org-latex-clock (clock _contents info)
-- 
2.43.1


^ permalink raw reply related	[relevance 8%]

* Re: [proof of concept] inline language blocks
  2024-02-21 13:10  5%         ` Ihor Radchenko
@ 2024-02-21 14:13 12%           ` Juan Manuel Macías
  2024-02-21 20:32  8%             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
  2024-02-21 22:11  4%             ` [proof of concept] inline language blocks Samuel Wales
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 14:13 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> We need to finalize inline special block syntax first, and then talk
>>> about special cases like inline language markup you propose.
>>
>> As I already said, in my local branch I have both elements created,
>> based on the same syntax:
>>
>> - language block: :lang{text}
>>
>> - special block &type{text}
>>
>> the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
>>
>> I like the syntax because it is minimalist and not verbose at all. That
>> could serve as a basis (at least it is good to have a starting point,
>> because otherwise everything will be diluted in discussions). Then we
>> can start thinking about whether to add options and how to add them.
>
> We do not need to design the inline special block markup fully to
> introduce it. However, we do need to make sure that whatever simple
> version of inline markup we introduce does not prevent further planned
> extensions.

My proposed syntax could be:

&type[options]{content}

> My main concern is the possibility to introduce multi-argument markup.
> Like @abbrev{EA}{example abbreviation}. This will be necessary to
> achieve parity with Texinfo markup.
> However, it is not yet clear about the best syntax to pass multiple
> arguments.

I imagine multiple arguments would depend on each backend, right?
Because I don't quite see much sense in html, for example. However, it
occurs to me to reuse content, and add some separator character:

&type[options]{arg1::arg2::etc}

or better:

&type[options and aditional args]{content}

to maintain a certain parallelism with the large blocks.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: [proof of concept] inline language blocks
  2024-02-21 12:00  5%     ` Ihor Radchenko
@ 2024-02-21 12:53 10%       ` Juan Manuel Macías
  2024-02-21 13:10  5%         ` Ihor Radchenko
  2024-02-21 23:33  6%         ` Suhail Singh
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-21 12:53 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Ihor Radchenko writes:
>>> This is a good idea, although it would be better to make this new markup
>>> element within the framework of more general inline special block we
>>> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
>>
>> Fun fact: the local branch is called inline-special-block, because I
>> originally had that idea in mind when I created it. Then, halfway
>> through, I doubted whether it wouldn't be better to have a specific
>> inline language selector, whose use would be as direct as an emphasis
>> mark. So in the branch there is also a "proto"-inline-special-block with
>> similar syntax: &foo{}.
>>
>> I opted for the -language-block version because, as I said, its use is
>> very 'direct' and covers a common need to segment multilingual text
>> within the paragraph.
>
> My main point is that we should use the same syntax with inline special
> blocks. Similar to how #+begin_verse uses the same syntax as special
> blocks.
>
> We need to finalize inline special block syntax first, and then talk
> about special cases like inline language markup you propose.

As I already said, in my local branch I have both elements created,
based on the same syntax:

- language block: :lang{text}

- special block &type{text}

the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}

I like the syntax because it is minimalist and not verbose at all. That
could serve as a basis (at least it is good to have a starting point,
because otherwise everything will be diluted in discussions). Then we
can start thinking about whether to add options and how to add them.

>> I think at the time we also discussed whether or not it would be a good
>> idea to provide the inline special blocks with options and attributes,
>> like their older brothers. And how to do it. My biggest concern here is
>> the (let's say) latexification of the paragraph. I mean, one of the
>> great things about Org versus heavier markup like LaTeX is that when org
>> wants to be verbose it uses dedicated lines, but usually keeps the
>> paragraphs clean and readable. I think that any element inside the
>> paragraph should tend to be as "transparent" as simple emphasis marks.
>>
>> I remember that there was also discussion about puting the options
>> outside the paragraph, using some type of identifier. It doesn't seem
>> like a bad idea to me, but I think it adds an extra complication for the
>> user. It would be very tedious for me to write like this (even more
>> tedious than writing in LaTeX).
>
> I still believe that we should /allow/ options inside inline block-type
> markup. This is often necessary in practice. For example, I recommend
> studying
> https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
> and how they had to use ugly |... extensions to provide options.
>
> But it does not mean that users /have to/ use these options. In fact, we
> might design the inline language blocks to ignore options.

The wiki language is for a specific purpose, and I wouldn't consider it
a lightweight markup language, although it is certainly less thick than
html.

Actually I'm just expressing my concerns and doubts, I'm not objecting
to anything. I remember reading in the pandoc issues, a long time ago,
similar discussions every time they talked about extending the markup. I
don't know if it's a good idea to stick to a certain point to preserve
the nature of a lightweight markup language and accept certain intrinsic
limitations instead of providing options that probably have very little
use or can be resolved by some export filter. I don't have a definite
opinion, I'm just raising my doubts. Although I really value simplicity
and minimalism.


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 10%]

* Re: [proof of concept] inline language blocks
  2024-02-20 20:35  9% [proof of concept] inline language blocks Juan Manuel Macías
@ 2024-02-21  8:42  6% ` Ihor Radchenko
  2024-02-21 10:57 10%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-21  8:42 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> I'm dedicating a local branch to developing this proof of concept and
> testing it in my workflow, so far with good results. The basic idea is
> to provide Org with multilingual features and various methods for
> selecting languages.
>
> The inline-language-block is intended for small segments of text in a
> language other than the main language. They can span several lines but
> not more than a paragraph. They can be used for in-line textual quotes,
> glosses, etc. They are constructions equivalent to, for example, LaTeX
> \foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
>
> I have thought of a syntax that is as least intrusive as possible, so as
> not to make reading uncomfortable. I have tried the following:
>
> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>
> You can also use a literal term instead of a language code:
>
> :klingon!{some text in Klingon}
>
> The blocks can be nested:
>
> :klingon!{Some text in Klingon with :it{some text in Italian}}
>
> And they may include other elements:
>
> :el{Some text in Greek with a {{{macro}}} and a [[link]]}

This is a good idea, although it would be better to make this new markup
element within the framework of more general inline special block we
discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [proof of concept] inline language blocks
  2024-02-21 10:57 10%   ` Juan Manuel Macías
@ 2024-02-21 12:00  5%     ` Ihor Radchenko
  2024-02-21 12:53 10%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-21 12:00 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Ihor Radchenko writes:
>> This is a good idea, although it would be better to make this new markup
>> element within the framework of more general inline special block we
>> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/
>
> Fun fact: the local branch is called inline-special-block, because I
> originally had that idea in mind when I created it. Then, halfway
> through, I doubted whether it wouldn't be better to have a specific
> inline language selector, whose use would be as direct as an emphasis
> mark. So in the branch there is also a "proto"-inline-special-block with
> similar syntax: &foo{}.
>
> I opted for the -language-block version because, as I said, its use is
> very 'direct' and covers a common need to segment multilingual text
> within the paragraph.

My main point is that we should use the same syntax with inline special
blocks. Similar to how #+begin_verse uses the same syntax as special
blocks.

We need to finalize inline special block syntax first, and then talk
about special cases like inline language markup you propose.

> I think at the time we also discussed whether or not it would be a good
> idea to provide the inline special blocks with options and attributes,
> like their older brothers. And how to do it. My biggest concern here is
> the (let's say) latexification of the paragraph. I mean, one of the
> great things about Org versus heavier markup like LaTeX is that when org
> wants to be verbose it uses dedicated lines, but usually keeps the
> paragraphs clean and readable. I think that any element inside the
> paragraph should tend to be as "transparent" as simple emphasis marks.
>
> I remember that there was also discussion about puting the options
> outside the paragraph, using some type of identifier. It doesn't seem
> like a bad idea to me, but I think it adds an extra complication for the
> user. It would be very tedious for me to write like this (even more
> tedious than writing in LaTeX).

I still believe that we should /allow/ options inside inline block-type
markup. This is often necessary in practice. For example, I recommend
studying
https://en.wikipedia.org/wiki/Help:Wikitext#Templates_and_transcluding_pages
and how they had to use ugly |... extensions to provide options.

But it does not mean that users /have to/ use these options. In fact, we
might design the inline language blocks to ignore options.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [proof of concept] inline language blocks
  2024-02-21 12:53 10%       ` Juan Manuel Macías
@ 2024-02-21 13:10  5%         ` Ihor Radchenko
  2024-02-21 14:13 12%           ` Juan Manuel Macías
  2024-02-21 23:33  6%         ` Suhail Singh
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-21 13:10 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> We need to finalize inline special block syntax first, and then talk
>> about special cases like inline language markup you propose.
>
> As I already said, in my local branch I have both elements created,
> based on the same syntax:
>
> - language block: :lang{text}
>
> - special block &type{text}
>
> the latter would be exported, for example, to html as <span class="type">text</span> or to LaTeX as \type{text}
>
> I like the syntax because it is minimalist and not verbose at all. That
> could serve as a basis (at least it is good to have a starting point,
> because otherwise everything will be diluted in discussions). Then we
> can start thinking about whether to add options and how to add them.

We do not need to design the inline special block markup fully to
introduce it. However, we do need to make sure that whatever simple
version of inline markup we introduce does not prevent further planned
extensions.

My main concern is the possibility to introduce multi-argument markup.
Like @abbrev{EA}{example abbreviation}. This will be necessary to
achieve parity with Texinfo markup.
However, it is not yet clear about the best syntax to pass multiple
arguments.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [proof of concept] inline language blocks
  2024-02-21  8:42  6% ` Ihor Radchenko
@ 2024-02-21 10:57 10%   ` Juan Manuel Macías
  2024-02-21 12:00  5%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-21 10:57 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I'm dedicating a local branch to developing this proof of concept and
>> testing it in my workflow, so far with good results. The basic idea is
>> to provide Org with multilingual features and various methods for
>> selecting languages.
>>
>> The inline-language-block is intended for small segments of text in a
>> language other than the main language. They can span several lines but
>> not more than a paragraph. They can be used for in-line textual quotes,
>> glosses, etc. They are constructions equivalent to, for example, LaTeX
>> \foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.
>>
>> I have thought of a syntax that is as least intrusive as possible, so as
>> not to make reading uncomfortable. I have tried the following:
>>
>> :fr{some text in French} :it{some text in Italian} :la{some text in Latin}
>>
>> You can also use a literal term instead of a language code:
>>
>> :klingon!{some text in Klingon}
>>
>> The blocks can be nested:
>>
>> :klingon!{Some text in Klingon with :it{some text in Italian}}
>>
>> And they may include other elements:
>>
>> :el{Some text in Greek with a {{{macro}}} and a [[link]]}
>
> This is a good idea, although it would be better to make this new markup
> element within the framework of more general inline special block we
> discussed in the past: https://list.orgmode.org/orgmode/87a6b8pbhg.fsf@posteo.net/

Fun fact: the local branch is called inline-special-block, because I
originally had that idea in mind when I created it. Then, halfway
through, I doubted whether it wouldn't be better to have a specific
inline language selector, whose use would be as direct as an emphasis
mark. So in the branch there is also a "proto"-inline-special-block with
similar syntax: &foo{}.

I opted for the -language-block version because, as I said, its use is
very 'direct' and covers a common need to segment multilingual text
within the paragraph.

I think at the time we also discussed whether or not it would be a good
idea to provide the inline special blocks with options and attributes,
like their older brothers. And how to do it. My biggest concern here is
the (let's say) latexification of the paragraph. I mean, one of the
great things about Org versus heavier markup like LaTeX is that when org
wants to be verbose it uses dedicated lines, but usually keeps the
paragraphs clean and readable. I think that any element inside the
paragraph should tend to be as "transparent" as simple emphasis marks.

I remember that there was also discussion about puting the options
outside the paragraph, using some type of identifier. It doesn't seem
like a bad idea to me, but I think it adds an extra complication for the
user. It would be very tedious for me to write like this (even more
tedious than writing in LaTeX).

Best regards,

-- 
Juan Manuel Macías 



^ permalink raw reply	[relevance 10%]

* [proof of concept] inline language blocks
@ 2024-02-20 20:35  9% Juan Manuel Macías
  2024-02-21  8:42  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-20 20:35 UTC (permalink / raw)
  To: orgmode

Hi,

I'm dedicating a local branch to developing this proof of concept and
testing it in my workflow, so far with good results. The basic idea is
to provide Org with multilingual features and various methods for
selecting languages.

The inline-language-block is intended for small segments of text in a
language other than the main language. They can span several lines but
not more than a paragraph. They can be used for in-line textual quotes,
glosses, etc. They are constructions equivalent to, for example, LaTeX
\foreignlanguage{french}{text} or HTML <span lang=fr>text</span>.

I have thought of a syntax that is as least intrusive as possible, so as
not to make reading uncomfortable. I have tried the following:

:fr{some text in French} :it{some text in Italian} :la{some text in Latin}

You can also use a literal term instead of a language code:

:klingon!{some text in Klingon}

The blocks can be nested:

:klingon!{Some text in Klingon with :it{some text in Italian}}

And they may include other elements:

:el{Some text in Greek with a {{{macro}}} and a [[link]]}

To this end, I have defined the following element:

#+begin_src emacs-lisp
(defun org-element-inline-language-block-parser ()
  "Parse inline language block at point.

When at an inline language block, return a new syntax node of
`inline-language-block' type containing `:begin', `:end',
`:type', `:contents-begin', `:contents-end' and `:post-blank' as
properties.  Otherwise, return nil.

Assume point is at the beginning of the block."
  (save-excursion
    (when (looking-at ":\\([A-Za-z!]+\\){")
      (goto-char (match-end 0))
      (let* ((begin (match-beginning 0))
             (contents-begin (match-end 0))
             (type (org-element--get-cached-string
                    (match-string-no-properties 1)))
             (contents-end
              (progn
                (goto-char (- contents-begin 1))
                (org-element--parse-paired-brackets ?\{)
                (- (point) 1)))
             (post-blank (skip-chars-forward " \t"))
             (end (point)))
        (when contents-end
          (org-element-create
           'inline-language-block
           (list :type type
                 :contents-begin contents-begin
                 :contents-end contents-end
                 :begin begin
                 :end end
                 :post-blank post-blank)))))))

(defun org-element-inline-language-block-interpreter (inline-language-block contents)
  "Interpret INLINE LANGUAGE BLOCK object as Org syntax."
  (format ":%s{%s}"
          (org-element-property :type inline-language-block)
          contents))
#+end_src

And, for now, this function for ox-latex:

#+begin_src emacs-lisp
(defun org-latex-inline-language-block (inline-language-block contents info)
  "Transcode an INLINE LANGUAGE BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block.  INFO is a plist
holding contextual information."
  (let ((type (org-element-property :type inline-language-block)))
    (if (string-match-p "!" type)
        (format "\\foreignlanguage{%s}{%s}"
                (replace-regexp-in-string "!" "" type)
                contents)
      (let* ((plist (cdr
                     (assoc type org-latex-language-alist)))
             (language (plist-get plist :babel))
             (language-ini-only (plist-get plist :babel-ini-only))
             (language-ini-alt (plist-get plist :babel-ini-alt))
             (lang (or language language-ini-only language-ini-alt)))
        (format "\\foreignlanguage{%s}{%s}" lang contents)))))
#+end_src

Opinions, suggestions, feedback, ideas?

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 9%]

* Re: set italian language in LaTeX export
  @ 2024-02-19 15:11 13%     ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-19 15:11 UTC (permalink / raw)
  To: Luca Ferrari; +Cc: emacs-org list

Luca Ferrari writes:

>> #+language:it
>> #+LaTeX_Header: \usepackage[AUTO]{babel}
>>
>
> Thanks, this solved the problem. Out of curiosity, why is not org-mode
> adding it automatically whenever a #+language setting is present?
> I'm just curious because it seems that, as an example, open-office
> exporting understands the language.

Hi, Luca. You may be interested in taking a look at this thread, where
this problem and other related issues such as fallback fonts in LaTeX
export are discussed:

https://list.orgmode.org/?t=20230830082719

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-19 11:15  6%                           ` Ihor Radchenko
@ 2024-02-19 13:24 12%                             ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-19 13:24 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>>> new header arguments.
>>
>> org-create-formula-image inserts LaTeX code:
>
> `org-create-formula-image' will be obsoleted after Timothy merges his
> latex preview branch. If the new implementation turns out to be not
> flexible enough, we can always refactor it further to meet ob-latex
> needs.

In that case, I think this patch could be considered canceled.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía




^ permalink raw reply	[relevance 12%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-18 13:43 10%                         ` Juan Manuel Macías
@ 2024-02-19 11:15  6%                           ` Ihor Radchenko
  2024-02-19 13:24 12%                             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-19 11:15 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> I'd prefer to refactor `org-babel-execute:latex' first, before adding
>> new header arguments.
>
> org-create-formula-image inserts LaTeX code:

`org-create-formula-image' will be obsoleted after Timothy merges his
latex preview branch. If the new implementation turns out to be not
flexible enough, we can always refactor it further to meet ob-latex
needs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: set italian language in LaTeX export
  @ 2024-02-19 11:11 13% ` Juan Manuel Macías
    0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-19 11:11 UTC (permalink / raw)
  To: Luca Ferrari; +Cc: emacs-org list

Luca Ferrari writes:

> #+language: it
>
> and I correctly got in the LaTeX buffer something like:
>
> pdflang={Italian}}
>
> but not something like:
>
> \usepackage[italian]{babel}

You must load the babel package with the AUTO option:

#+language:it
#+LaTeX_Header: \usepackage[AUTO]{babel}

(see 'LaTeX header and sectioning structure' in the Org Manual)

Best regards,

Juan Manuel

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-18 14:20  5%                       ` Ihor Radchenko
@ 2024-02-18 13:43 10%                         ` Juan Manuel Macías
  2024-02-19 11:15  6%                           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-18 13:43 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

>> In any case, if the org-create-formula-image method is going to stay, I
>> think it is fine as it is (except for extending the allowed file formats
>> to more extensions, and not only .png). I also believe that the :process
>> argument is sufficient for the user to control the value of
>> org-latex-pdf-process or org-preview-latex-default-process, as
>> appropriate.
>
> My concern about your patch is that it creates even more divergence
> between different branches of code in `org-babel-execute:latex'.
> With the new proposed features only available to some code branches,
> `org-babel-execute:latex' will just become more messy and harder to
> maintain.
>
> I'd prefer to refactor `org-babel-execute:latex' first, before adding
> new header arguments.

org-create-formula-image inserts LaTeX code:

...
    (with-temp-file texfile
      (insert latex-header)
      (insert "\n\\begin{document}\n"
              "\\definecolor{fg}{rgb}{" fg "}%\n"
              (if bg
                  (concat "\\definecolor{bg}{rgb}{" bg "}%\n"
                          "\n\\pagecolor{bg}%\n")
                "")
              "\n{\\color{fg}\n"
              string
              "\n}\n"
              "\n\\end{document}\n"))
...

that, /in principle/, would make it incompatible with the :standalone
argument (in my patch), which allows writing all LaTeX code from scratch
in the block content.

Anyway, it is true that org-babel-execute:latex has grown in a somewhat
irregular way. For example, I don't quite understand why the simple
output to PDF and the conversion to an image with :imagemagick live in
the same conditional:

(or (string= "pdf" extension) imagemagick)

I would propose three main branches in this function:

- A PDF branch, using org-format-latex-header with its valid options,
  and other sub-branches with conversion from the PDF, for example, the
  use of :imagemagick. Or you could even think of any possible
  conversion process using a hypothetical :pdf-postprocess

- A branch for orf-create-formula-image

- a third branch to export to html, with org-babel-latex-htlatex.

Having three clearly differentiated branches would make the code easier
to maintain.

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 10%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-13 20:25 11%                     ` Juan Manuel Macías
@ 2024-02-18 14:20  5%                       ` Ihor Radchenko
  2024-02-18 13:43 10%                         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-18 14:20 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> It is true that the "org-create-formula-image" method is much more
> complete. But, IMHO, I think it's a method focused on the buffer (rather
> than the block) or previewing LaTeX code in the buffer.

What do you mean? `org-create-formula-image' is passed a string of LaTeX
code. Note that `org-create-formula-image' is also used in HTML export.

> ... In the case of
> the LaTeX block, I think the :imagemagick method is simpler. It depends
> on two simple processes: imagemagick and org-latex-pdf-process and
> parameters such as the width or height of the generated image, the
> density in dpi, etc. can be easily applied, via arguments.

ob-latex does not have to expose all the possible toggles
`org-latex-pdf-process' has.

> ... In the case
> of the other method, in addition to the value of
> org-preview-latex-default-process, there is that of
> org-format-latex-options. There are, in short, many parameters that are
> perfect for a file or an Emacs session but for a simple block I find
> overhelming.

We can fix the parameters we do not want to expose.

> In any case, if the org-create-formula-image method is going to stay, I
> think it is fine as it is (except for extending the allowed file formats
> to more extensions, and not only .png). I also believe that the :process
> argument is sufficient for the user to control the value of
> org-latex-pdf-process or org-preview-latex-default-process, as
> appropriate.

My concern about your patch is that it creates even more divergence
between different branches of code in `org-babel-execute:latex'.
With the new proposed features only available to some code branches,
`org-babel-execute:latex' will just become more messy and harder to
maintain.

I'd prefer to refactor `org-babel-execute:latex' first, before adding
new header arguments.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: Exporting multiple #+AUTHOR keywords
  @ 2024-02-17 10:34  6% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-17 10:34 UTC (permalink / raw)
  To: ypuntot; +Cc: yantar92, Org-mode

ypuntot writes:

> Is it related with AUTHOR property? 
> I am starting to add these properties to every book, and chapter of
> the book, that I study. I hope this doesn't lead to a suboptimal
> workflow. 
>
> Doesn't this work? 
>
> :PROPERTIES: 
>     :AUTHOR:   García-Ael, Cristina and Pérez-Garín, Daniel and Recio
> Saboya, Patricia 
>     :BTYPE:    incollection 
>     :BOOKTITLE: Psicología de los Grupos 
>     :TITLE:    Métodos y Técnicas de Investigación en Psicología de
> los Grupos. 
>    
>     :PUBLISHER: UNED 
>
>     :ADDRESS:  C/ Bravo Murillo, 38; 28015; Madrid 
>     :INSTITUTION: UNED 
>     :YEAR:     2017 
>     :CHAPTER:  2 
>     :PAGES:    49-83 
>     :END: 


What we are dealing with here is the keyword #+AUTHOR or the
EXPORT_AUTHOR property (when exporting a subtree), that is, the author
of the document (see 'Export settings' in the Org Manual), not the
AUTHOR property of org-ref. Your workflow is correct.



^ permalink raw reply	[relevance 6%]

* Re: Retaking AUTO for \usepackage{fontenc}
  2024-02-14 14:55  6%           ` Ihor Radchenko
@ 2024-02-14 22:03 13%             ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-14 22:03 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> neither do I, This is why I'm asking for people to tell me what they
>>> use ;-)
>>
>> The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:
>
> May it be that babel automatically loads fontenc with appropriate parameters?

AFAIK, I'm afraid it's not possible. What is possible is to be able to
select a language in the middle of the document, without declaring it
before. But you need to load fontenc and the appropriate fontencodings.
According to the babel manual (p. 8), this functionality is only limited
to Latin, Cyrillic, Greek, Arabic, Hebrew, Cherokee, Armenian, and
Georgian.

Best regards,

Juan Manuel 


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: Retaking AUTO for \usepackage{fontenc}
  2024-02-13 17:22 11%         ` Juan Manuel Macías
@ 2024-02-14 14:55  6%           ` Ihor Radchenko
  2024-02-14 22:03 13%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-14 14:55 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

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

> Pedro Andres Aranda Gutierrez writes:
>
>> neither do I, This is why I'm asking for people to tell me what they
>> use ;-)
>
> The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:

May it be that babel automatically loads fontenc with appropriate parameters?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-13 16:01 11%             ` Juan Manuel Macías
@ 2024-02-14 14:37  6%               ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-02-14 14:37 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> I have fixed the org-latex-known-warnings regexp in the attached patch.
> I think it should work fine now...

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9eec4af62

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-13 13:42  5%                   ` Ihor Radchenko
@ 2024-02-13 20:25 11%                     ` Juan Manuel Macías
  2024-02-18 14:20  5%                       ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 20:25 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Moreover, it would be nice to unify handling .png and imagemagick
>>> branches of the code.
>>
>> I agree. In any case, I still think that the coexistence of two methods
>> to convert to images, when one of the methods has a scheme so different
>> from the rest, becomes difficult: for the user as well as for
>> maintaining the code.
>>
>> The first solution that occurs to me (I'm afraid it's too radical) is to
>> leave only the :imagemagick method, and maintain the possibility of
>> using the other one through a variable. Something like
>> org-babel-latex-default-image-conversion-method or something similar.
>> But I suppose this could cause unwanted inconveniences. We should see
>> what more users think.
>
> I am not sure.
> Conceptually, .png method is more flexible than imagemagick - it uses
> `org-create-formula-image' that is handling (1) preamble; (2) conversion
> not only to png but to svg and other arbitrary formats.
> ob-latex is duplicating org-create-formula-image code, layering custom
> latex preamble and more commands on top.
> So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
> use of `org-create-formula-image', possibly extending it to fit ob-latex
> needs.

It is true that the "org-create-formula-image" method is much more
complete. But, IMHO, I think it's a method focused on the buffer (rather
than the block) or previewing LaTeX code in the buffer. In the case of
the LaTeX block, I think the :imagemagick method is simpler. It depends
on two simple processes: imagemagick and org-latex-pdf-process and
parameters such as the width or height of the generated image, the
density in dpi, etc. can be easily applied, via arguments. In the case
of the other method, in addition to the value of
org-preview-latex-default-process, there is that of
org-format-latex-options. There are, in short, many parameters that are
perfect for a file or an Emacs session but for a simple block I find
overhelming.

In any case, if the org-create-formula-image method is going to stay, I
think it is fine as it is (except for extending the allowed file formats
to more extensions, and not only .png). I also believe that the :process
argument is sufficient for the user to control the value of
org-latex-pdf-process or org-preview-latex-default-process, as
appropriate.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: Retaking AUTO for \usepackage{fontenc}
  2024-02-13 16:47  6%       ` Pedro Andres Aranda Gutierrez
@ 2024-02-13 17:22 11%         ` Juan Manuel Macías
  2024-02-14 14:55  6%           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 17:22 UTC (permalink / raw)
  To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List

Pedro Andres Aranda Gutierrez writes:

> neither do I, This is why I'm asking for people to tell me what they
> use ;-)

The babel ini files (why hadn't I thought of this before :-): look in the babel ini files:

<your-texmf-dist-root>/tex/generic/babel/locale/

There you have all the information by language. For example, in
babel-fr.ini:

8<--------------------------------------------------------------

; This file is part of babel. For further details see:
;   https://www.ctan.org/pkg/babel
; Data has been collected mainly from the following sources:
; * babel language styles (license LPPL):
;   https://www.ctan.org/pkg/babel-contrib
; * Common Locale Data Repository (license Unicode):
;   http://cldr.unicode.org/
;   http://unicode.org/copyright.html

[identification]
charset = utf8
version = 0.981
date = 2022-05-14
name.local = français
name.english = French
name.babel = french
name.polyglossia = french
tag.bcp47 = fr
language.tag.bcp47 = fr
tag.bcp47.likely = fr-Latn-FR
tag.opentype = FRA
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1 <==========================================
derivate = no
.....
-------------------------------------------------------------->8

--

Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 11%]

* Re: Retaking AUTO for \usepackage{fontenc}
  2024-02-13 11:57 13%     ` Juan Manuel Macías
@ 2024-02-13 16:47  6%       ` Pedro Andres Aranda Gutierrez
  2024-02-13 17:22 11%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-02-13 16:47 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List

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

Hi Juan,

neither do I, This is why I'm asking for people to tell me what they use ;-)

best, /PA

On Tue, 13 Feb 2024 at 12:57, Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Pedro Andres Aranda Gutierrez writes:
>
> > Hi,
> >
> > Next step, @all, please help me filling up the list of codings vs.
> > languages. I currently am somehow confident of the following:
> >
> > greek -> LGR
> > russian -> T2A
>
> The information is in the encguide PDF (you can run texdoc fontenc or
> texdoc encguide). You should look especially at section 2.3 256 glyph
> encodings. I don't know if some languages require more than one
> encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for
>
> "The African Latin fonts contain in their lower half (0–127) the same
> characters as the European Latin (T1-encoded) Fonts, while in their
> upper half (128–255) they contain letters and symbols for African
> languages that use extended Latin alphabets."
>
> etc.
>
> But I can't find a simpler list anywhere.
>
> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos,
> diseño editorial y ortotipografía
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

^ permalink raw reply	[relevance 6%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-13 14:29  5%           ` Ihor Radchenko
@ 2024-02-13 16:01 11%             ` Juan Manuel Macías
  2024-02-14 14:37  6%               ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 16:01 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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

Ihor Radchenko writes:

> Probably something to do with my Texlive technically having Chinese
> support.
>
> I am getting
>
> ! Package inputenc Error: Unicode character 你 (U+4F60)
> (inputenc)                not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...                                              
>                                                   
> l.28 Hello. 你
>                好.
>
> ! Package inputenc Error: Unicode character 好 (U+597D)
> (inputenc)                not set up for use with LaTeX.
>
> See the inputenc package documentation for explanation.
> Type  H <return>  for immediate help.
>  ...                                              
>                                                   
> l.28 Hello. 你好

I have fixed the org-latex-known-warnings regexp in the attached patch.
I think it should work fine now...

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1816 bytes --]

From 742d67f2e8d4f1896d89f7543948facd65687ffe Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Tue, 13 Feb 2024 16:56:23 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings

* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
 lisp/ox-latex.el | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..2fdc2afe8 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
     ("Underfull \\hbox" . "[underfull hbox]")
     ("Overfull \\hbox" . "[overfull hbox]")
     ("Citation.*?undefined" . "[undefined citation]")
+    ("^!.+Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+    ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
     ("Undefined control sequence" . "[undefined control sequence]"))
   "Alist of regular expressions and associated messages for the user.
 The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
     (save-excursion
       (goto-char (point-max))
       (when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
-	(if (re-search-forward "^!" nil t) 'error
+	(if (and
+	     (re-search-forward "^!\\(.+\\)" nil t)
+             ;; This error is passed as missing character warning
+             (not (string-match-p "Unicode character" (match-string 1))))
+            'error
 	  (let ((case-fold-search t)
 		(warnings ""))
 	    (dolist (warning org-latex-known-warnings)
-- 
2.43.1


^ permalink raw reply related	[relevance 11%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 21:20  6%         ` Juan Manuel Macías
@ 2024-02-13 14:29  5%           ` Ihor Radchenko
  2024-02-13 16:01 11%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-13 14:29 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>>>> When I try the patch with a simple file like
>>>>
>>>> Hello. 你好。
>>>>
>>>> I do not see any warnings or errors indicated.
>>
>> I did
>> ...
>
> I have done the same, on a clean Emacs init. Warning appears.
>
> And in *Messages*:
>
> PDF file produced with warnings: [unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]
>
> In *Org PDF LaTeX Output*:
>
> ! LaTeX Error: Unicode character 你 (U+4F60)
>                not set up for use with LaTeX.
>
> (this error is the one that passes as a warning in my patch when
> compiled with pdfLaTeX).

Probably something to do with my Texlive technically having Chinese
support.

I am getting

! Package inputenc Error: Unicode character 你 (U+4F60)
(inputenc)                not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.28 Hello. 你
               好.

! Package inputenc Error: Unicode character 好 (U+597D)
(inputenc)                not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.28 Hello. 你好


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-11 20:01  9%                 ` Juan Manuel Macías
@ 2024-02-13 13:42  5%                   ` Ihor Radchenko
  2024-02-13 20:25 11%                     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-13 13:42 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> Moreover, it would be nice to unify handling .png and imagemagick
>> branches of the code.
>
> I agree. In any case, I still think that the coexistence of two methods
> to convert to images, when one of the methods has a scheme so different
> from the rest, becomes difficult: for the user as well as for
> maintaining the code.
>
> The first solution that occurs to me (I'm afraid it's too radical) is to
> leave only the :imagemagick method, and maintain the possibility of
> using the other one through a variable. Something like
> org-babel-latex-default-image-conversion-method or something similar.
> But I suppose this could cause unwanted inconveniences. We should see
> what more users think.

I am not sure.
Conceptually, .png method is more flexible than imagemagick - it uses
`org-create-formula-image' that is handling (1) preamble; (2) conversion
not only to png but to svg and other arbitrary formats.
ob-latex is duplicating org-create-formula-image code, layering custom
latex preamble and more commands on top.
So, ideally, I'd prefer to obsolete the custom code in ob-latex and make
use of `org-create-formula-image', possibly extending it to fit ob-latex
needs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: Retaking AUTO for \usepackage{fontenc}
  @ 2024-02-13 11:57 13%     ` Juan Manuel Macías
  2024-02-13 16:47  6%       ` Pedro Andres Aranda Gutierrez
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-13 11:57 UTC (permalink / raw)
  To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List

Pedro Andres Aranda Gutierrez writes:

> Hi,
>
> Next step, @all, please help me filling up the list of codings vs.
> languages. I currently am somehow confident of the following:
>
> greek -> LGR
> russian -> T2A

The information is in the encguide PDF (you can run texdoc fontenc or
texdoc encguide). You should look especially at section 2.3 256 glyph
encodings. I don't know if some languages require more than one
encoding. Cyrillic appears to be T2A, T2B and T2C. T4 is for

"The African Latin fonts contain in their lower half (0–127) the same
characters as the European Latin (T1-encoded) Fonts, while in their
upper half (128–255) they contain letters and symbols for African
languages that use extended Latin alphabets."

etc.

But I can't find a simpler list anywhere.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 19:52  5%       ` Ihor Radchenko
@ 2024-02-12 21:20  6%         ` Juan Manuel Macías
  2024-02-13 14:29  5%           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 21:20 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> When I try the patch with a simple file like
>>>
>>> Hello. 你好。
>>>
>>> I do not see any warnings or errors indicated.
>>
>> How weird... And don't they at least appear in the *Messages* buffer?
>> With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
>> (I have used the default value of org-latex-pdf-process):
>
> I did
>
> 1. Install your patch on top of the latest main
> 2. make repro
> 3. Open /tmp/1.org and enter
> Hello. 你好.
> 4. C-c C-e l o
>
> In *Messages* I see
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Org mode version 9.7-pre (release_9.6.18-1196-g8bd0dd @ /home/yantar92/Git/org-mode/lisp/)
> (New file)
> Making completion list... [3 times]
> Loading quail/PY (native compiled elisp)...done
> Saving file /tmp/1.org...
> Wrote /tmp/1.org
> Wrote /tmp/1.tex
> Processing LaTeX file 1.tex...
> PDF file produced.
> Running xdg-open /tmp/1.pdf...done
>
> My `org-latex-pdf-process' is
> ("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
> since I have latexmk installed.

I have done the same, on a clean Emacs init. Warning appears.

And in *Messages*:

PDF file produced with warnings: [unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]

In *Org PDF LaTeX Output*:

! LaTeX Error: Unicode character 你 (U+4F60)
               not set up for use with LaTeX.

(this error is the one that passes as a warning in my patch when
compiled with pdfLaTeX).


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 19:17 10%     ` Juan Manuel Macías
@ 2024-02-12 19:52  5%       ` Ihor Radchenko
  2024-02-12 21:20  6%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-12 19:52 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> When I try the patch with a simple file like
>>
>> Hello. 你好。
>>
>> I do not see any warnings or errors indicated.
>
> How weird... And don't they at least appear in the *Messages* buffer?
> With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
> (I have used the default value of org-latex-pdf-process):

I did

1. Install your patch on top of the latest main
2. make repro
3. Open /tmp/1.org and enter
Hello. 你好.
4. C-c C-e l o

In *Messages* I see
For information about GNU Emacs and the GNU system, type C-h C-a.
Org mode version 9.7-pre (release_9.6.18-1196-g8bd0dd @ /home/yantar92/Git/org-mode/lisp/)
(New file)
Making completion list... [3 times]
Loading quail/PY (native compiled elisp)...done
Saving file /tmp/1.org...
Wrote /tmp/1.org
Wrote /tmp/1.tex
Processing LaTeX file 1.tex...
PDF file produced.
Running xdg-open /tmp/1.pdf...done

My `org-latex-pdf-process' is
("latexmk -f -pdf -%latex -interaction=nonstopmode -output-directory=%o %f")
since I have latexmk installed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 18:26  6%   ` Ihor Radchenko
@ 2024-02-12 19:17 10%     ` Juan Manuel Macías
  2024-02-12 19:52  5%       ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 19:17 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry, the previous patch was incomplete. The attached patch is correct.
>
> When I try the patch with a simple file like
>
> Hello. 你好。
>
> I do not see any warnings or errors indicated.

How weird... And don't they at least appear in the *Messages* buffer?
With your example, they appear to me with pdfLaTeX, lualatex and XelaTeX
(I have used the default value of org-latex-pdf-process):

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

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 18:15 11% ` Juan Manuel Macías
@ 2024-02-12 18:26  6%   ` Ihor Radchenko
  2024-02-12 19:17 10%     ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-12 18:26 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Sorry, the previous patch was incomplete. The attached patch is correct.

When I try the patch with a simple file like

Hello. 你好。

I do not see any warnings or errors indicated.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [patch] ox.latex.el: Add missing character warnings
  2024-02-12 15:24 11% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
@ 2024-02-12 18:15 11% ` Juan Manuel Macías
  2024-02-12 18:26  6%   ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 18:15 UTC (permalink / raw)
  To: orgmode

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

Sorry, the previous patch was incomplete. The attached patch is correct.

Best regards,

Juan Manuel 

Juan Manuel Macías writes:

> Rationale for the attached patch: It seems that a common problem that
> users have with exporting to LaTeX is unicode characters that cannot be
> represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
> the warning is insidious, since the missing character warning is not
> preceded by a 'warning' string.
>
> Naturally, the added Org warnings do not solve the problem, but at least
> they give some clues on how to properly adjust the document.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1825 bytes --]

From 19fb7b81d6ce3a657c86497707f590063b27683c Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings

* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
 lisp/ox-latex.el | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..da4792c04 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
     ("Underfull \\hbox" . "[underfull hbox]")
     ("Overfull \\hbox" . "[overfull hbox]")
     ("Citation.*?undefined" . "[undefined citation]")
+    ("LaTeX Error: Unicode character" . "[unicode character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+    ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
     ("Undefined control sequence" . "[undefined control sequence]"))
   "Alist of regular expressions and associated messages for the user.
 The regular expressions are used to find possible warnings in the
@@ -4435,7 +4437,11 @@ encountered or nil if there was none."
     (save-excursion
       (goto-char (point-max))
       (when (re-search-backward "^[ \t]*This is .*?TeX.*?Version" nil t)
-	(if (re-search-forward "^!" nil t) 'error
+	(if (and
+	     (re-search-forward "^!\\(.+\\)" nil t)
+             ;; This error is passed as missing character warning
+             (not (string-match-p "Unicode character" (match-string 1))))
+            'error
 	  (let ((case-fold-search t)
 		(warnings ""))
 	    (dolist (warning org-latex-known-warnings)
-- 
2.43.1


^ permalink raw reply related	[relevance 11%]

* [patch] ox.latex.el: Add missing character warnings
@ 2024-02-12 15:24 11% Juan Manuel Macías
  2024-02-12 18:15 11% ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 15:24 UTC (permalink / raw)
  To: orgmode

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


Rationale for the attached patch: It seems that a common problem that
users have with exporting to LaTeX is unicode characters that cannot be
represented in pdfLaTeX or LuaLaTeX/XelaTeX. In the Unicode TeX engines
the warning is insidious, since the missing character warning is not
preceded by a 'warning' string.

Naturally, the added Org warnings do not solve the problem, but at least
they give some clues on how to properly adjust the document.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ox-latex.el-Add-missing-character-warnings.patch --]
[-- Type: text/x-patch, Size: 1247 bytes --]

From 03c4c94c22f720e38f1ffb180aaa8a23abd90406 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Mon, 12 Feb 2024 16:10:28 +0100
Subject: [PATCH] lisp/ox-latex.el: Add missing character warnings

* (org-latex-known-warnings): Two missing character warnings are
added: one for LuaLaTeX/XelaTeX and another for pdfLaTeX.
---
 lisp/ox-latex.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index cfa2b8178..80d992160 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1511,6 +1511,8 @@ logfiles to remove, set `org-latex-logfiles-extensions'."
     ("Underfull \\hbox" . "[underfull hbox]")
     ("Overfull \\hbox" . "[overfull hbox]")
     ("Citation.*?undefined" . "[undefined citation]")
+    ("LaTeX Error: Unicode character" . "[character(s) not set up for use with pdflatex. You can run lualatex or xelatex instead]")
+    ("Missing character: There is no" . "[Missing character(s): please load an appropriate font with the fontspec package]")
     ("Undefined control sequence" . "[undefined control sequence]"))
   "Alist of regular expressions and associated messages for the user.
 The regular expressions are used to find possible warnings in the
-- 
2.43.1


^ permalink raw reply related	[relevance 11%]

* Re: Link type for pdf-tools annotations
  2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
  2024-02-08 23:25  6% ` Ihor Radchenko
@ 2024-02-09 12:13  6% ` Irfan S
  2024-02-09 12:48 13%   ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Irfan S @ 2024-02-09 12:13 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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


> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:

> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]

> The link opens the PDF and jumps to the specific annotation. A screenshot:

FYI, there is also [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which provides similar (and additional) functionality, and is on MELPA. Thanks for sharing your code.

Irfan


^ permalink raw reply	[relevance 6%]

* Re: "Full Block" character in example block not visible in Beamer PDF
  2024-02-12 11:06 12% ` Juan Manuel Macías
@ 2024-02-12 12:40  6%   ` Loris Bennett
  0 siblings, 0 replies; 200+ results
From: Loris Bennett @ 2024-02-12 12:40 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Org Mode Mailing List

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

> Loris Bennett writes:
>
>> The blocks of the histogram are present in the PDF, but are white, like
>> the background of the slides.  I can see this by marking them with the
>> mouse.
>>
>> Does anyone know what I need to do to make the full block character
>> visible in this situation?
>
> Do you compile your document with pdfLaTeX?

Yes.

> It looks like you're using a Unicode character (FULL BLOCK / #2588 /
> descomp: █ #2588) that pdfLaTeX doesn't recognize. You would have to use
> LuaTeX or XeTeX as a TeX engine. And load the fontspec package to manage
> the ttf or otf fonts. Additionally, you must define a mono font that
> contains that character, for example Ubuntu Mono. An example:
>
> #+TITLE: Some title
> #+AUTHOR: author
>
> #+Beamer_Header:\usepackage{fontspec}
> #+Beamer_Header:\setsansfont{Linux Biolinum O}
> #+Beamer_Header:\setmonofont{Ubuntu Mono}
> #+LATEX_CLASS: beamer
> #+LATEX_CLASS_OPTIONS: [presentation]
> #+BEAMER_THEME: Boadilla
>
> #+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col)
>
> Screenshot:
>
> https://i.imgur.com/ulYxJgr.png

The following seems to be sufficient for me 

  #+LATEX_COMPILER: xelatex
  #+BEAMER_HEADER: \setmonofont{Fira Code}

Fira Code being the font for the terminal in which the histograms are
generated.

> Bonus: To check which fonts on your system contain a certain character,
> you can use the TeX live tool Albatross. E.g.:
>
> albatross █ --border-style 0 --detailed --show-styles --include-tex-fonts

Good to know.

Thanks!

Loris

> Best regards,
>
> Juan Manuel
>
> --
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
>
-- 
This signature is currently under constuction.


^ permalink raw reply	[relevance 6%]

* Re: "Full Block" character in example block not visible in Beamer PDF
  @ 2024-02-12 11:06 12% ` Juan Manuel Macías
  2024-02-12 12:40  6%   ` Loris Bennett
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-12 11:06 UTC (permalink / raw)
  To: Loris Bennett; +Cc: Org Mode Mailing List

Loris Bennett writes:

> The blocks of the histogram are present in the PDF, but are white, like
> the background of the slides.  I can see this by marking them with the
> mouse.
>
> Does anyone know what I need to do to make the full block character
> visible in this situation?

Do you compile your document with pdfLaTeX?

It looks like you're using a Unicode character (FULL BLOCK / #2588 /
descomp: █ #2588) that pdfLaTeX doesn't recognize. You would have to use
LuaTeX or XeTeX as a TeX engine. And load the fontspec package to manage
the ttf or otf fonts. Additionally, you must define a mono font that
contains that character, for example Ubuntu Mono. An example:

#+TITLE: Some title
#+AUTHOR: author
#+Beamer_Header:\usepackage{fontspec}
#+Beamer_Header:\setsansfont{Linux Biolinum O}
#+Beamer_Header:\setmonofont{Ubuntu Mono}
#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation]
#+BEAMER_THEME: Boadilla
#+COLUMNS: %45ITEM %10BEAMER_ENV(Env) %10BEAMER_ACT(Act) %4BEAMER_COL(Col)

Screenshot:

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

Bonus: To check which fonts on your system contain a certain character,
you can use the TeX live tool Albatross. E.g.:

albatross █ --border-style 0 --detailed --show-styles --include-tex-fonts

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 12%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-11 14:43  5%               ` Ihor Radchenko
@ 2024-02-11 20:01  9%                 ` Juan Manuel Macías
  2024-02-13 13:42  5%                   ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-11 20:01 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Got it.
> Although, it is confusing to have different formats of :process
> value depending on :file extension.

Indeed. For that reason I changed the original name I gave from
":pdf-process" to simply ":process". IMHO this function has a tremendous
problem: two methods coexist to convert a PDF compiled with LaTeX to an
image: the method with :imagemagick and the method without :imagemagick,
although this can also use imagemagick, which in itself is a first mess.
I don't know if this state of affairs is clear to the user...

The method without :imagemagick, furthermore, is the only one that
depends on a different process (leaving aside the case of conversion to
html, where another process is used).

The method with :imagemagick is, like the rest, more "transparent" (it is
the one I use, and I think many users prefer it):

TeX file --> compilation --> PDF --> conversion --> image file

The method without :imagemagick, which depends on the value of
org-preview-latex-default-process could be schematized like this:

TeX file --> {compilation + PDF + conversion + params.} --> image file

That is, the compilation and conversion processes along with the
parameters are included in the same pack.

> It would make things easier for users if
>     :results file :file foo.png :process '("lualatex -interaction nonstopmode
>     -output-directory %o %f")
>
> worked as expected, automatically overriding :latex-compiler value in
> let-bound `org-preview-latex-process-alist'.

I think that can cause certain drawbacks. Suppose a user has dvipng
as the value of org-preview-latex-default-process. If he/she puts

":process '(luatex etc ...)"

he/she will not be able to create the image because dvipng has the
value of ":image-converter" as the dvipng program, which, to put it
briefly and without going into details, would not work well with LuaTeX.
It is the problem of the same pack that I mentioned before. That's why I
think the lesser evil would be to allow the user to control the
necessary parameters at will, if the output file is an image file and
":imagemagick" is not present. Anyway, see what I say below.

>> Anyway, I don't understand why that feature option (convert to an image
>> without :imagemagick method) is limited to .png, when other graphic files are
>> possible. I can define something like this:
>>
>> (setq org-preview-latex-default-process
>>       '(my-process
>>      :programs ("lualatex" "convert")
>>      :description "pdf > jpg"
>>      :image-input-type "pdf"
>>      :image-output-type "jpg"
>>      :latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
>>      :image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>>
>> But if I put :file foo.jpg nothing happens. Maybe that part should be
>> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?
>
> I agree that it should be corrected.
> Moreover, it would be nice to unify handling .png and imagemagick
> branches of the code.

I agree. In any case, I still think that the coexistence of two methods
to convert to images, when one of the methods has a scheme so different
from the rest, becomes difficult: for the user as well as for
maintaining the code.

The first solution that occurs to me (I'm afraid it's too radical) is to
leave only the :imagemagick method, and maintain the possibility of
using the other one through a variable. Something like
org-babel-latex-default-image-conversion-method or something similar.
But I suppose this could cause unwanted inconveniences. We should see
what more users think.

Another possibility is to clarify the names a little more (for the user):

:image-conv [possible values: default, imagemagick (= :imagemagick yes)]

Best regards,

Juan Manuel

--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


^ permalink raw reply	[relevance 9%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 23:34 10%             ` Juan Manuel Macías
@ 2024-02-11 14:43  5%               ` Ihor Radchenko
  2024-02-11 20:01  9%                 ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-11 14:43 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> Considering that 'imagemagick is one of the variants in
>> `org-preview-latex-process-alist', it might be reasonable to allow
>> :process imagemagick == :imagemagick yes
>
> I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
> Instead, «:process 'imagemagick» depends on:
>
> (imagemagick :programs
> ...

Agree.

>> Also, it feels incomplete to be able to define latex command for :file
>> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.
>
> The ".png" method without ":imagemagick" does not depend on
> 'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
> depends on the value of 'org-preview-latex-default-process':
> ...
> If you put :file foo.png without :imagemagick, and want to control the
> process or change the compiler, you can do it with:
>
> :process '(foo :latex-compiler ("some LaTeX command")) 
>
> since this syntax is what org-preview-latex-default-process expects.
>
> In all other cases, including :imagemagick, the compilation process
> depends on the value of org-latex-pdf-process.

Got it.
Although, it is confusing to have different formats of :process
value depending on :file extension.

It would make things easier for users if
    :results file :file foo.png :process '("lualatex -interaction nonstopmode
    -output-directory %o %f")

worked as expected, automatically overriding :latex-compiler value in
let-bound `org-preview-latex-process-alist'.

> Anyway, I don't understand why that feature option (convert to an image
> without :imagemagick method) is limited to .png, when other graphic files are
> possible. I can define something like this:
>
> (setq org-preview-latex-default-process
>       '(my-process
> 	:programs ("lualatex" "convert")
> 	:description "pdf > jpg"
> 	:image-input-type "pdf"
> 	:image-output-type "jpg"
> 	:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
> 	:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))
>
> But if I put :file foo.jpg nothing happens. Maybe that part should be
> corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?

I agree that it should be corrected.
Moreover, it would be nice to unify handling .png and imagemagick
branches of the code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  @ 2024-02-11 11:04 12%             ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-11 11:04 UTC (permalink / raw)
  To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List

Pedro Andres Aranda Gutierrez writes:

> I agree it does not take advantage of the AUTO facility here, but I
> nevertheless think it would
> be interesting to show people how to do this. Until we expand the AUTO
> facility to cope with
> all quirks of multi-language in pdflatex (lualatex and xetex are a
> different pair of shoes), a quick
> and dirty alternative may be helpful for people. The introductory text
> could be

Pedro, the only problem I see with that is that it is an example of
LaTeX rather than Org. The only Org part here is #+LaTeX_header, and in
the entire section it's already made clear enough what it's used for.

Perhaps a brief reminder (the AUTO facility of the previous examples
is very limited) could be added first, and that if the users want to
obtain more complex, or more specific results (like the case you
exemplify for pdfLaTeX) they must put explicit LaTeX code, using
LaTeX_header. And then your example would come, but emphasizing that the
LaTeX documentation must be consulted. wdyt?

My point is that if we abuse examples of this type (at the expense of
"#+latex_header:something"), or "how is this done in LaTeX?", in the end
a LaTeX manual is made instead of Org.

I'm glad you enjoyed the jump to LuaTeX. :-)

Best regards,

Juan Manuel 


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 21:07  6%           ` Ihor Radchenko
@ 2024-02-10 23:34 10%             ` Juan Manuel Macías
  2024-02-11 14:43  5%               ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 23:34 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> I am attaching a new patch with this idea incorporated. I have also
>> changed the name from full-to-pdf to standalone.
>>
>> +             (process (cdr (assq :process params)))
>> +	     (org-preview-latex-default-process (if (and process
>> +							 (string-suffix-p ".png" out-file)
>> +							 (not imagemagick))
>
> Considering that 'imagemagick is one of the variants in
> `org-preview-latex-process-alist', it might be reasonable to allow
> :process imagemagick == :imagemagick yes

I wouldn't equate it. ':imagemagic yes' uses 'org-latex-convert-pdf'.
Instead, «:process 'imagemagick» depends on:

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

Also, one may want to put «:imagemagick yes» and compile the PDF
with another compiler or with a custom script:

:imagemagick yes :process '(...)

> Also, it feels incomplete to be able to define latex command for :file
> foo.pdf, but be limited to a pre-defined list of symbols for :file .png.

The ".png" method without ":imagemagick" does not depend on
'org-latex-pdf-process' but on 'org-create-formula-image', and this in turn
depends on the value of 'org-preview-latex-default-process':

...
((and (string-suffix-p ".png" out-file) (not imagemagick))
          (let ((org-format-latex-header
		 (concat org-format-latex-header "\n"
			 (mapconcat #'identity headers "\n"))))
	    (org-create-formula-image
             body out-file org-format-latex-options in-buffer)))
...

If you put :file foo.png without :imagemagick, and want to control the
process or change the compiler, you can do it with:

:process '(foo :latex-compiler ("some LaTeX command")) 

since this syntax is what org-preview-latex-default-process expects.

In all other cases, including :imagemagick, the compilation process
depends on the value of org-latex-pdf-process.

Anyway, I don't understand why that feature option (convert to an image
without :imagemagick method) is limited to .png, when other graphic files are
possible. I can define something like this:

(setq org-preview-latex-default-process
      '(my-process
	:programs ("lualatex" "convert")
	:description "pdf > jpg"
	:image-input-type "pdf"
	:image-output-type "jpg"
	:latex-compiler ("lualatex -interaction nonstopmode -output-directory %o %f")
	:image-converter ("convert -density %D -trim -antialias %f -quality 100 %O")))

But if I put :file foo.jpg nothing happens. Maybe that part should be
corrected... Something like (string-match-p "\\.png\\|\\.jpg\\|..." out-file)?

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 10%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 19:35 10%         ` Juan Manuel Macías
@ 2024-02-10 21:07  6%           ` Ihor Radchenko
  2024-02-10 23:34 10%             ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 21:07 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> I am attaching a new patch with this idea incorporated. I have also
> changed the name from full-to-pdf to standalone.
>
> +             (process (cdr (assq :process params)))
> +	     (org-preview-latex-default-process (if (and process
> +							 (string-suffix-p ".png" out-file)
> +							 (not imagemagick))

Considering that 'imagemagick is one of the variants in
`org-preview-latex-process-alist', it might be reasonable to allow
:process imagemagick == :imagemagick yes

Also, it feels incomplete to be able to define latex command for :file
foo.pdf, but be limited to a pre-defined list of symbols for :file .png.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 17:48 12%       ` Juan Manuel Macías
@ 2024-02-10 19:35 10%         ` Juan Manuel Macías
  2024-02-10 21:07  6%           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 19:35 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

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

Juan Manuel Macías writes:

>> Ihor Radchenko writes:

>> Would it make sense to make :pdf-process work for png previews as well?
>
> It would be ideal. The expected value for org-latex-pdf-process is a
> command or a list of commands, but org-preview-latex-default-process
> expects a plist of various processes and parameters. Maybe with some
> conditional? If only the png extension is provided (without the
> :imagemagick argument), then the expected value is for
> org-preview-latex-default-process. In all other cases, the value is for
> org-latex-pdf-process. The argument could then be called simply
> :process. E.g.:
>
> Assuming the user has somewhere (add-to-list
> org-preview-latex-process-alist my-process):
>
> :results file :file foo.png :process 'my-process [or :process '(a plist)]
>
> In other cases, like this:
>
> :imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")
>
> wdyt?

I am attaching a new patch with this idea incorporated. I have also
changed the name from full-to-pdf to standalone.

Best regards,

Juan Manuel


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2634 bytes --]

From a7f72015007722e665338c39b9a02d675c31cd93 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.

* (org-babel-execute:latex): `:process' allows modifying the value of
`org-latex-pdf-process' or `org-preview-latex-default-process' in a
specific block.  If only the `png' extension is provided (without the
`:imagemagick' argument), then the expected value is for
`org-preview-latex-default-process'. In all other cases, the value is
for `org-latex-pdf-process'.  This argument has no effect if the
conversion is to `HTML'.  The `:standalone' argument requires that
the LaTeX block contains all the code necessary to be compiled, as if
it were an autonomous LaTeX document: the expected result will always
be a PDF file.
---
 lisp/ob-latex.el | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..8bec0c661 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,14 @@ This function is called by `org-babel-execute-src-block'."
 	     (height (and fit (cdr (assq :pdfheight params))))
 	     (width (and fit (cdr (assq :pdfwidth params))))
 	     (headers (cdr (assq :headers params)))
+             (process (cdr (assq :process params)))
+	     (org-preview-latex-default-process (if (and process
+							 (string-suffix-p ".png" out-file)
+							 (not imagemagick))
+						    process
+						  org-preview-latex-default-process))
+	     (org-latex-pdf-process (if process process org-latex-pdf-process))
+	     (standalone (cdr (assq :standalone params)))
 	     (in-buffer (not (string= "no" (cdr (assq :buffer params)))))
 	     (org-latex-packages-alist
 	      (append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +195,14 @@ This function is called by `org-babel-execute-src-block'."
                              (list org-babel-latex-pdf-svg-process)
                              extension err-msg log-buf)))
               (rename-file img-out out-file t))))
+         ((and (string= "pdf" extension) standalone)
+	  (with-temp-file tex-file
+	    (insert body))
+	  (when (file-exists-p out-file) (delete-file out-file))
+	  (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+	    (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+		   (err-msg "org babel latex failed"))
+	      (rename-file tmp-pdf out-file t))))
          ((string-suffix-p ".tikz" out-file)
 	  (when (file-exists-p out-file) (delete-file out-file))
 	  (with-temp-file out-file
-- 
2.43.0


^ permalink raw reply related	[relevance 10%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 16:35  6%     ` Ihor Radchenko
@ 2024-02-10 17:48 12%       ` Juan Manuel Macías
  2024-02-10 19:35 10%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 17:48 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> May you please explain in more detail how these new header arguments fit
>>> into other available LaTeX code block parameters? In particular, when
>>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>>
>> Sure! `:pdf-process' simply applies a local value to
>> org-latex-pdf-process. It does not affect the export to png in its
>> version without imagemagick process, since this option depends on
>> org-create-formula-image, which in turn depends on
>> org-preview-latex-default-process. It also does not affect the export to
>> html, which depends on org-babel-latex-htlatex. It should work in all
>> other cases, including imagemagick, which ultimately depend on
>> org-latex-pdf-process.
>
> Would it make sense to make :pdf-process work for png previews as well?

It would be ideal. The expected value for org-latex-pdf-process is a
command or a list of commands, but org-preview-latex-default-process
expects a plist of various processes and parameters. Maybe with some
conditional? If only the png extension is provided (without the
:imagemagick argument), then the expected value is for
org-preview-latex-default-process. In all other cases, the value is for
org-latex-pdf-process. The argument could then be called simply
:process. E.g.:

Assuming the user has somewhere (add-to-list
org-preview-latex-process-alist my-process):

:results file :file foo.png :process 'my-process [or :process '(a plist)]

In other cases, like this:

:imagemagick yes :results file :file foo.png :process '("lualatex -interaction nonstopmode -output-directory %o %f")

wdyt?

>> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
>> better name), the expected result is a pdf file. Therefore it is
>> incompatible with exporting to png, svg or conversion with imagemagick.
>> For it to work, it is enough to provide these 2 args: ":file foo.pdf
>> :full-to-pdf yes."
>
> Maybe just :standalone?

Yes, I totally agree.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 15:20 12%   ` Juan Manuel Macías
@ 2024-02-10 16:35  6%     ` Ihor Radchenko
  2024-02-10 17:48 12%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 16:35 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> May you please explain in more detail how these new header arguments fit
>> into other available LaTeX code block parameters? In particular, when
>> exporting to .png/.svg/.html or when :imagemagick header argument is provided.
>
> Sure! `:pdf-process' simply applies a local value to
> org-latex-pdf-process. It does not affect the export to png in its
> version without imagemagick process, since this option depends on
> org-create-formula-image, which in turn depends on
> org-preview-latex-default-process. It also does not affect the export to
> html, which depends on org-babel-latex-htlatex. It should work in all
> other cases, including imagemagick, which ultimately depend on
> org-latex-pdf-process.

Would it make sense to make :pdf-process work for png previews as well?

> As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
> better name), the expected result is a pdf file. Therefore it is
> incompatible with exporting to png, svg or conversion with imagemagick.
> For it to work, it is enough to provide these 2 args: ":file foo.pdf
> :full-to-pdf yes."

Maybe just :standalone?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10 14:37  6% ` Ihor Radchenko
@ 2024-02-10 15:20 12%   ` Juan Manuel Macías
  2024-02-10 16:35  6%     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10 15:20 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> The attached patch adds two new header args to the LaTeX block:
>>
>> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>>   locally to the block. This can be useful for evaluating a given block
>>   with another LaTeX compiler, or even using some custom script.
>>   Example:
>> ...
>> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>>   should contain everything needed to be compiled, from \documentclass{}
>>   to \end{document}. Example:
>
> Thanks!
> May you please explain in more detail how these new header arguments fit
> into other available LaTeX code block parameters? In particular, when
> exporting to .png/.svg/.html or when :imagemagick header argument is provided.

Sure! `:pdf-process' simply applies a local value to
org-latex-pdf-process. It does not affect the export to png in its
version without imagemagick process, since this option depends on
org-create-formula-image, which in turn depends on
org-preview-latex-default-process. It also does not affect the export to
html, which depends on org-babel-latex-htlatex. It should work in all
other cases, including imagemagick, which ultimately depend on
org-latex-pdf-process.

As for `:full-to-pdf' (I don't know if standalone-to-pdf would be a
better name), the expected result is a pdf file. Therefore it is
incompatible with exporting to png, svg or conversion with imagemagick.
For it to work, it is enough to provide these 2 args: ":file foo.pdf
:full-to-pdf yes."

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: [patch] Add two new header args to LaTeX block
  2024-02-10  1:58  9% [patch] Add two new header args to LaTeX block Juan Manuel Macías
@ 2024-02-10 14:37  6% ` Ihor Radchenko
  2024-02-10 15:20 12%   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-10 14:37 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> The attached patch adds two new header args to the LaTeX block:
>
> - `:pdf-process' allows modifying the value of `org-latex-pdf-process'
>   locally to the block. This can be useful for evaluating a given block
>   with another LaTeX compiler, or even using some custom script.
>   Example:
> ...
> - `:full-to-pdf' makes the block like a standalone LaTeX document, which
>   should contain everything needed to be compiled, from \documentclass{}
>   to \end{document}. Example:

Thanks!
May you please explain in more detail how these new header arguments fit
into other available LaTeX code block parameters? In particular, when
exporting to .png/.svg/.html or when :imagemagick header argument is provided.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* [patch] Add two new header args to LaTeX block
@ 2024-02-10  1:58  9% Juan Manuel Macías
  2024-02-10 14:37  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-10  1:58 UTC (permalink / raw)
  To: orgmode

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

The attached patch adds two new header args to the LaTeX block:

- `:pdf-process' allows modifying the value of `org-latex-pdf-process'
  locally to the block. This can be useful for evaluating a given block
  with another LaTeX compiler, or even using some custom script.
  Example:

  #+begin_src latex :pdf-process '("lualatex -shell-escape -interaction nonstopmode -output-directory %o %f")
  \textbf{hello world}
  #+end_src

- `:full-to-pdf' makes the block like a standalone LaTeX document, which
  should contain everything needed to be compiled, from \documentclass{}
  to \end{document}. Example:

  #+begin_src latex :full-to-pdf yes
  \documentclass{article}  
  \begin{document}
  \textbf{hello world}
  \end{document}
  #+end_src

  I think both arguments can have many practical uses. For example, to
  compile separately and load multiple subdocuments, with different
  preambles:

   #+NAME: doc1
   #+begin_src org :exports none :results latex
    ,#+include: some-document.org
   #+end_src

  #+begin_src latex :noweb yes :results silent file :file file.pdf :full-to-pdf yes
    \documentclass{article}
    \usepackage[spanish]{babel}
    \usepackage{fontspec}
    \setmainfont{Vollkorn}
    \begin{document}
    <<doc1()>>
    \end{document}
  #+end_src

  #+latex: \includepdf{file.pdf}
  
  Or even to evaluate ConTeXt code within a LaTeX block:

  #+begin_src latex :full-to-pdf yes :results raw file :file file.pdf :pdf-process '("cd %o && context %f")
  \starttext
  \startsection[title={Testing ConTeXt}]
  Lorem ipsum dolor.
  \stopsection
  \stoptext
  #+end_src


Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-latex.el-Add-two-new-header-args-to-LaTeX-bl.patch --]
[-- Type: text/x-patch, Size: 2148 bytes --]

From fe1b40e2b22e2c668440bea13feda0ab7923bdd8 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias <maciaschain@posteo.net>
Date: Sat, 10 Feb 2024 02:01:08 +0100
Subject: [PATCH] lisp/ob-latex.el: Add two new header args to LaTeX block.

* (org-babel-execute:latex): `:pdf-process' allows modifying the value
of `org-latex-pdf-process' in a specific block.  The `:full-to-pdf'
argument requires that the LaTeX block contains all the code necessary
to be compiled, as if it were an autonomous LaTeX document: the
expected result will always be a PDF file.
---
 lisp/ob-latex.el | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index acb83228b..118d81338 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -162,6 +162,9 @@ This function is called by `org-babel-execute-src-block'."
 	     (height (and fit (cdr (assq :pdfheight params))))
 	     (width (and fit (cdr (assq :pdfwidth params))))
 	     (headers (cdr (assq :headers params)))
+             (pdf-process (cdr (assq :pdf-process params)))
+	     (org-latex-pdf-process (if pdf-process pdf-process org-latex-pdf-process))
+	     (full-to-pdf (cdr (assq :full-to-pdf params)))
 	     (in-buffer (not (string= "no" (cdr (assq :buffer params)))))
 	     (org-latex-packages-alist
 	      (append (cdr (assq :packages params)) org-latex-packages-alist)))
@@ -187,6 +190,14 @@ This function is called by `org-babel-execute-src-block'."
                              (list org-babel-latex-pdf-svg-process)
                              extension err-msg log-buf)))
               (rename-file img-out out-file t))))
+         ((and (string= "pdf" extension) full-to-pdf)
+	  (with-temp-file tex-file
+	    (insert body))
+	  (when (file-exists-p out-file) (delete-file out-file))
+	  (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+	    (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+		   (err-msg "org babel latex failed"))
+	      (rename-file tmp-pdf out-file t))))
          ((string-suffix-p ".tikz" out-file)
 	  (when (file-exists-p out-file) (delete-file out-file))
 	  (with-temp-file out-file
-- 
2.43.0


^ permalink raw reply related	[relevance 9%]

* Re: Link type for pdf-tools annotations
  2024-02-09 12:13  6% ` Irfan S
@ 2024-02-09 12:48 13%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09 12:48 UTC (permalink / raw)
  To: Irfan S; +Cc: orgmode

Irfan S writes:

> FYI, there is also
> [[https://github.com/fuxialexander/org-pdftools][org-pdftools]] which
> provides similar (and additional) functionality, and is on MELPA.
> Thanks for sharing your code.

Thank you very much, I didn't know that.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: Link type for pdf-tools annotations
  2024-02-08 23:25  6% ` Ihor Radchenko
@ 2024-02-09  0:40 11%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-09  0:40 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Many times I need to "save" an annotation point in the pdf-tools
>> annotations buffer. So I defined a new link type and the function to
>> store it. The link is stored with the structure:
>>
>> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
>>
>> The link opens the PDF and jumps to the specific annotation.
>
> You may also utilize `org-create-file-search-functions' and
> `org-execute-file-search-functions' to make an ordinary file: links
> works for the same purpose.

Thanks for the pointers. Note that in this use case I don't need to
search in the PDF file itself but in the pdf-annot-list-mode buffer that
is created via pdf-annot-list-annotations. This buffer is synchronized
with the PDF to which it is linked. What this link type does is visit
the pdf file (with pdf-tools), create the list of annotations and jump
to the specific annotation, by date.
pdf-annot-list-display-annotation-from-id highlights the specific list
annotation in the linked PDF (if necessary, moves to the corresponding
page), and opens the content of the annotation in another window
(interactively the function is executed by pressing SPC on the
annotation list at point). Storing the annotation date seemed like the
safest option to me, since the annotation id can change when adding new
annotations, each time the list is created. The typical scenario: when I
am consulting a PDF annotated by someone and I want to store the
location of some specific annotations. As there can be many annotations
per page, adding a simple bookmark to the page would not be enough
either.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: Link type for pdf-tools annotations
  2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
@ 2024-02-08 23:25  6% ` Ihor Radchenko
  2024-02-09  0:40 11%   ` Juan Manuel Macías
  2024-02-09 12:13  6% ` Irfan S
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-08 23:25 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Many times I need to "save" an annotation point in the pdf-tools
> annotations buffer. So I defined a new link type and the function to
> store it. The link is stored with the structure:
>
> [[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]
>
> The link opens the PDF and jumps to the specific annotation.

You may also utilize `org-create-file-search-functions' and
`org-execute-file-search-functions' to make an ordinary file: links
works for the same purpose.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Link type for pdf-tools annotations
@ 2024-02-08 22:13 11% Juan Manuel Macías
  2024-02-08 23:25  6% ` Ihor Radchenko
  2024-02-09 12:13  6% ` Irfan S
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-08 22:13 UTC (permalink / raw)
  To: orgmode

Hi,

Many times I need to "save" an annotation point in the pdf-tools
annotations buffer. So I defined a new link type and the function to
store it. The link is stored with the structure:

[[pdf-annot:/path/to/file.pdf::annotation-date][file-name.pdf (annot. on p. page-number)]]

The link opens the PDF and jumps to the specific annotation. A screenshot:

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

I share the code here in case it is useful to someone:

#+begin_src emacs-lisp

  (defun my-org-pdf-annot-store-link ()
    (when (equal (format "%s" major-mode) "pdf-annot-list-mode")
      (let* ((pdf-buf pdf-annot-list-document-buffer)
	     (pdf-file (buffer-file-name pdf-buf))
	     (annot (pdf-annot-getannot (tabulated-list-get-id) pdf-buf))
	     (date (pdf-annot-print-property annot 'modified))
	     (page (save-excursion
		     (beginning-of-line)
		     (re-search-forward "\\(^\s+\\)\\([[:digit:]]+\\)" nil t)
		     (match-string 2)))
	     (link (concat "pdf-annot:" pdf-file "::" date))
	     (desc (format "%s (annot. on p. %s)" (file-name-nondirectory pdf-file) page)))
	(org-link-store-props
	 :type "pdf-annot"
	 :link link
	 :description desc))))

  (org-link-set-parameters
   "pdf-annot"
   :follow (lambda (path)
	     (let ((a (if (string-match "::\\(.+\\)" path)
			  (match-string 1 path)
			(error "no annotation date")))
		   (file-path (replace-regexp-in-string "::.+" "" path)))
	       (find-file file-path)
	       (pdf-annot-list-annotations)
	       (let ((anot-buf (format "*%s's annots*"
				       (file-name-sans-extension
					(buffer-name)))))
		 (with-current-buffer anot-buf
		   (save-excursion
		     (goto-char (point-min))
		     (re-search-forward a nil t)
		     (call-interactively #'pdf-annot-list-display-annotation-from-id))))))
   :store #'my-org-pdf-annot-store-link)

#+end_src

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: Exporting multiple #+AUTHOR keywords
  @ 2024-02-04 22:13  9%                               ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 22:13 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Ihor Radchenko, orgmode

Max Nikulin writes:

> On 04/02/2024 22:21, Ihor Radchenko wrote:
>> 
>> Another option is to have a new set of keywords:
>> #+LATEX_AUTHOR: <author with formatting goes here>
>> #+HTML_AUTHOR: ...
>> 
>> For multiple authors, we may introduce something like
>> 
>> #+AUTHOR: John Doe
>> #+AUTHOR+: Luke Skywalker
>
> Another idea:
>
> #+metadata:
> - author ::
>    - John Doe
>    - Luke Skywalker
> - title :: Some text
>
> With overrides for specific backends
>
> #+metadata: :backend latex
> - author :: ....
>
> Perhaps backends may declare if they support footnotes, etc. by defining 
> some backend property.

I like both ideas. If I had to choose, perhaps I would prefer Ihor's
approach since it separates the formatting value and the metadata value
using simple keywords. I understand that in the former you could add any
direct format (LaTeX, odt, html...), macros and even footnotes. And if
the former is not explicitly included in the document, then the latter
is used to populate both the formatting value and the metadata value.

Anyway, I think your approach would work very well for more complex pdf
metadata like xmp. Maybe using the hyperxmp package, which you mentioned
in a thread months ago?

Maybe something like this:

#+latex_xmp
...
#+end

?

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 9%]

* Re: [DISCUSSION] Add "Recent News" to orgmode.org
  @ 2024-02-04 20:24 10% ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-04 20:24 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: emacs-orgmode, Sacha Chua, Bastien, Timothy

Ihor Radchenko writes:

> Hi,
>
> What do you think about an idea to modify Org mode front page
> (https://orgmode.org/), adding the most recent blog posts and
> discussions about Org mode?
>
> We might use Org-related records from Sacha's news and/or
> https://planet.emacslife.com/ as a source, scrape it regularly (once per
> day/week or on every export), and embed the relevant links into the
> orgweb/index.html
>
> This way, visitors can easily see how active Org mode community is and
> discover Org-related blogs/forums.

+1

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: Exporting multiple #+AUTHOR keywords
  2024-02-02 22:26 11%                         ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
@ 2024-02-04 15:21  6%                           ` Ihor Radchenko
    0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-04 15:21 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

> ... I think the basic problem is that org uses #+author, #+title, etc.
> as a single source for both the metadata strings and the exported
> format, i.e. the title, the author, the date that is printed somewhere.
>
> Perhaps the ideal would be to distinguish in some way between
> author-metadata and author-exported-format. For example something like:
>
> #+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
> Skywalker
>
> The optional string in square brackets would be the metadata; the rest
> would be the direct exported format. If there is no optional string, the
> value is used for both metadata and format. Could this be also a
> possible solution to the footnote problem?

Another option is to have a new set of keywords:
#+LATEX_AUTHOR: <author with formatting goes here>
#+HTML_AUTHOR: ...

For multiple authors, we may introduce something like

#+AUTHOR: John Doe
#+AUTHOR+: Luke Skywalker

That should be fully backwards-compatible.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: Exporting multiple #+AUTHOR keywords
  2024-02-02 20:21  5%                       ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
@ 2024-02-02 22:26 11%                         ` Juan Manuel Macías
  2024-02-04 15:21  6%                           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 22:26 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Sorry if this is off topic, but something like this:
>>
>> #+AUTHOR: Fred Astaire
>> #+AUTHOR: Ginger Rogers
>>
>> is exported to LaTeX as:
>>
>> \author{Fred Astaire Ginger Rogers}
>>
>> Shouldn't there be some separation? In LaTeX the usual thing is:
>>
>> \author{Fred Astaire \and Ginger Rogers}
>
> You can do
>
> #+AUTHOR: Fred
> #+AUTHOR: Astaire
>
> #+AUTHOR: and Ginger
> #+AUTHOR: Rogers
>
> The values are simply concatenated before passing to the exporter.
>
> Can we concatenate with "\and"? Sure. But not by default or it would be
> a breaking change.

Thanks for the explanation. I've never made documents with more than one
author, so I've never thought about this scenario. For a moment I
thought org supported more than one author (explicitly, I mean).

Anyway, \and is just a formatting command: add a space between two
authors. Some people may prefer to put a line break \\ or anything else.
Of course, \and (and any other format command) will have a negative
effect on the pdfauthor metadata, which only collects text strings. It
is a similar problem to the one with footnotes, which Maxim commented
on. I think the basic problem is that org uses #+author, #+title, etc.
as a single source for both the metadata strings and the exported
format, i.e. the title, the author, the date that is printed somewhere.

Perhaps the ideal would be to distinguish in some way between
author-metadata and author-exported-format. For example something like:

#+AUTHOR[John Doe and Luke Skywalker]: John Doe @@latex:\and@@ Luke
Skywalker

The optional string in square brackets would be the metadata; the rest
would be the direct exported format. If there is no optional string, the
value is used for both metadata and format. Could this be also a
possible solution to the footnote problem?

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía




^ permalink raw reply	[relevance 11%]

* Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc))
  2024-02-02 18:10 13%                     ` Juan Manuel Macías
@ 2024-02-02 20:21  5%                       ` Ihor Radchenko
  2024-02-02 22:26 11%                         ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-02 20:21 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

> Sorry if this is off topic, but something like this:
>
> #+AUTHOR: Fred Astaire
> #+AUTHOR: Ginger Rogers
>
> is exported to LaTeX as:
>
> \author{Fred Astaire Ginger Rogers}
>
> Shouldn't there be some separation? In LaTeX the usual thing is:
>
> \author{Fred Astaire \and Ginger Rogers}

You can do

#+AUTHOR: Fred
#+AUTHOR: Astaire
#+AUTHOR: and Ginger
#+AUTHOR: Rogers

The values are simply concatenated before passing to the exporter.

Can we concatenate with "\and"? Sure. But not by default or it would be
a breaking change.

In fact, you can already concatenate with "\and" when exporting
subtrees:

(push '("EXPORT_AUTHOR" . "\\and ") org-property-separators)

then

* This is test
:PROPERTIES:
:EXPORT_AUTHOR: John Doe
:EXPORT_AUTHOR+: David Stefanson
:END:
Text.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
  2024-02-02 17:00  5%                   ` Ihor Radchenko
@ 2024-02-02 18:10 13%                     ` Juan Manuel Macías
  2024-02-02 20:21  5%                       ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 18:10 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> #+AUTHOR: author1
> #+FN_AUTHOR: footnote for author 1
>
> #+AUTHOR: author2
> #+FN_AUTHOR: footnote for author 2

Sorry if this is off topic, but something like this:

#+AUTHOR: Fred Astaire
#+AUTHOR: Ginger Rogers

is exported to LaTeX as:

\author{Fred Astaire Ginger Rogers}

Shouldn't there be some separation? In LaTeX the usual thing is:

\author{Fred Astaire \and Ginger Rogers}

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 13%]

* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
  2024-02-01 17:44 10%                 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
  2024-02-01 17:57  5%                   ` Marvin Gülker
@ 2024-02-02 17:00  5%                   ` Ihor Radchenko
  2024-02-02 18:10 13%                     ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-02-02 17:00 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Max Nikulin, emacs-orgmode

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

>> #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 20535-0001]
>> it is probably not exported as expected anyway.
>
> How about using dedicated keywords? Something like:
>
> #+FN_AUTHOR: footnote text
> #+FN_TITLE: footnote text

What if you have multiple authors?

If you mean

#+AUTHOR: author1
#+FN_AUTHOR: footnote for author 1
#+AUTHOR: author2
#+FN_AUTHOR: footnote for author 2

, it is actually problematic because the code concatenates the values of
#+AUTHOR keywords before processing, and it is hard to know which author
corresponds to which footnote.


If we really need something safe, pre-processing values in ox.el and
producing backward-compatible :author value and addition
:author-w-footnotes value in the export INFO plist would be more
reasonable and less ugly. Still ugly though.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
  2024-02-02 16:18 12%   ` Juan Manuel Macías
@ 2024-02-02 16:41  0%     ` Pedro Andres Aranda Gutierrez
  0 siblings, 0 replies; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-02-02 16:41 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List

Hi,

I’m just trying to cover the “legacy” latex.
I’ve finally migrated to lualatex for my stuff, and it has really been worthwhile. But who knows what a conference might want me to use ;-P

Differentiating between pdflatex and lualatex was what my last patch was for.

I also sent a PoC for the fontenc stuff a couple of weeks ago. And I was trying to continue this work and collect info needed for handling fontenc when you need pdflatex as your latex compiler.

Best, /PA

> El 2 feb 2024, a las 17:18, Juan Manuel Macías <maciaschain@posteo.net> escribió:
> 
> Ihor Radchenko writes:
> 
>> #+LANGUAGE: fa
>> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>> 
>> #+latex_header: \usepackage[AUTO]{fontspec}
> 
> I think Pedro is referring to fontenc not fontspec. fontenc cannot be
> used in either lualatex or XelaTeX. fontspec is for advanced selection
> of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
> opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
> would say that what Pedro proposes is limited only to the output in
> pdfTeX.
> 
> -- 
> Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía
> 



^ permalink raw reply	[relevance 0%]

* Re: [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages
  @ 2024-02-02 16:18 12%   ` Juan Manuel Macías
  2024-02-02 16:41  0%     ` Pedro Andres Aranda Gutierrez
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-02-02 16:18 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

Ihor Radchenko writes:

> #+LANGUAGE: fa
> #+LaTeX_Header: \usepackage[AUTO]{polyglossia}
>
> #+latex_header: \usepackage[AUTO]{fontspec}

I think Pedro is referring to fontenc not fontspec. fontenc cannot be
used in either lualatex or XelaTeX. fontspec is for advanced selection
of truetype and opentype fonts in XeLatex and LuaLaTeX and setting
opentype properties. fontenc is for 'pre-Unicode' LaTeX font encoding. I
would say that what Pedro proposes is limited only to the output in
pdfTeX.

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 12%]

* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
  2024-02-01 17:44 10%                 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
@ 2024-02-01 17:57  5%                   ` Marvin Gülker
  2024-02-02 17:00  5%                   ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Marvin Gülker @ 2024-02-01 17:57 UTC (permalink / raw)
  To: emacs-orgmode


Am Donnerstag, dem 01. Februar 2024 schrieb Juan Manuel Macías:
> How about using dedicated keywords? Something like:
>
> #+FN_AUTHOR: footnote text
> #+FN_TITLE: footnote text

For reference -- I do not know if this prompted the discussion here --
just a few days ago I asked about footnotes in author information
because such footnotes are just so common in the field I write in. They
are used to give a short description of the author's position usually
("XY is a researcher at the chair of Foo Bar..."). Since in my field I
have to submit DOCX to journals, such footnotes should be properly
exported by ox-odt in particular.

Here is the thread over at emacs-humanities:
https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
It includes an ugly workaround I applied in form of an advice. A proper
solution directly in org would of course be much preferable.

I like the dedicated keyword solution. This way third party backends
will probably ignore the new keywords, because for them they will look
like a comment.

    Marvin

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kontakt@guelker.eu    | O<


^ permalink raw reply	[relevance 5%]

* Re: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)
  @ 2024-02-01 17:44 10%                 ` Juan Manuel Macías
  2024-02-01 17:57  5%                   ` Marvin Gülker
  2024-02-02 17:00  5%                   ` Ihor Radchenko
  0 siblings, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-02-01 17:44 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode

Ihor Radchenko writes:

> Max Nikulin <manikulin@gmail.com> writes:
>
>> On 26/01/2024 19:53, Ihor Radchenko wrote:
>>> So, I am leaning towards reverting that commit - that will allow things
>>> like
>>> 
>>> #+TITLE: This is a test title[fn::This is test]
>>
>> I hope, document metadata will be generated with stripped footnotes.
>
> This is a good point.
>
> For now, [fn::This is test], when passed to exporters, is simply treated
> as plain text.
>
> If we change the parser nesting rules, Org will pass footnote-reference
> objects instead.
>
> Then, in a number of parsers, if something like
> (org-export-data (plist-get info :title) info) or
> (org-export-data author info)
> is used, footnotes may break export because metadata fields often have
> special rules about markup that is allowed inside.
>
> In particular, ox-odt will be broken; ox-latex will be broken.
>
> Of course, we can adjust built-in backends to take into account the new
> parsing rules, but we have no control over the third-party backends.
>
> On the other hand, when user exports something like
>
> #+AUTHOR: John Doe[fn::935 Pennsylvania Avenue, NW Washington, D.C. 20535-0001]
> it is probably not exported as expected anyway.

How about using dedicated keywords? Something like:

#+FN_AUTHOR: footnote text
#+FN_TITLE: footnote text

I give these two examples because they are the two places where a
footnote of this type is expected. I know: it's ugly and corseted (what
to do if a title has more than one footnote or an "inner" footnote?).
But I suppose it would be safe for a basic case, since it would only be
necessary to modify org-latex-template, org-odt-template, etc., without
risk of unexpected results.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: An academic journal entirely made in Org-Mode
  2024-01-29 23:16  6% ` Dr. Arne Babenhauserheide
@ 2024-01-31 14:30  6%   ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-31 14:30 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: emacs-orgmode

Hi, Arne, thank you for your comments.

Dr. Arne Babenhauserheide writes:

> Hi,
>
> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Org-Publish and LuaTeX. If anyone is interested in the code I used for
>> specific aspects of the publication, I can share it here :-).
>
> That sounds very interesting! I’m writing roleplaying books and my
> website with org-mode and since there are many small pieces I found over
> the years, I expect that the solved problems for a journal will be very
> educational!

I am currently responsible for the production of five academic journals,
and I have ended up developing a fairly productive workflow using
org/luatex. A little background on the matter: in my editorial design
work I used to work only in (La)TeX, but I discovered that org can
function as a fairly competent high-level interface to LaTeX. One of the
main advantages is the clarity that a light markup language brings to
the content, since pure LaTeX code is cumbersome. I know LaTeX code
reasonably well (in fact, I'm working on a couple of packages for
LuaLaTeX), but it's not comfortable for me to work on content.
Naturally, for heavy and complex jobs, post-processing is always
necessary. Org is still very useful as it is not only a lightweight
markup language but also a set of tools. And, loosely speaking, a work
environment on Emacs (which in itself is a work environment).

The main challenge of this workflow is obtaining the content, the data,
from the Word documents that the authors deliver, since, unfortunately,
everyone uses Word. Pandoc does a good job, as long as the Word
documents arrive reasonably well structured. Unfortunately, this is not
the case, at least in Humanities. Word documents usually have the
following defects:

- abuse of direct format; 

- absence of applied styles, therefore it is impossible to obtain a
  hierarchical outline of the document;

- absence of an automated system of bibliographies and citations.
  Humanities authors don't even use "friendly" things like Zotero. That
  is, Humanities authors make citations and bibliographies by hand (!!),
  which means multiplying inconsistencies and typos.

Therefore, it is necessary to subject the original Word documents to a
cleaning process. Then I run pandoc using some templates and some custom
lua filters.

The journal is basically an org-publish project, where only the articles
and other parts are exported to *.tex files. There is a master document
that I export and compile using a function that runs latexmk in
interactive mode. This way I have more control over the parts, I can
deactivate nodes, etc. Each node, therefore, is an article, with a
series of properties: author, email, orcid-id, doi, title in English,
etc. In a sty document created ad hoc I have defined a series of LaTeX
variables, and then incorporated them into each heading. E.g.:

#+begin_src latex
  \def\@author{}
  \newcommand\author[1]{\def\@author{#1}}
  \def\@mail{}
  \newcommand\mail[1]{\def\@mail{#1}}
  \def\@doi{}
  \newcommand\doi[1]{\def\@doi{DOI: #1}}

etc...
#+end_src

I use org-capture to populate the nodes in the master document with all
that information.

>> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
>
> One small thing: the boxes for the abstract look pretty nice! How to
> create the complex tables on page 109ff would also be great to know.

The boxes are made with the mdframed package, which is very versatile for this type of
objets. The code used:

#+begin_src latex
\usepackage[framemethod=tikz,everyline=true]{mdframed}
#+end_src

A box style:

#+begin_src latex
  \colorlet{background}{gray!7}

  \mdfdefinestyle{mdabstracts}{%
    linewidth=.3pt,
    topline = true,
    leftline =true,
    rightline = true,
    bottomline = true,
    skipabove=0pt,
    skipbelow=2\bigskipamount, 
    leftmargin=0em,
    backgroundcolor=background,
    roundcorner = 5pt,
    innerleftmargin=1.5em,
    rightmargin=0em,
    innerrightmargin=1.5em,
    innertopmargin=1em,
    splittopskip=\topskip,
    innerbottommargin=1em,
  }
#+end_src

And an environment:

#+begin_src latex
  \newmdenv[style=mdabstracts]{abstracts}
#+end_src

As for tables, I always try to apply the ideas of Edward Tufte. I use the booktabs package
with some modifications. An example of a table:

https://i.imgur.com/70NtdGb.png

Here I use these two macros:

#+macro: cmd @@latex:\cmidrule(rl){$1}@@
#+macro: mc @@latex:\multicolumn{$1}{$2}{$3}@@

And this filter for multicolumn rows (simply, the cells that contain "!!" are removed:

#+BIND: org-export-filter-table-functions (my-multicolumn-filter)
#+begin_src emacs-lisp :exports results :results none
  (defun my-multicolumn-flilter (texto backend info)
    (when (org-export-derived-backend-p backend 'latex)
      (replace-regexp-in-string "&\s+!!" "" texto)))
#+end_src

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 6%]

* Re: An academic journal entirely made in Org-Mode
  2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
  2024-01-29 20:16  6% ` Daniel Ortmann
  2024-01-29 23:16  6% ` Dr. Arne Babenhauserheide
@ 2024-01-30  5:34  6% ` tomas
  2 siblings, 0 replies; 200+ results
From: tomas @ 2024-01-30  5:34 UTC (permalink / raw)
  To: emacs-orgmode

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

On Mon, Jan 29, 2024 at 08:03:36PM +0000, Juan Manuel Macías wrote:
> Hi,
> 
> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).

Very nice, thanks :)

Cheers
-- 
t

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

^ permalink raw reply	[relevance 6%]

* Re: An academic journal made entirely in Org-Mode
  2024-01-29 20:05 10% An academic journal made entirely " Juan Manuel Macías
@ 2024-01-30  0:00  6% ` William Denton
  0 siblings, 0 replies; 200+ results
From: William Denton @ 2024-01-30  0:00 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On Monday, January 29th, 2024 at 15:05, Juan Manuel Macías <maciaschain@posteo.net> wrote:

> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).

Fantastic work!  Congratulations.  Open scholarship in every sense of the word.  I'd love to see how you handled the publishing of such a complex project.  (And what citation style is used by that journal?)

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada



^ permalink raw reply	[relevance 6%]

* Re: An academic journal entirely made in Org-Mode
  2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
  2024-01-29 20:16  6% ` Daniel Ortmann
@ 2024-01-29 23:16  6% ` Dr. Arne Babenhauserheide
  2024-01-31 14:30  6%   ` Juan Manuel Macías
  2024-01-30  5:34  6% ` tomas
  2 siblings, 1 reply; 200+ results
From: Dr. Arne Babenhauserheide @ 2024-01-29 23:16 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: emacs-orgmode

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

Hi,

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

> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).

That sounds very interesting! I’m writing roleplaying books and my
website with org-mode and since there are many small pieces I found over
the years, I expect that the solved problems for a journal will be very
educational!

> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948

One small thing: the boxes for the abstract look pretty nice! How to
create the complex tables on page 109ff would also be great to know.

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

* Re: An academic journal entirely made in Org-Mode
  2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
@ 2024-01-29 20:16  6% ` Daniel Ortmann
  2024-01-29 23:16  6% ` Dr. Arne Babenhauserheide
  2024-01-30  5:34  6% ` tomas
  2 siblings, 0 replies; 200+ results
From: Daniel Ortmann @ 2024-01-29 20:16 UTC (permalink / raw)
  To: emacs-orgmode

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

Yes, please!

--
Daniel Ortmann<dortmann31415@pobox.com>
https://www.linkedin.com/in/danieldeanortmann/
https://ieee-collabratec.ieee.org/app/p/DanielDeanOrtmann/
612-518-3147 m

On 1/29/24 14:03, Juan Manuel Macías wrote:
> Hi,
>
> In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
> of Latin Studies) was published, sponsored by the Spanish Society of
> Latin Studies. It is designed and produced by me using Org-Mode,
> Org-Publish and LuaTeX. If anyone is interested in the code I used for
> specific aspects of the publication, I can share it here :-).
>
> Link to the journal in PDF version:
>
> https://recyt.fecyt.es/index.php/rel/issue/view/4327/948
>
> And a screenshot of the making-off:
>
> https://i.imgur.com/lkwIOGA.png
>
> Best regards,
>
> Juan Manuel
>
>
>
>
>
>

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

^ permalink raw reply	[relevance 6%]

* An academic journal made entirely in Org-Mode
@ 2024-01-29 20:05 10% Juan Manuel Macías
  2024-01-30  0:00  6% ` William Denton
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-29 20:05 UTC (permalink / raw)
  To: orgmode

Hi,

In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).

Link to the journal in PDF version:

https://recyt.fecyt.es/index.php/rel/issue/view/4327/948

And a screenshot of the making-off:

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

Best regards,

Juan Manuel 



-- 


^ permalink raw reply	[relevance 10%]

* An academic journal entirely made in Org-Mode
@ 2024-01-29 20:03 10% Juan Manuel Macías
  2024-01-29 20:16  6% ` Daniel Ortmann
                   ` (2 more replies)
  0 siblings, 3 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-29 20:03 UTC (permalink / raw)
  To: orgmode

Hi,

In last December, issue 23 of the "Revista de Estudios Latinos" (Journal
of Latin Studies) was published, sponsored by the Spanish Society of
Latin Studies. It is designed and produced by me using Org-Mode,
Org-Publish and LuaTeX. If anyone is interested in the code I used for
specific aspects of the publication, I can share it here :-).

Link to the journal in PDF version:

https://recyt.fecyt.es/index.php/rel/issue/view/4327/948

And a screenshot of the making-off:

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

Best regards,

Juan Manuel 







^ permalink raw reply	[relevance 10%]

* Re: [BUG] Footnotes in section titles
  2024-01-26 12:53  5%           ` Ihor Radchenko
@ 2024-01-26 13:17 11%             ` Juan Manuel Macías
    1 sibling, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-26 13:17 UTC (permalink / raw)
  To: Ihor Radchenko
  Cc: Colin Baxter, Max Nikulin, Eric Anderson, ihor Timothy, orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> ...
>> \title{Lorem ipsum dolor\thanks{blah blah}}
>> ...
>>
>> Org does not have support for this type of notes in the #+title or
>> #+author keywords. For LaTeX you can use a macro.
>
> Hmm.
> The reason footnotes are not allowed in #+title and other keywords is
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c
>
>     Inserting footnote references in parsed keywords (e.g., TITLE or
>     CAPTION) can lead to subtle bugs.  Indeed, it is impossible to know in
>     time if that particular footnote is going to be used in the output,
>     and, therefore, if it should count, e.g., in
>     `org-export-get-footnote-number'.
>
> However, I am not sure about that line of reasoning - we generally don't
> know if *any* given footnote reference is going to be used in the output
> or not because export backend may skip references or whole parts of the
> original Org file. Same for user filters.
>
> So, I am leaning towards reverting that commit - that will allow things
> like
>
> #+TITLE: This is a test title[fn::This is test]
>
> If we need special handling for footnotes in title (like using \thanks
> instead of \footnote), it is easy.

I completely agree. I think it would be a great improvement, since, as
Colin Baxter says, in academic articles it is a very common practice to
add foot notes to the title of the article or the name of the author.

As for the \thanks{} command, org exports the keyword #+email within a
\thanks{} command as '\author{Name\thanks{email}}0. I don't think two
\thanks macros collide within author (assuming the user adds the email
and puts a footnote in #+author. Anyway, I think the most common thing
is to put the email below the author's name, not as a footnote, but that
is another topic and also depends on the style of each publication,
journal, etc.

>> ... For backends like odt
>> it is trickier. Look at this thread:
>>
>> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
>>
>> I think it would be nice if Org had some kind of support for notes in
>> #+title and #+author...
>
> No idea about how to do it in ODT. If someone familiar with OpenDocument
> spec can help, it would be welcome.

I don't have much idea about odt, but I think the problem comes from a
type of nesting that is not allowed in the odt xml. I think org exports
#+author inside the initial-creator tag:

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

And within that tag the code for a footnote produces an error when
opening the document. If the footnote is placed right after
</meta:initial-creator>, there would be no problem.

Best regards,

Juan Manuel 
      

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: [BUG] Footnotes in section titles
  2024-01-24 15:41  9%         ` Juan Manuel Macías
@ 2024-01-26 12:53  5%           ` Ihor Radchenko
  2024-01-26 13:17 11%             ` Juan Manuel Macías
    0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-26 12:53 UTC (permalink / raw)
  To: Juan Manuel Macías
  Cc: Colin Baxter, Max Nikulin, Eric Anderson, ihor Timothy, orgmode

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

> ...
> \title{Lorem ipsum dolor\thanks{blah blah}}
> ...
>
> Org does not have support for this type of notes in the #+title or
> #+author keywords. For LaTeX you can use a macro.

Hmm.
The reason footnotes are not allowed in #+title and other keywords is
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ebe87e2d5fb6c

    Inserting footnote references in parsed keywords (e.g., TITLE or
    CAPTION) can lead to subtle bugs.  Indeed, it is impossible to know in
    time if that particular footnote is going to be used in the output,
    and, therefore, if it should count, e.g., in
    `org-export-get-footnote-number'.

However, I am not sure about that line of reasoning - we generally don't
know if *any* given footnote reference is going to be used in the output
or not because export backend may skip references or whole parts of the
original Org file. Same for user filters.

So, I am leaning towards reverting that commit - that will allow things
like

#+TITLE: This is a test title[fn::This is test]

If we need special handling for footnotes in title (like using \thanks
instead of \footnote), it is easy.

> ... For backends like odt
> it is trickier. Look at this thread:
>
> https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html
>
> I think it would be nice if Org had some kind of support for notes in
> #+title and #+author...

No idea about how to do it in ODT. If someone familiar with OpenDocument
spec can help, it would be welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [BUG] Footnotes in section titles
  2024-01-24 15:31  0%       ` Colin Baxter
@ 2024-01-24 15:41  9%         ` Juan Manuel Macías
  2024-01-26 12:53  5%           ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:41 UTC (permalink / raw)
  To: Colin Baxter
  Cc: Max Nikulin, Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode

Colin Baxter writes:

>     >> Perhaps it is better to avoid footnotes in titles and to add some
>     >> phrase to the body instead.
>
>     > That is the ideal scenario. I also believe that footnotes should
>     > be avoided in section headings, if possible. Or at least, have
>     > another type of numbering (symbols, letters...). The manyfoot and
>     > bigfoot packages allow constructions of this type, with various
>     > footnote apparatus.
>
> Indeed, but many journals *require* footnotes in titles, especially for
> affiliation, email, etc.

Notes on article titles (and even on the author name) are a slightly
different case from notes on section titles. In LaTeX there is the
"\thanks" command, which inserts footnotes for title and author,
numbered with fnsymbol. For example:

...
\title{Lorem ipsum dolor\thanks{blah blah}}
...

Org does not have support for this type of notes in the #+title or
#+author keywords. For LaTeX you can use a macro. For backends like odt
it is trickier. Look at this thread:

https://lists.gnu.org/archive/html/emacs-humanities/2024-01/msg00000.html

I think it would be nice if Org had some kind of support for notes in
#+title and #+author...

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [BUG] Footnotes in section titles
  2024-01-24 15:23 12%     ` Juan Manuel Macías
@ 2024-01-24 15:31  0%       ` Colin Baxter
  2024-01-24 15:41  9%         ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Colin Baxter @ 2024-01-24 15:31 UTC (permalink / raw)
  To: Juan Manuel Macías
  Cc: Max Nikulin, Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode

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

    > Max Nikulin writes:
    >> I recall some tricks with \footnotemark and \footnotetext, but I
    >> do not remember details and whether it may work for section
    >> titles.  Complications may arise if a heading title has several
    >> footnotes.

    > ox-latex has 'org-latex--delayed-footnotes-definitions': "[...]
    > This function is used within constructs that don't support
    > \footnote{} command (e.g., an item tag). In that case,
    > \footnotemark is used within the construct and the function just
    > outside of it."

    > The \footnotetext/\footnotemark option works well for specific
    > cases, but in general I don't like to abuse this method.

    >> Perhaps it is better to avoid footnotes in titles and to add some
    >> phrase to the body instead.

    > That is the ideal scenario. I also believe that footnotes should
    > be avoided in section headings, if possible. Or at least, have
    > another type of numbering (symbols, letters...). The manyfoot and
    > bigfoot packages allow constructions of this type, with various
    > footnote apparatus.

Indeed, but many journals *require* footnotes in titles, especially for
affiliation, email, etc.





^ permalink raw reply	[relevance 0%]

* Re: [BUG] Footnotes in section titles
  @ 2024-01-24 15:23 12%     ` Juan Manuel Macías
  2024-01-24 15:31  0%       ` Colin Baxter
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-24 15:23 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Eric Anderson, ihor Timothy, Ihor Radchenko, orgmode

Max Nikulin writes:

> I recall some tricks with \footnotemark and \footnotetext, but I do
> not remember details and whether it may work for section titles.
> Complications may arise if a heading title has several footnotes.

ox-latex has 'org-latex--delayed-footnotes-definitions': "[...] This
function is used within constructs that don't support \footnote{}
command (e.g., an item tag). In that case, \footnotemark is used within
the construct and the function just outside of it."

The \footnotetext/\footnotemark option works well for specific cases,
but in general I don't like to abuse this method.

> Perhaps it is better to avoid footnotes in titles and to add some
> phrase to the body instead.

That is the ideal scenario. I also believe that footnotes should be
avoided in section headings, if possible. Or at least, have another type
of numbering (symbols, letters...). The manyfoot and bigfoot packages
allow constructions of this type, with various footnote apparatus.

Best regards,

Juan Manuel 

-- 
Juan Manuel Macías -- 



^ permalink raw reply	[relevance 12%]

* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
    2024-01-20 16:04  0%   ` Ihor Radchenko
@ 2024-01-24 13:21  0%   ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-24 13:21 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin <manikulin@gmail.com> writes:

> Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX 
> to latex. Tue, 30 Nov 2021 16:56:00 +0000. 
> https://list.orgmode.org/87bl21vazj.fsf@posteo.net
>
> Likely should be modified a bit to support derived backends.

Done.
https://git.sr.ht/~bzg/worg/commit/405547ac

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 0%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-22 13:40  8%         ` Juan Manuel Macías
@ 2024-01-23  7:41  3%           ` Pedro Andres Aranda Gutierrez
  0 siblings, 0 replies; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-23  7:41 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List


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

Hi,

Attached is a _proof of concept_ for supporting AUTO in
\usepackage{fontenc}. Just an idea of how things could evolve.
This only uses a variable you can define as directory or file local to
control what is generated in the LaTeX file.
Could be expanded in the future to check #+language:

Best, /PA

On Mon, 22 Jan 2024 at 14:40, Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Ihor Radchenko writes:
>
> > Juan Manuel Macías <maciaschain@posteo.net> writes:
> >
> >> Pedro Andres Aranda Gutierrez writes:
> >>
> >>> +#+begin_example
> >>> +,#+latex_class_options: [greek,spanish,oneside]
> >>> +,#+language: es
> >>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> >>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> >>> +#+end_example
> >>
> >> I think this example doesn't take advantage of the AUTO facility, which
> >> is what the section is about.
>
> > Do you have any suggestions how to improve the patch?
>
> I would give an example that did include the AUTO 'facility', to unify
> with the rest of the examples in the section:
>
> #+language: es
> #+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> It is also said in the patch that this example is for pdfTeX, but it
> works equally well for LuaTeX and XeTeX, since Babel and alphabeta
> packages support both engines. However, the alphabeta package is not a
> specific package for writing texts in Greek. Rather, according to the
> package documentation: "The alphabeta package makes the standard macros
> for Greek letters in mathematical mode also available in text mode." In
> pdfTeX it is useful because you can enter the Greek input directly in
> Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
> be written directly, without the help of additional packages.
>
> >> ... Btw, maybe it would be nice to extend ''AUTO'' to
> >> latex_class_options and \PassOptionsToPackage? Something like:
> >
> > It would really be nice to have an ox-latex maintainer who is deeply
> > familiar with LaTeX :)
>
> My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
> willing to learn everything I can. And, naturally, I would like to help
> in any way I can. But my main problem (currently) is the lack of time to
> dedicate myself to it. My presence on this list is intermittent, and
> that for a maintainer is horrible. Maybe in a few months (spring
> perhaps), when my personal situation stabilizes a little, I could
> consider it...
>
> Best regards,
>
> Juan Manuel
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #1.2: Type: text/html, Size: 3828 bytes --]

[-- Attachment #2: 0001-PoC-support-AUTO-for-the-fontenc-package-in-LaTeX-ex.patch --]
[-- Type: text/x-patch, Size: 4180 bytes --]

From 66634498275a4dbea4cb8dc225db28bdea1bdf1a Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" <paaguti@gmail.com>
Date: Tue, 23 Jan 2024 08:31:46 +0100
Subject: [PATCH] PoC: support AUTO for the fontenc package in LaTeX exports

* lisp/org.el: Add `org-latex-fontenc' to support translation for
  \usepackage[AUTO]{fontenc}

* lisp/ox-latex.el: Implement rudimentary translation for the above

---
 lisp/org.el      | 17 ++++++++++++-----
 lisp/ox-latex.el | 36 ++++++++++++++++++++++++------------
 2 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index cf9abafac..d4356e15d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3401,9 +3401,16 @@ header, or they will be appended."
 	      x))
 	  (default-value var)))
 
+(defcustom org-latex-fontenc "T1"
+  "The fontenc for the file. Customise to LGR,T1 when including
+Greek, etc."
+  :group 'org-export-latex
+  :type 'string
+  :safe #'stringp)
+
 (defcustom org-latex-default-packages-alist
   '(("AUTO" "inputenc"  t ("pdflatex"))
-    ("T1"   "fontenc"   t ("pdflatex"))
+    ("AUTO" "fontenc"   t ("pdflatex"))
     (""     "graphicx"  t)
     (""     "longtable" nil)
     (""     "wrapfig"   nil)
@@ -15159,20 +15166,20 @@ INCREMENT-STEP divisor."
 	(setq hour (mod hour 24))
 	(setq pos-match-group 1
               new (format "-%02d:%02d" hour minute)))
-       
+
        ((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
 	(setq pos-match-group 6
               new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx))))
-       
+
        ((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
 	(setq pos-match-group 5
               ;; Never drop below X=1.
               new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))))))
-       
+
        ((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
 	(setq pos-match-group 9
               new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx))))
-       
+
        ((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
 	(setq pos-match-group 8
               ;; Never drop below X=0.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 57ea66ef1..6da8b8e53 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1639,6 +1639,17 @@ For non-floats, see `org-latex--wrap-label'."
 	      (org-trim label)
 	      (org-export-data main info))))))
 
+(defun org-latex-guess-fontenc (header)
+  "Set the fontenc.
+
+This is currently a copy of `org-latex-guess-inputenc'.
+Currently only goes for `org-latex-fontenc', but can be extended.
+Replaces AUTO for the font encoding string."
+  (let ((fenc org-latex-fontenc))
+    (if (not fenc) header
+      (replace-regexp-in-string "\\\\usepackage\\[\\(AUTO\\)\\]{fontenc}"
+                                fenc header t nil 1))))
+
 (defun org-latex-guess-inputenc (header)
   "Set the coding system in inputenc to what the buffer is.
 
@@ -1989,18 +2000,19 @@ specified in `org-latex-default-packages-alist' or
 	      (user-error "Unknown LaTeX class `%s'" class))))
     (org-latex-guess-polyglossia-language
      (org-latex-guess-babel-language
-      (org-latex-guess-inputenc
-       (org-element-normalize-string
-	(org-splice-latex-header
-	 class-template
-	 (org-latex--remove-packages org-latex-default-packages-alist info)
-	 (org-latex--remove-packages org-latex-packages-alist info)
-	 snippet?
-	 (mapconcat #'org-element-normalize-string
-		    (list (plist-get info :latex-header)
-			  (and (not snippet?)
-			       (plist-get info :latex-header-extra)))
-		    ""))))
+      (org-latex-guess-fontenc
+       (org-latex-guess-inputenc
+        (org-element-normalize-string
+	 (org-splice-latex-header
+	  class-template
+	  (org-latex--remove-packages org-latex-default-packages-alist info)
+	  (org-latex--remove-packages org-latex-packages-alist info)
+	  snippet?
+	  (mapconcat #'org-element-normalize-string
+		     (list (plist-get info :latex-header)
+			   (and (not snippet?)
+			        (plist-get info :latex-header-extra)))
+		     "")))))
       info)
      info)))
 
-- 
2.34.1


^ permalink raw reply related	[relevance 3%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-22 12:10  6%       ` Ihor Radchenko
@ 2024-01-22 13:40  8%         ` Juan Manuel Macías
  2024-01-23  7:41  3%           ` Pedro Andres Aranda Gutierrez
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-22 13:40 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>>> +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about.

> Do you have any suggestions how to improve the patch?

I would give an example that did include the AUTO 'facility', to unify
with the rest of the examples in the section:

#+language: es
#+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script

It is also said in the patch that this example is for pdfTeX, but it
works equally well for LuaTeX and XeTeX, since Babel and alphabeta
packages support both engines. However, the alphabeta package is not a
specific package for writing texts in Greek. Rather, according to the
package documentation: "The alphabeta package makes the standard macros
for Greek letters in mathematical mode also available in text mode." In
pdfTeX it is useful because you can enter the Greek input directly in
Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
be written directly, without the help of additional packages.

>> ... Btw, maybe it would be nice to extend ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>
> It would really be nice to have an ox-latex maintainer who is deeply
> familiar with LaTeX :)

My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
willing to learn everything I can. And, naturally, I would like to help
in any way I can. But my main problem (currently) is the lack of time to
dedicate myself to it. My presence on this list is intermittent, and
that for a maintainer is horrible. Maybe in a few months (spring
perhaps), when my personal situation stabilizes a little, I could
consider it...

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 8%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-22  6:47  0%         ` Pedro Andres Aranda Gutierrez
@ 2024-01-22 13:11  8%           ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-22 13:11 UTC (permalink / raw)
  To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List

Hi, Pedro Andrés,

Pedro Andres Aranda Gutierrez writes:

> PS: This is a very limited example. It would be nice to have more
> control on fontenc. AFAIK there is not alphabeta for cyrillic
> encodings and typesetting 'War and Peace' with its passages in French
> embedded in the Russian text is sort of a headache ;-)

For scripts other than Latin it is highly recommended to use the 'new'
Unicode versions of TeX, XeTeX or LuaTeX, especially the latter, since
it is the natural replacement for pdfTeX. The input is Unicode and you
can easily use true type or opentype fonts via the fontspec package.
Babel already has full support for these engines and it is not necessary
to use polyglossia. Even with Babel you can associate fonts with certain
scripts such as Greek, Cyrillic, Devanagari, etc. Look at this example I
made with several scripts and several fonts:
https://i.imgur.com/56P6U0R.png

I'm currently working on Org having multilingual font and script support
in LaTeX export with LuaTeX and babel. Although now I have put it on
hold due to lack of time :-). And Ihor is working on a much more
flexible language naming system. These are issues that were discussed,
among others, in this thread:

https://list.orgmode.org/878r9t7x7y.fsf@posteo.net/

Regarding your patch example, is there any special reason for you to
load the languages in the class options? It's perfectly valid, although,
as I said, it's not supported by org's AUTO facility (at the moment). I
understand that it is useful when the document is monolingual, but for
more than one language I find it unnecessary and, in addition to loading the
options with \PassOptionsToPackage.

Best regards,

Juan Manuel 



 


^ permalink raw reply	[relevance 8%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-21 17:47  9%     ` Juan Manuel Macías
  2024-01-22  6:30  6%       ` Pedro Andres Aranda Gutierrez
@ 2024-01-22 12:10  6%       ` Ihor Radchenko
  2024-01-22 13:40  8%         ` Juan Manuel Macías
  1 sibling, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-22 12:10 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Pedro Andres Aranda Gutierrez, Org Mode List

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

> Pedro Andres Aranda Gutierrez writes:
>
>> +#+begin_example
>> +,#+latex_class_options: [greek,spanish,oneside]
>> +,#+language: es
>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about.

Do you have any suggestions how to improve the patch?

> ... Btw, maybe it would be nice to extend ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:

It would really be nice to have an ox-latex maintainer who is deeply
familiar with LaTeX :)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-22  6:30  6%       ` Pedro Andres Aranda Gutierrez
@ 2024-01-22  6:47  0%         ` Pedro Andres Aranda Gutierrez
  2024-01-22 13:11  8%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-22  6:47 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List

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

PS: This is a very limited example. It would be nice to have more control
on fontenc. AFAIK there is not alphabeta for cyrillic encodings and
typesetting 'War and Peace' with its passages in French embedded in the
Russian text is sort of a headache ;-)

/PA

On Mon, 22 Jan 2024 at 07:30, Pedro Andres Aranda Gutierrez <
paaguti@gmail.com> wrote:

> HI Juan Manuel,
>
> you are absolutely right. There are many things that should improve in the
> LaTeX exporter and simplifying language treatment is one of them. What I
> show in my example is how to circumvent all the limitations in the exporter
> and give a working example for people who need it.
>
>  Adding AUTO to latex_class_options would be extremely helpful, since then
> you can load babel indicating the main language only and even avoid the
> PassOptions and can live with \usepackage{alphabeta} only.
> This is a MWE for mixing German and Greek which I use to compare with what
> org-mode generates:
>
> ---cut---
> \documentclass[greek,ngerman]{scrartcl}
> %% \documentclass[greek,ngerman]{scrreprt}
> %% \documentclass[greek,ngerman]{scrbook}
> %% \documentclass[greek,ngerman]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage[ngerman]{babel}
> %% \PassOptionsToPackage{main=ngerman}{babel}
> \usepackage{alphabeta}
>
> \begin{document}
> Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
> \verb|\textgreek{}|).\par
> Ach, unsere Freunde die Griechen: νους (direkt im Text).
> \end{document}
> ---cut---
> The commented document classes are all I had the time to test.
>
> Best, /PA
>
>
> On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías <maciaschain@posteo.net>
> wrote:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>> > +#+begin_example
>> > +,#+latex_class_options: [greek,spanish,oneside]
>> > +,#+language: es
>> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> > +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about. Btw, maybe it would be nice to extend
>> ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>>
>> #+latex_class_options: [greek,AUTO,oneside]
>> #+language: es
>> ...
>>
>> However, I would only find the \PassOptionsToPackage command useful in
>> classes that already load babel with a main language. From Org, using
>> just pdfTeX, I think it would be simpler:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek,AUTO]{babel}
>> #+latex_header: \usepackage{alphabeta} % to support greek script
>>
>> or this variant, using babelprovide and an INI file:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek]{babel}
>> #+latex_header: \babelprovide[import,main]{AUTO}
>> #+latex_header: \usepackage{alphabeta}
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

^ permalink raw reply	[relevance 0%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  2024-01-21 17:47  9%     ` Juan Manuel Macías
@ 2024-01-22  6:30  6%       ` Pedro Andres Aranda Gutierrez
  2024-01-22  6:47  0%         ` Pedro Andres Aranda Gutierrez
  2024-01-22 12:10  6%       ` Ihor Radchenko
  1 sibling, 1 reply; 200+ results
From: Pedro Andres Aranda Gutierrez @ 2024-01-22  6:30 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, Org Mode List

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

HI Juan Manuel,

you are absolutely right. There are many things that should improve in the
LaTeX exporter and simplifying language treatment is one of them. What I
show in my example is how to circumvent all the limitations in the exporter
and give a working example for people who need it.

 Adding AUTO to latex_class_options would be extremely helpful, since then
you can load babel indicating the main language only and even avoid the
PassOptions and can live with \usepackage{alphabeta} only.
This is a MWE for mixing German and Greek which I use to compare with what
org-mode generates:

---cut---
\documentclass[greek,ngerman]{scrartcl}
%% \documentclass[greek,ngerman]{scrreprt}
%% \documentclass[greek,ngerman]{scrbook}
%% \documentclass[greek,ngerman]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
%% \PassOptionsToPackage{main=ngerman}{babel}
\usepackage{alphabeta}

\begin{document}
Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
\verb|\textgreek{}|).\par
Ach, unsere Freunde die Griechen: νους (direkt im Text).
\end{document}
---cut---
The commented document classes are all I had the time to test.

Best, /PA


On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías <maciaschain@posteo.net>
wrote:

> Pedro Andres Aranda Gutierrez writes:
>
> > +#+begin_example
> > +,#+latex_class_options: [greek,spanish,oneside]
> > +,#+language: es
> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
> > +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about. Btw, maybe it would be nice to extend
> ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:
>
> #+latex_class_options: [greek,AUTO,oneside]
> #+language: es
> ...
>
> However, I would only find the \PassOptionsToPackage command useful in
> classes that already load babel with a main language. From Org, using
> just pdfTeX, I think it would be simpler:
>
> #+language: es
> #+latex_header: \usepackage[greek,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> or this variant, using babelprovide and an INI file:
>
> #+language: es
> #+latex_header: \usepackage[greek]{babel}
> #+latex_header: \babelprovide[import,main]{AUTO}
> #+latex_header: \usepackage{alphabeta}
>
> Best regards,
>
> Juan Manuel
>
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

^ permalink raw reply	[relevance 6%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-21 13:42  1%                                     ` Ihor Radchenko
@ 2024-01-21 19:25  9%                                       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-21 19:25 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:

> Upon looking closer into selective removal, it turned out to be more
> tricky than I thought. I'm afraid that using \\[0pt] only in some places
> may become a bit of headache to maintain - we may accidentally break
> certain regexp replacements in `org-latex-verse-block'. In particular,
> when verse contents is not straightforward and uses \\[0pt].
>
> Given that `org-latex-line-break-safe' also introduced the problem with
> verse blocks, I decided that it is better to remove it at the end.

LaTeX code generated without org-latex-line-break-safe is much cleaner.
The decision to make this variable obsolete seems correct to me, if
there is already a better and more discreet solution. I don't know if it
will cause many problems with custom settings and filters written in
relation to this variable, as Maxim commented in a previous email... I
hope not. I have a couple of filters written already, but I don't think
it will take much work for me to readjust them.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: New try at multi-lingual export to latex/pdf using pdflatex and babel
  @ 2024-01-21 17:47  9%     ` Juan Manuel Macías
  2024-01-22  6:30  6%       ` Pedro Andres Aranda Gutierrez
  2024-01-22 12:10  6%       ` Ihor Radchenko
    1 sibling, 2 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-21 17:47 UTC (permalink / raw)
  To: Pedro Andres Aranda Gutierrez; +Cc: Ihor Radchenko, Org Mode List

Pedro Andres Aranda Gutierrez writes:

> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example

I think this example doesn't take advantage of the AUTO facility, which
is what the section is about. Btw, maybe it would be nice to extend ''AUTO'' to
latex_class_options and \PassOptionsToPackage? Something like:

#+latex_class_options: [greek,AUTO,oneside]
#+language: es
...

However, I would only find the \PassOptionsToPackage command useful in
classes that already load babel with a main language. From Org, using
just pdfTeX, I think it would be simpler:

#+language: es
#+latex_header: \usepackage[greek,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script

or this variant, using babelprovide and an INI file:

#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 9%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 20:27  8%                                   ` Juan Manuel Macías
@ 2024-01-21 13:42  1%                                     ` Ihor Radchenko
  2024-01-21 19:25  9%                                       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-21 13:42 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

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

>> Although I am still a bit hesitant to remove
>> `org-latex-line-break-safe'.
>> What would be the benefit of removing it? For now, I mostly just see
>> that it will make the life harder for users in Scenario B.
>
> It's a complicated situation, because we now have two solutions to the
> same problem... It certainly sounds a bit abrupt to remove
> org-latex-line-break-safe (at least for now). I see no problem in both
> solutions coexisting. After all, the user can always give an "\\\\"
> value to org-latex-line-break-safe. The other possibility is that
> org-latex-line-break-safe is selectively deleted, as you mentioned in a
> previous email. In tables and verse blocks, unless I'm missing
> something, I think adding [0pt] would be unnecessary, with the new
> solution.

Upon looking closer into selective removal, it turned out to be more
tricky than I thought. I'm afraid that using \\[0pt] only in some places
may become a bit of headache to maintain - we may accidentally break
certain regexp replacements in `org-latex-verse-block'. In particular,
when verse contents is not straightforward and uses \\[0pt].

Given that `org-latex-line-break-safe' also introduced the problem with
verse blocks, I decided that it is better to remove it at the end.

See the attached tentative patchset.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2-0001-ox-latex-Make-sure-that-text-is-not-misinterprete.patch --]
[-- Type: text/x-patch, Size: 2518 bytes --]

From d2e74cc2734eaf8d782f5acf66b11956d6ffa47e Mon Sep 17 00:00:00 2001
Message-ID: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH v2 1/2] ox-latex: Make sure that [text] is not misinterpreted
 as LaTeX argument

* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [.  It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.

Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net
---
 lisp/ox-latex.el              |  9 +++++++++
 testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index df20345f8..a64dd5a87 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3095,6 +3095,15 @@ (defun org-latex-plain-text (text info)
 		    "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
                     (concat org-latex-line-break-safe "\n")
                     output nil t)))
+    ;; Protect [foo] at the beginning of lines / beginning of the
+    ;; plain-text object.  This prevents LaTeX from unexpectedly
+    ;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+    ;; optional argument.
+    (setq output (replace-regexp-in-string
+                  (rx bol (0+ space) (group "["))
+                  "{[}"
+                  output
+                  nil nil 1))
     ;; Return value.
     output))
 
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
 
 \f
 
+(ert-deftest text-ox-latex/protect-square-brackets ()
+  "Test [foo] being interpreted as plain text even after LaTeX commands."
+  (org-test-with-exported-text
+      'latex
+      "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+    (goto-char (point-min))
+    (should (search-forward "lorem \\pagebreak {[}ipsum]"))
+    (should (search-forward "{[}lorem] figure"))
+    (should (search-forward "{[}foo]"))
+    (should (search-forward "\\item {[}bax]"))))
+
 (ert-deftest test-ox-latex/verse ()
   "Test verse blocks."
   (org-test-with-exported-text
-- 
2.43.0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: v2-0002-ox-latex-Remove-org-latex-line-break-safe.patch --]
[-- Type: text/x-patch, Size: 11526 bytes --]

From dd4618b31dc5070d6802e484fd58cf50f5d3606d Mon Sep 17 00:00:00 2001
Message-ID: <dd4618b31dc5070d6802e484fd58cf50f5d3606d.1705844367.git.yantar92@posteo.net>
In-Reply-To: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
References: <d2e74cc2734eaf8d782f5acf66b11956d6ffa47e.1705844367.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Sun, 21 Jan 2024 14:21:33 +0100
Subject: [PATCH v2 2/2] ox-latex: Remove org-latex-line-break-safe

This reverts commit 3f60acff7717e472d06833e9cf9fff6ca3d59337 and
subsequent relevant comments.

* lisp/ox-latex.el (org-latex-line-break-safe): Remove constant.  The
\\[0pt] is actually not safe to use in some scenarios. We use a
different approach to avoid plain text [...] being interpreted as
LaTeX optional argument - we escape [ like {[}; that's what pandoc
does.
(org-latex-clock):
(org-latex-line-break):
(org-latex-plain-text):
(org-latex-planning):
(org-latex--org-table):
(org-latex--math-table):
(org-latex-table-row):
(org-latex-verse-block):
* testing/lisp/test-org-table.el (test-org-table/to-latex):
* testing/lisp/test-ox-latex.el (test-ox-latex/verse):
(test-ox-latex/longtable): Remove references to
`org-latex-line-break-safe'.
* etc/ORG-NEWS (=ox-latex=: ~org-latex-line-break-safe~ is removed):
Announce removal.
* lisp/org-compat.el (org-latex-line-break-safe): Make obsolete.

Link: https://orgmode.org/list/878r4jg37s.fsf@posteo.net
---
 etc/ORG-NEWS                   | 10 +++++++
 lisp/org-compat.el             | 18 +++++++++++++
 lisp/ox-latex.el               | 49 ++++++++++++----------------------
 testing/lisp/test-org-table.el |  6 ++---
 testing/lisp/test-ox-latex.el  | 16 +++++------
 5 files changed, 56 insertions(+), 43 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 847ddf614..46f1e66a7 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,16 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** =ox-latex=: ~org-latex-line-break-safe~ is removed
+
+~org-latex-line-break-safe~ constant was previously introduced to deal
+with edge cases when LaTeX interprets [...] as LaTeX command
+argument.  However, it caused a number of other issues and proved
+itself not to be as "safe" as it supposed to be.
+
+We now use a Pandoc's approach to deal with the same problem,
+utilizing ={[}= to escape =[...]= instances where needed.
+
 *** ~org-agenda-search-headline-for-time~ now ignores all the timestamp in headings
 
 Previously, ~org-agenda-search-headline-for-time~ made Org agenda
diff --git a/lisp/org-compat.el b/lisp/org-compat.el
index 17f07db9d..27d094b07 100644
--- a/lisp/org-compat.el
+++ b/lisp/org-compat.el
@@ -629,6 +629,24 @@ (define-obsolete-variable-alias 'org-reveal-start-hook
 (define-obsolete-function-alias 'org-file-url-p 'org-url-p "9.6")
 (define-obsolete-variable-alias 'org-plantuml-executable-args 'org-plantuml-args
   "Org 9.6")
+
+(defconst org-latex-line-break-safe "\\\\[0pt]"
+  "Linebreak protecting the following [...].
+
+Without \"[0pt]\" it would be interpreted as an optional argument to
+the \\\\.
+
+This constant, for example, makes the below code not err:
+
+\\begin{tabular}{c|c}
+    [t] & s\\\\[0pt]
+    [I] & A\\\\[0pt]
+    [m] & kg
+\\end{tabular}")
+(make-obsolete 'org-latex-line-break-safe
+               "should not be used - it is not safe in all the scenarios."
+               "9.7")
+
 (defun org-in-fixed-width-region-p ()
   "Non-nil if point in a fixed-width region."
   (save-match-data
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a64dd5a87..d6e74cb45 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -298,23 +298,10 @@ (defconst org-latex-language-alist
 - `:script-tag' the script otf tag.")
 
 
-(defconst org-latex-line-break-safe "\\\\[0pt]"
-  "Linebreak protecting the following [...].
 
-Without \"[0pt]\" it would be interpreted as an optional argument to
-the \\\\.
-
-This constant, for example, makes the below code not err:
-
-\\begin{tabular}{c|c}
-    [t] & s\\\\[0pt]
-    [I] & A\\\\[0pt]
-    [m] & kg
-\\end{tabular}")
-
-(defconst org-latex-table-matrix-macros `(("bordermatrix" . "\\cr")
+(defconst org-latex-table-matrix-macros '(("bordermatrix" . "\\cr")
 					  ("qbordermatrix" . "\\cr")
-					  ("kbordermatrix" . ,org-latex-line-break-safe))
+					  ("kbordermatrix" . "\\\\"))
   "Alist between matrix macros and their row ending.")
 
 (defconst org-latex-math-environments-re
@@ -2124,7 +2111,7 @@ (defun org-latex-clock (clock _contents info)
 	   (concat (org-timestamp-translate (org-element-property :value clock))
 		   (let ((time (org-element-property :duration clock)))
 		     (and time (format " (%s)" time)))))
-   org-latex-line-break-safe))
+   "\\\\"))
 
 
 ;;;; Code
@@ -2722,7 +2709,7 @@ ;;;; Line Break
 (defun org-latex-line-break (_line-break _contents _info)
   "Transcode a LINE-BREAK object from Org to LaTeX.
 CONTENTS is nil.  INFO is a plist holding contextual information."
-  (concat org-latex-line-break-safe "\n"))
+  "\\\\\n")
 
 
 ;;;; Link
@@ -3092,9 +3079,7 @@ (defun org-latex-plain-text (text info)
     ;; Handle break preservation if required.
     (when (plist-get info :preserve-breaks)
       (setq output (replace-regexp-in-string
-		    "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
-                    (concat org-latex-line-break-safe "\n")
-                    output nil t)))
+		    "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n" "\\\\\n" output nil t)))
     ;; Protect [foo] at the beginning of lines / beginning of the
     ;; plain-text object.  This prevents LaTeX from unexpectedly
     ;; interpreting @@latex:\pagebreak@@ [foo] as a command with
@@ -3139,7 +3124,7 @@ (defun org-latex-planning (planning _contents info)
 		(format (plist-get info :latex-active-timestamp-format)
 			(org-timestamp-translate scheduled)))))))
     " ")
-   org-latex-line-break-safe))
+   "\\\\"))
 
 
 ;;;; Property Drawer
@@ -3919,11 +3904,11 @@ (defun org-latex--org-table (table contents info)
 		(format "\\begin{%s}%s{%s}\n" table-env width alignment)
 		(and above?
 		     (org-string-nw-p caption)
-		     (concat caption org-latex-line-break-safe "\n"))
+		     (concat caption "\\\\\n"))
 		contents
 		(and (not above?)
 		     (org-string-nw-p caption)
-		     (concat caption org-latex-line-break-safe "\n"))
+		     (concat caption "\\\\\n"))
 		(format "\\end{%s}" table-env)
 		(and fontsize "}"))))
      (t
@@ -4008,7 +3993,7 @@ (defun org-latex--math-table (table info)
 		 (lambda (cell)
 		   (substring (org-element-interpret-data cell) 0 -1))
 		 (org-element-map row 'table-cell #'identity info) "&")
-		(or (cdr (assoc env org-latex-table-matrix-macros)) org-latex-line-break-safe)
+		(or (cdr (assoc env org-latex-table-matrix-macros)) "\\\\")
 		"\n")))
 	   (org-element-map table 'table-row #'identity info) "")))
     (concat
@@ -4083,7 +4068,7 @@ (defun org-latex-table-row (table-row contents info)
             (setq table-head-cache (make-hash-table :test #'eq))
             (plist-put info :org-latex-table-head-cache table-head-cache))
           (if-let ((head-contents (gethash (org-element-parent table-row) table-head-cache)))
-              (puthash (org-element-parent table-row) (concat head-contents org-latex-line-break-safe "\n" contents)
+              (puthash (org-element-parent table-row) (concat head-contents "\\\\\n" contents)
                        table-head-cache)
             (puthash (org-element-parent table-row) contents table-head-cache))))
       ;; Return LaTeX string as the transcoder.
@@ -4092,7 +4077,7 @@ (defun org-latex-table-row (table-row contents info)
        ;; hline was specifically marked.
        (and booktabsp (not (org-export-get-previous-element table-row info))
 	    "\\toprule\n")
-       contents org-latex-line-break-safe "\n"
+       contents "\\\\\n"
        (cond
 	;; Special case for long tables.  Define header and footers.
 	((and longtablep (org-export-table-row-ends-header-p table-row info))
@@ -4100,9 +4085,9 @@ (defun org-latex-table-row (table-row contents info)
 			      (org-element-lineage table-row 'table) info))))
 	   (format "%s
 \\endfirsthead
-\\multicolumn{%d}{l}{%s} \\\\[0pt]
+\\multicolumn{%d}{l}{%s} \\\\
 %s
-%s \\\\[0pt]\n
+%s \\\\\n
 %s
 \\endhead
 %s\\multicolumn{%d}{r}{%s} \\\\
@@ -4211,15 +4196,15 @@ (defun org-latex-verse-block (verse-block contents info)
 	       (replace-regexp-in-string
                 (if (not lit)
 		    (rx-to-string
-                     `(seq (group ,org-latex-line-break-safe "\n")
-		           (1+ (group line-start (0+ space) ,org-latex-line-break-safe "\n"))))
-		  (concat "^[ \t]*" (regexp-quote org-latex-line-break-safe) "$"))
+                     `(seq (group "\\\\\n")
+		           (1+ (group line-start (0+ space) "\\\\\n"))))
+		  "^[ \t]*\\\\$")
 	        (if (not lit)
 		    (if lin "\\\\!\n\n" "\n\n")
 		  "\\vspace*{\\baselineskip}")
 	        (replace-regexp-in-string
 	         "\\([ \t]*\\\\\\\\\\)?[ \t]*\n"
-                 (concat org-latex-line-break-safe "\n")
+                 "\\\\\n"
 	         (if (not lit)
 		     (concat (org-trim contents t) "\n")
 		   contents)
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 92ccd2a05..6ee790894 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1633,11 +1633,11 @@ (ert-deftest test-org-table/to-generic ()
 (ert-deftest test-org-table/to-latex ()
   "Test `orgtbl-to-latex' specifications."
   (should
-   (equal "\\begin{tabular}{l}\na\\\\[0pt]\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\na\\\\\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |") nil)))
   ;; Test :environment parameter.
   (should
-   (equal "\\begin{tabularx}{l}\na\\\\[0pt]\n\\end{tabularx}"
+   (equal "\\begin{tabularx}{l}\na\\\\\n\\end{tabularx}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |")
 			   '(:environment "tabularx"))))
   ;; Test :booktabs parameter.
@@ -1646,7 +1646,7 @@ (ert-deftest test-org-table/to-latex ()
     "\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t))))
   ;; Handle LaTeX snippets.
   (should
-   (equal "\\begin{tabular}{l}\n\\(x\\)\\\\[0pt]\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\n\\(x\\)\\\\\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil)))
   ;; Test pseudo objects and :raw parameter.
   (should
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 237ad97ec..d0be4e5a4 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -71,14 +71,14 @@ (ert-deftest test-ox-latex/verse ()
     (should
      (search-forward
       "\\begin{verse}
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
 lorem ipsum dolor
 
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
 lorem ipsum dolor
 
-lorem ipsum dolor\\\\[0pt]
-lorem ipsum dolor\\\\[0pt]
+lorem ipsum dolor\\\\
+lorem ipsum dolor\\\\
 \\end{verse}"))))
 
 (ert-deftest test-ox-latex/longtable ()
@@ -98,15 +98,15 @@ (ert-deftest test-ox-latex/longtable ()
     (should
      (search-forward
       "\\begin{longtable}{lr}
-First & Second\\\\[0pt]
-Column & Column\\\\[0pt]
+First & Second\\\\
+Column & Column\\\\
 \\hline
 \\endfirsthead"))
     (goto-char (point-min))
     (should
      (search-forward
-      "First & Second\\\\[0pt]
-Column & Column \\\\[0pt]
+      "First & Second\\\\
+Column & Column \\\\
 
 \\hline
 \\endhead"))
-- 
2.43.0


[-- Attachment #4: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

^ permalink raw reply related	[relevance 1%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 18:47  5%                                 ` Ihor Radchenko
  2024-01-20 20:27  8%                                   ` Juan Manuel Macías
@ 2024-01-21  6:06  3%                                   ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2024-01-21  6:06 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 21/01/2024 01:47, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
>>
>> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory

I agree with Juan Manuel.

> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.

An option might be disabling it by default without removing the code 
completely. Depending on user feedback it may be removed later.

Users, who need to submit LaTeX code, consider [0pt] as undesired noise. 
I see their point of view.


^ permalink raw reply	[relevance 3%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 18:47  5%                                 ` Ihor Radchenko
@ 2024-01-20 20:27  8%                                   ` Juan Manuel Macías
  2024-01-21 13:42  1%                                     ` Ihor Radchenko
  2024-01-21  6:06  3%                                   ` Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 20:27 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:

> I see your point.
> Although I am still a bit hesitant to remove
> `org-latex-line-break-safe'.
> What would be the benefit of removing it? For now, I mostly just see
> that it will make the life harder for users in Scenario B.

It's a complicated situation, because we now have two solutions to the
same problem... It certainly sounds a bit abrupt to remove
org-latex-line-break-safe (at least for now). I see no problem in both
solutions coexisting. After all, the user can always give an "\\\\"
value to org-latex-line-break-safe. The other possibility is that
org-latex-line-break-safe is selectively deleted, as you mentioned in a
previous email. In tables and verse blocks, unless I'm missing
something, I think adding [0pt] would be unnecessary, with the new
solution.

> For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)

From the tests I have done, the problem of the vertical space being
altered after the verse environment only appears when the last line ends
in \\[0pt]. If it ends in \\ the problem does not appear. It is not
recommended that a verse environment ends in \\, but it does not seem to
influence the output. In fact, that was how it was in Org in the days
pre org-latex-line-break-safe and there were never any problems.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 15:41  9%                               ` Juan Manuel Macías
@ 2024-01-20 18:47  5%                                 ` Ihor Radchenko
  2024-01-20 20:27  8%                                   ` Juan Manuel Macías
  2024-01-21  6:06  3%                                   ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-20 18:47 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

> Scenario B:
>
> lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory

I see your point.
Although I am still a bit hesitant to remove
`org-latex-line-break-safe'.
What would be the benefit of removing it? For now, I mostly just see
that it will make the life harder for users in Scenario B.

For verse blocks, AFAIU, even \\ is problematic. (Correct me if I am wrong)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated
  @ 2024-01-20 16:04  0%   ` Ihor Radchenko
  2024-01-24 13:21  0%   ` Ihor Radchenko
  1 sibling, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-20 16:04 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin <manikulin@gmail.com> writes:

> On 18/02/2023 17:18, Ihor Radchenko wrote:
>> In https://orgmode.org/worg/org-faq.html#org60202b9, the answer uses
>> obsolete function `org-add-link-type'. We should change it to
>> `org-link-set-parameters'.
>
> Confirmed.

Fixed.
https://git.sr.ht/~bzg/worg/commit/3194e6d5

> A newer recipe:
>
> Juan Manuel Macías to emacs-orgmode… Re: how to export red colored TeX 
> to latex. Tue, 30 Nov 2021 16:56:00 +0000. 
> https://list.orgmode.org/87bl21vazj.fsf@posteo.net
>
> Likely should be modified a bit to support derived backends.

I think we do not do this in any of the examples for :export link
property in WORG. I am actually not sure how to update things to work
for derived backends as well.

> The following package might be mentioned:
>
> Colours section in org-special-block-extras
> https://alhassy.com/org-special-block-extras/#Colours

Agree.
https://git.sr.ht/~bzg/worg/commit/5edf3ab0

> Other files:
> - org-tutorials/org-R/org-variables-counts.org
> - org-tutorials/org-R/variable-popcon.org
> - org-configs/org-customization-survey.org
> - org-configs/org-customization-survey-2013.org

These are not relevant - they contain tables for old Org mode
customization polls.

> Need review:
> - org-hacks.org
>    mid: links for org-gnus (not ol-gnus) and org-occur example

Done.
https://git.sr.ht/~bzg/worg/commit/83e85f8e

> - exporters/anno-bib-template-worg.org
>    citations using ebib

Thomas kindly updated the whole thing.
https://git.sr.ht/~bzg/worg/commit/c864fe68

> Outdated:
> - org-tutorials/org-latex-export.org
>    Org < 8.0

This is also authored by Thomas. I will ask him in another thread.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 0%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 13:46  5%                             ` Ihor Radchenko
@ 2024-01-20 15:41  9%                               ` Juan Manuel Macías
  2024-01-20 18:47  5%                                 ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 15:41 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> Paragraph\\
>>> @@latex:[foo]@@
>>
>> But since in both cases it is literal LaTeX code, the correct thing
>> would be for the user to be in charge of adding the curly braces to the
>> square brackets. I mean in such scenario it is LaTeX code, not Org.
>
> Not really. Because we do not give guarantees about the details of LaTeX
> export, we should try hard to not break things that users may put into
> literal export snippets.
>
>> Anyway, in both examples it does not make sense for LaTeX to end a
>> paragraph with the \\ macro, which is why we commented in previous
>> messages in the thread. The \\ macro is only used in horizontal mode;
>> this macro does not add a new paragraph but rather a forced line break
>> within the paragraph.
>
> In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
> - it is inside paragraph.

What I mean is that literal LaTeX code is LaTeX code, despite the
redundancy. IMHO, Org's only duty in that case is to export such literal
code as valid LaTeX code, but Org "does not know" what that literal code
consists of. The user who enters the literal LaTeX code is the one who
has the duty to add the necessary elements to that code so that it is
compiled correctly by LaTeX. Let's look at this as a territorial
question:

Scenario A:

@@LaTeX:\libebreak@@ [ipsum] ==> the problem is in Org territory

Scenario B:

lorem\\ @@latex:[ipsum]@@ ==> the problem is in the user's territory

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 13:22  9%                           ` Juan Manuel Macías
@ 2024-01-20 13:46  5%                             ` Ihor Radchenko
  2024-01-20 15:41  9%                               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-20 13:46 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

>> Paragraph\\
>> @@latex:[foo]@@
>
> But since in both cases it is literal LaTeX code, the correct thing
> would be for the user to be in charge of adding the curly braces to the
> square brackets. I mean in such scenario it is LaTeX code, not Org.

Not really. Because we do not give guarantees about the details of LaTeX
export, we should try hard to not break things that users may put into
literal export snippets.

> Anyway, in both examples it does not make sense for LaTeX to end a
> paragraph with the \\ macro, which is why we commented in previous
> messages in the thread. The \\ macro is only used in horizontal mode;
> this macro does not add a new paragraph but rather a forced line break
> within the paragraph.

In the example with @@latex:[foo]@@, \\ is not at the end of a paragraph
- it is inside paragraph.

Another alternative could be modifying how inline latex snippet is
exported, but that's worse IMHO - we should try hard not to touch what
users tell Org to do explicitly.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-20 12:34  5%                         ` Ihor Radchenko
@ 2024-01-20 13:22  9%                           ` Juan Manuel Macías
  2024-01-20 13:46  5%                             ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-20 13:22 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> \begin{itemize}
>>> \item {[}bax]
>>> \item {[}aur]
>>> \end{itemize}
>>
>> Great! Simple and effective. And more surgical than pandoc's global
>> solution. But now a question arises... Your code clearly solves the
>> problem that led to the declaration of org-latex-line-break-safe,
>> without foreseeing any unwanted effects, since it is the solution that
>> is usually recommended from LaTeX. So, if this code is included in Org,
>> what is the future of org-latex-line-break-safe?
>
> It is still useful in situations like
>
> Paragraph\\
>
> #+begin_export latex
> [foo]
> #+end_export
>
> or
>
> Paragraph\\
> @@latex:[foo]@@

But since in both cases it is literal LaTeX code, the correct thing
would be for the user to be in charge of adding the curly braces to the
square brackets. I mean in such scenario it is LaTeX code, not Org.

Anyway, in both examples it does not make sense for LaTeX to end a
paragraph with the \\ macro, which is why we commented in previous
messages in the thread. The \\ macro is only used in horizontal mode;
this macro does not add a new paragraph but rather a forced line break
within the paragraph.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 9%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-19 17:28 10%                       ` Juan Manuel Macías
@ 2024-01-20 12:34  5%                         ` Ihor Radchenko
  2024-01-20 13:22  9%                           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-20 12:34 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

>> \begin{itemize}
>> \item {[}bax]
>> \item {[}aur]
>> \end{itemize}
>
> Great! Simple and effective. And more surgical than pandoc's global
> solution. But now a question arises... Your code clearly solves the
> problem that led to the declaration of org-latex-line-break-safe,
> without foreseeing any unwanted effects, since it is the solution that
> is usually recommended from LaTeX. So, if this code is included in Org,
> what is the future of org-latex-line-break-safe?

It is still useful in situations like

Paragraph\\
#+begin_export latex
[foo]
#+end_export

or

Paragraph\\
@@latex:[foo]@@

My patch does not do anything about verbatim environments.

We may remove the use of `org-latex-line-break-safe' from some places,
but not all.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-13 15:08  6% ` Ihor Radchenko
  2024-01-13 16:05 10%   ` Juan Manuel Macías
@ 2024-01-20 10:27  3%   ` Max Nikulin
  1 sibling, 0 replies; 200+ results
From: Max Nikulin @ 2024-01-20 10:27 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

On 13/01/2024 22:08, Ihor Radchenko wrote:
> Juan Manuel Macías writes:
> 
>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem?

I would suggest to strip leading and trailing newlines before processing 
of the block content.

> In such scenario, we may technically violate what users ask us to do:
> 
> #+begin_verse
> I really want newline here\\
> #+end_verse

I really want newline here@@latex:\\%@@

P.S. Juan Manuel, I have sent another message to this thread without 
your address in Cc.


^ permalink raw reply	[relevance 3%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  @ 2024-01-20 10:57 10%                         ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-20 10:57 UTC (permalink / raw)
  To: Max Nikulin; +Cc: Ihor Radchenko, orgmode

Max Nikulin writes:

> On 18/01/2024 20:05, Ihor Radchenko wrote:
>> With the patch, I am getting the following:[...]
>> \begin{center}
>> \begin{tabular}{lr}
>> {[}foo] & 2\\[0pt]
>> {[}bar] & 3\\[0pt]
>> \end{tabular}
>> \end{center}
>
> It means that [0pt] is not necessary any more. However users will have
> adjust their filters once more. I have no idea if many of them will
> complain concerning {[} where it is not really required.
> (/[omitted]/).
>
> To have an additional excuse, it is better to add a note that it is
> inspired by pandoc strategy.

I agree with the note. Perhaps both strategies could coexist: by
default, Ihor's code; and org-latex-line-break-safe with value "\\\\".
And, after some time, the latter could become obsolete, unless a new
''raison d'etre'' is found for it...

In any case, I would no longer see it necessary to modify
org-latex-verse-block anymore.

Best regards,

Juan Manuel 



^ permalink raw reply	[relevance 10%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-18 13:05  4%                     ` Ihor Radchenko
@ 2024-01-19 17:28 10%                       ` Juan Manuel Macías
  2024-01-20 12:34  5%                         ` Ihor Radchenko
    1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-19 17:28 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:

> This turned out to be a lot easier than I thought.
> See the attached patch.
>
>>> \command
>>> [unrelated text]
>>>
>>> If there are, we may actually want to consider pandoc's approach
>>> seriously.
>>
>> In principle, any environment that takes an optional argument in a
>> "dangerous" position. Just do a simple test. Something like this:
>>
>> #+begin_figure
>> [lorem] ipsum
>> #+end_figure
>>
>> will throw an error like ''LaTeX Error: Unknown float option...''
>>
>> Of course, putting an empty line after #+begin... usually solves it. But
>> the user may not know it.
>>
>> There are also a number of commands with an optional argument. For
>> example \pagebreak. Something like this will give an error:
>>
>> lorem @@latex:\pagebreak@@ [ipsum]
>>
>> \item is another typical example, but in this case org adds \relax.
>
> With the patch, I am getting the following:
>
> * This is test
> lorem @@latex:\pagebreak@@ [ipsum]
>
> #+begin_figure
> [lorem] figure
> #+end_figure
>
> | [foo] | 2 |
> | [bar] | 3 |
>
> - [bax]
> - [aur]
>
> exports to
>
> lorem \pagebreak {[}ipsum]
>
> \begin{figure}
> {[}lorem] figure
> \end{figure}
>
> \begin{center}
> \begin{tabular}{lr}
> {[}foo] & 2\\[0pt]
> {[}bar] & 3\\[0pt]
> \end{tabular}
> \end{center}
>
> \begin{itemize}
> \item {[}bax]
> \item {[}aur]
> \end{itemize}

Great! Simple and effective. And more surgical than pandoc's global
solution. But now a question arises... Your code clearly solves the
problem that led to the declaration of org-latex-line-break-safe,
without foreseeing any unwanted effects, since it is the solution that
is usually recommended from LaTeX. So, if this code is included in Org,
what is the future of org-latex-line-break-safe?

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-17 17:50  7%                   ` Juan Manuel Macías
@ 2024-01-18 13:05  4%                     ` Ihor Radchenko
  2024-01-19 17:28 10%                       ` Juan Manuel Macías
    0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-18 13:05 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

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

>> As for {[}{]}, it is a bit difficult to implement. Especially when we
>> also consider user filters and derived backends. If we have several
>> transcoders of consequent elements, there is always a risk that even
>> when a given filter/transcoder is generating a valid LaTeX code,
>> concatenating them may still cause issues like we have with \\.
>
> I see. I think pandoc's solution is what Leslie Lamport recommends
> (naturally, Lamport doesn't say to enclose /all/ brackets in curly
> braces).

This turned out to be a lot easier than I thought.
See the attached patch.

>> \command
>> [unrelated text]
>>
>> If there are, we may actually want to consider pandoc's approach
>> seriously.
>
> In principle, any environment that takes an optional argument in a
> "dangerous" position. Just do a simple test. Something like this:
>
> #+begin_figure
> [lorem] ipsum
> #+end_figure
>
> will throw an error like ''LaTeX Error: Unknown float option...''
>
> Of course, putting an empty line after #+begin... usually solves it. But
> the user may not know it.
>
> There are also a number of commands with an optional argument. For
> example \pagebreak. Something like this will give an error:
>
> lorem @@latex:\pagebreak@@ [ipsum]
>
> \item is another typical example, but in this case org adds \relax.

With the patch, I am getting the following:

* This is test
lorem @@latex:\pagebreak@@ [ipsum]

#+begin_figure
[lorem] figure
#+end_figure

| [foo] | 2 |
| [bar] | 3 |

- [bax]
- [aur]

exports to

lorem \pagebreak {[}ipsum]

\begin{figure}
{[}lorem] figure
\end{figure}

\begin{center}
\begin{tabular}{lr}
{[}foo] & 2\\[0pt]
{[}bar] & 3\\[0pt]
\end{tabular}
\end{center}

\begin{itemize}
\item {[}bax]
\item {[}aur]
\end{itemize}


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-latex-Make-sure-that-text-is-not-misinterpreted-a.patch --]
[-- Type: text/x-patch, Size: 2511 bytes --]

From db3fa01d6f15b3d3f499f77e342a608a822029c8 Mon Sep 17 00:00:00 2001
Message-ID: <db3fa01d6f15b3d3f499f77e342a608a822029c8.1705583005.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH] ox-latex: Make sure that [text] is not misinterpreted as
 LaTeX argument

* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [.  It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.

Link: https://orgmode.org/list/87o7dju9vn.fsf@posteo.net
---
 lisp/ox-latex.el              |  9 +++++++++
 testing/lisp/test-ox-latex.el | 23 +++++++++++++++++++++++
 2 files changed, 32 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 432f09f4e..a3505c25f 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3094,6 +3094,15 @@ (defun org-latex-plain-text (text info)
 		    "\\(?:[ \t]*\\\\\\\\\\)?[ \t]*\n"
                     (concat org-latex-line-break-safe "\n")
                     output nil t)))
+    ;; Protect [foo] at the beginning of lines / beginning of the
+    ;; plain-text object.  This prevents LaTeX from unexpectedly
+    ;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+    ;; optional argument.
+    (setq output (replace-regexp-in-string
+                  (rx bol (0+ space) (group "["))
+                  "{[}"
+                  output
+                  nil nil 1))
     ;; Return value.
     output))
 
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
 
 \f
 
+(ert-deftest text-ox-latex/protect-square-brackets ()
+  "Test [foo] being interpreted as plain text even after LaTeX commands."
+  (org-test-with-exported-text
+      'latex
+      "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+    (goto-char (point-min))
+    (should (search-forward "lorem \\pagebreak {[}ipsum]"))
+    (should (search-forward "{[}lorem] figure"))
+    (should (search-forward "{[}foo]"))
+    (should (search-forward "\\item {[}bax]"))))
+
 (ert-deftest test-ox-latex/verse ()
   "Test verse blocks."
   (org-test-with-exported-text
-- 
2.43.0


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

^ permalink raw reply related	[relevance 4%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-17 13:00  4%                 ` Ihor Radchenko
@ 2024-01-17 17:50  7%                   ` Juan Manuel Macías
  2024-01-18 13:05  4%                     ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-17 17:50 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode, Max Nikulin

Ihor Radchenko writes:


> If the idea with custom command does not have obvious downsides, it
> might be a better option. In the previous thread, we only considered
> redefining \\ itself - obviously a non-starter for environments that
> re-define \\ by their own, like here.

I find several drawbacks to adding a new latex command like \nothing.
First, the standardization of the exported LaTeX code is lost. \\[0pt],
at least, always compiles. A new command obviously needs to be defined
first. Let's imagine that someone wants to simply share the LaTeX code
of a table... Then there is the problem of how to name the new command
so that it doesn't 'clash' with some user-defined command. In LaTeX it
is usually good practice to use the at sign character (@) in the name of
a command or macro that is not in user space, since this character can
only be used in a *.sty file. In a *.tex file, if you want to use the at
sign to define or redefine something, you have to enclose the code
between \makeatletter...\makeatother. And, in any case, I think that the
LaTeX code produced by org should be as 'universal' as possible (standard
LaTeX code + packages included in TeX live), and leave the definition of
new commands or environments to the user's discretion.

On the other hand, we are not sure that a command like \nothing does not
have some undesirable effect. I seem to remember that in the
aforementioned thread, adding \relax (the typical command that is used
to tell LaTeX do nothing) was also proposed as a solution, and it was
discarded for some reason.

>> In any case, square brackets are a problematic character in LaTeX
>> (think, e.g., of some environment that takes an optional argument). I
>> think pandoc chooses to always export them as {[}{]}:
>>
>> #+begin_src sh :results latex
>> str="[hello world] [foo] [bar]"
>> pandoc -f org -t latex <<< $str
>> #+end_src
>>
>> #+RESULTS:
>> #+begin_export latex
>> {[}hello world{]} {[}foo{]} {[}bar{]}
>> #+end_export
>>
>> We could do the same, but I'm afraid it's too late if
>> org-latex-line-break-safe already exists... I don't remember if
>> something similar was proposed in that discussion, and it was rejected
>> for some reason.
>
> It is not too late.
>
> AFAIR, we just decided not to dig deeper about pandoc's approach.
>
> As for {[}{]}, it is a bit difficult to implement. Especially when we
> also consider user filters and derived backends. If we have several
> transcoders of consequent elements, there is always a risk that even
> when a given filter/transcoder is generating a valid LaTeX code,
> concatenating them may still cause issues like we have with \\.

I see. I think pandoc's solution is what Leslie Lamport recommends
(naturally, Lamport doesn't say to enclose /all/ brackets in curly
braces).

> I am wondering if there are other examples of commands with optional
> arguments that may cause a similar problem with
>
> \command
> [unrelated text]
>
> If there are, we may actually want to consider pandoc's approach
> seriously.

In principle, any environment that takes an optional argument in a
"dangerous" position. Just do a simple test. Something like this:

#+begin_figure
[lorem] ipsum
#+end_figure

will throw an error like ''LaTeX Error: Unknown float option...''

Of course, putting an empty line after #+begin... usually solves it. But
the user may not know it.

There are also a number of commands with an optional argument. For
example \pagebreak. Something like this will give an error:

lorem @@latex:\pagebreak@@ [ipsum]

\item is another typical example, but in this case org adds \relax.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 7%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-16 19:33  8%               ` Juan Manuel Macías
@ 2024-01-17 13:00  4%                 ` Ihor Radchenko
  2024-01-17 17:50  7%                   ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-17 13:00 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode, Max Nikulin

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

>> May it be better to use something like
>>
>> \newcommand\nothing{}
>> \newcommand{\safenewline}{\\\nothing}
>>
>> And then use \safenewline instead of \\[0pt]
>>
>> In my tests,
>>
>> \begin{center}
>> \begin{tabular}{ll}
>> [t] & s\safenewline
>> [I] & A\safenewline
>> [m] & kg\safenewline
>> \end{tabular}
>> \end{center}
>>
>> Does not suffer from misinterpreting new line as argument.
>
> I remember the thread where these issues were discussed and the long
> discussion where many alternatives were proposed. After all, the \\[0pt]
> solution still seems the safest to me. It seems that the problem is
> located only in the verse environment, probably due to some particular
> redefinition of the \\ macro that makes that environment.

We chose \\[0pt] simply because we did not find anything better.
In fact, Max expressed some concerns about \\[0pt] - in
https://list.orgmode.org/orgmode/tik0uf$td1$1@ciao.gmane.io/ and
https://list.orgmode.org/orgmode/tio0th$vn8$1@ciao.gmane.io/

If the idea with custom command does not have obvious downsides, it
might be a better option. In the previous thread, we only considered
redefining \\ itself - obviously a non-starter for environments that
re-define \\ by their own, like here.

> In any case, square brackets are a problematic character in LaTeX
> (think, e.g., of some environment that takes an optional argument). I
> think pandoc chooses to always export them as {[}{]}:
>
> #+begin_src sh :results latex
> str="[hello world] [foo] [bar]"
> pandoc -f org -t latex <<< $str
> #+end_src
>
> #+RESULTS:
> #+begin_export latex
> {[}hello world{]} {[}foo{]} {[}bar{]}
> #+end_export
>
> We could do the same, but I'm afraid it's too late if
> org-latex-line-break-safe already exists... I don't remember if
> something similar was proposed in that discussion, and it was rejected
> for some reason.

It is not too late.

AFAIR, we just decided not to dig deeper about pandoc's approach.

As for {[}{]}, it is a bit difficult to implement. Especially when we
also consider user filters and derived backends. If we have several
transcoders of consequent elements, there is always a risk that even
when a given filter/transcoder is generating a valid LaTeX code,
concatenating them may still cause issues like we have with \\.

I am wondering if there are other examples of commands with optional
arguments that may cause a similar problem with

\command
[unrelated text]

If there are, we may actually want to consider pandoc's approach
seriously.

>> We may as well strip the trailing \\[0pt] there.
>
> I think it would be best to remove the last \\[0pt] in the verse block.
> I can prepare a patch, but I'm afraid that org-latex-verse-block is
> becoming an homage to replace-regexp-in-string...

Not a big deal. Or, if you want, you can make changes via temporary
buffer; if that is cleaner.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 4%]

* Re: #+LATEX_HEADER: \usepackage[greek,german]{babel} ??
  @ 2024-01-16 19:46 10%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:46 UTC (permalink / raw)
  To: Horst Leps; +Cc: emacs-orgmode@gnu.org

Horst Leps writes:

> % Created 2024-01-16 Tue 20:00
> % Intended LaTeX compiler: pdflatex
> \documentclass{scrartcl}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{grffile}
> \usepackage{longtable}
> \usepackage{wrapfig}
> \usepackage{rotating}
> \usepackage[normalem]{ulem}
> \usepackage{amsmath}
> \usepackage{textcomp}
> \usepackage{amssymb}
> \usepackage{capt-of}
> \usepackage{hyperref}
> \usepackage[germanb]{babel}
> \usepackage[utf8]{inputenc}
> \usepackage[LGR,T1]{fontenc}
> \usepackage[greek,german]{babel}
> \author{HL}

The document loads babel twice:

\usepackage[germanb]{babel} <==
\usepackage[utf8]{inputenc}
\usepackage[LGR,T1]{fontenc}
\usepackage[greek,german]{babel} <==

Hence the 'option class for package babel' error. You have loaded babel
in your org document with the [greek,german] option and (probably, in
the class you are loading) babel is already loaded as well.

Try:

#+LaTeX_Header: \PassOptionsToPackage{greek,german}{babel}

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-16 14:09  4%             ` Ihor Radchenko
@ 2024-01-16 19:33  8%               ` Juan Manuel Macías
  2024-01-17 13:00  4%                 ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-16 19:33 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> The very reason we use \\[0pt] is because it supposed to prevent
> interpreting [...] at the new line/transcoded element as argument.
>
> You demonstrated that it is yet not always safe enough.
>
> May it be better to use something like
>
> \newcommand\nothing{}
> \newcommand{\safenewline}{\\\nothing}
>
> And then use \safenewline instead of \\[0pt]
>
> In my tests,
>
> \begin{center}
> \begin{tabular}{ll}
> [t] & s\safenewline
> [I] & A\safenewline
> [m] & kg\safenewline
> \end{tabular}
> \end{center}
>
> Does not suffer from misinterpreting new line as argument.

I remember the thread where these issues were discussed and the long
discussion where many alternatives were proposed. After all, the \\[0pt]
solution still seems the safest to me. It seems that the problem is
located only in the verse environment, probably due to some particular
redefinition of the \\ macro that makes that environment.

In any case, square brackets are a problematic character in LaTeX
(think, e.g., of some environment that takes an optional argument). I
think pandoc chooses to always export them as {[}{]}:

#+begin_src sh :results latex
str="[hello world] [foo] [bar]"
pandoc -f org -t latex <<< $str
#+end_src

#+RESULTS:
#+begin_export latex
{[}hello world{]} {[}foo{]} {[}bar{]}
#+end_export

We could do the same, but I'm afraid it's too late if
org-latex-line-break-safe already exists... I don't remember if
something similar was proposed in that discussion, and it was rejected
for some reason.

> `org-latex-verse-block' already has a giant regexp replacement:
>
>       ;; In a verse environment, add a line break to each newline
>       ;; character and change each white space at beginning of a line
>       ;; into a normal space, calculated with `\fontdimen2\font'.  One
>       ;; or more blank lines between lines are exported as a single
>       ;; blank line.  If the `:lines' attribute is used, the last
>       ;; verse of each stanza ends with the string `\\!', according to
>       ;; the syntax of the `verse' package. The separation between
>       ;; stanzas can be controlled with the length `\stanzaskip', of
>       ;; the aforementioned package.  If the `:literal' attribute is
>       ;; used, all blank lines are preserved and exported as
>       ;; `\vspace*{\baselineskip}', including the blank lines before
>       ;; or after CONTENTS.
>
> We may as well strip the trailing \\[0pt] there.

I think it would be best to remove the last \\[0pt] in the verse block.
I can prepare a patch, but I'm afraid that org-latex-verse-block is
becoming an homage to replace-regexp-in-string...

Best regards,

Juan Manuel 




^ permalink raw reply	[relevance 8%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-14 21:58  7%           ` Juan Manuel Macías
@ 2024-01-16 14:09  4%             ` Ihor Radchenko
  2024-01-16 19:33  8%               ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-16 14:09 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>>> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
>>> that is, within a paragraph. At the end of an environment like verse
>>> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
>>> starts.
>>
>> Is it true for any environment? Or just some?
>
> In principle, nothing prevents one from defining an environment for use
> in horizontal mode (within the paragraph). E.g.:
> ...
> But the usual thing is that the beginning/end of an environment changes to
> vertical mode, with \par or something more elaborate.

This is annoying.
ox-latex has some transcoders that unconditionally add \\ at the
end: clocks and planning lines. If they happen to be at the end of an
environment, it can be problematic.

> hmm... I don't know if this should be considered a bug. We may think
> that \\[0pt] should never do anything, but we must keep in mind that the
> end of the verse environment is the end of a paragraph, and it changes
> to vertical mode. And the end of a paragraph is an illogical place to
> put that command. But it seems that it also alters things when it is at
> that point. Check out this reply from David Carlisle
> (https://tex.stackexchange.com/a/82666):

The very reason we use \\[0pt] is because it supposed to prevent
interpreting [...] at the new line/transcoded element as argument.

You demonstrated that it is yet not always safe enough.

May it be better to use something like

\newcommand\nothing{}
\newcommand{\safenewline}{\\\nothing}

And then use \safenewline instead of \\[0pt]

In my tests,

\begin{center}
\begin{tabular}{ll}
[t] & s\safenewline
[I] & A\safenewline
[m] & kg\safenewline
\end{tabular}
\end{center}

Does not suffer from misinterpreting new line as argument.

> If there are environments that redefine \\, such as verse or tabular,
> probably putting the optional argument of \\ with a value of 0pt at the
> end of verse alters the calculation of the normal space after the
> environment, making it shorter. I think that here we would not have a
> LaTeX bug, because the syntax of the verse environment itself says that
> the last line should not carry any \\ mark. 

AFAIU, \safenewline should still use re-defined version of \\ according
to the context.

> At the end of the tables I have not noticed any side effects. But in the
> export of the verse block, I would be in favor of somehow eliminating
> that last \\[0pt].

`org-latex-verse-block' already has a giant regexp replacement:

      ;; In a verse environment, add a line break to each newline
      ;; character and change each white space at beginning of a line
      ;; into a normal space, calculated with `\fontdimen2\font'.  One
      ;; or more blank lines between lines are exported as a single
      ;; blank line.  If the `:lines' attribute is used, the last
      ;; verse of each stanza ends with the string `\\!', according to
      ;; the syntax of the `verse' package. The separation between
      ;; stanzas can be controlled with the length `\stanzaskip', of
      ;; the aforementioned package.  If the `:literal' attribute is
      ;; used, all blank lines are preserved and exported as
      ;; `\vspace*{\baselineskip}', including the blank lines before
      ;; or after CONTENTS.

We may as well strip the trailing \\[0pt] there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 4%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-14 12:33  6%         ` Ihor Radchenko
@ 2024-01-14 21:58  7%           ` Juan Manuel Macías
  2024-01-16 14:09  4%             ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-14 21:58 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
>> that is, within a paragraph. At the end of an environment like verse
>> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
>> starts.
>
> Is it true for any environment? Or just some?

In principle, nothing prevents one from defining an environment for use
in horizontal mode (within the paragraph). E.g.:

\newenvironment{foo}{\itshape}{}

Lorem \begin{foo}ipsum\end{foo} dolor.

But the usual thing is that the beginning/end of an environment changes to
vertical mode, with \par or something more elaborate.


>> Therefore, I think that whether or not a verse environment ends with \\ is
>> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
>> some reason that escapes me, the space after the environment is altered.
>
> I see. Although, I am not 100% if it is something we have to deal with
> in Org mode. May it be better to report this as a bug to LaTeX devs?

hmm... I don't know if this should be considered a bug. We may think
that \\[0pt] should never do anything, but we must keep in mind that the
end of the verse environment is the end of a paragraph, and it changes
to vertical mode. And the end of a paragraph is an illogical place to
put that command. But it seems that it also alters things when it is at
that point. Check out this reply from David Carlisle
(https://tex.stackexchange.com/a/82666):

#+begin_quote
\\ at the end of a paragraph causes bad output with an empty, maximally under-full, box,
and so you get a warning about badness 10000, the visual effect looks a bit like extra
vertical space but it is not: it is an extra spurious line at the end of the paragraph,
and for example it is not dropped at a page break and will break widow/club line
calculations.
#+end_quote

If there are environments that redefine \\, such as verse or tabular,
probably putting the optional argument of \\ with a value of 0pt at the
end of verse alters the calculation of the normal space after the
environment, making it shorter. I think that here we would not have a
LaTeX bug, because the syntax of the verse environment itself says that
the last line should not carry any \\ mark. 

At the end of the tables I have not noticed any side effects. But in the
export of the verse block, I would be in favor of somehow eliminating
that last \\[0pt].

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 7%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-13 20:22  8%       ` Juan Manuel Macías
@ 2024-01-14 12:33  6%         ` Ihor Radchenko
  2024-01-14 21:58  7%           ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-14 12:33 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
> that is, within a paragraph. At the end of an environment like verse
> (\end{verse}) you are forced to enter vertical mode, and a new paragraph
> starts.

Is it true for any environment? Or just some?

> Therefore, I think that whether or not a verse environment ends with \\ is
> irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
> some reason that escapes me, the space after the environment is altered.

I see. Although, I am not 100% if it is something we have to deal with
in Org mode. May it be better to report this as a bug to LaTeX devs?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-13 18:28  5%     ` Ihor Radchenko
@ 2024-01-13 20:22  8%       ` Juan Manuel Macías
  2024-01-14 12:33  6%         ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 20:22 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> In such scenario, we may technically violate what users ask us to do:
>>>
>>> #+begin_verse
>>> I really want newline here\\
>>> #+end_verse
>>
>> I'm not sure if users asked for that specifically.
>> ...
>> This does not:
>>
>>  #+begin_verse
>>  I really want newline here\\
>>  #+end_verse
>
> I am not sure.
> What about
>
> #+begin_verse
> I really want newline here\\
> #+end_verse
>
> This must not be indented.

If I'm not mistaken, in TeX '\\' can only be used in horizontal mode:
that is, within a paragraph. At the end of an environment like verse
(\end{verse}) you are forced to enter vertical mode, and a new paragraph
starts. Doing something like this, for example, adds a new paragraph
after the environment:

\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}
\lipsum[1]
\end{document}

Even this one produces the same result:

\documentclass{article}
\usepackage{lipsum}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}\lipsum[1]
\end{document}

If one wants, for example, that after a verse environment there is no
vertical space or indentation, the only way to do it is by modifying, globally or
locally (with another environment) the space after the environment and
adding a \noindent to the following paragraph:

\documentclass{article}
\usepackage{lipsum}
\setlength\partopsep{-\topsep}\addtolength\partopsep{0pt}
\begin{document}
\begin{verse}
  Lorem ipsum dolor\\
\end{verse}
\noindent\lipsum[1]
\end{document}

(taking into account that within the verse environment there is also a
left indentation that would also have to be modified).

Therefore, I think that whether or not a verse environment ends with \\ is
irrelevant to LaTeX. The problem is that when it ends with \\[0pt], for
some reason that escapes me, the space after the environment is altered.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 8%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-13 16:05 10%   ` Juan Manuel Macías
@ 2024-01-13 18:28  5%     ` Ihor Radchenko
  2024-01-13 20:22  8%       ` Juan Manuel Macías
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2024-01-13 18:28 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

>> In such scenario, we may technically violate what users ask us to do:
>>
>> #+begin_verse
>> I really want newline here\\
>> #+end_verse
>
> I'm not sure if users asked for that specifically.
> ...
> This does not:
>
>  #+begin_verse
>  I really want newline here\\
>  #+end_verse

I am not sure.
What about

#+begin_verse
I really want newline here\\
#+end_verse
This must not be indented.

(Just trying to come up with valid uses of newline at the end of
LaTeX environment)

Although, the above causes Org export to fail...
\begin{verse}
This is test\\[0pt]\\[0pt]
\end{verse}
Paragraph.


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 5%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-13 15:08  6% ` Ihor Radchenko
@ 2024-01-13 16:05 10%   ` Juan Manuel Macías
  2024-01-13 18:28  5%     ` Ihor Radchenko
  2024-01-20 10:27  3%   ` Max Nikulin
  1 sibling, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-13 16:05 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Ihor Radchenko writes:

>> Can anyone think of a possible scenario where removing the '\\[0pt]' in
>> the last line would cause a problem? If not, I might send a patch in the
>> next few days. (I'm afraid that going back to abusing
>> replace-regexp-in-string. I can't think of any other more elegant
>> solution...).
>
> In such scenario, we may technically violate what users ask us to do:
>
> #+begin_verse
> I really want newline here\\
> #+end_verse

I'm not sure if users asked for that specifically.

You want a new line when there is a new line.

This makes sense:

 #+begin_verse
 I really want newline here\\
 blah...
 #+end_verse

This does not:

 #+begin_verse
 I really want newline here\\
 #+end_verse

For LaTeX it is the same as this:

 #+begin_verse
 I really want newline here
 #+end_verse

But this specifically alters the expected result in LaTeX, modifying the
space after the environment:

 #+begin_verse
 I really want newline here\\[0pt]
 #+end_verse

What is the cause? I don't know. But it happens.

Best regards,

Juan Manuel 


^ permalink raw reply	[relevance 10%]

* Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
  2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
@ 2024-01-13 15:08  6% ` Ihor Radchenko
  2024-01-13 16:05 10%   ` Juan Manuel Macías
  2024-01-20 10:27  3%   ` Max Nikulin
  0 siblings, 2 replies; 200+ results
From: Ihor Radchenko @ 2024-01-13 15:08 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: orgmode

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

> Can anyone think of a possible scenario where removing the '\\[0pt]' in
> the last line would cause a problem? If not, I might send a patch in the
> next few days. (I'm afraid that going back to abusing
> replace-regexp-in-string. I can't think of any other more elegant
> solution...).

In such scenario, we may technically violate what users ask us to do:

#+begin_verse
I really want newline here\\
#+end_verse

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* Re: org-attach-git don't automatically commit changes
  @ 2024-01-10 16:05  6%                 ` Ihor Radchenko
  0 siblings, 0 replies; 200+ results
From: Ihor Radchenko @ 2024-01-10 16:05 UTC (permalink / raw)
  To: Juan Manuel Macías; +Cc: Ihor Radchenko, orgmode

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

>> In any case, if you provide a patch, it will encourage the org
>> maintainers to join this discussion and proceed with changes.
>
> OK, this week I will try to propose a patch here, and bring it up for
> (possible) discussion. Thanks for the suggestions.

For the record, this appears to be fixed in df9b509a6.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 6%]

* [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export
@ 2024-01-02 23:46 11% Juan Manuel Macías
  2024-01-13 15:08  6% ` Ihor Radchenko
  0 siblings, 1 reply; 200+ results
From: Juan Manuel Macías @ 2024-01-02 23:46 UTC (permalink / raw)
  To: orgmode

Hi,

I recently discovered that if the last line of a LaTeX 'verse'
environment ends in '\\[0pt]', the space after the environment is
drastically altered. The space after a 'verse' environment (which is a
modified list environment) must be equivalent to
\partopsep+\topsep+\baselineskip. I have done the test with a document,
defining a rectangle of that height with tikz, where you can see the
difference in vertical space with and without '\\[0pt]':

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

Naturally, this implies an issue when exporting the verse block to
LaTeX, since the presence of the '\\[0pt]' string alters the expected
result in the compiled PDF. My suggestion is that the last line of the
verse block is not exported with either the string '[0pt]' or the line
break mark '\\', since it makes no sense for that mark to be there: it
is the end of a paragraph and the very end of the environment.

Can anyone think of a possible scenario where removing the '\\[0pt]' in
the last line would cause a problem? If not, I might send a patch in the
next few days. (I'm afraid that going back to abusing
replace-regexp-in-string. I can't think of any other more elegant
solution...).

Best regards,

Juan Manuel 


-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño editorial y ortotipografía



^ permalink raw reply	[relevance 11%]

* Re: Are 'placement' and 'float' "obsolete terms" in inline images export
  @ 2024-01-02 21:43 11%       ` Juan Manuel Macías
  0 siblings, 0 replies; 200+ results
From: Juan Manuel Macías @ 2024-01-02 21:43 UTC (permalink / raw)
  To: Ihor Radchenko; +Cc: orgmode

Apologies for my delay in answering all the interesting questions
you raised in this last message. November and December have been
horrible work days for me (all publishers are always in a hurry) and I
haven't been able to attend to the mailing list as I would like...

Ihor Radchenko writes:

> Juan Manuel Macías <maciaschain@posteo.net> writes:
>
>>> What about :wrap?
>>
>> I like :wrap. What's more, remembering that old thread where
>> some questions about code before/after the image were discussed,
>> what if the expected value of :wrap were a kind of template? This would
>> allow code to be placed before and/or after (not just an environment)
>> the image, always within the float environment, if it exists. Something
>> like this:
>>
>> #+ATTR_LaTeX: :float nil :wrap \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage} 
>> #+CAPTION: caption
>> [[file:foo.png]]
>> ...
>> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption \captionof{figure}{caption} 
>> [[file:foo.png]]
>>
>> I don't know if it would be appropriate to explain in the Manual that
>> doing so would not be... "correct"? I don't know if there is any term in
>> programming to designate these situations which, without being bugs, are
>> functionalities not consciously sought...
>
> What about making :wrap override :float completely + obsoleting :float.
> We can allow wrap to have special values like in float:
>
> :wrap t/:wrap multicolumn/:wrap sideways
>
> With these special values, :placement will be taken into account.

+1. Great idea.

> Further, we can make templates a bit more detailed.
> Starting from similar to what you proposed in the above
>
> :wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}
>
> to more granular control over caption, centering, comment-include,
> and image-code:
>
> %{caption} %{caption-text} %{centering} %{comment} %{comment-text}
>  %{image} %{image-path}.
>
> If the :wrap text does not contain %{...} placeholder, it will be
> treated as what  :float artbirary-environment does.
>
> We may even consider something like
>
> #+name: latex-template
> #+begin_src latex :export none
>
> \begin{minipage}[b]{10pc}\small
> %{body}
> \end{minipage}
> #+end_src
>
> #+attr_latex: :wrap latex-template[]
>
> As a bonus, :wrap may allow prepending/appending arbitrary code to
> headings:
>
> * Heading starting at a new page
> :PROPERTIES:
> :ATTR_LATEX: :wrap \clarpage%{default}
> :END:

I really like what you propose, both the idea and the syntax. I think
that such a versatile template system (with such a level of granularity
but with a clear syntax at the same time) would be a killer feature. It
wouldn't be bad to also extend it to the case of tables and other
backends, such as html. I also think it would solve a "classic" Org
syntax issue (in my opinion) which is the difficulty in 'nesting things'.
Well, it can be done currently (for example, the special blocks do their job
pretty  well), but at the cost of increasing the verbosity of the code (I am
thinking, for example, of using the LaTeX threeparttable package through
nested special blocks...)

Best regards, and  happy New Year

-- 
Juan Manuel Macías



^ permalink raw reply	[relevance 11%]

* Re: Links & images with different attributes in the same paragraph
  2023-12-16 14:44  0%             ` Ihor Radchenko
@ 2023-12-19 14:39  0%               ` Max Nikulin
  0 siblings, 0 replies; 200+ results
From: Max Nikulin @ 2023-12-19 14:39 UTC (permalink / raw)
  To: emacs-orgmode

On 16/12/2023 21:44, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>>
>> Are you assuming invisible zero-width space as a way to escape literal
>> {{ or }}? I would prefer some visible characters.
> 
> No, not zero-width space. Literally, {{...}}. The idea is to define
> delimiters as "[{]+" the matching number of "}". This way, we do not
> need to worry about escaping "}" inside and can get nested markup for
> free. It is more or less how Org parser works for special block:
> the opening delimiter is #+begin_whatever is matched against
> #+end_<same as opening delimiter>.

I am afraid, there is an issue if wrapped content is surrounded by 
braces. An ambiguity arises for

     @wrap{{{content}}}

it may be @wrap{{{ content }}}, @wrap{{ {content} }},
or @wrap{ {{content}} }. It seems, some escape character is unavoidable.

> Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
> with my original proposal and some discussion that followed up.

I completely forgot that you wrote about balanced parenthesis earlier.

>> Juan Manuel Macías. Re: About 'inline special blocks'
>>> Bringing that into the paragraph is
>>> unnecessarily overloading the paragraph and breaking the social contract
>>> of lightweight markup, where paragraphs should still look like
>>> paragraphs.

> I am pretty sure that I replied to that concern raised in a parallel
> thread. My idea was to allow macro replacement inside attributes:
> 
> #+macro: alt #+attr_html :alt $1
> What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}

Certainly it allows to shorten in-text arguments. Just as noweb 
references, it has some disadvantages. I consider comma as macro 
argument separator as a kind of a pitfall. Macro definitions, unlike 
code blocks definitions for noweb references, can not be multiline
(unless defined in elisp code).

Unless something better will be proposed, I consider macro expansion 
inside arguments as a viable approach. (I can not recall if it was 
discussed earlier.)



^ permalink raw reply	[relevance 0%]

* Re: Links & images with different attributes in the same paragraph
  @ 2023-12-16 14:44  0%             ` Ihor Radchenko
  2023-12-19 14:39  0%               ` Max Nikulin
  0 siblings, 1 reply; 200+ results
From: Ihor Radchenko @ 2023-12-16 14:44 UTC (permalink / raw)
  To: Max Nikulin; +Cc: emacs-orgmode

Max Nikulin <manikulin@gmail.com> writes:

>> @wrap{{outer wrap; @wrap{{inner wrap allowing } as well}}; back}}.
>
> Are you assuming invisible zero-width space as a way to escape literal 
> {{ or }}? I would prefer some visible characters.

No, not zero-width space. Literally, {{...}}. The idea is to define
delimiters as "[{]+" the matching number of "}". This way, we do not
need to worry about escaping "}" inside and can get nested markup for
free. It is more or less how Org parser works for special block:
the opening delimiter is #+begin_whatever is matched against
#+end_<same as opening delimiter>.

Also, see https://list.orgmode.org/orgmode/87mtaez8do.fsf@localhost/
with my original proposal and some discussion that followed up.

>> What about @wrap[#+attr_html: :alt "Text"]{[[/path/to/image]]}?
>
> Leaving aside precise syntax (that perhaps should be discussed in 
> another thread), it solves the issue.
>
> Do you have any idea how to address the following complain?
>
> https://list.orgmode.org/orgmode/875ykwvmz7.fsf@posteo.net
> Juan Manuel Macías. Re: About 'inline special blocks' Sun, 19 Jun 2022 
> 12:47:40 +0000
>> Bringing that into the paragraph is
>> unnecessarily overloading the paragraph and breaking the social contract
>> of lightweight markup, where paragraphs should still look like
>> paragraphs.
>
> I consider it as a valid point, so I tried to take advantage of noweb 
> features. I am in doubts concerning *evaluation* of expressions in 
> addition to just substitutions. It allows to implement another kind of 
> #+link: macro, but it gives too much power to my taste.

I am pretty sure that I replied to that concern raised in a parallel
thread. My idea was to allow macro replacement inside attributes:

#+macro: alt #+attr_html :alt $1
What about @wrap[<<<alt(Text)>>>]{[[/path/to/image]]}

Or even inline definition like

#+@macro: alt @wrap[@+attr_html :alt $1]
What about @alt[Text]{[[/path/to/image]]}

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


^ permalink raw reply	[relevance 0%]

Results 1-200 of ~1600   | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2021-01-29 16:03     org-attach-git don't automatically commit changes Juan Manuel Macías
2021-01-30  5:10     ` Ihor Radchenko
2021-01-30 13:38       ` Juan Manuel Macías
2021-01-31  3:33         ` Ihor Radchenko
2021-01-31 10:29           ` Juan Manuel Macías
2021-01-31 10:52             ` Ihor Radchenko
2021-01-31 13:16               ` Juan Manuel Macías
2021-01-31 13:40                 ` Ihor Radchenko
2021-01-31 14:36                   ` Juan Manuel Macías
2024-01-10 16:05  6%                 ` Ihor Radchenko
2023-02-18 10:18     [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated Ihor Radchenko
2023-03-05 11:12     ` Max Nikulin
2024-01-20 16:04  0%   ` Ihor Radchenko
2024-01-24 13:21  0%   ` Ihor Radchenko
2023-10-22 21:12     Are 'placement' and 'float' "obsolete terms" in inline images export Juan Manuel Macías
2023-10-23  9:27     ` Ihor Radchenko
2023-10-23 19:00       ` Juan Manuel Macías
2023-10-26  9:14         ` Ihor Radchenko
2024-01-02 21:43 11%       ` Juan Manuel Macías
2023-11-11 15:54     Links & images with different attributes in the same paragraph Max Nikulin
2023-12-05 13:46     ` Ihor Radchenko
2023-12-12 11:08       ` Max Nikulin
2023-12-12 13:18         ` Ihor Radchenko
2023-12-13 11:50           ` Max Nikulin
2023-12-14 15:23             ` Ihor Radchenko
2023-12-16  8:06               ` Max Nikulin
2023-12-16 14:44  0%             ` Ihor Radchenko
2023-12-19 14:39  0%               ` Max Nikulin
2024-01-02 23:46 11% [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export Juan Manuel Macías
2024-01-13 15:08  6% ` Ihor Radchenko
2024-01-13 16:05 10%   ` Juan Manuel Macías
2024-01-13 18:28  5%     ` Ihor Radchenko
2024-01-13 20:22  8%       ` Juan Manuel Macías
2024-01-14 12:33  6%         ` Ihor Radchenko
2024-01-14 21:58  7%           ` Juan Manuel Macías
2024-01-16 14:09  4%             ` Ihor Radchenko
2024-01-16 19:33  8%               ` Juan Manuel Macías
2024-01-17 13:00  4%                 ` Ihor Radchenko
2024-01-17 17:50  7%                   ` Juan Manuel Macías
2024-01-18 13:05  4%                     ` Ihor Radchenko
2024-01-19 17:28 10%                       ` Juan Manuel Macías
2024-01-20 12:34  5%                         ` Ihor Radchenko
2024-01-20 13:22  9%                           ` Juan Manuel Macías
2024-01-20 13:46  5%                             ` Ihor Radchenko
2024-01-20 15:41  9%                               ` Juan Manuel Macías
2024-01-20 18:47  5%                                 ` Ihor Radchenko
2024-01-20 20:27  8%                                   ` Juan Manuel Macías
2024-01-21 13:42  1%                                     ` Ihor Radchenko
2024-01-21 19:25  9%                                       ` Juan Manuel Macías
2024-01-21  6:06  3%                                   ` Max Nikulin
2024-01-20 10:09                           ` Max Nikulin
2024-01-20 10:57 10%                         ` Juan Manuel Macías
2024-01-20 10:27  3%   ` Max Nikulin
2024-01-12 10:24     Tableofcontents Horst Leps
2024-01-12 16:53     ` Tableofcontents Tory S. Anderson
2024-01-13 12:27       ` Tableofcontents Ihor Radchenko
2024-01-16 19:12         ` #+LATEX_HEADER: \usepackage[greek,german]{babel} ?? Horst Leps
2024-01-16 19:46 10%       ` Juan Manuel Macías
2024-01-21  8:44     New try at multi-lingual export to latex/pdf using pdflatex and babel Pedro Andres Aranda Gutierrez
2024-01-21 13:02     ` Ihor Radchenko
2024-01-21 17:11       ` Pedro Andres Aranda Gutierrez
2024-01-21 17:47  9%     ` Juan Manuel Macías
2024-01-22  6:30  6%       ` Pedro Andres Aranda Gutierrez
2024-01-22  6:47  0%         ` Pedro Andres Aranda Gutierrez
2024-01-22 13:11  8%           ` Juan Manuel Macías
2024-01-22 12:10  6%       ` Ihor Radchenko
2024-01-22 13:40  8%         ` Juan Manuel Macías
2024-01-23  7:41  3%           ` Pedro Andres Aranda Gutierrez
2024-02-09 23:10         ` Ihor Radchenko
2024-02-10  6:13           ` Pedro Andres Aranda Gutierrez
2024-02-10 14:39             ` Ihor Radchenko
2024-02-11  6:22               ` Pedro Andres Aranda Gutierrez
2024-02-11 11:04 12%             ` Juan Manuel Macías
2024-01-22 20:42     Possible LaTeX export bug: Footnotes in items Eric Anderson
2024-01-24 12:11     ` [BUG] Footnotes in section titles Ihor Radchenko
2024-01-24 14:14       ` Max Nikulin
2024-01-24 15:23 12%     ` Juan Manuel Macías
2024-01-24 15:31  0%       ` Colin Baxter
2024-01-24 15:41  9%         ` Juan Manuel Macías
2024-01-26 12:53  5%           ` Ihor Radchenko
2024-01-26 13:17 11%             ` Juan Manuel Macías
2024-01-26 16:43                 ` Max Nikulin
2024-02-01 14:44                   ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) (was: [BUG] Footnotes in section titles) Ihor Radchenko
2024-02-01 17:44 10%                 ` [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc) Juan Manuel Macías
2024-02-01 17:57  5%                   ` Marvin Gülker
2024-02-02 17:00  5%                   ` Ihor Radchenko
2024-02-02 18:10 13%                     ` Juan Manuel Macías
2024-02-02 20:21  5%                       ` Exporting multiple #+AUTHOR keywords (was: [DISCUSSION] Allowing footnote-references inside parsed keywords (#+AUTHOR, #+TITLE, etc)) Ihor Radchenko
2024-02-02 22:26 11%                         ` Exporting multiple #+AUTHOR keywords Juan Manuel Macías
2024-02-04 15:21  6%                           ` Ihor Radchenko
2024-02-04 16:16                                 ` Max Nikulin
2024-02-04 22:13  9%                               ` Juan Manuel Macías
2024-01-29 20:03 10% An academic journal entirely made in Org-Mode Juan Manuel Macías
2024-01-29 20:16  6% ` Daniel Ortmann
2024-01-29 23:16  6% ` Dr. Arne Babenhauserheide
2024-01-31 14:30  6%   ` Juan Manuel Macías
2024-01-30  5:34  6% ` tomas
2024-01-29 20:05 10% An academic journal made entirely " Juan Manuel Macías
2024-01-30  0:00  6% ` William Denton
2024-02-01  7:07     RFI: LaTeX - AUTO for \usepackage{inputenc} Pedro Andres Aranda Gutierrez
2024-02-02 16:00     ` [RFC] LaTeX - automatically configure encoding when exporting non-Latin languages Ihor Radchenko
2024-02-02 16:18 12%   ` Juan Manuel Macías
2024-02-02 16:41  0%     ` Pedro Andres Aranda Gutierrez
2024-02-04 19:41     [DISCUSSION] Add "Recent News" to orgmode.org Ihor Radchenko
2024-02-04 20:24 10% ` Juan Manuel Macías
2024-02-08 22:13 11% Link type for pdf-tools annotations Juan Manuel Macías
2024-02-08 23:25  6% ` Ihor Radchenko
2024-02-09  0:40 11%   ` Juan Manuel Macías
2024-02-09 12:13  6% ` Irfan S
2024-02-09 12:48 13%   ` Juan Manuel Macías
2024-02-10  1:58  9% [patch] Add two new header args to LaTeX block Juan Manuel Macías
2024-02-10 14:37  6% ` Ihor Radchenko
2024-02-10 15:20 12%   ` Juan Manuel Macías
2024-02-10 16:35  6%     ` Ihor Radchenko
2024-02-10 17:48 12%       ` Juan Manuel Macías
2024-02-10 19:35 10%         ` Juan Manuel Macías
2024-02-10 21:07  6%           ` Ihor Radchenko
2024-02-10 23:34 10%             ` Juan Manuel Macías
2024-02-11 14:43  5%               ` Ihor Radchenko
2024-02-11 20:01  9%                 ` Juan Manuel Macías
2024-02-13 13:42  5%                   ` Ihor Radchenko
2024-02-13 20:25 11%                     ` Juan Manuel Macías
2024-02-18 14:20  5%                       ` Ihor Radchenko
2024-02-18 13:43 10%                         ` Juan Manuel Macías
2024-02-19 11:15  6%                           ` Ihor Radchenko
2024-02-19 13:24 12%                             ` Juan Manuel Macías
2024-02-12  6:36     Retaking AUTO for \usepackage{fontenc} Pedro Andres Aranda Gutierrez
2024-02-12 14:01     ` Ihor Radchenko
2024-02-13  7:51       ` Pedro Andres Aranda Gutierrez
2024-02-13 11:57 13%     ` Juan Manuel Macías
2024-02-13 16:47  6%       ` Pedro Andres Aranda Gutierrez
2024-02-13 17:22 11%         ` Juan Manuel Macías
2024-02-14 14:55  6%           ` Ihor Radchenko
2024-02-14 22:03 13%             ` Juan Manuel Macías
2024-02-12 10:05     "Full Block" character in example block not visible in Beamer PDF Loris Bennett
2024-02-12 11:06 12% ` Juan Manuel Macías
2024-02-12 12:40  6%   ` Loris Bennett
2024-02-12 15:24 11% [patch] ox.latex.el: Add missing character warnings Juan Manuel Macías
2024-02-12 18:15 11% ` Juan Manuel Macías
2024-02-12 18:26  6%   ` Ihor Radchenko
2024-02-12 19:17 10%     ` Juan Manuel Macías
2024-02-12 19:52  5%       ` Ihor Radchenko
2024-02-12 21:20  6%         ` Juan Manuel Macías
2024-02-13 14:29  5%           ` Ihor Radchenko
2024-02-13 16:01 11%             ` Juan Manuel Macías
2024-02-14 14:37  6%               ` Ihor Radchenko
2024-02-17  0:36     Exporting multiple #+AUTHOR keywords ypuntot
2024-02-17 10:34  6% ` Juan Manuel Macías
2024-02-19 10:08     set italian language in LaTeX export Luca Ferrari
2024-02-19 11:11 13% ` Juan Manuel Macías
2024-02-19 14:06       ` Luca Ferrari
2024-02-19 15:11 13%     ` Juan Manuel Macías
2024-02-20 20:35  9% [proof of concept] inline language blocks Juan Manuel Macías
2024-02-21  8:42  6% ` Ihor Radchenko
2024-02-21 10:57 10%   ` Juan Manuel Macías
2024-02-21 12:00  5%     ` Ihor Radchenko
2024-02-21 12:53 10%       ` Juan Manuel Macías
2024-02-21 13:10  5%         ` Ihor Radchenko
2024-02-21 14:13 12%           ` Juan Manuel Macías
2024-02-21 20:32  8%             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-21 23:29 12%               ` [proof of concept] inline-special-block Juan Manuel Macías
2024-02-22 22:03 13%               ` Juan Manuel Macías
2024-02-21 22:11  4%             ` [proof of concept] inline language blocks Samuel Wales
2024-02-21 22:28 13%               ` Juan Manuel Macías
2024-02-21 22:55  6%                 ` Samuel Wales
2024-02-21 23:02 10%                 ` Juan Manuel Macías
2024-02-28 10:29  7%                   ` Max Nikulin
2024-02-28 13:15  4%                     ` Juan Manuel Macías
2024-02-28 17:21  6%                       ` Max Nikulin
2024-02-28 23:42  4%                         ` Juan Manuel Macías
2024-02-29  7:05  6%                           ` Max Nikulin
2024-02-29 10:41 10%                             ` Juan Manuel Macías
2024-02-29 12:05  5%                               ` Max Nikulin
2024-02-29 12:50 10%                                 ` Juan Manuel Macías
2024-02-21 23:33  6%         ` Suhail Singh
2024-02-23 23:50  4% [testing patch] inline-special-block with full implementation for LaTeX backend Juan Manuel Macías
2024-02-25 13:53 11% A question about local/experimental branches Juan Manuel Macías
2024-02-25 14:05  6% ` Ihor Radchenko
2024-02-25 15:10 12%   ` Juan Manuel Macías
2024-02-26  8:43       ` Bastien Guerry
2024-02-26 11:06         ` Ihor Radchenko
2024-02-26 13:03           ` Bastien Guerry
2024-02-27  9:57 10%         ` Juan Manuel Macías
2024-02-26  8:55     [ANN] Please share useful blog posts on this list with the [BLOG] subject prefix Bastien
2024-02-26 10:32 13% ` Juan Manuel Macías
2024-02-26 11:03  5%   ` Ihor Radchenko
2024-02-26 12:58  6%   ` Bastien Guerry
2024-03-01 20:34  9% Experimental public branch for inline special blocks Juan Manuel Macías
2024-03-02  8:29     ` Stefan Nobis
2024-03-02 10:57 13%   ` Juan Manuel Macías
2024-03-03 20:29  9% ` Juan Manuel Macías
2024-03-10  2:08 10%   ` `:export' attribute?: " Juan Manuel Macías
2024-03-10 13:54 13%     ` Juan Manuel Macías
2024-03-11 10:27  5%     ` Max Nikulin
2024-03-11 13:59 11%       ` Juan Manuel Macías
2024-03-11 17:01  6%         ` Max Nikulin
2024-03-11 20:19 11%           ` Juan Manuel Macías
2024-03-12  8:32  6%             ` Stefan Nobis
2024-03-12 13:45 11%               ` Juan Manuel Macías
2024-03-12 16:20  5%                 ` Max Nikulin
2024-03-12 17:41 12%                   ` Juan Manuel Macías
2024-03-13 16:08  5%                     ` Max Nikulin
2024-03-13 16:48 12%                       ` Juan Manuel Macías
2024-03-13 17:16 14%                         ` Juan Manuel Macías
2024-03-15  2:19  5%                           ` Juan Manuel Macías
2024-03-15 10:52  4%                             ` Max Nikulin
2024-03-15 13:10  5%                               ` Juan Manuel Macías
2024-03-15 17:21  5%                                 ` Max Nikulin
2024-03-15 16:26 12%                               ` Juan Manuel Macías
2024-03-16 14:07  4%                                 ` Max Nikulin
2024-03-18 19:42  6%                                   ` Juan Manuel Macías
2024-03-19 14:54  3%                                     ` Max Nikulin
2024-03-19 17:47  6%                                       ` Juan Manuel Macías
2024-03-21 10:26  5%                                       ` inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) Juan Manuel Macías
2024-03-26 16:56  6%                                         ` inline-special-block: export rules Max Nikulin
2024-03-04 17:13  5% ` naming: Re: Experimental public branch for inline special blocks Max Nikulin
2024-03-04 17:29       ` Ihor Radchenko
2024-03-04 17:49 12%     ` Juan Manuel Macías
2024-03-05 10:53  6%       ` Max Nikulin
2024-03-05 15:16 11%         ` Juan Manuel Macías
2024-03-04 18:07  6%   ` Juan Manuel Macías
2024-03-04 22:17  5%     ` Samuel Wales
2024-03-04 22:18  0%       ` Samuel Wales
2024-03-05 16:47  5% ` smallcaps: " Max Nikulin
2024-03-05 17:28 10%   ` Juan Manuel Macías
2024-03-06 10:55  5%     ` Max Nikulin
2024-03-06 15:21 11%       ` Juan Manuel Macías
2024-03-06 16:53  7% ` To avoid zero width space: " Max Nikulin
2024-03-06 18:27 12%   ` Juan Manuel Macías
2024-03-06 21:13 12%   ` Juan Manuel Macías
2024-03-07 10:57  6% ` false positives: " Max Nikulin
2024-03-07 11:06 12%   ` Juan Manuel Macías
2024-03-07 11:18  6%     ` Ihor Radchenko
2024-03-07 11:19  6%       ` Juan Manuel Macías
2024-03-07 15:53 12%       ` Juan Manuel Macías
2024-03-07 16:09  6%         ` Ihor Radchenko
2024-03-07 16:57 12%           ` Juan Manuel Macías
2024-03-07 18:21 12%             ` Juan Manuel Macías
2024-03-08 13:58  6%               ` Max Nikulin
2024-03-08 15:44 12%                 ` Juan Manuel Macías
2024-03-08 16:04  6%                   ` Max Nikulin
2024-03-08 16:15  6%                   ` Ihor Radchenko
2024-03-08 18:44 12%                     ` Juan Manuel Macías
2024-03-08 18:57 14%                       ` Juan Manuel Macías
2024-03-09 11:10  6%                         ` Max Nikulin
2024-03-09 11:48 12%                           ` Juan Manuel Macías
2024-03-09 15:24 14%                             ` Juan Manuel Macías
2024-03-10  7:11  7%                               ` Max Nikulin
2024-03-05  0:58  9% [tip] Export to PDF with latexmk 'continuous preview' option Juan Manuel Macías
2024-03-11  9:56     Footnotes on line and not raised Colin Baxter
2024-03-11 10:12     ` Colin Baxter
2024-03-11 11:03 12%   ` Juan Manuel Macías
2024-03-22  1:04 11% [bug] Smart quotes: confusion of apostrophe with second level quotes Juan Manuel Macías
2024-03-23 11:38  5% ` Ihor Radchenko
2024-03-23 13:41  6%   ` Juan Manuel Macías
2024-03-23 13:49  6%     ` Ihor Radchenko
2024-03-23 15:42  6%       ` Juan Manuel Macías
2024-03-24  9:55  6%         ` Ihor Radchenko

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