From: Kaushal Modi <kaushal.modi@gmail.com>
To: "Juan Manuel Macías" <maciaschain@posteo.net>
Cc: orgmode <emacs-orgmode@gnu.org>
Subject: Re: About 'inline special blocks'
Date: Mon, 23 May 2022 11:20:08 -0400 [thread overview]
Message-ID: <CAFyQvY3q314qh83k-F=43vGajVsNV1VRBvZMXOK7tLiEtowWmw@mail.gmail.com> (raw)
In-Reply-To: <87a6b8pbhg.fsf@posteo.net>
On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
<maciaschain@posteo.net> wrote:
> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think it would be very productive for Org to have a
> multipurpose inline container, so it occurred to me to open this thread
> to invite a possible discussion on the subject.
Thanks for doing this. I missed that thread. I would welcome this
feature addition too.
If I understand correctly, this will mean adding a new element type
that all the Org exporters can then support. Right?
> The question is: Does Org Mode need inline special blocks?
Yes.
> On the one hand, it seems that we can live without them.
Not quite. I developed few hacks in ox-hugo to make regular special
blocks act like special inline blocks :D
Example:
=====
More than the visual inaccuracy of seeing curved quoted where straight
quotes should be,
#+begin_mark
if someone copies that code to try it out, it will
not work
#+end_mark
!
=====
Another example:
=====
By the way, I submitted a patch for fixing the escaping of straight
quotes in ~shortdoc-add-function~ documentation string
#+begin_sidenote
I planned to fix just this straight quote escaping issue, but then I
also ended up slightly improving the documentation of the ~(FUNC :eval
EVAL)~ and other forms used for adding a function's documentation to
~shortdoc~.
#+end_sidenote
in ..
=====
ox-hugo does the job of deleting the newlines and white-space (leaving
just 1) before and after few "special" special Org blocks.
> Therefore, I think that inline special blocks would fill an important
> gap. They could be translated into HTML as a <span></span> container;
+1
> Perhaps the syntax could be a continuation of that of inline code
> blocks. Something like:
>
> <name>_[options]{text}
The challenging part will be deciding the syntax so that there are no
false matches.
May be reserve "inline_" for inline blocks?
e.g. inline_<name>[options]{text} ?
Using my example above, if I want the <mark> elements in HTML, I would do
abc inline_mark{some text} def
and that would export to below for an HTML based exporter:
abc <mark>some text</mark> def
next prev parent reply other threads:[~2022-05-23 15:21 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-23 14:30 About 'inline special blocks' Juan Manuel Macías
2022-05-23 15:20 ` Kaushal Modi [this message]
2022-05-23 21:06 ` Juan Manuel Macías
2022-05-24 2:36 ` Tim Cross
2022-05-24 2:51 ` Timothy
2022-05-24 6:54 ` Eric S Fraga
2022-05-26 7:30 ` Christian Moe
2022-05-24 15:09 ` Max Nikulin
2022-05-25 7:22 ` Ihor Radchenko
2022-05-25 17:05 ` Max Nikulin
2022-05-26 2:54 ` Merging paragraphs separated by comment lines during export (was: About 'inline special blocks') Ihor Radchenko
2022-05-24 3:56 ` About 'inline special blocks' Ihor Radchenko
2022-05-24 14:05 ` João Pedro
2022-05-26 4:56 ` Ihor Radchenko
2022-05-26 11:30 ` João Pedro
2022-05-26 12:20 ` Ihor Radchenko
2022-05-26 17:35 ` João Pedro
2022-05-26 21:22 ` About opening issues vs email [Was: About 'inline special blocks'] Kaushal Modi
2022-05-27 4:24 ` Ihor Radchenko
2022-05-27 4:36 ` João Pedro
2022-05-25 13:55 ` About 'inline special blocks' Juan Manuel Macías
2022-06-17 6:28 ` Ihor Radchenko
2022-06-17 19:49 ` Juan Manuel Macías
2022-06-19 12:47 ` Juan Manuel Macías
2022-06-19 19:30 ` Christian Moe
2022-06-19 20:15 ` Juan Manuel Macías
2022-06-19 22:18 ` Tim Cross
2022-06-20 16:57 ` Max Nikulin
2022-06-20 19:06 ` Juan Manuel Macías
2022-06-21 16:39 ` Max Nikulin
2022-06-21 18:19 ` Juan Manuel Macías
2022-06-20 22:46 ` Tim Cross
2022-06-26 4:07 ` Org mode export accessibility (was: About 'inline special blocks') Ihor Radchenko
2022-06-26 6:29 ` Tim Cross
2022-06-26 10:46 ` Org mode export accessibility Juan Manuel Macías
2022-06-26 10:54 ` Ihor Radchenko
2022-06-27 14:40 ` T.V Raman
2022-06-30 7:53 ` Ihor Radchenko
2022-07-07 14:18 ` briangpowell
2022-07-07 14:42 ` T.V Raman
2022-07-08 4:38 ` Ihor Radchenko
2022-07-08 13:55 ` T.V Raman
2022-07-09 3:39 ` Ihor Radchenko
2022-07-09 13:20 ` T.V Raman
2022-09-30 11:07 ` Max Nikulin
2022-09-30 13:29 ` T.V Raman
2022-09-30 16:43 ` Max Nikulin
2022-09-30 16:55 ` T.V Raman
2022-10-01 4:36 ` Ihor Radchenko
2022-10-01 14:59 ` T.V Raman
2022-10-02 2:54 ` Org source in PDF (Re: Org mode export accessibility) Max Nikulin
2022-10-02 3:50 ` Timothy
2022-07-07 14:43 ` Org mode export accessibility T.V Raman
2022-07-07 15:37 ` T.V Raman
2022-07-08 4:33 ` Ihor Radchenko
2022-07-08 13:54 ` T.V Raman
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='CAFyQvY3q314qh83k-F=43vGajVsNV1VRBvZMXOK7tLiEtowWmw@mail.gmail.com' \
--to=kaushal.modi@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=maciaschain@posteo.net \
/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).