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 ms11 with LMTPS id UI1SONygy15GIAAA0tVLHw (envelope-from ) for ; Mon, 25 May 2020 10:41:32 +0000 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 wF6tM9ygy16lVQAAbx9fmQ (envelope-from ) for ; Mon, 25 May 2020 10:41:32 +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 5DE1194014C for ; Mon, 25 May 2020 10:41:32 +0000 (UTC) Received: from localhost ([::1]:43286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdAXy-0004Rj-9w for larch@yhetil.org; Mon, 25 May 2020 06:41:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54018) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdAXc-0004Rb-Sq for emacs-orgmode@gnu.org; Mon, 25 May 2020 06:41:08 -0400 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]:36487) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jdAXb-00024v-P7; Mon, 25 May 2020 06:41:08 -0400 Received: by mail-pj1-x1029.google.com with SMTP id q24so8397745pjd.1; Mon, 25 May 2020 03:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:references:user-agent:in-reply-to :message-id:mime-version; bh=kHIaHblgCh0yj2meq7o7+MIfbXOO7tmPTWN317qtu7o=; b=j1Nmg6rMyjFW148mE7PD5sgD0bF/PLWt3jClcqIasWIdfRt+n3OiEE2jP34qc7anJr PMfOYgaq03xECaENlB4d8tEksBx+lhdx7d7xWjiCTZdMbhJYjyM0fM0apRwDPlsY7r/e hCx+shndcIYdswmJoZNT0ycL+aDecAXx+o2emgc5eFYZRblETUEiS8g5QtmY1OsLLTCI wZqdcFCZUkNcaswDO3uSvf5IH7b2503oKWTq4KTSEfdQxqUvk/xe2WG0xCHxzQq7upLr T5TMjHCQlhNgxu+9zL1zAbf8XP0K3td+32l+UQAm+StJSifhUSFZmBU8TDhmUecfZeGj rcdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:references:user-agent :in-reply-to:message-id:mime-version; bh=kHIaHblgCh0yj2meq7o7+MIfbXOO7tmPTWN317qtu7o=; b=Y4YmZj+Je9OacCSICesqP1/siLur9DzE67BwOkgUBK+0829p2rfbdvLzInswo+ImZG oFly3kUzynHSROA9tndbAzqKjCIT214SrsconV/R1p8iZ+LFMICldMd6Zpmac0aaBWj2 VZRY6/Wbp/GmgQkWc66KJT/nFFae5GSmNUaWtIny+BmWKyHGjQpmQPpe1Pp+WIjm/Ntw u478LDkhYMi0y48kGd3topQ0HsG/3uMGEk+xf34ge7pPGvtyFHDhNpz9mOTPsZyuXRwF +UtZcodEWEuQptxSk+sDe/B1U8JPkm5of677t9rzAtZQM9CHdTNyNiX/a1i10khV2xyY YmFA== X-Gm-Message-State: AOAM533gwZvFUqAYCpI52WmYiUcZ+sv0SYp2vnzgoKjS3SgZzZ0a2iFI NFwUOtajSe+mBLnaJzXblD0= X-Google-Smtp-Source: ABdhPJwwa6zt5HGaJEnvhymExwBIpDi6XgprBD6KA3Zi7gFyl6b34m7nx+CMvU/YcCZ7vcY7XN2JTg== X-Received: by 2002:a17:902:d3d4:: with SMTP id w20mr27424679plb.3.1590403265924; Mon, 25 May 2020 03:41:05 -0700 (PDT) Received: from localhost (180-150-91-8.b4965b.per.nbn.aussiebb.net. [180.150.91.8]) by smtp.gmail.com with ESMTPSA id m12sm8304796pjf.44.2020.05.25.03.41.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2020 03:41:05 -0700 (PDT) From: TEC To: Nicolas Goaziou Subject: Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \] Date: Mon, 25 May 2020 18:21:33 +0800 References: <87zh9xxrww.fsf@gmail.com> <4274FCF8-5304-4B55-9586-0C718DA388D3@getmailspring.com> <87r1v9ceml.fsf@nicolasgoaziou.fr> <871rn8gy40.fsf@gmail.com> <87ftbobbct.fsf@nicolasgoaziou.fr> <87zh9wfish.fsf@gmail.com> <87v9kkfhx9.fsf@gmail.com> <87y2pg9uzr.fsf@nicolasgoaziou.fr> User-agent: mu4e 1.4.6; emacs 26.3 In-reply-to: <87y2pg9uzr.fsf@nicolasgoaziou.fr> Message-ID: <877dx0guv6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=tecosaur@gmail.com; helo=mail-pj1-x1029.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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, HTML_MESSAGE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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: Bastien , "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=j1Nmg6rM; dmarc=fail reason="SPF not aligned (relaxed)" 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-Spam-Score: 0.09 X-TUID: 2wOauVlrqZIN --=-=-= Content-Type: text/plain --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =20 Nicolas Goaziou writes:=20 =20 > That would be undesirable. LaTeX fragments (inline type) and=20 > LaTeX environments (block type) are different beasts. This is=20 > clearly outside the scope of `org-edit-special' to move from one=20 > type to the other.=20 =20 Inline LaTeX, and Environments are indeed different. I failed to=20 consider that there may be additional complications if switching=20 an inline environment to an environment. Quite frankly I'm not too=20 sure how org handles an environment in the middle of a line. I'll=20 do some quick tests. I was also referring to \( \) =E2=86=92 \[ \] (inline to inline) as=20 something one could well want to change, in which case I don't=20 think this is a concern. Lastly, I feel like it may be a good idea to give some example ----- inline =E2=86=92 inline ::INITIAL \(\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial=20 z}{\partial x \partial y}} ... \)g ::CHANGE INLINE STYLE \[\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial=20 z}{\partial x \partial y}} ... \] ::END inline =E2=86=92 environment ::INITIAL \[ \alpha =3D \psi(0) \quad \beta =3D \psi(1) \quad \gamma =3D \psi(2) \] ::CHANGE STYLE \begin{align*}=20 \alpha &=3D \psi(0) \\ \beta &=3D \psi(1) \\ \psi &=3D \psi(2)=20 \end{align*} ::END=20 ----- However this ends up being implemented, I think it would be good=20 not to prevent the user from making these changes in the pop-up=20 edit buffer. > This is clearly outside the scope of `org-edit-special' to move=20 > from one type to the other. To be honest I don't quite see this point, in both cases it's just a LaTeX = buffer... --==-=-= Content-Type: multipart/related; boundary="===-=-=" --===-=-= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> That would be undesirable. LaTeX fragments (inline type) and LaTeX
> environments (block type) are different beasts. This is clearly outsid= e
> the scope of `org-edit-special’ to move from one type to the oth= er.

Inline LaTeX, and Environments are indeed different. I failed to consider t= hat
there may be additional complications if switching an inline environment to= an
environment. Quite frankly I’m not too sure how org handles an enviro= nment in
the middle of a line. I’ll do some quick tests.

I was also referring to \( \) =E2=86=92 \[ \] (inline to inline) as somethi= ng one could
well want to change, in which case I don’t think this is a concern.

Lastly, I feel like it may be a good idea to give some example

inline =E2=86=92 inline

::INITIAL
\(\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \)g
::CHANGE INLINE STYLE
\[\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \]
::END

inline =E2=86=92 environment

::INITIAL
\[ \alpha =3D \psi(0) \quad \beta =3D \psi(1) \quad \gamma =3D \psi(2) \]
::CHANGE STYLE

\begin{align*} \alpha &=3D \psi(0) \\ \beta &=3D \psi(1) \\=20 \psi &=3D \psi(2) \end{align*}

::END

However this ends up being implemented, I think it would be good not to pre= vent
the user from making these changes in the pop-up edit buffer.

> This is clearly outside the scope of `org-edit-special’ to move = from one type
> to the other.

