From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id EB5KKKveF2aC8gAAqHPOHw:P1 (envelope-from ) for ; Thu, 11 Apr 2024 14:59:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id EB5KKKveF2aC8gAAqHPOHw (envelope-from ) for ; Thu, 11 Apr 2024 14:59:23 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=dQn9LRAC; 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=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1712840363; 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=KXddXBCrXn0Pg2wiUKf9DQLaxArYZGHqfSrjY5HlIPc=; b=GLVmPNmTr1FaxYlds7VnU/AD5+e9gdts2bfnT+LK5PvIPdO3x2+X0tn2owdf2G7QzkEi4H ILTxjxe6uETbSHl1/fTY6QIGY+zRqVqdm6kUgw9gpRtHqM8vMbdyzuj8LLUhxzSaQi7KN7 lsMSNgSjY4VXmAtMcEpTqOjXCj7r1zgGRRDd4yQNFq3vWivrtra46sVp0oyOso8mGXBi4V oMct0sZQI52Hryxai0jBgFjdneGGSNBxSJTxOAMLjkFv4gRCuUcKFQc7Lo+jUS8DYLJRcL b5gBZhjhcWHh2a1jB3kH40XdjpWPxc6/IHWmkaaCuLw5Wjy+pyJxTC/f/u+Pew== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1712840363; a=rsa-sha256; cv=none; b=EGh4O9LWjX8W1nXevGRQ4Zy58LAwY8Z8nnK4cmmks4H2FSfrDEEB6KwTRAlZYJbVhyJDLb uRTRIOVcGnQaQvCUcNHSkk0W8sHHfSrq+bi+iL5W5s6owzvuzi2Wd3bZBtSu+sw2kmkAub bzByd5e59pydZdcYjAK7SlCDg11wbP2cKLkVXRpRvCNLBRxXOnFo9mVGW+xXLVAsyssuyJ aWlxzI9vQxJgGfi423ZrNUaj3Bh0dilAql6t0z+1U+jFToYa4tCcXQK50IjiEpSFJQElJW 8lrRRl1vdUP3TJ0YBkTxxI89lKQPckjLMT9m3xf/r48EyvCwWiSzLkYeXAbnQw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=dQn9LRAC; 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=pass (policy=none) header.from=posteo.net 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 72AD66DC9F for ; Thu, 11 Apr 2024 14:59:23 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ruu0k-0002H9-66; Thu, 11 Apr 2024 08:58:38 -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 1ruu0i-0002Gj-43 for emacs-orgmode@gnu.org; Thu, 11 Apr 2024 08:58:36 -0400 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 1ruu0f-0008P8-Ld for emacs-orgmode@gnu.org; Thu, 11 Apr 2024 08:58:35 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 73850240027 for ; Thu, 11 Apr 2024 14:58:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1712840311; bh=5vN40qmB1yc4JdGmY3CBu8tfpJJ1zNClbQ9+dY3DvIc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=dQn9LRACIvtB2sd4FrgpqcvW5/qQ8mcQJmXG+/IUbbqUDU+JQZmMridRbraTJUYcF IyKm2G54adbS32wPMRCPze/oEHpDJPk/i7zNyr0ejmbEIAOrOKpi/p0BodaVGlokkS UcyHevHrOh3l5r2kANesImTWbqwDAfxEGGYamd1J7Q7mQXXDhOiE/rMYnUfiuzA7KZ hjMrqcowA4tXpqKe4ERGVc29BOissA3zjtD7HqgBjqedwUxkCAk5rIcYQF0OCwkjkD APJAF7d7EV07dzTDT+INyyw/tPg1WLIulvRP9J9doKiytlLGWyBj97QWQqO+vjatia /5VEFm5c7L6aQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VFfrk2WkJz9rxD; Thu, 11 Apr 2024 14:58:30 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Verbatim content (inline-special-block) In-Reply-To: <3ada6078-6c03-447c-9e32-32ca0967cac3@gmail.com> References: <0f1351e2-cb5e-4b65-9faf-c6e78f15c975@gmail.com> <3ada6078-6c03-447c-9e32-32ca0967cac3@gmail.com> Date: Thu, 11 Apr 2024 12:58:57 +0000 Message-ID: <877ch4ys1a.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@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 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: -9.58 X-Spam-Score: -9.58 X-Migadu-Queue-Id: 72AD66DC9F X-Migadu-Scanner: mx13.migadu.com X-TUID: 2w4/8SD3QwZ5 Max Nikulin writes: >> - We should be able to define special markup for code, where the >> contents is not parsed. Something like >> >> @code{ unlike =code=, we can have leading and trailing spaces } >> @code{ @foo{is not interpreted inside}} > > I think, it should be controlled by some optional parameter like > > @kbd[:verbatim t]{ unlike =code=, ... } I do not like this idea - this will make the attribute list a part of the Org markup spec, which I would like to avoid if possible: 1. External parsers would be forced to understand the attribute syntax, which will complicate Org markup spec. 2. Our own parser may have to account for attribute inheritance while parsing, which will complicate the parser too much. The question remains how to define custom verbatim markup, of course. 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 =...=) > Certainly parsing of normal Org markup should be suppressed, > however I am less sure concerning @markup{}. In the following example > text inside @param{} may be emphasized: > > @code{def calculate(@param{expr}, @param{env})} > > "@" inside such object may be escaped as @{@}. An alternatively is a > parameter like :parse that can have values like "markup", "custom", > "verbatim". This case "verbatim" disabled parsing of @objects(). AFAIU, you are referring to how Texinfo handles its @code{...} command, where other texinfo commands are allowed, which is _conceptually_ different from how Org handles the verbatim/code - as a general rule, all the "code" in Org mode syntax is taken verbatim (with the only exception of src blocks where we have no choice). Also, the reason why Texinfo users do @param in @code is the lack of automatic syntax highlighting, unlike in Org mode. I think that Org mode's equivalent of Texinfo @code should be either 1. inline src block 2. if direct markup is unavoidable, use something like @fixedwidth{@code{def calculate(}@param{expr}@code{, }@param{env}@code{)}} Most of the @code{..} can be safely dropped. It is just to illustrate the idea that we still parse the contents. In practice, things like *def* calculate(expr, env) "foo\alpha" will become @fixedwidth{*def@code{*} calculate(@param{expr}, @param{env}) "foo@code{\}alpha"} or @fixedwidth{\star{}def* calculate(@param{expr}, @param{env}) "foo\@@{}alpha"} -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at