[PATCH] Fix indentation in test-org.el

[Allen Li]

The indentation in test-org.el is all over the place.  I've attached a
patch fixing it.

Alternatively, you can do the following to reproduce the changes:

Load org-test.el and test-org.el to pick up macros which define their own
indentation.
In test-org.el, type `C-x h TAB` to mark the entire buffer and re-indent.
From 69ddca72e4744c8f3d3a552b760108bd17c676ae Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 25 Nov 2023 03:06:06 -0800
Subject: [PATCH] testing/lisp/test-org.el: Fix indentation

The indentation in this file is all messed up.  Fix it by loading
test-org.el and org-test.el to pick up all the macros, and then C-x h
TAB to re-indent the entire file.

* testing/lisp/test-org.el (org-test-with-timezone): Fix indentation.
---
 testing/lisp/test-org.el | 584 +++
 1 file changed, 292 insertions(+), 292 deletions(-)

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 612bfa1e5..1825af21d 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -41,7 +41,7 @@
(progn
  (setenv "TZ" ,tz)
  ,@body)
- (setenv "TZ" ,tz-saved)
+ (setenv "TZ" ,tz-saved)
 
 (defmacro org-test-with-result (result  body)
   "Evaluate BODY, and return buffer content based on RESULT.
@@ -562,7 +562,7 @@ Otherwise, evaluate RESULT as an sexp and return its result."
   ;; The function ignores incomplete drawers.
   (should-not
(org-test-with-temp-text ":PROPERTIES:\n:PROP: t\n"
-(org-at-property-drawer-p)))
+ (org-at-property-drawer-p)))
   ;; tab separating the value.
   (should
(org-test-with-temp-text ":PROPERTIES:\n:PROP:	t\n:END:\n"
@@ -682,20 +682,20 @@ Otherwise, evaluate RESULT as an sexp and return its result."
 (should
  (equal "* H\n:PROPERTIES:\n:END:\n*** I\n*** END\nP"
 	(org-test-with-temp-text
-		"* H\n*** I\n*** END\nP"
+	"* H\n*** I\n*** END\nP"
 	  (let ((org-adapt-indentation nil)
 		(org-inlinetask-min-level 15))
-		(org-insert-property-drawer))
+	(org-insert-property-drawer))
 	  (buffer-string)
   ;; Correctly set drawer in an inlinetask.
   (when (featurep 'org-inlinetask)
 (should
  (equal "* H\n*** I\n:PROPERTIES:\n:END:\nP\n*** END"
 	(org-test-with-temp-text
-		"* H\n*** I\nP\n*** END"
+	"* H\n*** I\nP\n*** END"
 	  (let ((org-adapt-indentation nil)
 		(org-inlinetask-min-level 15))
-		(org-insert-property-drawer))
+	(org-insert-property-drawer))
 	  (buffer-string))
 
 
@@ -941,21 +941,21 @@ Otherwise, evaluate RESULT as an sexp and return its result."
   (should
(equal "\n- 2345678\n  9\n- 2345678\n  9"
 	  (org-test-with-temp-text "\n- 2345678 9\n- 2345678 9"
-	   (let ((fill-column 10))
-	 (transient-mark-mode 1)
-	 (push-mark (point-min) t t)
-	 (goto-char (point-max))
-	 (call-interactively #'fill-region)
-	 (buffer-string)
+	(let ((fill-column 10))
+	  (transient-mark-mode 1)
+	  (push-mark (point-min) t t)
+	  (goto-char (point-max))
+	  (call-interactively #'fill-region)
+	  (buffer-string)
   (should
(equal "\n- 1 2\n- 1 2"
 	  (org-test-with-temp-text "\n- 1\n  2\n- 1\n  2"
-	   (let ((fill-column 10))
-	 (transient-mark-mode 1)
-	 (push-mark (point-min) t t)
-	 (goto-char (point-max))
-	 (call-interactively #'fill-region)
-	 (buffer-string)  )
+	(let ((fill-column 10))
+	  (transient-mark-mode 1)
+	  (push-mark (point-min) t t)
+	  (goto-char (point-max))
+	  (call-interactively #'fill-region)
+	  (buffer-string)  )
 
 (ert-deftest test-org/auto-fill-function ()
   "Test auto-filling features."
@@ -1127,9 +1127,9 @@ Otherwise, evaluate RESULT as an sexp and return its result."
   (should
(= 1
   (org-test-with-temp-text
-	  "\\begin{equation}\n 1+1=2\n\\end{equation}"
-	(org-indent-line)
-	(org-get-indentation
+  "\\begin{equation}\n 1+1=2\n\\end{equation}"
+(org-indent-line)
+(org-get-indentation
   ;; On blank lines at the end of a list, indent like last element
   ;; within it if the line is still in the list.  If the last element
   ;; is an item, indent like its contents.  Otherwise, indent like the
@@ -1157,9 +1157,9 @@ Otherwise, evaluate RESULT

[PATCH] Raise gc-cons-threshold for org-element-cache-map

[Allen Li]

Attached patch, I think it's self-explanatory so the commit message is
reproduced here:

org-element: Raise gc-cons-threshold for org-element-cache-map

This garbage collects many times when calling
org-get-buffer-tags (such as during tag completion) in a large file
with many tags.  Raise gc-cons-threshold as this may affect other
callers in large files.

Note that org-element-parse-buffer also raises gc-cons-threshold as a
precedent.

This has no effect on most callers and increases performance for
extreme cases.
From 01e06d90f27b8204e69508351b7fca9c03e7af32 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Wed, 23 Aug 2023 00:22:06 -0700
Subject: [PATCH] org-element: Raise gc-cons-threshold for
 org-element-cache-map

This garbage collects many times when calling
org-get-buffer-tags (such as during tag completion) in a large file
with many tags.  Raise gc-cons-threshold as this may affect other
callers in large files.

Note that org-element-parse-buffer also raises gc-cons-threshold as a
precedent.

This has no effect on most callers and increases performance for
extreme cases.

* lisp/org-element.el (org-element-cache-map): Raise gc-cons-threshold.
---
 lisp/org-element.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index b2c5b0402..694a4f43f 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -7568,7 +7568,8 @@ the cache."
   (let ((mk (make-marker)))
 (set-marker mk to-pos)
 (setq to-pos mk)))
-(let (;; Bind variables used inside loop to avoid memory
+(let ((gc-cons-threshold #x4000)
+  ;; Bind variables used inside loop to avoid memory
   ;; re-allocation on every iteration.
   ;; See https://emacsconf.org/2021/talks/faster/
   tmpnext-start tmpparent tmpelement)
-- 
2.41.0

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Attached

On Sat, Jun 25, 2022 at 9:48 PM Ihor Radchenko  wrote:

> Allen Li  writes:
>
> >> Would you also be interested to write a test checking org-todo ARGS?
> >>
> >
> > Attached
>
> Thanks! However, it is unclear what this test is checking for.
>
> > +(ert-deftest test-org/org-todo-prefix ()
> > +  "Test `org-todo' prefix arg behavior."
> > +  ;; -1 prefix arg should cancel repeater and mark DONE.
> > +  (should-not
> > +   (string-prefix-p
> > +"* TODO H"
> > +(let ((org-todo-keywords '((sequence "TODO" "DONE"
> > +  (org-test-with-temp-text "* TODO H\n<2012-03-29 Thu +2y>"
> > +(org-todo -1)
> > +(buffer-string)
>
> This test does not check if the task is actually marked DONE and also
> does not check if the repeater is canceled.
>
> Best,
> Ihor
>
>
From 42156ba1e8b3c589394212ef423f99e122544c5f Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 25 Jun 2022 21:27:20 -0700
Subject: [PATCH] test-org: Add test for org-todo prefix behavior

* testing/lisp/test-org.el (test-org/org-todo-prefix): Add test.
---
 testing/lisp/test-org.el | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 121f9efd5..d686c0e3b 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -7753,6 +7753,25 @@ CLOSED: %s
   (org-add-log-note))
 (buffer-string))
 
+(ert-deftest test-org/org-todo-prefix ()
+  "Test `org-todo' prefix arg behavior."
+  ;; -1 prefix arg should cancel repeater and mark DONE.
+  (should
+   (string-match-p
+"DONE H\\(.*\n\\)*<2012-03-29 Thu \\+0y>"
+(let ((org-todo-keywords '((sequence "TODO" "DONE"
+  (org-test-with-temp-text "* TODO H\n<2012-03-29 Thu +2y>"
+	(org-todo -1)
+	(buffer-string)
+  ;; - prefix arg should cancel repeater and mark DONE.
+  (should
+   (string-match-p
+"DONE H\\(.*\n\\)*<2012-03-29 Thu \\+0y>"
+(let ((org-todo-keywords '((sequence "TODO" "DONE"
+  (org-test-with-temp-text "* TODO H\n<2012-03-29 Thu +2y>"
+	(org-todo '-)
+	(buffer-string))
+
 
 ;;; Timestamps API
 
-- 
2.36.1

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

On Fri, Jun 17, 2022 at 11:09 PM Ihor Radchenko  wrote:

> Ihor Radchenko  writes:
>
> > Allen Li  writes:
> >
> >> On Sat, Jan 1, 2022 at 9:31 AM Allen Li 
> wrote:
> >>
> >>> It seems like the right fix here is to make - behave the same as -1,
> and
> >>> raise a user error for any other negative numeric prefix, since it is
> >>> likely not doing whatever the user wanted.
> >>>
> >>
> >> Attached a small patch fixing this, which I tested manually.
>
> Applied onto main via bfd63cc4f.
>
> Would you also be interested to write a test checking org-todo ARGS?
>

Attached


>
> Best,
> Ihor
>
From 9255819ee05b9f2bdbe8de1cf0acbd6ae6553152 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 25 Jun 2022 21:27:20 -0700
Subject: [PATCH] test-org: Add test for org-todo prefix behavior

* testing/lisp/test-org.el (test-org/org-todo-prefix): Add test.
---
 testing/lisp/test-org.el | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 121f9efd5..304dddc08 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -7753,6 +7753,25 @@ CLOSED: %s
   (org-add-log-note))
 (buffer-string))
 
+(ert-deftest test-org/org-todo-prefix ()
+  "Test `org-todo' prefix arg behavior."
+  ;; -1 prefix arg should cancel repeater and mark DONE.
+  (should-not
+   (string-prefix-p
+"* TODO H"
+(let ((org-todo-keywords '((sequence "TODO" "DONE"
+  (org-test-with-temp-text "* TODO H\n<2012-03-29 Thu +2y>"
+	   (org-todo -1)
+	   (buffer-string)
+  ;; - prefix arg should cancel repeater and mark DONE.
+  (should-not
+   (string-prefix-p
+"* TODO H"
+(let ((org-todo-keywords '((sequence "TODO" "DONE"
+  (org-test-with-temp-text "* TODO H\n<2012-03-29 Thu +2y>"
+	   (org-todo '-)
+	   (buffer-string))
+
 
 ;;; Timestamps API
 
-- 
2.36.1

[BUG] C-u C-u C-u TAB regression on master

[Allen Li]

There appears to be a regression in the behavior of C-u C-u C-u TAB on
master (at aea24b3feafb9c389dc5933005928462bb20c4f8).

C-u C-u C-u TAB is supposed to show everything including drawers, but on
this test file it does not show property drawers:

Make a file containing 2000 copies of the following:

* blah
:PROPERTIES:
:ID: blah
:END:
blah

This bug does not manifest on small files, e.g. containing one copy of
the above.

This is using (setq org-fold-core-style 'text-properties), the default.
The behavior does not happen with 'overlays.

Can anyone else reproduce?

Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.17.6)
 of 2022-04-27
Package: Org mode version 9.5.3 (9.5.3-gca5c9f @ 
/home/ionasal/.emacs.d/straight/build/org/)

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Ihor Radchenko  writes:
> Unfortunately, fixing the occurrences of (defvar foo nil) is not
> completely straightforward. Some of them are real defvars.

I see, I thought you meant those defvars were also used for dynamic
scoping.

>
> If someone is willing to check all the occurrences of
> (defvar +[^ ]+ +nil) and remove nil values where we merely put a defvar
> to silence byte-compiler, please do it.

My initial request was just to fix this one instance that is actively
troubling me.  If there are any other known cases of defvar, they should
also be fixed.  If not, then let's wait until someone identifies them.

If any maintainers reading this could fix this one defvar, that'd be
great.

>
> Also, I feel that my Elisp-foo is not good enough in this specific
> scenario. I invite others to reply if they feel that changing
> (defvar foo nil) to (defvar foo) for externally defined variables is
> _not_ universally safe.
>
> Best,
> Ihor

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Ihor Radchenko  writes:

> Allen Li  writes:
>
>>> I agree. The question is whether changing to
>>> (defvar org-id-link-to-org-use-id)
>>> solves your problem.
>>
>> Thanks for your concern.  By editing ob-tangle.el, I can confirm that
>> changing this does solve my problem.
>>
>> If I must, I could provide a reproducible example, but I feel like
>> that costs unnecessary effort on the part of everyone involved if we
>> agree on the above point.
>
> Let me clarify what I am worrying about.
> We have 132 occurrences of (defvar foo nil) in the code.
> I am genuinely surprised that changing defvar fixed the problem for you
> and at the same time nobody reported similar issues with the other 131
> defvars. That's why I really want to get a reproducer and understand
> what is going on there. So far, I don't understand how defvar can break
> anything except in case of some strange compilation/mixed installation
> problems.

I see.  In my opinion those occurrences should be fixed even if no one
is reporting issues because it is bad/improper code, and it is not
especially surprising that no one has reported it yet; there is always a
first person who reports a bug, and there are always more old bugs to be
found in a big project like Emacs/Org mode.

This is annoying to reproduce because it relies on the normal Emacs
startup process, which loads packages.  Anyway, I have found a reproduction.

This is using the Emacs install on Arch Linux.

GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo 
version 1.17.4)
 of 2021-03-26

Have the packages org-9.5.2 and org-contrib-0.3 installed in
~/.emacs.d/elpa.  I have these installed from
https://elpa.gnu.org/packages/ and https://elpa.nongnu.org/nongnu/
respectively.

Start emacs by loading a tmp.el file with the contents provided below.

1. emacs -Q --load tmp.el
2. C-h v org-id-link-to-org-use-id

Note that the value is nil instead of the expected
'create-if-interactive

3. Press RET on the customize link.

Note that the Customize UI says "CHANGED outside Customize."

Expected behavior:

User sees org-id-link-to-org-use-id set to the value they saved in
Customize.

Personal aside:

It is easy to get subtle bugs in between autoloading, package activation
and Customize when some bit of code is not following all of the right
conventions.  I suspect most Emacs users are adding setqs to their init
file until things work.  Meanwhile I foolishly read and follow all of
the conventions and thus I make the above claim ("It is easy to get
subtle bugs...") from my experience running into other bugs like this one.
Hence my stance on fixing the aforementioned 132 occurrences, lest they
cause yet another subtle bug later on.

;; tmp.el starts here.

;; This is usually called by Emacs before loading init.el.
;; It is skipped when using -Q so we call it manually.
;; 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Startup-Summary.html
(package-activate-all)

;; This is added to init.el and is the standard way user
;; customizations are saved/loaded.
(custom-set-variables
 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.
 '(org-id-link-to-org-use-id 'create-if-interactive)
 '(org-babel-load-languages '((emacs-lisp . t) (python . t) (shell . t

;; tmp.el ends here.

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Ihor Radchenko  writes:

> Allen Li  writes:
>> Even if org-id-link-to-org-use-id were always set at this point, there
>> would be no reason to use
>>
>> (defvar org-id-link-to-org-use-id nil)
>>
>> instead of
>>
>> (defvar org-id-link-to-org-use-id)
>
> I agree. The question is whether changing to
> (defvar org-id-link-to-org-use-id)
> solves your problem.

Thanks for your concern.  By editing ob-tangle.el, I can confirm that
changing this does solve my problem.

If I must, I could provide a reproducible example, but I feel like
that costs unnecessary effort on the part of everyone involved if we
agree on the above point.

(Similarly, I could provide a patch, but I feel like it would be less
effort for everyone if a maintainer who agrees with the above point just
edits that one line.)

>
> Best,
> Ihor

Re: [BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

Ihor Radchenko  writes:

> Allen Li  writes:
>
>> In ob-tangle.el, the line
>>
>> (defvar org-id-link-to-org-use-id nil) ; Dynamically scoped
>>
>> appears to override the user's customization of
>> org-id-link-to-org-use-id.
>
> Have you seen this happening?

Yes, that's why I filed the bug.

> FYI, defvar does not overwrite variable value that is already set.
> Try the following:
> (setq foo 'my-value) ;; foo = 'my-value
> (defvar foo 'value) ;; foo = 'my-value !!
> foo ;; foo still = 'my-value
>
> defvar only matters if the variable is not yet defined:
> bar ;; => error void-variable
> (defvar bar 'value) ;; bar = 'value

Yes, that is so.

Even if org-id-link-to-org-use-id were always set at this point, there
would be no reason to use

(defvar org-id-link-to-org-use-id nil)

instead of

(defvar org-id-link-to-org-use-id)

>
> Best,
> Ihor

[BUG] ob-tangle overrides user customization of org-id-link-to-org-use-id [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

In ob-tangle.el, the line

(defvar org-id-link-to-org-use-id nil) ; Dynamically scoped

appears to override the user's customization of
org-id-link-to-org-use-id.

Specifically, this happens if the user has python in
org-babel-do-load-languages, which leads to the require chain:

require ob-python
require ob
require ob-tangle

I believe the line should be changed to

(defvar org-id-link-to-org-use-id) ; Dynamically scoped

which makes the variable dynamically scoped without setting its value.

I don't know if ob-tangle.el refers to
org-id-link-to-org-use-id before it has a value set.  If so, the
change I suggest would cause an error and ob-tangle.el should be fixed
to require org-id before using said variable.

Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, 
cairo version 1.17.4)
 of 2021-03-26
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ 
/home/ionasal/.emacs.d/elpa/org-9.5.2/)

Re: [BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

On Sat, Jan 1, 2022 at 9:31 AM Allen Li  wrote:

> It seems like the right fix here is to make - behave the same as -1, and
> raise a user error for any other negative numeric prefix, since it is
> likely not doing whatever the user wanted.
>

Attached a small patch fixing this, which I tested manually.

Feel free to remove the negative arg error if it's not desired (although I
don't think there is a use case for, e.g., typing M-- M-2 instead of M-1).
From 16ff89c309b8bd9aa11183cc9620c56ed96e3ff7 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 1 Jan 2022 01:38:35 -0800
Subject: [PATCH] org: Improve org-todo handling of negative prefix args

* lisp/org.el (org-todo): Handle -1 prefix args consistently and error
on other negative args.
---
 lisp/org.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index e2f315a4c..6b48f660e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9785,7 +9785,8 @@ When called through ELisp, arg is also interpreted in the following way:
 	 nil cl
 	 (when (org-invisible-p) (org-end-of-subtree nil t
 (when (equal arg '(16)) (setq arg 'nextset))
-(when (equal arg -1) (org-cancel-repeater) (setq arg nil))
+(when (equal (prefix-numeric-value arg) -1) (org-cancel-repeater) (setq arg nil))
+(when (< (prefix-numeric-value arg) -1) (user-error "Prefix argument %d not supported" arg))
 (let ((org-blocker-hook org-blocker-hook)
 	  commentp
 	  case-fold-search)
-- 
2.34.1

[BUG] org-todo (C-c C-t) bad negative prefix behavior [9.5.2 (9.5.2-gfbff08 @ /home/ionasal/.emacs.d/elpa/org-9.5.2/)]

[Allen Li]

The docstring for org-todo (C-c C-t) is unclear about the handling of -
prefix compared to -1 prefix.

Here is the relevant part of the docstring:

With ‘C-u’ prefix ARG, force logging the state change and take a
logging note.
With a ‘C-u C-u’ prefix, switch to the next set of TODO keywords (nextset).
Another way to achieve this is ‘S-C-’.
With a ‘C-u C-u C-u’ prefix, circumvent any state blocking.
With numeric prefix arg, switch to the Nth state.

With a numeric prefix arg of 0, inhibit note taking for the change.
With a numeric prefix arg of -1, cancel repeater to allow marking as DONE.

The actual behavior is that - (along with any other negative numeric
prefix excluding -1) switches to the first state and -1 cancels
the repeater.

It seems like the right fix here is to make - behave the same as -1, and
raise a user error for any other negative numeric prefix, since it is
likely not doing whatever the user wanted.

Emacs  : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, 
cairo version 1.17.4)
 of 2021-03-26
Package: Org mode version 9.5.2 (9.5.2-gfbff08 @ 
/home/ionasal/.emacs.d/elpa/org-9.5.2/)

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Allen Li]

No Wayman  writes:
>> Yes, I think using only ":" and "," is the best default option. I
>> still
>> don't think there is a need to make it customizable (I doubt anyone
>> is
>> typing tags separated with ! or @ or #), but I suppose
>> there's minimal harm from doing so.
>
> I don't see the need to prevent customization here, either.
> There may be use cases we don't anticiapte and it adds very little in
> the way of maitenance.
> Consider if the author of crm.el decided to hardcode the separator.
> Your original patch would not have been so trivial.

crm.el is a library whose purpose is to provide a customizable
completion API.  That's not comparable to Org mode's tag setting commands.

>
>> I am -0.5 on showing the delimiters since this is not conventional
>> for
>> completing-read-multiple, especially after we add support for ","
>> like
>> most other uses of completing-read-multiple.  It needlessly inflates
>> the
>> length of the prompt.
>
> I don't know what you mean by -0.5, but I wouldn't say it's needless.
> `org-todo-list' adds the following to the prompt:
>
>> "Keyword (or KWD1|KWD2|...): "
>
> We're talking a handful of characters at most. e.g.
>
>> "Tags (: , to delimit): "
>
> Actually shorter than what `org-todo-list' does now.
> I'm open to suggestions on improving that prompt format as well.

-0.5 means slightly against (+1 means agree and -1 means disagree).

> So it looks like the remaining issue is whether or not it's worth
> displaying the tag delimiters in the prompt. I'll think on it some 
> more and give it some time to see if anyone else has any arguments in
> favor or against the idea. If I don't see anything by the weekend,
> I'll amend the patch with the changes suggested above.

I don't want to bikeshed it further since it is not that important and
not worth either of our time.  I have already stated my reasons that I
would personally not add these things, but it does not bother me enough,
nor is it significant enough to spend more time on.

Whether to make the delimiters customizable: No, because I don't think
there's a need.  Maybe one Org mode user will need it and they can
define their own command.

Whether to display separators in prompt: No, because both , and : are
intuitive, and also no if delimiters are customizable since the user
knows what the delimiters are (since they set them).

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Allen Li]

No Wayman  writes:
> Allen Li  writes:
>> The question here is, which behavior do we want?  My philosphy 
>> is that
>> programs shouldn't try to silently re-interpret the user's 
>> intentions.
>> For example, if I accidentally mistyped the tag "green_blue" as
>> "green-blue", I don't want Org to "helpfully" split one tag into 
>> two
>> tags "green:blue".  I may not realize the data corruption until 
>> too
>> late.
>
> Consider the current behavior of `org-capture-fill-template':
>
> If you were to mistype your tag as "green-blue" it would be 
> captured as part of the headline string instead of a set of tags.
> Future tag completions would not include any reference to it, and 
> so you likely wouldn't notice until long after the fact 
> (especially in the case of a template with a non-nil 
> :immediate-finish).
> So the risk of data corruption exists now by allowing the function 
> to return an invalid tag string.

green-blue is recoverable, and green:blue is not.  Consider a file where
some headings are tagged :green:blue: and some are tagged :green_blue:.
If green-blue gets changed into :green:blue:, then it is no longer
possible to tell which :green:blue: headings are supposed to be
:green_blue:.  If they were left as green-blue, it is trivial to fix
them with a search-replace.  It is also easy to notice that they were
typed incorrectly because the tags would be highlighted differently (as
they are invalid).

> It defaults to what you've proposed (allowing ":" and "," to 
> delimit tags).
> It avoids introducing a new regexp variable which needs to be 
> maintained in lockstep with `org-tag-re'.
> It's customizable.
> It informs the user about the tag delimiting characters in the 
> prompt.

Yes, I think using only ":" and "," is the best default option.  I still
don't think there is a need to make it customizable (I doubt anyone is
typing tags separated with ! or @ or #), but I suppose
there's minimal harm from doing so.

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index c51744680..e51d039d5 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1740,9 +1740,12 @@ The template may still contain \"%?\" for cursor 
positioning."
(org-add-colon-after-tag-completion t)
(ins (mapconcat
  #'identity
- (let ((crm-separator "[ \t]*:[ \t]*"))
+ (let* ((separators (or 
org-tags-crm-separators '(?: ?,)))
+ (crm-separator (org-tags-crm-regexp 
separators)))
 (completing-read-multiple
-(if prompt (concat prompt ": ") "Tags: ")
+(if prompt (concat prompt ": ")
+   (format "Tags (%s to delimit): "
+   (mapconcat #'char-to-string 
separators " ")))
 org-last-tags-completion-table nil nil nil
 'org-tags-history))
  ":")))

I am -0.5 on showing the delimiters since this is not conventional for
completing-read-multiple, especially after we add support for "," like
most other uses of completing-read-multiple.  It needlessly inflates the
length of the prompt.

I suggest adding a helper function for the:

  (separators (or org-tags-crm-separators '(?: ?,)))
   (crm-separator (org-tags-crm-regexp separators))

so you can call it like:

  (crm-separator (org-tags--crm-separator-regexp))

since you repeat this verbatim below.

diff --git a/lisp/org.el b/lisp/org.el
index ce68f4692..4cd173c99 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -2980,6 +2980,11 @@ is better to limit inheritance to certain tags using the 
variables
  (const :tag "Reverse alphabetical" org-string-collate-greaterp)
  (function :tag "Custom function" nil)))
 
+(defcustom org-tags-crm-separators '(?: ?,)
+  "List of tag delimiting characters used when reading multiple tags."
+  :type 'list
+  :group 'org-tags)
+
 (defvar org-tags-history nil
   "History of minibuffer reads for tags.")
 (defvar org-last-tags-completion-table nil

You should make the :type a list of characters so the widget is more
user friendly.

@@ -12007,6 +12012,10 @@ tags."
;; it now points to BLANK-START.  Use COLUMN instead.
(if in-blank? (org-move-to-column column) (goto-char origin))
 
+(defun org-tags-crm-regexp (chars)
+  "Return `crm-separator' regexp using CHARS as separators."
+  (format &quo

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Allen Li]

No Wayman  writes:

> org-set-tags-command correctly parses the tags when using a comma
> (the default
> crm-separator) to separate them, but completion is broken unless
> ":" is used as
> the separator.
> org-capture-fill-template incorrectly parses this.
>
> Reproducible from emacs -Q:
>
> org-set-tags-command:
> 1. Insert a new Org entry in the a buffer
> 2. M-x org-set-tags-command
> 3. At the prompt enter "one,two,three"
> 4. Entry's tags are correctly set to :one:two:three:
>
> org-capture-fill-template:
> 1. evaluate (org-capture-fill-template "%^g")
> 2. At the prompt enter "one,two,three"
> 3. String returned is incorrect: ":one,two,three:"

Sorry about that (I wrote the crm patch).  I did not consider people
deliberately using invalid tag characters to separate tags.  It's an
(un?)happy coincidence that org-set-tags-commands retains this behavior,
because the fast tags selection logic gets in the way.

The inconsistency in behavior can be easily fixed by deleting the code
in org-set-tags-commands that replaces invalid tag characters with ":".

The question here is, which behavior do we want?  My philosphy is that
programs shouldn't try to silently re-interpret the user's intentions.
For example, if I accidentally mistyped the tag "green_blue" as
"green-blue", I don't want Org to "helpfully" split one tag into two
tags "green:blue".  I may not realize the data corruption until too
late.

If we want the other behavior (invalid tag characters can separate
tags), then it's also a simple matter of changing crm-separator wherever
only tags are completed to recognize all invalid tag characters.

There's also the option to only allow ":" and "," as separators.

> Note this does not change the case of org-todo-list, which binds
> crm-separator to "|". I chose not to touch that because I'm not
> fully aware
> of what the restrictions on characters for todo-keywords are, if
> any.
> org-todo-list also does the right thing by mentioning the
> separator in the prompt.

Agreed, org-todo-list is out of scope.

>
> We could also combine the approaches:
>
> - Introduce a defcustom that determines if we're going to
>   contextually rebind crm-separator
> - Use a broader regexp when contextually binding crm-separator
> - Mention the separator in the prompt when rebound

Whichever behavior we choose, I don't think it's worth making it customizable.

>
> Thoughts?
>
>
> Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+
> Version 3.24.30, cairo version 1.17.4)
>  of 2021-08-02
> Package: Org mode version 9.4.6 (9.4.6-g366444 @
> /home/n/.emacs.d/straight/build/org/)

Re: Bug: Unexpected behavior marking recurring tasks as DONE

[Allen Li]

On Fri, Jul 9, 2021 at 7:49 AM Alan Ristow  wrote:
> On 7/8/21 8:19 PM, Bhavin Gandhi wrote:
> >>> Second, if I bulk-process a habit via org-agenda-bulk-action, the task
> >>> is simply marked DONE. Bot the recurrence and the LAST_REPEAT field
> >>> are ignored, but the time stamp is only entered into the LOGBOOK once:
> >>>
> >>> ** DONE Walk
> >>> CLOSED: [2021-07-07 Wed 11:26] SCHEDULED: <2021-07-07 Wed .+1d>
> >>> :PROPERTIES:
> >>> :STYLE:  habit
> >>> :LAST_REPEAT: [2021-07-06 Tue 15:33]
> >>> :END:
> >>> :LOGBOOK:
> >>> - State "DONE"   from "TODO" [2021-07-07 Wed 11:26]
> >>> - State "DONE"   from "TODO" [2021-07-06 Tue 15:33]
> >>> :END:
> > I was not able to reproduce this correctly, I will try to reproduce it
> > again later.
>
> I had a difficult time reproducing this one reliably. If I remember
> correctly, I could only reproduce it when I set a key binding to
> org-store-link. It is a binding I never use, I only set it because it
> was in seemingly every org config on the planet when I first started
> with orgmode, and I certainly don't explicitly invoke it when processing
> in bulk.

I have also experienced repeating tasks getting marked as DONE
(not because I explicitly stopped the repetition).  I haven't able to
reproduce it reliably either, as it's seemingly random.

Bug: [PATCH] Use crm for tag completion [9.4.6 (9.4.6-gab9f2a @ /home/ionasal/.emacs.d/elpa/org-9.4.6/)]

[Allen Li]

Org mode's tag completion commands all use a custom completion function,
which makes it difficult for alternative completion functions to support
well.

Emacs already has a function for reading multiple things,
completing-read-multiple, which can be used for the tag completion use
case.

I have attached a patch for this change, which I have tested manually a
few times and also fixed the existing tests.  I have tested this with
vertico, which claims to strictly follow Emacs's completion API.

>From 933dc914694c14889af86c06ba0a8bbd88a316cf Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Thu, 8 Jul 2021 21:35:34 -0700
Subject: [PATCH] org: Use crm for completing tags

Change various places which use `completing-read' to read tags using a
custom completion function to instead use `completing-read-multiple'
with a completion table instead.

This makes tab completion play better with alternative completion
frameworks such as vertico, selectrum, etc.

`org-change-tag-in-region' only reads a single tag, so it is changed
to use a completion table with `completing-read'.  This also makes it
play better with alternative completion frameworks.

Note that there is still one use for `org-tags-completion-function',
which is for completing tag matches.  Completing tag matches is
different from completing lists of tags since the separators (+, -,
etc) have semantic meaning.  This commit does not address that use
case.

* lisp/org-capture.el (org-capture-fill-template): Changed to use
completing-read-multiple.
* lisp/org.el (org-set-tags-command): Changed to use
completing-read-multiple.
(org-change-tag-in-region): Changed to use a simple completion table.
* testing/lisp/test-org.el (test-org/set-tags-command): Fixed tests.
* etc/ORG-NEWS (Tag completion now uses =completing-read-multiple=):
Added news.
---
 etc/ORG-NEWS |  6 +
 lisp/org-capture.el  | 12 +-
 lisp/org.el  | 18 +--
 testing/lisp/test-org.el | 50 
 4 files changed, 43 insertions(+), 43 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 3f3971961..719ac3547 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -409,6 +409,12 @@ The function does not allow for a third optional parameter anymore.
 If a babel src block produces a raw LaTeX environment, it will now be
 recognised as a result, and so replaced when re-evaluated.
 
+*** Tag completion now uses =completing-read-multiple=
+
+Tag completion now uses =completing-read-multiple= with a simple
+completion table, which should allow better interoperability with
+custom completion functions.
+
 * Version 9.4
 ** Incompatible changes
 *** Possibly broken internal file links: please check and fix
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 5ecec6309..c51744680 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -69,6 +69,7 @@
 (declare-function org-table-goto-line "org-table" (N))
 
 (defvar dired-buffers)
+(defvar crm-separator)
 (defvar org-end-time-was-given)
 (defvar org-keyword-properties)
 (defvar org-remember-default-headline)
@@ -1739,12 +1740,11 @@ The template may still contain \"%?\" for cursor positioning."
 			(org-add-colon-after-tag-completion t)
 			(ins (mapconcat
   #'identity
-  (org-split-string
-   (completing-read
-(if prompt (concat prompt ": ") "Tags: ")
-'org-tags-completion-function nil nil nil
-'org-tags-history)
-   "[^[:alnum:]_@#%]+")
+  (let ((crm-separator "[ \t]*:[ \t]*"))
+(completing-read-multiple
+ (if prompt (concat prompt ": ") "Tags: ")
+ org-last-tags-completion-table nil nil nil
+ 'org-tags-history))
   ":")))
 		   (when (org-string-nw-p ins)
 			 (unless (eq (char-before) ?:) (insert ":"))
diff --git a/lisp/org.el b/lisp/org.el
index 4fd8b6fa6..ed3ee3a1c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -201,6 +201,8 @@ Stars are put in group 1 and the trimmed body in group 2.")
 ;; load languages based on value of `org-babel-load-languages'
 (defvar org-babel-load-languages)
 
+(defvar crm-separator)  ; dynamically scoped param
+
 ;;;###autoload
 (defun org-babel-do-load-languages (sym value)
   "Load the languages defined in `org-babel-load-languages'."
@@ -12054,12 +12056,14 @@ in Lisp code use `org-set-tags' instead."
 		  inherited-tags
 		  table
 		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
-		   (let ((org-add-colon-after-tag-completion (< 1 (length table
-		 (org-trim (completing-read
-"Tags: "
-#'org-tags-completion-function
-nil nil (org-make-tag-string current-tags)
-'org-tags-history)))
+		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
+ (crm-separator "[ \t]*:[ \t]*"))

Adding a goto-heading protocol to org-protocol

[Allen Li]

I have a feature request that I'm wondering whether it would be suitable.

The idea is to add a new protocol that looks like
"org-protocol://goto-heading?id=UUID-HERE" that jumps to the specified Org
heading in Emacs.  The implementation is really simple:

;;;###autoload
(defun goto-heading (arg)
  "Org protocol handler for navigating to Org headings.
ARG is a property list."
  (org-id-goto (plist-get arg :id))
  (raise-frame))

(then add the appropriate item to org-protocol-protocol-alist-default)

The use case for this is to be able to link to Org headings from external
programs, e.g., Google Docs.

Re: Starting from 9.5, Org contrib will be distributed as a separate NonGNU ELPA package

[Allen Li]

Bastien  writes:

> Hi all,
>
> starting from Org 9.5, org-contrib will be distributed as a NonGNU
> ELPA package.  You will find it here: https://elpa.nongnu.org/nongnu/
>
> See for https://orgmode.org/list/87wnzfy60h@bzg.fr/ for context.
>
> Thanks,

Will there be an overlapping period (and if not, can we add such a
period)?  For example, have one release where org-contrib is still
shipped, and the NonGNU repos are available.  That gives users such as
myself a period to switch over without things breaking immediately.

If I understand correctly, the current plan is that users using
org-contrib will have their configs break immediately when they upgrade
to 9.5, forcing them to do both the 9.5 upgrade and switchover to NonGNU
simultaneously.  It's easier if we can first safely upgrade to 9.5, then
switch to NonGNU repos, and in the next release org-contrib can be removed.

Re: [PATCH] Query when exiting with running clock

[Allen Li]

On Wed, Feb 3, 2021 at 5:45 AM Kyle Meyer  wrote:
>
> Allen Li writes:
>
> > This is a patch adding a query function when exiting Emacs, warning the
> > user if there is a running clock.  This is useful for preventing the
> > user from accidentally leaving dangling clocks.  I have had success
> > using a modified personal version of this code.
>
> Thanks.  I'd find this useful as well.

Thanks for your feedback.  I have addressed your comments.  Please see
the new patches.
From e2fa281ca3d5c58fd759011c5f93790f49cb669d Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 12 Jan 2021 00:33:32 -0800
Subject: [PATCH 2/2] org-clock: Query when exiting with running clock

It's annoying to accidentally quit Emacs with a running clock, then
resolve the clock the next time when Emacs is started.

* lisp/org-clock.el (org-clock-kill-emacs-query): New function.
(org-clock-ask-before-exiting): New user option.
---
 lisp/org-clock.el | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 2a6a9af47..52b486cd8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -485,6 +485,16 @@ is added to the user configuration."
 	  (integer :tag "Clock out after Emacs is idle for X seconds")
 	  (const :tag "Never auto clock out" nil)))
 
+(defcustom org-clock-ask-before-exiting t
+  "If non-nil, ask if the user wants to clock out before exiting Emacs.
+  This variable only has effect if set with \\[customize]."
+  :set (lambda (symbol value)
+ (if value
+ (add-hook 'kill-emacs-query-functions #'org-clock-kill-emacs-query)
+   (remove-hook 'kill-emacs-query-functions #'org-clock-kill-emacs-query))
+ (set symbol value))
+  :type 'boolean)
+
 (defvar org-clock-in-prepare-hook nil
   "Hook run when preparing the clock.
 This hook is run before anything happens to the task that
@@ -3096,6 +3106,17 @@ The details of what will be saved are regulated by the variable
 	   (when (org-invisible-p) (org-show-context))
 	(_ nil)
 
+(defun org-clock-kill-emacs-query ()
+  "Query user when killing Emacs.
+This function is added to `kill-emacs-query-functions'."
+  (let ((buf (org-clock-buffer)))
+(when (and buf (yes-or-no-p "Clock out and save? "))
+  (with-current-buffer buf
+(org-clock-out)
+(save-buffer
+  ;; Unconditionally return t for `kill-emacs-query-functions'.
+  t)
+
 ;; Suggested bindings
 (org-defkey org-mode-map "\C-c\C-x\C-e" 'org-clock-modify-effort-estimate)
 
-- 
2.30.1

From 429dd06ac281a5706c8ce2f3e35dab4aab6b5bfc Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 12 Jan 2021 00:26:47 -0800
Subject: [PATCH 1/2] org-clock: Replace org-clocking-buffer with
 org-clock-is-active

org-clocking-buffer and org-clock-is-active have the same definition.
org-clocking-buffer is defined in org-clock.el while
org-clock-is-active is defined in org.el.  org-clock.el requires
org.el.

org-clocking-buffer is kept as an alias to preserve backward
compatibility with any user code.

* lisp/org-clock.el (org-clocking-buffer): Moved to org.el.
* lisp/org.el (org-clocking-buffer): Moved function.
(org-clock-is-active): Made into an alias.
---
 lisp/org-clock.el | 4 
 lisp/org.el   | 6 +++---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index c94f60781..2a6a9af47 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -607,10 +607,6 @@ cannot be translated."
 	  ((stringp drawer) drawer)
 	  (t nil
 
-(defun org-clocking-buffer ()
-  "Return the clocking buffer if we are currently clocking a task or nil."
-  (marker-buffer org-clock-marker))
-
 (defun org-clocking-p ()
   "Return t when clocking a task."
   (not (equal (org-clocking-buffer) nil)))
diff --git a/lisp/org.el b/lisp/org.el
index fd6226702..e35c19a9e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -144,7 +144,6 @@ Stars are put in group 1 and the trimmed body in group 2.")
 (declare-function org-clock-timestamps-down "org-clock" ( n))
 (declare-function org-clock-timestamps-up "org-clock" ( n))
 (declare-function org-clock-update-time-maybe "org-clock" ())
-(declare-function org-clocking-buffer "org-clock" ())
 (declare-function org-clocktable-shift "org-clock" (dir n))
 (declare-function org-columns-quit "org-colview" ())
 (declare-function org-columns-insert-dblock "org-colview" ())
@@ -3828,10 +3827,11 @@ This is needed for font-lock setup.")
   "Marker recording the last clock-in, but the headline position.")
 (defvar org-clock-heading ""
   "The heading of the current clock entry.")
-(defun org-clock-is-active ()
+(defun org-clocking-buffer ()
   "Return the buffer where the clock is currently running.
 Return nil if no clock

[PATCH] Query when exiting with running clock

[Allen Li]

This is a patch adding a query function when exiting Emacs, warning the
user if there is a running clock.  This is useful for preventing the
user from accidentally leaving dangling clocks.  I have had success
using a modified personal version of this code.

My personal version instead prompts the user to clock out and save the
buffer.  I didn't use it for the patch because it seems a little hacky
to me; e.g., kill-emacs-query-functions doesn't mention whether
functions can have side effects, and the UI is inconsistent with
save-buffers-kill-emacs.  The code for my personal version:

(add-to-list 'kill-emacs-query-functions
   (lambda ()
 (if (not (org-clocking-p))
 t
   (if (y-or-n-p "Clock out and save?")
   (with-current-buffer (marker-buffer org-clock-marker)
 (org-clock-out)
 (save-buffer)
 t)
 (message "Aborting")
 nil

If there is great demand for this version, I might provide another patch.

I have also attached another patch which deduplicates two identical
functions that I noticed when preparing the first patch.

>From f6145afd7d457cec533c44c8a3297d28f11d7255 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 12 Jan 2021 00:26:47 -0800
Subject: [PATCH 1/2] org-clock: Replace org-clocking-buffer with
 org-clock-is-active

org-clocking-buffer and org-clock-is-active have the same definition.
org-clocking-buffer is defined in org-clock.el while
org-clock-is-active is defined in org.el.  org-clock.el requires
org.el.

org-clocking-buffer is kept as an alias to preserve backward
compatibility with any user code.

* lisp/org-clock.el (org-clocking-buffer): Changed to alias.
(org-clocking-p): Changed reference to org-clocking-buffer.
(org-clock-out): Changed reference to org-clocking-buffer.
(org-clock-cancel): Changed reference to org-clocking-buffer.
(org-clock-sum): Changed reference to org-clocking-buffer.
(org-clock-out-if-current): Changed reference to org-clocking-buffer.
(org-clock-save): Changed reference to org-clocking-buffer.
---
 lisp/org-clock.el | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 892ae1810..37459580b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -503,13 +503,11 @@ of a different task.")
   (mapc (lambda (m) (org-check-and-save-marker m beg end))
 	org-clock-history))
 
-(defun org-clocking-buffer ()
-  "Return the clocking buffer if we are currently clocking a task or nil."
-  (marker-buffer org-clock-marker))
+(defalias 'org-clocking-buffer #'org-clock-is-active)
 
 (defun org-clocking-p ()
   "Return t when clocking a task."
-  (not (equal (org-clocking-buffer) nil)))
+  (not (equal (org-clock-is-active) nil)))
 
 (defvar org-clock-before-select-task-hook nil
   "Hook called in task selection just before prompting the user.")
@@ -1501,7 +1499,7 @@ to, overriding the existing value of `org-clock-out-switch-to-state'."
 	  ts te s h m remove)
   (setq org-clock-out-time now)
   (save-excursion ; Do not replace this with `with-current-buffer'.
-	(org-no-warnings (set-buffer (org-clocking-buffer)))
+	(org-no-warnings (set-buffer (org-clock-is-active)))
 	(save-restriction
 	  (widen)
 	  (goto-char org-clock-marker)
@@ -1652,7 +1650,7 @@ Optional argument N tells to change by that many units."
 (force-mode-line-update)
 (error "No active clock"))
   (save-excursion ; Do not replace this with `with-current-buffer'.
-(org-no-warnings (set-buffer (org-clocking-buffer)))
+(org-no-warnings (set-buffer (org-clock-is-active)))
 (goto-char org-clock-marker)
 (if (org-looking-back (concat "^[ \t]*" org-clock-string ".*"))
 	(progn (delete-region (1- (point-at-bol)) (point-at-eol))
@@ -1763,7 +1761,7 @@ PROPNAME lets you set a custom text property instead of :org-clock-minutes."
 	  (t ;; A headline
 	   ;; Add the currently clocking item time to the total
 	   (when (and org-clock-report-include-clocking-task
-		  (equal (org-clocking-buffer) (current-buffer))
+		  (equal (org-clock-is-active) (current-buffer))
 		  (equal (marker-position org-clock-hd-marker) (point))
 		  tstart
 		  tend
@@ -1897,8 +1895,8 @@ and is only done if the variable `org-clock-out-when-done' is not nil."
 		  (member org-state org-done-keywords))
 		 (and (listp org-clock-out-when-done)
 		  (member org-state org-clock-out-when-done)))
-	 (equal (or (buffer-base-buffer (org-clocking-buffer))
-			(org-clocking-buffer))
+	 (equal (or (buffer-base-buffer (org-clock-is-active))
+			(org-clock-is-active))
 		(or (buffer-base-buffer (current-buffer))
 			(current-buffer)))
 	 (< (point) org-clock-marker)
@@ -2816,7 +2814,7 @@ The det

Bug: 9.4 Regression in handling of empty #+TAGS: [9.4 (9.4-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Allen Li]

Previously, placing an empty #+TAGS: in a file would override
org-file-tags for the file.  In 9.4, an empty #+TAGS: is ignored and
org-file-tags is used.

The relevant code in org.el:

  (setq org-current-tag-alist
(org--tag-add-to-alist
 org-tag-persistent-alist
 (let ((tags (mapconcat #'identity
(cdr (assoc "TAGS" alist))
"\n")))
   (if (org-string-nw-p tags) (org-tag-string-to-alist tags)
 org-tag-alist

This regression is undesirable because I have a set of common
org-file-tags for most files, but one particular file where
automatically detecting the existing tags in the file works better (the
default behavior when org-current-tag-alist is empty).

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22, 
cairo version 1.17.3)
 of 2020-08-28
Package: Org mode version 9.4 (9.4-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20200914/)

Re: [feature request] A new cookie type [!] showing the last note taken

[Allen Li]

On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko  wrote:

>
> Over the years of using Org I often have a need to add a short note
> about how to proceed with some task:
>
> * REVIEW check again, subscribe | sindresorhus/awesome:  Awesome
> lists about all kinds of interesting topics :BOOKMARK:
> :PROPERTIES:
> :CREATED: [2020-03-15 Sun 18:59]
> :Source: https://github.com/sindresorhus/awesome
> :END:
> :LOGBOOK:
> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] =>  1:28
> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] =>  0:15
> - Refiled on [2020-03-16 Mon 23:59]
> :END:
>
> In the above example, the short note is "check again, subscribe".
> The note is not fixed, but changes as I progress with completing the
> task.
>

Everyone has their own workflows, but I think the way you are approaching
this problem is "wrong".  Under the GTD methodology, there is the concept
of a project (some higher goal to be achieved) and next actions (the
concrete tasks to do next to achieve the project).  You would only track
the next action in your regular toto list. In Org mode, this would look
like:

* PROJECT make babel support org file links in header args (:file or :dir)
** TODO Finish the text prop org-mode

My anecdotal impression is that many people using Org do this (see
https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
"last note taken embedded in headline" feature.  As a practical matter, I
would find it inconvenient to have both the "last note take"/"next action"
and the overall project headline appear in the agenta view because it makes
the text too wide.  If I need to associate the next action with the overall
project, I take advantage of the CATEGORY property:

* PROJECT make babel support org file links in header args (:file or :dir)
:PROPERTIES:
:CATEGORY: BabelLinks
:END:
** TODO Finish the text prop org-mode

Which would show in the agenda as:

BabelLinks: TODO Finish the text prop org-mode

I have only been partially paying attention to this discussion thread, but
this sounds like both a feature with limited appeal and significant
complexity to implement, so I would suggest implementing it yourself for
your own use case, and then bringing it to the mailing list to share.  Once
you have a dozen people using it, it will likely have developed into a
mature enough form to include in Org mode.

Just my 2 cents.


> This is even more useful for delegated or HOLD tasks where I often need
> to add a short note why the task is delegated or put on hold:
>
> ** HOLD Finish the text prop org-mode | make babel support org file links
> in header args (:file or :dir)
> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
> CuNbARBshearstrength]] :HOLD:
> :PROPERTIES:
> :CREATED: [2020-07-20 Mon 16:53]
> :SHOWFROMDATE: 2020-08-15
> :END:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> Seeing this note directly in the headline without a need to dig into the
> task body / LOGBOOK drawer is really handy.
>
> In this last example, I had to duplicate the note taken using built-in
> note mechanism into headline, which was inconvenient. It would be handy
> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
> the headline to show the last note taken for this task. Then, I could
> easily see the reason why the task is blocked or what I am supposed to
> do with the task right in agenda view or in the folded headline.
> Something like the following
>
> ** HOLD [!] make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> The cookie would be replaced by the last note text, according to
> user-defined format (say, "[%s] |"):
>
> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
> :LOGBOOK:
> - State "HOLD"   from "NEXT"  [2020-08-10 Mon 15:16] \\
>   Finish the text prop org-mode
> - Refiled on [2020-07-20 Mon 17:15]
> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] =>  0:01
> :END:
>
> What do you think?
>
> Best,
> Ihor
>
>

Re: Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

[Allen Li]

On Fri, Aug 21, 2020 at 8:39 AM Allen Li  wrote:
>
> Kyle Meyer  writes:
>
> > That looks good as far as fixing the misbehavior you report.  I wonder
> > though whether there's a deeper org-get-tags issue here worth
> > considering.  Its documentation says
> >
> > ... the returned list of tags contains tags in this order: file
> > tags, tags inherited from parent headlines, local tags.
> >
> > But it's not specified what happens when a tag is both local and
> > inherited.  The current implementation drops the local tag variant
> > through its delete-dups call:
> >
> > (delete-dups
> >  (append (org-remove-uninherited-tags itags) ltags))
> >
> > I would have expected the local tag to get priority here.  If that were
> > the case (e.g., something like below), that would also solve the issue
> > you describe.
> >
> > Thoughts?
>
> That sounds reasonable, let me prepare a new patch.

Attached new patch
From 24c1c9c423cd92d307033d56ca07692a23eab089 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 18 Aug 2020 15:34:38 -0700
Subject: [PATCH] org.el: Don't exclude local tags that are also inherited

This fixes a bug in set-tags-command excluding a tag that is both set
locally and inherited from the initial minibuffer input by modifying
org-get-tags to prefer keeping the locally set tag over the inherited
tag, as this behavior is more intuitive for org-get-tags anyway.

* lisp/org.el (org-get-tags): Keep local tags over inherited
* testing/lisp/test-org.el (test-org/set-tags-command): Add test
---
 lisp/org.el  | 14 --
 testing/lisp/test-org.el | 11 +++
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index fb95590fc..71dbc611e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12290,7 +12290,8 @@ According to `org-use-tag-inheritance', tags may be inherited
 from parent headlines, and from the whole document, through
 `org-file-tags'.  In this case, the returned list of tags
 contains tags in this order: file tags, tags inherited from
-parent headlines, local tags.
+parent headlines, local tags.  If a tag appears multiple times,
+only the most local tag is returned.
 
 However, when optional argument LOCAL is non-nil, only return
 tags specified at the headline.
@@ -12306,12 +12307,13 @@ Inherited tags have the `inherited' text property."
 (let ((ltags (org--get-local-tags)) itags)
   (if (or local (not org-use-tag-inheritance)) ltags
 (while (org-up-heading-safe)
-  (setq itags (append (mapcar #'org-add-prop-inherited
-  (org--get-local-tags))
-  itags)))
+  (setq itags (nconc (mapcar #'org-add-prop-inherited
+	 (org--get-local-tags))
+ itags)))
 (setq itags (append org-file-tags itags))
-(delete-dups
- (append (org-remove-uninherited-tags itags) ltags
+(nreverse
+	 (delete-dups
+	  (nreverse (nconc (org-remove-uninherited-tags itags) ltags))
 
 (defun org-get-buffer-tags ()
   "Get a table of all tags used in the buffer, for completion."
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 4f8c74539..6144a7af1 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -6953,6 +6953,17 @@ Paragraph"
 	  (let ((org-use-fast-tag-selection nil)
 		(org-tags-column 1))
 		(org-set-tags-command)))
+	(buffer-substring (point) (line-end-position)
+  ;; Handle tags both set locally and inherited.
+  (should
+   (equal "b :foo:"
+	  (org-test-with-temp-text "* a :foo:\n** b :foo:"
+	(cl-letf (((symbol-function 'completing-read)
+		   (lambda (prompt coll  pred req initial  args)
+			 initial)))
+	  (let ((org-use-fast-tag-selection nil)
+		(org-tags-column 1))
+		(org-set-tags-command)))
 	(buffer-substring (point) (line-end-position))
 
 (ert-deftest test-org/toggle-tag ()
-- 
2.28.0

Re: Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

[Allen Li]

Kyle Meyer  writes:

> That looks good as far as fixing the misbehavior you report.  I wonder
> though whether there's a deeper org-get-tags issue here worth
> considering.  Its documentation says
>
> ... the returned list of tags contains tags in this order: file
> tags, tags inherited from parent headlines, local tags.
>
> But it's not specified what happens when a tag is both local and
> inherited.  The current implementation drops the local tag variant
> through its delete-dups call:
>
> (delete-dups
>  (append (org-remove-uninherited-tags itags) ltags))
>
> I would have expected the local tag to get priority here.  If that were
> the case (e.g., something like below), that would also solve the issue
> you describe.
>
> Thoughts?

That sounds reasonable, let me prepare a new patch.

>
> -- >8 --
> diff --git a/lisp/org.el b/lisp/org.el
> index fb95590fc..3dac42b7b 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -12310,8 +12310,10 @@ (defun org-get-tags ( pos local)
>(org--get-local-tags))
>itags)))
>  (setq itags (append org-file-tags itags))
> -(delete-dups
> - (append (org-remove-uninherited-tags itags) ltags
> +(nreverse
> + (delete-dups
> +  (nreverse (nconc (org-remove-uninherited-tags itags)
> +   ltags))
>  
>  (defun org-get-buffer-tags ()
>"Get a table of all tags used in the buffer, for completion."

Bug: org-set-tags-command deletes inherited tags [9.3.7 (9.3.7-18-g093b47-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)]

[Allen Li]

Example Org file:

* Parent :foo:bar:baz:
** Child :foo:bar:spam:

Invoking org-set-tags-command with point on Child prepopulates the
minibuffer prompt with only the tags :spam:

This is because org-get-tags doesn't distinguish between inherited only
tags and inherited tags which are also explicitly set on a heading, so
org-set-tags-command treats :foo:bar: as inherited only rather than also
set locally on the heading.

This is undesirable because having tags set directly on a heading has
different semantics even if they are also inherited (e.g., the TAGS
special property, or when headings will be refiled to a different
location later).

Attached patch.

>From 934d65537e46c68c10edbfa2d7140cebfe89d271 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 18 Aug 2020 15:34:38 -0700
Subject: [PATCH] org.el: Don't exclude local tags that are also inherited

* lisp/org.el (org-set-tags-command): Don't exclude local tags even if inherited.
---
 lisp/org.el | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index fb95590fc..49d7d24f2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11880,9 +11880,7 @@ in Lisp code use `org-set-tags' instead."
   (org-global-tags-completion-table
    (org-agenda-files)))
 			 (or org-current-tag-alist (org-get-buffer-tags)
-	   (current-tags
-		(cl-remove-if (lambda (tag) (get-text-property 0 'inherited tag))
-			  all-tags))
+	   (current-tags (org-get-tags nil t))
 	   (inherited-tags
 		(cl-remove-if-not (lambda (tag) (get-text-property 0 'inherited tag))
   all-tags))
-- 
2.28.0


Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.22)
 of 2020-08-11
Package: Org mode version 9.3.7 (9.3.7-18-g093b47-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20200810/)

Re: Delete duplicate subtrees?

[Allen Li]

On Wed, Aug 5, 2020 at 6:16 PM David Rogers  wrote:
>
> Hello
>
> I've copied text from several different sources into an org
> buffer, and now I find I have a large number of subtrees that are
> exactly the same. All headlines are at the top level, so there are
> no duplicates at different levels from each other - but there
> *are* some where the headline matches but the contents don't
> match. Is there an efficient way to delete all-but-one of the
> exactly duplicate subtrees, but avoid deleting any whose contents
> are different? (When the large number of exact duplicates are
> gone, it will be easy for me to resolve the partial matches one by
> one.)

Maybe this will be useful to you.

https://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00626.html
https://lists.gnu.org/archive/html/emacs-orgmode/2018-01/msg0.html

You will have to modify the code since IIRC the linked code only
matches by heading and not body.

>
> --
> Thanks
> David
>

Bug: New agenda filtering multiple tags broken [9.3.6 (9.3.6-29-g6a3dff-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)]

[Allen Li]

The new agenda filtering doesn't seem to work properly with multiple
tags.

Opening the file below, e.g., at /tmp/tmp.org

* TODO foo  :foo:
* TODO bar  :foo:bar:
* TODO baz

Open an agenda buffer M-x org-agenda RET < t

Filter / +foo-bar RET

I expect to see only

TODO foo

But instead I see all of the items, as if the filter was ignored.

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.3.6 (9.3.6-29-g6a3dff-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20200406/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-after-todo-state-change-hook '(org-checklist)
 org-columns-default-format "%60ITEM %TODO %Effort{:} %CLOCKSUM"
 org-agenda-skip-scheduled-if-deadline-is-shown t
 org-link-shell-confirm-function 'yes-or-no-p
 org-agenda-sticky t
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 2))
 org-speed-commands-user '(("a" progn (forward-char 1) (call-interactively 
'org-insert-heading-respect-content) (org-demote)) ("N" . 
org-toggle-narrow-to-subtree))
 org-enforce-todo-dependencies t
 org-special-ctrl-k t
 org-checkbox-hierarchical-statistics nil
 org-export-use-babel nil
 org-edit-src-content-indentation 0
 org-special-ctrl-a/e t
 org-columns-modify-value-for-display-function 
'orgx-columns-remove-stars-for-display
 org-log-redeadline 'note
 org-modules '(org-bibtex org-docview org-eww org-gnus org-habit org-id 
org-info org-irc org-mhe org-protocol org-rmail org-w3m org-checklist 
org-depend)
 org-blocker-hook '(org-depend-block-todo 
org-block-todo-from-children-or-siblings-or-parent)
 org-id-link-to-org-use-id 'create-if-interactive
 org-clock-persist 'history
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-clock-string-limit 25
 org-clock-history-length 25
 org-agenda-persistent-filter t
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-adapt-indentation nil
 org-log-reschedule 'time
 org-agenda-text-search-extra-files '(agenda-archives)
 org-babel-pre-tangle-hook '(save-buffer)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
 org-agenda-search-view-always-boolean t
 org-babel-load-languages '((dot . t) (emacs-lisp . t) (ledger . t) (python . 
t) (shell . t) (ditaa . t))
 org-log-done 'time
 org-agenda-skip-deadline-prewarning-if-scheduled 'pre-scheduled
 org-export-backends '(ascii html md texinfo)
 org-checklist-export-function 'org-export-as-ascii
 org-ellipsis "..."
 org-attach-store-link-p 'attached
 org-agenda-span 'day
 org-trigger-hook '(org-depend-trigger-todo)
 org-latex-packages-alist '(("" "siunitx" t))
 org-clock-into-drawer "CLOCK"
 org-clock-out-remove-zero-time-clocks t
 org-confirm-babel-evaluate nil
 org-use-sub-superscripts '{}
 org-use-speed-commands '(lambda nil (and (looking-at org-outline-regexp) 
(looking-back "^**")))
 org-agenda-todo-ignore-scheduled 'future
 org-ctrl-k-protect-subtree 'error
 org-agenda-skip-unavailable-files t
 )

Bug: C-c C-k show branches also expands archived headings [9.3.1 (9.3.1-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191226/)]

[Allen Li]

The command org-kill-note-or-show-branches bound to C-c C-k when used to
show branches also expands headings tagged with :ARCHIVE:.  This is
contrary to expectations, as the manual states:

‘C-c C-k’ (‘outline-show-branches’)
 Expose all the headings of the subtree, CONTENTS view for just one
 subtree.

CONTENTS view when using TAB cycling does not expand archived headings.

Can be reproduced with a .org file containing:

* Foo
** Bar :ARCHIVE:
*** Baz

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.3.1 (9.3.1-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20191226/)

Re: Properties Drawer versus tags

[Allen Li]

On Fri, Dec 20, 2019 at 3:25 PM Lawrence Bottorff  wrote:
>
> Very simple, largely philosophical question: When/why use a properties drawer 
> below a heading versus just using tags on the heading? What are the 
> advantages, disadvantages of both?

I believe tag filtering has better performance than property
filtering.  Also, I think that tags were initially designed/intended
primarily for filtering in agenda views (more wizened users can
correct me on both points).

Tags also have better visibility, as they are visible by default on
each heading line in the buffer and in the agenda.

>
> LB

Re: Can Org warn me if I create a time conflict?

[Allen Li]

On Wed, Dec 18, 2019 at 7:06 AM David Rogers
 wrote:
>
> It's currently possible for me to create two meeting times, one from 
> 8:00-10:00 tomorrow and the other from 9:00-11:00 tomorrow.
>
> When both are mentioned in the same sentence, as above, it's easy to 
> recognize that the two meetings are probably incompatible. But org-mode 
> allows agenda items to be created at different times and in different files; 
> it's possible to create Meeting #1 far in advance, have enough time to forget 
> that Meeting #1 exists, and then create Meeting #2 covering the same period 
> of time. (Compare this with the wall calendar made of paper, where if I try 
> to add Meeting #2 I'll be forced to write it in the same physical space, and 
> therefore automatically be alerted before making the error.)
>
> Is there any method to get org-mode to alert me (by an error message, or a 
> red mark in the agenda, or whatever) that I've created a conflict - 
> specifically, a method that doesn't involve me having to remember to perform 
> any type of conflict-checking myself? If I could remember to do things like 
> conflict checks, I wouldn't really need org-agenda anyway. :-)
>
> I realize that it's likely some situations *do* require timed events to 
> happen concurrently - but I don't believe that they're the usual case for an 
> individual. Having an "ignore conflict" or "accept anyway" type of option 
> would make sense to me for such situations.

Does org-clock-consistency-checks support your needs?
https://orgmode.org/manual/Agenda-commands.html

>
> --
> Thanks
> David
>

Re: Bug: org-use-fast-todo-selection prefix option removed [9.3 (9.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Allen Li]

On Thu, Dec 12, 2019 at 10:48 AM Kyle Meyer  wrote:
>
> Allen Li  writes:
>
> > The option to set org-use-fast-todo-selection to 'prefix was removed
> > without my noticing.  This breaks my workflow since I like the default
> > cycling behavior and only occasionally use fast todo selection to
> > switch between todo state sets.
> >
> > It was removed in commit f1c030bed54737319aeb1d592e3340d6a48cea3a
>
> Carsten proposed that change here:
>
>   https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00138.html
>
> A couple of people chimed in to say they were in favor and nobody raised
> an objection.  I personally prefer the new behavior as well.
>
> While I think we should reassess that change if it turns out that it
> breaks many people's workflow, for now I'd recommend that you advise
> org-todo.

My problem with this is that there is a hard feature regression
here in that the ONLY way to jump to a particular TODO state is
by enabling fast todo selection, which requires one to ALWAYS use
fast todo selection.  There is no way to both not use fast todo
selection and also jump to a particular TODO state.

For example, the old behavior allowed one to use completion to
select a TODO state to jump to with C-u C-c C-t, which does not
require enabling fast todo selection.

This makes using ! or @ with TODO keywords basically unusable
without fast todo selection.

Bug: org-use-fast-todo-selection prefix option removed [9.3 (9.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Allen Li]

The option to set org-use-fast-todo-selection to 'prefix was removed
without my noticing.  This breaks my workflow since I like the default
cycling behavior and only occasionally use fast todo selection to
switch between todo state sets.

It was removed in commit f1c030bed54737319aeb1d592e3340d6a48cea3a

Bug: org-agenda-skip-unavailable-files removes files instead of skipping [9.2.6 (9.2.6-5-g9c611f-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20191111/)]

[Allen Li]

The docstring for org-agenda-skip-unavailable-files says:

Non-nil means to just skip non-reachable files in ‘org-agenda-files’.
A nil value means to remove them, after a query, from the list.

However, doing a grep over the org mode code, the only place where this
variable is checked is in org-agenda-files (it is also let bound in
exactly two places):

(when org-agenda-skip-unavailable-files
  (setq files (delq nil
(mapcar (function
 (lambda (file)
   (and (file-readable-p file) file)))
files

The behavior appears to be contrary to the docstring: A non-nil value means
silently remove non-reachable files and a nil value means do nothing.

Or so it appears.  Actually, the querying for removal happens in
org-check-agenda-file.  It looks like the "just skip non-reachable
files" is implemented by filtering them out so we don't call
org-check-agenda-file on them later.

The problem is that when org-agenda-file-to-front or org-remove-file is called, 
any
non-reachable files get filtered out from org-agenda-files and then
saved back to the user's customizations.  The result is that setting
org-agenda-skip-unavailable-files to t ends up remove the user's
un-reachable agenda files rather than skipping them, contrary to the
docstring.

If a user did not realize this, they may end up missing important items
on their agenda, if they have some agenda files that are sometimes
missing and get removed from org-agenda-files (e.g., mounted via a
network drive), so in my opinion this is a serious bug.

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29
Package: Org mode version 9.2.6 (9.2.6-5-g9c611f-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-2019/)

[O] Bug: org-agenda-set-tags with certain options sets tags on wrong entry [9.2.3 (9.2.3-13-g727c3f-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20190506/)]

[Allen Li]

Repro:

1. emacs -Q
2. Eval:

(setq org-tag-alist '(("agenda" . ?a)))
(add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20190506")
(define-key global-map (kbd "C-c a") #'org-agenda)
(setq switch-to-buffer-preserve-window-point t)

3. Make a tmp.org containing:

* TODO foo
* TODO bar

4. Add tmp.org to agenda files.
5. Make sure point is on the foo entry.
6. C-c a t
7. Move point to the bar entry.
8. : a RET // Set agenda tag

Expected:

agenda tag set on bar entry

Actual:

agenda tag set on foo entry

More info:

switch-to-buffer-preserve-window-point interacts poorly with the
(delete-other-windows) call in org-fast-tag-selection.


Emacs  : GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8)
 of 2019-04-12
Package: Org mode version 9.2.3 (9.2.3-13-g727c3f-elpaplus @
~/.emacs.d/elpa/org-plus-contrib-20190506/)

[O] Bug: Preserving agenda settings per buffer? [9.2.3 (9.2.3-7-g222408-elpaplus @ .emacs.d/elpa/org-plus-contrib-20190415/)]

[Allen Li]

Example variables:

org-agenda-todo-list-sublevels
org-agenda-dim-blocked-tasks

If org-agenda-dim-blocked-tasks is default true, and you have
custom agenda views foo and bar, where bar sets this to false, opening
bar will result in an agenda view where blocked tasks are not dimmed,
but if you go back to a previously opened buffer for foo and revert, the
foo agenda view will now also not be dimming blocked tasks.

This is because the local settings for an agenda view are stored in
the org-lprops property of org-agenda-redo-command, so there can only
be one set of local agenda settings, for whichever agenda command was
run last.

This behavior is confusing when combined with org-agenda-sticky,
because you can switch to the buffers of previously run agenda
commands, but if you redo/revert them, the results may be completely
different.

Actually fixing this is difficult.  Probably it should be documented
somewhere that switching directly to agenda buffers produces undefined
behavior and you have to use the agenda command.

On a slightly different tack, the variables I listed above could be
made "local" to an agenda command, like how some vars
(org-agenda-sorting-strategy I think?) have special handling so they
stick to a particular agenda buffer.  That doesn't solve the general
problem that local settings provided to a custom agenda commnd are
effectively set globally.

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Package: Org mode version 9.2.3 (9.2.3-7-g222408-elpaplus @
.emacs.d/elpa/org-plus-contrib-20190415/)

[O] Bug: Capture prepend checkbox doesn't handle scheduled [9.2.3 (9.2.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20190402/)]

[Allen Li]

Make file /tmp/tmp.org containing:

* TODO Foo
SCHEDULED: <2019-04-08 Mon>

1. emacs -Q
2. Eval

(add-to-list 'load-path (expand-file-name
"~/.emacs.d/elpa/org-plus-contrib-20190402/"))
(setq org-capture-templates '(("c" "Capture" checkitem (file+headline
"/tmp/tmp.org" "Foo") "" :prepend t)))

3. M-x org-capture RET c
4. foo C-c C-c

Contents of tmp.org:

* TODO Foo
- [ ] foo
SCHEDULED: <2019-04-08 Mon>

Expected:

* TODO Foo
SCHEDULED: <2019-04-08 Mon>
- [ ] foo

prepend checkitem should also skip any property drawer in addition to
the planning line.

This bug does not happen if the headline already contains a checkbox
list item.

I cannot reproduce this with the Org mode that ships with Emacs, so
it's probably a regression?

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Package: Org mode version 9.2.3 (9.2.3-elpaplus @
~/.emacs.d/elpa/org-plus-contrib-20190402/)

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

Thank you for the comments, attached new patch.

On Mon, Feb 18, 2019 at 9:16 PM Nicolas Goaziou  wrote:
>
> >  (defun org-agenda-finalize ()
> >"Finishing touch for the agenda buffer, called just before displaying 
> > it."
> >(unless org-agenda-multi
> > @@ -3783,7 +3784,7 @@ FILTER-ALIST is an alist of filters we need to apply 
> > when
> >   (unless org-agenda-with-colors
> > (remove-text-properties (point-min) (point-max) '(face nil)))
> >   (when (bound-and-true-p org-agenda-overriding-columns-format)
> > -   (setq-local org-agenda-overriding-columns-format
> > +   (setq-local org-agenda-local-overriding-columns-format
>
> Since this is a local variable, `setq' is enough, isn't it?

I don't know if the defvar-local in org-colview will be loaded before
this point,
so I think it's safer to just use setq-local.

> >  (defvar org-agenda-overriding-columns-format nil
> >"When set, overrides any other format definition for the agenda.
> > -Don't set this, this is meant for dynamic scoping.")
> > +Don't set this, this is meant for dynamic scoping.  Set
> > +`org-agenda-local-overriding-columns-format' instead.")
>
> The first line of a docstring cannot contain an incomplete sentence (due
> to `apropos` design).

I think you misread?  I didn't touch the first line.

>
> > +(defvar-local org-agenda-local-overriding-columns-format nil
> > +  "When set, overrides any other format definition for the agenda.
> > +This can be set as a buffer local value to avoid interfering with
> > +dynamic scoping for `org-agenda-overriding-columns-format'.")
>
> The two variable names are somewhat confusing. Could
> `org-agenda-local-overriding-columns-format' be renamed into
> `org-local-columns-format'? Since it is defined in "org-colview.el", it
> doesn't deserve the "org-agenda" prefix (and neither does the original
> `org-agenda-overriding-columns-format'.).
>
> Regards,
>
> --
> Nicolas Goaziou
From a8814962e73af61ebbbdeb20eceb53e09d030b06 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 16 Feb 2019 17:21:04 -0800
Subject: [PATCH] Fix buffer local org-agenda-overriding-columns-format bug

Setting org-agenda-overriding-columns-format as a buffer local value
interferes with how it is used as a dynamically scoped var, so use a
separate variable for buffer local setting.

* doc/org-manual.org (Using Column View in the Agenda): Updated
  reference to variable.
* lisp/org-agenda.el (org-agenda-finalize): Set buffer local variable
  instead.
* lisp/org-colview.el (org-overriding-columns-format): Renamed.
(org-agenda-overriding-columns-format): Renamed.
(org-local-columns-format): New buffer local variable.
(org-columns-edit-value): Updated reference to variable.
(org-columns-next-allowed-value): Updated reference to variable.
(org-agenda-columns): Updated reference to variable.
---
 doc/org-manual.org  |  2 +-
 lisp/org-agenda.el  |  9 +
 lisp/org-colview.el | 20 +++-
 3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a1cc35608..a8c52681b 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -10477,7 +10477,7 @@ environment.  This causes the following issues:
the entries in the agenda are collected from different files, and
different files may have different columns formats, this is
a non-trivial problem.  Org first checks if the variable
-   ~org-agenda-overriding-columns-format~ is currently set, and if so,
+   ~org-overriding-columns-format~ is currently set, and if so,
takes the format from there.  Otherwise it takes the format
associated with the first item in the agenda, or, if that item does
not have a specific format (defined in a property, or in its file),
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index c1a8a44f2..4a0604a9b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3766,7 +3766,8 @@ FILTER-ALIST is an alist of filters we need to apply when
 	 (setq-local org-agenda-name name)))
   (setq buffer-read-only nil
 
-(defvar org-agenda-overriding-columns-format)  ; From org-colview.el
+(defvar org-overriding-columns-format)
+(defvar org-local-columns-format)
 (defun org-agenda-finalize ()
   "Finishing touch for the agenda buffer, called just before displaying it."
   (unless org-agenda-multi
@@ -3781,9 +3782,9 @@ FILTER-ALIST is an alist of filters we need to apply when
 	  (org-agenda-align-tags))
 	(unless org-agenda-with-colors
 	  (remove-text-properties (point-min) (point-max) '(face nil)))
-	(when (bound-and-true-p org-agenda-overriding-columns-format)
-	  (setq-local org-agenda-overriding-columns-format
-		  org-agenda-overriding-columns-format))
+	(when (bound-and-true-p org-overriding

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

On Wed, Feb 13, 2019 at 8:17 AM Allen Li  wrote:
>
> 0. Make /tmp/tmp.org containing
>
> * TODO foo bar
>
> 1. emacs -Q
> 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" 
> ((org-agenda-overriding-columns-format "%TODO")
> 3. Eval (setq org-agenda-files '("/tmp/tmp.org"))
> 4. M-x org-agenda RET n
> 5. Move point to item
> 6. C-c C-x C-c (column view)
> 7. g
>
> Expected:
>
> Column format is preserved
>
> Actual:
>
> Column format is reset
>
> (The example uses the version of Org shipped with Emacs, but I can
> reproduce with my personal config using latest org-contrib-plus)

I think the right way to fix this is by using a separate variable for
setting buffer local values.

I have attached a patch implementing this on maint.

>
> Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
>  of 2018-07-05
> Package: Org mode version 9.2.1 (9.2.1-2-gc6d37c-elpaplus @ 
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20190204/)
From eba87f9de87cc661c99d12ef31b961c36b3d528b Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Sat, 16 Feb 2019 17:21:04 -0800
Subject: [PATCH] Fix buffer local org-agenda-overriding-columns-format bug

Setting org-agenda-overriding-columns-format as a buffer local value
interferes with how it is used as a dynamically scoped var, so use a
separate variable for buffer local setting.
---
 lisp/org-agenda.el  | 3 ++-
 lisp/org-colview.el | 9 -
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 489ecec95..054c0b268 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -3768,6 +3768,7 @@ FILTER-ALIST is an alist of filters we need to apply when
   (setq buffer-read-only nil
 
 (defvar org-agenda-overriding-columns-format)  ; From org-colview.el
+(defvar org-agenda-local-overriding-columns-format)  ; From org-colview.el
 (defun org-agenda-finalize ()
   "Finishing touch for the agenda buffer, called just before displaying it."
   (unless org-agenda-multi
@@ -3783,7 +3784,7 @@ FILTER-ALIST is an alist of filters we need to apply when
 	(unless org-agenda-with-colors
 	  (remove-text-properties (point-min) (point-max) '(face nil)))
 	(when (bound-and-true-p org-agenda-overriding-columns-format)
-	  (setq-local org-agenda-overriding-columns-format
+	  (setq-local org-agenda-local-overriding-columns-format
 		  org-agenda-overriding-columns-format))
 	(when org-agenda-view-columns-initially
 	  (org-agenda-columns))
diff --git a/lisp/org-colview.el b/lisp/org-colview.el
index 746426bc7..2fbb5aa6c 100644
--- a/lisp/org-colview.el
+++ b/lisp/org-colview.el
@@ -567,7 +567,13 @@ for the duration of the command.")
 
 (defvar org-agenda-overriding-columns-format nil
   "When set, overrides any other format definition for the agenda.
-Don't set this, this is meant for dynamic scoping.")
+Don't set this, this is meant for dynamic scoping.  Set
+`org-agenda-local-overriding-columns-format' instead.")
+
+(defvar-local org-agenda-local-overriding-columns-format nil
+  "When set, overrides any other format definition for the agenda.
+This can be set as a buffer local value to avoid interfering with
+dynamic scoping for `org-agenda-overriding-columns-format'.")
 
 (defun org-columns-edit-value ( key)
   "Edit the value of the property at point in column view.
@@ -1564,6 +1570,7 @@ PARAMS is a property list of parameters:
 	 (fmt
 	  (cond
 	   ((bound-and-true-p org-agenda-overriding-columns-format))
+	   ((bound-and-true-p org-agenda-local-overriding-columns-format))
 	   ((let ((m (org-get-at-bol 'org-hd-marker)))
 	  (and m
 		   (or (org-entry-get m "COLUMNS" t)
-- 
2.20.1

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

Apologies for the spam.

On Wed, Feb 13, 2019 at 9:11 AM Allen Li  wrote:
> I don't see an easy good fix due to how Emacs's dynamic variable
> binding works with respect to buffer local variables.
>
> One way to fix is redefine:
>
> (defun org-let (list  body)
>   (eval `(with-temp-buffer ,(cons 'let (cons list body)

This does not work for obvious reasons, please don't use it.  I'll
shut up now since I clearly need sleep.

>
> That way, the let doesn't use the buffer local value for ocf, so the
> kill-all-local-variables doesn't wipe it.
>
> I can confirm that this fixes this bug.  However, I have no idea what
> effect this may have on all of Org mode.

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

On Wed, Feb 13, 2019 at 8:37 AM Allen Li  wrote:
>
> I'm suspicious of org-agenda-mode -> kill-all-local-variables=
>
> One oddity is that repeatedly reverting the buffer swaps between the
> "correct" overriding column format and the default.

It seems like what is happening is that the org-agenda-prepare and
org-agenda-finalize calls in org-tags-view are swapping
org-agenda-overriding-columns-format (ocf) on and off.  I added debug
messages around these points, and a cycle looks like:

@@@ before prepare "%TODO %60ITEM %SCHEDULED"
@@@ after prepare "%TODO %60ITEM %SCHEDULED"
@@@ before finalize "%TODO %60ITEM %SCHEDULED"
@@@ after finalize "%TODO %60ITEM %SCHEDULED"
@@@ before prepare "%TODO %60ITEM %SCHEDULED"
@@@ after prepare nil
@@@ before finalize nil
@@@ after finalize nil

During the first cycle, prepare doesn't unset the local value for ocf
because it's not set, then in finalize the local value of ocf is set
using the current dynamic value.

During the second cycle, ocf is set locally so prepare wipes the local
value.  It looks like this also wipes the current let-bound dynamic
value for ocf, so during finalize ocf is not (re)set as a local value.

Go back to first cycle.

I don't see an easy good fix due to how Emacs's dynamic variable
binding works with respect to buffer local variables.

One way to fix is redefine:

(defun org-let (list  body)
  (eval `(with-temp-buffer ,(cons 'let (cons list body)

That way, the let doesn't use the buffer local value for ocf, so the
kill-all-local-variables doesn't wipe it.

I can confirm that this fixes this bug.  However, I have no idea what
effect this may have on all of Org mode.

Re: [O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

On Wed, Feb 13, 2019 at 8:17 AM Allen Li  wrote:
>
> 0. Make /tmp/tmp.org containing
>
> * TODO foo bar
>
> 1. emacs -Q
> 2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" 
> ((org-agenda-overriding-columns-format "%TODO")
> 3. Eval (setq org-agenda-files '("/tmp/tmp.org"))
> 4. M-x org-agenda RET n
> 5. Move point to item
> 6. C-c C-x C-c (column view)
> 7. g
>
> Expected:
>
> Column format is preserved
>
> Actual:
>
> Column format is reset
>
> (The example uses the version of Org shipped with Emacs, but I can
> reproduce with my personal config using latest org-contrib-plus)

I'm suspicious of org-agenda-mode -> kill-all-local-variables

Debugger entered--killing local value of
org-agenda-overriding-columns-format in buffer *Org
Agenda(f:SCHEDULED>"")*:
  debug--implement-debug-watch(org-agenda-overriding-columns-format
nil makunbound #"")*>)
  kill-all-local-variables()
  org-agenda-mode()
  org-agenda-prepare("TAGS SCHEDULED>\"\"")
  org-tags-view((4) "SCHEDULED>\"\"")
  (let ((org-agenda-sorting-strategy '(scheduled-up))
(org-agenda-overriding-columns-format "%TODO %60ITEM %SCHEDULED"))
(org-tags-view '(4) (if current-prefix-arg nil
"SCHEDULED>\"\"")))
  eval((let ((org-agenda-sorting-strategy '(scheduled-up))
(org-agenda-overriding-columns-format "%TODO %60ITEM %SCHEDULED"))
(org-tags-view '(4) (if current-prefix-arg nil
"SCHEDULED>\"\""
  org-let(((org-agenda-sorting-strategy '(scheduled-up))
(org-agenda-overriding-columns-format "%TODO %60ITEM %SCHEDULED"))
(org-tags-view '(4) (if current-prefix-arg nil
"SCHEDULED>\"\"")))
  (if series-redo-cmd (eval series-redo-cmd) (org-let lprops redo-cmd))
  (let* ((p (or (and (looking-at "\\'") (1- (point))) (point))) (cpa
(if (eq all t) nil current-prefix-arg)) (org-agenda-doing-sticky-redo
org-agenda-sticky) (org-agenda-sticky nil) (org-agenda-buffer-name (or
org-agenda-this-buffer-name org-agenda-buffer-name))
(org-agenda-keep-modes t) (tag-filter org-agenda-tag-filter)
(tag-preset (get 'org-agenda-tag-filter :preset-filter))
(top-hl-filter org-agenda-top-headline-filter) (cat-filter
org-agenda-category-filter) (cat-preset (get
'org-agenda-category-filter :preset-filter)) (re-filter
org-agenda-regexp-filter) (re-preset (get 'org-agenda-regexp-filter
:preset-filter)) (effort-filter org-agenda-effort-filter)
(effort-preset (get 'org-agenda-effort-filter :preset-filter))
(org-agenda-tag-filter-while-redo (or tag-filter tag-preset)) (cols
org-agenda-columns-active) (line (org-current-line)) (window-line (-
line (org-current-line (window-start (lprops (get
'org-agenda-redo-command 'org-lprops)) (redo-cmd (get-text-property p
'org-redo-cmd)) (last-args (get-text-property p 'org-last-args))
(org-agenda-overriding-cmd (get-text-property p 'org-series-cmd))
(org-agenda-overriding-cmd-arguments (if (eq all t) nil (cond ((listp
last-args) (cons (or cpa (car last-args)) (cdr last-args))) ((stringp
last-args) last-args (series-redo-cmd (get-text-property p
'org-series-redo-cmd))) (put 'org-agenda-tag-filter :preset-filter
nil) (put 'org-agenda-category-filter :preset-filter nil) (put
'org-agenda-regexp-filter :preset-filter nil) (put
'org-agenda-effort-filter :preset-filter nil) (and cols
(org-columns-quit)) (message "Rebuilding agenda buffer...") (if
series-redo-cmd (eval series-redo-cmd) (org-let lprops redo-cmd))
(setq org-agenda-undo-list nil org-agenda-pending-undo-list nil
org-agenda-tag-filter tag-filter org-agenda-category-filter cat-filter
org-agenda-regexp-filter re-filter org-agenda-effort-filter
effort-filter org-agenda-top-headline-filter top-hl-filter) (message
"Rebuilding agenda buffer...done") (put 'org-agenda-tag-filter
:preset-filter tag-preset) (put 'org-agenda-category-filter
:preset-filter cat-preset) (put 'org-agenda-regexp-filter
:preset-filter re-preset) (put 'org-agenda-effort-filter
:preset-filter effort-preset) (let ((tag (or tag-filter tag-preset))
(cat (or cat-filter cat-preset)) (effort (or effort-filter
effort-preset)) (re (or re-filter re-preset))) (if tag (progn
(org-agenda-filter-apply tag 'tag t))) (if cat (progn
(org-agenda-filter-apply cat 'category))) (if effort (progn
(org-agenda-filter-apply effort 'effort))) (if re (progn
(org-agenda-filter-apply re 'regexp (and top-hl-filter
(org-agenda-filter-top-headline-apply top-hl-filter)) (and cols
(called-interactively-p 'any) (org-agenda-columns)) (org-goto-line
line) (recenter window-line))
  org-agenda-redo()

One oddity is that repeatedly reverting the buffer swaps between the
"correct" overriding column format and the default.

[O] Bug: org-agenda-overriding-columns-format destroyed on revert [9.2.1 (9.2.1-2-gc6d37c-elpaplus)]

[Allen Li]

0. Make /tmp/tmp.org containing

* TODO foo bar

1. emacs -Q
2. Eval (setq org-agenda-custom-commands '(("n" "n" alltodo "" 
((org-agenda-overriding-columns-format "%TODO")
3. Eval (setq org-agenda-files '("/tmp/tmp.org"))
4. M-x org-agenda RET n
5. Move point to item
6. C-c C-x C-c (column view)
7. g

Expected:

Column format is preserved

Actual:

Column format is reset

(The example uses the version of Org shipped with Emacs, but I can
reproduce with my personal config using latest org-contrib-plus)

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-07-05
Package: Org mode version 9.2.1 (9.2.1-2-gc6d37c-elpaplus @ 
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20190204/)

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Wed, Dec 19, 2018 at 6:11 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Allen Li  writes:
>
> > Okay, thanks.  I guess we can see how this works out with respect to users
> > like Brent using org-tags-match-list-sublevels or otherwise using
> > hierarchy.
>
> On second thought, this may not be a good idea, especially on master
> branch, which is close from being released.
>
> As suggested before, you ought to use
> `org-columns-modify-value-for-display-function' instead. This is
> probably the cleanest way to solve the current issue.

I have worked around this locally, but I hope we can revisit this later since
it makes Org mode's user interface better.

Does it make sense for Org mode to keep a separate release branch so
new features can be worked on while a release is prepared (like how I
think Emacs does it)?

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Tue, Dec 18, 2018 at 3:18 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Allen Li  writes:
>
> > Perhaps the stars should only be shown if
> > org-tags-match-list-sublevels is set to indented, so that the agenda
> > view matches
> > the column view with respect to showing hierarchy?
>
> I don't think it makes sense since the aforementioned variable is not
> related to columns view.
>
> > I personally stand by Org mode's default stance that there's no point
> > in showing hierarchy in agenda view. Some people like Bernt have
> > workflows that do use hierarchy in agenda view, and that's fine. But
> > let us be consistent about it.
>
> I removed stars from columns view in Agenda mode, in master branch.

Okay, thanks.  I guess we can see how this works out with respect to users
like Brent using org-tags-match-list-sublevels or otherwise using hierarchy.

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Package System questions ?

[Allen Li]

On Fri, Dec 14, 2018 at 3:46 PM David Masterson  wrote:
>
> Am I reading the startup process right?
>
> In GNU Emacs v26+, it appears that package-initialize is run out of
> startup.el which is run (I think) before the various "init" files.
> Therefore, it is hardcoding the assumptions that:
>
> 1. The standard packages are in site-lisp or elpa directories.
> 2. The user packages are in .emacs.d/elpa directory.
>
> This means that, if you set up a number of package-archives to install
> packages from (such as "melpa"), all of the packages must be installed
> in "elpa" directories in your local setup.  This would seem to be a
> configuration issue.

>From the NEWS file in emacs master:

** Emacs can now be configured using an early init file.
The file is called 'early-init.el', in 'user-emacs-directory'.  It is
loaded very early in the startup process: before graphical elements
such as the tool bar are initialized, and before the package manager
is initialized.  The primary purpose is to allow customizing how the
package system is initialized given that initialization now happens
before loading the regular init file (see below).

Also, this question belongs on the Emacs mailing list rather than
the Org mode mailing list.

>
> True?
> --
> David
>

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Fri, Dec 14, 2018 at 6:36 AM Bernt Hansen  wrote:
>
>
> In my custom agenda view for Projects I set
> (org-tags-match-list-sublevels 'indented)

Good to know, although I see that setting
org-tags-match-list-sublevels to anything other than t is
semi-obsolete.

However, we are talking mostly about how the columns view in the
agenda works, not the agenda itself.

It is odd from a user standpoint that the agenda view deliberately
hides the hierarchy, while the column view adds the hierarchy back in.

Perhaps the stars should only be shown if
org-tags-match-list-sublevels is set to indented, so that the agenda
view matches
the column view with respect to showing hierarchy?  I personally stand
by Org mode's default stance that there's no point in
 showing hierarchy in agenda view.  Some people like Bernt have
workflows that do use hierarchy in agenda view, and that's fine.
But let us be consistent about it.

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Thu, Dec 13, 2018 at 6:28 AM Bernt Hansen  wrote:
>
> Allen Li  writes:
>
> > On Wed, Dec 12, 2018 at 10:00 AM Nicolas Goaziou  
> > wrote:
> >>
> >> This is not satisfying, actually. If every item has a single asterisk,
> >> you miss hierarchy between headlines in the same tree.
> >
> > I don't know what you mean.  Hierarchy is not displayed normally in
> > agenda view anyway, I don't know why displaying it in agenda column
> > view via the ITEM property is desirable?
> >
>
> I use hierarchy in my custom agenda view everyday.  Please do not remove
> this feature.

Apparently I'm missing something.  How are you using hierarchy in an
agenda view?  Agenda views are flat, e.g.:

  tasks:  TODO [#A] Some task
  tasks:  TODO [#A] Some task
  tasks:  TODO [#A] Some task
  tasks:  TODO Some task
  tasks:  TODO Some task
  tasks:  TODO Some task

If I remember correctly, the reason they're flat is that it generally
doesn't make sense to show the hierarchy because it won't make any
sense.  For example, the following:

* TODO Project A
** Some project A notes
* Project B
** TODO Some task for B

would have this hierarchy in an agenda view if we hypothetically displayed it:

  tasks:  * TODO Project A
  tasks:  ** TODO Some task for B

which I think is confusing at best (but I can believe is useful for
some work flows if you're careful).

>
> Thanks,
> Bernt

Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

[Allen Li]

On Wed, Dec 12, 2018 at 9:59 AM Nicolas Goaziou  wrote:
>
> Could you give more context about the bug you're encountering? What does
> mean "function correctly if a URL was not provided"? What is the use
> case? What result did you expect, besides not encountering an error
> message?

The issue occurs when org protocol capture is invoked without a url param, e.g.

emacsclient 'org-protocol://capture?url=percent-encoded-url=some-text'

vs

emacsclient 'org-protocol://capture?body=some-text'

By "function correctly", I mean make the latter not break
org-insert-link by not corrupting the value of org-stored-links.

The use case is capturing some text without an associated URL.

The result I expect is the latter not breaking org-insert-link.

Note that invoking the latter otherwise behaves correctly/as expected.
It starts the capture process with the provided body text/initial
contents.  The only thing that breaks is org-insert-link when the user
calls org-insert-link later.

> There are multiple ways to solve this. In particular, if a URL is not
> provided, it seems natural to store nil instead, as
> `org-protocol-capture' currently does. If we do not support missing URL,
> then it should raise an error instead of letting it slip into
> `org-insert-link'. If we do, then `org-insert-link' should handle it
> gracefully.

Except storing nil is not supported by org-insert-link, breaking it
until the savvy user manually fixes org-stored-links.  I don't see
what meaning storing and inserting a nil link could have.

We could change org-insert-link to fix or ignore the invalid value in
org-stored-links, but why not stop inserting the invalid value into
org-stored-links in the first place?

>
> So, again, more context could help understanding what is the best
> solution.
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Wed, Dec 12, 2018 at 10:00 AM Nicolas Goaziou  wrote:
>
> This is not satisfying, actually. If every item has a single asterisk,
> you miss hierarchy between headlines in the same tree.

I don't know what you mean.  Hierarchy is not displayed normally in
agenda view anyway, I don't know why displaying it in agenda column
view via the ITEM property is desirable?

>
> You can use `org-columns-modify-value-for-display-function' to remove
> the asterisks, if needed.

Is there a recommended way to set this only for agenda views?  I tried
setting it via the custom settings in org-agenda-custom-commands but
that doesn't work.

>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

[Allen Li]

Attached patch

I didn't realize that org-protocol-capture is documented for URLs,
since the concept of capturing through org-protocol is useful for
non-web browser contexts.

Anyway, I'm not interested in updating the documentation for
org-protocol-capture at the moment, but even if org-protocol-capture
is documented to need a URL, it seems wrong for it to corrupt
org-stored-links but otherwise function correctly if a URL was not
provided.
On Tue, Dec 11, 2018 at 7:18 PM Allen Li  wrote:
>
> Using Org protocol capture without supplying a URL inserts a corrupt
> entry into org-stored-links (nil "").  The nil causes a type error later
> in org-insert-link.
>
> (defun org-protocol-do-capture (info)
>   "Perform the actual capture based on INFO."
>   (let* ((temp-parts (org-protocol-parse-parameters info))
> (parts
>   (cond
>((and (listp info) (symbolp (car info))) info)
>((= (length (car temp-parts)) 1) ;; First parameter is exactly one
> character long
> (org-protocol-assign-parameters temp-parts '(:template :url :title 
> :body)))
>(t
> (org-protocol-assign-parameters temp-parts '(:url :title :body)
> (template (or (plist-get parts :template)
>org-protocol-default-template-key))
> (url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get
> parts :url
> (type (and url (string-match "^\\([a-z]+\\):" url) (match-string 1 url)))
> (title (or (plist-get parts :title) ""))
> (region (or (plist-get parts :body) ""))
> (orglink (if url
>   (org-make-link-string
>url (if (string-match "[^[:space:]]" title) title url))
> title))
> (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link
> (setq org-stored-links
>   (cons (list url title) org-stored-links))
>
>
> Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
>  of 2018-07-05
> Package: Org mode version 9.1.14 (9.1.14-1059-gadec50-elpaplus @
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)
From 112ef17dec8aa7dfaba5d6ee0018d8fe3b6639e6 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 11 Dec 2018 19:32:56 -0800
Subject: [PATCH] org-protocol: Don't corrupt org-stored-link if url is nil

* lisp/org-protocol.el (org-protocol-do-capture): Handle nil case.
---
 lisp/org-protocol.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index c0eb52c2b..81ab47698 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -503,8 +503,8 @@ Now template ?b will be used."
 		   url (if (string-match "[^[:space:]]" title) title url))
 		title))
 	 (org-capture-link-is-already-stored t)) ;; avoid call to org-store-link
-(setq org-stored-links
-	  (cons (list url title) org-stored-links))
+(when url
+  (push (if (string= title "") (list url) (list url title)) org-stored-links))
 (org-store-link-props :type type
 			  :link url
 			  :description title
-- 
2.20.0

[O] Bug: protocol capture without url corrupts org-stored-links [9.1.14 (9.1.14-1059-gadec50-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)]

[Allen Li]

Using Org protocol capture without supplying a URL inserts a corrupt
entry into org-stored-links (nil "").  The nil causes a type error later
in org-insert-link.

(defun org-protocol-do-capture (info)
  "Perform the actual capture based on INFO."
  (let* ((temp-parts (org-protocol-parse-parameters info))
(parts
  (cond
   ((and (listp info) (symbolp (car info))) info)
   ((= (length (car temp-parts)) 1) ;; First parameter is exactly one
character long
(org-protocol-assign-parameters temp-parts '(:template :url :title :body)))
   (t
(org-protocol-assign-parameters temp-parts '(:url :title :body)
(template (or (plist-get parts :template)
   org-protocol-default-template-key))
(url (and (plist-get parts :url) (org-protocol-sanitize-uri (plist-get
parts :url
(type (and url (string-match "^\\([a-z]+\\):" url) (match-string 1 url)))
(title (or (plist-get parts :title) ""))
(region (or (plist-get parts :body) ""))
(orglink (if url
  (org-make-link-string
   url (if (string-match "[^[:space:]]" title) title url))
title))
(org-capture-link-is-already-stored t)) ;; avoid call to org-store-link
(setq org-stored-links
  (cons (list url title) org-stored-links))


Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-07-05
Package: Org mode version 9.1.14 (9.1.14-1059-gadec50-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20181211/)

Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

[Allen Li]

On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou  wrote:
> > (((headline (:raw-value "stuff" :begin 17 :end 36 :pre-blank 0
> > :contents-begin 26 :contents-end 36 ...)) 17 35))
>
> `org-element-at-point' ignores narrowing.

Yes, but my issue is with the fact that the entry bounds reported by
org-element-at-point disagrees with the bounds used by org-map-entries
narrowing, in specific edge cases.

For example, when running org-map-entries on a tree, the bounds
reported by org-element-at-point can be used *except* for the last
entry, which will extend one character past the narrowing.

It seems to me that whatever Org mode considers the bounds for an
entry should be used consistently.

I looked into this and it seems this behavior is deliberate in
org-narrow-to-subtree.  I can see why this behavior exists, because if
point is at the end of an entry (after the newline), it is considered
to be pointing at the next entry.  Thus the narrowing is artificially
tightened to make it impossible to position point at the end of an
entry.  Example, the bounds of an entry/subtree delimited by $:

* A
$* B
** foo
** bar
$* C

The bounds used by narrowing:

* A
$* B
** foo
** bar$
* C

If one were to narrow to a subtree and delete the entire visible
region, it would leave an extra newline that should be considered part
of the deleted subtree.  If such an operation were repeated, it would
leave behind many extra newlines.

I think this issue is medium/low priority and difficult to resolve.  I
have worked around it for my use case.  However, I still think it is
an issue since it's an edge case that users of org-map-entries will
need to take into account.

>
> Regards,
>
> --
> Nicolas Goaziou

[O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

[Allen Li]

org-map-entries narrows the buffer to narrower than the given entry.

1. Run: cat > /tmp/tmp.org <

[O] [PATCH] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

[Allen Li]

Attached patch fixing this.

This was caused by a bug in a feature that I did not realize existed
(prefixing each line in %i).  I have also included patches to clarify
the documentation.

On Fri, Dec 7, 2018 at 6:12 PM Allen Li  wrote:
>
> There's an escaping bug in Org capture:
>
> 1. emacs -Q
> 2. Evaluate:
>
> (setq org-capture-templates
>'(("Z" "org-protocol capture" entry
>   (file "/tmp/tmp")
>   "* %?
> %(let ((x \"%:annotation\")) (if (string= x \"\") \"\" (concat x
> \"\\n\")))%i")))
>
> 3. Evaluate (require 'org-protocol)
>
> 4. Evaluate to simulate org protocol capture:
>
> (org-protocol-capture '(:template "Z" :body "foo\nbar\n"))
>
> Causes error:
>
> (error "Capture abort: (error Invalid use of ‘\\’ in replacement text)")
>
> org-protocol is used in the example as that's where I encountered it,
> but the bug is in org-capture proper.
>
> Note that this works:
>
> (org-protocol-capture '(:template "Z" :body "foo"))
>
> Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
>  of 2018-07-05
> Package: Org mode version 9.1.14 (9.1.14-1049-g04641c-elpaplus @
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)
From 9b0d43846694e0afac19289da8a4152bd0f9bd52 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Fri, 7 Dec 2018 19:35:56 -0800
Subject: [PATCH 2/2] Document %i prefix in capture templates

* doc/org-manual.org (Template expansion): Fix documentation.
* lisp/org-capture.el (org-capture-templates): Fix docstring.
---
 doc/org-manual.org  | 5 +++--
 lisp/org-capture.el | 6 --
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 3d2211474..f96c326ae 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -7390,8 +7390,9 @@ here:
 - ~%i~ ::
 
  Initial content, the region when capture is called while the
- region is active.  The entire text will be indented like ~%i~
- itself.
+ region is active.  If there is text before %i on the same line,
+ such as indentation, and %i is not inside a %(sexp), that prefix
+ will be added before every line in the inserted text.
 
 - ~%a~ ::
 
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 8505c2b92..745fbcd3d 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -287,8 +287,10 @@ be replaced with content and expanded:
   with `org-capture-use-agenda-date' set.
   %T  Time stamp as above, with date and time.
   %u, %U  Like the above, but inactive time stamps.
-  %i  Initial content, copied from the active region.  If %i is
-  indented, the entire inserted text will be indented as well.
+  %i  Initial content, copied from the active region.  If
+  there is text before %i on the same line, such as
+  indentation, and %i is not inside a %(sexp), that prefix
+  will be added before every line in the inserted text.
   %a  Annotation, normally the link created with `org-store-link'.
   %A  Like %a, but prompt for the description part.
   %l  Like %a, but only insert the literal link.
-- 
2.19.2

From 4ac40f705f615105c208fcfa6e169ed08af153cf Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Fri, 7 Dec 2018 19:27:12 -0800
Subject: [PATCH 1/2] org-capture: Quote regexp for initial content prefix

* lisp/org-capture.el (org-capture-fill-template): Quote initial
  content lead.
---
 lisp/org-capture.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 2d72c39fd..8505c2b92 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1673,7 +1673,7 @@ The template may still contain \"%?\" for cursor positioning."
 			 (let ((lead (buffer-substring-no-properties
 	  (line-beginning-position) (point
 			   (replace-regexp-in-string "\n\\(.\\)"
-			 (concat lead "\\1")
+			 (concat (regexp-quote lead) "\\1")
 			 v-i nil nil 1
 			  (?a v-a)
 			  (?A v-A)
-- 
2.19.2

[O] Bug: Org capture: Invalid use of ‘\’ in replacement text [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

[Allen Li]

There's an escaping bug in Org capture:

1. emacs -Q
2. Evaluate:

(setq org-capture-templates
   '(("Z" "org-protocol capture" entry
  (file "/tmp/tmp")
  "* %?
%(let ((x \"%:annotation\")) (if (string= x \"\") \"\" (concat x
\"\\n\")))%i")))

3. Evaluate (require 'org-protocol)

4. Evaluate to simulate org protocol capture:

(org-protocol-capture '(:template "Z" :body "foo\nbar\n"))

Causes error:

(error "Capture abort: (error Invalid use of ‘\\’ in replacement text)")

org-protocol is used in the example as that's where I encountered it,
but the bug is in org-capture proper.

Note that this works:

(org-protocol-capture '(:template "Z" :body "foo"))

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2018-07-05
Package: Org mode version 9.1.14 (9.1.14-1049-g04641c-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Thu, Dec 6, 2018 at 6:35 AM Nicolas Goaziou  wrote:
> We could ignore the level when displaying ITEM in agenda column view. As
> a consequence, every item would start with a single star, which is
> shorter and still not confusing.

Sounds good to me.

>
> WDYT?
>
> Regards,
>
> --
> Nicolas Goaziou

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Tue, Dec 4, 2018 at 2:14 AM Allen Li  wrote:
>
> Or did you mean ITEM omits the stars?  That doesn't appear to be the
> case as of 04641c4bbefc5f90e05fe4e846f4aeab15f1c262 on master
> yesterday.

So org-entry-properties does indeed return ITEM without the leading
stars, but the column view adds them back in.
This includes agenda views, where the stars make less sens out of the
outline context.

Apologies, the issue isn't in the ITEM special property, but how
column view processes it.

Re: [O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

On Mon, Dec 3, 2018 at 2:57 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> Allen Li  writes:
>
> > (I used org-submit-bug-report, but this is a feature request.)
> >
> > It would be nice to have a special property like ITEM
> > without the leading stars, which is annoying in, e.g., the agenda column
> > view.
> >
> > I imagine that this will be easy to implement.
> > There may be some UI implications (confusing in some contexts?) and
> > the property name needs to be chosen.
>
> This is already the case in master branch.

Is it not documented?  I'm running a master build, but it's not on the
Special Properties info doc.

Or did you mean ITEM omits the stars?  That doesn't appear to be the
case as of 04641c4bbefc5f90e05fe4e846f4aeab15f1c262 on master
yesterday.

>
> Regards,
>
> --
> Nicolas Goaziou

[O] Bug: Special property ITEM without stars [9.1.14]

[Allen Li]

(I used org-submit-bug-report, but this is a feature request.)

It would be nice to have a special property like ITEM
without the leading stars, which is annoying in, e.g., the agenda column
view.

I imagine that this will be easy to implement.
There may be some UI implications (confusing in some contexts?) and
the property name needs to be chosen.

If this is a bad idea, please let me know.

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Package: Org mode version 9.1.14 (9.1.14-1040-gf33fa9-elpaplus @ mixed
installation! /usr/share/emacs/26.1+gg1+14/lisp/org/ and
/usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20181125/)

Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

[Allen Li]

On Tue, Oct 2, 2018 at 2:14 PM Bernt Hansen  wrote:
>
> Nicolas Goaziou  writes:
>
> > Hello,
> >
> > Allen Li  writes:
> >
> >> org-insert-structure-template (C-c C-,) leaves point at an inconvenient
> >> place (X marks the spot):
> >>
> >> #+begin_example
> >> X#+end_example
> >>
> >> My expectation is that right after inserting the template, I can start
> >> typing or yank right into it:
> >>
> >> #+begin_example
> >> X
> >> #+end_example
> >
> > Use `C-o'.
> >
> > I think the current behaviour is better because you can yank text within
> > the newly created block without dealing with a blank line later on.
>
> I also prefer the current behaviour.
>
> I regularly use C-c C-, e C-c ' C-y C-c '
>
> to create and populate my example blocks.  This handles the newline
> correctly and does not break the syntax.  This also has the benefit of
> properly escaping text that interferes with org's syntax.

That's very interesting.  Perhaps this is too invasive, but maybe C-c
C-, should do C-c ' automatically?

Since the user almost certainly wants to populate the block
immediately, this saves the user a step,
and also handles characters to escape and a missing final newline correctly.

>
> When you have text in the kill buffer that looks like org headlines it
> pastes outside the example block -- which is proper behaviour when
> moving headlines around.
>
> try this:
>
> C-c C-, e C-y
> with the following your yank buffer
>
> 
> *** one
> some text
> *** two
> more text
> 
>
> You can't paste that inside
>
> #begin_example
> #end_example
>
> or
>
> #begin_example
>
> #end_example
>
> Regards,
> Bernt

Re: [O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

[Allen Li]

On Tue, Oct 2, 2018 at 8:06 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Allen Li  writes:
>
> > org-insert-structure-template (C-c C-,) leaves point at an inconvenient
> > place (X marks the spot):
> >
> > #+begin_example
> > X#+end_example
> >
> > My expectation is that right after inserting the template, I can start
> > typing or yank right into it:
> >
> > #+begin_example
> > X
> > #+end_example
>
> Use `C-o'.
>
> I think the current behaviour is better because you can yank text within
> the newly created block without dealing with a blank line later on.

But it works less well when you yank text that doesn't have a trailing newline.

Either you need to press C-o in one case, or DEL/backspace in the
other (to get rid of the extra blank line).

I guess I don't have a huge preference, but the current behavior is
annoying because it's the opposite of the old template behavior (e.g.
< s TAB).

One advantage that I can think of is that an extra newline is an
annoyance but otherwise harmless, whereas missing a newline messes up
the syntax.

#+begin_example
yanked text

#+end_example

#+begin_example
yanked text#+end_example

>
> Regards,
>
> --
> Nicolas Goaziou

[O] Bug: org-insert-structure-template leaves point at inconvenient place [9.1.14 (9.1.14-932-gf82a30-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180923/)]

[Allen Li]

org-insert-structure-template (C-c C-,) leaves point at an inconvenient
place (X marks the spot):

#+begin_example
X#+end_example

My expectation is that right after inserting the template, I can start
typing or yank right into it:

#+begin_example
X
#+end_example

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Package: Org mode version 9.1.14 (9.1.14-932-gf82a30-elpaplus @
/usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20180923/)

[O] Bug: org-toggle-tag always marks buffer modified [9.1.13 (9.1.13-elpaplus @ .emacs.d/elpa/org-plus-contrib-20180618/)]

[Allen Li]

org-toggle-tag always marks the buffer as modified due to how it is
implemented.  It would be better if it did not mark the buffer
modified if it does not change anything.  This is annoying for
org-depend.el (which is contrib, not officially supported) because the
org-blocker-hook set by org-depend.el will mark the buffer modified
whenever an agenda view is built/refreshed.

Glancing at org-toggle-tag, the feature isn't difficult to implement,
but it'll be ugly.

Emacs  : GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.22.24), modified by Debian
Package: Org mode version 9.1.13 (9.1.13-elpaplus @
/usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20180618/)

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

[Allen Li]

On Wed, Feb 28, 2018 at 12:25 AM Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,

> Allen Li <darkfel...@felesatra.moe> writes:

> >> > I modified the example a bit and made the undesired behavior unclear.
> >> >
> >> > * foo
> >> > :PROPERTIES:
> >> > :ID: a
> >> > :END:
> >> > * bar
> >> > :PROPERTIES:
> >> > :ID: b
> >> > :END:
> >> >
> >> > Folded, this looks like
> >> >
> >> > * foo...
> >> > * bar...
> >> >
> >> > With point on the f in foo, press C-c C-x C-w.  With point on the b
in
> > bar,
> >> > press C-c C-x C-y.  Results in
> >> >
> >> > * bar
> >> > * foo...
> >> >
> >> > Unfolded, this looks like
> >> >
> >> > * bar
> >> > * foo
> >> > :PROPERTIES:
> >> > :ID: a
> >> > :END:
> >> > :PROPERTIES:
> >> > :ID: b
> >> > :END:
> >> >
> >> > I would expect C-c C-x C-y to work like C-RET rather than M-RET, that
> > is to
> >> > always append after the heading and body rather than splitting it.
> >
> >> I changed the behaviour of `org-paste-subtree' in master. Does it solve
> >> the issue?
> >
> > No, the issue still exists.

> Applying the recipe above, I get:

>  * bar
>  :PROPERTIES:
>  :ID: b
>  :END:
>  * foo
>  :PROPERTIES:
>  :ID: a
>  :END:

Sorry, I made a silly mistake.  I can also confirm that the issue is fixed
on master.

Thanks for the quick fix.




> Regards,

> --
> Nicolas Goaziou

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

[Allen Li]

On Mon, Feb 26, 2018 at 3:11 PM Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,

> Allen Li <darkfel...@felesatra.moe> writes:

> > I modified the example a bit and made the undesired behavior unclear.
> >
> > * foo
> > :PROPERTIES:
> > :ID: a
> > :END:
> > * bar
> > :PROPERTIES:
> > :ID: b
> > :END:
> >
> > Folded, this looks like
> >
> > * foo...
> > * bar...
> >
> > With point on the f in foo, press C-c C-x C-w.  With point on the b in
bar,
> > press C-c C-x C-y.  Results in
> >
> > * bar
> > * foo...
> >
> > Unfolded, this looks like
> >
> > * bar
> > * foo
> > :PROPERTIES:
> > :ID: a
> > :END:
> > :PROPERTIES:
> > :ID: b
> > :END:
> >
> > I would expect C-c C-x C-y to work like C-RET rather than M-RET, that
is to
> > always append after the heading and body rather than splitting it.

> I changed the behaviour of `org-paste-subtree' in master. Does it solve
> the issue?

No, the issue still exists.


> Thank you.

> Regards,

> --
> Nicolas Goaziou

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Allen Li]

On Mon, Feb 26, 2018 at 5:54 PM Samuel Wales  wrote:

> On 2/26/18, Nicolas Goaziou  wrote:
> > I guess these are rhetorical questions because I answered them above.

> real questions, fyi, but never mind.

> >> if not, then i will have to use local mark
> >> ring.  this means i have to think about whether the file i was in was
> >> the same file or not.
> >
> > In practice, when I have no clue about where I was before, I first try
> > a local ring jump. If it fails, I do a global ring jump. This is
> > a no-brainer.

> i see.  but 1 step [current org pop behavior] is the only no brainer
> to me.  2 steps could take me to a similar link in the same file and
> really confuse me.

> i actually don't care what file the previous link was in.  or what
> file i am in.  org is a forest.

> i care just what project i am in.

> but even if i get used to the 2 steps, there are more issues:

> 1] the local "try a local ring jump" jump will move me away from where
> i was, which is undesirable.

> 2] and it seems that the global jump will not be guaranteed to take me
> to the actual link i did RET on.  i might have forgotten what it was.
> knowing i can get back to it can be reassuring.

> > The current situation is worse. I have to know how I made it to the
> > current location, i.e., with an Org command or not. It is harder to
> > mitigate.

> can't this be fixed by pushing to both emacs mark rings in addition to
> the current org behavior?  then you can just use emacs mark rings.

> > I changed `org-mark-ring-push' to also push to Emacs mark ring. This is
> > better, but, out of the 3 problems I stated at the beginning of this
> > thread, it only solves the second one.

> i presume you mean:

> - Emacs already provides two of them: the local one and the global one.
>This feels like re-inventing the wheel;

> the solution seems to require a new command [such as a wrapper to
> global mark pop to go to the exact location.  i presume you will push
> to it upon RET on a link.  if not then we need that too.].  otherwise
> behavior is changed significantly.

> - Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
>#23745;

> i never encountered the bug, but a push or two presumably fixes it.
  thank you.

> - `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
>(e.g., Yasnippet).

> i'm ok with removing the binding.

> am i really the only objector?  if i  knew what to do to get my
> currently non-confusing behavior back i'd be ok with it of course.

I retract my previous stance and think that we should keep the
org-mark-ring for now.  While I do not use the org-mark-ring, I do use
xref's marker ring, and I appreciate the value of a "link ring"
separate from mark-ring and global-mark-ring.

I also do not find global-mark-ring very intuitive to use.  The
feature appears to date back to 1994 (with essentially no changes
since then) with an unhelpful commit message, and the mailing list
archives do not go back that far, so I cannot fathom what use case the
author had for it.

The fact that xref, org, and anaconda-mode, to name the three I am
aware of, all have seen fit to invent their own "link ring" instead of
using the standard mark, suggests that there is a real need for a kind
of "link ring" built into Emacs proper.

Marks make sense in a single file because they serve the dual purpose
of delimiting the region and allowing the user to jump back to the
previous location of point.  However, it’s not really useful for the
"follow link" type jumps that org or xref use.  I don’t really see a
need to operate on the region between a link and the destination of
the link, assuming the destination is in the same file, but that
region is often useful for the other ways that mark is set (e.g.,
yank, isearch-forward).

Furthermore, the semantics of hyperlinking have been established;
users expect to be able to jump back after following a link, and
it is a useful feature.

My opinion is thus to keep org-mark-ring for now and discuss on
emacs-devel.  It’s true that emacs-devel is conservative (and slow),
but I think it’s worth asking at least.



> thank you for engaging.

Re: [O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

[Allen Li]

On Thu, Feb 15, 2018 at 1:02 PM Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,

> Allen Li <darkfel...@felesatra.moe> writes:

> > With the org file:
> >
> > * foo
> > some content
> > * bar
> > some content 1
> > some content 2
> >
> > 1. C-s foo RET
> > 2. C-c C-x C-w
> > 3. C-r some RET
> > 4. C-c C-x C-y
> >
> > Final content is
> >
> > * bar
> > some content 1
> > * foo
> > some content
> > some content 2

> I can reproduce it.

> > The behavior is insidious when the contents are folded:
> >
> > * foo...
> > * bar...
> >
> > turns into
> >
> > * bar...
> > * foo...

> IIUC, you cannot reproduce the example above when contents are folded,
> since you do not have access to the headline contents.

> > This can displace property and logbook drawers, timestamps, etc with
very
> > little visual indication.
> >
> > Is this behavior even desirable?  To me, killing and yanking subtrees
> > should keep the content with the headings and not "splice" subtrees into
> > the middle of another heading's content

> But you did yank the contents of the subtree into the middle of another
> heading's content. So, what should do Org? Decide that you don't know
> what you are doing and paste it at the end of the current section? What
> if you really want to split the current section?

I modified the example a bit and made the undesired behavior unclear.

* foo
:PROPERTIES:
:ID: a
:END:
* bar
:PROPERTIES:
:ID: b
:END:

Folded, this looks like

* foo...
* bar...

With point on the f in foo, press C-c C-x C-w.  With point on the b in bar,
press C-c C-x C-y.  Results in

* bar
* foo...

Unfolded, this looks like

* bar
* foo
:PROPERTIES:
:ID: a
:END:
:PROPERTIES:
:ID: b
:END:

I would expect C-c C-x C-y to work like C-RET rather than M-RET, that is to
always append after the heading and body rather than splitting it.



> Is there any good solution to this problem?

> Regards,

> --
> Nicolas Goaziou

[O] Bug: org-paste-subtree displaces folded content [9.1.6 (9.1.6-48-gfe7619-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)]

[Allen Li]

With the org file:

* foo
some content
* bar
some content 1
some content 2

1. C-s foo RET
2. C-c C-x C-w
3. C-r some RET
4. C-c C-x C-y

Final content is

* bar
some content 1
* foo
some content
some content 2

The behavior is insidious when the contents are folded:

* foo...
* bar...

turns into

* bar...
* foo...

This can displace property and logbook drawers, timestamps, etc with very
little visual indication.

Is this behavior even desirable?  To me, killing and yanking subtrees
should keep the content with the headings and not "splice" subtrees into
the middle of another heading's content

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
  of 2018-02-08
Package: Org mode version 9.1.6 (9.1.6-48-gfe7619-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20180212/)

Re: [O] [Bug] M-S Ret keybinding translated to M-Ret

[Allen Li]

Thanks, your new patch looks acceptable to me.


On Fri, Feb 9, 2018 at 7:02 AM Matt Lundin <m...@imapmail.org> wrote:

> Allen Li <vianchielfa...@gmail.com> writes:
>
> > On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin <m...@imapmail.org> wrote:
> >
> >> Matt Lundin <m...@imapmail.org> writes:
> >
> >> > I discovered that when trying to insert a new item with a checkbox
> using
> >> > M-S Return (org-insert-todo-heading), the keybinding is "translated"
> to
> >> > M-Return (org-meta-return). As a result, all I get is simple list item
> >> > without a checkbox.
> >> >
> >
> >> The attached patch fixes this issue.
> >
> > I'm pretty sure your patch would break those binding in terminal Emacs
> > completely, since  cannot be typed in the terminal and Emacs
> > does not remap these bindings.
>
> Attached please find a more limited patch that fixes the issue in the
> GUI without affecting TTY use. I have only changed bindings for the
> M-S-RET or S-RET combinations. These combinations cannot be used in the
> TTY anyway and Org Mode already defines alternative TTY bindings for
> these combinations.
>
> Best,
> Matt
>
>

Re: [O] [Bug] M-S Ret keybinding translated to M-Ret

[Allen Li]

On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin  wrote:

> Matt Lundin  writes:

> > I discovered that when trying to insert a new item with a checkbox using
> > M-S Return (org-insert-todo-heading), the keybinding is "translated" to
> > M-Return (org-meta-return). As a result, all I get is simple list item
> > without a checkbox.
> >

> The attached patch fixes this issue.

I'm pretty sure your patch would break those binding in terminal Emacs
completely, since 
cannot be typed in the terminal and Emacs does not remap these bindings.

Furthermore, I cannot reproduce your issue on Org mode version 9.1.6
(9.1.6-33-g5b4a71-elpaplus)

C-h C-k M-S-

 runs the command org-insert-todo-heading (found in
org-mode-map), which is an interactive compiled Lisp function in
‘org.el’.

It is bound to .

(org-insert-todo-heading ARG  FORCE-HEADING)

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Allen Li]

On Tue, Jan 30, 2018 at 3:15 PM, Samuel Wales  wrote:
> On 1/30/18, Nicolas Goaziou  wrote:
>> With local ring, you do, not with global one. That is standard Emacs
>> behaviour.
>
> does this constitute a change in org behavior?  i'd want the same
> behavior as now.  it would be confusing to follow a link, then follow
> another link in the same buffer, then go back globally, and end up not
> in the original place [or even the same buffer].

It does change org behavior, since the native mark ring
distinguishes local from global, whereas org-mark-ring does not.
With the proposed change, there won't be a single
org-mark-ring-goto, you would have to make sure you call the
right command out of pop-to-mark-command or pop-global-mark.

As a counterpoint, it is not entirely without precedent to
implement our own mark ring. xref.el also has its own "marker"
ring.

Maybe there should be a standard specialized marker ring macro in
Emacs, then org and xref (and others) can use it.

>
> probably i have the wrong end of the stick.  but i find that asking
> weird questions like this can lead to people being on the same page
> where they were not.
>

Re: [O] [RFC] Could we get rid of Org specific "mark ring"

[Allen Li]

I was not aware Org had its own mark ring, and I see no use for it
personally when Emacs's mark ring exists.

On Mon, Jan 29, 2018 at 3:21 PM, Nicolas Goaziou  wrote:
> Hello,
>
> As the title suggests, I'm wondering if we could remove Org's own
> implementation of the mark ring, for some reasons :
>
> - Emacs already provides two of them: the local one and the global one.
>   This feels like re-inventing the wheel;
>
> - Org mark ring and Emacs mark ring are sometimes out of sync, hence bug
>   #23745;
>
> - `org-mark-ring-goto' binding (C-c &) conflicts with some minor modes
>   (e.g., Yasnippet).
>
> So, could we simply remove this part of Org and use Emacs facilities,
> with their standard bindings (C-u C- and C-x C-) and behaviour
> instead?
>
> For hard-core Org users, it might be possible to create a function that
> cycles among Org buffers only in the Emacs' mark ring. I don't think
> this is necessary, tho.
>
> Thoughts?
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>

Re: [O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]

[Allen Li]

On Fri, Jan 19, 2018 at 1:35 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> C-c C-k unfolds archived headings.  I am using it/interpreting it as a
>> subtree variant to S-TAB, which shows the CONTENTS headlines only view
>> without unfolding archived headings.
>
> Could you provide an ECM?

* Foo
** Bar
*** a
*** b
** Archive :ARCHIVE:
*** a
*** b
*** c

Expected visibility when using C-c C-k on Foo:

* Foo
** Bar
*** a
*** b
** Archive :ARCHIVE:...

Actual:

* Foo
** Bar
*** a
*** b
** Archive :ARCHIVE:
*** a
*** b
*** c

>
> Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou

[O] Bug: C-c C-k unfolds archived headings [9.1.6 (9.1.6-10-g0c9329-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)]

[Allen Li]

C-c C-k unfolds archived headings.  I am using it/interpreting it as a
subtree variant to S-TAB, which shows the CONTENTS headlines only view
without unfolding archived headings.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-04
Package: Org mode version 9.1.6 (9.1.6-10-g0c9329-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20180108/)

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 6:36 AM, Robert Horn <rjhorn...@gmail.com> wrote:
>
> Allen Li writes:
>
>> On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter <a...@alphapapa.net> wrote:
>>
>> I don’t see a use case for checking all heading data.
>>
>
> I can see such cases arising from templates and time tracking.  I can
> have a template that captures telephone calls.  The call comes in and I
> start the template.  At this point the heading is just "Received Phone
> Call" and a time tracking start.  Time tracking is eventually kept in a
> drawer, not in the headline.
>
> I might eventually go back an revise the headline based on notes from
> the call, but that will not happen during the call.  It's quite likely
> that sorting out the calls will happen at the end of the day or the next
> day.
>
> Similarly, I receive lab results.  These will initially be a headline
> with just "Lab Result", a time tag like CLOCK, and a tag to indicate
> that it is a lab result.  Some time later I might move them around to
> attach them to a patient or project, but often by just moving them as
> element into the right section for that patient or project.  So these
> also have the same headline contents and different headline data.

It doesn’t sound like you end up with duplicates though?  How do you
envision using duplicate removal for your workflows?

In any case, it sounds like you want to assign unique IDs to each entry
as suggested by Florian and remove duplicates using IDs instead of
matching against heading data, which could collide through sheer luck.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 7:28 AM, Florian Beck  wrote:
>
>> AFAIK, this is the first time this need is expressed on this ML. There
>> is no equivalent in "org-list.el" either.
>
>
> A way to handle duplicates would be useful, indeed. But a basic function
> should only remove duplicates that are truly identical (same properties,
> same tags, same/no content). Still, removing true duplicates from subtrees
> (AND lists) would be useful.
>
> More useful would be a slightly more general approach. I have three kinds of
> duplicates:
>  - duplicate IDs (which are handled rather poorly),
>  - duplicate content (which often is only almost identical) and
>  - duplicate headings (which usually I want to rectify when they are on
>the same level of the same subtree)
>
> As you can see, a fixed concept of duplication is probably not going to
> work.

It sounds like this problem might vary too much across use cases to
generalize and include in Org mode because...

>
> What I'd like is a function finds duplicates according to scope, match (as
> in `org-map-entries') and a user defined function. This function should then
> display the problem cases (via agenda view?). Then we need a couple of
> convenience functions like
>  - delete all duplicates but the one at point,
>  - mark duplicates I want to keep,
>  - uniquify entries (tricky; for headlines maybe prompt the user; for
>IDs, we should check if the ID is referenced from somewhere)
>  - merge entries.
>
> But then, I also have duplicates (in content) I want to keep, e.g. one in my
> notes and in a writing project. So, we'd need a property like
> "DUPLICATE_OF".

You’re requesting a different feature, removing duplicates across all
agenda files.  My initial proposal was just for removing duplicate
direct children (whether by heading or full text pending discussion)
under the heading at point.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Tue, Jan 2, 2018 at 8:36 AM, Nick Dokos <ndo...@gmail.com> wrote:
> Allen Li <vianchielfa...@gmail.com> writes:
>>
>> There is always undo and automatic Emacs file backups.
>>
>
> There be dragons.
>
> The problem is that some things happen invisibly and far away from
> where you are, so you don't know about it and you don't find out for a
> couple of weeks.  Undo and automatic backups are useless in that case.
>
> That *has* happened: there have been multiple postings in the ML about
> such problems. Whenever it has happened, the devs have always modified
> org to make it safer: that is the prudent thing to do and the correct
> course of action IMO.
>
> Hell hath no fury like an orgmode user who lost part of his/her
> precious org file because of an errant keystroke a month ago and was
> not aware of the loss until it was too late.

I can see where you're coming from, but for me there are various reasons
why I don’t think warning is right:

1. org-sort-entries, which performs an action of similar scope and
   destructiveness, does not need to warn so far.

2. Since I see the only use case for warning is checking beforehand, a
   user that uses this command frequently is not going to type C-c d C-u
   C-c d every time (assuming the user has bound this command to C-c d),
   they’re just going to type C-u C-c d or get frustrated and just bind
   the actual command without warning to C-c d.  So warning provides
   zero safety in practice.

   Another possibility is using a y or n confirmation prompt before
   removing duplicates, however this falls into the same trap that a
   user who uses this frequently is just going to bind the command to a
   key and disable this check.

3. I don’t propose binding this command to any key by default, and I
   don’t think M-x org-remove-duplicates RET is a very common typo.

4. The only commands in Emacs that warn beforehand are truly
   irreversible commands, like deleting in Dired or killing a buffer.
   Everything else in Emacs follows the philosophy of using undo if the
   user makes a mistake, including lots of commands that could have
   unintentional, low visibility effects.  I would prefer following this
   policy unless it proves to actually be a problem.  It seems like
   org-sort-entries in practice has not suffered from this problem, so I
   believe a remove duplicates command will similarly not suffer from
   this problem in practice.

5. Everyone should be keeping reliable backups.  This is reiterated all
   the time, yet no one seems to follow it? =)

>
> --
> Nick
>
>

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Mon, Jan 1, 2018 at 8:07 PM, Adam Porter <a...@alphapapa.net> wrote:
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> I don’t know if a more intelligent way of handling tags and todo
>> keywords is worth the extra complexity, but in the use case that I
>> imagine it makes sense to match using only the heading/list item:
>>
>> * Things to buy
>> ** TODO cabbage
>> ** DONE milk :store1:
>>Maybe I forgot a tag here.  Oh well, I already bought the milk.
>> ** TODO carrots
>> ** TODO milk :store1:store2:
>>
>> ...
>>
>> It doesn’t make sense to include the contents because I see this as
>> primarily being useful for list items.  In particular, we would want
>> to ignore log entries and properties for the sake of matching
>> (intelligent property or logbook merging might be useful, but adds
>> complexity).
>
> I think such a command should check all heading data by default,
> because that's the safest option.  A user who commonly needs to ignore
> one or more types of data could use a custom function that calls the
> command with arguments to disable checking of certain types.

I don’t see a use case for checking all heading data.

>> Since the point would be remove duplicates from lists, I don’t think
>> warning is very useful.  I would want to remove the duplicate list
>> items, not get a warning about it and delete them manually.  Perhaps
>> that would be a useful additional feature however (like uniq -d).
>
> I think warning or asking for confirmation should be the default action,
> because it's the safest option.  Users who want to skip that could use a
> prefix argument or call it from a custom command.

There is always undo and automatic Emacs file backups.

>> I don’t think doing a full text check is useful, but if someone has a
>> use case for that, please speak up.
>
> An example where this would be useful is if the user has copied and
> pasted subtrees and accidentally pasted one more than once.

In that case, the user should use undo instead of a remove duplicates
command.

> I argue here for the safest behavior by default because I've found that,
> in very large Org buffers, it's easy to lose my place in the file, and
> it's easy to accidentally do something that I didn't mean to, without
> noticing.  IMO this is simply a consequence of Org buffers still being
> plain-text.

I don’t agree with this philosophy.  Org and Emacs already has lots of
commands that can cause damage, for example org-sort-entries which my
remove duplicates command is modeled after (both modify the direct children
under the heading at point irreversibly ignoring undo).  If this command should
warn, then org-sort-entries should also warn.  If org-sort-entries does not need
to warn, then this command does not need to warn.

Emacs makes backups by default and supports undo, which under my
philosophy is good enough; we shouldn’t be constantly asking for
confirmation to prevent user error.  That just causes pop-up dialog fatigue.
For example, everyone clicks OK on pop-up confirmation boxes without
reading them.
These kinds of confirmation prompts are worse than useless; they slow
down and annoy the user without providing any protection.  Undo is the
better solution.

> So it is quite conceivable to me that a user might intentionally give
> two headings the same name (e.g. a user who captures quotations to an
> inbox file might have two "Quote" headings that are completely
> different), or might accidentally duplicate a subtree and then make a
> desired change to one of them without realizing there was a
> duplicate--then he might use this deduplication command and accidentally
> delete a subtree he didn't mean to, resulting in data loss.

I think it would be more useful for list members to post actual use
cases than hypothesize about what people want.

For me, the use case is filtering out duplicates from a list,
e.g. groceries to buy or links to read captured with timestamps and
other metadata, so checking the tags, todo, or body text is not useful,
warning is not useful.

Based on the responses I have gotten, it sounds like this feature is
too specialized to be worth including in Org mode, so I will stop
pursuing this unless people post actual use cases/desire for
the feature.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Mon, Jan 1, 2018 at 10:26 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> Org mode is fundamentally an outliner, and one often makes lists with
>> an outliner.  Filtering out duplicates from a list seems to me like a
>> common need.
>
> AFAIK, this is the first time this need is expressed on this ML. There
> is no equivalent in "org-list.el" either.
>
> Anyway, I'm not questioning the usefulness of the feature in your
> workflow. AIUI, in your implementation, duplicates are headlines with
> the same title, but without considering TODO keyword, priority, comment
> status, tags or contents. So,
>
>   * DONE Summary :Alice:
>   * TODO Summary :Bob:
>
> are duplicates. Isn't it a bit too tolerant? We may be able to find
> a more general function that still suits you.

I see this feature as primarily being useful on lists.  So for example:

* Things to buy
** cabbage
** milk
** carrots
** milk

I don’t know if a more intelligent way of handling tags and todo
keywords is worth the extra complexity, but in the use case that I
imagine it makes sense to match using only the heading/list item:

* Things to buy
** TODO cabbage
** DONE milk :store1:
   Maybe I forgot a tag here.  Oh well, I already bought the milk.
** TODO carrots
** TODO milk :store1:store2:

>
>> I wrote such a command to support some of my work flows, and I posted
>> this here because I think there is a possibility that other Org users
>> might also find it useful.
>
> You didn't answer to any of my suggestions, tho. Are they fundamentally
> wrong? I.e., wouldn't warning instead of deleting more useful? Or would
> it make more sense to include contents when looking for duplicates ? In
> the latter case, maybe a prefix argument could toggle headline check and
> full check.

Since the point would be remove duplicates from lists, I don’t think
warning is very useful.  I would want to remove the duplicate list
items, not get a warning about it and delete them manually.  Perhaps
that would be a useful additional feature however (like uniq -d).

It doesn’t make sense to include the contents because I see this as
primarily being useful for list items.  In particular, we would want
to ignore log entries and properties for the sake of matching
(intelligent property or logbook merging might be useful, but adds
complexity).

I don’t think doing a full text check is useful, but if someone has a
use case for that, please speak up.

Re: [O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

On Mon, Jan 1, 2018 at 2:04 AM, Nicolas Goaziou  wrote:
> Duplicates headings are not necessarily wrong. I think this is too
> specific to be integrated in Org proper.
>
> Maybe we could add a check for duplicates headings in Org Lint instead,
> and add this to Worg, in a "tools" page.
>
> Or we could check for duplicate headings _including contents_, which are
> more likely to be an error.
>
> WDYT?

Org mode is fundamentally an outliner, and one often makes lists with
an outliner.  Filtering out duplicates from a list seems to me like a
common need.  I wrote such a command to support some of my work flows,
and I posted this here because I think there is a possibility that
other Org users might also find it useful.

If this is not so, I’m perfectly okay just keeping this in my personal
config.

[O] New feature? Remove duplicate subheadings, preserving order

[Allen Li]

I wrote a command to remove duplicate subheadings, which I use to
remove duplicate captured links among other things.  Would this be a
useful addition to Org mode?

I have included it below for reference.  I will clean it up a bit if
it's a worthy feature.

(defun mir-org-uniq ()
  "Remove duplicate subheadings, preserving order."
  (interactive)
  (let ((seen (make-hash-table :test 'equal))
(removed 0))
(save-excursion
  (org-map-entries (lambda ()
 (let ((heading (org-get-heading t t t t)))
   (if (not (gethash heading seen))
   (puthash heading t seen)
 (org-cut-subtree)
 (org-backward-heading-same-level 1)
 (setq removed (1+ removed)
   (format "LEVEL=%s" (1+ (org-current-level)))
   'tree))
(message "Removed %d duplicates" removed)))

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Allen Li]

On Sat, Dec 30, 2017 at 3:57 AM, Bastien  wrote:
> Hi Achim,
>
> Achim Gratz  writes:
>
>> Am 29.12.2017 um 13:26 schrieb Bastien Guerry:
>>> Migrating to a new vultr instance was easier than trying to upgrade
>>> the rackspace hosting service and the vultr pricing is better.
>>
>> It's water under the bridge now, but if there had been a discussion
>> here we might have converged to a different solution.
>
> Yes, I should have raised the issue on the list to see if people would
> come up with preferrable solutions, apologies for that.
>
> But I had very little time and the clock was ticking.
>
> Since I wasn't sure I could follow a potentially long discussion with
> many suggestions, and since the solution I envisioned does not impact
> regular users, I thought it was best to *just do it*.
>
> Nothing is irreversible, my time is gone anyway.
>
> So if you want to open a discussion on better hosting plans and if you
> or someone else is willing to handle the migration and to maintain the
> server afterwards, we can of course discuss this.

It sounds like we already have a solution, so I don't suggest anyone
spend more time on this since I am sure there are lots of bugs that
would be worth fixing.

I don’t want to blame anyone, just to clarify the state of affairs.  It
looks like Rackspace failed to communicate properly and on short notice.
People simply make mistakes, including myself, so I don’t think pointing
fingers is productive.

Re: [O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

[Allen Li]

On Sat, Dec 30, 2017 at 4:10 AM, Bastien <b...@gnu.org> wrote:
> Hi Allen,
>
> thanks for the patch, it looks good.
>
> Can you provide it with a changelog?  Like for those two:
>
> https://code.orgmode.org/bzg/org-mode/commit/b9b921716ba1d2a564bb9443427dfb21bb609e05
> https://code.orgmode.org/bzg/org-mode/commit/da83e7d583895976a2398becbb995bcce1f729be

Oops, done.  Attached new patch.

> I assume the email address darkfeline AT felesatra DOT moe belongs
> to you, in which case you don't need to add "TINYCHANGE" at the end
> of the changelog message since your FSF papers are signed.

Yes, that's under a domain that I own so I don't rely on Gmail to
receive email (although I often send with Gmail to avoid spam filter
issues, alas).

You can find my public key/identity on, e.g. the MIT key servers.

>
> Thanks!
>
> --
>  Bastien
From 21d8d507474ac3faa5b1ea9dfa7aa3647cddd8af Mon Sep 17 00:00:00 2001
From: Allen Li <darkfel...@felesatra.moe>
Date: Sat, 30 Dec 2017 03:41:51 -0800
Subject: [PATCH] Remove agenda-archives even with buffer restriction

* lisp/org-agenda.el (org-search-view): Remove agenda-archives even
  with buffer restriction
---
 lisp/org-agenda.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 18630..7f3b9d0ca 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4482,9 +4482,9 @@ is active."
   (setq files (org-agenda-files nil 'ifmode))
   ;; Add `org-agenda-text-search-extra-files' unless there is some
   ;; restriction.
-  (unless (get 'org-agenda-files 'org-restrict)
-	(when (eq (car org-agenda-text-search-extra-files) 'agenda-archives)
-	  (pop org-agenda-text-search-extra-files)
+  (when (eq (car org-agenda-text-search-extra-files) 'agenda-archives)
+	(pop org-agenda-text-search-extra-files)
+	(unless (get 'org-agenda-files 'org-restrict)
 	  (setq files (org-add-archive-files files
   ;; Uniquify files.  However, let `org-check-agenda-file' handle
   ;; non-existent ones.
-- 
2.15.1

Re: [O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

[Allen Li]

On Sat, Dec 30, 2017 at 3:38 AM, Allen Li <vianchielfa...@gmail.com> wrote:
> Doing a text agenda search with org-agenda-text-search-extra-files
> set to (agenda-archives) and with a buffer restriction results in an error:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp agenda-archives)
>   file-exists-p(agenda-archives)
>   #[(a b) "\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p
> file-equal-p] 3]("/tmp/tmp.org" agenda-archives)
>   cl--position("/tmp/tmp.org" (agenda-archives) 0 1)
>   cl--delete-duplicates(("/tmp/tmp.org" agenda-archives) (:test #[(a
> b) "\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p
> file-equal-p] 3]) t)
>   cl-remove-duplicates(("/tmp/tmp.org" agenda-archives) :test #[(a b)
> "\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p file-equal-p]
> 3])
>   org-search-view(nil)
>   funcall-interactively(org-search-view nil)
>   call-interactively(org-search-view)
>   org-agenda(nil)
>   funcall-interactively(org-agenda nil)
>   call-interactively(org-agenda nil nil)
>   command-execute(org-agenda)

I made a patch for this (attached), which works when evaluated in my
working session.
We were not removing the agenda-archives symbol if a restriction is in effect.

>
>
> Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
>  of 2017-12-04
> Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpaplus @
> /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)
From ea7602a50ce258eeb4833962f91150d401303171 Mon Sep 17 00:00:00 2001
From: Allen Li <darkfel...@felesatra.moe>
Date: Sat, 30 Dec 2017 03:41:51 -0800
Subject: [PATCH] Remove agenda-archives even with buffer restriction

---
 lisp/org-agenda.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 18630..7f3b9d0ca 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -4482,9 +4482,9 @@ is active."
   (setq files (org-agenda-files nil 'ifmode))
   ;; Add `org-agenda-text-search-extra-files' unless there is some
   ;; restriction.
-  (unless (get 'org-agenda-files 'org-restrict)
-	(when (eq (car org-agenda-text-search-extra-files) 'agenda-archives)
-	  (pop org-agenda-text-search-extra-files)
+  (when (eq (car org-agenda-text-search-extra-files) 'agenda-archives)
+	(pop org-agenda-text-search-extra-files)
+	(unless (get 'org-agenda-files 'org-restrict)
 	  (setq files (org-add-archive-files files
   ;; Uniquify files.  However, let `org-check-agenda-file' handle
   ;; non-existent ones.
-- 
2.15.1

[O] Bug: agenda text search with buffer restriction fails [9.1.5 (9.1.5-1-gb3ddb0-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)]

[Allen Li]

Doing a text agenda search with org-agenda-text-search-extra-files
set to (agenda-archives) and with a buffer restriction results in an error:

Debugger entered--Lisp error: (wrong-type-argument stringp agenda-archives)
  file-exists-p(agenda-archives)
  #[(a b) "\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p
file-equal-p] 3]("/tmp/tmp.org" agenda-archives)
  cl--position("/tmp/tmp.org" (agenda-archives) 0 1)
  cl--delete-duplicates(("/tmp/tmp.org" agenda-archives) (:test #[(a
b) "\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p
file-equal-p] 3]) t)
  cl-remove-duplicates(("/tmp/tmp.org" agenda-archives) :test #[(a b)
"\302 !\205 \302 !\205 \303  \"\207" [a b file-exists-p file-equal-p]
3])
  org-search-view(nil)
  funcall-interactively(org-search-view nil)
  call-interactively(org-search-view)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)


Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-04
Package: Org mode version 9.1.5 (9.1.5-1-gb3ddb0-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20171225/)

Re: [O] [IMPORTANT] Server migration: please update your git repositories before 31/12/2017

[Allen Li]

On Fri, Dec 29, 2017 at 4:26 AM, Bastien Guerry  wrote:
> Hi Achim,
>
> Achim Gratz  writes:
>
>> And if you'd read through the entirety of the Register article you
>> linked to you'd find that presumably any existing OSS hosting would
>> continue to be free, so why exactly does Org need to migrate?
>
> I didn't decide to migrate the server based on reading this article
> but based on email exchanges with Jason.
>
> Migrating to a new vultr instance was easier than trying to upgrade
> the rackspace hosting service and the vultr pricing is better.

I'm not sure I understand.  According to the referenced news article,
Rackspace will continue to service existing FOSS projects (i.e., Org)
for free.  Shouldn't Rackspace's free pricing be better than vultr's
$5 hosting?

Re: [O] Bug: org-clock-total-time is calculated from midnight in UTC (not in current time zone) [9.1.4 (9.1.4-13-g84cb63-elpa @ /home/yantar92/.emacs.d/elpa/org-20171218/)]

[Allen Li]

On Thu, Dec 21, 2017 at 5:55 PM, Ihor Radchenko
 wrote:
>
> org-clock-in in org-clock.el calculates org-clock-total-time via calling
> (org-clock-sum-current-item (org-clock-get-sum-start)).
> However, org-clock-get-sum-start returns the time in UTC, which is not
> considered by org-clock-sum-current-time.
>
> My time zone if UTC+8 and org-clock-mode-line-total is 'today. Hence
> org-clock-total-time is gives total time starting from 8am today (which
> is midnight in UTC) instead of midnight in UTC+8.

This sounds like a continuation of Org mode’s timezone issues.

The original thread (which is long-winded):

http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg0.html
http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg00027.html

The second bug, also timezone issues:

http://lists.gnu.org/archive/html/emacs-orgmode/2017-12/msg00039.html

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

On Mon, Dec 11, 2017 at 6:10 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> On Wed, Dec 6, 2017 at 12:19 PM, Allen Li <vianchielfa...@gmail.com> wrote:
>>> (Can reproduce with Org 9.1.3, submitting with emacs -Q)
>>>
>>> Using a file tmp.org:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:
>>>   *** Test
>>>   :PROPERTIES:
>>>   :ARCHIVE_TIME: 2017-12-06 Wed 12:13
>>>   :END:
>>>   ** Bar
>>>
>>> This appears like so with default visibility:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>>>   ** Bar
>>>
>>> Archiving Bar with C-c C-x A yields:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>>>   *** Bar...
>>>
>>> Expected visibility:
>>>
>>>   * Foo
>>>   ** Archive :ARCHIVE:...
>
> AFAICT, the action leaves point on the just archived sub-heading. As
> a consequence, it has to visible.
>
> Your expected visibility means the function should move point. Why would
> that be better than letting it on the headline you just operated on?

Archiving DOES move point, it's just a question of where it moves
point to.  It should not be moving point to the archived heading.
Examples (^ is point):

  * Foo
  ** A
  ** ^B
  ** C
  ** Archive :ARCHIVE:...

Archiving to a separate file yields:

  * Foo
  ** A
  ^** C
  ** Archive :ARCHIVE:...

Archiving to a subtree yields:

  * Foo
  ** A
  ^** C
  ** Archive :ARCHIVE:...

BUT if the Archive heading isn’t last:

  * Foo
  ** Archive :ARCHIVE:...
  ** A
  ** ^B
  ** C

Archiving to a separate file yields:

  * Foo
  ** Archive :ARCHIVE:...
  ** A
  ^** C

Archiving to a subtree yields:

  * Foo
  ** Archive :ARCHIVE:
  *** B^...
  ** A
  ** C

The implementation is painfully inconsistent.

Re: [O] Bug: shiftmeta[left|right] on multi line items [9.1.2 (release_9.1.2-40-g6ca906 @ /usr/local/share/emacs/27.0.50/lisp/org/)]

[Allen Li]

On Sat, Dec 9, 2017 at 4:41 PM, Nathan Aclander
 wrote:
>
> Nicolas Goaziou  writes:
>
>> I don't qualify this as a bug. These commands explicitly work when point
>> is at the beginning of an item. Indeed, the sub-item may be arbitrarily
>> large, contain tables... it would be confusing to move the whole
>> sub-list when its structure is out of sight.
>
> Why do you think it would be confusing to move the whole sub-list? Why
> would it be move confusing when the point is on the sub-item vs. when
> the point is on the parent item?
>
> I think the inconsistency is unintuitive here, and causes confusion. And
> I think since large sub-items already get moved when the point is
> at the beginning, it would make sense to also move them when the point
> is on the sub item.
>
> Nathan

I think what Nicolas is saying is this (^ is point):

* ^Heading

M-S-left/right works here.

* Heading
^content text

M-S-left/right does not work here.  Let’s assume that it does work
here to be consistent with the feature/bug you are requesting.

* Heading

- foo
  - bar
^second bar line

M-S-left/right does not work here.  Let’s assume that it does work
here per the feature/bug you are requesting.  Does it move bar, foo,
or Heading?  What if the text is very long and you cannot see where
you are?

  ...
  some very long text
  ^some very long text
  some very long text
  ...

What M-S-left/right does would be very confusing.

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

[Allen Li]

On Mon, Dec 4, 2017 at 11:59 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> 
>> wrote:
>>> Hello,
>>>
>>> Jan Böhm <schmuufanp...@gmx.de> writes:
>>>
>>>> Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave
>>>> just like normally setting todo state to "DONE" with org-todo.
>>>> Specifically, the timestamp
>>>> added in the log takes the current time instead of 23:59 of the previous
>>>> day, as would be expected.
>>>>
>>>> Replicate behaviour:
>>>> start emacs -Q
>>>> set org-log-done to "time"
>>>> visit new file and switch to org mode
>>>> create TODO headline and set TODO state to "DONE" by calling
>>>> "org-todo-yesterday"
>>>> ⇒ todo state is set to DONE correctly, but the timestamp inserted in
>>>> the log drawer is the current time.
>>>
>>> I cannot reproduce it in a recent Org release. Could you double-check
>>> with a newer Org?
>>
>> I am going to blindly wager that this is yet another bug caused by Org
>> mode's subtle timezone issues.
>>
>> I can reproduce it (and crucially, I am not in the GMT time zone),
>> although the repro recipe produces a CLOSED timestamp and not a log
>> drawer timestamp.
>
> I removed timezone references from maint. Can you still reproduce the
> issue?

I can confirm that it's fixed on 9.1.4 (org-plus-contrib-20171205)

Re: [O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

On Wed, Dec 6, 2017 at 12:19 PM, Allen Li <vianchielfa...@gmail.com> wrote:
> (Can reproduce with Org 9.1.3, submitting with emacs -Q)
>
> Using a file tmp.org:
>
>   * Foo
>   ** Archive :ARCHIVE:
>   *** Test
>   :PROPERTIES:
>   :ARCHIVE_TIME: 2017-12-06 Wed 12:13
>   :END:
>   ** Bar
>
> This appears like so with default visibility:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   ** Bar
>
> Archiving Bar with C-c C-x A yields:
>
>   * Foo
>   ** Archive :ARCHIVE:...
>   *** Bar...
>
> Expected visibility:
>
>   * Foo
>   ** Archive :ARCHIVE:...

Actually, this issue is a bit more severe.  point does not get left on
the next headline, which breaks my workflow of recording a macro for
C-c C-x A and tapping F4 many times.

According to 
http://lists.gnu.org/archive/html/emacs-orgmode/2017-10/msg00286.html

> AFAIK, there is no special location in the file for archived subtrees,
> i.e., there is nothing wrong with
>
>   * Some projects
>   ** Some item...
>   ** Archive :ARCHIVE:...
>   ** New entry...

This bug means that the Archive headline's position is significant.

[O] bug#28263: bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

On Wed, Dec 6, 2017 at 7:23 AM, Drew Adams  wrote:
> [paraphrased] Org should not suggest user reserved key bindings

I agree with you in general.  However, when I first started using
Emacs for Org mode years ago, I found the documentation very helpful.
Furthermore, I did not find the documentation misleading about the
fact that these keys are not standard.

For users that are not accustomed to Emacs, the ability to bind keys
freely is paralyzing.  I had no idea what keys would be okay or not
okay to bind.

This could be solved by instead linking to the Emacs key binding
guidelines and pointing out ranges of keys or example keys that would
be safe to bind. I interpret the current documentation as suggesting
such example keys.

For comparison, calendar.el et al do not suggest global key bindings
for their commands.  However, Org mode is different because it is one
of Emacs’s "killer apps".  It is something that a non-Emacs user would
start using Emacs for.  No one is going to switch to Emacs to use
calendar.el, but there are many people that switch to Emacs to use Org
mode.  Therefore, there is a benefit in adding some tips for very new
users.

As a matter of practicality, I suspect many users are just blindly
copying Emacs Lisp code from various guides online, so there is no
good way to fight de facto standards from emerging.  Projectile is a
particularly blatant offender, a popular package that reserves the C-c
p key for its minor mode.

However, the Emacs documentation is quite clear about key binding
rules.  All built in libraries follow it, including Org mode.  I do
not interpret the Org documentation as implying otherwise.

[O] Bug: subtree archiving when Archive is not final headline yields bad visibility [8.2.10 (release_8.2.10 @ /usr/share/emacs/25.2+gg1+12/lisp/org/)]

[Allen Li]

(Can reproduce with Org 9.1.3, submitting with emacs -Q)

Using a file tmp.org:

  * Foo
  ** Archive :ARCHIVE:
  *** Test
  :PROPERTIES:
  :ARCHIVE_TIME: 2017-12-06 Wed 12:13
  :END:
  ** Bar

This appears like so with default visibility:

  * Foo
  ** Archive :ARCHIVE:...
  ** Bar

Archiving Bar with C-c C-x A yields:

  * Foo
  ** Archive :ARCHIVE:...
  *** Bar...

Expected visibility:

  * Foo
  ** Archive :ARCHIVE:...

Emacs  : GNU Emacs 25.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version
3.22.11), modified by Debian
Package: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/25.2+gg1+12/lisp/org/)

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

On Tue, Dec 5, 2017 at 7:15 AM, Drew Adams  wrote:
>
> That's even worse, IMHO.  And hardly "as neutral as possible".
>
> 
>
> Just one opinion.

Could you summarize how you think the situation could be improved in
one or two sentences?

I think what you are trying to say is, Org mode should make global
key bindings for some commands.

However, this is problematic because there are pretty much no global
keys available that are not reserved for major modes, minor modes, or
the user, and at any rate I don’t think we could justify binding
global keys by default since Org mode is a pretty small application
within Emacs.  calendar.el does not have a global key.  remember.el
does not have a global key.  et cetera.  Org mode is no different.

If we make an Org minor mode, that’s really no better than the user
just binding his own keys vs turning on the minor mode.  Also, the
reserved minor mode keys are not very good (hard to press), and they
can conflict with other minor modes, which is probably undesirable for
Org users.

Is your complaint simply that we suggest a key for the user to bind?

[O] bug#28263: bug#28263: 24.5; Org: `C-c LETTER' keys

[Allen Li]

[O] Bug: org-attach-directory should be safe [9.1.3 (9.1.3-10-gadfbfd-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)]

[Allen Li]

org-attach-directory should be safe to set as a file local or
directory local string.

This allows the user to set a directory local attachment directory for
all Org files in a directory tree recursively.

I do not believe there are any security issues to enable arbitrary Org
files to set org-attach-directory to a string value as the user would
have to explicitly initiate any attach operations.  The most dangerous
thing I can think of is an Org file setting the attachment directory
to the user's home directory and the user running the command to
delete all attachments.

Note that org-attach already allows setting the attachment directory
on a headline basis, this would just allow setting the attachment
directory on a file or directory basis.  It can be argued that the
existing functionality makes it more visible if a malicious Org file
sets a dangerous attachment path (a property on the headline vs a file
local variable or dir-locals file).  org-attach already mentions that
deleting all attachments is potentially dangerous and recommends
deleting through Dired.  Deleting through Dired would make it
impossible for a user to not notice that a malicious Org file has set
the attachment directory to something undesirable.

Emacs  : GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.19)
 of 2017-09-16
Package: Org mode version 9.1.3 (9.1.3-10-gadfbfd-elpaplus @
/home/ionasal/.emacs.d/elpa/org-plus-contrib-20171127/)

[O] Org mode bug submission and viewing?

[Allen Li]

What's the proper way to submit an Org mode bug, and are the bugs
collected anywhere for viewing their status?

I see the mailing list has bugs generated using org-submit-bug-report
(containing "Bug:" in the subject) and other bugs that have numbers
("bug#:" in the subject).

Is there a preferred way to submit bugs?

Where are the numbered bugs coming from?

Is there a place to view submitted bugs and their resolution status?

[O] bug#24791: bug#24791: org-todo-yesterday behaves like plain org-todo (incorrect timestamp)

[Allen Li]

On Fri, Dec 1, 2017 at 1:53 PM, Nicolas Goaziou  wrote:
> Hello,
>
> Jan Böhm  writes:
>
>> Symptoms: both org-todo-yesterday and org-agenda-todo-yesterday behave
>> just like normally setting todo state to "DONE" with org-todo.
>> Specifically, the timestamp
>> added in the log takes the current time instead of 23:59 of the previous
>> day, as would be expected.
>>
>> Replicate behaviour:
>> start emacs -Q
>> set org-log-done to "time"
>> visit new file and switch to org mode
>> create TODO headline and set TODO state to "DONE" by calling
>> "org-todo-yesterday"
>> ⇒ todo state is set to DONE correctly, but the timestamp inserted in
>> the log drawer is the current time.
>
> I cannot reproduce it in a recent Org release. Could you double-check
> with a newer Org?

I am going to blindly wager that this is yet another bug caused by Org
mode's subtle timezone issues.

I can reproduce it (and crucially, I am not in the GMT time zone),
although the repro recipe produces a CLOSED timestamp and not a log
drawer timestamp.

Re: [O] Bug: ordered property blocks grandchildren [9.1.3 (9.1.3-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171116/)]

[Allen Li]

On Mon, Nov 20, 2017 at 5:18 PM, Allen Li <vianchielfa...@gmail.com> wrote:
> Create a file tmp.org with contents
>
> * TODO parent
>   :PROPERTIES:
>   :ORDERED:  t
>   :END:
> ** TODO child1
> ** TODO child2
> *** TODO grandchild1
> *** TODO grandchild2
>
> 1. emacs -Q
> 2. M-: (setq org-enforce-todo-dependencies t) RET
> 3. C-x C-f tmp.org RET
> 4. Move point to grandchild2
> 5. C-c C-t
>
> user-error: TODO state change from TODO to DONE blocked (by "TODO child1")
>
> The documentation emphasizes that ORDERED is not inherited.  The
> behavior that I would expect is that child1 blocks child2, but it should
> not block grandchild1 or grandchild2.
>
> However, I think the current behavior is also reasonable under some
> workflows.  I’m creating a bug to track opinions, if one behavior is
> significantly more desired than the other, or if an option to control
> this behavior would be welcome.

There's an additional quirk to this behavior:

If the child is not a TODO heading, its grandchildren are not blocked


* TODO parent
  :PROPERTIES:
  :ORDERED:  t
  :END:
** TODO child1
** child2
*** TODO grandchild1
*** TODO grandchild2

In this modified example, the grandchildren are not blocked, unlike
the original example.  Again I can see certain workflows relying on
this behavior, but the behavior isn't quite obvious.  The
documentation should probably be improved.  I'd also like to think
about the implications behind this behavior and any alternatives a
little more.