To be honest I don’t quite see this point, in both cases it’s j= ust a LaTeX buffer…

--===-=-=-- --==-=-=-- --=-=-= Content-Type: multipart/related; boundary="====-=-=" --====-=-= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

<#multipart type=3Dalternative><#part type=3Dtext/plain>

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> That would be undesirable. LaTeX fragments (inline type) and LaTeX
> environments (block type) are different beasts. This is clearly outsid= e
> the scope of `org-edit-special’ to move from one type to the oth= er.

Inline LaTeX, and Environments are indeed different. I failed to consider t= hat
there may be additional complications if switching an inline environment to= an
environment. Quite frankly I’m not too sure how org handles an enviro= nment in
the middle of a line. I’ll do some quick tests.

I was also referring to \( \) =E2=86=92 \[ \] (inline to inline) as somethi= ng one could
well want to change, in which case I don’t think this is a concern.

Lastly, I feel like it may be a good idea to give some example

inline =E2=86=92 inline

::INITIAL
\(\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \)g
::CHANGE INLINE STYLE
\[\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \]
::END

inline =E2=86=92 environment

::INITIAL
\[ \alpha =3D \psi(0) \quad \beta =3D \psi(1) \quad \gamma =3D \psi(2) \]
::CHANGE STYLE

\begin{align*} \alpha &=3D \psi(0) \\ \beta &=3D \psi(1) \\=20 \psi &=3D \psi(2) \end{align*}

::END

However this ends up being implemented, I think it would be good not to pre= vent
the user from making these changes in the pop-up edit buffer.

> This is clearly outside the scope of `org-edit-special’ to move = from one type
> to the other.

