From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ANvYCvfDqmGfnQAAgWs5BA (envelope-from ) for ; Sat, 04 Dec 2021 02:27:19 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id gNhpBvfDqmGzZwAAbx9fmQ (envelope-from ) for ; Sat, 04 Dec 2021 01:27:19 +0000 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 5E1D6E028 for ; Sat, 4 Dec 2021 02:27:18 +0100 (CET) Received: from localhost ([::1]:46892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtJpc-0007Gz-CL for larch@yhetil.org; Fri, 03 Dec 2021 20:27:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57614) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtJoi-0007Gq-7Y for emacs-orgmode@gnu.org; Fri, 03 Dec 2021 20:26:20 -0500 Received: from mout02.posteo.de ([185.67.36.66]:59971) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtJof-0005E7-E6 for emacs-orgmode@gnu.org; Fri, 03 Dec 2021 20:26:20 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 3F18B240101 for ; Sat, 4 Dec 2021 02:26:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1638581174; bh=H/+TmMZYl5zWwjTjRPhs3ErJrXD6YN7rHP08q6rAsPI=; h=From:To:Cc:Subject:Date:From; b=X9iMTfIBqcQkbNPlg/zF6JJiRfHHS3iClicE7At9fTwkpbDnmng1SYh9JEoZ3Nf36 6CtEPIxtLgnAuRhJdyAfIWvvM7ibQkZZoXymV/Tpr4dERRZoE6cz8dJDrfX5zaeBtu kw16dajoM5po6YSc1hEdgMSAuRDHhKx564g4qXJTRa72b+nPMSCCdevT3mtXrvkbwF XiXk2ebtrAwWXdisrG1cA2RY+EWteChZtKVxxFRnwepIeVSmZU9sskbQa0dRRp7p/9 V5NOQSZDjonWOZx/s2aqIGu8AaCLWesgB2tS5OGLc6j/zJq5xi5TRQfyiOQYkzR+oE rbpI0DN55BhOg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4J5X8P3cJtz9rxK; Sat, 4 Dec 2021 02:26:13 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Tim Cross Subject: Re: On zero width spaces and Org syntax References: <87ilw5yhv3.fsf@posteo.net> <87v905gtis.fsf@gmail.com> Date: Sat, 04 Dec 2021 01:26:11 +0000 In-Reply-To: <87v905gtis.fsf@gmail.com> (Tim Cross's message of "Sat, 04 Dec 2021 08:48:39 +1100") Message-ID: <87a6hh40uk.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@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_H2=-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: , Cc: orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638581238; 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=zW2419FO5z2EudEyzWcsFpZNZDRAdj7NEwvDrsJwyDk=; b=kcULeIYBI2q+nOqOBU9QeNX8u3LfXda5ZljA32bDHmGjVU2QRoYoBHyOoYb1K5s//tLtIP ofHtHiMqLMeCN81UDysM7tB8nvGpduU6YDWG3qXUXQpOpqr9paCl663hRL4LOW9yaGVAjG qP9YDgJYGwZOYmai4upg1Mm2ZJS3PtCx76UumMuO9vseHayp7vHeDyr5zLs2XCT3VA7y/F fogI95vprzfZHCq348xbPPKf1Dm7F+Qrg1LxdovZXb2JkqqisV9Q+sL+mqEgZupCkAu+AG slWFoJ5lIx6R2w4o9xDP9/FESi1qvTDs8G1FrLzhnnpSUWa6/q1zpi22nTy3GA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638581238; a=rsa-sha256; cv=none; b=iYPmKq1og3g2OksDtg+uoGMPJM6UtMdclbkUPNG5qcYt2whx4iJ3O/caRPUB7eeJZdaIfd cBAAkVGZsqHZ3maVj53d8++XP5OA9zLYdHFaxUd1GkJzkjR4GMA1hVcVKY+vMvb9KtvlI3 /+cx2sM9cTyPQ7UUvcScaKusYxd5voOZMtFKBJ1Pa/xInQXFoiwhtrdU6kXkVU/3KUYxAD 9qi0sHEsK0qVlLqhvssV+ee3CsuzY3PeHTOWwg5JOuMMkh7WObInmbUMqCZRArtPasRpsE RvY3VddZD1dqJHN7lPtcjcLgGi1o9HPhgHbAjomIlmkvemORSWneBvt72DCIPQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=X9iMTfIB; 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" X-Migadu-Spam-Score: -4.33 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=X9iMTfIB; 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" X-Migadu-Queue-Id: 5E1D6E028 X-Spam-Score: -4.33 X-Migadu-Scanner: scn0.migadu.com X-TUID: IUP1se9WdYs4 Tim Cross writes: > I think I am in agreement regarding most of your points about the use of > the zero-width character. I see it as a type of escape hatch which > provides a solution in some less frequent situations. It is a somewhat > clever kludge to enable markup in some situations not supported by the > basic markup syntax I'm happy with its status as a kludge and would not > want to see it become an official part of the syntax. Where we may > differ is in whether we actually want to add inner word markup support > at all. > > I'm somewhat surprised and more than a little concerned at how much > interest and focus on modifying the markup syntax of org the question of > inner word markup has generated. This seems to be a symptom of a more > general trend towards adding and extending org mode to meet the needs of > everyone and I'm concerned this is overlooking the key strength of org > mode - simplicity. > > Consider how many times we have had requests for inner word markup in > the last 18 years. I've seen such requests only a very few times. > Certainly not frequently enough to consider modification of the markup > syntax to accommodate such a requirement. > > A key philosophy of org mode is simplicity - it makes the easy stuff > simple and the hard stuff possible. The thing about simple solutions is > that they will inevitably have limitations. If you don't want those > limitations, then you use a more complex feature rich markup, such as > Latex, HTML, XML etc. Ideally, your system will provide some escape > hatches to allow you to do things not supported by the base markup > syntax. Those escape hatches will usually be less convenient and often > look quite ugly, but that is fine because they are an escape hatch > which is used infrequently. Better still is if the system provides some > way to make a specific escape hatch easier to use in a document (such as > via a macro). The basic org markup syntax has worked remarkably well for > 18 years. Nearly all the proposed additions or alterations to support > inner word markup with complicate the syntax or introduce potential new > ambiguities and/or complexity in processing to support a feature which > has been rarely asked for and which has other, less convenient and often > ugly, solutions which work. > > One of org's strengths has been the ability to export documents to > multiple formats. One way this has been made possible is by keeping the > markup syntax simple - a basic markup which is well supported by all > export back ends. Once you start adding more complex markup support, you > see a blow out of complexity in the export back ends. Worse yet, you get > results which are surprising to the end user or which simply don't work > correctly with some formats. to avoid this, it is critical to keep the > markup syntax as simple and straight-forward as possible, even if that > means some limitations on what can be done with the markup. > > My vote is to simply maintain the status quo. Don't modify the syntax, > don't make the zero space character somewhat special or processed in any > special way during export. In short, accept that inner word markup has > only limited support and if that is a requirement which is critical to > your use case, accept that org mode may not be the right solution for > your requirements. Thank you very much for the detailed and precise exposition of your point of view. I appreciate it. First of all, a point that I consider important and essential in this and other debates that are generated here, is that there is no single conception of Org that should prevail as (say) "the canon". Org is so polyhedral and so multifaceted that there are as many conceptions of Org as there are users of Org. Well, what I have said is in itself one more conception of Org. But I assume that other users may think that Org is not all the things that I say it is. At the end of the day, what matters is only one thing, for on top of theories and doctrines: if Org is useful to you and helps you to do your work, so great. A few months ago (and I think I already shared it here) I finished the typesetting and layout of a dictionary of almost 1000 pages, and I did it using a workflow that I have developed which is a merge between Org/Org-Publish and LuaTeX. And now, using the same method, I am working on an ancient-Greek/Spanish bilingual critical edition. So I believe I'm not suspicious of thinking that Org doesn't cover the needs of my workflow. As for the matter of emphasis marks between words. I believe that this is not the underlying problem, but rather the (little) inconsistency of the markup on certain contexts. Think, for example, of a text where you have to put many words in italics, enclosed between brackets. I don't care if that type of text is 'typical' or 'non-typical', 'majority' or 'non-majority'. It is simply a kind of scenario absolutely legitimate and feasible, and right now I could quote you more than a type of text in that direction. Since I have been using Org I have been running into these little inconsistencies. Any insurmountable, of course, nor I had to abandon the use of Org for that minor issues. Fortunately, Org is more than just a markup language, and it offers lots of alternative resources and extensibility. Org is GNU Emacs. Org is not Markdown. My proposal here also does not arise from an irrepressible desire to add more complexity to the syntax. If it's recommended that the user, in certain contexts, enter implicitly a zero-width space (which, I insist, is a practice that should be avoided as much as possible in a plain text document), why not at least offer a graphical alternative, a *real* mark whose role is *exactly* the same as that of the zero-with space? Is that adding more complexity??? Honestly I think that's exactly the opposite. In any case, I have suggested that new mark as a possibility, in case it is interesting to implement it, since a thread has emerged these days about the topic of the intra-words syntax. Discussions and threads arised about these questions and any other are perfectly legitimate and natural and welcome. Please: there are no issues more 'important' than others; no two users are the same in Org. What you do not find useful, another user may perhaps finds it indispensable. And vice versa. And I think no one is in willingness to state what the average Org user does or does not want, given that we do not know even 1% of Org users. Best regards, Juan Manuel