From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id qK/DB3mir2JnDgAAbAwnHQ (envelope-from ) for ; Mon, 20 Jun 2022 00:26:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id uOqWB3mir2I3UAEAauVa8A (envelope-from ) for ; Mon, 20 Jun 2022 00:26:01 +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 8F90B3EF50 for ; Mon, 20 Jun 2022 00:26:00 +0200 (CEST) Received: from localhost ([::1]:44150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o33Ml-0003Bh-LV for larch@yhetil.org; Sun, 19 Jun 2022 18:25:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41498) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o33M7-00035g-0m for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 18:25:19 -0400 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]:44645) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o33M5-0002ND-DK for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 18:25:18 -0400 Received: by mail-pf1-x42a.google.com with SMTP id s37so8662387pfg.11 for ; Sun, 19 Jun 2022 15:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:subject:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=q6h/8eRQsI1qbmmCAzghbUhkYP1a84sXyfmSqH1RXps=; b=bTfHW9GP1FDspv96OdhubLPdtm5YQIM2qOYiYHfBoCEtZ6wLCQEXt7QJ2CCY85pPqK hzxLEbXczWwNrPL0bniz5TvzfUDLkC5zWOk4SgMkVccTk6uwc+tlelncrWxOfsuP+pEx eDB//RpgU0jFA+wo2jIrefPx+i7q/STBmO2MJX3vF2kervozC0oJUA9GXFFmwE0VOY37 +SqKobzBaG8WYDBumsJLTFyu6IKFxP1VaIaVu762CjlhW47Av6Th28yxN8+EEVgPgWG6 jax8bgXPy37DpZo6S6bA6vyT2G++v4vIe5xJJkLjCGPInxRRuGkousD/4x7PAGUvJhvF or3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=q6h/8eRQsI1qbmmCAzghbUhkYP1a84sXyfmSqH1RXps=; b=S9ke1mj5wnaBrBMNJQpOgWvHa8zCxx1bnwDgY/E+47BI8HZ/3G1y/NGTBb/g0n6/cN pWE2yjRVsDdcICVf8T4QFjdM1dEByFIAHeo4bKZSjLWX+CXVxi/dKqR5nR4IboCu3Txj ouH6Or+PaIT7KbqXkCoiCLSBWsM3CB57unqWX4pRMuqb+tBM5XbBxQRXDZfkkbOGHL4t JPwgF5HphEHV4P2NaiYIdE0hl92BHYhf/aH2Tc3Hdf/2GVvO0It4Zv+opWvXHq6ucEh7 bs3Sr6lW78m2R9SZY+xxMSFzzQFXtR7UToayoCiQF+43tffpiMMOod/eRpakZjaunjeK +E9Q== X-Gm-Message-State: AJIora++DtL6SjPfZ4OVF90S5mlNj++3QU9qvKk5HL8MckGpvRgIfkWA NdyzufO4BkbwW2Gh3+0YlgagrwfrG3E= X-Google-Smtp-Source: AGRyM1tlezs7aK6sDhVQr1UinLrARSoK5mZ3GV1qBbiAsvNNV+zafFjCpW65dckFK7JCNwu8wHpfdQ== X-Received: by 2002:a63:cc09:0:b0:3fb:aae7:4964 with SMTP id x9-20020a63cc09000000b003fbaae74964mr18815289pgf.118.1655677515505; Sun, 19 Jun 2022 15:25:15 -0700 (PDT) Received: from dingbat (2001-44b8-31f2-bb00-fe04-6766-d064-4e23.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:fe04:6766:d064:4e23]) by smtp.gmail.com with ESMTPSA id p14-20020a170902e74e00b00163bfaf0b17sm7230118plf.233.2022.06.19.15.25.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 Jun 2022 15:25:15 -0700 (PDT) References: <87a6b8pbhg.fsf@posteo.net> <875ykwvmz7.fsf@posteo.net> User-agent: mu4e 1.7.28; emacs 28.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: About 'inline special blocks' Date: Mon, 20 Jun 2022 08:18:53 +1000 In-reply-to: <875ykwvmz7.fsf@posteo.net> Message-ID: <87pmj4nvec.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::42a; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=1655677560; 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=q6h/8eRQsI1qbmmCAzghbUhkYP1a84sXyfmSqH1RXps=; b=qbPzUUvv04J98A1xEfUIKz79cOcyEtfFAaJGIGvMK6p3d/R2zxuKANK47YY+MXjAXxiON9 cC5hwhYuQDUwX/yodhyoyoArovysQ3wMkoJNYpSH07hXWZ9T/GFgGOGcLr1zXrqmWgUzlC Ho4zQmfzvU2u6GAbbIIKXOQxa+gEhPQXwVthjuNJfr3WjgPPwJ54EIrk1L/5WLGjdFcZFM yE/uysqxiK9fv04XET1bUY65SrFIxlf5ZpVSrzc5jbt4TRdegFzxa4L+RdDFE9o5a8NnWc vlTSC9g5I5y/AWIZGgqz3XfGkFM3spTEDnTKODMXRLcSaojUMHXV1G/lDcX4LQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655677560; a=rsa-sha256; cv=none; b=tPaX6UJghN80FTgLbq2QxKsEtzGuR6byT4Yi2lSDr1lPPOK7zsTRu8wSN9rFs3LXI/aQ+Z +nl7SjQ2iuyvgK8edSEdjpx9mnmod1/ddj4CSn2BmvE/t9RKZUPu7ZjAs5AsuCQVk2Olwl zwA0gzm9h/9pJZPxAB23/bLZ8lmCA3C7u04znc6AXTwRXK1qF2zzSWxt1cqHgHDt0gpO90 eEJqXNwRV3W+8kWQ9azM8+2dwq42NRPnnL6/KJyD1wRNHIETlehHUMke/lATeebgM/xsdp mTTf1MqWStWaVLInjZvfqd9JbI9IlXMnd6mh/MFdahzGOrb815IvJqCC/xLlxw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=bTfHW9GP; dmarc=pass (policy=none) header.from=gmail.com; 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: -7.48 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=bTfHW9GP; dmarc=pass (policy=none) header.from=gmail.com; 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: 8F90B3EF50 X-Spam-Score: -7.48 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5NEEHe9fp5Q7 Juan Manuel Mac=C3=ADas writes: > 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. > Agree. I think your reasoning here is spot on.=20 > 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. > Agreed. In fact, I use in-line blocks so rarely that at first I wasn't going to respond as I really didn't have much skin in the game when it comes to inline blocks. The reason I dond't use them much is pretty much the same as your reasoning above. > 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. > I also like this approach. We need some form of escape hatch. However, for uncommon edge cases, I would rather have a slightly less convenient escape hatch and a simple consistent general syntax than a more complex syntax which is difficult to maintain and keep consistent and reliable.=20 > Starting from that, a syntax like this in Org: > > %[name]{contents} > > Would produce in LaTeX, by default: > > \name{contents} > > in html: > > contents> or should that be contents? > > in odt: > > contents > > and so on. > > In short, I think it would be enough to simply implement something like > this. > Sound reasoning IMO.=20