(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

Hello All!

I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me.
Shortly after that though, I was disappoint to discover that this didn't work with inline LaTeX equations \( … \) or LaTeX display equations \[ … \]. If it would be possible to account for this form of LaTeX too, that would be marvellous!
A brief note on me
Hola! Love the work that's gone on here, so first of all: thanks to all those who have helped make Org-mode so great 💖.
I'm a new-ish Emacs user (~5 months old) currently using Doom (which I'm finding very comfortable), and my only regret is not getting into this all earlier 😛

First email to this mailing list, so please let me know if I'm not quite following protocol or anything like that. Otherwise, this is the first of a few emails that I've been meaning to send off for a while now.
I'm also a uni student a few weeks off from exams so I am not able to really need to resist the urge to jump in and work on implementing these ideas. I should have significantly more time late june though :)
All the best,
Timothy


[-- Attachment #2: Type: text/html, Size: 3119 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

Timothy <tecosaur@gmail.com> writes:

> I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me.
> Shortly after that though, I was disappoint to discover that this
> didn't work with inline LaTeX equations \( … \) or LaTeX display
> equations \[ … \]. If it would be possible to account for this form of
> LaTeX too, that would be marvellous!

Luckily, this is trivial to implement. 

One needs to write a `org-edit-latex-fragment' function in "org-src.el",
which would be a mix between `org-edit-latex-environment' and
`org-edit-inline-src-code' (without all the Babel stuff).

The new function can then be installed in `org-edit-special' from
"org.el".

Unfortunately, no one so far volunteered to do it (*hint*).

> First email to this mailing list, so please let me know if I'm not
> quite following protocol or anything like that. 

Welcome!

> I'm also a uni student a few weeks off from exams so I am not able to
> really need to resist the urge to jump in and work on implementing
> these ideas. I should have significantly more time late june though :)

Great. For non-trivial (more than 15 locs) contributions to Org mode
(and more generally, to GNU projects), you need to sign FSF papers. You
might want to consider signing them beforehand.


Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

Hi Nicolas,

Thanks for the pointers. Taking your hint :P I took a look to see what I might be in for.
With your comments in mind I started by looking at org-edit-special, and managed to get as far as org-element--current-element: but at this point I'm stumped.

I'll look into getting FSF papers signed, it sounds like they may come in handy :)
Timothy

On May 19 2020, at 3:47 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Hello, Timothy writes: > I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me. > Shortly after that though, I was disappoint to discover that this > didn't work with inline LaTeX equations \( … \) or LaTeX display > equations \[ … \]. If it would be possible to account for this form of > LaTeX too, that would be marvellous! Luckily, this is trivial to implement. One needs to write a `org-edit-latex-fragment' function in "org-src.el", which would be a mix between `org-edit-latex-environment' and `org-edit-inline-src-code' (without all the Babel stuff). The new function can then be installed in `org-edit-special' from "org.el". Unfortunately, no one so far volunteered to do it (*hint*). > First email to this mailing list, so please let me know if I'm not > quite following protocol or anything like that. Welcome! > I'm also a uni student a few weeks off from exams so I am not able to > really need to resist the urge to jump in and work on implementing > these ideas. I should have significantly more time late june though :) Great. For non-trivial (more than 15 locs) contributions to Org mode (and more generally, to GNU projects), you need to sign FSF papers. You might want to consider signing them beforehand. Regards, -- Nicolas Goaziou


[-- Attachment #2: Type: text/html, Size: 2521 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> With your comments in mind I started by looking at org-edit-special,
> and managed to get as far as org-element--current-element: but at this
> point I'm stumped.

It sounds like you took the opposite route. I suggested to first write
a function, `org-edit-latex-fragment'.

Once done, you can insert it in `org-edit-special', but it boils down to
adding a line there, right below (`inline-src-block ...):

  (`latex-fragment (org-edit-latex-fragments))

You really don't need to mess with `org-element--current-element' for
this task.

> I'll look into getting FSF papers signed, it sounds like they may come
> in handy :)

Great!

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

Nicolas,

> It sounds like you took the opposite route. I suggested to first write a function, `org-edit-latex-fragment'.
I wanted to see how it would fit in first ¯\_(ツ)_/¯
> Once done, you can insert it in `org-edit-special', but it boils down to adding a line there, right below (`inline-src-block ...):
For that to work though, i.e. adding something of the form (latex-fragment ...) I'd want a `latex-fragment type to be returned from org-element-at-point wouldn't I?
At the moment running (org-element-at-point) inside \( … \) yields paragraph.

Can I really get away without modifying anything more than org-edit-special and writing org-edit-latex-fragment ?
Timothy

On May 19 2020, at 5:39 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Timothy writes: > With your comments in mind I started by looking at org-edit-special, > and managed to get as far as org-element--current-element: but at this > point I'm stumped. It sounds like you took the opposite route. I suggested to first write a function, `org-edit-latex-fragment'. Once done, you can insert it in `org-edit-special', but it boils down to adding a line there, right below (`inline-src-block ...): (`latex-fragment (org-edit-latex-fragments)) You really don't need to mess with `org-element--current-element' for this task. > I'll look into getting FSF papers signed, it sounds like they may come > in handy :) Great!


[-- Attachment #2: Type: text/html, Size: 2768 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

>> It sounds like you took the opposite route. I suggested to first write a function, `org-edit-latex-fragment'.
> I wanted to see how it would fit in first ¯\_(ツ)_/¯

Sure. That's a good way to learn stuff. In this case, it's not the
easiest one, though.

>> Once done, you can insert it in `org-edit-special', but it boils down to adding a line there, right below (`inline-src-block ...):

> For that to work though, i.e. adding something of the form
> (latex-fragment ...) I'd want a `latex-fragment type to be returned
> from org-element-at-point wouldn't I?

This is already done a few lines above in `org-edit-special', when
`org-element-context' is called.

LaTeX fragments are at a lower level than plain "elements", so
`org-element-at-point' does not see them.

> At the moment running (org-element-at-point) inside \( … \) yields
> paragraph.

See above.

> Can I really get away without modifying anything more than org-edit-special and writing org-edit-latex-fragment ?

Yes, you (we) can!

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> LaTeX fragments are at a lower level than plain "elements", so
> `org-element-at-point' does not see them.

I see. Might you be willing to do & show me the modifications needed to
use the `latex-fragment case?


>> Can I really get away without modifying anything more than
>> org-edit-special and writing org-edit-latex-fragment ?
> Yes, you (we) can!

Fantastic!

In other news, I have sent off am email to assign@gnu.org, so hopefully
you'll be able to accept >15 loc patches from me in the (near?) future :)

> Timothy <tecosaur@gmail.com> writes:
>  
>>> It sounds like you took the opposite route. I suggested to first
>>> write a function, `org-edit-latex-fragment'.
>> I wanted to see how it would fit in first ¯\_(ツ)_/¯
>  
> Sure. That's a good way to learn stuff. In this case, it's not the
> easiest one, though.
>  
>>> Once done, you can insert it in `org-edit-special', but it boils
>>> down to adding a line there, right below (`inline-src-block ...):
>  
>> For that to work though, i.e. adding something of the form
>> (latex-fragment ...) I'd want a `latex-fragment type to be returned
>> from org-element-at-point wouldn't I?
>  
> This is already done a few lines above in `org-edit-special', when
> `org-element-context' is called.
>  
> LaTeX fragments are at a lower level than plain "elements", so
> `org-element-at-point' does not see them.
>  
>> At the moment running (org-element-at-point) inside \( … \) yields
>> paragraph.
>  
> See above.
>  
>> Can I really get away without modifying anything more than
>> org-edit-special and writing org-edit-latex-fragment ?
>  
> Yes, you (we) can!
>

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> I see. Might you be willing to do & show me the modifications needed to
> use the `latex-fragment case?

