Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello, TEC 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 \[ \]
Timothy writes: > Nicolas Goaziou 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 \[ \]
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. >From 31aa97c7f0cc9bf7272f4e781192b1458ee98525 Mon Sep 17 00:00:00 2001 From: TEC 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. \\ 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 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 \[ \]
Timothy 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 \[ \]
Nicolas Goaziou 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. 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch Description: Binary data
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello, TEC 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 \[ \]
Nicolas Goaziou 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 \[ \]
Timothy 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 \[ \]
>From fc91322e9f8e47484767b66fb9f438d3326ccc08 Mon Sep 17 00:00:00 2001 From: TEC 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. \\ 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
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas 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 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 \[ \]
Nicolas Goaziou 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...
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Nicolas Goaziou 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 :)
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
TEC 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 \[ \]
Nicolas Goaziou 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 \[ \]
TEC 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 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 \[ \]
Nicolas Goaziou 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.
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
TEC 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 \[ \]
Nicolas Goaziou 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 \[ \]
TEC writes: > Nicolas Goaziou 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 \[ \]
I've had another thought :)
Nicolas Goaziou 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
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
One other quick comment
Nicolas Goaziou 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.
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
>From 748c20d65df9cd0ae9f9f80c2bb5ee87aea101e4 Mon Sep 17 00:00:00 2001
From: TEC
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.
\\
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
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
TEC 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 \[ \]
Nicolas Goaziou 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.
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello, TEC 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 \[ \]
Nicolas Goaziou writes:
Hello,
Timothy 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.
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello,
Timothy 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
> 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 \[ \]
> <#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. 0001-Extend-org-edit-special-to-editing-LaTeX-fragments.patch Description: Binary data
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
>From 379e23545d7e55766e48b50514bd797bdf691a40 Mon Sep 17 00:00:00 2001 From: TEC 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. \\ 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 \[ \]
Bastien 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 \[ \]
tecos...@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 \[ \]
Bastien 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?
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hi Timothy, thanks for the various feature requests! It's always interesting to discuss use cases and possible features. Timothy 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 \[ \]
Nicolas Goaziou 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 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 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 \[ \]
Nicolas Goaziou 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 wrote: > Timothy 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 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 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 ass...@gnu.org, so hopefully you'll be able to accept >15 loc patches from me in the (near?) future :) > Timothy 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 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!
(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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 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!
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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!
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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 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
Re: (Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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
(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
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
