From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id OBp4F6gL/GXY7AAA62LTzQ:P1 (envelope-from ) for ; Thu, 21 Mar 2024 11:27:52 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id OBp4F6gL/GXY7AAA62LTzQ (envelope-from ) for ; Thu, 21 Mar 2024 11:27:52 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=bh0qcHoE; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711016872; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=jspOecmDrb7E6NjoPLtRipYLpu9vxUgdn/sllWuQFSE=; b=uXrUQ75U/dZ8INgPyJxtpoPFPr5ma7sJXgaEXa5hnBoww55Um3h7YdV8yMjCsJZk00cQdd 4Xe2dlsbjttjVf1DNeYgYe/BEpD5Dy1/jHGrGDIOYlGVVLNZqFwzevUJnsQf618cOGnze/ /WvZc7fVMkDm36MZvhBuwpo4ikBxaH2eJFKSeLsZkIbe+8JRTS/S/LTPFdQQeAG+OEzWg0 fGVH+fSN976vhpiNLe9bNOtDIdzFoMIGAsnk2YWlifu9IGAHj68CBnIpvIreHvOI6YZNbf Ri7yAWR5jjbX3Txeg43V0eWTHUZVaFSnAw8+8mStSpn/qidEm5xMq+SoR4SCIQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=bh0qcHoE; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711016872; a=rsa-sha256; cv=none; b=ZJlPJ+WxLTVS2tCJ9IgkAlDmtyEZz4Q+vzgRYXPIFs5/uh815jcsNHsoFg/4bj/PuCjEIr pXgeG3bHLW+6OF/FPP3PtuhF7v/5yENK7JMpJoRZUCEd+s50vOsKO0iTnkXr2rUl7Hw/L2 MtC49MwjE+DNi4pn9AtUP6Ssgzsa/h5k0g8iW/0y1sEARGl7nG3OBCI1nrEkQ8iOWDXsRQ eJSCgDm3MEmVHCTHFlx2LwekQeGhI8kjXx8PMy2JKoB9bR9d5CZjL2pmTWjM4QQljVqRLN b+HHx7OnfPdOM3nJ2tFk2kej8KCDylH7DnF0rsU7vSsIzZg2i9UFQwpDpZvbPg== 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 1F67313456 for ; Thu, 21 Mar 2024 11:27:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rnFdg-0003gY-24; Thu, 21 Mar 2024 06:27:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnFdd-0003fg-Ue for emacs-orgmode@gnu.org; Thu, 21 Mar 2024 06:27:10 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rnFdc-0003ON-06 for emacs-orgmode@gnu.org; Thu, 21 Mar 2024 06:27:09 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A21F9240105 for ; Thu, 21 Mar 2024 11:26:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1711016819; bh=I9E2ABcod+6rFJEzl7LdthvMt3PeieSXVDaQ4OhPtx8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=bh0qcHoENST7qA89Olma8ZC9Ozz+Ee5m80+Bt60F6FlEC012gAfzHePWQ8+kD1mF4 cdt9pIJJ2eMLlrP4ZBApUogRJqz5vaGzW81vlBwD4uU+Z9h6KI3WGH7pk1ZXGcimzh v6zpUh9hsWoNddVSrWdo+arEM9XbliTzBMTB5l+VT9Zq/DExj7mJWp8hpodarYxRId vwzI3ks1NjSaVrh1lfSAC6QjkyMwphwjTESI/z28PRzIUN90U7IfJMKjL7jbe9+HQN 8MyWJRP/oqdVdrkp3juufQZIo/39ey4KQM93N1LMfgkjNZvA3LNzoAPkOwPFtyq/29 8yS65t6LADeYQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4V0hTZ6mfvz6twS; Thu, 21 Mar 2024 11:26:58 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: inline-special-block: export rules (was: `:export' attribute?: Re: Experimental public branch for inline special blocks) In-Reply-To: (Max Nikulin's message of "Tue, 19 Mar 2024 21:54:12 +0700") References: <87wmql6690.fsf@posteo.net> <87cysb2h68.fsf@posteo.net> <877ciavnwo.fsf_-_@posteo.net> <87bk7k7tuf.fsf@posteo.net> <87wmq85xn9.fsf@posteo.net> <877ci7bm2b.fsf@posteo.net> <87y1an9wkj.fsf@posteo.net> <87il1qm61y.fsf@posteo.net> <87edcem4rw.fsf@posteo.net> <87wmq4me2k.fsf@posteo.net> <875xxn4g2g.fsf@posteo.net> <87r0g7qqcg.fsf@posteo.net> Date: Thu, 21 Mar 2024 10:26:56 +0000 Message-ID: <877chvvq1b.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_H4=0.001, RCVD_IN_MSPIKE_WL=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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -7.02 X-Spam-Score: -7.02 X-Migadu-Queue-Id: 1F67313456 X-Migadu-Scanner: mx12.migadu.com X-TUID: +4JG2G9SEkg5 Max Nikulin writes: > I am afraid that :export will cause confusion with :exports for source > code blocks. Its name differs by just "s" but possible values have > nothing common. I agree. At the moment two alternative names come to mind: :backends or :export-rules > Another issue is more general and should apply e.g. to HTML attributes > as well. Consider > > --- 8< --- > > #+options: inline-special-block-aliases:(("kbd" :export "html*" > :html-tag kbd)) > > @kbd{Default} and @kbd[:export "latex*"]{LaTeX} > --- >8 --- > > It exports to > >

\nDefault and LaTeX

> > I would expect that "html*" is inherited from the parent declaration and > "latex*" does not override it, so > >

\nDefault and LaTeX

But it is the expected result in all attributes. If an attribute of the same type as the one declared in the alias is added, the value is overwritten. In any case, since in this case the attribute allows cumulative values, I think the approach should be at the level of the attribute name itself and not the code to manage the export rules. For example: :export [or whatever new name we give it] ==> normal behavior, overwrites the values :export+ ==> adds the new values to the values defined in the alias This syntax could also be extended to other cases. Perhaps we want attributes like :prelatex, :postlatex, or :html to support accumulating values. It could be easily solved from the functions of each backend. In other cases, of course, it wouldn't make sense (a block can't have two languages at the same time), but in that scenario, if someone puts :lang+, it simply wouldn't be taken into account. Wdyt?