[proof of concept] inline language blocks

[proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

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>

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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 

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

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>

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

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>

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

[proof of concept] inline-special-block (was: [proof of concept] inline language blocks)

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Samuel Wales]

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Samuel Wales]

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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 

Re: [proof of concept] inline-special-block

[Juan Manuel Macías]

Juan Manuel Macías writes:

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

Correction:

&type[optional parameters]{contents}

Re: [proof of concept] inline language blocks

[Suhail Singh]

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

Re: [proof of concept] inline-special-block

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

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.

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

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

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Max Nikulin]

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.

Re: [proof of concept] inline language blocks

[Juan Manuel Macías]

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

Re: [proof of concept] inline language blocks

[Daniel Clemente]

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

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

Sorry for joining the discussion a bit late. A long time ago I created a
syntax to be able to mix languages in that way, and a program to separate
each version into a different file.

Info: https://www.danielclemente.com/dislines/
Sample: https://www.danielclemente.com/dislines/perl.txt
Syntax: https://www.danielclemente.com/dislines/syntax.en.html
Syntax in practice: https://www.danielclemente.com/dislines/quick.en.txt

It's format-agnostic, and unrelated to org. I have used it in plain HTML
and other file types.
Many times I tried to use it for org-mode, and while it works, the
challenges are more. For instance I'd like to integrate it into the export
process (so that a single command produces many files), I want to use it to
translate headers (but where do you keep the translations of the header
name? in the header itself? in a property?), I want the TOC to use the
translated headers, and I want to keep links working (and making sure each
language only links to files in the same language). More difficult yet:
what if a particular language requires another header structure (more
headers, fewer headers, or headers arranged in another way).
I tried several approaches (inline tasks, SRC blocks, my own syntax, tags
in headers, one sub-header per language, selective export of tags,
properties in headers, post-processing, exporting all and making language
selection in JS, one manual TOC per language, …). But I didn't have time to
think or discover a good system. Multi-language hypertext systems are hard.

Maybe you can get some ideas from this, if you're still working on mixing
human languages in org paragraphs/headers/lines/files. I see the discussion
may have shifted from multilingual texts (i.e. human languages) to
multi-backend texts (e.g. export HTML/LaTeX/… differently); multi-backend
variations might be an easier goal than dealing with multilingual texts and
translations.

Thanks for implementing code for your ideas.

On Tue, 20 Feb 2024 at 20:36, Juan Manuel Macías <maciaschain@posteo.net>
wrote:

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

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

Re: [proof of concept] inline language blocks

[Ihor Radchenko]

Daniel Clemente <n142857@gmail.com> writes:

> Sorry for joining the discussion a bit late. A long time ago I created a
> syntax to be able to mix languages in that way, and a program to separate
> each version into a different file.
>
> Info: https://www.danielclemente.com/dislines/
> Sample: https://www.danielclemente.com/dislines/perl.txt
> Syntax: https://www.danielclemente.com/dislines/syntax.en.html
> Syntax in practice: https://www.danielclemente.com/dislines/quick.en.txt
>
> It's format-agnostic, and unrelated to org. I have used it in plain HTML
> and other file types.
> ...

AFAIK, the common tool for this kind of tasks is GNU gettext and .po
files.
See https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html
and recent discussion in
https://yhetil.org/emacs-devel/1E3685C0-7B33-45BB-BF3C-AD1215BAB33B@traductaire-libre.org/

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