From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp10.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms5.migadu.com with LMTPS
	id 0OhZH9R5r2LwdgEAbAwnHQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 19 Jun 2022 21:32:36 +0200
Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp10.migadu.com with LMTPS
	id KDlsHtR5r2LE5QAAG6o9tA
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sun, 19 Jun 2022 21:32:36 +0200
Received: from lists.gnu.org (lists.gnu.org [209.51.188.17])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by aspmx1.migadu.com (Postfix) with ESMTPS id 2F1B929F76
	for <larch@yhetil.org>; Sun, 19 Jun 2022 21:32:36 +0200 (CEST)
Received: from localhost ([::1]:35068 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	id 1o30ex-0007Xf-B7
	for larch@yhetil.org; Sun, 19 Jun 2022 15:32:35 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50776)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mail@christianmoe.com>)
 id 1o30cs-0007XD-Fn
 for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 15:30:26 -0400
Received: from mailer-211-145.hitrost.net ([91.185.211.145]:12655)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mail@christianmoe.com>)
 id 1o30co-000438-Rb
 for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 15:30:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=christianmoe.com; s=x; h=Content-Transfer-Encoding:Content-Type:
 MIME-Version:Message-ID:Date:In-reply-to:Subject:To:From:References:Sender:
 Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
 Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
 List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=G7DB2p42Jnh+DeX6KPwdm5o5aCaiM90wLFuApTXRPjo=; b=YqroYuINMZMWfRVKLftsn5ZDWH
 qtTMiVv133cZGkInjiO3Oau+h9YQ4OHPANQLakzCqKjRDyhI256/p3GQklyn+ShAOsu4Tvllz6kvO
 jPnkobPYC+fzkp9uS2rOytlw5uW0yMVh3mtUo3nPDR8NHFwnLkJuDNf6EqM0UfYCltQHXObCFm0tf
 1WlKUHvvc/OhI1LZQjA+oxH1DUxyHA/qzxNMLDUSLZAg+8xPDAWw1LTnWg80/UBjc6hYG+PPwmJBB
 SSmYy+s5brTTEb+4iVhGdM9GZeFbZF+8vsCGBJAfCAMXyuBgSyf4TY5KE7cmQDDA00K/MRmPM1XWe
 yMFw848w==;
Received: from 84-20-244-215.dynamic.telemach.net ([84.20.244.215]
 helo=Tauriel)
 by b1.hitrost.net with esmtpsa  (TLS1.3) tls TLS_AES_256_GCM_SHA384
 (Exim 4.95) (envelope-from <mail@christianmoe.com>)
 id 1o30ch-00FaOd-I1; Sun, 19 Jun 2022 21:30:15 +0200
References: <87a6b8pbhg.fsf@posteo.net>
 <CAFyQvY3q314qh83k-F=43vGajVsNV1VRBvZMXOK7tLiEtowWmw@mail.gmail.com>
 <875ykwvmz7.fsf@posteo.net>
User-agent: mu4e 1.2.0; emacs 27.2
From: Christian Moe <mail@christianmoe.com>
To: emacs-orgmode@gnu.org
Subject: Re: About 'inline special blocks'
In-reply-to: <875ykwvmz7.fsf@posteo.net>
Date: Sun, 19 Jun 2022 21:30:14 +0200
Message-ID: <874k0gpi2h.fsf@christianmoe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-GeoIP: Country [IP], SI [84.20.244.215]
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
X-Authenticated-Id: mail@christianmoe.com
Received-SPF: pass client-ip=91.185.211.145;
 envelope-from=mail@christianmoe.com; helo=mailer-211-145.hitrost.net
X-Spam_score_int: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1,
 DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-orgmode@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: "Emacs-orgmode" <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-To: larch@yhetil.org
