From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id IH2/DN1vAGKiNgAAgWs5BA (envelope-from ) for ; Mon, 07 Feb 2022 02:03:25 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id oIVXCt1vAGK2pQAA9RJhRA (envelope-from ) for ; Mon, 07 Feb 2022 02:03:25 +0100 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 79E973BE08 for ; Mon, 7 Feb 2022 02:03:24 +0100 (CET) Received: from localhost ([::1]:35918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGsR9-0006ar-7m for larch@yhetil.org; Sun, 06 Feb 2022 20:03:23 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGsP6-0006a0-Ck for emacs-orgmode@gnu.org; Sun, 06 Feb 2022 20:01:17 -0500 Received: from [2607:f8b0:4864:20::1036] (port=51876 helo=mail-pj1-x1036.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nGsP2-0007aH-Bh for emacs-orgmode@gnu.org; Sun, 06 Feb 2022 20:01:14 -0500 Received: by mail-pj1-x1036.google.com with SMTP id y9so3603362pjf.1 for ; Sun, 06 Feb 2022 17:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=dpvoh+sFJk3LbTQAbNNhNWWsgXdnGPLUshr06Qm895A=; b=AhqDNUTMmpw+hUcMvn/js3BOiI3C5eyAqmchBY/ORtAz2YrWc12dNFZ0SL65BramRj nWYn+MHFKMpLog0r29FpHOaVitOjoK2kCcXHF5v943V/PkssuEzVeaqUl5C7EkqDIlFo 3HzmBIq+7pYiQ5MPeG4fPkEV/kSCYAoAGMtiHl3D4C9hAkTuGzioQcBKuxPWRZbE5U4d rosBhs15NMsaGec1/KHilILqSR2hmP9odS0casNJFZuTVGhfEFZNSSCiNr1PrHtxBIsN E8EP95RqY8vvap/BVpES5GtUxHmvFJwle9QqoeVGl1ahgo/+HQzzXtBhmlijP8SwvrAi OlEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=dpvoh+sFJk3LbTQAbNNhNWWsgXdnGPLUshr06Qm895A=; b=LQT9XSyvg/fRWRyK2PvvPqXoO9iTywt7N0Y2uzkqJCQtwP4l64At/C7v8lNEdjrgaA Zi7MCaFaybreFT9fTeDCftqUCbYvC0W9ylOtFhBGv5ao3MFj26OLnPJdgnY9s8VMRBDW 3lZxfK/xwYFGfTVuzjTKXohiDMIiqfJdw4bePUf8IvGT5/6sYuxZaGeqAHVbrRALU40q KQdZi3JI80RId6DR0vRT/RJg67jbWFGQw1F2sUZKriQOQV6P1SxIZ1spdwDt5PxIgWHg bu7IDp55hpQUkXA55Tp8o1UPz0fjGqRRpQh9wvEvxw12YatCELWO6O9aoIdWtqin3vXJ 5ovQ== X-Gm-Message-State: AOAM532A33EBu9Lb1iZS8GidrfbTpDrjKTc6wXYASwkKCy/1l0YeSeNz X6dLlBY9YJHqHui6O6KzJwCIJ5A2/fc= X-Google-Smtp-Source: ABdhPJy7rL8KsqOA7a+dOnV7CxUmLutzkqeLkVpxmpD8JumqgQGqWAK7TNH7R5W2AgFVPxYC5RtcHw== X-Received: by 2002:a17:902:b495:: with SMTP id y21mr13955700plr.82.1644195666629; Sun, 06 Feb 2022 17:01:06 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-258d-f255-e8e2-f18f.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:258d:f255:e8e2:f18f]) by smtp.gmail.com with ESMTPSA id d15sm9439919pfu.127.2022.02.06.17.01.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Feb 2022 17:01:06 -0800 (PST) References: <874k5si6zh.fsf@ucl.ac.uk> <87r18t7fc5.fsf@localhost> <87ee4mkmpw.fsf@gmail.com> User-agent: mu4e 1.7.7; emacs 28.0.91 From: Tim Cross To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= Subject: Re: [PATCH] Add support for =?utf-8?Q?$=E2=80=A6$?= latex fragments followed by a dash Date: Mon, 07 Feb 2022 11:00:08 +1100 In-reply-to: Message-ID: <87tudb4hip.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1036 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1036; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1036.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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: =?utf-8?Q?Jo=C3=A3o?= Pedro de Amorim Paula , =?utf-8?Q?S=C3=A9?= =?utf-8?Q?bastien?= Miquel , emacs-orgmode@gnu.org, Ihor Radchenko , Eric S Fraga 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=1644195804; 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=dpvoh+sFJk3LbTQAbNNhNWWsgXdnGPLUshr06Qm895A=; b=ILCQnsUolmrkfkAMzUGwJSMxH+llInvDROlxT9ff1if+QJ8oaEgi1YJVIZAP64m1kRF630 hzNO35BRIuqOCmnvHQ/Zhk/52wsz9/SmC7koCkvorElDByO9u6e7HLMcZP5L8NxrRyTW+Z Gagowc1rgjFkr8zPDwwlibfFE55zrAnUfN3y45argmcJ/Qvi/9pyzTA7OP9zuYty8Amo+T yd5Y60suoOQOZcEJ+heN9VkgkeB9hd4r6dyNQ9euaw0V+lUiNJ39YWE3TXaQYN6waDCRuj wXiOfmkQrXZTF9gqUziiQq4803Quab0wMn19/SOiS7gAREJ1uDMNIAvcHeOXDQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1644195804; a=rsa-sha256; cv=none; b=XmVkjHcxA04DPu4NKj9Mfbayf7/GSC24jHEdLpRd5pMQBTxU+6Kab2vh/ej8OrEmpIfrdX XrdLoMX7z8nWs/ButUCsGdLena2qRzJh1GXOd/yq6uO1xF+5hBa9/Buy7EHh+us0VZDN2R WhVozhdv42Po8f9DeuY5dkt/2rsN8b2i0kN16T84BAuF8REcit0w7D8eXgII1f6UQtCJYG gy8Ny1p4ie5T2FjkQWp2pvWnLH8tJc04PbkG+CkhRa90XVPw5KUJo4+CLyz1YUmnbQS31E ufVoIds5jf1S0crunFLgdp74Lud+wyBesMCbRE2bjeQLzH0fNiKNvxpIhorHBA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=AhqDNUTM; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: -1.03 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=AhqDNUTM; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 79E973BE08 X-Spam-Score: -1.03 X-Migadu-Scanner: scn1.migadu.com X-TUID: 69N89wNo3f4p Rudolf Adamkovi=C4=8D writes: > Jo=C3=A3o Pedro de Amorim Paula writes: > >> On 01 February 2022 22:00, Rudolf Adamkovi=C4=8D wrote: >> >>> Me, I cannot use any of these "pretty" features because, simply put, >>> they break plain text. For example, they cause misaligned tables and >>> make the text overflow the fill column, which I keep at 72 columns. >> >> [=E2=80=A6] there are fonts that enforce Unicode (all characters, from w= hat I >> understand, Unicode included) characters to be exactly 1 unit width, >> i.e. Unicode characters are the same widths as other characters. At >> least I can guarantee that any of the Term (all characters are the >> same length, but has ligatures) or Fixed (same as Term but no >> ligatures) for Iosekva [1] have this given property. >> >> [1] https://typeof.net/Iosevka/ > > Thank you for sharing! I use the amazing "Hack" typeface [1]. Then, I > fail to understand how the font changes the fact that Org breaks "the > promise of plain text" in this regard. > > For example, Org can hide its emphasis markers. Later, one opens the > file in another editor and sees the truth. The lines go over the fill > column, the tables have misaligned columns, and so on. > The promise of plain text has no inherent promise regarding alignment, line wrapping etc. The promise of plain text is simply that - a promise that org files will be just plain text rather than some application specific format like many other systems (MS Word, LibreOffice, etc). Provided you can still edit the file with a plain text editor, org has not broken its promise. Ironically, it is this plain text basis of org files which makes on-going support of $..$ (and any extension) so problematic. Without this restriction, org files could have a format where elements were 'tagged' to remove ambiguity and simplify the parsing process. However, this would of course mean that either you had to edit the file within org mode or you would have to be intimately familiar with the internal structure of org mode files and use an editor which made editing/updating the internal structure possible. To be very clear, I am NOT advocating that org should adopt some form of internal tagging or structure. I'm only attempting to highlight that having a system which aims to maintain the data source in plain text comes at a cost. In LaTex et. al. $..$ works well because $ is a special character. If you want a literal $, you have to escape it. In org, $ is not a special character. This means we need complex regular expressions in order to identify when $ is being used for LaTex specific markup and when it is being used in other contexts (e.g. literal $ sign, variable name). These regular expressions are difficult to get right, error prone and above all, incur a significant performance hit. Extending the syntax further to support $..$- simply makes the situation worse by adding further complexity. So far, all the arguments against removal of support for $..$ are based on inconvenience and reduced readability associated with the alternatives. Both legitimate concerns. For many, the proposed change may seem to be just inconvenient change for no real purpose because they don't deal with the complexities inherent in making $..$ work and for others, change is something they would always prefer to avoid. In this instance, I feel we really need to listen to those who put in such a dedicated effort in maintaining org mode and accept their position that sustaining $..$ syntax going forward is problematic and focus on what can be done to mitigate the impact from this change, make the alternative syntax more convenient and address the readability issues.