To be honest I don’t quite see this point, in both cases it’s j= ust a LaTeX buffer…
<#multipart type=3Drelated><#part type=3Dtext/html><p> Nicolas Goaziou &lt;mail@nicolasgoaziou.fr&gt; writes:<br /><= br /> </p>

<p>
&gt; That would be undesirable. LaTeX fragments (inline type) and LaTeX= <br />
&gt; environments (block type) are different beasts. This is clearly ou= tside<br />
&gt; the scope of `org-edit-special&rsquo; to move from one type to= the other.<br />
</p>

<p>
Inline LaTeX, and Environments are indeed different. I failed to consider t= hat<br />
there may be additional complications if switching an inline environment to= an<br />
environment. Quite frankly I&rsquo;m not too sure how org handles an en= vironment in<br />
the middle of a line. I&rsquo;ll do some quick tests.<br />
</p>

<p>
I was also referring to \( \) =E2=86=92 \[ \] (inline to inline) as somethi= ng one could<br />
well want to change, in which case I don&rsquo;t think this is a concer= n.<br />
</p>

<p>
Lastly, I feel like it may be a good idea to give some example<br /><= br /> </p>

<hr />

<p>
inline =E2=86=92 inline<br />
</p>

<p>
::INITIAL<br />
\(\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \)g<br />
::CHANGE INLINE STYLE<br />
\[\epsilon_0 =3D \binom{n}{b} \sqrt{\alpha_2 + \frac{\partial z}{\partial x= \partial y}} ... \]<br />
::END<br />
</p>

<p>
inline =E2=86=92 environment<br />
</p>

<p>
::INITIAL<br />
\[ \alpha =3D \psi(0) \quad \beta =3D \psi(1) \quad \gamma =3D \psi(2) \]<br />
::CHANGE STYLE<br />
</p>

\begin{align*} \alpha &=3D \psi(0) \\ \beta &=3D \psi(1) \\=20 \psi &=3D \psi(2) \end{align*}

<p>
::END<br />
</p>

<hr />

<p>
However this ends up being implemented, I think it would be good not to pre= vent<br />
the user from making these changes in the pop-up edit buffer.<br /> </p>

<p>
&gt; This is clearly outside the scope of `org-edit-special&rsquo; = to move from one type<br />
&gt; to the other.<br />
</p>

<p>
To be honest I don&rsquo;t quite see this point, in both cases it&r= squo;s just a LaTeX buffer&#x2026;<br />
</p>
<#/multipart>
<#/multipart>

--====-=-=-- --=-=-=--