X-Migadu-Country: US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1655667156;
	h=from:from:sender:sender:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:list-id:list-help:
	 list-unsubscribe:list-subscribe:list-post:dkim-signature;
	bh=G7DB2p42Jnh+DeX6KPwdm5o5aCaiM90wLFuApTXRPjo=;
	b=fexrc6TEMavq+QuzdDk3HZEH20QPmCMROFp2xQwaLUkdb0/XGREjpfE5XPHxOfc4uMstRQ
	lMgUk+m/Y9v0Ii2ur3afJu/iRWAEDc1RvwKhY/HC1Z6/V4hHF2vCxf3rgtnHMW6zIfXONz
	1NLs/wUE5p4xgzK7851tw8C2HqNwB0xLIZ3uu8OOhyqX5oqkDBjd1+F4r0TTdcJAkzkAjo
	AixUWd14LfcBip+eKONXDu5Cvy23SXggBOdaxDLZZxXvVnLdFycI/NAR039BisrBKNWJxX
	yTCphgw17dr/7M3Frn0fvyHNFvQEj4IGpj9iS4K/UhluQjjb9apbbMj3aRPJtw==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655667156; a=rsa-sha256; cv=none;
	b=mwc/hBJ74K0OGF+VKvWd4P/tcV2jLqVDYOt6h2dPOr9/zy+I4NU9WguDd9QCKu048zWbGd
	t3VBhZ+9UEsUwErj0mqgskzwDOfou20QZjYvQNzLoFNdRTIK1FXANkDQCcVAnyHwcFT4Sj
	4TW1NwPzHmWANwqpSxDnI4l34R6iqX5orQ1+ECqRBiHs8ZGvr3SBz/LIQm5xoCjQ8yrMrR
	0KstiiBDnrQ56yshIEbzAFaOksDPv9ZA66O5relOI6a5yNhlTFGJNrJ0FgJ4kOPsluspgF
	qtgh/FCXkyrTqHKR0Xyjpm212OE2pdix5YsnePkqiXZQmQRWQA+SyINIwD3UNA==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=temperror ("DNS error when getting key") header.d=christianmoe.com header.s=x header.b=YqroYuIN;
	dmarc=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
X-Migadu-Spam-Score: -2.78
Authentication-Results: aspmx1.migadu.com;
	dkim=temperror ("DNS error when getting key") header.d=christianmoe.com header.s=x header.b=YqroYuIN;
	dmarc=none;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
X-Migadu-Queue-Id: 2F1B929F76
X-Spam-Score: -2.78
X-Migadu-Scanner: scn1.migadu.com
X-TUID: V+VzFmPly/l1


Juan Manuel Mac=C3=ADas writes:

> To add some ideas that have been occurring to me these days...
>

Hi,

This makes sense to me.

Note: For the html output in your example, I expect you don't mean
<name>contents></name>, but <span class=3D"name">contents</span>. That
would give the desired custom style controle of the output, and would
parallel the behavior of special blocks.

If "inline special blocks" will be able to nest, they will have an
advantage over org macros, which cannot.

Apart from nesting, an org macro could do the same job, but less
elegantly. The suggested inline syntax would not require commas to be
escaped in the contents. And it would be somewhat more concise and far
more legible, as illustrated in the below example (with working macros,
imagined inline special blocks, and a CSS implementation):

#+begin_example
#+macro: fmt @@html:<span class=3D"$1">$2</span>@@@@latex:\$1{$2}@@@@odt:<t=
ext:span text:style-name=3D"$1">$2</text:span>@@
#+html_head: <style>.highlight {background-color: yellow;}
#+html_head:        .smallcaps {font-variant: small-caps;}</style>

This is some {{{fmt(highlight, highlighted text)}}} and this is some
{{{fmt(smallcaps, text in small caps)}}}.

This is some %[highlight]{highlighted text} and this is some
%[smallcaps]{text in small caps}.
#+end_example

Yours,
Christian

> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would produce
> an overly complicated syntax. Big brothers are independent of the
> paragraph and there it makes sense to add lines with attr_latex, etc.,
> since it is a line-oriented syntax. 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.
>
> Another argument against possible fine-tuning within inline special
> blocks, for export purposes, is that (in my opinion) direct formatting
> is a practice that should be avoided as much as possible in a document.
> A document with a lot of direct formatting is an inconsistent document.
> In html, all possible formatting should be controlled by style sheets;
> in LaTeX, by (re)defining macros, commands and environments in the
> preamble or in a .sty file; in odt using character styles.
>
> Perhaps if we detach special blocks from fine-tuning possibilities we
> lose some (export) flexibility, but we gain in a clearer implementation
> of these elements and keep Org aseptic about the output format. And in
> any case, if someone needs a fine-tuning in a certain case, there are
> always the export filters. Or it can be implemented in a similar way to
> inline tasks, with a default format function (for html, latex, etc),
> which can be changed via a defcustom.
>
> Starting from that, a syntax like this in Org:
>
> %[name]{contents}
>
> Would produce in LaTeX, by default:
>
> \name{contents}
>
> in html:
>
> <name>contents></name>
>
> in odt:
>
> <text:span text:style-name=3D"name">contents</text:span>
>
> and so on.
>
> In short, I think it would be enough to simply implement something like
> this.
>
> Best regards,
>
> Juan Manuel