From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp10.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms5.migadu.com with LMTPS
	id mEgaHvXU5GI1JwAAbAwnHQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sat, 30 Jul 2022 08:51:33 +0200
Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp10.migadu.com with LMTPS
	id MAj2HPXU5GKvEgEAG6o9tA
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Sat, 30 Jul 2022 08:51:33 +0200
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 05F1410D62
	for <larch@yhetil.org>; Sat, 30 Jul 2022 08:51:33 +0200 (CEST)
Received: from localhost ([::1]:33276 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	id 1oHgJw-0005kK-1Z
	for larch@yhetil.org; Sat, 30 Jul 2022 02:51:32 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35468)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <yantar92@gmail.com>)
 id 1oHgH8-0005iy-Am
 for emacs-orgmode@gnu.org; Sat, 30 Jul 2022 02:48:43 -0400
Received: from mail-pf1-x433.google.com ([2607:f8b0:4864:20::433]:46786)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <yantar92@gmail.com>)
 id 1oHgH6-0000Ns-3Q
 for emacs-orgmode@gnu.org; Sat, 30 Jul 2022 02:48:37 -0400
Received: by mail-pf1-x433.google.com with SMTP id c3so6321648pfb.13
 for <emacs-orgmode@gnu.org>; Fri, 29 Jul 2022 23:48:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=from:to:cc:subject:in-reply-to:references:date:message-id
 :mime-version; bh=7Cufhu7b7d/BH1biEqYRojz6BhQbu0SLQhx19/66arE=;
 b=hHscArunFjcv0UyveMaPI/CjYK3nV5QVv7rLkgcK1evWfR8jtEQDFLWy2YrTxRZq4o
 URCMOq+qB+gKlgkz6pVLVczE8W82JOq3Z5C8H6Fu3zztPy+z6jcWzEEy3Jx4eKB9K04R
 wlsAtTl+3lgLCx1tve6D2dJpWSk7JSMdbXQELkckXsWZ8Fgk5Wl06bkvMiievQ+zPIF0
 nyUxN91tBwLvpe4egarodbBTsjJ/ulbxtXTNqJ0mG0HodhrJS59TUqg2rM3hjZsdpSIp
 lV+m8GmLdGVQwc2s1YRX60agpWOnZ8gQfB1Zxqb9a9qCH6SRwjvhrVfuWyFF62XS2SH5
 GITQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
 :message-id:mime-version;
 bh=7Cufhu7b7d/BH1biEqYRojz6BhQbu0SLQhx19/66arE=;
 b=CYkV7jktTEvdeVcPj9dKAqJ4EaY0hWHAb+NU9fPcXmn4Pr1sobV/ZwhvQ0rOUpkV0y
 Fxpx4b3x1uo3Z774ODzHBUFsYVkVRZF+sTf53eF4RkvkxyXNi5+r1EhSoWXMJXcqEHjO
 GwJgIncgX2IFPzbJziuwnySEyh+n+OigHUL0a+AAyd7vMhXgwtE0vRaxkFkM+r9CgEbA
 AaYwM56X9YhSvLIE/SpAiDuq8th/cSn7Mll2A8RN6Tdk5btxDPwyF1aAwx/EtHCvGMB4
 MqZTnBT18N0W7XyJsRjnfahu/vw581tf3xHounIB50wCb1Ampz1Yl2zncVQS2eqnNAwL
 6x1A==
X-Gm-Message-State: AJIora/ETbo5XMFBLEBmqFdS6FukeQ4C+v/oRaQRFTIJPSQDos7+t+Yt
 SjTe3xMzny0/qnMhggCsJyo=
X-Google-Smtp-Source: AGRyM1s/z5ZNQg6PrNvh77kRsZ9B8rH/YlzeUgHezeMQmnC5P97vwHWAfY2G7HfCwxlKWLdynWhXKg==
X-Received: by 2002:a63:6908:0:b0:41a:3c2:622b with SMTP id
 e8-20020a636908000000b0041a03c2622bmr5529489pgc.304.1659163714517; 
 Fri, 29 Jul 2022 23:48:34 -0700 (PDT)
Received: from localhost ([1.83.155.1]) by smtp.gmail.com with ESMTPSA id
 m17-20020a170902db1100b0016ec8286733sm1257212plx.243.2022.07.29.23.48.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 29 Jul 2022 23:48:33 -0700 (PDT)
From: Ihor Radchenko <yantar92@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: Max Nikulin <manikulin@gmail.com>,  emacs-orgmode@gnu.org
Subject: Re: [PATCH v2] Add new entity \-- serving as markup
 separator/escape symbol
In-Reply-To: <CAJcAo8s6k=BYCdSiKhdR5uOTxw9FE1N6XCp1JGEnuzkFhSpYcw@mail.gmail.com>
References: <BY5PR10MB4289167298649297E045360996959@BY5PR10MB4289.namprd10.prod.outlook.com>
 <87r128d5pp.fsf@localhost> <tbnj6u$11sv$1@ciao.gmane.io>
 <80f0990042a564556cc6b047a94f7e9dddf5a280.camel@outlook.com>
 <87v8rkav2x.fsf@localhost> <87mtct9y1f.fsf@localhost>
 <tbua9i$hg4$1@ciao.gmane.io> <87mtcsn173.fsf@localhost>
 <tbvhuk$pt3$1@ciao.gmane.io> <878rocmgoi.fsf@localhost>
 <CAJcAo8s6k=BYCdSiKhdR5uOTxw9FE1N6XCp1JGEnuzkFhSpYcw@mail.gmail.com>
