From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 OHvQF9ev5GLVgQEAbAwnHQ (envelope-from ) for ; Sat, 30 Jul 2022 06:13:11 +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 wB3UFtev5GL5JQAAG6o9tA (envelope-from ) for ; Sat, 30 Jul 2022 06:13:11 +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 7913BE83B for ; Sat, 30 Jul 2022 06:13:09 +0200 (CEST) Received: from localhost ([::1]:33568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oHdqe-0006vw-CO for larch@yhetil.org; Sat, 30 Jul 2022 00:13:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oHdpw-0006vm-CG for emacs-orgmode@gnu.org; Sat, 30 Jul 2022 00:12:24 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]:37620) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oHdpt-0000lC-1x for emacs-orgmode@gnu.org; Sat, 30 Jul 2022 00:12:24 -0400 Received: by mail-lj1-x233.google.com with SMTP id e11so7053608ljl.4 for ; Fri, 29 Jul 2022 21:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:from:to:cc; bh=p2h4lxTE7ufuZYgYnwTNRPtLdepJwJL5313nu6NVxsw=; b=AZf7ncv4RfFmINgT5SGr5PZ1oBv+SnU7Ly4dlwEGYN8o2kJFJsv1mvJ22Mv68e4Slc e0Ph3oS/twlO31JrxsV+9u0E/eBCUxz2n9aqUi7ncW0Uo/aPQKIgUoa/XqwC4n1OM54s yHiXif29rIFKOOFm3O0oeVFJJFWOq9DxpZ3HRNQI3OnPkz7IiwOB1s5ByqZOR4C0wXqg +PZJVXM8T6v+4w3Ugdv8QESdRGOoRNIMXa+aBgpcAHNVX+UoZpZCPMIbsUzhiRRXQro2 EL2GB4aGstKtYzDRSOVZxZ+80mqMZG7kk0dAduQS4azvMeoXqQEz1Rx6hhHlHvViODRv wjng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:x-gm-message-state:from:to:cc; bh=p2h4lxTE7ufuZYgYnwTNRPtLdepJwJL5313nu6NVxsw=; b=OsSM1+hJeNayG14DC7cJoKm4jf7EXx0+yVMP6rdhPe+9ILUjkN6Vvo9IMyPCQshv1j W3bI1wnAwvNImVJFp17k82vV3jtW91xRULNDEAoe3YuhiMMSRb76ZKrY7ZHuAFunwCeA aPWoZlBQcWcSSi4GKfZsiGOBVnq6PAeEtziEindTaz+sf975Rt7LwalqEhzLoWM4h9lE JAHA63x8DKGnTGxAmloh4hlVPtPt//VCTBDPhqeDuMIjV3oZn+oLVdLZyM0xjhkwafY9 KRbxAZDP2bZ0pczsy/rJcuceQGVzdJ8tGVqvW1AUKvO8I4JlT7bRUGa9KMI1JKKCKcmA OPKA== X-Gm-Message-State: AJIora+JFUV73DgbjCxRJQxNQ2K6I8O/u4FOMvqSR00Bj8kpXCQGt+MI ZCZ8jtiXagBkDozXV8+1gCFXdTUCBwZM5OTNXKw= X-Google-Smtp-Source: AGRyM1uWhIRnCNIzOHfWL9kMXj4wK+t7zMG0nxFRggGXsHarCSB/r9yevd+3rDY9/ks8jM4iE2uiwFRySwXpqKuBeZI= X-Received: by 2002:a2e:3112:0:b0:24f:132a:fd71 with SMTP id x18-20020a2e3112000000b0024f132afd71mr2049090ljx.522.1659154338823; Fri, 29 Jul 2022 21:12:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aa6:cac4:0:b0:1fe:cd23:c613 with HTTP; Fri, 29 Jul 2022 21:12:17 -0700 (PDT) In-Reply-To: References: <87r128d5pp.fsf@localhost> <80f0990042a564556cc6b047a94f7e9dddf5a280.camel@outlook.com> <87v8rkav2x.fsf@localhost> <87mtct9y1f.fsf@localhost> <87mtcsn173.fsf@localhost> <878rocmgoi.fsf@localhost> From: Samuel Wales Date: Fri, 29 Jul 2022 21:12:17 -0700 Message-ID: Subject: Re: [PATCH v2] Add new entity \-- serving as markup separator/escape symbol To: Ihor Radchenko Cc: Max Nikulin , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=samologist@gmail.com; helo=mail-lj1-x233.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" 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=1659154389; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=p2h4lxTE7ufuZYgYnwTNRPtLdepJwJL5313nu6NVxsw=; b=G+HeI2l1Twb2Ih6BU8X3S74wEoIEWyaO5UGEfEUXK82UcgDnNhxzfFRKknSUzmj7qt9f9C Jf5tf8tNW1jcO6veHmaUOQbYv9+hFTav8rsu4RLsAJXBszkPRQIcDyN5Avwc6z/voFaOjv M39oyj6mFHImGScxa0+bHo2U2+O0BCRqQcBTbOsm+lM+pIuVaFqDonfzJFxtHtqRXC/0hC xRSofmnuP+uzTI8wGfww88SKspaAsTr6ahHkacjHAvQKaxJL5Xr+RwA0+S2XSwPgsQF/wt uvn4/l7CxTvFr0KE5s0RWY5oOryOstGU1kpiMOxPE++LQcEohYvOFUa8I5TJwg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1659154389; a=rsa-sha256; cv=none; b=OnMqKf7DvejfpAUMqIWECa+g35keyD3II3o5z4eou6WGXT2xXSLXpa7NiWabACa0gexIBU O9prkBxDrQINwfNGrXZGfheN23OHe3Y/JB34K3Nu2c8XKZBVF38rqiYOEzm9gifYeoKT31 pyu5m15mNFRp52XLM3uuDtqf95HUZqCKnSqdqJiGH01oF5QIlNozQ/v0Tb27ODL3qd4fva Y2aNrx8lCv/uoJ/RRvpMfNR1tX7IfROUdb1/SqDIIXxRp9NXtg/VU1GWiPk/dmqVq9sSmD dJGOjr0CXDJ/6SW7cZUrdlamVL/HE/z4N4hLpl96O6Td5dnGA1MOJmuwOVCP/w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AZf7ncv4; 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: -8.73 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=AZf7ncv4; 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: 7913BE83B X-Spam-Score: -8.73 X-Migadu-Scanner: scn0.migadu.com X-TUID: Gdfy6BtWAGuz my deep apologies for the typo in john's name. i meant of course John Kitchin -- jkitchin. i refer to his new style link syntax and his proof of concept for cl style keyword args. i still owe you email replies. On 7/29/22, Samuel Wales wrote: > 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 "*"] > > 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. > > it looks verbose to 3rd party tools but is parseable by them. this > example displays as * to the user. parseable as lisp sexp data using > lisp tools. it is meant to be vaguely reminiscent of a cl function > call while still not likely to occur naturally. > > it would of course not be typed by the user directly but by some > completion thing. > > 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. > > 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. > > On 7/29/22, Ihor Radchenko wrote: >> Max Nikulin writes: >> >>>>> The good point in your patch is that \- is still work as shy hyphen >>>>> (that, by the way, may be used in some cases instead of zero width >>>>> space: *intra*\-word). On the other hand I have managed to find a cas= e >>>>> when your approach is not ideal: >>>>> >>>>> *\--scratch\--* >>>>> >>>>>

