Re: Replace Org's C-TAB with C-M-TAB - objection?
I'd rather support this change, as I don't have TAB on my keyboard, I use C-i instead of TAB OTOH, C-M-i , which is essentially M-TAB, and essentially what the changes is supposed to be, if flyspell-auto-correct-word (found in flyspell-mode-map) So, if this change is made, and flyspell is turned on by default (an not turning it on is an offence punishable by Grammar Nazi), this binding will be shadowed. All this is a mess. -- Yours sincerely, Vladimir Nikishkin
Re: Bug: why does org-goto call org-latex-preview?
Ihor Radchenko writes: >> It looks like an oversight to me. I think >> org-startup-with-latex-preview should be let-bound to nil around >> org-goto-location's call to org-mode. Likewise, I'd say that >> org-startup-with-inline-images and org-startup-shrink-all-tables should >> be let-bound to nil. > > Is there even a need to call the whole (org-mode). The new buffer is > an indirect buffer. It should already have org-mode activated (at least, > we can check for it and not call (org-mode) unnecessarily). If we just > want to reset initial visibility, (org-overview) is already doing the > job of (org-set-startup-visibility) from (org-mode). Hmm, thanks for taking a step back. It does seem like the org-mode call should be unnecessary. (I haven't tried yet.) I wonder whether calling org-mode could be a leftover from all the way back in 70b6cc5da (Release 5.10a, 2008-01-31), where there was a switch from using a normal buffer to an indirect one.
Re: Bug: why does org-goto call org-latex-preview?
> It looks like an oversight to me. I think > org-startup-with-latex-preview should be let-bound to nil around > org-goto-location's call to org-mode. Likewise, I'd say that > org-startup-with-inline-images and org-startup-shrink-all-tables should > be let-bound to nil. Is there even a need to call the whole (org-mode). The new buffer is an indirect buffer. It should already have org-mode activated (at least, we can check for it and not call (org-mode) unnecessarily). If we just want to reset initial visibility, (org-overview) is already doing the job of (org-set-startup-visibility) from (org-mode). Best, Ihor Kyle Meyer writes: > Vladimir Nikishkin writes: > >> Why is it that org-goto enforces the regeneration of previews in a buffer? > > It looks like an oversight to me. I think > org-startup-with-latex-preview should be let-bound to nil around > org-goto-location's call to org-mode. Likewise, I'd say that > org-startup-with-inline-images and org-startup-shrink-all-tables should > be let-bound to nil. > > Assuming nobody chimes in to explain why that's a bad idea, I'll plan to > make those changes tomorrow night. > -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
Re: Bug: why does org-goto call org-latex-preview?
Vladimir Nikishkin writes: > Why is it that org-goto enforces the regeneration of previews in a buffer? It looks like an oversight to me. I think org-startup-with-latex-preview should be let-bound to nil around org-goto-location's call to org-mode. Likewise, I'd say that org-startup-with-inline-images and org-startup-shrink-all-tables should be let-bound to nil. Assuming nobody chimes in to explain why that's a bad idea, I'll plan to make those changes tomorrow night.
Re: org-babel block with :exports code that gets evaluated on export
Sébastien Miquel writes: > Is there a way to have an org-babel block which only exports its code > but still gets evaluated when exporting ? I think you can do something like this: #+begin_src emacs-lisp :exports both :results none (setq my-variable t) #+end_src Or, if you want to pass the results to another block you could use ":results output silent" or ":results value silent." Best, Matt
Bug: why does org-goto call org-latex-preview?
Hello, everyone! Below is an excerpt of the profiler report after typing C-c C-j: - command-execute2385 76% - call-interactively2385 76% - funcall-interactively1928 61% - org-goto1878 60% - org-goto-location 1867 59% - org-mode 1861 59% - org-latex-preview1590 51% - org--latex-preview-region 1590 51% - org-format-latex 1588 50% Why is it that org-goto enforces the regeneration of previews in a buffer? In my case, the buffer has a huge number of latex formulae, and in total is 65000 lines long, so I can't really wait till the regeneration finishes, just takes too much time. -- Yours sincerely, Vladimir Nikishkin
Re: [PATCH] test-ob-tangle.el: Fix dirty repo state caused by testing
Kevin Foley writes: > The attached patch kills the buffer of the file modified > during testing to prevent leaving the repo in a dirty state. Thanks. I applied it in 7a2b785d6 with a small tweak so that a buffer rather than a buffer name is passed to kill-buffer. In the context of the tests, the buffer name "babel.org" is very likely to be the one we intend to kill, but I think it's better to use the actual buffer object.
[PATCH] test-ob-tangle.el: Fix dirty repo state caused by testing
The attached patch kills the buffer of the file modified during testing to prevent leaving the repo in a dirty state. Thanks to Kyle for seeing this and providing guidance on how to address. Thanks, Kevin >From 46dd1cf3c34a372612e4a67a79afd84ca3317500 Mon Sep 17 00:00:00 2001 From: "Kevin J. Foley" Date: Tue, 26 May 2020 20:42:54 -0400 Subject: [PATCH] test-ob-tangle.el: Fix dirty repo state caused by testing * testing/lisp/test-ob-tangle.el (ob-tangle/detangle-false-positive): Kill modified buffer after test. Another test is causing the modifications to be saved which leaves the repo in a dirty state after testing. --- testing/lisp/test-ob-tangle.el | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/testing/lisp/test-ob-tangle.el b/testing/lisp/test-ob-tangle.el index ed75e6ca4..bd2d99ca2 100644 --- a/testing/lisp/test-ob-tangle.el +++ b/testing/lisp/test-ob-tangle.el @@ -384,12 +384,14 @@ (ert-deftest ob-tangle/commented-src-blocks () (ert-deftest ob-tangle/detangle-false-positive () "Test handling of false positive link during detangle." - (org-test-in-example-file (expand-file-name "babel.el" org-test-example-dir) -(org-babel-detangle) -(org-test-at-id "73115FB0-6565-442B-BB95-50195A499EF4" -(org-babel-next-src-block) -(should (equal (string-trim (org-element-property :value (org-element-at-point))) - ";; detangle changes") + (unwind-protect + (org-test-in-example-file (expand-file-name "babel.el" org-test-example-dir) + (org-babel-detangle) + (org-test-at-id "73115FB0-6565-442B-BB95-50195A499EF4" + (org-babel-next-src-block) + (should (equal (string-trim (org-element-property :value (org-element-at-point))) + ";; detangle changes" +(kill-buffer "babel.org"))) (provide 'test-ob-tangle) -- 2.19.0
Re: ISSUE: org publish document processor silently inserts licensed content into targets by default
On 5/22/20 11:10 AM, Bastien wrote: > If you think it is useful as a patch against Org, not just as a way to > customize a setup, can you send a patch? > > See https://orgmode.org/worg/org-contribute.html on how to contribute. Ok, it is on my list, thanks. -- Anthony Carrico
Re: Migrating from HUGO to org-publish
Alejandro, Have you tried ox-hugo? There's an org exporter to Hugo. I use it and it works pretty much flawlessly. -- James Miller james.ryland.mil...@gmail.com
Re: org-archive-all-matches doesn't use org-archive-default-command
Hi Thomas, Thomas Schaper writes: > When playing around with org-archive, I noticed that the function > org-archive-all-matches doesn't use org-archive-default-command but > calls org-archive-subtree directly. Is there any reason for this, or is > it simply a small bug/missing feature? I think this is because at present org-archive-all-matches is a non-interactive helper function that is called only when someone is using org-archive-subtree or org-toggle-archive-tag with a prefix argument. So without some refactoring, using org-archive-default-command would cause unexpected behavior, since it is invoked only in contexts in which people are explicitly expecting *either* org-archive-subtree *or* org-toggle-archive-tag. Were you by chance looking to have this work with org-archive-to-archive-sibling? Best, Matt
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: issue tracker?
Anthony Carrico writes: > Given that the mailing list holds the issues, it would be nice if you > could import the mailing list into your client as a lump (maildir/mbox). > Currently you can only download it chunk by chunk, so it isn't really > practical for a newcomer to import the whole list to do research a new > issue before reporting it. You can use wget to download them all the mbox files at once here: https://lists.gnu.org/archive/mbox/emacs-orgmode/ For instance, the following command... wget -r -nH --cut-dirs=2 --no-parent -A "2019-*" --reject="index.html*" https://lists.gnu.org/archive/mbox/emacs-orgmode/ ..will download all mbox archives from 2019 into the directory emacs-orgmode. Then you can browse them in Gnus, cat them into a single file for easier importing into a client, convert them to Maildir (via mb2md) for indexing in notmuch, mu4e, etc. Matt
Re: [PATCH] ob-plantuml: Support for plantuml as well as the current java+jar solution
Hello Bastien, I have now signed the FSF papers. Here is the updated patch on top of current master. Let me know if all looks good or if I need to make further changes or need to provide something else. Best regards, Terje On Mon, Feb 17, 2020 at 12:29 AM Bastien wrote: > > Hi Terje, > > Terje Larsen writes: > > > You are welcome, I have never gotten around to sign the FSF papers as > > I thought it was a > > bit of a hassle, but with those clear instructions I have now started > > the process. > > Thanks! > > > I guess I have to wait until the process is done until I can > > resubmit? > > Yes, exactly. Thanks for contributing, > > -- > Bastien -- // Terje Larsen From b5f1bf735e6cf7eeeaa4f8bfdab921bed0959b46 Mon Sep 17 00:00:00 2001 From: Terje Larsen Date: Fri, 8 Nov 2019 10:25:49 +0100 Subject: [PATCH] ob-plantuml: Add support for plantuml executable * lisp/ob-plantuml (org-babel-variable-assignments:plantuml): Support using plantuml executable instead of jar. Some systems come with an executable for plantuml instead of a specific JAR file. This adds support for two different modes: - jar :: using java together with a JAR (previous behavior) - plantuml :: using a PlantUML executable The PlantUML executable can be configured via `org-plantuml-executable-path` and also the arguments that will be given via `org-plantuml-executable-args`. --- etc/ORG-NEWS| 7 lisp/ob-plantuml.el | 94 + 2 files changed, 67 insertions(+), 34 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 5183b58de..0b161a32b 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -243,6 +243,13 @@ explicitly: In situations where ~org-return~ calls ~newline~, multiple newlines can now be inserted with this prefix argument. +*** =ob-plantuml=: now supports using PlantUML executable to generate diagrams + +Set =org-plantuml-exec-mode= to ='plantuml= in order to use the +executable instead of JAR. When using an executable it is also +possible to configure executable location as well as arguments via: +=org-plantuml-executable-path= and =org-plantuml-executable-args=. + ** New commands *** ~org-table-header-line-mode~ diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el index 0e1d4eda2..67b469c31 100644 --- a/lisp/ob-plantuml.el +++ b/lisp/ob-plantuml.el @@ -31,7 +31,7 @@ ;;; Requirements: ;; plantuml | http://plantuml.sourceforge.net/ -;; plantuml.jar | `org-plantuml-jar-path' should point to the jar file +;; plantuml.jar | `org-plantuml-jar-path' should point to the jar file (when exec mode is `jar') ;;; Code: (require 'ob) @@ -46,6 +46,31 @@ :version "24.1" :type 'string) +(defcustom org-plantuml-exec-mode 'jar + "Method to use for PlantUML diagram generation. +`jar' means to use java together with the JAR. +The JAR can be configured via `org-plantuml-jar-path'. + +`plantuml' means to use the PlantUML executable. +The executable can be configured via `org-plantuml-executable-path'. +You can also configure extra arguments via `org-plantuml-executable-args'." + :group 'org-babel + :package-version '(Org . "9.4") + :type 'symbol + :options '(jar plantuml)) + +(defcustom org-plantuml-executable-path "plantuml" + "File name of the PlantUML executable." + :group 'org-babel + :package-version '(Org . "9.4") + :type 'string) + +(defcustom org-plantuml-executable-args (list "-headless") + "The arguments passed to plantuml executable when executing PlantUML." + :group 'org-babel + :package-version '(Org . "9.4") + :type '(repeat string)) + (defun org-babel-variable-assignments:plantuml (params) "Return a list of PlantUML statements assigning the block's variables. PARAMS is a property list of source block parameters, which may @@ -83,40 +108,41 @@ This function is called by `org-babel-execute-src-block'." (cmdline (cdr (assq :cmdline params))) (in-file (org-babel-temp-file "plantuml-")) (java (or (cdr (assq :java params)) "")) + (executable (cond ((eq org-plantuml-exec-mode 'plantuml) org-plantuml-executable-path) + (t "java"))) + (executable-args (cond ((eq org-plantuml-exec-mode 'plantuml) org-plantuml-executable-args) +((string= "" org-plantuml-jar-path) + (error "`org-plantuml-jar-path' is not set")) +((not (file-exists-p org-plantuml-jar-path)) + (error "Could not find plantuml.jar at %s" org-plantuml-jar-path)) +(t (list java + "-jar" + (shell-quote-argument (expand-file-name org-plantuml-jar-path)) (full-body (org-babel-plantuml-make-body body params)) - (cmd (if (string= "" org-plantuml-jar-path) - (error "`org-plantuml-jar-path' is not set") - (concat "java " java " -jar " - (shell-quote-argument - (expand-file-name org-plantuml-jar-path)) - (if (string= (file-name-extension out-file) "png") - " -tpng" "") - (if (string= (file-name-extension out-file) "svg") - " -tsvg" "") - (if (string= (file-name-extension out-file) "eps") - "
Re: issue tracker?
Detlef Steuer writes: > How to add more now? Same here. Mail is functionally superior to a lot > of modern solutions. > > A Bugtracker you do not use on a regular basis often is a horrible time sink. > Plus, most of the time you need just another account for a site you > never wanted an account on. > > Furthermore many of the discussions on this list wouldn't have happend, > if the first post went into a bugtracker. > > I would go as far as saying *this list* is one of the fastest reacting > amd friendliest communities I have been part of. The job Nicolas does is > just awesome. > > That leads to the next point: If Nicolas decided *he* would love to work > with a bugtracker, I would not complain and open an account. > As it is now, anything that's not in the best interest of our benevolent > developer, should not even be considered :-) I agree wholeheartedly with everything Detlef says here. Due to life circumstances, I have only been able to participate intermittently on the mailing list over the past 10 years. But I have happily used Org during that time, and I love that that this ML has been a constant in the Org Mode community, even as countless other tech fads have come and gone. Matt
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: [bug] Should #+attr_latex affect image display within the org buffer itself?
I think another way to do it is to have an #+attr_org: :width as the first attribute. Vladimir Nikishkin writes: > At the moment, I'm working around this by setting the width in "TeX points": > > #+attr_latex: :width 224pt > > The exported image becomes 224 points wide (roughly 8 cm), and the > embedded image is 224 pixels wide, which is okay. > > > 2020-05-26 12:01 GMT+08:00, Vladimir Nikishkin : >> Hello, everyone >> >> My problem is the following: >> >> Compare the following three pieces of org code: >> >> #+attr_latex: :width 80px >> [[file:figure-1-1-dot.png]] >> >> #+attr_latex: :width 8cm >> [[file:figure-1-1-dot.png]] >> >> #+attr_latex: :width 80mm >> [[file:figure-1-1-dot.png]] >> >> They get exported into LaTeX as expected. >> But if you org-redisplay-inline-images, you will see that the first >> one is rendered 80 pixels wide, >> the second one ise rendered 8 pixels wide, and the third one is >> rendered 80 (again) pixels wide. >> >> So it seems that org is using #+attr_latex as a guide in setting the >> width of the images in the org-buffer. >> >> This seems wrong. >> >> -- >> Yours sincerely, Vladimir Nikishkin >> -- 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: ical2org.awk
On Friday, 22 May 2020 at 16:14, Bastien wrote: > I see there is > https://github.com/msherry/ical2org/blob/master/ical2org.awk Interesting. I hadn't been aware of that fork. > so perhaps hosting the code on worg/code/ is not so useful > anymore? I don't really have a strong opinion about this. Happy for it to remain (it does work) but also happy to have it removed and a link to that fork put in. My own version has diverged from the one I put on Worg ever so long ago now in any case. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc
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: issue tracker?
> On Mon, 25 May 2020 13:20:30 +0200, Roland Everaert > said: Roland> No, I was not aware of it. Yet, if I understand the objective of the Emacs Roland> ML and Debbugs, it is for, when you have a crash with emacs or, at least, Roland> an error stack trace when evaluating some lisp code. This is different from Roland> the intent here to define how to switch a thread started as a simple Roland> conversation to a tracked conversation, as a bug, feature request or Roland> suggestion, an the other way around. Roland> Sorry if I was not clear about it or if I misunderstand the purpose of Roland> Debbugs and the Emacs ML. The definition of 'emacs bug' is fairly loose. It ranges from 'emacs crashed' to 'when I do this funky org-mode thing with 1000 lines of config, thereʼs an extra space at eol' and everything in between, and also covers feature requests. Robert
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: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Hello, Ihor Radchenko writes: > I have five updates from the previous version of the patch: Thank you. > 1. I implemented a simplified version of element parsing to detect > changes in folded drawers or blocks. No computationally expensive calls > of org-element-at-point or org-element-parse-buffer are needed now. > > 2. The patch is now compatible with master (commit 2e96dc639). I > reverted the earlier change in folding drawers and blocks. Now, they are > back to using 'org-hide-block and 'org-hide-drawer. Using 'outline would > achieve nothing when we use text properties. > > 3. 'invisible text property can now be nested. This is important, for > example, when text inside drawers contains fontified links (which also > use 'invisible text property to hide parts of the link). Now, the old > 'invisible spec is recovered after unfolding. Interesting. I'm running out of time, so I cannot properly inspect the code right now. I'll try to do that before the end of the week. > 4. Some outline-* function calls in org referred to outline-flag-region > implementation, which is not in sync with org-flag-region in this patch. > I have implemented their org-* versions and replaced the calls > throughout .el files. Actually, some org-* versions were already > implemented in org, but not used for some reason (or not mentioned in > the manual). I have updated the relevant sections of manual. These > changes might be relevant to org independently of this feature branch. Yes, we certainly want to move to org-specific versions in all cases. > 5. I have managed to get a working version of outline folding via text > properties. However, that approach has a big downside - folding state > cannot be different in indirect buffer when we use text properties. I > have seen packages relying on this feature of org and I do not see any > obvious way to achieve different folding state in indirect buffer while > using text properties for outline folding. Hmm. Good point. This is a serious issue to consider. Even if we don't use text properties for outline, this also affects drawers and blocks. > For now, I still used before/after-change-functions combination. You shouldn't. > I see the following problems with using only after-change-functions: > > 1. They are not guaranteed to be called after every single change: Of course they are! See below. > From (elisp) Change Hooks: > "... some complex primitives call ‘before-change-functions’ once before > making changes, and then call ‘after-change-functions’ zero or more > times" "zero" means there are no changes at all, so, `after-change-functions' are not called, which is expected. > The consequence of it is a possibility that region passed to the > after-change-functions is quite big (including all the singular changes, > even if they are distant). This region may contain changed drawers as > well and unchanged drawers and needs to be parsed to determine which > drawers need to be re-folded. It seems you're getting it backwards. `before-change-functions' are the functions being called with a possibly wide, imprecise, region to handle: When that happens, the arguments to ‘before-change-functions’ will enclose a region in which the individual changes are made, but won’t necessarily be the minimal such region however, after-change-functions calls are always minimal: and the arguments to each successive call of ‘after-change-functions’ will then delimit the part of text being changed exactly. If you stick to `after-change-functions', there will be no such thing as you describe. >> And, more importantly, they are not meant to be used together, i.e., you >> cannot assume that a single call to `before-change-functions' always >> happens before calling `after-change-functions'. This can be tricky if >> you want to use the former to pass information to the latter. > > The fact that before-change-functions can be called multiple times > before after-change-functions, is trivially solved by using buffer-local > changes register (see org--modified-elements). Famous last words. Been there, done that, and it failed. Let me quote the manual: In general, we advise to use either before- or the after-change hooks, but not both. So, let me insist: don't do that. If you don't agree with me, let's at least agree with Emacs developers. > The register is populated by before-change-functions and cleared by > after-change-functions. You cannot expect `after-change-functions' to clear what `before-change-functions' did. This is likely to introduce pernicious bugs. Sorry if it sounds like FUD, but bugs in those areas are just horrible to squash. >> Well, `before-change-fuctions' and `after-change-functions' are not >> clean at all: you modify an unrelated part of the buffer, but still call >> those to check if a drawer needs to be unfolded somewhere. > > 2. As you pointed, instead of global before-change-functions, we can use > modification-hooks text
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
Using font-lock to align tags in org buffers
Hello, Currently, org does tag alignment by adding a number of spaces before the tags. This becomes messy when one changes the window size and turns off line truncation. I came up with an experimental code utilising 'display text property and font-lock to align tags dynamically, as you resize the Emacs frame. If anyone is interested, the code is below: - (defun string-display-pixel-width (string mode) "Calculate pixel width of STRING. Optional MODE specifies major mode used for display." (with-temp-buffer (with-silent-modifications (setf (buffer-string) string)) (when (fboundp mode) (funcall mode) (font-lock-fontify-buffer)) (if (not (get-buffer-window (current-buffer))) (save-window-excursion ;; Avoid errors if the selected window is a dedicated one, ;; and they just want to insert a document into it. (set-window-dedicated-p nil nil) (set-window-buffer nil (current-buffer)) (car (window-text-pixel-size nil (line-beginning-position) (point (car (window-text-pixel-size nil (line-beginning-position) (point)) (setq org-auto-align-tags nil) (add-hook 'org-mode-hook (lambda () (font-lock-add-keywords nil '(yant/org-align-tags) t)) 100) (add-hook 'org-mode-hook (lambda () (add-to-list 'font-lock-extra-managed-props 'org-tag-aligned))) (defun yant/org-align-tags (limit) "Align all the tags in org buffer." (while (re-search-forward "^\\*+ \\(.+?\\)\\([ \t]+\\)\\(:\\(?:[^ \n]+:\\)+\\)$" limit t) (when (and (match-string 2) (not (get-text-property (match-beginning 2) 'org-tag-aligned))) (with-silent-modifications (put-text-property (match-beginning 2) (match-end 2) 'org-tag-aligned t) (put-text-property (match-beginning 2) (match-end 2) 'display `(space . (:align-to (- right (,(+ (string-display-pixel-width org-ellipsis) (string-display-pixel-width (or (match-string 3) "" - The same approach can be used to align tags in agenda: - (defun org-agenda-fix-tag-alignment () "Use 'display :align-to instead of spaces in agenda." (goto-char (point-min)) (setq-local word-wrap nil) ; tags would be moved to next line if `word-wrap'` is non-nil and `truncate-lines' is nil (while (re-search-forward org-tag-group-re nil 'noerror) (put-text-property (match-beginning 0) (match-beginning 1) 'display `(space . (:align-to (- right (,(string-display-pixel-width (match-string 1) (add-hook 'org-agenda-finalize-hook #'org-agenda-fix-tag-alignment) - Best, Ihor -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg
