From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id KD6vKz11GWbF2wAAe85BDQ:P1 (envelope-from ) for ; Fri, 12 Apr 2024 19:54:05 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id KD6vKz11GWbF2wAAe85BDQ (envelope-from ) for ; Fri, 12 Apr 2024 19:54:05 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="FTr/jX4G"; 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=1712944445; 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=t9VL136QN2qqStuMcXrXxsqrE7rYVoUu8N3XSfOag7Q=; b=S763K04+JNEf5dcQ/W55GPKLkIbe6+SgKiv5cEQywbybIaueXK3A2v5Xu0Erl6BIRBwM3B WhURixypn9Qsc+M9H89UP4cv4f/NbONXJMQFYEHPK3VoPKzzhVI0w/N/FCgZyhT27Z4DKt DTiXLFAPVvwqwgaRSzpeX8G+NiYDgjgDo1OvYAzsKu4w8/I4QDcND986v1T3Zy3awApeD3 ZGjIkeZxurS/F1nSmK+Kfia2NpIMzyO+GMKkKCH6ueWKR7qYyoTIrprgritY5yEwkAg0OH HwdclpMkV9nxiX4GcInu4EqK+YlNkW1U3/ChGMHP0tC0mXImFRQkS90xYjcy3w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="FTr/jX4G"; 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=1712944445; a=rsa-sha256; cv=none; b=QyIVJQHJGzdrnzTlrU0uNZbx1N6CDz2XE4ofzm2oWzNBANoQaGSW3aUcnZofTXrSHP6K3t +o/3TBUsJ5oFm0CXc++ZVokhpzlX+zSg/vwxopsBOLreyUBANC0FkFLRHtRx/tBTlTgj8D tfd9nHhXP1mX/oMhRC5kM+g1Sm3RKIg80XnZYugzoTMgpS3cZQBg3PzvMS2e1gDOBovuXS DrDVCbN7fn8K4AOPRPn3Lml22PiUEkNpo395afMNcSct8Kjfz6NGiVthRcI7DnlwoWBXtm cIY2noOrnfV+iLAsve6d2SMlgeCYrSC2C9B6bRgf5WSs9o4GiUAlVBD8xtWF+Q== 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 37CC75E6A for ; Fri, 12 Apr 2024 19:54:05 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rvL5I-0002c0-Ny; Fri, 12 Apr 2024 13:53:08 -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 1rvL5G-0002bc-Pb for emacs-orgmode@gnu.org; Fri, 12 Apr 2024 13:53:06 -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 1rvL5D-0007vE-67 for emacs-orgmode@gnu.org; Fri, 12 Apr 2024 13:53:06 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8C7C1240103 for ; Fri, 12 Apr 2024 19:52:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1712944379; bh=8cE1rHhu9vWe1AoJL9nrhwlpX0g3HabW8RhsB6RzGrA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=FTr/jX4GXr2D3JN+M8FLuvOuUn8a/b7Ky5v3+NaWlZn/eb7hlggqQVxuxhqb+Y7YR q9CW/DI8Lc2xXkRls8BV2wyIxtwLTP6XrhThFY+kKc6zdhKqFVtYtqxqiyR96KUSUs cbvBXRigSDHa+y767Pw5U8f1Mq04xEoanxlPzH4mS6UpMXV/OTZ/+aVxmcIGg9+YpB WFdwgLEnSlzqLE+YIhqKFPmpBos9ta6+Y4RyKxf4UAf6lIf7zM5VgAw8OZ0jpXHhJO YiktnhFje1gcyvfDizOdDuZQo3c9p9qkg5gt3Px4L5b6YUkKn4FhSf5Q5PnnHjuLTT dMjCJ8McW3n8w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VGPL23ydNz6twp; Fri, 12 Apr 2024 19:52:58 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Verbatim content (inline-special-block) In-Reply-To: References: <0f1351e2-cb5e-4b65-9faf-c6e78f15c975@gmail.com> <3ada6078-6c03-447c-9e32-32ca0967cac3@gmail.com> <877ch4ys1a.fsf@localhost> Date: Fri, 12 Apr 2024 17:53:24 +0000 Message-ID: <87r0facvsb.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@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 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: -6.59 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -6.59 X-Migadu-Queue-Id: 37CC75E6A X-TUID: DJKRZELo0uft Max Nikulin writes: >> It may be enough to have @kbd{@code{...}} - it is not like Texinfo has a >> concept of truly verbatim text like in Org. >> >> Alternatively, we may allow two classes of inline markup: >> @foo{parsed *text* inside} >> and >> @foo={verbatim *text* inside}/@foo~{verbatim *text* inside} >> >> This way, instead of @code{}, we should use @code~{...} or even >> @~{...}/@={...} (mnemonics for ~...~ and =...=) > > I consider @foo={}-like variants as unnecessary complications of the > inline special block feature. The idea of composition is better from my > point of view. With this approach it is enough to have non-conflicting > syntax for non-parsed fragments. I am against making @code{} a special > name with suppressed markup parsing. The price of composition in > comparison with @foo={} is more verbose markup. Then, do you have an idea about such syntax? One option I thought of was making @foo{=...=} a special type of boundary delimiting non-parsing contents. However, it is not very elegant IMHO. > By the way, Org has src_lang{...} syntax for almost non-parsed fragments > (neglecting requirement of balanced curly brackets that is an issue). Yes, but it is handled differently by exporters from =verbatim=/~code~. In fact, even the idea with @foo{@code{...}} may be problematic in this regard - @code{...} inside, if we treat it as an equivalent of ~code~, may be problematic if some export backends do something unusual about code markup. > Actually "=" in @foo={} is a kind of special argument distinct from ones > specified inside [] and {}. Yes, but it is much easier to parse. If we use a proper attribute, we run into all kind of issues with how consistent it should be with the parsing rules for other attributes (should it be inherited? may it appear in arbitrary place in [...]?). And if we make it special, we will run in various special cases in the parser... >>> @code{def calculate(@param{expr}, @param{env})} > [...] >> Also, the reason why Texinfo users do @param in @code is the lack of >> automatic syntax highlighting, unlike in Org mode. > > Is ox-texinfo able to convert syntax highlighting to native texinfo markup? No. > So if @markup{} is not allowed in verbatim content then it is another > feature loosely related to custom inline blocks. May you elaborate? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at