Date: Sat, 30 Jul 2022 14:49:35 +0800
Message-ID: <875yjft7r4.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2607:f8b0:4864:20::433;
 envelope-from=yantar92@gmail.com; helo=mail-pf1-x433.google.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 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,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, 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." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: "Emacs-orgmode" <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
X-Migadu-Flow: FLOW_IN
X-Migadu-To: larch@yhetil.org
X-Migadu-Country: US
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1659163893;
	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=7Cufhu7b7d/BH1biEqYRojz6BhQbu0SLQhx19/66arE=;
	b=MSGV50DO4C1RpnBzF/n2Il5+jHQmv2yVQfoS+aFu8EYVGo87ZjIrt/sTNZL6ySBheJfFPV
	YbePAZYrQgF2JNYYjucRlEwJyvn323i4/TFXq0mkyL2pExDbuV0gK2IKb1xPy1o7pjlWh5
	+TxPojinrbUDk8vOqH1Ai3Xh17m3lFqImsTc5e+rl+QVX3+s21Sy8DbWrXjtQ3P9aYGfkO
	U0ZDtfjplyjZt6WQl+f7W2cYAVOYKM7fR8ClqUYltVf6P62r1q8S3M6TDqzFvytNi11Wzo
	9Z1LkOMsQFSFw7QnkREjZnlL8flP+pvEv7hF+vQOAOCGxQnLGa65U+sRfmWXpA==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659163893; a=rsa-sha256; cv=none;
	b=qW2wujWxMf8YSRCluBPyj2r8JNEe7Z+DZwXINkVCRLEyjzQuwr1ZmlH6KlDkzLH04Ja4X2
	NLh+h+Q1OwHepX0X+uQiMfAHh7jfxOliekwQUIHVjRVylbvdauqIAG6yMol2a8spCfloqa
	i4Xpv44GKsbtZ9eIxTrgZ1FKfTUC1wVWkEq7HJXAS8VBLQDMQgYkWueTkWAUaltKlf8h5T
	jZFRZ9F+p2fREec4IhOzwFPowehDGPl0e256/AgrEScgKjfVSLFXyx6ZFopuy3fXqGiTvA
	RLr9vsvBJ92ovA978f1tqueooFLWUjtL4df2XoHxgSk5C9JKaI2fgx43+If9Xg==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=hHscArun;
	dmarc=pass (policy=none) header.from=gmail.com;
	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"
X-Migadu-Spam-Score: -3.43
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=gmail.com header.s=20210112 header.b=hHscArun;
	dmarc=pass (policy=none) header.from=gmail.com;
	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"
X-Migadu-Queue-Id: 05F1410D62
X-Spam-Score: -3.43
X-Migadu-Scanner: scn1.migadu.com
X-TUID: aVPmGRrece1E

Samuel Wales <samologist@gmail.com> writes:

> i am not in a position to judge \-- but i like the idea of not having
> zws be used, and expect you have thought it out.
>
>
> just an idea: something approximately like this might work, or
> something like john kitchen's poc implementation of it might.  this is
> called extensible syntax.  one of the goals of es is to reduce the
> proliferation of org syntax and other stuff.
>
> es was proposed long ago, but i was unable to sufficiently follow up
> for unrelated reasons.  i have lots of replies and lots of further
> work on it but that's neither here nor there in this case.
>
> [other stuff includes but is not limited to increase reusability and
> reliability of code to implement things you want to do with syntax
> such as whether to show it, add a subfeature, export it variantly in
> different exporters, escape it, quote it, pretty-print it, etc.; allow
> user to do this so org is not burdened by it; etc.  terms to look up
> in the mailing list archives include extensible syntax, parsing risk,
> and id markers.]
>
>   $[emphasis :position beg :type bold :display "*"]bold text$[emphasis
> :position end :type bold :display "*"]

This is similar to another recent idea about inline special blocks.
Among other things, we discussed supplying parameters to such inline
special blocks. This suggestion is essentially equivalent, except you
give a slightly different syntax.

> alternatively:
>
>   $()...
>
> other than the basics, such as sexp, i do NOT care about the details
> of the $[] low level syntax in general OR the arglist details in this
> particular case.  those can change according to consensus or
> implementation needs etc.  instead, it is getting the concept across
> that matters to me.  one key thing about es is that when we want a new
> feature, we do not need new org syntax for that new feature.  OR for
> new subfeatures.  we just do something like this:
>
>   $[extended-timestamp :whatever yes :displays-as interval]
>
> or whatever.  this has nothing to do with bold emphasis.  it is an
> unrelated feature, using the same outer syntax.  another completely
> unrelated feature i'd strongly like, for emacs in general, is id
> markers.  that too can be done with this syntax.

I feel like generalizing syntax to arbitrary inline object types is a
bit too much **at this point of time**. Yes, we can do this, but a lot
of places in Org codebase depend on the existing syntax. It is not easy
to extend, for example, the code dealing with timestamps, to work with
arbitrary timestamp-like objects. Too many things are hard-coded -
changing them will be a humongous amount of work.

> merely saying that once implemented, could solve this problem and ALSO
> later problems.  in fact, we discussed coloring of text using this
> syntax.  although with various understandings of it.  that's kinda
> similar to emphasis.

Colouring was also one of the things I thought of when discussing inline
special blocks. Also, authored comments where we need to keep the author
metadata.

> i am not doing well so i am unlikely to be able to respond much or at
> all to queries.  please take it easy on me if this rubs you the wrong
> way.  it is just an idea and it does not have to be the answer.

Sorry to hear this now and recently. I am hoping that you get better
soon.

Best,
Ihor