From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id mC4TEh3F32Wo2QAAe85BDQ:P1 (envelope-from ) for ; Thu, 29 Feb 2024 00:43:25 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id mC4TEh3F32Wo2QAAe85BDQ (envelope-from ) for ; Thu, 29 Feb 2024 00:43:25 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Qv3oHEKJ; 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=1709163805; 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=C9YYBrQPt1xPydFk1aEdtfZ0F6IFQJSBfcQzevMH5u8=; b=uyD7Cv3CiJDNJjNH816DPulv4v2cMlWoLgTBtfCbVmMmGVWIHNY0jpbXzy5rPEXjT4ZhJ1 LHTnVnm7JBacUQqn0QwCgVs57TBmAfsDSe6/h0bUrwSZPu+rziITD4ogoCIiEeuuxHCVnT kX/tdji8NDQi3q2sG4WAJjS84cyMNxcwRQu8GFYYjexH/GDVvaYRXilPv2YawkYrZVFe2r dN9lTgGGC8ixtdwA7Zo02DKDWzA/0fAcRptat9T9u1K7p0GpGvprD97LVu+KxL6Qc9DmjE QmAUQ6fzqpgvjOYZRPXQE2o5XGB5CcsTP3PSqdztxTN+qG5vy2y3nzFgT7pBTw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Qv3oHEKJ; 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=1709163805; a=rsa-sha256; cv=none; b=ZXPFdbUNBEjAgd/5pzlU6Qei3z0CJQVoa52JAWmE4NZordWtYQu3kX3I1sPi4uWC7ix2G4 0IEAP/Ac61yTTD4rrBnwiRlFgh35ei0XMk1sMoW4WWd3aW+C3EQ2Z67MKdwVmRjYYkeriH FvLGeuNQWfrdVD1tIn3zuzrgRai/VKmJ1NFOZGwK6GqSUmXUOAnJJR5vnikckan7wRHX9f cF9hx9Drk7GZp5H8j77H8KgMH6J8RXJFj40vUNPEnuzpoHjRk7DbIUTq+J/O5urCJeDLN+ /TkuWyXIMaI4Ee8+s0kb5CXFPnyiatVInvh2kaOs1PiT/uwf/btwJXmv1ADDLA== 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 067AD44D8C for ; Thu, 29 Feb 2024 00:43:25 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rfTZ9-0006xd-Kg; Wed, 28 Feb 2024 18:42:23 -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 1rfTZ6-0006xP-8b for emacs-orgmode@gnu.org; Wed, 28 Feb 2024 18:42:20 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rfTZ3-0008LP-K2 for emacs-orgmode@gnu.org; Wed, 28 Feb 2024 18:42:19 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2B06F240027 for ; Thu, 29 Feb 2024 00:42:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1709163734; bh=+SUxwnCyYOxnY4onPebpIk64VZ7YsrRVQjxwlGIqwi4=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:From; b=Qv3oHEKJ3CHgPDnd16z+F2EzzYxd4uYgxGApLMszf2TFfio8lpuYDXXJ7LLg/Fqct BNSLJ/zqipu6pvqeHFHF/Cm0VZEY85y/vzIMPi6Qai/HkDDeqUDw0FvKcszioYXYLI KPvDUVq2aBzD+qYrzhMR4lyDiUji3eMP+Cxwn4bdQVt4jctzkWxCBaEciEU/EUcEsr GGpzZ7cuD8GJoWghHtDpof4i0zoXdPdDI1vLa2OHx5cX2GdiFmKCgvdM7++D/bPAlt c0LSe76iTRhpEVndRAQ0fIQMGzTQGw3qH0y0xXEk0arYF5soE7fOyhrDTCuTLYt9yD MNKZgsY0Du5Ug== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TlW9K4Rlyz6tvq for ; Thu, 29 Feb 2024 00:42:13 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: orgmode Subject: Re: [proof of concept] inline language blocks In-Reply-To: (Max Nikulin's message of "Thu, 29 Feb 2024 00:21:37 +0700") 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> Date: Wed, 28 Feb 2024 23:42:11 +0000 Message-ID: <87le74noks.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@posteo.net; helo=mout01.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_H3=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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.98 X-Spam-Score: -9.98 X-Migadu-Queue-Id: 067AD44D8C X-Migadu-Scanner: mx13.migadu.com X-TUID: GfJ4d/cPr+vb Max Nikulin writes: > #+options: custom-object(:type la :latex_element foreignlanguage > :latex_pre "{latin}") mmm, I see it as not very flexible and perhaps too complicated for the user. My idea with the concept of inline-special-block is that it is like the inline version of its older brother. If something like #+begin_foo ... #+end_foo produces things like \begin{foo} ... \end{foo} or
...
the user should expect something like &foo{...} to produce \foo{...} or ..., etc. The only difference is that there would be an anonymous variant &_{...}. The attributes syntax (in square brackets) adds verbosity, but I understand that it is also very flexible and granular. It doesn't need to be used always, but at least it's there when you need to use it. Furthermore, the user can always define lists of attributes (styles or aliases: I would have preferred the term "style", instead of "alias", but I fear that it will be confused with the HTML attribute of the same name). Furthermore, these lists of attributes can also be used in combination with other single attributes, giving rise to a great possibility of combinations. The fact that there are a number of universal attributes such as :lang, :color, :smallcaps prevents the user from having to figure out which code to use on each backend to produce colored text, small caps or the correct language selector. ":lang ru", for example, will always produce in LaTeX \foreignlanguage{russian}{} (which, in addition, is a command shared by babel and polyglossia) and in HTML lang="ru". And ultimately you could also think about some kind of folding for the attributes part. I believe that this possible new element would solve the need for a native, multipurpose inline text container with properties[1], which until now could only be achieved through macros or links, with the limitations of both elements. Additionally, I think this approach is more flexible than having specific purpose blocks (for languages, colors, etc.). Of course, it would be best not to abuse the attributes. If in a long document one needs to put a single sentence in red, I don't think it is a verbosity problem to put something like &_[:color red]{lorem ipsum dolor}. If you need to put a lot of sentences in red or any other color, it may be a better idea to define some command in LaTeX (\redtext), a class in HTML or a character style in odt. And then it would be enough to use &redtext{lorem ipsum dolor}. [1] Pandoc has the "bracketed spans". According to pandoc manual: #+begin_quote A bracketed sequence of inlines, as one would use to begin a link, will be treated as a Span with attributes if it is followed immediately by attributes: [This is *some text*]{.class key="val"} #+end_quote