From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id oI9IKId64GUOnAAA62LTzQ:P1 (envelope-from ) for ; Thu, 29 Feb 2024 13:37:27 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id oI9IKId64GUOnAAA62LTzQ (envelope-from ) for ; Thu, 29 Feb 2024 13:37:27 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709210247; 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; bh=DtYJrSecXDZTCb7R1EAKjl/gbR5d/cN+6vKHAFx1x2w=; b=JpSFKM6FxT5/kKiM5vqIDxObuk3t9alU7La3dVaTFDw9Mu2q/uNQ/LBWN8tjqhkDvCJLDM wS8rahxvwKMPuI2a3Z9VI0hdLN99nl0LePrVPxmJpdDdiCqU7n8CdXvFBW7TTjEug9utmD jjmcKviCqtjhkN/PcEWcCouFJAvhptXkbZJfgnoFg+0J2K1TS2vjEfygGHMhzWD+BoAOYh GhIkpl9s5Cw4v7oW+T9Yr1b8MONOSGCnX+SjMWLxT1eRnGNK707R2FBGNrbbs5IMnYvdb8 kXuUyX9n4QCQ/OezicEnu8wngLf40NDXHonRZ/pIdAAAb9NXVjJyPWm2gecc2A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=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"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709210247; a=rsa-sha256; cv=none; b=MCHjCnWUgMdARvaqt49V0bw2CFT5AYyymBxkfiNl4pilsltQoEmJPfiJqR1IiZBWdkDTFV Vdfo/+g/qVitSCmTnoov0ZUAwqES8uC4B1c6g4SQQzE6Od+ydbNbrKRqKyJ7eDWIcaEdDF gwGONGpPpOAsJT9wfaOFDBxF7oc7BnMhp3FNs/q1kGko59Gehn663dT5M5scojPDsUSVYQ tM1a+HxZ5n9w/4yKbEBqPdE04aEflldLPirDTgzt2ViKmHUYoX3U4HnLIt3qagx4Hu3K4c dOjbaTITdvqUsyTIRJLzJuO+BHQPQchdmHHmPYA0Lk2olCIKgnTC030w1ejJJg== 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 36E1A763A3 for ; Thu, 29 Feb 2024 13:37:27 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rffAH-0003tx-Hr; Thu, 29 Feb 2024 07:05:29 -0500 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 1rffAE-0003td-KD for emacs-orgmode@gnu.org; Thu, 29 Feb 2024 07:05:26 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rffA9-0000hD-J8 for emacs-orgmode@gnu.org; Thu, 29 Feb 2024 07:05:26 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rffA3-0007YV-QW for emacs-orgmode@gnu.org; Thu, 29 Feb 2024 13:05:15 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [proof of concept] inline language blocks Date: Thu, 29 Feb 2024 19:05:07 +0700 Message-ID: References: <87msrudgcn.fsf@posteo.net> <8734tmmcnv.fsf@localhost> <87edd6ytiy.fsf@posteo.net> <87sf1mrpr6.fsf@localhost> <87a5nuyo4w.fsf@posteo.net> <87frxmrmjb.fsf@localhost> <875xyhzyzl.fsf@posteo.net> <87le7dihaj.fsf@posteo.net> <87h6i1ifp7.fsf@posteo.net> <87wmqoohlr.fsf@posteo.net> <87le74noks.fsf@posteo.net> <87o7bzd02m.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU In-Reply-To: <87o7bzd02m.fsf@posteo.net> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -3.80 X-Spam-Score: -3.80 X-Migadu-Queue-Id: 36E1A763A3 X-TUID: 7/zDi2JCn101 On 29/02/2024 17:41, Juan Manuel Macías wrote: > Max Nikulin writes: >> >> I do not try to dispute \foo and class="foo" as default behavior. I >> suggest to implement possibility to override default behavior of >> &foo{text} to \bar{text} and text. The same is applicable >> for anonymous objects >> >> &_[:latex_command bar :html_element bar]{text} > > Maxim, I insist that I follow the logic of the "large" special blocks. Export of special blocks may be extended as well. > Anyway, I think your example only makes sense in HTML, or at least I > can't make sense of it in LaTeX. Why would anyone want &foo{text} to be > passed to LaTeX as \bar{text}, instead of just &bar{text}? In HTML it > does seem sensible to me that someone would want to change the tags. > Maybe with a :html-tag, or something like that. Consider a document aimed to be exported to different formats. It is unlikely that names of commands, elements, classes, etc. match for all of them. > As for :latex-command, if I understand it correctly, I don't quite see > how useful this could be: > > &foo[:latex-command bar]{text} == LaTeX ==> \bar{text} > > when it is simpler to put: > > &bar{text} Command may require additional arguments and it should be convenient to define shortcuts to the same command with different arguments: &la{text} => \foreignlanguage{latin}{text} &es{text} => \foreinglanguage{spanish}{text} > The same thing happens with the anonymous variant: > > &_[:latex-command foo]{text} == LaTeX ==> \foo{text} > > which is identical to putting &foo{text} > > The anonymous variant would be equivalent in LaTeX to a > \begingroup...\endgroup, or rather to {...}. One could add all the > commands one wants within the group simply with :prelatex: > > &_[:prelatex \foo\bar\vaz\blah{}]{text} > > ==> {\foo\bar\vaz\blah{}text} The idea is to not add \begingroup and \endgroup if LaTeX command is specified (or to control it by a dedicated attribute). Again, consider a document suitable for multiple export formats. I think, flexibility in respect to underlying commands/classes/elements allows to minimize changes in documents later. Sometimes it is necessary to switch to another LaTeX package, CSS framework, etc. It allows usage semantic names within Org documents despite they may be exported to the same command. > In any case, I think that my implementation leaves open the possibility > of extending it with everything you mentioned, or anything else. The question is proper balance of built-in features, flexibility, implementation complexity. It would be unfortunate if most of users will have to create custom backends even for basic documents.