>>>>> ­-scratch

>>>> >>>> Well. I think that it is impossible to use the same escape construct t= o >>>> both force emphasis and escape it. >>> >>> Let's articulate the problem as follows: when some characters ("*". "/"= . >>> etc.) besides used literally are overloaded with 2 additional roles tha= t >>> are start emphasis group and terminate emphasis group, in addition to >>> lightweight markup heuristics, it is necessary to provide a way to >>> disambiguate which of 3 roles is associated with particular character. >>> >>> "Activate" and "deactivate" characters or entities for emphasis markers >>> are alternative and perhaps not so clear terms have used before. >>> >>> The advantage of zero width space is that "[:space:]" is part of >>> PREMATCH and POSTMATCH (outer) regexps in >>> `org-emphasis-regexp-components' and "[:space:]" is forbidden at the >>> inner borders of emphasized span of text. The latter is mostly >>> meaningful, however I am unsure if bold space has the same width as >>> regular one, and space in fixed width font is certainly distinct. >>> >>> The problem with the "\--" entity is that it is not handled properly at >>> the start of emphasis region. It neither disables emphasis nor parsed a= s >>> complete entity, instead it becomes combination of "\-" shy hyphen and >>> literal "-". >>> >>> Unsure if it can be solved consistently. Possible ways: >>> - It addition to space-like (in respect to current regexp) entity add >>> another one that acts as a part of word, but like "\--" stripped from >>> output. Likely it should be accompanied by more changes in the parser >>> and regexps. >>> - Provide some new explicit syntax for literal character, start of >>> emphasis group, end of emphasis group. >> >> The fact that \-- was not parsed in your example is because entities >> cannot be directly followed by a letter (see 12.4 Special Symbols). >> >> You need >> >> *\--{}scratch\--* >> >> Concerning the 3 listed roles of the *_/+ markup, I propose to simplify >> the problem a bit and not try to make \-- serve as a proper escape >> symbol. >> Instead, we can document the already existing quoting entities: >> >> ("slash" "/" nil "/" "/" "/" "/") >> ("plus" "+" nil "+" "+" "+" "+") >> ("under" "\\_" nil "_" "_" "_" "_") >> ("equal" "=3D" nil "=3D" "=3D" "=3D" "=3D") >> ("star" "\\star" t "*" "*" "*" "=E2=8B=86") >> >> Then, your example should better be written as >> >> \star{}scratch\star >> >> \-- may better work between markup, not inside. >> >>> Concerning zero width space workaround, I may be wrong, but Nicolas >>> might consider using U+200B zero width space as the escape character fo= r >>> itself: single one is filtered out during export, double zero width >>> space becomes single character. (I do not like this kind of "white >>> space" programming language".) >> >> This is too complex, IMHO. >> If desired, we can again go the entity road and introduce >> \zws entity. >> >> Note that we already have >> >> ("nbsp" "~" nil " " " " "=C2=A0" "=C2=A0") >> ("ensp" "\\hspace*{.5em}" nil " " " " " " "=E2=80=82") >> ("emsp" "\\hspace*{1em}" nil " " " " " " "=E2=80=83") >> ("thinsp" "\\hspace*{.2em}" nil " " " " " " "=E2=80=89") >> >> Generally, it is a good idea to advertise entities in the manual. >> Zero-width space is not only limited, it is impossible to use, e.g. in >> tables when you want to quote "|". The only solution is using \vert or >> \vbar entity. >> >>> Another question is whether U+2060 word >>> joiner (or some other character) should be added either as alternative >>> to zero width space or to allow =3D verbatim =3D fixed width text >>> surrounded by fixed width spaces. >> >> This particular example is tricky. >> If we put escape symbol _inside_ the verbatim, it is never possible to >> know if the user intents to use that symbol literally or not. >> But non-space before/after opening/closing markup char is hard-coded and >> changing it is fragile. >> >> Instead of using some kind of "escape" symbol here, I suggest turning to >> the idea about inline special blocks. We can introduce a more verbose >> markup that will allow spaces inside at the beginning/end of the >> contents. >> >> https://orgmode.org/list/87a6b8pbhg.fsf@posteo.net >> Manuel Mac=C3=ADas [ML:Org mode] (2022) About 'inline special blocks' >> >> Instead of using the tricky *bold text*, we may allow _*{bold text}*_ or >> something similar, with _name{...}name_ being inline special block. >> >> Best, >> Ihor >> >> > > > -- > The Kafka Pandemic > > A blog about science, health, human rights, and misopathy: > https://thekafkapandemic.blogspot.com > --=20 The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com