emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Juan Manuel Macías" <maciaschain@posteo.net>
To: orgmode <emacs-orgmode@gnu.org>
Subject: Re: [proof of concept] inline language blocks
Date: Wed, 28 Feb 2024 23:42:11 +0000	[thread overview]
Message-ID: <87le74noks.fsf@posteo.net> (raw)
In-Reply-To: <efec3077-63fd-49cb-bb6c-5b8f7d5afecf@gmail.com> (Max Nikulin's message of "Thu, 29 Feb 2024 00:21:37 +0700")

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




  reply	other threads:[~2024-02-28 23:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 20:35 [proof of concept] inline language blocks Juan Manuel Macías
2024-02-21  8:42 ` Ihor Radchenko
2024-02-21 10:57   ` Juan Manuel Macías
2024-02-21 12:00     ` Ihor Radchenko
2024-02-21 12:53       ` Juan Manuel Macías
2024-02-21 13:10         ` Ihor Radchenko
2024-02-21 14:13           ` Juan Manuel Macías
2024-02-21 20:32             ` [proof of concept] inline-special-block (was: [proof of concept] inline language blocks) Juan Manuel Macías
2024-02-21 23:29               ` [proof of concept] inline-special-block Juan Manuel Macías
2024-02-22 22:03               ` Juan Manuel Macías
2024-02-21 22:11             ` [proof of concept] inline language blocks Samuel Wales
2024-02-21 22:28               ` Juan Manuel Macías
2024-02-21 22:55                 ` Samuel Wales
2024-02-21 23:02                 ` Juan Manuel Macías
2024-02-28 10:29                   ` Max Nikulin
2024-02-28 13:15                     ` Juan Manuel Macías
2024-02-28 17:21                       ` Max Nikulin
2024-02-28 23:42                         ` Juan Manuel Macías [this message]
2024-02-29  7:05                           ` Max Nikulin
2024-02-29 10:41                             ` Juan Manuel Macías
2024-02-29 12:05                               ` Max Nikulin
2024-02-29 12:50                                 ` Juan Manuel Macías
2024-02-21 23:33         ` Suhail Singh
2024-03-31 14:56 ` Daniel Clemente
2024-03-31 15:20   ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87le74noks.fsf@posteo.net \
    --to=maciaschain@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).