From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4AcfMEk+WGGXwgAAgWs5BA (envelope-from ) for ; Sat, 02 Oct 2021 13:11:05 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id APe0K0k+WGGXJQAAbx9fmQ (envelope-from ) for ; Sat, 02 Oct 2021 11:11:05 +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 3793D2B3AA for ; Sat, 2 Oct 2021 13:11:05 +0200 (CEST) Received: from localhost ([::1]:51248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWcv1-0000W7-3i for larch@yhetil.org; Sat, 02 Oct 2021 07:11:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWcrC-0003wS-ON for emacs-orgmode@gnu.org; Sat, 02 Oct 2021 07:07:06 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:36689) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWcr9-0001nK-CP for emacs-orgmode@gnu.org; Sat, 02 Oct 2021 07:07:05 -0400 Received: (Authenticated sender: admin@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id E6D3B60003; Sat, 2 Oct 2021 11:06:57 +0000 (UTC) From: Nicolas Goaziou To: Timothy Subject: Re: [PATCH] Don't fill displayed equations References: <87czoq7z3p.fsf@gmail.com> <87tui1ew1o.fsf@nicolasgoaziou.fr> <871r5599j7.fsf@gmail.com> <87pmspevjy.fsf@nicolasgoaziou.fr> <87bl49kca3.fsf@gmail.com> <87ee95ekrh.fsf@nicolasgoaziou.fr> <875yuhjhpa.fsf@gmail.com> Date: Sat, 02 Oct 2021 13:06:55 +0200 In-Reply-To: <875yuhjhpa.fsf@gmail.com> (Timothy's message of "Fri, 01 Oct 2021 15:43:35 +0800") Message-ID: <877devofcg.fsf@nicolasgoaziou.fr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=217.70.183.195; envelope-from=mail@nicolasgoaziou.fr; helo=relay3-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Org Mode List Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1633173065; 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; bh=S4Wv6V7yunZ9UpHCoFIOXgxoas9zhWwnlIImMoOHOIE=; b=hY5eNkqjVzbob9ujHdvjHDx4fBD/aC04bAVLvvhKejm8FXpcctEDrgJH8KoWpfi6tlXlGr JiXKkyoDSuZFmhFqyXIBS3dLAoOixnZKeUGWECmkkDo2rAYIsbpRZBXd8gzWWtIr+deugq MTck0GSRiBaJmAsxmJ6CxyOse/3X3+5yT4yIEJGc+GCwtPCWgnbbpawgdmf7dmPKtm1JQo hEnualv9pehCwFFkJetmKz7Q7f19IInb/jOeFJ87cLzeALoZXaG4RS0FuQP0Nc4wfr8Uw8 s7YbzV8qiqIleYkBvj3lMNPnsTbUzoCVEMFRo0q28hvuiFoO3yQa4YqfLYF2Jw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633173065; a=rsa-sha256; cv=none; b=UJR8aC7u/2TYtP9/hb+xlZ/4tb2IFZiAOzKDyjdNPUbzmy6zusHuaKKdWuLC/Xkr9HGZ2F DsyLQDe9HbRV52UPfji0AHaG9pfIc3cSIfnuGTXuzmy6DrLX/rySLH7WAZZqWkaY4w4Hlr sxQkDLkwimKRGXmG4cQt2QYf3iOpXamE4aQISPgdb1J7adTEc4Chv5QB52zVyIHuhs/4U7 yRi4HH4RFXjHcL1yIOciDnwCkCmcf3bgp3UYCCWAZitCQsJG4r4JRVZp+uSHcWRQ2K2Kjq uY7E7EMwXOTdPWWuxt0Drr8UndUAv2MIjdg35wre5qCylfhIMs6WB1xfcDnREQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -2.41 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 3793D2B3AA X-Spam-Score: -2.41 X-Migadu-Scanner: scn0.migadu.com X-TUID: evds1O9enNLR Hello, Timothy writes: > Is it? I can't use verbatim like this: > > =3D > some > verbatim > text > =3D > > but I can do > > \[ > some > display > equation > \] > > It seems to me that \[ ... \] is already treated differently from other > inline markup. There is some misunderstanding here.=20 You cannot use verbatim like the above because its definition forbids spaces on the inner side of the markers (for obvious reasons). There is no such restriction in \[...\] markup. For citations, you can also write [@cite: @foo ] if you like. But this is orthogonal to the type of element, i.e., inline or block. Inline means the object is always enclosed in a paragraph (or a verse block, or possibly a table cell). In particular, it cannot get past the boundaries of its container. Corollary: since a blank line in Org ends a paragraph, objects cannot contain blank lines. Both verbatim objects and \[...\] snippets share those limitations. > If that's the only way that Org could treat \[ ... \] differently from > \( ... \), I'd be strongly in favour of this. I think it is not necessarily a bad thing that \(...\) and \[...\] are the same. Some export back-ends can tell the difference between them, others do not care. This is the same for, e.g., verbatim and code. Not all back-ends use a different output for them. IOW, it is not necessarily right to treat them differently just because some back-ends do treat them differently. Org is simply agnostic to this subtleties. > I prefer \[ ... \] over \begin{equation*}...\end{equation*} as it's much > more succinct, and helps reduce the "markup noise" in my documents.=20 This is all about taste. But at least you have a choice. With your patch, I may have to struggle with filling whenever some paragraph contains \[...\], without any choice. Also, it could be possible to overlay "\[" over \begin{equation*} thus negating the markup noise. > I don't think this is an insignificant concern, brevity may not be > something I'm very good at in emails =F0=9F=98=9B but is something I look= for in > syntax. You probably have noticed that Org syntax is not very much into brevity. > I must admit, I don't see the downside here --- how does this break the > filling function for the rest of you? This only affects \[ ... \] blocks > that have already been put on their own line. No it doesn't. Without additional guards, filling a paragraph could split a line and send an otherwise mid-line block at the beginning of a line. But this is not the point. The point is much more basic, actually. It is related to the uniformity of filling behaviour, as already explained. > Why can't we apply LaTeX expectations to LaTeX elements in Org? Applying > LaTeX expectations to Org as a whole is clearly a silly idea, but Org > copies \[ .. \] from LaTeX and it is a LaTeX construct. Nope, it is obviously borrowed to LaTeX, but they are not the same. I think I understand where you're coming from. Relying much on LaTeX, you probably grew habits on how your equations should be formatted in a LaTeX document. Applying this formatting in an Org document doesn't work, tho, because Org has little understanding of true LaTeX syntax. It just needs a way to quickly write maths. \[ ... equation ... \] should be seen as a LaTeXism. >> Notwithstanding filling behaviour, \[...\] in Org is much more limited >> than \[...\] in LaTeX. > > I'd be curious to hear how, as I personally haven't run into any > instances where \[ ... \] has behaved differently other than when an > environment starts on a new line in of a \[ ... \] block (which can > easily be fixed by putting something like \!\ at the start of the > line). As explained above, for example, \[...\] cannot contain blank lines. They cannot contain, e.g., "|" at the beginning of a line, too. Full-fledged LaTeX environments do not have those limitations. > I don't want "advanced" LaTeX code, I just want my display equations to > be treated as display equations consistently =F0=9F=98=82. It is a "display equation" in LaTeX. There is no such thing as a "display equation" in Org, even though you probably see it as such due to your LaTeX background. There, \[...\] is just another way to write maths within a paragraph. Regards, --=20 Nicolas Goaziou