Re: Failing tests

[Kyle Meyer]

Kévin Le Gouguec writes:

> Kyle Meyer  writes:
>
>>> I think I've narrowed this down to org-open-file running "less
>>> examples/att1/fileA" instead of visiting this file.
>> [...]
>>> Let-binding org-file-apps to '(("." . emacs)) makes the tests pass, but
>>> I don't know if that's the way we want to solve this.
>>
>> Thanks for looking into the failures.  Let-binding org-file-apps sounds
>> like a good approach to me.  Rather than the catch-all regular
>> expression, I believe the value could be ((t . emacs)).
>
> Absolutely.  I've attached a patch to that effect.

Thanks.  Applied (c8f7e89d7).

> I wonder though, shouldn't org-open-file always visit text/plain files?
> Why would we ever want to send those to an external viewer?
>
> I think this would need special-casing inside org-open-file, since I
> don't see a way to catch all text/plain files with org-file-apps.

Good question.  I'm not sure, though offhand I can't think of cases
where I'd want to send text/plain files to an external viewer.  I'd
guess this doesn't matter much in practice given the default position of

  (auto-mode . emacs)

in org-file-apps, which will catch a good number of text/plain files.

Re: Bug: org-collect-keywords is void when config uses org-babel-load-file [9.3.6 (release_9.3.6-683-g3b2de4 @ /home/eric/.emacs.d/straight/build/org/)]

[Kyle Meyer]

Eric Berquist writes:

> When loading a configuration using `(org-babel-load-file (concat
> user-emacs-directory "config.org"))` in `init.el`, this message is reported:
>
> org-export--get-inbuffer-options: Symbol’s function definition is
> void: org-collect-keywords
>
> and export doesn't work.

Hmm, org-export--get-inbuffer-options is defined in ox.el, and
org-collect-keywords in org.el.  Even though ox.el doesn't load org.el
explicitly, it pulls it in through other things (org-element, at least),
so it should be defined.  But based on the org-babel-load-file
instructions you're giving, an older org.el is already loaded, and
presumably that is what is leading to the error.