I don't understand your question.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

>> I see. Might you be willing to do & show me the modifications needed to
>> use the `latex-fragment case?
> I don't understand your question.

In your original email you wrote
>>>> The new function can then be installed in `org-edit-special' from
>>>> "org.el" 

I can't quite see how I would insert this. Since it sounds relatively
simple, if you would be willing to cook up the necessary modification
for me that would be a great help.

On May 19 2020, at 10:09 pm, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> Timothy <tecosaur@gmail.com> writes:
> 
>> I see. Might you be willing to do & show me the modifications needed to
>> use the `latex-fragment case?
> 
> I don't understand your question.
> 

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> In your original email you wrote
>>>>> The new function can then be installed in `org-edit-special' from
>>>>> "org.el" 
>
> I can't quite see how I would insert this. Since it sounds relatively
> simple, if you would be willing to cook up the necessary modification
> for me that would be a great help.

I already did, didn't I?

In `org-edit-special', near the end (that is _after_ call to
`org-element-context') there's a line:

   (`inline-src-block (org-edit-inline-src-code))

Right after this line, i.e., as another case in the `pcase' pattern, you
would simply add:

   (`latex-fragment (org-edit-latex-fragment))

That's all for the changes required in `org-edit-special'.

Of course, you need to write `org-edit-latex-fragment' function in
"org-src.el" beforehand. I suggested examples to look at.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I already did, didn't I?
> ...
> That's all for the changes required in `org-edit-special'.

Oh ':) I thought that was just you saying 'it would be something along
the lines of...'

Thanks! I'll let you know when I have something.

> Timothy <tecosaur@gmail.com> writes:
> 
>> In your original email you wrote
>>>>>> The new function can then be installed in `org-edit-special' from
>>>>>> "org.el" 
>> 
>> I can't quite see how I would insert this. Since it sounds relatively
>> simple, if you would be willing to cook up the necessary modification
>> for me that would be a great help.
> 
> I already did, didn't I?
> 
> In `org-edit-special', near the end (that is _after_ call to
> `org-element-context') there's a line:
> 
>   (`inline-src-block (org-edit-inline-src-code))
> 
> Right after this line, i.e., as another case in the `pcase' pattern, you
> would simply add:
> 
>   (`latex-fragment (org-edit-latex-fragment))
> 
> That's all for the changes required in `org-edit-special'.
> 
> Of course, you need to write `org-edit-latex-fragment' function in
> "org-src.el" beforehand. I suggested examples to look at.
> 

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Bastien]

Hi Timothy,

thanks for the various feature requests!  It's always interesting to
discuss use cases and possible features.

Timothy <tecosaur@gmail.com> writes:

> I'm also a uni student a few weeks off from exams so I am not able to
>  really need to resist the urge to jump in and work on implementing
> these ideas. I should have significantly more time late june
> though :)

I hope you will have time to move forward with sending patches so that
we can discuss the feature proposals against something we can actually
test.

Thanks again,

-- 
 Bastien

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[tecosaur]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]


Bastien <bzg@gnu.org> writes:

> I hope you will have time to move forward with sending patches 
> so that
> we can discuss the feature proposals against something we can 
> actually
> test.
>
> Thanks again,

Don't worry, I haven't faded out of exitance! I've merely become 
(as usual)
distracted. In this case I've spend some time setting up mu4e 
(which I am now
sending this email from), which has been interesting. I think I'll 
like it.

I've also now completed the FSF copyright assignment. Let me know 
if you need
any details on that front.

I'm yet to look at what would be required for testing and 
submitting a patch
though. I'm thinking I could probably just try editing the source 
files for my
installed org versions. Since Doom uses github (pinned to a 
specific, usually
quite recent commits) instead of MELPA I imagine I should be able 
to use this to
produce patches which apply to master without issue.

No idea how to test, other that try it manually a few times. 
Hopefully you'll be
willing to help with that :)

All the best,

Timothy.

p.s. I recall a comment about distaste for HTML emails earlier, 
does that extend
to HTML+Plaintext multipart messages?

[-- Attachment #2.1: Type: text/html, Size: 1453 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Bastien]

tecosaur@gmail.com writes:

> Don't worry, I haven't faded out of exitance!

Well, I was not worried :)

> I've also now completed the FSF copyright assignment. Let me know if
> you need any details on that front.

If you confirm that the FSF confirmed that you're all set, then no.

> I'm yet to look at what would be required for testing and submitting
> a patch though.

See https://orgmode.org/worg/org-contribute.html

> I'm thinking I could probably just try editing the source files for
> my installed org versions.

Please clone like this:

~$ git clone https://code.orgmode.org/bzg/org-mode.git

and send patches as attachments to the mailing list.

> No idea how to test, other that try it manually a few times.

Before sending patches, run this from your org-mode directory:

~$ make test

This does not say that the patch is correct, so further discussions
are often needed, but it checks whether the patch breaks current tests
or not, which is already useful.

Thanks!

> p.s. I recall a comment about distaste for HTML emails earlier, does
> that extend to HTML+Plaintext multipart messages?

Yes, definitely.  Plain text is always better.

-- 
 Bastien

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

 
Bastien <bzg@gnu.org> writes: 
 
> I hope you will have time to move forward with sending patches 
> so that we can discuss the feature proposals against something 
> we can actually test. 

Well, I'm currently having a look at patching this, so this looks 
hopeful :)

I think I've got a mostly-functional `org-edit-latex-fragment', 
I'm just wrangling with `org-src--contents-area' complaining 
"Unsupported element or object: latex-fragment" at the moment.
            
I hope to have more soon!

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

 
TEC <tecosaur@gmail.com> writes: 
 
> Well, I'm currently having a look at patching this, so this 
> looks hopeful :) 

Done! Here's a first-pass patch. Please try it out and let me know 
what you think.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: text/x-patch, Size: 2329 bytes --]

From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments

---
 lisp/org-src.el | 19 +++++++++++++++++++
 lisp/org.el     |  1 +
 2 files changed, 20 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index c9eef744e..d648ce2c9 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,10 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	     (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t))))
 	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-element-property :end datum)))
+	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
 	     (end (org-element-property :contents-end datum)))
@@ -959,6 +963,21 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let ((context (org-element-context)))
+    (unless (and (eq (org-element-type context) 'latex-fragment)
+		 (org-src--on-datum-p context))
+      (user-error "Not on a LaTeX fragment"))
+    (pp (org-element-property :contents-begin context))
+    (org-src--edit-element
+     context
+     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+     (org-src-get-lang-mode "latex")
+     t)
+  t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index 40c3c46b9..0808fc210 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17347,6 +17347,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2


[-- Attachment #3.1: Type: text/html, Size: 515 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 259 bytes --]

> <#part type=“text/x-patch”
> filename=“home/tec.emacs.d/.local/straight/repos/org-mode/0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch” disposition=attachment>
> <#/part>

Well that didn't quite work as intended. Here's a take two.

[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: application/octet-stream, Size: 2329 bytes --]

From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments

---
 lisp/org-src.el | 19 +++++++++++++++++++
 lisp/org.el     |  1 +
 2 files changed, 20 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index c9eef744e..d648ce2c9 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,10 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	     (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t))))
 	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-element-property :end datum)))
+	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
 	     (end (org-element-property :contents-end datum)))
