From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Links & images with different attributes in the same paragraph
Date: Tue, 19 Dec 2023 21:39:26 +0700 [thread overview]
Message-ID: <uls9v0$168v$1@ciao.gmane.io> (raw)
In-Reply-To: <878r5ucill.fsf@localhost>
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.)
next prev parent reply other threads:[~2023-12-19 14:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 ` Ihor Radchenko
2023-12-19 14:39 ` Max Nikulin [this message]
2023-12-21 14:03 ` 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='uls9v0$168v$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--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).