I'd assume that in general using the built-in Org to load a newer Org is
going to be susceptible to these sorts of issues (along the lines of
what's described at ).

Re: [PATCH] implementing `with' as a list, and respecting `deps' order.

[Kyle Meyer]

Mario Frasca writes:

>  From 436bfd0b9fd656f52ea9d7e6a6a665a32564ae93 Mon Sep 17 00:00:00 2001
> From: Mario Frasca 
> Date: Tue, 2 Jun 2020 15:46:20 +
> Subject: [PATCH] implementing `with' as a list, and respecting `deps' order.

Thank you for sending an updated patch.  Unfortunately it looks like it
got mangled by your email client and can't be understood by `git am'.
This list is okay with patches being sent as attachments, and going that
route gets around needing to re-configure your email client or use
git-send-email.

Before sending the updated patch, please revise the commit message to
more closely match the conventions described at
.  Looking over some
recent commits in the repo should give you a good sense for the expected
changelog-like entries as well other style aspects (e.g., it is common
to start the subject with ": " like "org-plot: ..."), which
gives log readers a sense for the general topic affected by the commit.

Please send the next patch as a follow-up to the original thread to keep
the discussion in one place.

Thanks again.

[PATCH] some minimal refactoring for the sake of unit-testing, and a, couple of tests.

[Mario Frasca]

From 0ee824cccf793734fa18d42b67d44dae2a2e136e Mon Sep 17 00:00:00 2001
From: mfrasca 
Date: Tue, 2 Jun 2020 15:48:46 -0500
Subject: [PATCH] some minimal refactoring for the sake of unit-testing, 
and a

 couple of tests.

---
 lisp/org-plot.el  |  18 ++-
 testing/lisp/test-org-plot.el | 207 ++
 2 files changed, 220 insertions(+), 5 deletions(-)
 create mode 100644 testing/lisp/test-org-plot.el

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..f4526db13 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -91,8 +91,8 @@ Return value is the point at the beginning of the table."
   (while (not (or (org-at-table-p) (< 0 (forward-line 1)
   (goto-char (org-table-begin)))

-(defun org-plot/collect-options (&optional params)
-  "Collect options from an org-plot `#+Plot:' line.
+(defun org-plot/collect-line-options (&optional params)
+  "Collect options from the org-plot `#+Plot:' line at point.
 Accepts an optional property list PARAMS, to which the options
 will be added.  Returns the resulting property list."
   (interactive)
@@ -101,6 +101,16 @@ will be added.  Returns the resulting property list."
 (org-plot/add-options-to-plist params (match-string 1 line))
   params)))

+(defun org-plot/collect-table-options (&optional params)
+  "Collect options from the `#+Plot:' lines preceding the current table.
+Point must immediately after last `#+Plot:' line.
+Accepts an optional property list PARAMS, to which the options will be 
added.

+Returns the accumulated property list."
+  (save-excursion (while (and (equal 0 (forward-line -1))
+              (looking-at "[[:space:]]*#\\+"))
+            (setq params (org-plot/collect-line-options params
+  params)
+
 (defun org-plot-quote-timestamp-field (s)
   "Convert field S from timestamp to Unix time and export to gnuplot."
   (format-time-string org-plot-timestamp-fmt (org-time-string-to-time s)))
@@ -299,9 +309,7 @@ line directly before or after the table."
   (plist-put params :labels (nth 0 table))) ; headers to labels
 (setf table (delq 'hline (cdr table ; clean non-data from table
   ;; Collect options.
-  (save-excursion (while (and (equal 0 (forward-line -1))
-                  (looking-at "[[:space:]]*#\\+"))
-            (setf params (org-plot/collect-options params
+  (setq params (org-plot/collect-table-options params))
   ;; Dump table to datafile (very different for grid).
   (pcase (plist-get params :plot-type)
 (`2d   (org-plot/gnuplot-to-data table data-file params))
diff --git a/testing/lisp/test-org-plot.el b/testing/lisp/test-org-plot.el
new file mode 100644
index 0..b23075050
--- /dev/null
+++ b/testing/lisp/test-org-plot.el
@@ -0,0 +1,207 @@
+;;; test-org-plot.el --- Tests for Org Plot library -*- 
lexical-binding: t; -*-

+
+;; Copyright (C) 2020  Mario Frasca
+
+;; Author: Mario Frasca 
+
+;; This file is not part of GNU Emacs.
+
+;; This program is free software; you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; This program is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with this program.  If not, see .
+
+;;; Code:
+
+(require 'org-test)
+(require 'org-plot)
+
+
+;; General auxiliaries
+
+
+(ert-deftest test-org-plot/collect-line-options ()
+  "Test `org-plot/collect-line-options' specifications."
+  ;; no options specified in table, no defaults
+  (should
+   (equal nil
+  (org-test-with-temp-text
+  "| 1 |"
+    (org-plot/collect-line-options
+  ;; no options specified in table, keeps all defaults
+  (should
+   (equal '(:ind 1 :deps 2 3)
+  (org-test-with-temp-text
+  "| 1 |"
+    (org-plot/collect-line-options '(:ind 1 :deps 2 3)
+  ;; the independent column
+  (should
+   (equal '(:ind 1)
+  (org-test-with-temp-text
+  "#+PLOT: ind:1\n| 1 |"
+    (org-plot/collect-line-options
+  ;; overruling default
+  (should
+   (equal '(:ind 2)
+  (org-test-with-temp-text
+  "#+PLOT: ind:2\n| 1 | 2 |"
+    (org-plot/collect-line-options '(:ind 1)
+  ;; appends to already collected
+  (should
+   (equal '(:deps (1 3) :ind 2 )
+  (org-test-with-temp-text
+  "#+PLOT: ind:2\n| 1 | 2 | 3 |"
+    (org-plot/collect-line-options '(:deps (1 3))
+  ;; appends to already collected
+  (should
+   (equal '(:ind 2 :deps (1 3) )
+  (org-test-with-temp-text
+  "#+PLOT: ind:2\n| 1 | 2 | 3

Re: Anyone doing any fancy customizations of source blocks?

[John Kitchin]

Here is one approach:

https://pank.eu/blog/pretty-babel-src-blocks.html

I feel like I have seen some work that used ruby and python icons as
displays over #+begin_src, but I can't find it 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 Tue, Jun 2, 2020 at 2:54 PM William Denton  wrote:

> Is anyone doing any fancy formatting of source blocks, such as putting a
> line
> in the left fringe, or a box around them, or having some interesting
> background?
>
> I ask because I recently changed the theme I use to get the dark Solarized
> look
> I like,[1] and all of a sudden my #+begin_src lines were underlined and
> #+end_src had a line above it.  These come from org-block-begin-line and
> org-block-end-line, and are shown here, but I'd never noticed them in
> documentation or had them on my screen before:
>
>
> https://orgmode.org/worg/org-contrib/babel/examples/fontify-src-code-blocks.html
>
> Aside from fontifying the source blocks I've never done anything special
> about
> them (except wonder how I ever did anything without them), but seeing this
> made
> me wonder if anyone here has really customized them so they look like
> medieval
> manuscripts or something from a futuristic video game.  (If any of that is
> possible---but in Emacs, anything is possible ...)
>
> Bill
>
> [1] Now I'm using https://github.com/bbatsov/solarized-emacs, with
> variable
> pitch turned off and Org headline resizing turned off.
>
> --
> William Denton :: Toronto, Canada   ---   Listening to Art:
> https://listeningtoart.org/
> https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
> Caveat lector.  ---   STAPLR: https://staplr.org/
>
>

Anyone doing any fancy customizations of source blocks?

[William Denton]

Is anyone doing any fancy formatting of source blocks, such as putting a line
in the left fringe, or a box around them, or having some interesting background?

I ask because I recently changed the theme I use to get the dark Solarized look 
I like,[1] and all of a sudden my #+begin_src lines were underlined and 
#+end_src had a line above it.  These come from org-block-begin-line and 
org-block-end-line, and are shown here, but I'd never noticed them in 
documentation or had them on my screen before:


https://orgmode.org/worg/org-contrib/babel/examples/fontify-src-code-blocks.html

Aside from fontifying the source blocks I've never done anything special about 
them (except wonder how I ever did anything without them), but seeing this made 
me wonder if anyone here has really customized them so they look like medieval 
manuscripts or something from a futuristic video game.  (If any of that is 
possible---but in Emacs, anything is possible ...)


Bill

[1] Now I'm using https://github.com/bbatsov/solarized-emacs, with variable 
pitch turned off and Org headline resizing turned off.


--
William Denton :: Toronto, Canada   ---   Listening to Art: 
https://listeningtoart.org/
https://www.miskatonic.org/ ---   GHG.EARTH: https://ghg.earth/
Caveat lector.  ---   STAPLR: https://staplr.org/

Export to attach directory?

[Eric Abrahamsen]

I think the last thing I'm missing before my Org set up is Absolutely
Perfect and never needs to be tweaked again (ha!) is the ability to
export Org files/subtrees to their relevant ATTACH directories, if any.
It might be overkill to have a global setting for this, but I would
love to be able to say:

* Report #25 :ATTACH:
:PROPERTIES:
:ID:   3da327aa-b51e-444a-ae5c-95bb56d025a9
:EXPORT_FILE_NAME: report_25
:EXPORT_TO_ATTACH: t
:END:

Or maybe a property with an ATTACH prefix, I'm not sure. I find myself
having to use Google Docs more and more, for collaboration, and this
would let me use a package that mounts G-Docs on your filesystem, and
export directly there. (And it would keep my Org directory tidy!)

Has anyone cooked this up before? I wasn't able to find anything on the
web.

I'm imagining that org-attach.el could add something to
`org-export-before-processing-hook', to check for the presence of this
property, and set/rewrite the EXPORT_FILE_NAME property, if it's
present.

WDYT?

Eric

[PATCH] docstrings to match the code, and minor cosmetics.

[Mario Frasca]

From 43cc6264deb89fcc665d123b06c7c2aebb35ab3a Mon Sep 17 00:00:00 2001
From: Mario Frasca 
Date: Tue, 2 Jun 2020 16:22:07 +
Subject: [PATCH] docstrings to match the code, and minor cosmetics.

---
 lisp/org-plot.el | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..3a95c72d6 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -85,14 +85,18 @@ Returns the resulting property list."
   p)

 (defun org-plot/goto-nearest-table ()
-  "Move the point forward to the beginning of nearest table.
-Return value is the point at the beginning of the table."
-  (interactive) (move-beginning-of-line 1)
+  "Move the point to the beginning of table.
+Moves back if the point is inside a table, otherwise looks for next table.
+If there is no table to be found, moves to end of buffer.
+Return value is the point."
+  (interactive)
+  (move-beginning-of-line 1)
   (while (not (or (org-at-table-p) (< 0 (forward-line 1)
   (goto-char (org-table-begin)))

 (defun org-plot/collect-options (&optional params)
   "Collect options from an org-plot `#+Plot:' line.
+Examines the line at point.
 Accepts an optional property list PARAMS, to which the options
 will be added.  Returns the resulting property list."
   (interactive)
@@ -143,7 +147,8 @@ and dependent variables."
  (counter 0)
  row-vals)
 (when (>= ind 0) ;; collect values of ind col
-  (setf row-vals (mapcar (lambda (row) (setf counter (+ 1 counter))
+  (setf row-vals (mapcar (lambda (row)
+               (setf counter (+ 1 counter))
            (cons counter (nth ind row)))
          table)))
 (when (or deps (>= ind 0)) ;; remove non-plotting columns
@@ -156,7 +161,8 @@ and dependent variables."
           table)))
 ;; write table to gnuplot grid datafile format
 (with-temp-file data-file
-  (let ((num-rows (length table)) (num-cols (length (nth 0 table)))
+  (let ((num-rows (length table))
+        (num-cols (length (nth 0 table)))
     (gnuplot-row (lambda (col row value)
            (setf col (+ 1 col)) (setf row (+ 1 row))
            (format "%f  %f  %f\n%f  %f  %f\n"
@@ -180,7 +186,8 @@ and dependent variables."
 row-vals))

 (defun org-plot/gnuplot-script (data-file num-cols params &optional 
preface)
-  "Write a gnuplot script to DATA-FILE respecting the options set in 
PARAMS.

+  "Return gnuplot script respecting the options set in PARAMS.
+DATA-FILE is the name of the data containing file.
 NUM-COLS controls the number of columns plotted in a 2-d plot.
 Optional argument PREFACE returns only option parameters in a
 manner suitable for prepending to a user-specified script."
@@ -274,7 +281,7 @@ manner suitable for prepending to a user-specified 
script."

 (defun org-plot/gnuplot (&optional params)
   "Plot table using gnuplot.  Gnuplot options can be specified with 
PARAMS.

 If not given options will be taken from the +PLOT
-line directly before or after the table."
+line(s) directly before the table."
   (interactive)
   (require 'gnuplot)
   (save-window-excursion
--
2.20.1

[PATCH] implementing `with' as a list, and respecting `deps' order.

[Mario Frasca]

From 436bfd0b9fd656f52ea9d7e6a6a665a32564ae93 Mon Sep 17 00:00:00 2001
From: Mario Frasca 
Date: Tue, 2 Jun 2020 15:46:20 +
Subject: [PATCH] implementing `with' as a list, and respecting `deps' order.

---
 doc/org-manual.org    |  7 ++--
 lisp/org-plot.el  | 66 +--
 testing/lisp/test-org-plot.el | 64 +
 3 files changed, 108 insertions(+), 29 deletions(-)
 create mode 100644 testing/lisp/test-org-plot.el

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 92252179b..40cb3c2f2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -2845,9 +2845,10 @@ For more information and examples see the 
[[https://orgmode.org/worg/org-tutoria


 - =with= ::

-  Specify a =with= option to be inserted for every column being
-  plotted, e.g., =lines=, =points=, =boxes=, =impulses=. Defaults to
-  =lines=.
+  Specify a =with= option to be inserted for the columns being
+  plotted, e.g., =lines=, =points=, =boxes=, =impulses=. You can specify
+  a single value, to be applied to all columns, or a list of different
+  values, one for each column in the =deps= property. Defaults to =lines=.

 - =file= ::

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index a23195d2a..073075037 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -179,6 +179,24 @@ and dependent variables."
   (setf back-edge "") (setf front-edge ""
 row-vals))

+(defun org-plot/zip-deps-with (num-cols ind deps with)
+  "Describe each column to be plotted as (col . with).
+Loops over DEPS and WITH in order to cons their elements.
+If the DEPS list of columns is not given, use all columns from 1
+to NUM-COLS, excluding IND.
+If WITH is given as a string, use the given value for all columns.
+If WITH is given as a list, and it's shorter than DEPS, expand it
+with the global default value."
+  (unless deps
+    (setq deps (remove ind (number-sequence 1 num-cols
+  (setq with
+    (if (listp with)
+        (append with
+            (make-list (max 0 (- (length deps) (length with)))
+               "lines"))
+      (make-list (length deps) with)))
+  (cl-mapcar #'cons deps with))
+
 (defun org-plot/gnuplot-script (data-file num-cols params &optional 
preface)
   "Write a gnuplot script to DATA-FILE respecting the options set in 
PARAMS.

 NUM-COLS controls the number of columns plotted in a 2-d plot.
@@ -239,32 +257,27 @@ manner suitable for prepending to a user-specified 
script."

            (or timefmt    ; timefmt passed to gnuplot
            "%Y-%m-%d-%H:%M:%S") "\"")))
 (unless preface
-  (pcase type            ; plot command
-    (`2d (dotimes (col num-cols)
-       (unless (and (eq type '2d)
-                (or (and ind (equal (1+ col) ind))
-                (and deps (not (member (1+ col) deps)
-         (setf plot-lines
-           (cons
-            (format plot-str data-file
-                (or (and ind (> ind 0)
-                     (not text-ind)
-                     (format "%d:" ind)) "")
-                (1+ col)
-                (if text-ind (format ":xticlabel(%d)" ind) "")
-                with
-                (or (nth col col-labels)
-                    (format "%d" (1+ col
-            plot-lines)
-    (`3d
-     (setq plot-lines (list (format "'%s' matrix with %s title ''"
-                    data-file with
-    (`grid
-     (setq plot-lines (list (format "'%s' with %s title ''"
-                    data-file with)
+  (setq plot-lines
+        (pcase type            ; plot command
+      (`2d (cl-loop
+            for (col . with)
+            in (org-plot/zip-deps-with num-cols ind deps with)
+            collect (format plot-str data-file
+                    (or (and ind (> ind 0)
+                     (not text-ind)
+                     (format "%d:" ind)) "")
+                    col
+                    (if text-ind (format ":xticlabel(%d)" ind) "")
+                    with
+                    (or (nth (1- col) col-labels)
+                    (format "%d" col)
+      (`3d (list (format "'%s' matrix with %s title ''"
+                 data-file with)))
+      (`grid (list (format "'%s' with %s title ''"
+                   data-file with)
   (funcall ats
    (concat plot-cmd " " (mapconcat #'identity
-                       (reverse plot-lines)
+                       plot-lines
                    ",\\\n    "
 script))

@@ -310,7 +323,8 @@ line directly before or after the table."
             table data-file params)))
      (when y-labels (plist-put params :ylabels y-labels)
   ;; Check for timestamp ind column.
-  (let ((ind (1- (plist-get params :ind
+  (let ((ind (1- (plist-get params :ind)))
+        (with (plist-get params :with)))
 (when (and (>= ind 0) (eq '2d (plist-get params :plot-type)))
   (if (= (length
       (delq 0 (mapcar
@@ -320

Re: A small idea to simplify (further) time input in the date/time prompt

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Gustavo Barros  writes:

> Hi stardiviner,
>
> On Tue, Jun 02 2020, stardiviner wrote:
>>
>> Which date/time prompt do you mean? Like set schedule or deadline? If just 
>> raw
>> timestamp, it makes me confused whether it is time continuance.
>>
>
> The date/time prompt is Org's interface for querying for date and time which 
> is
> described in the [[info:org#The date/time prompt]] section of the manual.  It 
> is
> indeed the interface you get when calling 'org-time-stamp', 'org-schedule',
> 'org-deadline' etc.

Thanks for declaration. I see, I have not noticed Org have this way treating
input time value. Glad about learning new stuff.

> As mentioned before in the thread, the suggestion is orthogonal to the 
> timestamp
> format or with document syntax.  It is just an alternative way to input time 
> in
> the date/time prompt, which should produce the same good old timestamp.

That's great.

>
> Best,
> Gustavo.


- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WZXMUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOcUgf/X765J3pj9TdAXLKy+IWNH9KTB92y
H0KR25vOZmKqxnrSDrjxajbiJ/iSQkujaVJMsfAGf4v/w+GSeqtHqip745BIhGIb
2TG6dOpE1L3FnKREmC93uuSs3bemciezD4CM7qAjB1DvpNVGiy4NiEbzmoHPjMpY
arvxObEeHmceOEc/1oqFlJfmb7sO5YKfd4xoAHofr+sSpVrG7ophbIAHNVQiAhvt
gQItQ7wudD9wlp42dBP6V56W2ON2VXIuDpCWNEpjvx3MtxvGgvoa1Y8x+RqB3pd6
TL60qk85wdwLRcjl69q2P9Zz4XBk3iWOHfL9mIBJ7ZKqtHwBVzy/6olTig==
=VaY4
-END PGP SIGNATURE-

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Bastien  writes:

> Hi Stardiviner,
>
> stardiviner  writes:
>
>> I think maybe Org maintainer can improve the org-attach code to suitable to 
>> add
>> custom function. 
>
> Sorry, I don't understand.
>
> Can you to use M-x customize-option RET org-attach-commands RET then
> add a custom command pointing to the command you have written, bound
> to a keybinding of your choice?
>
> If something does not work with this approach, can you show me what
> you tried and what does not work?

Here is my patch, I try to annotate on my patch code to express my words:

#+begin_src diff
- From 6c667461b45e93059c6f801e485f7da4bfc3606c Mon Sep 17 00:00:00 2001
From: stardiviner 
Subject: [PATCH] * org-attach.el: add a new command to archive web page

,* lisp/org-attach.el (org-attach-url-archive): A new org-attach
dispatcher command to archive web page to a single file.

,* lisp/org-agenda.el (org-attach-url-archive-command): A customize
option to specify external command for archiving web page.

,* lisp/org-attach.el (org-attach-url-archive-page): A command
invoke external command to offline archive save web page.
- ---
 lisp/org-attach.el | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 57d1360fc..80855d147 100644
- --- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -204,6 +204,8 @@ (defcustom org-attach-commands
  "Attach a file using symbolic-link method.")
 ((?u ?\C-u) org-attach-url
  "Attach a file from URL (downloading it).")
+((?U) org-attach-url-archive
+ "Attach an offline version of web page URL.") <- This 
`org-attach-commands' is an option which indeead can be customized.
 ((?b) org-attach-buffer
  "Select a buffer and attach its contents to the task.")
 ((?n ?\C-n) org-attach-new
@@ -467,6 +469,31 @@ (defun org-attach-url (url)
   (let ((org-attach-method 'url))
 (org-attach-attach url)))
 
+(defun org-attach-url-archive (url)
<-+
+  (interactive "MURL of the web page be archived to attach: \n")   
  |
+  (let ((org-attach-method 'archive))  
  |
+(org-attach-attach url)))  
  |
+   
  |
+(defcustom org-attach-url-archive-command  
  |  You can see, all those function code can be put in user configuration. Yes.
+  (file-name-nondirectory (executable-find "monolith"))
  |
+  "The command used to offline archive web page.   
  |
+monolith can be found here: https://github.com/Y2Z/monolith.";  
  |
+  :type 'string
  |
+  :safe #'stringp  
  |
+  :group 'org-attach)  
  |
+   
  |
+(defun org-attach-url-archive-page (url target-file)   
  |
+  "Save an offline archive of web page."   
  |
+  (pcase org-attach-url-archive-command
  |
+("monolith"
  |
+ (make-process 
  |
+  :name "org-attach-offline"   
  |
+  :command (list org-attach-url-archive-command url "-o" target-file)  
  |
+  :sentinel (lambda (proc event) (message "org-attach-offline finished!")) 
  |
+  :buffer "*org-attach-url-archive*")) 
  |
+(nil (warn "You must have a command availble for offline save web page!
  |
+Set variable `org-attach-url-archive-command'."   
<--+
+
 (defun org-attach-buffer (buffer-name)
   "Attach BUFFER-NAME's contents to current outline node.
 BUFFER-NAME is a string.  Signals a `file-already-exists' error
@@ -504,7 +531,8 @@ (defun org-attach-attach (file &optional visit-dir method)
((eq method 'cp) (copy-file file attach-file))
((eq method 'ln) (add-name-to-file file attach-file))
((eq method 'lns) (make-symbolic-link file attach-file))
- -   ((eq method 'url) (url-copy-file file attach-file)))
+   ((eq method 'url) (url-copy-file file attach-file))
<-- But this can't be don'e through advice or something else. 
Unless copy whole function code.
+   ((eq method 'archive) (org-attach-url-archive-page file attach-file)))  
   In my less elisp knowledge, I don't have any idea how to add a new 
org-attach method in `org-attach-attach'.

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[Bastien]

Hi Stardiviner,

stardiviner  writes:

> I think maybe Org maintainer can improve the org-attach code to suitable to 
> add
> custom function. 

Sorry, I don't understand.

Can you to use M-x customize-option RET org-attach-commands RET then
add a custom command pointing to the command you have written, bound
to a keybinding of your choice?

If something does not work with this approach, can you show me what
you tried and what does not work?

-- 
 Bastien

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi stardiviner,

On Tue, Jun 02 2020, stardiviner wrote:


Which date/time prompt do you mean? Like set schedule or deadline? If 
just raw

timestamp, it makes me confused whether it is time continuance.



The date/time prompt is Org's interface for querying for date and time 
which is described in the [[info:org#The date/time prompt]] section of 
the manual.  It is indeed the interface you get when calling 
'org-time-stamp', 'org-schedule', 'org-deadline' etc.


As mentioned before in the thread, the suggestion is orthogonal to the 
timestamp format or with document syntax.  It is just an alternative way 
to input time in the date/time prompt, which should produce the same 
good old timestamp.


Best,
Gustavo.

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Bastien  writes:

> Hi,
>
> stardiviner  writes:
>
>> I added monolith link to defcustom option docstring now. Update
>> patch again.
>
> thanks for working on this, sorry for coming late to the party.
>
> The initial need was to be able to download big web documents
> asynchronously* but the conversation drifted and the patch now is
> about adding a new org-attach command, using monolith.

No, my patch's purpose is to offline archive the whole web page completely.

>
> org-attach-commands is an option that users can customize to suit
> their needs.  Adding the ability to use monolith is fine, and we can
> advertize through Worg, but I don't think it should be in Org's core,
> because (1) monolith is never preinstalled and (2) there seems to be a
> thin and non-obvious difference between what `org-attach-url' and what
> `org-attach-url-archive' provide -- unless I miss something?

Well, It is acceptable if you think reply on monolith is un-acceptable.

I think maybe Org maintainer can improve the org-attach code to suitable to add
custom function. In my patch, If I want to add a custom function to archive
without modify Org Mode org-attach code, customize is not possible. So do you
have any idea to improve current org-attach code, make it suitable for things
like my patch?

>
> So please don't hesitate to document this on
> https://orgmode.org/worg/org-hacks.html or any other page!
>
> Thanks,
>
> * BTW, I still think implementing url-copy-file-asynchronously
> is something that would be useful within Emacs core!

I remember I send an email to emacs-dev mailing list, but seems this is not
implemented. So 

- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WXNoUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOJ1wgAwxeVRr8DS5VmN49SP6g5BfcNUYGy
V6BdIBH2DFFU1F68df8VR/zIgq94QylsoAGR/9R6zyDv7iWBiHZxCBdnn4CXkYsh
k18td+lcRmG9M2sr40FvLeNW5bNseI1Sz0quNrSOlc+1n0DDH9AiTEWUQEGCE2gW
53u2zQak4woFCuQToNP2AWm9vd+U7yBDBtkdz2vFYnqQ5TUMLC17bDcKYDPEXMVj
X0QulekeVhFw+iheQ2s63bU/IpaeU3fdylZhctNECNUqHRf9If+mOInpKYmZ3xsP
JDly8+tjtOPHlr0Llizzd07805NwNGhONyH8DXdeI7AeAQJudYkAt6x8lw==
=PEyv
-END PGP SIGNATURE-

Re: A small idea to simplify (further) time input in the date/time prompt

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Gustavo Barros  writes:

> Hi All,
>
> the Org date/time prompt does deliver the promise in the manual that we "start
> getting annoyed by pretty
> much any other way of entering a date/time out there".  It has indeed become 
> so
> for me, as the date/time prompt is very neat.  But there is one place where
> input could be even shorter, which is time input.
>
> Currently, time input mostly requires "hour colon minutes", thus a full time
> specification even when minutes are "00".  And "mostly" because you can get 
> away
> with that last part if you use am/pm convention (alas, I do not belong to 
> those
> strange corners of the world).  Besides, the colon is a shift-key in many 
> common
> keyboard layouts (from a simple search, it seems to be so in British, 
> American,
> US International, German, Spanish, and Portuguese layouts, it doesn't seem to 
> be
> so for the French layout though).
>
> So I'd like to suggest a simplification there, which is: a string in the 
> format
> "hour h minute" (that's small caps letter "H"), but in which "hour h" would 
> also
> be recognized as a full hour and "00" minutes presumed.  The mnemonic is 
> obvious
> for "hour", which works well for English, French, Spanish, Portuguese, not so
> much for German.
>
> With this, we'd have some example inputs, and their respective results:
>
> 8h   -> 08:00
> 10h30-> 10:30
> 18h  -> 18:00
> 9h-10h   -> 09:00-10:00
> 9h30-10h -> 09:30-10:00
> 14h+1h   -> 14:00-15:00
>

Which date/time prompt do you mean? Like set schedule or deadline? If just raw
timestamp, it makes me confused whether it is time continuance.

> This would ease input in two ways.  First, it presumes the minutes in full
> hours, thus dispensing with this typing.  Considering full hours are a very
> common case for scheduling and appointments, that shortening should be
> significant.  It is also one key shorter than the am/pm way for full hours, 
> and
> two keys shorter for non full hours in the same case.  Second, it is easier to
> type "h" than it is to type ":", it is easier to reach and it is not a
> shift-key, so the chord is gone too.
>
> One corner case which will arise is if "zero hour" should also be presumed.
> Arguably midnight is not that common in most people's agenda, and could be
> either "0h" or "24h", so we should not really worry in shortening something 
> like
> "midnight and thirty minutes" as "h30".  But this is more tricky with duration
> specification, that is with "+".  In this case minutes not comprising a full
> hour might well be common.  So, how to specify an appointment starting at 
> 10:00
> that lasts 30 minutes? Some alternatives could be: "10h+0h30", "10h+h30",
> "10h+30m".  On a first thought I like the last one better, but I'm really not
> sure what the best approach should be here.
>
> Needless to say, current input conventions should not change.  This is just
> thought as an additional way of inputting time, alongside the ones which 
> already
> exist.  I'm unaware of any use of "h" in the date/time prompt (or of "m", for
> that matter), so I presume this should be viable without conflicting with 
> other
> currently recognized input forms.
>
>
> That's the small suggestion I had to make for the date/time prompt.  I guess,
> technically, this should be filed as "feature request".  But it is just an 
> idea
> I bring to your consideration, in the hope someone else here also likes it.
>
>
> Best,
> Gustavo.


- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WWxwUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOi4Qf/RpkotaYxjmrDA+SsjqK4ep7sLM+Y
tLwm+N47cYYDGPNR3M9o9WZYNxLncygdxXF2eYQjX7DQHmuZ8rLLyNa3Yb9P7vUb
OYywOyTWgSa5wgp1cOJepcFS384DZvZeSg+odhrJDr5wPfhfN7NpbhB3VB3TLiEr
hIHx1XzBfZbNifMR90gupPIZt2IEfHqcoI7zGa1uHfoDRPYDU61m2cVj4ZZDc1Ya
H8gPAFQD+oGbg32PUw6vQn4a6x7Qk668G0kP52e5yCISG8S5P7BKrk0HSKClPUxM
GjH0kYVm5DzEOm6YQvnWfGr2EIDuHLlMxvBaxyIXmMYc+k61RBAisKS1WA==
=QSbI
-END PGP SIGNATURE-

Re: [QUESTION] What's the ":desk" link parameter?

[stardiviner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Ihor Radchenko  writes:

>> I'm not sure `org-link-make-description-function' is used a lot out
>> there, but the change may break existing configurations/hacks.
>
> It should not break anything. I did not remove
> `org-link-make-description-function' functionality. Just marked it as
> deprecated.
>
>> Also, is it something we could use in the current export backends
>> or just for the users?  If the latter, then I'm in favor of making
>> this move, probably for 9.5.
>
> I am not very familiar with the export code, but the function provided
> in :description property should follow the same conventions with
> `org-link-make-description-function'. The only place it is used is
> org-insert-link. I do not see how it can influence export code. As I
> understand, org-insert-link is mostly for users.

I agree, I used org-store-link and org-insert-link a lot. If this patch is
applied, then I can add more smart rules to auto generate the description based
on file extension etc.

>
> Best,
> Ihor
>
>
> Bastien  writes:
>
>> Hi Ihor,
>>
>> Ihor Radchenko  writes:
>>
 thanks for the patch.  I assume you are submitting it against master,
 am I right?
>>>
>>> The patch is against commit 2e96dc639.
>>
>> I see, thanks.
>>
 From reading this, I don't see what bug it fixes, what problem it
 solves or what real user need it responds to, but maybe I lost part
 of the context.  Can you explain why this should be applied?
>>>
>>> It does not fix any bug. Rather adds a new feature [1]. Currently, org
>>> provides org-link-make-description-function as user customisation to
>>> compute default link description. The patch provides a way to set such
>>> description functions on per link type basis (via :description link
>>> parameter). Using link parameters looks natural for me since similar
>>> customisation is already done in :follow and :store link parameters.
>>
>> Okay, I understand.  It feels natural to me too.
>>
>> I'm not sure `org-link-make-description-function' is used a lot out
>> there, but the change may break existing configurations/hacks.
>>
>> Also, is it something we could use in the current export backends
>> or just for the users?  If the latter, then I'm in favor of making
>> this move, probably for 9.5.
>>
>> Nicolas, what do you think?
>>
>> -- 
>>  Bastien


- -- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WWmEUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsMUewf/RK9/BCnTbNyiNKMklORPitNALPxb
xJC4OKQiwkrPLK1y8m1sUa8Qu1rgg/vb/CSa/lJYJOY448hL6IxAJAxMdGvw0k1g
xIyslnyHu7WxneouxhYr5qIQFWtdJFtKPcuPvMN9VfryD/fxtA+n9rjfw9FLEZuf
Rqp+/clRzQC6BfrYP35OTb1srryST9PblUv283VR6MQASS7QRlHRlVNykFsNWvb9
2kaRt+uB5KqIGVYWIkLYwE1aelw4iUdg/sQkl5keZHIBU/DE5RqPEWFzyIfgcROz
EGUVBh0z0wiAqpm8Ncj7M0MwjkQnNLiRuMWH485NhlSKdMKjDKog7fOMkA==
=pi7r
-END PGP SIGNATURE-

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Oh, I thought this was already done.  Do you need to submit the form
> or do you wait for the FSF confirmation?

Need to submit.

Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>>> Thanks -- just a quick note, in case you missed the message: we are in
>>> feature free for core functionalities, so we have time to work on this 
>>> welcome enhancement for Org 9.5, which will give us time to properly
>>> test it too.
>>
>> I do not expect it to be merged any time soon. The patch is modifying
>> low-level internals. It certainly needs a careful testing under various
>> user configs. 
>
> Indeed, thanks for your patience.
>
>> Not to mention that so big patch will require FSF
>> paperwork, unless I miss something.
>
> Oh, I thought this was already done.  Do you need to submit the form
> or do you wait for the FSF confirmation?
>
> -- 
>  Bastien

-- 
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: [QUESTION] What's the ":desk" link parameter?

[Ihor Radchenko]

> I'm not sure `org-link-make-description-function' is used a lot out
> there, but the change may break existing configurations/hacks.

It should not break anything. I did not remove
`org-link-make-description-function' functionality. Just marked it as
deprecated.

> Also, is it something we could use in the current export backends
> or just for the users?  If the latter, then I'm in favor of making
> this move, probably for 9.5.

I am not very familiar with the export code, but the function provided
in :description property should follow the same conventions with
`org-link-make-description-function'. The only place it is used is
org-insert-link. I do not see how it can influence export code. As I
understand, org-insert-link is mostly for users.

Best,
Ihor


Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>>> thanks for the patch.  I assume you are submitting it against master,
>>> am I right?
>>
>> The patch is against commit 2e96dc639.
>
> I see, thanks.
>
>>> From reading this, I don't see what bug it fixes, what problem it
>>> solves or what real user need it responds to, but maybe I lost part
>>> of the context.  Can you explain why this should be applied?
>>
>> It does not fix any bug. Rather adds a new feature [1]. Currently, org
>> provides org-link-make-description-function as user customisation to
>> compute default link description. The patch provides a way to set such
>> description functions on per link type basis (via :description link
>> parameter). Using link parameters looks natural for me since similar
>> customisation is already done in :follow and :store link parameters.
>
> Okay, I understand.  It feels natural to me too.
>
> I'm not sure `org-link-make-description-function' is used a lot out
> there, but the change may break existing configurations/hacks.
>
> Also, is it something we could use in the current export backends
> or just for the users?  If the latter, then I'm in favor of making
> this move, probably for 9.5.
>
> Nicolas, what do you think?
>
> -- 
>  Bastien

-- 
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

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

>> Thanks -- just a quick note, in case you missed the message: we are in
>> feature free for core functionalities, so we have time to work on this 
>> welcome enhancement for Org 9.5, which will give us time to properly
>> test it too.
>
> I do not expect it to be merged any time soon. The patch is modifying
> low-level internals. It certainly needs a careful testing under various
> user configs. 

Indeed, thanks for your patience.

> Not to mention that so big patch will require FSF
> paperwork, unless I miss something.

Oh, I thought this was already done.  Do you need to submit the form
or do you wait for the FSF confirmation?

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

> Thanks -- just a quick note, in case you missed the message: we are in
> feature free for core functionalities, so we have time to work on this 
> welcome enhancement for Org 9.5, which will give us time to properly
> test it too.

I do not expect it to be merged any time soon. The patch is modifying
low-level internals. It certainly needs a careful testing under various
user configs. Not to mention that so big patch will require FSF
paperwork, unless I miss something.

Best,
Ihor

Bastien  writes:

> Hi Ihor,
>
> Ihor Radchenko  writes:
>
>> The patch (against 758b039c0) is attached.
>
> Thanks -- just a quick note, in case you missed the message: we are in
> feature free for core functionalities, so we have time to work on this 
> welcome enhancement for Org 9.5, which will give us time to properly
> test it too.
>
> -- 
>  Bastien

-- 
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: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi Bastien,

On Tue, Jun 02 2020, Bastien wrote:


I like this idea, thanks for proposing it.  We are in feature freeze
for core features, so we have time to work on this for Org 9.5.


Of course, there's absolutely no rush in this, and this is clearly not 
something to be added shortly before a release.  Thank you very much for 
considering it.



Gustavo Barros  writes:

With this, we'd have some example inputs, and their respective 
results:


8h   -> 08:00
10h30-> 10:30
18h  -> 18:00
9h-10h   -> 09:00-10:00
9h30-10h -> 09:30-10:00


All the above looks good to me as more flexible ways to input time. 


But:


14h+1h   -> 14:00-15:00


is not necessary.  Instead, 14h+1 should produce 14:00-15:00.

This way, the "+" in "[hour]+N" as the same meaning, whether [hour] is
formed as HH:MM or as Hh.

Would you agree?


I wasn't aware that a plain number after "+" in "[hour]+N" was 
interpreted as "N hours", I always went for a "3-4 digit plus colon" 
format to specify duration.  But this is indeed a strong argument for 
things to work the same way for both kinds of input.


Besides, I like the idea, but I'm probably missing something.  In this 
case, how would you then input a duration smaller than an hour? Let's 
say 30 minutes? 


Would you like to work on this change?


I'm not sure I'm up for the task, but I would be willing to try. 
However, there's another problem.  I can't offer signed papers for the 
foreseeable future.  I'd love to, I've contacted FSF to do so last year, 
but my current employment terms imposed a barrier there, which I cannot 
circumvent.  So I've been trying to contribute in the ways that I can, 
with ideas, reports, and so on.  And I hope to be doing so with good 
ones.


Anyway, if you, with your knowledge of the date/time prompt, think this 
sort of change might fit into a "tiny change" (even if it turns out it 
doesn't, ex-post), I'd be willing to give it a shot.  But otherwise, 
I've got my hands tied.


Thanks again.

Best,
Gustavo.

Re: Bug: org-html-export-to-html doesn't handle .gpg files properly [9.3.6 (9.3.6-17-g389288-elpa @ /home/adalricus/.emacs.d/elpa/org-20200224/)]

[Bastien]

Hi,

Adalricus Ovicula  writes:

> - create a file called "test.org.gpg"
> - run org-html-export-to-html
>
> File gets exported as test.org.html, shouldn't it be test.html?

Yes it should -- I will have a look at this, and if the fix does not
feel to hackish I will commit it.

Thanks,

-- 
 Bastien

Re: [QUESTION] What's the ":desk" link parameter?

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

>> thanks for the patch.  I assume you are submitting it against master,
>> am I right?
>
> The patch is against commit 2e96dc639.

I see, thanks.

>> From reading this, I don't see what bug it fixes, what problem it
>> solves or what real user need it responds to, but maybe I lost part
>> of the context.  Can you explain why this should be applied?
>
> It does not fix any bug. Rather adds a new feature [1]. Currently, org
> provides org-link-make-description-function as user customisation to
> compute default link description. The patch provides a way to set such
> description functions on per link type basis (via :description link
> parameter). Using link parameters looks natural for me since similar
> customisation is already done in :follow and :store link parameters.

Okay, I understand.  It feels natural to me too.

I'm not sure `org-link-make-description-function' is used a lot out
there, but the change may break existing configurations/hacks.

Also, is it something we could use in the current export backends
or just for the users?  If the latter, then I'm in favor of making
this move, probably for 9.5.

Nicolas, what do you think?

-- 
 Bastien

Re: [Feature] add a new org-attach dispatcher command to offline save web page

[Bastien]

Hi,

stardiviner  writes:

> I added monolith link to defcustom option docstring now. Update
> patch again.

thanks for working on this, sorry for coming late to the party.

The initial need was to be able to download big web documents
asynchronously* but the conversation drifted and the patch now is
about adding a new org-attach command, using monolith.

org-attach-commands is an option that users can customize to suit
their needs.  Adding the ability to use monolith is fine, and we can
advertize through Worg, but I don't think it should be in Org's core,
because (1) monolith is never preinstalled and (2) there seems to be a
thin and non-obvious difference between what `org-attach-url' and what
`org-attach-url-archive' provide -- unless I miss something?

So please don't hesitate to document this on
https://orgmode.org/worg/org-hacks.html or any other page!

Thanks,

* BTW, I still think implementing url-copy-file-asynchronously
is something that would be useful within Emacs core!

-- 
 Bastien

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Bastien]

Hi Ihor,

Ihor Radchenko  writes:

> The patch (against 758b039c0) is attached.

Thanks -- just a quick note, in case you missed the message: we are in
feature free for core functionalities, so we have time to work on this 
welcome enhancement for Org 9.5, which will give us time to properly
test it too.

-- 
 Bastien

Re: A small idea to simplify (further) time input in the date/time prompt

[Bastien]

Hi Gustavo,

I like this idea, thanks for proposing it.  We are in feature freeze
for core features, so we have time to work on this for Org 9.5.

Gustavo Barros  writes:

> With this, we'd have some example inputs, and their respective results:
>
> 8h   -> 08:00
> 10h30-> 10:30
> 18h  -> 18:00
> 9h-10h   -> 09:00-10:00
> 9h30-10h -> 09:30-10:00

All the above looks good to me as more flexible ways to input time. 

But:

> 14h+1h   -> 14:00-15:00

is not necessary.  Instead, 14h+1 should produce 14:00-15:00.

This way, the "+" in "[hour]+N" as the same meaning, whether [hour] is
formed as HH:MM or as Hh.

Would you agree?  Would you like to work on this change?

Thanks,

-- 
 Bastien

Re: [PATCH] Add support for trace and error output streams in Common Lisp

[Bastien]

Hi,

akater  writes:

> This patch can't be merged right away: I need to sort out the exact
> SLIME version where the feature will be introduced. Some doc update is
> needed, too.

did you finally managed to finalize this patch?

If so, can you send it to the list as an attachment?

We are in feature freeze, but small enhancement on ob- and ol- files
are acceptable if they don't break anything for the user.

Thanks,

-- 
 Bastien

Re: issue tracker?

[Bastien]

Hi Mario,

Mario Frasca  writes:

> On 01/06/2020 10:53, Bastien wrote:
>> Let us know what would help you contribute more.
>
> as mentioned, I would like to correct docstrings, refactor the code in
> a few points, and add unit tests.

Please go ahead.  Read https://orgmode.org/worg/org-contribute.html
and submit your first patch following the rules we have for the commit
messages (they are not easily understood for newcomers).  After a few
well-formatted useful patches, we can perhaps add you as a committer.

Thanks,

-- 
 Bastien 

Re: issue tracker?

[Bastien]

Hi Vladimir,

Vladimir Nikishkin  writes:

> Does any other email client apart from Gnus support adding
> additional headers?

M-x mail RET
M-x compose-mail RET

And surely quite a few other email clients, even outside Emacs.

If a user cannot set the headers herself, that's not a problem:
someone with this ability can help with the bug triage anyway.

Also, let me make something more clear: we don't want all emails
from M-x org-submit-bug-report to be flagged as "bug" - because
many are not real bugs.  The manual confirmation step is here to
help flagging the relevant entries only (not flagging bugs that
are immediatey fixed neither.)

I hope it makes sense to you.

-- 
 Bastien

Re: Bug: Export dispatcher scrolling with hidden top [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]

[Bastien]

Hi Gustavo,

Gustavo Barros  writes:

> this is a friendly ping on this export dispatcher regression.
> (Considering
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-06/msg00038.html).

thanks for the ping.

It is on my radar but I didn't have time to look seriously into it.

I keep this in mind before 9.4.

-- 
 Bastien

Re: issue tracker?

[Vladimir Nikishkin]

Does any other email client apart from Gnus support adding additional headers?

-- 
Yours sincerely, Vladimir Nikishkin

Re: Bug: Export dispatcher scrolling with hidden top [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]

[Gustavo Barros]

Hi All,

this is a friendly ping on this export dispatcher regression.
(Considering 
https://lists.gnu.org/archive/html/emacs-orgmode/2020-06/msg00038.html).


I just re-tested it now and the recipe provided in the report still 
generates the issue in the current weekly build.


Of course, if anyone is already onto it, please disregard the ping.

Best,
Gustavo.

On Sat, Feb 29 2020, Gustavo Barros wrote:


Hi All,

The export dispatcher scrolling seems to interact unfavorably general 
Emacs
scroll option "scroll-margin", in particular, setting it a positive 
displaces
the dispatcher upwards, eventually hiding completely the options 
section at

the top, even when there is space in the frame/window to fit the whole
dispatcher. You can scroll back to it, but it seems both inconvenient 
and hard

to find if one does not know "it should be there".

I hope the following minimal example is reproducible by you.  But it 
might not
be, given the interaction with frame size, results may well depend on 
things
which are not controlled.  Besides, even though I managed to come up 
with this

reproducible (to me) example, I'm still not sure I grasp properly the
interactions involved.  So, in case you cannot reproduce, I can 
provide

further info as requested.

Start "emacs -Q" and do some setup:

#+begin_src emacs-lisp
(package-initialize)
(add-to-list 'default-frame-alist '(height . 42))
(setq scroll-margin 3)
#+end_src

Find an Org file in other frame with "C-x 5 f". Run 
org-export-dispatch ("C-c

C-e"), and see that the top of the dispatcher is not visible.

Best,
Gustavo.


Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30)

of 2019-11-11
Package: Org mode version 9.3.6 (9.3.6-17-g389288-elpaplus @
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)

current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-odt-format-headline-function 
'org-odt-format-headline-default-function
org-ascii-format-inlinetask-function 
'org-ascii-format-inlinetask-default

org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
   local]
   5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
   org-babel-show-result-all
append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes
 org-eldoc-load)
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME 
CONTENTS)"]

org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn

ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ 
CONTENTS)"]

org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME 
CONTENTS

WIDTH)"]
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" 
. php)

  ("C" . c) ("C++" . c++) ("asymptote" . asy)
  ("bash" . sh) ("beamer" . latex) ("calc"
  . fundamental)
  ("cpp" . c++) ("ditaa" . artist) ("dot"
  . fundamental)
  ("elisp" . emacs-lisp) ("ocaml" . tuareg)
  ("screen" . shell-script) ("shell" . sh)
  ("sqlite" . sql))
org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-show-empty-lines

  org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-open-link 
:export

org-attach-export-link :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow eww :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store
   org-mhe-store-link)
   ("irc" :follow org-irc-visit :store
 

Re: Using est+ with effort estimate range

[Axel Kielhorn]

> Am 30.05.2020 um 14:40 schrieb Axel Kielhorn :
> 
> Hello,
> 
> according to the manual, there is a special column type for column view
> 
> ‘est+’Add low-high estimates.
> 
> This is explained later:
> 
> The ‘est+’ summary type requires further explanation. It is used for 
> combining estimates, expressed as low-high ranges. For example, instead of 
> estimating a particular task will take 5 days, you might estimate it as 5–6 
> days if you’re fairly confident you know how much work is required, or 1–10 
> days if you do not really know what needs to be done. Both ranges average at 
> 5.5 days, but the first represents a more predictable delivery.

There was a bug report in 2014:

Date: Tue, 16 Dec 2014 11:45:21 -0500
Message-ID: 
To: emacs-orgmode@gnu.org
Subject: [O] Bug: est+ not working,
 or perhaps under-documented [8.2.10 (release_8.2.10 @
 c:/Users/yhluc00/emacs/share/emacs/24.4/lisp/org/)]

With a reply and a patch by Nicolas:

From: Nicolas Goaziou 
Date: Tue, 16 Dec 2014 23:57:48 +0100
Subject: Re: [O] Bug: est+ not working,
or perhaps under-documented [8.2.10 (release_8.2.10 @
c:/Users/yhluc00/emacs/share/emacs/24.4/lisp/org/)]
X-BeenThere: emacs-orgmode@gnu.org
X-Mailman-Version: 2.1.14

Proper syntax is simply

  :Effort: 4-12

But this gives:
Invalid duration format: "4-12“

Here is the patch:

Fix low-high estimates  c1558d34d   Nicolas Goaziou 
16.12.2014, 23:53

Greetings Axel

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Github link to the patch:
https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef 


Ihor Radchenko  writes:

> Hello,
>
> [The patch itself will be provided in the following email]
>
> I have three updates from the previous version of the patch:
>
> 1. I managed to implement buffer-local text properties.
>Now, outline folding also uses text properties without a need to give
>up independent folding in indirect buffers.
>
> 2. The code handling modifications in folded drawers/blocks was
>rewritten. The new code uses after-change-functions to re-hide text
>inserted in the middle of folded regions; and text properties to
>unfold folded drawers/blocks if one changes BEGIN/END line.
>
> 3. [experimental] Started working on improving memory and cpu footprint
>of the old code related to folding/unfolding. org-hide-drawer-all now
>works significantly faster because I can utilise simplified drawer
>parser, which require a lot less memory. Overall, I managed to reduce
>Emacs memory footprint after loading all my agenda_files twice. The
>loading is also noticeably faster.
>
> ---
> ---
>
> More details on the buffer-local text properties:
>
> I have found char-property-alias-alist variable that controls how Emacs
> calculates text property value if the property is not set. This variable
> can be buffer-local, which allows independent 'invisible states in
> different buffers.
>
> All the implementation stays in
> org--get-buffer-local-text-property-symbol, which takes care about
> generating unique property name and mapping it to 'invisible (or any
> other) text property.
>
> ---
> ---
>
> More details on the new implementation for tracking changes:
>
> I simplified the code as suggested, without using pairs of before- and
> after-change-functions.
>
> Handling text inserted into folded/invisible region is handled by a
> simple after-change function. After testing, it turned out that simple
> re-hiding text based on 'invisible property of the text before/after the
> inserted region works pretty well.
>
> Modifications to BEGIN/END line of the drawers and blocks is handled via
> 'modification-hooks + 'insert-behind-hooks text properties (there is no
> after-change-functions analogue for text properties in Emacs). The
> property is applied during folding and the modification-hook function is
> made aware about the drawer/block boundaries (via apply-partially
> passing element containing :begin :end markers for the current
> drawer/block). Passing the element boundary is important because the
> 'modification-hook will not directly know where it belongs to. Only the
> modified region (which can be larger than the drawer) is passed to the
> function. In the worst case, the region can be the whole buffer (if one
> runs revert-buffer).
>
> It turned out that adding 'modification-hook text property takes a
> significant cpu time (partially, because we need to take care about
> possible existing 'modification-hook value, see
> org--add-to-list-text-property). For now, I decided to not clear the
> modification hooks during unfolding because of poor performance.
> However, this approach would lead to partial unfolding in the following
> case:
>
> :asd:
> :drawer:
> lksjdfksdfjl
> sdfsdfsdf
> :end:
>
> If :asd: was inserted in front of folded :drawer:, changes in :drawer:
> line of the new folded :asd: drawer would reveal the text between
> :drawer: and :end:.
>
> Let me know what you think on this.
>
>> You shouldn't be bothered by the case you're describing here, for
>> multiple reasons.
>> 
>> First, this issue already arises in the current implementation. No one
>> bothered so far: this change is very unlikely to happen. If it becomes
>> an issue, we could make sure that `org-reveal' handles this.
>> 
>> But, more importantly, we actually /want it/ as a feature. Indeed, if
>> DRAWER is expanded every time ":BLAH:" is inserted above, then inserting
>> a drawer manually would unfold /all/ drawers in the section. The user is
>> more likely to write first ":BLAH:" (everything is unfolded) then
>> ":END:" than ":END:", then ":BLAH:".
>
> Agree. This allowed me to simplify the code significantly.
>
>> 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 t

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

The patch (against 758b039c0) is attached.

diff --git a/contrib/lisp/org-notify.el b/contrib/lisp/org-notify.el
index 9f8677871..ab470ea9b 100644
--- a/contrib/lisp/org-notify.el
+++ b/contrib/lisp/org-notify.el
@@ -246,7 +246,7 @@ seconds.  The default value for SECS is 20."
   (switch-to-buffer (find-file-noselect file))
   (org-with-wide-buffer
(goto-char begin)
-   (outline-show-entry))
+   (org-show-entry))
   (goto-char begin)
   (search-forward "DEADLINE: <")
   (search-forward ":")
diff --git a/contrib/lisp/org-velocity.el b/contrib/lisp/org-velocity.el
index bfc4d6c3e..2312b235c 100644
--- a/contrib/lisp/org-velocity.el
+++ b/contrib/lisp/org-velocity.el
@@ -325,7 +325,7 @@ use it."
   (save-excursion
 (when narrow
   (org-narrow-to-subtree))
-(outline-show-all)))
+(org-show-all)))
 
 (defun org-velocity-edit-entry/inline (heading)
   "Edit entry at HEADING in the original buffer."
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 92252179b..ff3e31abe 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -509,11 +509,11 @@ Org uses just two commands, bound to {{{kbd(TAB)}}} and
   Switch back to the startup visibility of the buffer (see [[*Initial
   visibility]]).
 
-- {{{kbd(C-u C-u C-u TAB)}}} (~outline-show-all~) ::
+- {{{kbd(C-u C-u C-u TAB)}}} (~org-show-all~) ::
 
   #+cindex: show all, command
   #+kindex: C-u C-u C-u TAB
-  #+findex: outline-show-all
+  #+findex: org-show-all
   Show all, including drawers.
 
 - {{{kbd(C-c C-r)}}} (~org-reveal~) ::
@@ -529,18 +529,18 @@ Org uses just two commands, bound to {{{kbd(TAB)}}} and
   headings.  With a double prefix argument, also show the entire
   subtree of the parent.
 
-- {{{kbd(C-c C-k)}}} (~outline-show-branches~) ::
+- {{{kbd(C-c C-k)}}} (~org-show-branches~) ::
 
   #+cindex: show branches, command
   #+kindex: C-c C-k
-  #+findex: outline-show-branches
+  #+findex: org-show-branches
   Expose all the headings of the subtree, but not their bodies.
 
-- {{{kbd(C-c TAB)}}} (~outline-show-children~) ::
+- {{{kbd(C-c TAB)}}} (~org-show-children~) ::
 
   #+cindex: show children, command
   #+kindex: C-c TAB
-  #+findex: outline-show-children
+  #+findex: org-show-children
   Expose all direct children of the subtree.  With a numeric prefix
   argument {{{var(N)}}}, expose all children down to level
   {{{var(N)}}}.
@@ -7294,7 +7294,7 @@ its location in the outline tree, but behaves in the following way:
   command (see [[*Visibility Cycling]]).  You can force cycling archived
   subtrees with {{{kbd(C-TAB)}}}, or by setting the option
   ~org-cycle-open-archived-trees~.  Also normal outline commands, like
-  ~outline-show-all~, open archived subtrees.
+  ~org-show-all~, open archived subtrees.
 
 -
   #+vindex: org-sparse-tree-open-archived-trees
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index f07c3b801..a9c4d9eb2 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6824,7 +6824,7 @@ and stored in the variable `org-prefix-format-compiled'."
 	(t "  %-12:c%?-12t% s")))
 	(start 0)
 	varform vars var e c f opt)
-(while (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([ .;,:!?=|/<>]?\\)\\([cltseib]\\|(.+)\\)"
+(while (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([ .;,:!?=|/<>]?\\)\\([cltseib]\\|(.+?)\\)"
 			 s start)
   (setq var (or (cdr (assoc (match-string 4 s)
 '(("c" . category) ("t" . time) ("l" . level) ("s" . extra)
@@ -9136,20 +9136,20 @@ if it was hidden in the outline."
  ((and (called-interactively-p 'any) (= more 1))
   (message "Remote: show with default settings"))
  ((= more 2)
-  (outline-show-entry)
+  (org-show-entry)
   (org-show-children)
   (save-excursion
 	(org-back-to-heading)
 	(run-hook-with-args 'org-cycle-hook 'children))
   (message "Remote: CHILDREN"))
  ((= more 3)
-  (outline-show-subtree)
+  (org-show-subtree)
   (save-excursion
 	(org-back-to-heading)
 	(run-hook-with-args 'org-cycle-hook 'subtree))
   (message "Remote: SUBTREE"))
  ((> more 3)
-  (outline-show-subtree)
+  (org-show-subtree)
   (message "Remote: SUBTREE AND ALL DRAWERS")))
 (select-window win)))
 
diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index d3e12d17b..d864dad8a 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -330,7 +330,7 @@ direct children of this heading."
 		  (insert (if datetree-date "" "\n") heading "\n")
 		  (end-of-line 0))
 		;; Make the subtree visible
-		(outline-show-subtree)
+		(org-show-subtree)
 		(if org-archive-reversed-order
 			(progn
 			  (org-back-to-heading t)
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index e50a4d7c8..e656df555 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -699,7 +699,7 @@ FUN is a function called with no argument."
 			  (move-beginning-of-line 2)
 			  (org-at-heading-p t)
 (unwind-protect (funcall fun)

Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers

[Ihor Radchenko]

Hello,

[The patch itself will be provided in the following email]

I have three updates from the previous version of the patch:

1. I managed to implement buffer-local text properties.
   Now, outline folding also uses text properties without a need to give
   up independent folding in indirect buffers.

2. The code handling modifications in folded drawers/blocks was
   rewritten. The new code uses after-change-functions to re-hide text
   inserted in the middle of folded regions; and text properties to
   unfold folded drawers/blocks if one changes BEGIN/END line.

3. [experimental] Started working on improving memory and cpu footprint
   of the old code related to folding/unfolding. org-hide-drawer-all now
   works significantly faster because I can utilise simplified drawer
   parser, which require a lot less memory. Overall, I managed to reduce
   Emacs memory footprint after loading all my agenda_files twice. The
   loading is also noticeably faster.

---
---

More details on the buffer-local text properties:

I have found char-property-alias-alist variable that controls how Emacs
calculates text property value if the property is not set. This variable
can be buffer-local, which allows independent 'invisible states in
different buffers.

All the implementation stays in
org--get-buffer-local-text-property-symbol, which takes care about
generating unique property name and mapping it to 'invisible (or any
other) text property.

---
---

More details on the new implementation for tracking changes:

I simplified the code as suggested, without using pairs of before- and
after-change-functions.

Handling text inserted into folded/invisible region is handled by a
simple after-change function. After testing, it turned out that simple
re-hiding text based on 'invisible property of the text before/after the
inserted region works pretty well.

Modifications to BEGIN/END line of the drawers and blocks is handled via
'modification-hooks + 'insert-behind-hooks text properties (there is no
after-change-functions analogue for text properties in Emacs). The
property is applied during folding and the modification-hook function is
made aware about the drawer/block boundaries (via apply-partially
passing element containing :begin :end markers for the current
drawer/block). Passing the element boundary is important because the
'modification-hook will not directly know where it belongs to. Only the
modified region (which can be larger than the drawer) is passed to the
function. In the worst case, the region can be the whole buffer (if one
runs revert-buffer).

It turned out that adding 'modification-hook text property takes a
significant cpu time (partially, because we need to take care about
possible existing 'modification-hook value, see
org--add-to-list-text-property). For now, I decided to not clear the
modification hooks during unfolding because of poor performance.
However, this approach would lead to partial unfolding in the following
case:

:asd:
:drawer:
lksjdfksdfjl
sdfsdfsdf
:end:

If :asd: was inserted in front of folded :drawer:, changes in :drawer:
line of the new folded :asd: drawer would reveal the text between
:drawer: and :end:.

Let me know what you think on this.

> You shouldn't be bothered by the case you're describing here, for
> multiple reasons.
> 
> First, this issue already arises in the current implementation. No one
> bothered so far: this change is very unlikely to happen. If it becomes
> an issue, we could make sure that `org-reveal' handles this.
> 
> But, more importantly, we actually /want it/ as a feature. Indeed, if
> DRAWER is expanded every time ":BLAH:" is inserted above, then inserting
> a drawer manually would unfold /all/ drawers in the section. The user is
> more likely to write first ":BLAH:" (everything is unfolded) then
> ":END:" than ":END:", then ":BLAH:".

Agree. This allowed me to simplify the code significantly.

> 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.

You are right here, I missed that before-change-functions are likely to
be called on large regions. I thought that the regions are same for
before/after-

Release 9.3.7

[Bastien]

Hi all,

Org 9.3.7, a bugfix release, is out: https://orgmode.org

Note that we are entering in feature freeze to prepare for 9.4,
which I hope we can release this month.

Enjoy!

-- 
 Bastien