From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 wJzZIykbr2JcHAEAbAwnHQ (envelope-from ) for ; Sun, 19 Jun 2022 14:48:41 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YEqWIykbr2LBAAEAauVa8A (envelope-from ) for ; Sun, 19 Jun 2022 14:48:41 +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 13109117C0 for ; Sun, 19 Jun 2022 14:48:41 +0200 (CEST) Received: from localhost ([::1]:36372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2uM3-0007JZ-Fz for larch@yhetil.org; Sun, 19 Jun 2022 08:48:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2uLF-0007JR-8K for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 08:47:49 -0400 Received: from mout02.posteo.de ([185.67.36.66]:34951) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2uLD-0007Xo-Aa for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 08:47:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 04978240107 for ; Sun, 19 Jun 2022 14:47:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1655642864; bh=em9XG3lGqWXcWuzqlqbQ1mnXWMbB+wHqbZecgixqJGk=; h=From:To:Subject:Date:From; b=A7XsYPrsPc7cc0oheNSXnyrVBo8pmk7bvQ0Q7qBSZsdw11TQ9UK+Ai3byXi/eynTL 3fDBMxeB1qpuZen/R2aCNM1K6Sk/x0AHTDVYnrLbctd0DINCOYBCgAVEcODcCAau6A 8chHLa3O0EUZu3Lka1rqU6n246GH8glX3EHH2s5Y1N1BcXFkpqNOfwNii0oPU43Pf8 EwTvbXUaRJGugfU0U4vBT8yQfXiUHQze36ssULYIit2HQqghptKmj81G72CbIE45l8 kr8pJYPs6p9Cuf6TaN1TS1c20YkdjdZw0pCsjRHIoeD5UiTGWRtuKFxX8X13eW+Jha Ns397XdIDvYIA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LQsxq2pfZz6tmG for ; Sun, 19 Jun 2022 14:47:43 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: orgmode Subject: Re: About 'inline special blocks' References: <87a6b8pbhg.fsf@posteo.net> Date: Sun, 19 Jun 2022 12:47:40 +0000 In-Reply-To: (Kaushal Modi's message of "Mon, 23 May 2022 11:20:08 -0400") Message-ID: <875ykwvmz7.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" 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=1655642921; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=s8Z2LnD5LmrYwLFYRlNJVf/OT77FT7JvjBhvEI9WLDQ=; b=g0g1nv5LVvBeJofgzsmiKONjR8PKOBIjWY6LyCTAx+9sD8zJKxL1ZFolFPg5RZn0vJ1UaZ BEHYThml1xGxXjhx8SIrazUJ5lbummsp9cREWucxblIgmQnmu0se4g+RnXizmMh2lSDxEa RreW73pLDKx00KlPl2PG/e+JtpZaINeQWPp+LyIfVaFuK/7/xE1qyar2708TqARRy/TPkg oXmv6Kwuomq+DUCVPRMVHIxzwdSPZdueGgajfawCSWVR7ld7VK8iXYI8ZrRA5DcY99nu3n hzISJaM6beU2JAsvOJrA56W0XoveDXJUY8Huji/pZaGXi1rPmy3oKRHpM2ZC+A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655642921; a=rsa-sha256; cv=none; b=fKHI1yC/ONqgggUR4l3sAnv7eK+srZqoeVrkNXcOV0gEZyMWHD17eMu3db9BrWoFx0rc7W VXfPBw4eDHSiJrIYB5E+XMx8N9oQAJw1asoGgsALA468GhlScg6GUrRa5n/WluvKX9YVEZ +CjVgodDE9uQJFsS0D97CjvRGf3AUExA6GSS2Lbh1Kx2QhCz3DA8WCIQ6LDYJ1SXiC8IQ0 xxLi/BlU76RMx7rWd7HLE4Iy0csNcC6L0vpgVcNLOrQOAYjhlGB1YR7L3dDNFx34eq3Af8 PObd9RX8bMYpAUedjX1nvkqUnm5jKygZABMSfHYM/alID53/M7M5FUguzewgfg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A7XsYPrs; dmarc=pass (policy=none) header.from=posteo.net; 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.69 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A7XsYPrs; dmarc=pass (policy=none) header.from=posteo.net; 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: 13109117C0 X-Spam-Score: -2.69 X-Migadu-Scanner: scn1.migadu.com X-TUID: ojWKClP8I5mV To add some ideas that have been occurring to me these days... 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: contents> in odt: contents and so on. In short, I think it would be enough to simply implement something like this. Best regards, Juan Manuel