From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id qJVVIdzAVmEK4QAAgWs5BA (envelope-from ) for ; Fri, 01 Oct 2021 10:03:40 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 6FkUHdzAVmFLDQAA1q6Kng (envelope-from ) for ; Fri, 01 Oct 2021 08:03:40 +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 DB64D33B0D for ; Fri, 1 Oct 2021 10:03:39 +0200 (CEST) Received: from localhost ([::1]:39668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWDW7-0000oW-2i for larch@yhetil.org; Fri, 01 Oct 2021 04:03:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWDVI-0000np-Uj for emacs-orgmode@gnu.org; Fri, 01 Oct 2021 04:02:48 -0400 Received: from mail-pj1-x102d.google.com ([2607:f8b0:4864:20::102d]:53026) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWDVG-0005AR-Vr for emacs-orgmode@gnu.org; Fri, 01 Oct 2021 04:02:48 -0400 Received: by mail-pj1-x102d.google.com with SMTP id v19so5993137pjh.2 for ; Fri, 01 Oct 2021 01:02:46 -0700 (PDT) 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=h0GfePY9o2ehdiyKXO+UhBHretxXdEKPhKPPLigpSB8=; b=m52slXpGHSocXcQ8WKm/ZEqUWM5g2op0phsxRgjTR3ixCcXPjtpEKujOk8OIhgSAPa 0tgPozJz+J21vDREPmsECTnwvJuND6lXlSwge7E4XLs6QeDtkCSlmYhGvHfJSS5A8ij1 HXW0uzdaZNMxgIXzqSVPRRX4M90UNF354y+s+CesK23YYEEWzsS6Zkd93DXufNjrgXdt 6+CThAMUEfIPYBh9PynpXwzVECoYmmipQw7rwSWlS6fB7ErxZjJwWtqLCwOVoXolbzgQ xa56qqPxEJ0r0orwhLQnshd1gP+zu5kaQaTZRm7CQZzVABBV1Fz8uwWpCpE5GvVuRtQ9 9uZg== 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=h0GfePY9o2ehdiyKXO+UhBHretxXdEKPhKPPLigpSB8=; b=EzIqSXpMCkSHv17Xq9lB1+j5mNMKgv6FBTKpH+p4RrdXIO5bSv6Q8vy8vgt7SnmO0i /lUYvTERH7eYTX/mJhwlX35xv6NiP2evDSDdRLrSt79WpgPGL4kdkeeqd6s9wT+7vN81 ZV2x6qoV68OC0qxLwJ+zN5vxnMlp14fVQJjSqR9njffmLonztPBuu8UaYaeeoTp1/owe mrOEVqm1xz6Zwz4YjiXLx0QOAeENuei2QqdFFAe0+MH5wd3Fu6RIyLLi6bzAOYpzGHia +QghyBatBgestnTYPp1xNripZzCtw7R/gPanv+YCryBhv+lgSNbmMI2qk380Ubl1FVLC KTLw== X-Gm-Message-State: AOAM532Cvb8u8iviboxw+CBfWLxG2HgAksURziAdYJDZpbC90B/9GL+r K1buBhJ0Wnd1FMD/vAa+S0B296THlt0= X-Google-Smtp-Source: ABdhPJzZ5tn9+l9bOQpOkPho/kDgMP6X2Gul5cpc0uXXxyUATjzq0pEfgxBmZ+TMUZPcunDbA4PLxQ== X-Received: by 2002:a17:902:7b85:b0:13d:cdc4:9531 with SMTP id w5-20020a1709027b8500b0013dcdc49531mr8357859pll.27.1633075365436; Fri, 01 Oct 2021 01:02:45 -0700 (PDT) Received: from localhost (61-245-128-160.3df580.per.nbn.aussiebb.net. [61.245.128.160]) by smtp.gmail.com with ESMTPSA id k7sm5354364pfk.59.2021.10.01.01.02.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Oct 2021 01:02:44 -0700 (PDT) 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> User-agent: mu4e 1.6.5; emacs 28.0.50 From: Timothy To: Nicolas Goaziou Subject: Re: [PATCH] Don't fill displayed equations Date: Fri, 01 Oct 2021 15:43:35 +0800 In-reply-to: <87ee95ekrh.fsf@nicolasgoaziou.fr> Message-ID: <875yuhjhpa.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::102d; envelope-from=tecosaur@gmail.com; helo=mail-pj1-x102d.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 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=1633075420; 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=h0GfePY9o2ehdiyKXO+UhBHretxXdEKPhKPPLigpSB8=; b=AlvAdcHxsFkFVjSyfnB5cUpohYYWxp+KeRqUItKeErdP1NqNNzYqfM452NJIM0GCak3L1p xOqrmqm+XmV+k2eheQXmZQH57n/KJenScJvOmanSA/e1mLepXOf8lPiJQ/VXaZMYY42f0w pDn0NTZwPu0xBrcj+NqmOnr4jfY94xAZing1Hg602Oh9H2b5Mnv7bRG9RyHvDizWoARSmn LGkKAVsa10YPeJ/R+Np+H4uWFyi2we+siZYNJAIM5HL20e3LrZ03sSWwb1LmHls0rzhSi3 VPGDN4lhntJEqqMNv88mxUNwWJn0jg7gbXFqiXQtc2RmxLoRwn9KDhqPb8wuqQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633075420; a=rsa-sha256; cv=none; b=WQyD4z8ahFmjS1PBSs1eKbUMao5dj4Jh6SJJLWAfBkGl2dBiuYVGxQ6InFsq6B/9GzX/wV wJeoagE+BzeIQ7EjlOgIC4S4PzRPOZxR6kzWH4+N1vXHz1Rlr77f38ac+XQohbMNBaQYND TzSeYzhJc+BmWxco0wWQzAfg/6oShOmX3M4fz87AmF1mdDAuEqh299eambrGgtMQ5NX6Ju CFdo9jwS6gqjl6u9CyGYw4O8MDTnPJULIAQuGL0QLfHkx4dpUowY38D7vCB+ZsE9CAQKPb YsOLhoxQW8uwtC715vd/8/JRmCAGC2owlGBFXe4/RC0MBgVVcAJjik26wxmx8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m52slXpG; dmarc=pass (policy=none) header.from=gmail.com; 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: -1.60 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=m52slXpG; dmarc=pass (policy=none) header.from=gmail.com; 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: DB64D33B0D X-Spam-Score: -1.60 X-Migadu-Scanner: scn0.migadu.com X-TUID: snjingWTwMsL Nicolas Goaziou writes: > Timothy writes: > >> I think there are also some relevant points which I haven=E2=80=99t ment= ioned so far, >> separate from my thoughts that since we=E2=80=99re using the LaTeX synta= x we should be >> consistent with how LaTeX treats this. > > I'm not convinced about this. I don't think it is even possible. By this, I'm specifically thinking of the fact that \( ... \) is inline, and \[ ... \] is a display equation. What's the point of Org having both if they're treated the same in "org syntax", on top of the inconstancy that creates with HTML, LaTeX exports etc. where it is once again treated as a display equation? Perhaps the discussion should shift from my specific patch to this general situation, but this behaviour feels wrong to me. >>> As I wrote above, they do not belong to the same category of syntax. >>> There=E2=80=99s no reason to special case .... >> >> I think we already do special-case `\[ ... \]' somewhat. When refer to i= nline >> elements like bold, verbatim, italic, etc. they sit in the text. Semanti= cally, >> this doesn=E2=80=99t hold for `\[ ... \]' either. The semantically inlin= e maths element is >> `\( ... \)'. Considering other =E2=80=9Cinline=E2=80=9D syntax elements,= like bold, verbatim, >> italic, etc. if you spread the delimiters across multiple lines that doe= sn=E2=80=99t >> work. So I=E2=80=99d argue the ship has already sailed on treating `\[ .= .. \]' differently >> to other inline elements. > > I'm not sure about what you mean. \[...\] is no different than, e.g., > verbatim. It's an inline element, with all that it implies. 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. > Now, if you want to discuss changing syntax for \[...\] and make it > a block element, you can of course do it to your heart's content (it has > been discussed already in this ML and I don't have an opinion on the > subject), but please don't make filling do bizarre things (not all Org > users use LaTeX or even like LaTeXisms), just because LaTeX modes behave > differently. If that's the only way that Org could treat \[ ... \] differently from \( ... \), I'd be strongly in favour of this. >> If you=E2=80=99re wondering why I=E2=80=99m so opposed to the current be= haviour, that is probably >> best explained by a more realistic demo that what I have in the commit m= essage. >> [*snip*] > In every case above, you can already use > \begin{equation*}...\end{equation*}, so I don't see the point. I prefer \[ ... \] over \begin{equation*}...\end{equation*} as it's much more succinct, and helps reduce the "markup noise" in my documents. 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 f= or in syntax. > You already have all you need without breaking filling function for > the rest of us. 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. > I don't think it is a worse experience, unless you apply expectations > from LaTeX to Org. It just doesn't work. 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. > 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). > If you need to write or copy "advanced" LaTeX code, Org provides > dedicated environments. I don't want "advanced" LaTeX code, I just want my display equations to be treated as display equations consistently =F0=9F=98=82. Anyway, thanks for engaging with this Nicolas. Even if my patch is a bad idea, I hope that by the end of this conversation we may arrive at an agreement on how \[ ... \] should be treated. -- Timothy