From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ) for ; 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 ) for ; 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 ; 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 ) 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 ) 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 ) 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 ) id 1o30ch-00FaOd-I1; Sun, 19 Jun 2022 21:30:15 +0200 References: <87a6b8pbhg.fsf@posteo.net> <875ykwvmz7.fsf@posteo.net> User-agent: mu4e 1.2.0; emacs 27.2 From: Christian Moe 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." 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=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 contents>, but contents. 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:$2@@@@latex:\$1{$2}@@@@odt:$2@@ #+html_head: 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: > > 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