From: Denis Maier <denismaier@mailbox.org>
To: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Org-syntax: Intra-word markup
Date: Sat, 4 Dec 2021 16:57:53 +0100 [thread overview]
Message-ID: <9525e029-a590-3f48-df64-ffb9176075d9@mailbox.org> (raw)
In-Reply-To: <sod9ac$uul$1@ciao.gmane.io>
Am 03.12.2021 um 15:24 schrieb Max Nikulin:
> On 03/12/2021 02:03, Nicolas Goaziou wrote:
>>> Denis Maier writes:
>>>
>>>> As for suggestions: If just using /intra/word creates ambiguities, what
>>>> about the asciidoc solution? So //intra//word?
>>
>> I sympathize to the idea of intra-word emphasis, but the syntax above is
>> going to cause some ambiguous situations.
>
> I suppose, some more general solution is required.
>
>> I do think the marker + zero-width space is one way to go. We could, as
>> an improvement, consider zero-width spaces around emphasis markers to be
>> part of the markup, and replace them along during export.
>
> Zero-space characters adjacent to emphasis markers is a better idea than
> replacing any zero space. However I agree with Juan Manuel that white
> space characters, especially completely invisible (I am not Eli who sees
> such special characters by moving cursor through them) should not be
> overloaded. From my point of view, it is acceptable to use zero width
> spaces as a workaround but they should not become official part of Org
> syntax.
>
>> Another solution is to introduce a less-subtle, but less prone to
>> ambiguity, syntax, e.g.,
>>
>> /{bold}/markup or /|bold|/markup
>>
>> where /{ }/ or /| |/ become "extended" markers.
>
> More explicit markup leaves less room for ambiguities, and I like the
> idea due to this reason. On the other hand it diverges from principle of
> lightweight markup. The almost only special character in TeX is "\",
> HTML has three ones "&<>" with simple escape rules. Org uses many
> special characters to avoid verbosity and requires some tricks to escape
> them. Markers like "\{" make Org more verbose but do not make it more
> strict, a lot of things still rely on heuristics.
>
> I have an idea what can be done when some special markup is required
> that is not fit into current syntax. Unfortunately some new constructs
> should be introduced anyway: inline objects and multiline elements that
> represent simplified result of parsed Org structures:
>
> ((italic "intra") "word")
>
> wrapped with some markup. It should satisfy any special needs (and even
> should allow to create invalid impossible constructs). Maybe idea of
> combination of lightweight markup and low-level blocks better suits for
> some other project with more expressive internal representation. In Org
> it may become the most hated feature.
I have to admit I like this idea. That brings a lot of flexibility to
accomodate even the most obscure needs, yet it makes the discussion
about escape characters or new symbols much less pressing. After all,
most markup languages face the same problem, i.e., special characters
are limited, and beyond the usual /*_ the meaning of characters becomes
much less obvious.
This idea reminds me a bit of Scribble/Racket where every document is
just inverted code, which makes it possible to insert arbitrary Racket
code in your prose...
Denis
>
>
>
next prev parent reply other threads:[~2021-12-04 15:58 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 10:50 Org-syntax: Intra-word markup Denis Maier
2021-12-02 11:18 ` Ihor Radchenko
2021-12-02 11:30 ` Juan Manuel Macías
2021-12-02 11:36 ` Denis Maier
2021-12-02 12:01 ` Ihor Radchenko
2021-12-02 11:42 ` Marco Wahl
2021-12-02 11:50 ` Denis Maier
2021-12-02 12:10 ` Ihor Radchenko
2021-12-02 12:40 ` Denis Maier
2021-12-02 12:54 ` Ihor Radchenko
2021-12-02 13:14 ` Juan Manuel Macías
2021-12-02 13:28 ` Denis Maier
2021-12-02 12:48 ` Max Nikulin
2021-12-02 12:02 ` Ihor Radchenko
2021-12-02 12:00 ` Ihor Radchenko
[not found] ` <87r1avtdjy.fsf@ucl.ac.uk>
2021-12-02 12:27 ` Denis Maier
2021-12-02 13:06 ` Eric S Fraga
2021-12-02 12:28 ` Denis Maier
2021-12-02 12:55 ` Ihor Radchenko
2021-12-02 11:58 ` Timothy
2021-12-02 12:26 ` Denis Maier
2021-12-02 13:07 ` Ihor Radchenko
2021-12-02 15:51 ` Max Nikulin
2021-12-02 18:11 ` Tom Gillespie
2021-12-02 19:09 ` Juan Manuel Macías
2021-12-04 13:07 ` Org-syntax: emphasis and not English punctuation Max Nikulin
2021-12-04 16:42 ` Juan Manuel Macías
2021-12-02 20:47 ` Org-syntax: Intra-word markup Denis Maier
2021-12-02 22:44 ` Samuel Wales
2021-12-03 14:53 ` Max Nikulin
2021-12-03 23:51 ` Tim Cross
2021-12-04 15:01 ` Max Nikulin
2021-12-05 23:34 ` Russell Adams
2021-12-05 23:37 ` Russell Adams
2021-12-06 1:39 ` Samuel Wales
2021-12-02 19:03 ` Nicolas Goaziou
2021-12-02 19:34 ` Juan Manuel Macías
2021-12-02 23:05 ` Nicolas Goaziou
2021-12-02 23:24 ` Juan Manuel Macías
2021-12-03 14:24 ` Max Nikulin
2021-12-03 15:01 ` Juan Manuel Macías
2021-12-04 15:57 ` Denis Maier [this message]
2021-12-04 17:53 ` Tom Gillespie
2021-12-04 18:37 ` John Kitchin
2021-12-04 21:16 ` Juan Manuel Macías
2021-12-06 10:57 ` Raw Org AST snippets for "impossible" markup Max Nikulin
2021-12-06 15:45 ` Juan Manuel Macías
2021-12-06 16:56 ` Juan Manuel Macías
2021-12-08 13:09 ` Max Nikulin
2021-12-08 23:19 ` Juan Manuel Macías
2021-12-08 23:35 ` John Kitchin
2021-12-09 7:01 ` Juan Manuel Macías
2021-12-09 14:56 ` Max Nikulin
2021-12-09 16:11 ` Juan Manuel Macías
2021-12-09 22:27 ` Juan Manuel Macías
2022-01-03 14:34 ` Max Nikulin
2021-12-04 19:04 ` Org-syntax: Intra-word markup Timothy
2021-12-04 21:48 ` Tom Gillespie
2021-12-06 10:59 ` Max Nikulin
2022-01-28 14:52 ` Max Nikulin
2022-01-29 3:13 ` Ihor Radchenko
2022-01-29 13:05 ` Juan Manuel Macías
2022-02-02 15:28 ` Max Nikulin
2022-02-02 20:01 ` Juan Manuel Macías
2022-02-03 12:10 ` Max Nikulin
2021-12-06 11:01 ` Denis Maier
2022-01-28 12:12 ` [PATCH] Intra-word markup: \relax Max Nikulin
2022-01-28 13:13 ` Juan Manuel Macías
2022-02-02 15:42 ` Max Nikulin
-- strict thread matches above, loose matches on Subject: below --
2021-12-02 13:36 Org-syntax: Intra-word markup autofrettage
2021-12-02 15:24 ` Robert Pluim
2021-12-02 17:11 ` autofrettage
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=9525e029-a590-3f48-df64-ffb9176075d9@mailbox.org \
--to=denismaier@mailbox.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/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).