@@ -959,6 +963,21 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let ((context (org-element-context)))
+    (unless (and (eq (org-element-type context) 'latex-fragment)
+		 (org-src--on-datum-p context))
+      (user-error "Not on a LaTeX fragment"))
+    (pp (org-element-property :contents-begin context))
+    (org-src--edit-element
+     context
+     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+     (org-src-get-lang-mode "latex")
+     t)
+  t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index 40c3c46b9..0808fc210 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17347,6 +17347,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

Timothy <tecosaur@gmail.com> writes:

> Well that didn't quite work as intended. Here's a take two.

This doesn't look bad. Thank you.

> From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001
> From: TEC <tec@tecosaur.com>
> Date: Sun, 24 May 2020 23:35:33 +0800
> Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments

In the commit message, you need to list functions being modified. See
other commits messages for some examples.

> +      ((eq type 'latex-fragment)
> +       (let ((beg (org-element-property :begin datum))
> +	     (end (org-element-property :end datum)))
> +	 (list beg end (buffer-substring-no-properties beg end))))

These are not correct buffer positions. BEG and END should be between
"\(" and "\)" (or "$" and "$", or…). See, in the same function, how
inline source blocks are handled.

> +    (pp (org-element-property :contents-begin context))

It is a left-over.

> +    (org-src--edit-element
> +     context
> +     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
> +     (org-src-get-lang-mode "latex")
> +     t)
> +  t))

You also need to put read-only property on fragment markers, and remove
any blank line as the final step. See `org-edit-footnote-reference'.

>  	 (pcase (org-element-type context)
>  	   (`footnote-reference (org-edit-footnote-reference))
>  	   (`inline-src-block (org-edit-inline-src-code))
> +	   (`latex-fragment (org-edit-latex-fragment))

This line is perfect ;)

Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
> Hello, 
> 
> Timothy <tecosaur@gmail.com> writes: 
> 
>> Well that didn't quite work as intended. Here's a take two. 
> 
> This doesn't look bad. Thank you. 
 
> In the commit message, you need to list functions being 
> modified. See other commits messages for some examples.

I'll patch my patch :P 
 
>> +      ((eq type 'latex-fragment) +       (let ((beg 
>> (org-element-property :begin datum)) +	     (end 
>> (org-element-property :end datum))) +	 (list beg end 
>> (buffer-substring-no-properties beg end)))) 
> 
> These are not correct buffer positions. BEG and END should be 
> between "\(" and "\)" (or "$" and "$", or…). See, in the same 
> function, how inline source blocks are handled.

I thought that too initially. The think is you actually want them 
in the LaTeX buffer so they get treated as mathematics instead of 
text. 
 
>> +    (org-src--edit-element +     context + 
>> (org-src--construct-edit-buffer-name (buffer-name) "LaTeX 
>> fragment") +     (org-src-get-lang-mode "latex") +     t) + 
>> t)) 
> 
> You also need to put read-only property on fragment markers, and 
> remove any blank line as the final step. See 
> `org-edit-footnote-reference'. 

I'll take a look :)
 
>>  	 (pcase (org-element-type context) (`footnote-reference 
>>  (org-edit-footnote-reference)) (`inline-src-block 
>>  (org-edit-inline-src-code)) 
>> +	   (`latex-fragment (org-edit-latex-fragment)) 
> 
> This line is perfect ;)

I must have had great inspiration for it ;-)

Regards,

Timothy.

[-- Attachment #2.1: Type: text/html, Size: 2217 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

TEC <tecosaur@gmail.com> writes:

> I thought that too initially. The think is you actually want them in the LaTeX
> buffer so they get treated as mathematics instead of text.

Indeed!

Still, END is not correct, because it includes white space after the
object. So, you probably need something like:

  (end (org-with-point-at (org-element-property :end datum)
        (skip-chars-backward " \t")
        (point)))

Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
> You also need to put read-only property on fragment markers, and 
> remove any blank line as the final step. See 
> `org-edit-footnote-reference'. 

I'm trying to work out what it is that should be happening with 
this. Looking at `org-edit-footnote-reference', as you pointed me 
to, and `org-edit-inline-src': I'm not sure what functionality 
you're looking for is.
Would you mind explaining a bit more?

Thanks,

Timothy.

[-- Attachment #2.1: Type: text/html, Size: 616 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> I’m trying to work out what it is that should be happening with this. Looking at
> `org-edit-footnote-reference’, as you pointed me to, and
> `org-edit-inline-src’:

From `org-edit-footnote-reference':

--8<---------------cut here---------------start------------->8---
(add-text-properties
 0
 (progn (string-match (if inline? "\\`\\[fn:.*?:" "\\`.*?\\]") contents)
        (match-end 0))
 '(read-only "Cannot edit footnote label" front-sticky t rear-nonsticky t)
 contents)
 (when inline?
  (let ((l (length contents)))
    (add-text-properties
     (1- l) l
     '(read-only "Cannot edit past footnote reference"
  	       front-sticky nil rear-nonsticky nil)
     contents)))
--8<---------------cut here---------------end--------------->8---

The equivalent code will prevent a user from changing, deleting the
LaTeX markers, or writing past them : this is not the purpose of the
functionality.

In the same function:

(lambda ()
 (if (not inline?) (delete-region (point) (search-forward "]"))
   (delete-region (point) (search-forward ":" nil t 2))
   (delete-region (1- (point-max)) (point-max))
   (when (re-search-forward "\n[ \t]*\n" nil t)
     (user-error "Inline definitions cannot contain blank lines"))
   ;; If footnote reference belongs to a table, make sure to
   ;; remove any newline characters in order to preserve
   ;; table's structure.
   (when (org-element-lineage definition '(table-cell))
     (while (search-forward "\n" nil t) (replace-match "")))))

LaTeX fragments should not break paragraphs, or tables. So you need to
prevent inserting blank lines, or even newlines characters in the case
of tables.

Regards,

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 364 bytes --]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
> The equivalent code will prevent a user from changing, deleting 
> the LaTeX markers, or writing past them : this is not the 
> purpose of the functionality. 

That's most helpful, thanks :)

I'l have a look at that now, in the mean time here's what I hope 
will be the penultimate version of this patch :D


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: text/x-patch, Size: 2936 bytes --]

From 748c20d65df9cd0ae9f9f80c2bb5ee87aea101e4 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
 new function, `org-edit-latex-fragment' which is hooked into
 `org-edit-special', modifying `org-src--contents-area-modified' to recognise
 the element type.

---
 lisp/org-src.el | 29 +++++++++++++++++++++++++++--
 lisp/org.el     |  1 +
 2 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index c9eef744e..d41879c09 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -360,8 +360,13 @@ where BEG and END are buffer positions and CONTENTS is a string."
       ((eq type 'inline-src-block)
        (let ((beg (progn (goto-char (org-element-property :begin datum))
 			 (search-forward "{" (line-end-position) t)))
-	     (end (progn (goto-char (org-element-property :end datum))
-			 (search-backward "}" (line-beginning-position) t))))
+	     (end (org-with-point-at (org-element-property :end datum)
+		    (skip-chars-backward " \t")
+		    (point))))
+	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-element-property :end datum)))
 	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
