Re: patch for org-capture.el to allow for no file extension on open-source, protocol
On 10 May 2020, at 13:57, Nicolas Goaziou wrote:
Hello,
"Stacey Marshall" writes:
The issue was that the URL I was opening had the full filename as-is.
No extension needed to be added or removed. If no suffix is provided
in the alist then the function failed. The patch allows both
online-suffix and working-suffix to not be required.
Thank you. Could you add a test in "test-org-protocol.el" ?
Regards,
--
Nicolas Goaziou
Hi Nicolas,
Test patch below. I've attached both patch files too.
```
From 9263002dc97753e297f8571511839eea0b39252e Mon Sep 17 00:00:00 2001
From: Stacey Marshall
Date: Mon, 11 May 2020 00:58:40 +0100
Subject: [PATCH 2/2] test-org-protocol.el: Fix tests and add new test
for
as-is filename.
* testing/lisp/test-org-protocol.el
(test-org-protocol/org-protocol-parse-parameters):
Fix issue of missing flag to indicate new paramenter testing.
* testing/lisp/test-org-protocol.el
(test-org-protocol/org-protocol-open-source):
Fix test3 which was not working. Add test4, for opening file name
as-is without suffix modification.
Tested using ert.
TINYCHANGE
---
testing/lisp/test-org-protocol.el | 37 ++-
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/testing/lisp/test-org-protocol.el
b/testing/lisp/test-org-protocol.el
index 6ee368dcf..42ad5e1a3 100644
--- a/testing/lisp/test-org-protocol.el
+++ b/testing/lisp/test-org-protocol.el
@@ -40,7 +40,7 @@
"url=https%3A%2F%2Forgmode.org%2Forg.html%23capture-protocol&"
"title=The%20Org%20Manual&"
"body=9.4.2%20capture%20protocol"))
-(data (org-protocol-parse-parameters url)))
+(data (org-protocol-parse-parameters url t)))
(should (string= (plist-get data :template) "p"))
(should (string= (plist-get data :url)
"https://orgmode.org/org.html#capture-protocol;))
(should (string= (plist-get data :title) "The Org Manual"))
@@ -138,6 +138,8 @@
"Test org-protocol://open-source links."
(let* ((temp-file-name1 (make-temp-file "org-protocol-test1"))
(temp-file-name2 (make-temp-file "org-protocol-test2"))
+(temp-file-name3 (make-temp-file "org-protocol-test3" nil ".md"))
+(temp-file-name4 (make-temp-file "org-protocol-test4" nil ".c"))
(org-protocol-project-alist
`((test1
:base-url "http://example.com/;
@@ -149,10 +151,13 @@
:working-directory ,(file-name-directory temp-file-name2))
(test3
:base-url "https://blog-example.com/;
-:working-directory ,(file-name-directory temp-file-name2)
+:working-directory ,(file-name-directory temp-file-name3)
:online-suffix ".html"
:working-suffix ".md"
- :rewrites
(("\\(https://blog-example.com/[0-9]+/[0-9]+/[0-9]+/\\)" . ".md")
+ :rewrites
(("\\(https://blog-example.com/[0-9]+/[0-9]+/[0-9]+/\\)" . ".md")))
+ (test4
+:base-url "http://as-is.example.com/;
+:working-directory ,(file-name-directory temp-file-name4
(test-cases
(list
;; Old-style URLs
@@ -166,6 +171,16 @@
(url-hexify-string
(concat "http://another.example.com/; (file-name-nondirectory
temp-file-name2) ".js")))
temp-file-name2)
+ (cons
+ (concat "/some/directory/org-protocol:/open-source:/"
+ (url-hexify-string
+ (concat "https://blog-example.com/; (file-name-nondirectory
(file-name-sans-extension temp-file-name3)) ".html")))
+ temp-file-name3)
+ (cons
+ (concat "/some/directory/org-protocol:/open-source:/"
+ (url-hexify-string
+ (concat "http://as-is.example.com/; (file-name-nondirectory
temp-file-name4
+ temp-file-name4)
;; New-style URLs
(cons
(concat "/some/directory/org-protocol:/open-source?url="
@@ -176,7 +191,17 @@
(concat "/some/directory/org-protocol:/open-source?url="
(url-hexify-string
(concat "http://another.example.com/; (file-name-nondirectory
temp-file-name2) ".js")))
- temp-file-name2
+ temp-file-name2)
+ (cons
+ (concat "/some/directory/org-protocol:/open-source?url="
+ (url-hexify-string
+ (concat "https://blog-example.com/; (file-name-nondirectory
(file-name-sans-extension temp-file-name3)) ".html")))
+ temp-file-name3)
+ (cons
+ (concat "/some/directory/org-protocol:/open-source?url="
+ (url-hexify-string
+ (concat "http://as-is.example.com/; (file-name-nondirectory
temp-file-name4
+ temp-file-name4
(mapc (lambda (test-case)
(should (string=
(org-protocol-check-filename-for-protocol
@@ -185,7 +210,9 @@
(cdr
[PATCH] manual: Fix special property descriptions for DEADLINE/SCHEDULED
Kyle Meyer writes: > Instead I think it'd be better to update the documentation and tweak > the output on colview's end. Here's an update for the manual. I'll apply it in a day or two if no objections come in. -- >8 -- Subject: [PATCH] manual: Fix special property descriptions for DEADLINE/SCHEDULED * doc/org-manual.org (Special Properties): Remove claim that angular brackets are stripped from DEADLINE and SCHEDULED time stamps, which has not been true since v8.3, specifically 8d8ad9838. It doesn't seem like 8d8ad9838 (Rewrite `org-entry-properties', 2014-09-30) intended to change this behavior, but let's stick with it because some spots in Org's code base depend on it and it's likely that third-party code does too. Also, replace "time string" with "timestamp" in DEADLINE's description for consistency with the other descriptions. --- doc/org-manual.org | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index 92a526ba6..c20a93000 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -5169,11 +5169,11 @@ ** Special Properties || ~org-clock-sum-today~ must be run first to compute the | || values in the current buffer. | | =CLOSED= | When was this entry closed? | -| =DEADLINE= | The deadline time string, without the angular brackets. | +| =DEADLINE= | The deadline timestamp. | | =FILE= | The filename the entry is located in. | | =ITEM= | The headline of the entry. | | =PRIORITY= | The priority of the entry, a string with a single letter. | -| =SCHEDULED=| The scheduling timestamp, without the angular brackets. | +| =SCHEDULED=| The scheduling timestamp. | | =TAGS= | The tags defined directly in the headline. | | =TIMESTAMP=| The first keyword-less timestamp in the entry. | | =TIMESTAMP_IA= | The first inactive timestamp in the entry. | base-commit: 3bbaca166052c4761a1bc8227496b23dc157bf96 -- 2.26.1
Re: Possible bug with columnview and active dates
Kyle Meyer writes: > While I think it's be fair to consider this a regression, I'm leery of s/it's be/it's/ > restoring the original behavior of stripping the brackets given how long > the current behavior has been around. Instead I think it'd be better to > update the documentation and tweak the output on colview's end. For the "tweaking the output part", it looks this is already possible on the user's end via org-columns-modify-value-for-display-function. Here's a lightly tested function that I think does what you want: (defun my/org-columns-remove-brackets (_title value) (and (string-match org-ts-regexp value) (match-string 1 value))) (setq org-columns-modify-value-for-display-function #'my/org-columns-remove-brackets)
Re: Possible bug with columnview and active dates
Kyle Meyer writes: >> According to the docs: >> https://orgmode.org/manual/Special-Properties.html#Special-Properties >> Using DEADLINE or SCHEDULED should not include the angular brackets. > > Thanks for the report. There is certainly a document/code mismatch. > Digging a bit, it seems that brackets started being included quite a > while ago: 8d8ad9838 (Rewrite `org-entry-properties', 2014-09-30). I > didn't spot anything in that commit that suggests that it was an > intended change. While I think it's be fair to consider this a regression, I'm leery of restoring the original behavior of stripping the brackets given how long the current behavior has been around. Instead I think it'd be better to update the documentation and tweak the output on colview's end. However, for the record, when I restored this behavior locally, here were the adjustments needed to make the tests pass. (Of course, restoring the behavior likely introduces other issues that are not caught be the tests, not to mention third-party code that relies on brackets being included.) diff --git a/lisp/org.el b/lisp/org.el index 4d1a6a6b4..18a358c85 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10817,7 +10817,7 @@ (defun org-auto-repeat-maybe (done-word) ;; a SCHEDULED time-stamp without one is removed, as they are no ;; longer relevant. (save-excursion - (let ((scheduled (org-entry-get (point) "SCHEDULED"))) + (let ((scheduled (format "<%s>" (org-entry-get (point) "SCHEDULED" (when (and scheduled (not (string-match-p org-repeat-re scheduled))) (org-remove-timestamp-with-keyword org-scheduled-string ;; Update every time-stamp with a repeater in the entry. @@ -13145,7 +13145,8 @@ (defun org-entry-properties ( pom which) (skip-chars-forward " \t") (and (looking-at org-ts-regexp-both) (push (cons (car pair) -(match-string-no-properties 0)) +(match-string-no-properties + (if (equal (car pair) "CLOSED") 0 1))) props))) (when specific (throw 'exit props))) (when (or (not specific) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 29ac0a8f9..fe07ea7e3 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -5201,12 +5201,12 @@ (ert-deftest test-org/entry-properties () (cdr (assoc "CLOSED" (org-entry-properties nil "CLOSED") (should (equal -"<2014-03-04 tue.>" +"2014-03-04 tue." (org-test-with-temp-text "* H\nDEADLINE: <2014-03-04 tue.>" (cdr (assoc "DEADLINE" (org-entry-properties nil "DEADLINE")) (should (equal -"<2014-03-04 tue.>" +"2014-03-04 tue." (org-test-with-temp-text "* H\nDEADLINE: <2014-03-04 tue.>" (cdr (assoc "DEADLINE" (org-entry-properties)) (should-not @@ -5214,12 +5214,12 @@ (ert-deftest test-org/entry-properties () (cdr (assoc "DEADLINE" (org-entry-properties nil "DEADLINE") (should (equal -"<2014-03-04 tue.>" +"2014-03-04 tue." (org-test-with-temp-text "* H\nSCHEDULED: <2014-03-04 tue.>" (cdr (assoc "SCHEDULED" (org-entry-properties nil "SCHEDULED")) (should (equal -"<2014-03-04 tue.>" +"2014-03-04 tue." (org-test-with-temp-text "* H\nSCHEDULED: <2014-03-04 tue.>" (cdr (assoc "SCHEDULED" (org-entry-properties)) (should-not
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Ihor Radchenko writes: > Currently, `org-flag-region' only removes one SPEC type of overlays: > > (remove-overlays from to 'invisible spec) > > If we change it to > > (remove-overlays from to 'invisible spec) > (when flag > (remove-overlays from to 'invisible 'org-hide-drawer) > ... > ) > > then all the extra drawer overlays in the flagged region will be > removed. It will require re-creating those extra overlays later if the > region is revealed again though. Exactly. This would be equivalent to drop `org-hide-drawer' altogether, which we did for property drawers. You have to fold again every drawer after each visibility change. For the record, this is the initial bug `org-hide-drawer' was trying to solve. Back to square one. Also, we would have the same problem with blocks.
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Ihor Radchenko writes: > This should be better: > https://gist.github.com/yantar92/e37c2830d3bb6db8678b14424286c930 Thank you. > This might get tricky in the following case: > > :PROPERTIES: > :CREATED: [2020-04-13 Mon 22:31] > > :SHOWFROMDATE: 2020-05-11 > :ID: e05e3b33-71ba-4bbc-abba-8a92c565ad34 > :END: > > > > :PROPERTIES: > :CREATED: [2020-04-27 Mon 13:50] > > :ID: b2eef49f-1c5c-4ff1-8e10-80423c8d8532 > :ATTACH_DIR_INHERIT: t > :END: > > If the text in the region is replaced by something else, in between> should not be fully hidden. We cannot simply look at the > 'invisible property before and after the changed region. Be careful: "replaced by something else" is ambiguous. "Replacing" is an unlikely change: you would need to do (setf (buffer-substring x y) "foo") We can safely assume this will not happen. If it does, we can accept the subsequent glitch. Anyway it is less confusing to think in terms of deletion and insertion. In the case above, you probably mean "the region is deleted then something else is inserted", or the other way. So there are two actions going on, i.e., `after-change-functions' are called twice. In particular the situation you foresee /cannot happen/ with an insertion. Text is inserted at a single point. Let's assume this is in the first drawer. Once inserted, both text before and after the new text were part of the same drawer. Insertion introduces other problems, though. More on this below. It is true the deletion can produce the situation above. But in this case, there is nothing to do, you just merged two drawers into a single one, which stays invisible. Problem solved. IOW, big changes like the one you describe are not an issue. I think the "check if previous and next parts match" trick gives us roughly the same functionality, and the same glitches, as overlays. However, I think we can do better than that, and also fix the glitches from overlays. Here are two of them. Write the following drawer: :FOO: bar :END: fold it and delete the ":f". The overlay is still there, and you cannot remove it with TAB any more. Or, with the same initial drawer, from beginning of buffer, evaluate: (progn (re-search-forward ":END:") (replace-match "")) This is no longer a drawer: you just removed its closing line. Yet, the overlay is still there, and TAB is ineffective. Here's an idea to develop that would make folding more robust, and still fast. Each syntactical element has a "sensitive part", a particular area that can change the nature of the element when it is altered. Luckily drawers (and blocks) are sturdy. For a drawer, there are three things to check: 1. the opening line must match org-drawer-regexp 2. the closing line must match org-property-end-re (case ignored) 3. between those, you must not insert text match org-property-end-re or org-outline-regexp-bol Obviously, point 3 needs not be checked during deletion. Instead of `after-change-functions', we may use `modification-hooks' for deletions, and `insert-behind-hooks' for insertions. For example, we might add modification-hooks property to both opening and closing line, and `insert-behind-hooks' on all the drawer. If any of the 3 points above is verified, we remove all properties. Note that if we can implement something robust with text properties, we might use them for headlines too, for another significant speed-up. WDYT? > I think that using fontification (something similar to > org-fontify-drawers) instead of after-change-functions should be > faster. I don't think it would be faster. With `after-change-functions', `modification-hooks' or `insert-behind-hook', we know exactly where the change happened. Fontification is fuzzier. It is not instantaneous either. It is an option only if we cannot do something fast and accurate with `after-change-functions', IMO.
Re: Possible bug with columnview and active dates
> I posted this question here: > https://emacs.stackexchange.com/questions/58337/how-remove-active-date-from-a-dynamic-block-using-columnview > regarding removing the active dates from a columnview. A user replied > suggesting this could maybe be a bug. > > According to the docs: > https://orgmode.org/manual/Special-Properties.html#Special-Properties > Using DEADLINE or SCHEDULED should not include the angular brackets. Thanks for the report. There is certainly a document/code mismatch. Digging a bit, it seems that brackets started being included quite a while ago: 8d8ad9838 (Rewrite `org-entry-properties', 2014-09-30). I didn't spot anything in that commit that suggests that it was an intended change.
Re: Bug: Images with link break LaTeX export with centered images [9.3.6 (9.3.6-elpa @ /home/arne/.guix-profile/share/emacs/site-lisp/)]
Nicolas Goaziou writes:
>> When I use the syntax for images with link, exporting to LaTeX fails,
>> because it uses \begin{center} inside the href:
…
>> To reproduce: use linked image syntax like this:
>>
>>
>> [[file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png][file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png]]
>
> Fixed. Thank you.
Cool — thank you!
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
Customizable fixed indentation column
Hello to all, This is my first time using the mailing list so please point out if I am going about this the wrong way. After searching a bit, I didn't find a way to specify a custom fixed indentation column in org sections; the current implementation automatically aligns content at the beginning of the line when `org-adapt-indentation' is set to nil, which I find somewhat restrictive (e.g., in this case, one should be careful when using lists beginning with '*' characters). To that end, I modified the current implementation accordingly (and added some tests) in order to allow one to set the desired indentation column to something other than the 0th, where section contents will be aligned at if adaptive indentation is disabled. I don't know if others will find this feature useful but I'll go and include the patch here anyway. If you find this worth merging but should be modified somehow before that, I would be happy to do so. Best regards, Panagiotis From 9b24257aeb11fa6f1d00eae0ac48fe0f92ca2dad Mon Sep 17 00:00:00 2001 From: Panagiotis Vlantis Date: Sun, 10 May 2020 18:09:00 +0300 Subject: [PATCH] org: Enable selection of custom indentation column * lisp/org.el (org--get-expected-indentation): Return value of `org-fixed-indentation' when `org-adapt-indentation' is nil. (org-add-planning-info): Properly indent newly added planning info. (org-fixed-indentation): Introduce customizable variable for preferred fixed indentation column. * testing/lisp/test-org.el (test-org/get-property-block, test-org/insert-property-drawer, test-org/indent-line, test-org/indent-region, test-org/add-planning-info, test-org/deadline, test-org/schedule, test-org/set-property): Modify tests depending on indentation and add more tests. Introduce variable and modify indentation mechanism accordingly in order to allow the user to specify a custom indentation column (other than zero) to be used when adaptive indentation is disabled. TINYCHANGE --- lisp/org.el | 18 ++- testing/lisp/test-org.el | 293 --- 2 files changed, 290 insertions(+), 21 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 9b9b4376b..d87d449f7 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -10639,8 +10639,9 @@ WHAT entry will also be removed." (what (end-of-line) (insert "\n") - (when org-adapt-indentation - (indent-to-column (1+ (org-outline-level) + (indent-to-column (if org-adapt-indentation + (1+ (org-outline-level)) + (max org-fixed-indentation 0 (t nil))) (when what ;; Insert planning keyword. @@ -18720,6 +18721,16 @@ hierarchy of headlines by UP levels before marking the subtree." ;;; Indentation +(defcustom org-fixed-indentation 0 + "Preferred indentation column when adaptive indentation is disabled. + +When `org-adapt-indentation' is nil, the contents of sections +shall be indented to the column specified by this variable, +independently of the the corresponding section's level." + :group 'org-edit-structure + :type 'integer + :safe #'integerp) + (defvar org-element-greater-elements) (defun org--get-expected-indentation (element contentsp) "Expected indentation column for current line, according to ELEMENT. @@ -18735,7 +18746,8 @@ ELEMENT." (cl-case type ((diary-sexp footnote-definition) 0) ((headline inlinetask nil) - (if (not org-adapt-indentation) 0 + (if (not org-adapt-indentation) + (if (org-current-level) (max org-fixed-indentation 0) 0) (let ((level (org-current-level))) (if level (1+ level) 0 ((item plain-list) (org-list-item-body-column post-affiliated)) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index a0f505cbc..baaf6d800 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -452,7 +452,15 @@ (should (equal "* H\n:PROPERTIES:\n:END:\n" (org-test-with-temp-text "* H" - (let ((org-adapt-indentation nil)) + (let ((org-adapt-indentation nil) + (org-fixed-indentation 0)) + (org-get-property-block nil 'force)) + (buffer-string + (should + (equal "* H\n :PROPERTIES:\n :END:\n" + (org-test-with-temp-text "* H" + (let ((org-adapt-indentation nil) + (org-fixed-indentation 5)) (org-get-property-block nil 'force)) (buffer-string (should @@ -473,7 +481,16 @@ (should (equal ":PROPERTIES:\n:END:\n" (org-test-with-temp-text "" - (let ((org-adapt-indentation nil)) (org-insert-property-drawer)) + (let ((org-adapt-indentation nil) + (org-fixed-indentation 0)) + (org-insert-property-drawer)) + (buffer-string + (should + (equal ":PROPERTIES:\n:END:\n" + (org-test-with-temp-text "" + (let ((org-adapt-indentation nil) + (org-fixed-indentation 5)) +
Re: [PATCH] Fix moving cursor in org-set-tags-command
Nicolas Goaziou writes: > >> -(when (save-excursion (skip-chars-backward "*") (bolp)) >> - (forward-char >> +(and (looking-at " ") >> + (string-match "\\*+" (buffer-substring (point-at-bol) (point))) >> + (forward-char > > Please replace `and' with `when' if side-effects are involved. > Thanks, this is really helpful to know for future patches. And thanks so much for the fixes you and Kyle made. > Also, note that > > (save-excursion (skip-chars-backward "*") (bolp)) > > is faster and more accurate than > > (string-match "\\*+" (buffer-substring (point-at-bol) (point))) > > because the latter matches, e.g., > > ab*|c > > where "|" is point. Oops, yes I see the problem in the string-match there! > Besides, I don't understand how this is related to empty headlines > since, AFAICT, this part of code is supposed to fix the issue on empty > headlines. Thanks. What I meant was fixing a very specific circumstance "when the cursor is at the beginning of an empty headline." This is the scenario affected by the original bug. The earlier patches (450452de4b and 44ec473c1) introduced a more general logic of moving the cursor forward at any point before the beginning of an empty headline (including when positioned on an asterisk). I see the commit has already been made, so hopefully this email will serve as clarification. Best, Matt
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
> You're talking about "overview" (org-overview), whereas I'm talking > about "contents view" (org-content). They are not the same. In the > latter, you show every headline in the buffer, so you have one overlay > per headline. Thanks for the explanation. I finally understand you initial note. I was thinking about org-overview mostly because it is the case when next/previous-line was extremely slow with many overlays jammed between two subsequent lines. >> Now, thinking second time about this, using the following for >> org-flag-region would achieve similar effect: >> >> (remove-overlays from to 'invisible 'outline) >> (remove-overlays from to 'invisible 'org-hide-drawer) >> >> Now sure if it is going to break org-cycle though. >> What do you think? > > This is already the case. See first line of `org-flag-region'. Currently, `org-flag-region' only removes one SPEC type of overlays: (remove-overlays from to 'invisible spec) If we change it to (remove-overlays from to 'invisible spec) (when flag (remove-overlays from to 'invisible 'org-hide-drawer) ... ) then all the extra drawer overlays in the flagged region will be removed. It will require re-creating those extra overlays later if the region is revealed again though. Best, Ihor Nicolas Goaziou writes: > Ihor Radchenko writes: > >> If you want, I can test the file without :LOGBOOK: lines tomorrow. > > Don't worry, it doesn't matter now. > >> No, there are only 9 'outline overlays in the folded buffer if we do not >> create overlays for drawers. This is because outline-hide-sublevels >> called by org-overview is calling outline-flag-region on the whole >> buffer thus removing all the 'outline overlays in buffer >> (remove-overlays from to 'invisible 'outline) and re-creating a single >> overlay for each top-level heading. > > You're talking about "overview" (org-overview), whereas I'm talking > about "contents view" (org-content). They are not the same. In the > latter, you show every headline in the buffer, so you have one overlay > per headline. > >> Now, thinking second time about this, using the following for >> org-flag-region would achieve similar effect: >> >> (remove-overlays from to 'invisible 'outline) >> (remove-overlays from to 'invisible 'org-hide-drawer) >> >> Now sure if it is going to break org-cycle though. >> What do you think? > > This is already the case. See first line of `org-flag-region'. > > Regards, -- 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: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Ihor Radchenko writes: > If you want, I can test the file without :LOGBOOK: lines tomorrow. Don't worry, it doesn't matter now. > No, there are only 9 'outline overlays in the folded buffer if we do not > create overlays for drawers. This is because outline-hide-sublevels > called by org-overview is calling outline-flag-region on the whole > buffer thus removing all the 'outline overlays in buffer > (remove-overlays from to 'invisible 'outline) and re-creating a single > overlay for each top-level heading. You're talking about "overview" (org-overview), whereas I'm talking about "contents view" (org-content). They are not the same. In the latter, you show every headline in the buffer, so you have one overlay per headline. > Now, thinking second time about this, using the following for > org-flag-region would achieve similar effect: > > (remove-overlays from to 'invisible 'outline) > (remove-overlays from to 'invisible 'org-hide-drawer) > > Now sure if it is going to break org-cycle though. > What do you think? This is already the case. See first line of `org-flag-region'. Regards,
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
> Unfortunately, reviewing this way is not nice. This should be better: https://gist.github.com/yantar92/e37c2830d3bb6db8678b14424286c930 > The `insert-and-inherit' issue sounds serious. We cannot reasonably > expect any library outside Org to use it. > > We could automatically extend invisible area with > `after-change-functions', i.e., if we're inserting something and both > side have the same `invisible' property, extend it. Using > `after-change-functions' sounds bad, but this kind of check shouldn't > cost much. > > WDYT? This might get tricky in the following case: :PROPERTIES: :CREATED: [2020-04-13 Mon 22:31] :SHOWFROMDATE: 2020-05-11 :ID: e05e3b33-71ba-4bbc-abba-8a92c565ad34 :END: :PROPERTIES: :CREATED: [2020-04-27 Mon 13:50] :ID: b2eef49f-1c5c-4ff1-8e10-80423c8d8532 :ATTACH_DIR_INHERIT: t :END: If the text in the region is replaced by something else, should not be fully hidden. We cannot simply look at the 'invisible property before and after the changed region. I think that using fontification (something similar to org-fontify-drawers) instead of after-change-functions should be faster. Best, Ihor Nicolas Goaziou writes: > Ihor Radchenko writes: > >> My response to you was blocked by your mail server: >> >>> 550 5.7.1 Reject for policy reason RULE3_2. See >>> http://postmaster.gandi.net > > Aka "spam detected". Bah. > >> The message landed on the mail list though: >> https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972.html > > Unfortunately, reviewing this way is not nice. > > The `insert-and-inherit' issue sounds serious. We cannot reasonably > expect any library outside Org to use it. > > We could automatically extend invisible area with > `after-change-functions', i.e., if we're inserting something and both > side have the same `invisible' property, extend it. Using > `after-change-functions' sounds bad, but this kind of check shouldn't > cost much. > > WDYT? > > Regards, -- 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: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
> I don't know how you made your test. You probably didn't > remove :LOGBOOK: lines. When headlines are fully folded, there are > 8 overlays in the buffer, where there used to be 10k. It cannot be > a "small improvement". Ouch. I did not remove :LOGBOOK: lines. I thought you referred to the original file in "I can navigate in your example file without much trouble." If you want, I can test the file without :LOGBOOK: lines tomorrow. >>> ... In current master, >>> it means there is at most 5217 overlays in the buffer. With text >>> properties, the worse situation in the same. >> >> Do you mean that number of overlays is same with text properties? I feel >> that I misunderstand what you want to say. > > AFAIU, you still use overlays for headlines. If you activate so-called > "contents view", all headlines are visible, and are all folded. You get > 5217 overlays in the buffer. No, there are only 9 'outline overlays in the folded buffer if we do not create overlays for drawers. This is because outline-hide-sublevels called by org-overview is calling outline-flag-region on the whole buffer thus removing all the 'outline overlays in buffer (remove-overlays from to 'invisible 'outline) and re-creating a single overlay for each top-level heading. Now, thinking second time about this, using the following for org-flag-region would achieve similar effect: (remove-overlays from to 'invisible 'outline) (remove-overlays from to 'invisible 'org-hide-drawer) Now sure if it is going to break org-cycle though. What do you think? Best, Ihor Nicolas Goaziou writes: > Ihor Radchenko writes: > >> I still do not feel much difference, so I used elp to quantify if there >> is any difference I cannot notice by myself. I tested the time to move >> from to bottom of the example file with next-logical-line. >> >> org master (7801e9236): >> 6(#calls) 2.852953989(total time, sec) 0.4754923315(average) >> >> org e39365e32: >> 6 2.991771891 0.4986286485 >> >> org feature/drawertextprop: >> 6 0.149731379 0.0249552298 >> >> There is small improvement in speed, but it is not obvious. > > I don't know how you made your test. You probably didn't > remove :LOGBOOK: lines. When headlines are fully folded, there are > 8 overlays in the buffer, where there used to be 10k. It cannot be > a "small improvement". > > Ah, well. It doesn't matter. At least the situation improved in some > cases, and the code is better. > >>> ... In current master, >>> it means there is at most 5217 overlays in the buffer. With text >>> properties, the worse situation in the same. >> >> Do you mean that number of overlays is same with text properties? I feel >> that I misunderstand what you want to say. > > AFAIU, you still use overlays for headlines. If you activate so-called > "contents view", all headlines are visible, and are all folded. You get > 5217 overlays in the buffer. > >>> Of course, that case happens less often with text properties. For >>> example, it happens in "contents" view in both cases. However, in "show >>> all" view, it is only a problem with overlays. >> >> I am completely lost. What do you mean by "that case"? > > I am talking about the "worse case" situation just above. > > I'll comment your patch in another message. > > Regards, -- 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: Display in minibuffer link under point
Hi, Thanks both of you for your answers. What would be the way to automatically trigger =display-local-help= when the point is on the link? Org-ref does that beautifully ;) Thanks again. Garjola On Fri 08-May-2020 at 22:48:37 +02, John Kitchin wrote: > It looks like that variable is obsolete now since Emacs 24.1, and > (tooltip-mode -1) is probably the way to get the same thing now. > > John > > --- > 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 > > On Fri, May 8, 2020 at 1:18 PM briangpowell . > wrote: > > I use this variable to toggle my Gnu Emacs Org-Mode buffer into an audio > desktop: > > (setq tooltip-use-echo-area (not tooltip-use-echo-area)) > > Of course I had to do some programming to do that but the above should get > you started > > And we can leave that programming as an exercise for the class--right Dr. > Kitchin? > > ;-) > > On Fri, May 8, 2020 at 9:19 AM John Kitchin wrote: > > M-x display-local-help might do it. > > John > > --- > 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 > > On Fri, May 8, 2020 at 9:15 AM Garjola Dindi wrote: > > Hi, > > Is there a way to display in the minibuffer the URL of the link under > the point in the same way as when the mouse pointer is over the link? > > Thanks! > > Garjola > -- --
Re: "\_" sequences in indented lines of column view dynamic blocks
Thanks, understood. It would be nice to have to have an option to just use other indentation characters like "." for ASCII or special blanks for other encoding. And what about the second question? I'm looking for something like a minlevel argument. Am So., 10. Mai 2020 um 17:33 Uhr schrieb Nicolas Goaziou < m...@nicolasgoaziou.fr>: > Hello, > > "Dauer, Michael" writes: > > > What are the "\_" sequences in indented lines of column view dynamic > blocks > > good for? > > Those are entities, like, e.g., \alpha. They have two effects. > > 1. They allow indenting the cell in the buffer. Text columns are left >aligned otherwise. > > 2. They preserve indentation upon export. > > > I just find them ugly and irritating. > > Sorry about that. Note it is our best idea to solve both problems so > far. It you have something better, please tell us! > > Regards, > > -- > Nicolas Goaziou >
Re: "\_" sequences in indented lines of column view dynamic blocks
Hello, "Dauer, Michael" writes: > What are the "\_" sequences in indented lines of column view dynamic blocks > good for? Those are entities, like, e.g., \alpha. They have two effects. 1. They allow indenting the cell in the buffer. Text columns are left aligned otherwise. 2. They preserve indentation upon export. > I just find them ugly and irritating. Sorry about that. Note it is our best idea to solve both problems so far. It you have something better, please tell us! Regards, -- Nicolas Goaziou
Possible bug with columnview and active dates
Hello, I posted this question here: https://emacs.stackexchange.com/questions/58337/how-remove-active-date-from-a-dynamic-block-using-columnview regarding removing the active dates from a columnview. A user replied suggesting this could maybe be a bug. According to the docs: https://orgmode.org/manual/Special-Properties.html#Special-Properties Using DEADLINE or SCHEDULED should not include the angular brackets. Thank you!
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Nicolas Goaziou writes: > Ihor Radchenko writes: > >> My response to you was blocked by your mail server: >> >>> 550 5.7.1 Reject for policy reason RULE3_2. See >>> http://postmaster.gandi.net > > Aka "spam detected". Bah. > >> The message landed on the mail list though: >> https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972.html > > Unfortunately, reviewing this way is not nice. It's probably not helpful at this point, but just in case: you can get that message's mbox with curl -fSs https://yhetil.org/orgmode/87imh5w1zt.fsf@localhost/raw >mbox
"\_" sequences in indented lines of column view dynamic blocks
Hi,
What are the "\_" sequences in indented lines of column view dynamic blocks
good for? I just find them ugly and irritating. See the simple example
below:
#+BEGIN: columnview :indent t :id local
| ITEM | a |
|---+---|
| column view | 7 |
| \_ item1 | 3 |
| \_item1.1 | 3 |
| \_ item2 | 4 |
#+END
And is there a way to omit the root of the branch ("column view" in this
case)?
thx
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Ihor Radchenko writes: > My response to you was blocked by your mail server: > >> 550 5.7.1 Reject for policy reason RULE3_2. See >> http://postmaster.gandi.net Aka "spam detected". Bah. > The message landed on the mail list though: > https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127972.html Unfortunately, reviewing this way is not nice. The `insert-and-inherit' issue sounds serious. We cannot reasonably expect any library outside Org to use it. We could automatically extend invisible area with `after-change-functions', i.e., if we're inserting something and both side have the same `invisible' property, extend it. Using `after-change-functions' sounds bad, but this kind of check shouldn't cost much. WDYT? Regards,
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Ihor Radchenko writes: > I still do not feel much difference, so I used elp to quantify if there > is any difference I cannot notice by myself. I tested the time to move > from to bottom of the example file with next-logical-line. > > org master (7801e9236): > 6(#calls) 2.852953989(total time, sec) 0.4754923315(average) > > org e39365e32: > 6 2.991771891 0.4986286485 > > org feature/drawertextprop: > 6 0.149731379 0.0249552298 > > There is small improvement in speed, but it is not obvious. I don't know how you made your test. You probably didn't remove :LOGBOOK: lines. When headlines are fully folded, there are 8 overlays in the buffer, where there used to be 10k. It cannot be a "small improvement". Ah, well. It doesn't matter. At least the situation improved in some cases, and the code is better. >> ... In current master, >> it means there is at most 5217 overlays in the buffer. With text >> properties, the worse situation in the same. > > Do you mean that number of overlays is same with text properties? I feel > that I misunderstand what you want to say. AFAIU, you still use overlays for headlines. If you activate so-called "contents view", all headlines are visible, and are all folded. You get 5217 overlays in the buffer. >> Of course, that case happens less often with text properties. For >> example, it happens in "contents" view in both cases. However, in "show >> all" view, it is only a problem with overlays. > > I am completely lost. What do you mean by "that case"? I am talking about the "worse case" situation just above. I'll comment your patch in another message. Regards,
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
>> I tested with master + my personal config + native compilation of org, >> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae. >> Did not see much improvement. >> Vertical motion in the folded buffer is still quite slow. > > Oh! This is embarrassing. I improved speed, then broke it again in > a later commit. Sorry for wasting your time. I think I fixed it again. > Thank you for the feedback. > > Could you have a look again? I still do not feel much difference, so I used elp to quantify if there is any difference I cannot notice by myself. I tested the time to move from to bottom of the example file with next-logical-line. org master (7801e9236): 6(#calls) 2.852953989(total time, sec) 0.4754923315(average) org e39365e32: 6 2.991771891 0.4986286485 org feature/drawertextprop: 6 0.149731379 0.0249552298 There is small improvement in speed, but it is not obvious. > ... In current master, > it means there is at most 5217 overlays in the buffer. With text > properties, the worse situation in the same. Do you mean that number of overlays is same with text properties? I feel that I misunderstand what you want to say. > Of course, that case happens less often with text properties. For > example, it happens in "contents" view in both cases. However, in "show > all" view, it is only a problem with overlays. I am completely lost. What do you mean by "that case"? Best, Ihor Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >>> Oops, you are right. I fixed this. It should be way faster. I can >>> navigate in your example file without much trouble. >>> >>> Please let me know how it goes. >> >> I tested with master + my personal config + native compilation of org, >> Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae. >> Did not see much improvement. >> Vertical motion in the folded buffer is still quite slow. > > Oh! This is embarrassing. I improved speed, then broke it again in > a later commit. Sorry for wasting your time. I think I fixed it again. > Thank you for the feedback. > > Could you have a look again? > >> Apparently I misunderstood the purpose of: 1027e0256 >> "Implement `org-cycle-hide-property-drawers'" > > The function is meant to re-hide only property drawers after visibility > cycling. Its purpose is not to improve /unfolding/ speed. Unfolding is > very fast already, faster than using text properties. > > Folding has roughly the same speed in both cases: most time is spent > looking for the next location to fold. However, folding with text > properties is more resilient, so you fold less often. > > As a side note, your file contains 5217 headlines and 5215 property > drawers. I'll ignore the 3989 regular drawers for the time being > (although they do contribute to the slow navigation). In current master, > it means there is at most 5217 overlays in the buffer. With text > properties, the worse situation in the same. > > Of course, that case happens less often with text properties. For > example, it happens in "contents" view in both cases. However, in "show > all" view, it is only a problem with overlays. > > Regards, > > -- > Nicolas Goaziou -- 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: patch for org-capture.el to allow for no file extension on open-source, protocol
Hello, "Stacey Marshall" writes: > The issue was that the URL I was opening had the full filename as-is. > No extension needed to be added or removed. If no suffix is provided > in the alist then the function failed. The patch allows both > online-suffix and working-suffix to not be required. Thank you. Could you add a test in "test-org-protocol.el" ? Regards, -- Nicolas Goaziou
Re: [Patch] Do not ignore headers argument in ob-latex
Hello, Yuri Lensky writes: > I have updated the attached patch to use `mapconcat' as requested. > `org-format-latex-header' is already declared earlier in ob-latex.el. I fixed the commit message and applied the patch. Thank you. > I am not sure what kind of test you have in mind, since this feature isn't > completely internal to org-mode. For example, the preview compiles but the > produced PDF is incorrect before this fix, and I believe the org preview > machinery ignores errors from the latex compiler. I was thinking about regression testing `org-babel-execute:latex'. But it may not make much sense, indeed. Regards, -- Nicolas Goaziou
Re: Bug: Images with link break LaTeX export with centered images [9.3.6 (9.3.6-elpa @ /home/arne/.guix-profile/share/emacs/site-lisp/)]
Hello,
Arne Babenhauserheide writes:
> When I use the syntax for images with link, exporting to LaTeX fails,
> because it uses \begin{center} inside the href:
>
>
> \href{covid-19-germany-infections-by-date-prognosen-2020-03-23.png}{\begin{center}
>
> \includegraphics[width=.9\linewidth]{covid-19-germany-infections-by-date-prognosen-2020-03-23.png}
> \end{center}}
>
> I have a workaround to set
>
> # Local Variables:
> # org-latex-images-centered: nil
> # End:
>
> but this is no proper fix.
>
> To reproduce: use linked image syntax like this:
>
>
> [[file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png][file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png]]
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
Re: [RFC] Let Org Mode's completion support all Babel header arguments
Hello, stardiviner writes: > I found Org Mode's completion (from ~completion-at-point-functions~ which is > provided by ~pcomplete-completions-at-point~) can complete in bellowing places > (the "|" represent cursor point): [...] > So I think Org Mode need an union API to manage those keywords. WDYT? pcomplete certainly needs some love. There is already `org-babel-common-header-args-w-values' and `org-babel-header-args:LANG'. You may want to look into `org-lint-wrong-header-value' to check how they are used. Regards, -- Nicolas Goaziou
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: >> Oops, you are right. I fixed this. It should be way faster. I can >> navigate in your example file without much trouble. >> >> Please let me know how it goes. > > I tested with master + my personal config + native compilation of org, > Emacs native-comp branch, commit c984a53b4e198e31d11d7bc493dc9a686c77edae. > Did not see much improvement. > Vertical motion in the folded buffer is still quite slow. Oh! This is embarrassing. I improved speed, then broke it again in a later commit. Sorry for wasting your time. I think I fixed it again. Thank you for the feedback. Could you have a look again? > Apparently I misunderstood the purpose of: 1027e0256 > "Implement `org-cycle-hide-property-drawers'" The function is meant to re-hide only property drawers after visibility cycling. Its purpose is not to improve /unfolding/ speed. Unfolding is very fast already, faster than using text properties. Folding has roughly the same speed in both cases: most time is spent looking for the next location to fold. However, folding with text properties is more resilient, so you fold less often. As a side note, your file contains 5217 headlines and 5215 property drawers. I'll ignore the 3989 regular drawers for the time being (although they do contribute to the slow navigation). In current master, it means there is at most 5217 overlays in the buffer. With text properties, the worse situation in the same. Of course, that case happens less often with text properties. For example, it happens in "contents" view in both cases. However, in "show all" view, it is only a problem with overlays. Regards, -- Nicolas Goaziou
Bug: Images with link break LaTeX export with centered images [9.3.6 (9.3.6-elpa @ /home/arne/.guix-profile/share/emacs/site-lisp/)]
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
When I use the syntax for images with link, exporting to LaTeX fails,
because it uses \begin{center} inside the href:
\href{covid-19-germany-infections-by-date-prognosen-2020-03-23.png}{\begin{center}
\includegraphics[width=.9\linewidth]{covid-19-germany-infections-by-date-prognosen-2020-03-23.png}
\end{center}}
I have a workaround to set
# Local Variables:
# org-latex-images-centered: nil
# End:
but this is no proper fix.
To reproduce: use linked image syntax like this:
[[file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png][file:covid-19-germany-infections-by-date-prognosen-2020-03-23.png]]
Then export to LaTeX.
Expected: Exports to LaTeX with centered images.
Actual: Export fails with
[2] [3 <./covid-19-germany-infections-by-date.png>] [4] [5
<./covid-19-germany-
infections-by-date-prognosen.png>] [6]
! pdfTeX error (ext1): \pdfendlink cannot be used in vertical mode.
\close@pdflink ...\Hy@VerboseLinkStop \pdfendlink
l.135 \end{center}}
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on .//covid-19-naiver-blick.log.
Best wishes,
Arne
Emacs : GNU Emacs 26.3 (build 1, x86_64-unknown-linux-gnu, GTK+ Version
3.24.14)
Package: Org mode version 9.3.6 (9.3.6-elpa @
/home/arne/.guix-profile/share/emacs/site-lisp/)
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
