From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id ICZ2Jf41W2F2tgAAgWs5BA (envelope-from ) for ; Mon, 04 Oct 2021 19:12:30 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id wGodIf41W2HQKwAA1q6Kng (envelope-from ) for ; Mon, 04 Oct 2021 17:12:30 +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 DE9AE3578D for ; Mon, 4 Oct 2021 19:12:29 +0200 (CEST) Received: from localhost ([::1]:45642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mXRVs-0000Y3-W8 for larch@yhetil.org; Mon, 04 Oct 2021 13:12:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37110) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXRV6-0000Xv-NS for emacs-orgmode@gnu.org; Mon, 04 Oct 2021 13:11:40 -0400 Received: from ciao.gmane.io ([116.202.254.214]:32972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mXRV5-0007jw-2e for emacs-orgmode@gnu.org; Mon, 04 Oct 2021 13:11:40 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mXRUz-0003Rz-EH for emacs-orgmode@gnu.org; Mon, 04 Oct 2021 19:11:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH] Don't fill displayed equations Date: Tue, 5 Oct 2021 00:11:24 +0700 Message-ID: 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> <87ilygo4uh.fsf@nicolasgoaziou.fr> <87a6jr3fq6.fsf@ucl.ac.uk> <87sfxjiumm.fsf@gmail.com> <87y27b1xga.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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: , 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=1633367550; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=5R39LfcmPUvK3qTMcrm8w+t9eigSkHieH2GWHBQS85g=; b=lxGmWH2og0uGV7Y1GGVQMY9g2/SBMmJ0UQI7gh41J3GkHb+Ibb7ro6t24GdzhS6iwkiEzl E8q0Q0qWlOHo2XOp5cz6HImISPHT8oSScOYbtpvWfowP1vkANBPYA5jFnXtjADP2Oh64Oo phqtUSK9oxCYhU1OLtFhVrFqDc+acyA0Gyyh9tDAaI6ZXWtUjhgUvLcHChxvqCDB+LXx4e 8zFM+E78avn0NvMnQdL0MpcNPXzF/I5rqakN/8g+dTIm0nW49VYkUOPfIwEou4g0NfwA5v Qlw/qAssCSx+/Ql9pNimmWCs1fiByCeBKhZPGtm5T71fwk1miY8lLgm2KQdINg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633367550; a=rsa-sha256; cv=none; b=ngS6fs3aeYJG4zVCmuqvLh27W6qz3IngOagjr52iokG3ZdCbSp6jeUQOBSZrsUrLuZxPGF h/CoMOnIiY36loDSFlNPMQt+BQ7CF84QmPrBVBSgj3hIGKkFShc6LCgO/CgjayleoJFlVH 20Z77hXXChgsZgRnhVb1N/HColoT/iXZJPhnc2vfzmp+ZCuVrwfQ5qHik0Fl+0BKClPVwe QAiQYcQqq51sO58Ani5e3nNKZFSOoOxXXJvP422A628hNpEIwvTCxXV/WseUtNVVf7gSUx 21OjekNkUqsXkRyq6uQYd3rz3+zh3VjcLPlyLZUvBcKYfhOnjjII30Mc1dFReQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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: -1.81 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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: DE9AE3578D X-Spam-Score: -1.81 X-Migadu-Scanner: scn0.migadu.com X-TUID: 7Iz2MB2f/USj My thanks to Ihor for the argument concerning code of (maybe external) exproters and to Tom for parser-related considerations. I think it is a kind of trade-off: breaking change vs. continuously breaking user experience. Do not worry too much, there is almost no chance that I will try to implement my plan, so current state will remain as is. In naive form my idea was: 1. Find the code where \( \) is parsed and remove \[ \] option 2. Find the place where \begin{equation} is handled and add \[ somewhere around. I fill some misunderstanding since some arguments has the form "it is too hard because it requires ..." where "..." exactly what I was going to discuss. On 04/10/2021 12:57, Tom Gillespie wrote: > >> Maybe you are right and Tom was actually assuming \begin{equation*}, not >> #+begin_export latex. > > Correct. My bad on that one. By the way, I realized that choice of "\begin{equation}" and not "#+begin_equation" is not clear to me. However it allows to pass \begin{equation} to LaTeX or HTML+MathJax transparently. >> Just as Timothy, I believe that \begin{equation*} is unnecessary verbose >> when \[ works *mostly* in a similar way. > > \begin{equation*} is absolutely required if you want to be able to include > newlines because \[ and \begin are not similar at all as far as parsing > is concerned. > > From the spec: https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Environments >> CONTENTS can contain anything but the “\end{NAME}” string. > The spec is not completely accurate since latex environments can't > contain a new heading, but the point is that latex environments are > elements, whereas \[ \] is an object. ^^^^^^^^^^^^ I was going to discuss namely this change. >> Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$, >> and \begin{env} ... \end{env} and constructs in Org to be consistent >> with LaTeX? > > For \begin and \end yes. For the others no. Unsure, but then forbidding \[ \] at all may result in less confusion then current state "inline object that is transformed to block element during export". Making \[ \] a special case for paragraph filling when it is inline object would be even more confusing. > I'm actually fairly certain that such a change should never be made > due to the recent changes in org link syntax. Specifically given how > \[ is used for escapes in links. https://orgmode.org/manual/Link-Format.html > This means that the only place you could reliably use \[ is at the start of a > new line preceded only by whitespace. However, if this were to happen then > pretty much every org document that uses \[ \] is at risk for being broken > because something that was once a single paragraph will now be multiple > paragraphs. Agree that context-dependent "\]" may cause problems. > If you need multiline use \begin \end, that is what they are there for, and they > fit better with org's general extensible approach to blocks. I would dearly love > to be able to have a single shorthand for src blocks that worked inline and > standalone, I do not suggest using \[ \] both for inline object and block elements. I hope that even if behavior of \[ \] inside paragraphs were not specified it would not break user files since it will be transparently passed to LaTeX or HTML. However, LaTeX exporter may escape them to have it literally in the output. > Consider the case where you have something like > > \[ something something > > more content > more content [[www.example.com/\]oops][evil link]] \] Frankly speaking, with Org I never sure in such cases whether everything inside \[ \] will be literally copied to LaTeX file or some some Org markup will be handled, so it is possible to insert something e.g. inside \text{}. > \[ a > > b \] > > \[ > a > b > \] > > a \[ b > > c \] d Similar variants exist for \begin{equation} \end{equation} > In short. Just not worth it. The value of TeX, markdown, reStructured text, Org is convenience to type in comparison with SGML&XML-based formats that are not really human friendly. In this sense \[ is noticeably better than \begin{equation*}.