@@ -959,6 +964,26 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let ((context (org-element-context)))
+    (unless (and (eq (org-element-type context) 'latex-fragment)
+		 (org-src--on-datum-p context))
+      (user-error "Not on a LaTeX fragment"))
+    (org-src--edit-element
+     context
+     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+     (org-src-get-lang-mode "latex")
+     (lambda () ; trim content
+       (goto-char (point-min))
+       (skip-chars-forward " \t")
+       (delete-region (point-min) (point))
+       (goto-char (point-max))
+       (skip-chars-backward " \t")
+       (delete-region (point) (point-max))))
+  t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index dcd446745..2f5b89231 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17340,6 +17340,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2


[-- Attachment #3.1: Type: text/html, Size: 712 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 612 bytes --]


One other quick comment

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> LaTeX fragments should not break paragraphs, or tables. So you 
> need to
> prevent inserting blank lines, or even newlines characters in 
> the case
> of tables.

I don't think we need to worry about newlines, particularly as 
this only applies
to elements which are not defined by a \begin{env} \end{env} 
block, ruling
tables out :P

Another query from me, with something like a blank line, why is a 
user-error
raised? Surely just strip blank lines from the buffer? I can't 
think of any
situation where this would be undesirable.

[-- Attachment #2.1: Type: text/html, Size: 730 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>> LaTeX fragments should not break paragraphs, or tables. So you need to
>> prevent inserting blank lines, or even newlines characters in the case
>> of tables.
>
> I don’t think we need to worry about newlines, 

We need to.

  | some  | table    |
  | LaTeX | $1 + 1$  |

Here, when editing "$1 + 1$", you certainly don't want to insert
a newline character.

Likewise

  Some $1+1$ paragraph

is very different from

  Some $1+

  1$ paragraph

> Another query from me, with something like a blank line, why is a user-error
> raised? Surely just strip blank lines from the buffer? I can’t think of any
> situation where this would be undesirable.

Some blank lines are meaningful in Org, so removing them could change
the structure of the input. I wasn't sure it was a good idea to do this
on user's behalf. 

The code should also prevent footnote definitions to contain two
consecutive blank lines. But that's another story.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
>> I don’t think we need to worry about newlines,  
> 
> We need to. 
> 
>   | some  | table    | | LaTeX | $1 + 1$  | 

Oh dear, I haden't considered that. This is beginning to sound 
complicated :sweat_smile:

Just saying 'no' to new lines seems like a possible solution, but 
long equations can often be deperate for newlines when it comes to 
readability.

> Some blank lines are meaningful in Org, so removing them could 
> change the structure of the input. I wasn't sure it was a good 
> idea to do this on user's behalf.  

I see. I'm not quite sure how Org could get inside a LaTeX fragment though..?

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> Just saying 'no' to new lines seems like a possible solution, but long
> equations can often be deperate for newlines when it comes to
> readability.

Saying no to new lines is only necessary in tables.  Outside, we only
need to say no to blank lines.

Note that you cannot preserve newlines in a LaTeX fragment. For example,
filling a paragraph containing a LaTeX fragment could modify newlines.

>> Some blank lines are meaningful in Org, so removing them could
>> change the structure of the input. I wasn't sure it was a good idea
>> to do this on user's behalf.  
>
> I see. I'm not quite sure how Org could get inside a LaTeX fragment
> though..?

I was talking about footnote reference stuff. Perhaps removing silently
blank lines, here or in both cases, is better. I have no strong opinion
about it.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
>> Just saying 'no' to new lines seems like a possible solution, 
>> but long equations can often be deperate for newlines when it 
>> comes to readability. 
> 
> Saying no to new lines is only necessary in tables.  Outside, we 
> only need to say no to blank lines.

This is what I thought. Might you have any suggestions on how I 
incorporate this logic? Something like `org-in-table-p' would be 
ideal :D
 
> I was talking about footnote reference stuff. Perhaps removing 
> silently blank lines, here or in both cases, is better. I have 
> no strong opinion about it. 
 
I feel like, at least in this case, this would be a sensible way 
to go.
If you're happy with this, I think I'll go ahead and give this approach a shot.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> This is what I thought. Might you have any suggestions on how
> I incorporate this logic? Something like `org-in-table-p' would be
> ideal :D

This is the following part, in `org-edit-footnote-reference':

--8<---------------cut here---------------start------------->8---
;; If footnote reference belongs to a table, make sure to
;; remove any newline characters in order to preserve
;; table's structure.
(when (org-element-lineage definition '(table-cell))
  (while (search-forward "\n" nil t) (replace-match "")))
--8<---------------cut here---------------end--------------->8---

You need to replace `definition' with the actual LaTeX object.

Replacing "\n" with "", as above, is too strong BTW. It would be better
to replace it with " ". I'll fix the footnote-reference part.

> I feel like, at least in this case, this would be a sensible way to
> go. If you're happy with this, I think I'll go ahead and give this
> approach a shot.

Sure, go ahead.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2.1: Type: text/plain, Size: 357 bytes --]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
 
> This is the following part, in `org-edit-footnote-reference':

Thanks. Sorry I'm having you repeat yourself. 

> Replacing "\n" with "", as above, is too strong BTW. It would be 
> better to replace it with " ". I'll fix the footnote-reference 
> part.

Sounds sensible.

> Sure, go ahead.

Will do :)

[-- Attachment #2.2.1: Type: text/html, Size: 532 bytes --]

[-- Attachment #3.1: Type: text/html, Size: 1634 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]


I've had another thought :)

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> The equivalent code will prevent a user from changing, deleting
>> the LaTeX markers, or writing past them : this is not the
>> purpose of the functionality.
>
> That's most helpful, thanks :)
>
> I'l have a look at that now, in the mean time here's what I hope
> will be the penultimate version of this patch :D

Thinking about this a bit more, I think this may not actually be 
desirable
behaviour.

Why? I considered the case where I've been writing a growing 
inline equation \( \),
realised it should be displayed as an equation instead with \[ \] 
and edited the
LaTeX marks such. I have had similar experiences where while 
editing an equation
\[ \] I've realised it should instead be \begin{align*} 
\end{align*}.

Were the boundary made read-only, I'd have to:
 - pause editing the mathematics
 - move to the start/end of the fragment in the org buffer, and 
 edit accordingly
 - re-start org-edit-latex-fragment/environment on the tweaked 
 LaTeX

In my opinion the potential hassle introduced by this outweighs 
the safety in
not being able to modify the LaTeX deliminators.

Let me know what you think.

Timothy

[-- Attachment #2.1: Type: text/html, Size: 1552 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> Thinking about this a bit more, I think this may not actually be desirable
> behaviour.
>
> Why? I considered the case where I’ve been writing a growing inline equation \( \),
> realised it should be displayed as an equation instead with \[ \] and edited the
> LaTeX marks such. I have had similar experiences where while editing an equation
> \[ \] I’ve realised it should instead be \begin{align*} \end{align*}.
>
> Were the boundary made read-only, I’d have to:
>
> * pause editing the mathematics
> * move to the start/end of the fragment in the org buffer, and edit accordingly
> * re-start org-edit-latex-fragment/environment on the tweaked LaTeX
>
> In my opinion the potential hassle introduced by this outweighs the safety in
> not being able to modify the LaTeX deliminators.
>
> Let me know what you think.

That would be undesirable. LaTeX fragments (inline type) and LaTeX
environments (block type) are different beasts. This is clearly outside
the scope of `org-edit-special' to move from one type to the other.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2.1: Type: text/plain, Size: 1643 bytes --]

 
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 outside the scope of `org-edit-special' to move from one 
> type to the other. 
 
Inline LaTeX, and Environments are indeed different. I failed to 
consider that there may be additional complications if switching 
an inline environment to an environment. Quite frankly I'm not too 
sure how org handles an environment in the middle of a line. I'll 
do some quick tests.

I was also referring to \( \) → \[ \] (inline to inline) as 
something 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 → inline

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

inline → environment

::INITIAL
\[
  \alpha = \psi(0) \quad \beta = \psi(1) \quad \gamma = \psi(2)
\]
::CHANGE STYLE
\begin{align*} 
  \alpha &= \psi(0) \\ \beta &= \psi(1) \\  \psi &= \psi(2) 
\end{align*}
::END 

-----

However this ends up being implemented, I think it would be good 
not to prevent 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 just a LaTeX buffer...

[-- Attachment #2.2.1: Type: text/html, Size: 1992 bytes --]

[-- Attachment #3.1: Type: text/html, Size: 5056 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> <#multipart type=alternative><#part type=text/plain>

Please don't send HTML.

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

You cannot have an environment in the middle of a line.

> I was also referring to \( \) → \[ \] (inline to inline) as something one could
> well want to change, in which case I don’t think this is a concern.

Yes, this particular change would be harmless. But you don't need
`org-edit-special' to change that. Moreover you cannot allow this
without allowing any change. So, let's not do that.

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

No, it's not. It is a part of an Org document that happens to be handled
by LaTeX. IOW, there is context around the object that doesn't belong to
LaTeX.

`org-edit-special' focuses on contents, not structure. For example, you
cannot change the number of the footnote definition being edited from
`org-edit-special'. This should also be the case here.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

Nicolas <mail@nicolasgoaziou.fr> writes:

>> <#multipart type=alternative><#part type=text/plain>
>  
> Please don't send HTML.

Appologies, I'm trying to use org-msg for emails, which should be off
for replying to plaintext, but I seem to have odd things happen now and
then ... as you have noticed.

So, I'm trying to keep things plaintext, but unfortunately there
everything isn't quite functioning as intended (for example, mu4e was
unable to open this email, and I have no idea why).

While I may be spending too much time on Email and not enough on Org :P
I'd be interested to hear what the aversion to mime multipart is? I have
only a basic working understanding, but my impression was that in
functioned as a 'best of both worlds' type thing.


> Yes, this particular change would be harmless. But you don't need
> `org-edit-special' to change that. Moreover you cannot allow this
> without allowing any change. So, let's not do that.
>  
>> To be honest I don’t quite see this point, in both cases it’s just
>> a LaTeX buffer…
>  
> No, it's not. It is a part of an Org document that happens to be handled
> by LaTeX. IOW, there is context around the object that doesn't belong to
> LaTeX.
>  
> `org-edit-special' focuses on contents, not structure. For example, you
> cannot change the number of the footnote definition being edited from
> `org-edit-special'. This should also be the case here.

Heh. And I was most of the way through tweaking
`org-edit-latex-fragment' to detech when inline was changed to an
environment and insert newlines if necesary to ensure that the \begin
and \end statements are on their own line.

I neglected to consider that org is likely doing context caching etc.
and so complicating things. I still like the idea that this can be
changed in the minibuffer (in my case because I have nice LaTeX-mode
configurations for changing these sorts of things more easily that I do
in org mode). However I don't like the sound of the extra complexity any
more than you do. I'll leave this be, and see if I can get the read-only
locking working for now :) I think I've got everything else as it should
be, so I should be sending in a patch for feedback shortly :)

Timothy.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 99 bytes --]

 
Here we go, I think I got everything. Please give this a 
test-drive and let me know how it is!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: text/x-patch, Size: 3664 bytes --]

From fc91322e9f8e47484767b66fb9f438d3326ccc08 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
 new function, `org-edit-latex-fragment' which is hooked into
 `org-edit-special', modifying `org-src--contents-area-modified' to recognise
 the element type.

---
 lisp/org-src.el | 45 +++++++++++++++++++++++++++++++++++++++++++++
 lisp/org.el     |  1 +
 2 files changed, 46 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index c9eef744e..3be0793a8 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,12 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	     (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t))))
 	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-with-point-at (org-element-property :end datum)
+		    (skip-chars-backward " \t")
+		    (point))))
+	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
 	     (end (org-element-property :contents-end datum)))
@@ -959,6 +965,45 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let* ((context (org-element-context))
+	 (_ (unless (and (eq (org-element-type context) 'latex-fragment)
+			 (org-src--on-datum-p context))
+	      (user-error "Not on a LaTeX fragment")))
+    ;; Grab the LaTeX fragment for propertization
+	 (contents (buffer-substring-no-properties
+		    (org-element-property :begin context)
+		    (- (org-element-property :end context)
+		       (org-element-property :post-blank context))))
+	 (delim-length (if (string-match "\\$[^$]" (substring contents 0 2))
+			   1 2)))
+    ;; make the LaTeX deliminators read-only
+    (add-text-properties
+       0 delim-length
+       '(read-only "Cannot edit LaTeX deliminator" front-sticky t rear-nonsticky t)
+       contents)
+    (add-text-properties
+       (- (length contents) delim-length)
+       (length contents)
+       '(read-only "Cannot edit LaTeX deliminator" front-sticky nil rear-nonsticky nil)
+       contents)
+    (org-src--edit-element
+     context
+     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+     (org-src-get-lang-mode "latex")
+     (lambda ()
+       ;; Blank lines break things, replace with a single newline
+       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
+       ;; If within a table a newline would disrupt the structure,
+       (goto-char (point-min))
+       (when (org-element-lineage context '(table-cell))
+	 (while (search-forward "\n" nil t) (replace-match " ")))
+       )
+     contents)
+  t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index dcd446745..2f5b89231 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17340,6 +17340,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2


[-- Attachment #3.1: Type: text/html, Size: 362 bytes --]

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

TEC <tecosaur@gmail.com> writes:

> ---
>  lisp/org-src.el | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  lisp/org.el     |  1 +
>  2 files changed, 46 insertions(+)

Thank you. It looks fine, I will only be nitpicking.

> +(defun org-edit-latex-fragment ()
> +  "Edit LaTeX fragment at point."
> +  (interactive)
> +  (let* ((context (org-element-context))
> +	 (_ (unless (and (eq (org-element-type context) 'latex-fragment)
> +			 (org-src--on-datum-p context))
> +	      (user-error "Not on a LaTeX fragment")))

This is a fancy way to use a let-binding. I suggest to mimic what is
done elsewhere, i.e., first bind `context', then check if we're at
a LaTeX fragment, then bind the rest.

> +    ;; Grab the LaTeX fragment for propertization

Missing full stop at the end of the comment.

> +	 (contents (buffer-substring-no-properties
> +		    (org-element-property :begin context)
> +		    (- (org-element-property :end context)
> +		       (org-element-property :post-blank context))))
> +	 (delim-length (if (string-match "\\$[^$]" (substring contents 0 2))

Use 

    (string-match "\\`\\$[^$]" contents)

instead.

or, arguably better,

    (string-match (rx (seq string-start "$" (not (any "$")))) 
                  contents)

> +			   1 2)))
> +    ;; make the LaTeX deliminators read-only

Missing initial capital and final full stop.

> +    (add-text-properties
> +       0 delim-length
> +       '(read-only "Cannot edit LaTeX deliminator" front-sticky t rear-nonsticky t)
> +       contents)
> +    (add-text-properties
> +       (- (length contents) delim-length)
> +       (length contents)
> +       '(read-only "Cannot edit LaTeX deliminator" front-sticky nil rear-nonsticky nil)
> +       contents)

You could factor out (length contents) so it is only called once.

> +    (org-src--edit-element
> +     context
> +     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
> +     (org-src-get-lang-mode "latex")
> +     (lambda ()
> +       ;; Blank lines break things, replace with a single newline

See above.

> +       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
> +       ;; If within a table a newline would disrupt the structure,

This comment is truncated.

> +       (goto-char (point-min))
> +       (when (org-element-lineage context '(table-cell))
> +	 (while (search-forward "\n" nil t) (replace-match " ")))
> +       )

Don't leave parenthesis alone.

Also, make sure your indentation is right, e.g., using M-q on the
definition.

You also need to add a proper commit message and use `git format-patch',
and an entry in ORG-NEWS (probably in Miscellaneous part).

Bonus points if you can add some tests in
"testing/lisp/test-org-src.el".

Could you remind me if you signed the FSF papers already?

Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 3366 bytes --]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Thank you. It looks fine, I will only be nitpicking.

Nitpick away :D

>> +(defun org-edit-latex-fragment ()
>> +  "Edit LaTeX fragment at point."
>> +  (interactive)
>> +  (let* ((context (org-element-context))
>> +	 (_ (unless (and (eq (org-element-type context) 'latex-fragment)
>> +			 (org-src--on-datum-p context))
>> +	      (user-error "Not on a LaTeX fragment")))
> 
> This is a fancy way to use a let-binding. I suggest to mimic what is
> done elsewhere, i.e., first bind `context', then check if we're at
> a LaTeX fragment, then bind the rest.

I had a look at that, to me this was cleaner than using multiple let
bindings, like so

(let ((context ...))
  (unless  ... user error)
  (let* ((contents ...)
         (delim-length ...))
   ...

vs.

(let* ((context ...)
       (_ (unless ... user error))
       (contents ...)
       (delim-length ...))
 ...
       
Personally I find the second one nicer. Thoughts?

>> +    ;; Grab the LaTeX fragment for propertization
> 
> Missing full stop at the end of the comment.

Fixed!

> 
>> +	 (contents (buffer-substring-no-properties
>> +		    (org-element-property :begin context)
>> +		    (- (org-element-property :end context)
>> +		       (org-element-property :post-blank context))))
>> +	 (delim-length (if (string-match "\\$[^$]" (substring contents 0 2))
> 
> Use 
> 
>    (string-match "\\`\\$[^$]" contents)
> 
> instead.
> 
> or, arguably better,
> 
>    (string-match (rx (seq string-start "$" (not (any "$")))) 
>                  contents)
> 
>> +			   1 2)))
>> +    ;; make the LaTeX deliminators read-only

I've changed to (string-match-p "\\`\\$[^$]" contents), as this seems
like the idiomatic form, let me know if you're happy with this.

I'm not actually sure what's going on with your second suggested form,
or why that may be better. If you'd mind explaining, that would be
appriciated :)
 
> Missing initial capital and final full stop.

Fixed!

> You could factor out (length contents) so it is only called once.

I'm not sure if this a big deal, but I shoved it in the let* for now,
let me know if that suffices.

>> +    (org-src--edit-element
>> +     context
>> +     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
>> +     (org-src-get-lang-mode "latex")
>> +     (lambda ()
>> +       ;; Blank lines break things, replace with a single newline
> 
> See above.

I'm not quite sure what I should see? I don't notice anything to factor
out here.

> 
>> +       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
>> +       ;; If within a table a newline would disrupt the structure,
> 
> This comment is truncated.

Added ", so remove newlines"

> Don't leave parenthesis alone.

Fixed!

> Also, make sure your indentation is right, e.g., using M-q on the
> definition.

I've applied auto-indent to `org-edit-latex-fragment'

> You also need to add a proper commit message and use `git format-patch',
> and an entry in ORG-NEWS (probably in Miscellaneous part).

I recall being asked to list modified/added functions, what else do I need?

> Bonus points if you can add some tests in
> "testing/lisp/test-org-src.el".

I'll have a look at that, but I'm not quite sure what to do.

> Could you remind me if you signed the FSF papers already?

They're done and dusted :)

Regards,

Timothy.

[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: application/octet-stream, Size: 3689 bytes --]

From bb494ebfd541343d3f42c312a2efcba5e3cac543 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
 new function, `org-edit-latex-fragment' which is hooked into
 `org-edit-special', modifying `org-src--contents-area-modified' to recognise
 the element type.

---
 lisp/org-src.el | 45 +++++++++++++++++++++++++++++++++++++++++++++
 lisp/org.el     |  1 +
 2 files changed, 46 insertions(+)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 1643607e4..ebc443a16 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,12 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	     (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t))))
 	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-with-point-at (org-element-property :end datum)
+		    (skip-chars-backward " \t")
+		    (point))))
+	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
 	     (end (org-element-property :contents-end datum)))
@@ -959,6 +965,45 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let* ((context (org-element-context))
+	 (_ (unless (and (eq (org-element-type context) 'latex-fragment)
+			 (org-src--on-datum-p context))
+	      (user-error "Not on a LaTeX fragment")))
+	 ;; Grab the LaTeX fragment for propertization.
+	 (contents (buffer-substring-no-properties
+		    (org-element-property :begin context)
+		    (- (org-element-property :end context)
+		       (org-element-property :post-blank context))))
+	 (contents-length (length contents))
+	 (delim-length (if (string-match-p "\\`\\$[^$]" contents))
+		       1 2))
+    ;; Make the LaTeX deliminators read-only.
+    (add-text-properties
+     0 delim-length
+     '(read-only "Cannot edit LaTeX deliminator" front-sticky t rear-nonsticky t)
+     contents)
+    (add-text-properties
+     (- contents-length delim-length)
+     contents-length
+     '(read-only "Cannot edit LaTeX deliminator" front-sticky nil rear-nonsticky nil)
+     contents)
+    (org-src--edit-element
+     context
+     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+     (org-src-get-lang-mode "latex")
+     (lambda ()
+       ;; Blank lines break things, replace with a single newline
+       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
+       ;; If within a table a newline would disrupt the structure, so remove newlines
+       (goto-char (point-min))
+       (when (org-element-lineage context '(table-cell))
+	 (while (search-forward "\n" nil t) (replace-match " "))))
+     contents)
+    t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index 40c3c46b9..0808fc210 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17347,6 +17347,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> I had a look at that, to me this was cleaner than using multiple let
> bindings, like so
>
> (let ((context ...))
>   (unless  ... user error)
>   (let* ((contents ...)
>          (delim-length ...))
>    ...
>
> vs.
>
> (let* ((context ...)
>        (_ (unless ... user error))
>        (contents ...)
>        (delim-length ...))
>  ...
>        
> Personally I find the second one nicer. Thoughts?

Without hesitation, the first form is nicer. The second one is just
abusing let-binding. I die a little just by looking at it.

> I've changed to (string-match-p "\\`\\$[^$]" contents), as this seems
> like the idiomatic form, let me know if you're happy with this.

the "-p" part is not warranted here. In Emacs, every function is
expected to modify match data, unless specified in the docstring. Since
there is a cost in preserving match-data, we shouldn't do it without
a good reason. Here, there isn't.

Note that you'll find a zillion of places in Org code base that
contradict the above. But, hey, nobody's perfect.

> I'm not actually sure what's going on with your second suggested form,
> or why that may be better. If you'd mind explaining, that would be
> appriciated :)

See `rx' macro. S-exp regexps are usually easier to read (after an
initial struggle), and less likely to introduce subtle bugs. For long
regexps, this is important. For this one, either way is fine.

>> You could factor out (length contents) so it is only called once.
>
> I'm not sure if this a big deal, 

This is not a big deal, but poor practice, IMO.

> but I shoved it in the let* for now, let me know if that suffices.

Well. Ideally, let-binding should enclose the minimum part of the code
that needs the binding. Sometimes, an exception is tolerated, because
the code would contain too many nested let-forms. But, conversely, you
shouldn't stuff every local variable at the beginning of the function
and be done with it.

In this particular case, there's no reason to stuff the `length' call at
the top of the function when you need it later on, on a well-defined
S-exp. IOW, it is more idiomatic to just add a let-binding around the
appropriate (add-text-properties ...).

>>> +    (org-src--edit-element
>>> +     context
>>> +     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
>>> +     (org-src-get-lang-mode "latex")
>>> +     (lambda ()
>>> +       ;; Blank lines break things, replace with a single newline
>> 
>> See above.
>
> I'm not quite sure what I should see? I don't notice anything to factor
> out here.

It was just about the missing full stop. You looked at the moon, but
I really was the fool showing the tip of his finger ;)

>>> +       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
>>> +       ;; If within a table a newline would disrupt the structure,
>> 
>> This comment is truncated.
>
> Added ", so remove newlines"

But it should be ", so remove newlines."

> I recall being asked to list modified/added functions, what else do
> I need?

Nothing else.

>> Bonus points if you can add some tests in
>> "testing/lisp/test-org-src.el".
>
> I'll have a look at that, but I'm not quite sure what to do.

You could look at `test-org-src/footnote-references' for inspiration.
However, I assume tests will be less complicated for LaTeX fragments.

>> Could you remind me if you signed the FSF papers already?
>
> They're done and dusted :)

Perfect.

We're almost there, then.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
> Without hesitation, the first form is nicer. The second one is 
> just abusing let-binding. I die a little just by looking at it. 

I'll make an attempt to avoid killing you then :P
 
> See `rx' macro. S-exp regexps are usually easier to read (after 
> an initial struggle), and less likely to introduce subtle bugs. 
> For long regexps, this is important. For this one, either way is 
> fine. 

I'll just remove the -p and be done with it then.
 
> Well. Ideally, let-binding should enclose the minimum part of 
> the code that needs the binding. Sometimes, an exception is 
> tolerated, because the code would contain too many nested 
> let-forms. But, conversely, you shouldn't stuff every local 
> variable at the beginning of the function and be done with it. 
> 
> In this particular case, there's no reason to stuff the `length' 
> call at the top of the function when you need it later on, on a 
> well-defined S-exp. IOW, it is more idiomatic to just add a 
> let-binding around the appropriate (add-text-properties ...). 

Somehow it feels like overkill to have

(let (contents-length (length contents))
 ...)

when it's only used twice :P
 
> But it should be ", so remove newlines." 

Gah!
 
>> I recall being asked to list modified/added functions, what 
>> else do I need? 
> 
> Nothing else. 

Should be good then, as far as I can tell.
 
>>> Bonus points if you can add some tests in 
>>> "testing/lisp/test-org-src.el". 
>> 
>> I'll have a look at that, but I'm not quite sure what to do. 
> 
> You could look at `test-org-src/footnote-references' for 
> inspiration.  However, I assume tests will be less complicated 
> for LaTeX fragments. 

I'll have a look.

> We're almost there, then.

Nice! :) I'll try to send through the next iteration soon.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]


Ok, I think this is everything except for except putting (length 
contents) in a let binding. I don't mind if you edit a let binding 
into the patch, I'm just struggling to overcome a feeling that 
it's a bit silly adding a binding for a short, simple function 
called twice.

Let me know if this is good, or if you'd like any changes.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch --]
[-- Type: text/x-patch, Size: 4368 bytes --]

From 31aa97c7f0cc9bf7272f4e781192b1458ee98525 Mon Sep 17 00:00:00 2001
From: TEC <tec@tecosaur.com>
Date: Sun, 24 May 2020 23:35:33 +0800
Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
 new function, `org-edit-latex-fragment' which is hooked into
 `org-edit-special', modifying `org-src--contents-area-modified' to recognise
 the element type.

---
 etc/ORG-NEWS    |  7 +++++++
 lisp/org-src.el | 45 +++++++++++++++++++++++++++++++++++++++++++++
 lisp/org.el     |  1 +
 3 files changed, 53 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 5183b58de..ea7ccb7c5 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -459,6 +459,13 @@ By default, Haskell blocks are interpreted. By adding =:compile yes=
 to a Haskell source block, it will be compiled, executed and the
 results will be displayed.
 
+*** Support for ~org-edit-special~ with LaTeX fragments.
+
+Calling ~org-edit-special~ on an inline LaTeX fragment calls a new
+function, ~org-edit-latex-fragment~. This functions in a comparable
+manner to editing inline source blocks, bringing up a minibuffer set
+to LaTeX mode. The math-mode deliminators are read only.
+
 * Version 9.3
 
 ** Incompatible changes
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 1643607e4..43fb10fa5 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -363,6 +363,12 @@ where BEG and END are buffer positions and CONTENTS is a string."
 	     (end (progn (goto-char (org-element-property :end datum))
 			 (search-backward "}" (line-beginning-position) t))))
 	 (list beg end (buffer-substring-no-properties beg end))))
+      ((eq type 'latex-fragment)
+       (let ((beg (org-element-property :begin datum))
+	     (end (org-with-point-at (org-element-property :end datum)
+		    (skip-chars-backward " \t")
+		    (point))))
+	 (list beg end (buffer-substring-no-properties beg end))))
       ((org-element-property :contents-begin datum)
        (let ((beg (org-element-property :contents-begin datum))
 	     (end (org-element-property :contents-end datum)))
@@ -959,6 +965,45 @@ Throw an error when not at such a table."
     (table-recognize)
     t))
 
+(defun org-edit-latex-fragment ()
+  "Edit LaTeX fragment at point."
+  (interactive)
+  (let ((context (org-element-context)))
+    (unless (and (eq (org-element-type context) 'latex-fragment)
+		 (org-src--on-datum-p context))
+      (user-error "Not on a LaTeX fragment"))
+    (let*
+	;; Grab the LaTeX fragment for propertization.
+	((contents (buffer-substring-no-properties
+		    (org-element-property :begin context)
+		    (- (org-element-property :end context)
+		       (org-element-property :post-blank context))))
+	 (delim-length (if (string-match "\\`\\$[^$]" contents))
+		       1 2))
+      ;; Make the LaTeX deliminators read-only.
+      (add-text-properties
+       0 delim-length
+       '(read-only "Cannot edit LaTeX deliminator" front-sticky t rear-nonsticky t)
+       contents)
+      (add-text-properties
+       (- (length contents) delim-length)
+       (length contents)
+       '(read-only "Cannot edit LaTeX deliminator" front-sticky nil rear-nonsticky nil)
+       contents)
+      (org-src--edit-element
+       context
+       (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
+       (org-src-get-lang-mode "latex")
+       (lambda ()
+	 ;; Blank lines break things, replace with a single newline.
+	 (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
+	 ;; If within a table a newline would disrupt the structure, so remove newlines.
+	 (goto-char (point-min))
+	 (when (org-element-lineage context '(table-cell))
+	   (while (search-forward "\n" nil t) (replace-match " "))))
+       contents))
+    t))
+
 (defun org-edit-latex-environment ()
   "Edit LaTeX environment at point.
 \\<org-src-mode-map>
diff --git a/lisp/org.el b/lisp/org.el
index 40c3c46b9..0808fc210 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17347,6 +17347,7 @@ Otherwise, return a user error."
 	 (pcase (org-element-type context)
 	   (`footnote-reference (org-edit-footnote-reference))
 	   (`inline-src-block (org-edit-inline-src-code))
+	   (`latex-fragment (org-edit-latex-fragment))
 	   (`timestamp (if (eq 'inactive (org-element-property :type context))
 			   (call-interactively #'org-time-stamp-inactive)
 			 (call-interactively #'org-time-stamp)))
-- 
2.26.2

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Hello,

TEC <tecosaur@gmail.com> writes:

> Ok, I think this is everything except for except putting (length
> contents) in a let binding. I don't mind if you edit a let binding
> into the patch, I'm just struggling to overcome a feeling that it's
> a bit silly adding a binding for a short, simple function called
> twice.

I love doing silly things; I added a let binding.

> Subject: [PATCH] Extend org-edit-special to editing LaTeX-fragments Defines a
>  new function, `org-edit-latex-fragment' which is hooked into
>  `org-edit-special', modifying `org-src--contents-area-modified' to recognise
>  the element type.

I fixed the commit message, made sure no line was getting past char 80,
and applied your patch.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[John Kitchin]

Timothy <tecosaur@gmail.com> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Thank you. It looks fine, I will only be nitpicking.
>
> Nitpick away :D
>
>>> +(defun org-edit-latex-fragment ()
>>> +  "Edit LaTeX fragment at point."
>>> +  (interactive)
>>> +  (let* ((context (org-element-context))
>>> +	 (_ (unless (and (eq (org-element-type context) 'latex-fragment)
>>> +			 (org-src--on-datum-p context))
>>> +	      (user-error "Not on a LaTeX fragment")))

Is this a case for the if-let* macro? Or is that too new a feature for
org to use still?

>>
>> This is a fancy way to use a let-binding. I suggest to mimic what is
>> done elsewhere, i.e., first bind `context', then check if we're at
>> a LaTeX fragment, then bind the rest.
>
> I had a look at that, to me this was cleaner than using multiple let
> bindings, like so
>
> (let ((context ...))
>   (unless  ... user error)
>   (let* ((contents ...)
>          (delim-length ...))
>    ...
>
> vs.
>
> (let* ((context ...)
>        (_ (unless ... user error))
>        (contents ...)
>        (delim-length ...))
>  ...
>
> Personally I find the second one nicer. Thoughts?
>
>>> +    ;; Grab the LaTeX fragment for propertization
>>
>> Missing full stop at the end of the comment.
>
> Fixed!
>
>>
>>> +	 (contents (buffer-substring-no-properties
>>> +		    (org-element-property :begin context)
>>> +		    (- (org-element-property :end context)
>>> +		       (org-element-property :post-blank context))))
>>> +	 (delim-length (if (string-match "\\$[^$]" (substring contents 0 2))
>>
>> Use
>>
>>    (string-match "\\`\\$[^$]" contents)
>>
>> instead.
>>
>> or, arguably better,
>>
>>    (string-match (rx (seq string-start "$" (not (any "$"))))
>>                  contents)
>>
>>> +			   1 2)))
>>> +    ;; make the LaTeX deliminators read-only
>
> I've changed to (string-match-p "\\`\\$[^$]" contents), as this seems
> like the idiomatic form, let me know if you're happy with this.
>
> I'm not actually sure what's going on with your second suggested form,
> or why that may be better. If you'd mind explaining, that would be
> appriciated :)
>
>> Missing initial capital and final full stop.
>
> Fixed!
>
>> You could factor out (length contents) so it is only called once.
>
> I'm not sure if this a big deal, but I shoved it in the let* for now,
> let me know if that suffices.
>
>>> +    (org-src--edit-element
>>> +     context
>>> +     (org-src--construct-edit-buffer-name (buffer-name) "LaTeX fragment")
>>> +     (org-src-get-lang-mode "latex")
>>> +     (lambda ()
>>> +       ;; Blank lines break things, replace with a single newline
>>
>> See above.
>
> I'm not quite sure what I should see? I don't notice anything to factor
> out here.
>
>>
>>> +       (while (re-search-forward "\n[ \t]*\n" nil t) (replace-match "\n"))
>>> +       ;; If within a table a newline would disrupt the structure,
>>
>> This comment is truncated.
>
> Added ", so remove newlines"
>
>> Don't leave parenthesis alone.
>
> Fixed!
>
>> Also, make sure your indentation is right, e.g., using M-q on the
>> definition.
>
> I've applied auto-indent to `org-edit-latex-fragment'
>
>> You also need to add a proper commit message and use `git format-patch',
>> and an entry in ORG-NEWS (probably in Miscellaneous part).
>
> I recall being asked to list modified/added functions, what else do I need?
>
>> Bonus points if you can add some tests in
>> "testing/lisp/test-org-src.el".
>
> I'll have a look at that, but I'm not quite sure what to do.
>
>> Could you remind me if you signed the FSF papers already?
>
> They're done and dusted :)
>
> Regards,
>
> Timothy.


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

Timothy <tecosaur@gmail.com> writes:

> I have only a basic working understanding, but my impression was that
> in functioned as a 'best of both worlds' type thing.

I don't understand what would be the best of HTML email in that case.
You're neither inlining any image, nor using any fancy presentation.
Yet, your email is twice as big as it could be.

In this mailing list, and probably in others, too, HTML email is just
a waste of space.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

 
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: 
 
> I don't understand what would be the best of HTML email in that 
> case.  You're neither inlining any image, nor using any fancy 
> presentation.  Yet, your email is twice as big as it could be. 
HTML is often prettier :P it's also nice to get code blocks with 
syntax highlighting.
I'm not sure quite how it happens, but with one of my earlier test 
org-msg emails in which
I sent a code block, when viewing it as plaintext in mu4e it seem 
to recognise the
language and apply syntax highlighting. Or it may have just 
applied some of the HTML styling,
I'm not entirely sure. Either way --- I thought it seemed pretty 
nifty :D
 
> In this mailing list, and probably in others, too, HTML email is 
> just a waste of space. 

I see what you're saying. If it's just text that's being 
communicated
why use anything more than plaintext?

>> Here we go, I think I got everything. Please give this a 
>> test-drive and let me know how it is!

I look forward to hearing your feedback on the latest path. I 
think there's a decent
chance it could be the last one :) The only thing that comes to 
mind is changing
`string-match' to `string-match-p'.

All the best,

Timothy.

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Nicolas Goaziou]

TEC <tecosaur@gmail.com> writes:

> -	     (end (progn (goto-char (org-element-property :end datum))
> -			 (search-backward "}" (line-beginning-position) t))))
> +	     (end (org-with-point-at (org-element-property :end datum)
> +		    (skip-chars-backward " \t")
> +		    (point))))
> +	 (list beg end (buffer-substring-no-properties beg end))))
> +      ((eq type 'latex-fragment)
> +       (let ((beg (org-element-property :begin datum))
> +	     (end (org-element-property :end datum)))

It seems you're mixing inline source blocks and LaTeX fragment. You
modified the former, but not the latter.

> +     (lambda () ; trim content
> +       (goto-char (point-min))

This is not needed. The function is always called at `point-min'.

> +       (skip-chars-forward " \t")
> +       (delete-region (point-min) (point))
> +       (goto-char (point-max))
> +       (skip-chars-backward " \t")
> +       (delete-region (point) (point-max))))

I'm not sure this clean-up is necessary. Is it?

Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[TEC]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]


Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> It seems you're mixing inline source blocks and LaTeX fragment. 
> You
> modified the former, but not the latter.

Ooops, I'll fix that.

>> +     (lambda () ; trim content
>> +       (goto-char (point-min))
>
> This is not needed. The function is always called at 
> `point-min'.

Got it :)

>> +       (skip-chars-forward " \t")
>> +       (delete-region (point-min) (point))
>> +       (goto-char (point-max))
>> +       (skip-chars-backward " \t")
>> +       (delete-region (point) (point-max))))
>
> I'm not sure this clean-up is necessary. Is it?

What cleanup? I just took this from org-edit-inline-src-code.

[-- Attachment #2.1: Type: text/html, Size: 941 bytes --]

(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Hello All!

I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me.
Shortly after that though, I was disappoint to discover that this didn't work with inline LaTeX equations \( … \) or LaTeX display equations \[ … \]. If it would be possible to account for this form of inline LaTeX too, that would be marvellous!
A brief note on me
Hola! Love the work that's gone on here, so first of all: thanks to all those who have helped make Org-mode so great 💖.
I'm a new-ish Emacs user (~5 months old) currently using Doom (which I'm finding very comfortable), and my only regret is not getting into this all earlier 😛

First email to this mailing list, so please let me know if I'm not quite following protocol or anything like that. Otherwise, this is the first of a few emails that I've been meaning to send off for a while now.
I'm also a uni student a few weeks off from exams so I am not able to really need to resist the urge to jump in and work on implementing these ideas. I should have significantly more time late june though :)
All the best,
tecosaur

[-- Attachment #2: Type: text/html, Size: 1502 bytes --]