[BUG] org-element-cache-map calls native-comp-available-p without checking if it is bound first [9.5 (9.5-gf5faff @ /home/n/.emacs.d/straight/build/org/)]

2021-10-29 Thread No Wayman



See: 
https://www.reddit.com/r/emacs/comments/qil2qh/symbols_function_definition_is_void/



For context:


(and (symbolp func)
(native-comp-available-p)
(fboundp 'subr-native-elisp-p)


The check could be wrapped in a function to prevent this in the 
future. e.g.


(defun org-native-comp-available-p ()
  (and (fboundp 'native-comp-available-p) 
  (native-comp-available-p)))




Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

2021-10-09 Thread No Wayman



Your analysis is correct. I looked into this a couple days ago.
See the following message for an explanation and a patch (testing 
appreciated):


https://list.orgmode.org/87zgrmc2rg@gmail.com/T/#m9888bc09d77d7bba70ba99671aca72446c4d41b9





Re: [BUG] org-save-all-org-buffers reapplies startup visibility [9.5 (release_9.5 @ /usr/local/share/emacs/29.0.50/lisp/org/)]

2021-10-05 Thread No Wayman

Confirmed with the following, simpler, test case:

Yodel[1] Report 2021-10-05 22:07:33
===

--8<---cut here---start->8---
(yodel
 :user-dir "org-save-all-org-buffers"
 :packages* org
 :formatter yodel-format-as-mailing-list-message
 :post*
 (yodel-file "./test.org"
   :with*
   "#+startup: overview
* A
** B"
   :then*
   (require 'org-element)
   (defun +org-visible nil
 (org-element-interpret-data
  (org-element-parse-buffer nil 'visible-only)))
   (message "%s
%s" "Before `org-save-all-org-buffers':"
(+org-visible))
   (set-buffer-modified-p t)
   (org-save-all-org-buffers)
   (message "%s
%s" "After `org-save-all-org-buffers':"
(+org-visible
--8<---cut here---end--->8---

STDOUT
==

Loading 
/tmp/org-save-all-org-buffers/straight-bootstrap-snippet.el 
(source)...

Before `org-save-all-org-buffers':



#+startup: overview
* A
** B



Saving all Org buffers...



Saving all Org buffers... done
After `org-save-all-org-buffers':



#+startup: overview
* A


Environment
===

- emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, 
 X toolkit, cairo version 1.17.4, Xaw3d scroll bars)

of 2021-09-29
- system type: gnu/linux

Packages


- org 
 https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cc2490a7061955395c4f5a1a23a088044554a2f7


The behavior of `save-some-buffers' PRED argument changed 
recently:


https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a

If the PRED returns a function, that function is called.
Since `derived-mode-p' returns the symbol `org-mode', Org is being 
reloaded in modified buffers.
That's what is causing the visibility change. 
This could also have other undesirable behavior such as running 
the mode hook, resetting buffer-local variables, etc.


The attached patch ensures we're returning a boolean from the PRED 
function.

Tested with:

Yodel[1] Report 2021-10-05 22:07:33
===

--8<---cut here---start->8---
(yodel
 :user-dir "org-save-all-org-buffers.patch"
 :packages*
 (org :host github :repo "progfolio/org-mode" :branch 
 "fix/org-save-all-org-buffers")

 :formatter yodel-format-as-mailing-list-message
 :post*
 (yodel-file "./test.org"
   :with*
   "#+startup: overview
* A
** B"
   :then*
   (require 'org-element)
   (defun +org-visible nil
 (org-element-interpret-data
  (org-element-parse-buffer nil 'visible-only)))
   (message "%s
%s" "Before `org-save-all-org-buffers':"
(+org-visible))
   (set-buffer-modified-p t)
   (org-save-all-org-buffers)
   (message "%s
%s" "After `org-save-all-org-buffers':"
(+org-visible
--8<---cut here---end--->8---

STDOUT
==

Loading 
/tmp/org-save-all-org-buffers.patch/straight-bootstrap-snippet.el 
(source)...

Bootstrapping straight.el...
Bootstrapping straight.el...done
Rebuilding all packages due to build cache schema change
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for emacsmirror-mirror recipe → Cloning 
gnu-elpa-mirror...
Looking for emacsmirror-mirror recipe → Cloning 
gnu-elpa-mirror...done

Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done
Cloning org...
Cloning org...done
Building org...
Building org...done



Before `org-save-all-org-buffers':



#+startup: overview
* A
** B



Saving all Org buffers...



Saving all Org buffers... done
After `org-save-all-org-buffers':



#+startup: overview
* A
** B


Environment
===

- emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, 
 X toolkit, cairo version 1.17.4, Xaw3d scroll bars)

of 2021-09-29
- system type: gnu/linux

Packages


- org 
 https://github.com/progfolio/org-mode/commit/f1fc22f861ca9610ad4f1e1227660712b46337e4



[1] https://www.github.com/progfolio/yodel

>From f1fc22f861ca9610ad4f1e1227660712b46337e4 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 5 Oct 2021 21:07:01 -0400
Subject: [PATCH] lisp/org.el: (org-save-all-org-buffers): Prevent `org-mode'
 reload

* lisp/org.el: (org-save-all-org-buffers): Ensure `save-some-buffers' PRED returns boolean.

As of this upstream commit:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a9ad3d477441feefa3bf6107d58281cb64e0e78a

`save-some-buffers' will call its PRED argument if it returns a function.
Since (derived-mode-p 'org-mode) returns the symbol org-mode,
and org-mode is a function, org-mode is reloaded in modified Org
buffers when calling `org-save-all-org-buffers'. Among other
undesirable behavior, this will cause the buffer's visibility to be
reset to 

[BUG] [PATCH] org-archive.el: Fix checkdoc warnings [9.5 (9.5-g477f05 @ /home/n/.emacs.d/straight/build/org/)]

2021-10-03 Thread No Wayman


See Attached.

>From e995d2ed668edd9f29e9a8aeaf39bb0eb039e856 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-archive.el: Fix checkdoc warnings

* org-archive.el: Fix checkdoc warnings.
---
 lisp/org-archive.el | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 0943869a8..db8c02049 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -148,7 +148,7 @@ archive location, but not yet deleted from the original file.")
 
 ;;;###autoload
 (defun org-add-archive-files (files)
-  "Splice the archive files into the list of files.
+  "Splice the archive files into the list of FILES.
 This implies visiting all these files and finding out what the
 archive file is."
   (org-uniquify
@@ -580,8 +580,9 @@ don't move trees, but mark them with the ARCHIVE tag."
 ;;;###autoload
 (defun org-toggle-archive-tag ( find-done)
   "Toggle the archive tag for the current headline.
-With prefix ARG, check all children of current headline and offer tagging
-the children that do not contain any open TODO items."
+When called interactively with \\[universal-argument], or FIND-DONE is
+non-nil, check current headline's children and offer tagging for
+children which do not contain any open TODO items."
   (interactive "P")
   (if (and (org-region-active-p) org-loop-over-headlines-in-active-region)
   (let ((cl (if (eq org-loop-over-headlines-in-active-region 'start-level)
-- 
2.33.0



[PATCH] org-attach: Fix checkdoc warnings

2021-10-02 Thread No Wayman


See attached.

>From 477f05274d2de75fc6d4761e6e6089f46e024f4e Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-attach.el: Fix checkdoc warnings

* org-attach.el: Fix checkdoc warnings.
---
 lisp/org-attach.el | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 75db69c9c..e62432dca 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -123,8 +123,8 @@ lns   create a symbol link.  Note that this is not supported
 
 Enabling inheritance for `org-attach' implies two things.  First,
 that attachment links will look through all parent headings until
-it finds the linked attachment.  Second, that running org-attach
-inside a node without attachments will make org-attach operate on
+it finds the linked attachment.  Second, that running `org-attach'
+inside a node without attachments will make `org-attach' operate on
 the first parent heading it finds with an attachment.
 
 Selective means to respect the inheritance setting in
@@ -335,7 +335,7 @@ will be invoked to access the directory for the current entry.
 Note that this method returns the directory as declared by ID or
 DIR even if the directory doesn't exist in the filesystem.
 
-If CREATE-IF-NOT-EXIST-P is non-nil, `org-attach-dir-get-create'
+If CREATE-IF-NOT-EXISTS-P is non-nil, `org-attach-dir-get-create'
 is run.  If NO-FS-CHECK is non-nil, the function returns the path
 to the attachment even if it has not yet been initialized in the
 filesystem.
@@ -378,7 +378,7 @@ If the attachment by some reason cannot be created an error will be raised."
 	 ((or (eq org-attach-preferred-new-method 'dir) (eq answer ?2))
 	  (setq attach-dir (org-attach-set-directory)))
 	 ((eq org-attach-preferred-new-method 'nil)
-	  (error "No existing directory. DIR or ID property has to be explicitly created")
+	  (error "No existing directory.  DIR or ID property has to be explicitly created")
 (unless attach-dir
   (error "No attachment directory is associated with the current node"))
 (unless (file-directory-p attach-dir)
@@ -483,6 +483,7 @@ DIR-property exists (that is different from the unset one)."
   (org-attach-tag 'off))
 
 (defun org-attach-url (url)
+  "Attach URL."
   (interactive "MURL of the file to attach: \n")
   (let ((org-attach-method 'url))
 (org-attach-attach url)))
@@ -503,7 +504,7 @@ if it would overwrite an existing filename."
 
 (defun org-attach-attach (file  visit-dir method)
   "Move/copy/link FILE into the attachment directory of the current outline node.
-If VISIT-DIR is non-nil, visit the directory with dired.
+If VISIT-DIR is non-nil, visit the directory with `dired'.
 METHOD may be `cp', `mv', `ln', `lns' or `url' default taken from
 `org-attach-method'."
   (interactive
@@ -574,27 +575,27 @@ The attachment is created as an Emacs buffer."
 (find-file (expand-file-name file attach-dir))
 (message "New attachment %s" file)))
 
-(defun org-attach-delete-one ( file)
-  "Delete a single attachment."
+(defun org-attach-delete-one ( attachment)
+  "Delete a single ATTACHMENT."
   (interactive)
   (let* ((attach-dir (org-attach-dir))
 	 (files (org-attach-file-list attach-dir))
-	 (file (or file
+	 (attachment (or attachment
 		   (completing-read
 		"Delete attachment: "
 		(mapcar (lambda (f)
 			  (list (file-name-nondirectory f)))
 			files)
-(setq file (expand-file-name file attach-dir))
-(unless (file-exists-p file)
-  (error "No such attachment: %s" file))
-(delete-file file)
+(setq attachment (expand-file-name attachment attach-dir))
+(unless (file-exists-p attachment)
+  (error "No such attachment: %s" attachment))
+(delete-file attachment)
 (run-hook-with-args 'org-attach-after-change-hook attach-dir)))
 
 (defun org-attach-delete-all ( force)
   "Delete all attachments from the current outline node.
 This actually deletes the entire attachment directory.
-A safer way is to open the directory in dired and delete from there.
+A safer way is to open the directory in `dired' and delete from there.
 
 With prefix argument FORCE, directory will be recursively deleted
 with no prompts."
@@ -629,12 +630,12 @@ empty attachment directories."
  t))
   (delete-directory attach-dir))
 
-(defun org-attach-file-list (dir)
-  "Return a list of files in the attachment directory.
+(defun org-attach-file-list (directory)
+  "Return a list of files in the attachment DIRECTORY.
 This ignores files ending in \"~\"."
   (delq nil
 	(mapcar (lambda (x) (if (string-match "^\\.\\.?\\'" x) nil x))
-		(directory-files dir nil "[^~]\\'"
+		(directory-files directory nil "[^~]\\'"
 
 (defun org-attach-reveal ()
   "Show the attachment directory of the current outline node.
@@ -645,7 +646,7 @@ exist yet.  Respects `org-attach-preferred-new-method'."
   (org-open-file 

Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

2021-10-02 Thread No Wayman


Bastien  writes:

Thanks -- it does not apply against the main branch, can you 
rebase

and resend it?


Certainly. See attached.

>From 4971ceb26a1fb138f4eeddc1a569b5c4dd3f1859 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-src.el: Fix checkdoc warnings

* org-src.el: Fix checkdoc warnings.
---
 lisp/org-src.el | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 8d02cf434..23e196438 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -37,6 +37,7 @@
 (require 'org-compat)
 (require 'org-keys)
 
+(declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-mode "org" ())
 (declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-element-at-point "org-element" ())
@@ -240,8 +241,7 @@ green, respectability.
   :package-version '(Org . "9.0"))
 
 (defcustom org-src-tab-acts-natively t
-  "If non-nil, the effect of TAB in a code block is as if it were
-issued in the language major mode buffer."
+  "If non-nil, TAB uses the language's major-mode binding in code blocks."
   :type 'boolean
   :package-version '(Org . "9.4")
   :group 'org-babel)
@@ -304,7 +304,8 @@ is 0.")
 (put 'org-src--preserve-blank-line 'permanent-local t)
 
 (defun org-src--construct-edit-buffer-name (org-buffer-name lang)
-  "Construct the buffer name for a source editing buffer."
+  "Construct the buffer name for a source editing buffer.
+Format is \"*Org Src ORG-BUFFER-NAME [ LANG ]*\"."
   (concat "*Org Src " org-buffer-name "[ " lang " ]*"))
 
 (defun org-src--edit-buffer (beg end)
@@ -614,7 +615,7 @@ Leave point in edit buffer."
 ;;; Fontification of source blocks
 
 (defun org-src-font-lock-fontify-block (lang start end)
-  "Fontify code block.
+  "Fontify code block between START and END using LANG's syntax.
 This function is called by Emacs' automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
   (let ((lang-mode (org-src-get-lang-mode lang)))
@@ -760,7 +761,9 @@ See also `org-src-mode-hook'."
 ;;; Babel related functions
 
 (defun org-src-associate-babel-session (info)
-  "Associate edit buffer with comint session."
+  "Associate edit buffer with comint session.
+INFO should be a list simlar in format to the return value of
+`org-babel-get-src-block-info'."
   (interactive)
   (let ((session (cdr (assq :session (nth 2 info)
 (and session (not (string= session "none"))
@@ -770,6 +773,7 @@ See also `org-src-mode-hook'."
(and (fboundp f) (funcall f session))
 
 (defun org-src-babel-configure-edit-buffer ()
+  "Configure src editing buffer."
   (when org-src--babel-info
 (org-src-associate-babel-session org-src--babel-info)))
 
@@ -842,6 +846,7 @@ Raise an error when current buffer is not a source editing buffer."
   org-src--source-type)
 
 (defun org-src-switch-to-buffer (buffer context)
+  "Switch to BUFFER considering CONTEXT and `org-src-window-setup'."
   (pcase org-src-window-setup
 (`plain
  (when (eq context 'exit) (quit-restore-window))
@@ -1204,11 +1209,12 @@ the area in the Org mode buffer."
   (interactive)
   (let (org-src--allow-write-back) (org-edit-src-exit)))
 
-(defun org-edit-src-continue (e)
+(defun org-edit-src-continue (event)
   "Unconditionally return to buffer editing area under point.
-Throw an error if there is no such buffer."
+Throw an error if there is no such buffer.
+EVENT is passed to `mouse-set-point'."
   (interactive "e")
-  (mouse-set-point e)
+  (mouse-set-point event)
   (let ((buf (get-char-property (point) 'edit-buffer)))
 (if buf (org-src-switch-to-buffer buf 'continue)
   (user-error "No sub-editing buffer for area at point"
-- 
2.33.0



Re: [BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

2021-10-02 Thread No Wayman


Bastien  writes:


Hi,

No Wayman  writes:


The attached patch


I don't see a patch, can you resend it?


Apologies. Resent.

>From e5d1c6cc231363e20b378e082236af44ac717ccc Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 16:07:15 -0400
Subject: [PATCH] org-src.el: Fix checkdoc warnings

* org-src.el: Fix checkdoc warnings.
---
 lisp/org-src.el | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lisp/org-src.el b/lisp/org-src.el
index 0e16e236b..8f1e68d90 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -37,6 +37,7 @@
 (require 'org-compat)
 (require 'org-keys)
 
+(declare-function org--get-expected-indentation "org" (element contentsp))
 (declare-function org-mode "org" ())
 (declare-function org-element-at-point "org-element" ())
 (declare-function org-element-class "org-element" (datum  parent))
@@ -239,8 +240,7 @@ green, respectability.
   :package-version '(Org . "9.0"))
 
 (defcustom org-src-tab-acts-natively t
-  "If non-nil, the effect of TAB in a code block is as if it were
-issued in the language major mode buffer."
+  "If non-nil, TAB uses the language's major-mode binding in code blocks."
   :type 'boolean
   :package-version '(Org . "9.4")
   :group 'org-babel)
@@ -303,7 +303,8 @@ is 0.")
 (put 'org-src--preserve-blank-line 'permanent-local t)
 
 (defun org-src--construct-edit-buffer-name (org-buffer-name lang)
-  "Construct the buffer name for a source editing buffer."
+  "Construct the buffer name for a source editing buffer.
+Format is \"*Org Src ORG-BUFFER-NAME [ LANG ]*\"."
   (concat "*Org Src " org-buffer-name "[ " lang " ]*"))
 
 (defun org-src--edit-buffer (beg end)
@@ -613,7 +614,7 @@ Leave point in edit buffer."
 ;;; Fontification of source blocks
 
 (defun org-src-font-lock-fontify-block (lang start end)
-  "Fontify code block.
+  "Fontify code block between START and END using LANG's syntax.
 This function is called by Emacs' automatic fontification, as long
 as `org-src-fontify-natively' is non-nil."
   (let ((lang-mode (org-src-get-lang-mode lang)))
@@ -759,7 +760,9 @@ See also `org-src-mode-hook'."
 ;;; Babel related functions
 
 (defun org-src-associate-babel-session (info)
-  "Associate edit buffer with comint session."
+  "Associate edit buffer with comint session.
+INFO should be a list simlar in format to the return value of
+`org-babel-get-src-block-info'."
   (interactive)
   (let ((session (cdr (assq :session (nth 2 info)
 (and session (not (string= session "none"))
@@ -769,6 +772,7 @@ See also `org-src-mode-hook'."
(and (fboundp f) (funcall f session))
 
 (defun org-src-babel-configure-edit-buffer ()
+  "Configure src editing buffer."
   (when org-src--babel-info
 (org-src-associate-babel-session org-src--babel-info)))
 
@@ -841,6 +845,7 @@ Raise an error when current buffer is not a source editing buffer."
   org-src--source-type)
 
 (defun org-src-switch-to-buffer (buffer context)
+  "Switch to BUFFER considering CONTEXT and `org-src-window-setup'."
   (pcase org-src-window-setup
 (`plain
  (when (eq context 'exit) (quit-restore-window))
@@ -1203,11 +1208,12 @@ the area in the Org mode buffer."
   (interactive)
   (let (org-src--allow-write-back) (org-edit-src-exit)))
 
-(defun org-edit-src-continue (e)
+(defun org-edit-src-continue (event)
   "Unconditionally return to buffer editing area under point.
-Throw an error if there is no such buffer."
+Throw an error if there is no such buffer.
+EVENT is passed to `mouse-set-point'."
   (interactive "e")
-  (mouse-set-point e)
+  (mouse-set-point event)
   (let ((buf (get-char-property (point) 'edit-buffer)))
 (if buf (org-src-switch-to-buffer buf 'continue)
   (user-error "No sub-editing buffer for area at point"
-- 
2.33.0



Re: Visibility cycling with inline tasks 2

2021-10-01 Thread No Wayman



Ihor Radchenko  writes:

Your patch will fail with the following counterexample (when 
there is a

subheading containing an inlinetask inside current heading):


I wasn't really sure what the intended behavior is, but that makes 
sense.



I propose an alternative patch. See the attached.


Haven't installed it, but at a glance it stands to reason.



Re: Visibility cycling with inline tasks 2

2021-09-30 Thread No Wayman


I can confirm the issue you've outlined on latest 'main'.
To me it looks like the problem is in `org-inline-hide-tasks'.
I don't use inline tasks, so I'm not sure what the exact expected 
behavior is,
but that function uses a `while' during `org-cycle-hook' to 
iterate through all of the headings.
My intuition is that it's overshooting a boundary and toggling 
visibility on more than it should.


Does the attached patch behave more in line with what you expect? 

>From 04ed84c36a4cc04838b5b75e18858996af125f77 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 30 Sep 2021 23:31:50 -0400
Subject: [PATCH] org-inlinetask.el: Limit children visibility toggle to
 subtree

* org-inlinetask: (org-inlinetask-toggle-visibility): Limit toggling
to subtree.

Not sure if this is correct behavior or not. Just a suggestion.
---
 lisp/org-inlinetask.el | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el
index 3379a2e46..3bdc03ae4 100644
--- a/lisp/org-inlinetask.el
+++ b/lisp/org-inlinetask.el
@@ -334,11 +334,13 @@ This function is meant to be used in `org-cycle-hook'."
 	   (org-inlinetask-goto-end)
 (`children
  (save-excursion
-   (while
-	   (or (org-inlinetask-at-task-p)
-	   (and (outline-next-heading) (org-inlinetask-at-task-p)))
-	 (org-inlinetask-toggle-visibility)
-	 (org-inlinetask-goto-end))
+   (save-restriction
+ (org-narrow-to-subtree)
+ (while
+ (or (org-inlinetask-at-task-p)
+ (and (outline-next-heading) (org-inlinetask-at-task-p)))
+   (org-inlinetask-toggle-visibility)
+   (org-inlinetask-goto-end)))
 
 (defun org-inlinetask-remove-END-maybe ()
   "Remove an END line when present."
-- 
2.33.0



[BUG] [PATCH] org-src.el: Fix checkdoc warnings [9.5 (9.5-g59cb39 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-30 Thread No Wayman



The attached patch addresses org-src.el's checkdoc warnings spare 
the following (IMO spurious) warnings:


 >158 0 notee-f-cLisp symbol ‘split-window-below’ 
 >should appear in quotes


split-window-below is a value used in org-src-window-setup (along 
with split-window-right, other-window, other-frame), but these 
values do not necessarily map onto their functions. e.g. 
other-window displays via `switch-to-buffer-other-window'.


 >80050  notee-f-cKeycode C-c embedded in doc string. 
 >Use \\ & \\[function] instead


The embedded keycodes in `org-src-do-key-sequence-at-code-block' 
are just for the sake of example.




[BUG] [PATCH] org-id: Fix checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-28 Thread No Wayman


See attached.

>From 7fbdca5dc81dfe0dd542ed0e2352d3334b16fd7f Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 27 Sep 2021 20:35:12 -0400
Subject: [PATCH] org-id: Fix checkdoc warnings

* org-id: Fix checkdoc warnings.
---
 lisp/org-id.el | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/lisp/org-id.el b/lisp/org-id.el
index 3725ff9e5..56783d108 100644
--- a/lisp/org-id.el
+++ b/lisp/org-id.el
@@ -419,15 +419,15 @@ So a typical ID could look like \"Org:4nd91V40HI\"."
 	(substring rnd 18 20)
 	(substring rnd 20 32
 
-(defun org-id-int-to-b36-one-digit (i)
-  "Turn an integer between 0 and 61 into a single character 0..9, A..Z, a..z."
+(defun org-id-int-to-b36-one-digit (integer)
+  "Convert INTEGER between 0 and 61 into a single character 0..9, A..Z, a..z."
   (cond
-   ((< i 10) (+ ?0 i))
-   ((< i 36) (+ ?a i -10))
+   ((< integer 10) (+ ?0 integer))
+   ((< integer 36) (+ ?a integer -10))
(t (error "Larger that 35"
 
 (defun org-id-b36-to-int-one-digit (i)
-  "Turn a character 0..9, A..Z, a..z into a number 0..61.
+  "Convert character 0..9, A..Z, a..z into a number 0..61.
 The input I may be a character, or a single-letter string."
   (and (stringp i) (setq i (string-to-char i)))
   (cond
@@ -435,9 +435,11 @@ The input I may be a character, or a single-letter string."
((and (>= i ?a) (<= i ?z)) (+ (- i ?a) 10))
(t (error "Invalid b36 letter"
 
-(defun org-id-int-to-b36 (i  length)
-  "Convert an integer to a base-36 number represented as a string."
-  (let ((s ""))
+(defun org-id-int-to-b36 (integer  length)
+  "Convert an INTEGER to a base-36 number represented as a string.
+The returned string is padded with leading zeros to LENGTH if necessary."
+  (let ((s "")
+(i integer))
 (while (> i 0)
   (setq s (concat (char-to-string
 		   (org-id-int-to-b36-one-digit (mod i 36))) s)
@@ -447,11 +449,11 @@ The input I may be a character, or a single-letter string."
 	(setq s (concat (make-string (- length (length s)) ?0) s)))
 s))
 
-(defun org-id-b36-to-int (s)
-  "Convert a base-36 string into the corresponding integer."
+(defun org-id-b36-to-int (string)
+  "Convert a base-36 STRING into the corresponding integer."
   (let ((r 0))
 (mapc (lambda (i) (setq r (+ (* r 36) (org-id-b36-to-int-one-digit i
-	  s)
+	  string)
 r))
 
 (defun org-id-time-to-b36 ( time)
@@ -489,7 +491,8 @@ and TIME is a Lisp time value (HI LO USEC)."
 Store the relation between files and corresponding IDs.
 This will scan all agenda files, all associated archives, and all
 files currently mentioned in `org-id-locations'.
-When FILES is given, scan also these files."
+When FILES is given, scan also these files.
+If SILENT is non-nil, messages are suppressed."
   (interactive)
   (unless org-id-track-globally
 (error "Please turn on `org-id-track-globally' if you want to track IDs"))
@@ -610,7 +613,7 @@ When FILES is given, scan also these files."
   (add-hook 'kill-emacs-hook 'org-id-locations-save))
 
 (defun org-id-hash-to-alist (hash)
-  "Turn an org-id hash into an alist.
+  "Turn an org-id HASH into an alist.
 This is to be able to write it to a file."
   (let (res x)
 (maphash
@@ -622,7 +625,7 @@ This is to be able to write it to a file."
 res))
 
 (defun org-id-alist-to-hash (list)
-  "Turn an org-id location list into a hash table."
+  "Turn an org-id location LIST into a hash table."
   (let ((res (make-hash-table
 	  :test 'equal
 	  :size (apply '+ (mapcar 'length list
-- 
2.33.0



[PATCH] Fix org-capture checkdoc warnings [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-27 Thread No Wayman


The attached patch addresses most of the checkdoc warnings for 
org-capture.

There are two remaining warnings (both the same):

Disambiguate org-capture-mode by preceding w/ 
function,command,variable,option or symbol.


I did not address these because checkdoc has recently been fixed 
to stop asking for disambiguation of mode names:


http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=79a9b50621ec22640358bd6b94b65d14d747c644

>From 7f2e0e0a8735dbc2f4e79f17400471585e14d193 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 27 Sep 2021 20:35:12 -0400
Subject: [PATCH] org-capture: Fix checkdoc warnings

* org-capture: Fix checkdoc warnings.
---
 lisp/org-capture.el | 71 +
 1 file changed, 39 insertions(+), 32 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index cbdb30c03..15c62e14f 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -306,13 +306,15 @@ be replaced with content and expanded:
   current template.
   %(sexp) Evaluate elisp `(sexp)' and replace it with the results.
   Only placeholders pre-existing within the template, or
-  introduced with %[pathname] are expanded this way.  Since this
-  happens after expanding non-interactive %-escapes, those can
-  be used to fill the expression.
-  %<...>  The result of format-time-string on the ... format specification.
-  %t  Time stamp, date only.  The time stamp is the current time,
-  except when called from agendas with `\\[org-agenda-capture]' or
-  with `org-capture-use-agenda-date' set.
+  introduced with %[pathname] are expanded this way.
+  Since this happens after expanding non-interactive
+  %-escapes, those can be used to fill the expression.
+  %<...>  The result of `format-time-string' on the ... format
+  specification.
+  %t  Time stamp, date only.  The time stamp is the current
+  time, except when called from agendas with
+  `\\[org-agenda-capture]' or 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
@@ -328,7 +330,7 @@ be replaced with content and expanded:
   %k  Title of currently clocked task.
   %K  Link to currently clocked task.
   %n  User name (taken from the variable `user-full-name').
-  %f  File visited by current buffer when org-capture was called.
+  %f  File visited by current buffer when `org-capture' was called.
   %F  Full path of the file or directory visited by current buffer.
   %:keyword   Specific information for certain link types, see below.
   %^g Prompt for tags, with completion on tags in target file.
@@ -497,17 +499,17 @@ is copied to this variable, which is local in the indirect buffer.")
   "Local variable to store the value of the :clock-keep parameter.
 This is needed in case `org-capture-finalize' is called interactively.")
 
-(defun org-capture-put ( stuff)
-  "Add properties to the capture property list `org-capture-plist'."
-  (while stuff
+(defun org-capture-put ( elements)
+  "Add ELEMENTS to the capture property list `org-capture-plist'."
+  (while elements
 (setq org-capture-plist (plist-put org-capture-plist
-   (pop stuff) (pop stuff)
-(defun org-capture-get (prop  local)
-  "Get properties from the capture property list `org-capture-plist'.
+   (pop elements) (pop elements)
+(defun org-capture-get (property  local)
+  "Get PROPERTY from the capture property list `org-capture-plist'.
 When LOCAL is set, use the local variable `org-capture-current-plist',
 this is necessary after initialization of the capture process,
 to avoid conflicts with other active capture processes."
-  (plist-get (if local org-capture-current-plist org-capture-plist) prop))
+  (plist-get (if local org-capture-current-plist org-capture-plist) property))
 
 ;;; The minor mode
 
@@ -1119,7 +1121,7 @@ FILE is a generalized file location, as handled by
 
 (defun org-capture-place-template ( inhibit-wconf-store)
   "Insert the template at the target location, and display the buffer.
-When `inhibit-wconf-store', don't store the window configuration, as it
+When INHIBIT-WCONF-STORE is non-nil, don't store the window configuration, as it
 may have been stored before."
   (unless inhibit-wconf-store
 (org-capture-put :return-to-wconf (current-window-configuration)))
@@ -1414,21 +1416,21 @@ Of course, if exact position has been required, just put it there."
 	(org-capture--position-cursor beg end)
 
 (defun org-capture-mark-kill-region (beg end)
-  "Mark the region that will have to be killed when aborting capture."
+  "Mark region between BEG and END to be killed on aborted capture."
   

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

2021-09-27 Thread No Wayman



Bastien  writes:


Hi,

No Wayman  writes:

Instead of a defvar that we don't want the user to modify, why 
not

hardcoding the addition of the coma?  I'd prefer this.


`completing-read-multiple' is currently used in two spots to read 
tags:

`org-set-tags-command' and `org-capture-fill-template'.
To be clear, you would rather I hard code the same regexp and 
comment in those two locations rather than abstracting it into a 
defconst?


Any place in the manual that refers to tag separators, 
explicitly or
implicitly, I've not checked if there are some.  Also in the 
code

itself, as a comment, to explain why both "," and ":" should be
allowed


I don't see why we need to add anything to the manual.
We're not changing the syntax of tags.
We're utilizing the normal behavior of completing-read-multiple.
The manual states for `org-set-tags-command':

"By default Org mode uses the standard minibuffer completion 
facilities for entering tags."


The comma is standard when reading multiple items.
That seems to cover it to me.

Another solution I proposed was indicating the delimiters in the 
minibuffer prompt similar to what is currently done in 
`org-todo-list'.

e.g.

org-todo-list prompt:"Keyword (or KWD1|KWD2|...): "
org-set-tags-command prompt: "Tags ("," or ":" to delimit): "

The only argument I heard against that was from one person who 
thought it "wasted space".
I don't consider that a strong argument considering the length of 
the prompt for `org-todo-list'.



(avoid the keyboard-based argument, which is too subjective.)


If one can customize their keyboard layout, I don't see why we 
should be so rigid about a delimiter in a prompt.
It's a moot point, though, I've abandoned that proposal because it 
was apparently too controversial.







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

2021-09-27 Thread No Wayman



Bastien  writes:


Hi,

No Wayman  writes:


* org.el (org-tags-crm-separators): Defcustom controlling which
characters are used to delimit tags in commands which utilize
`completing-read-multiple'.


Why should we allow anything else than ":" for separating tags 
in

commands which utilize completing-read-multiple?

I surely miss something obvious.


The patch you are viewing is outdated.
This is the latest patch on offer:

https://list.orgmode.org/87bl4rce4j@gmail.com/2-0001-Allow-to-delimit-tags.patch

It allows "," (the default for completing-read-multiple) and ":" 
to delimit tags when completing-read-multiple is used.
The reason for allowing "," is that it's easier to type than ":". 
I make liberal use of tags and IMO typing a "Shift+;" between each 
tag is annoying and slow.
The comma is also used as the default separator when 
completing-read-multiple is used.


If we relax a constraint, I'd rather have this hardcoded and 
well

documented than adding a new defvar or defcustom.


The latest patch removed the defcustom and replaced it with a 
defvar for the crm-separator regexp.
If it would ease your mind I'd be happy to convert it to a 
defconst.
It's also worth noting that the constraint was only recently 
introduced.
"," worked fine to delimit tags in `org-set-tags-command' prior to 
the switch to completing-read-multiple.


Regarding documentation, let me know where you'd prefer it 
documented. 



[BUG] 502/slow response from new repo [9.5 (9.5-g9364b2 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-26 Thread No Wayman



Experiencing 502 errors and delay when trying to clone the new 
development repo:


time git clone https://git.savannah.gnu.org/git/emacs/org-mode.git
Cloning into 'org-mode'...
remote: Counting objects: 129920, done.
remote: Compressing objects: 100% (28292/28292), done.
remote: Total 129920 (delta 101703), reused 129609 (delta 101488)
Receiving objects: 100% (129920/129920), 81.43 MiB | 10.35 MiB/s, 
done.

Resolving deltas: 100% (101703/101703), done.

real1m59.019s
user0m27.884s
sys 0m0.955s

That was after multiple attempts which resulted in 502 errors.

For comparison:
time git clone -b master git://git.sv.gnu.org/emacs.git
Cloning into 'emacs'...
remote: Counting objects: 950806, done.
remote: Compressing objects: 100% (167880/167880), done.
remote: Total 950806 (delta 782727), reused 949614 (delta 781638)
Receiving objects: 100% (950806/950806), 318.40 MiB | 31.17 MiB/s, 
done.

Resolving deltas: 100% (782727/782727), done.

real1m37.033s
user2m56.213s
sys 0m2.527s

Just a heads up.



Re: [PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-25 Thread No Wayman


Bastien  writes:

That's not just org-attach.el, right?  The patch does not apply 
either in the bugfix or in the main branch.  Could you resend 
it,

also wrapping the body of the ChangeLog at <80 lines?  M-x
change-log-mode RET can help.  TIA!


Sorry. Didn't realize the first patch had already been committed, 
so I rolled the change into that.

Separated the org-attach patch. See attached.

>From c5b77469c2fbff5d9fd25fcf9025b8a354406256 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sat, 25 Sep 2021 15:05:08 -0400
Subject: [PATCH] org-attach: Fix byte-comp function warning

* (org-attach.el): Declare function for byte compiler.
---
 lisp/org-attach.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 162a01e5e..c2d71514c 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -40,6 +40,7 @@
 (require 'org-id)
 
 (declare-function dired-dwim-target-directory "dired-aux")
+(declare-function dired-get-marked-files "dired" ( localp arg filter distinguish-one-marked error))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-type "org-element" (element))
 (declare-function org-inlinetask-goto-beginning "org-inlinetask" ())
-- 
2.33.0



Re: [PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-25 Thread No Wayman


No Wayman  writes:

And one more in org-attach.el.
See attached.

>From 21620549a24703697d65c46bc88258cd4b2aaa80 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sat, 25 Sep 2021 15:05:08 -0400
Subject: [PATCH] Fix byte-comp function warnings

* (org.el, org-attach.el, org-keys.el, org-table.el): Declare functions for byte compiler.
---
 lisp/org-attach.el | 1 +
 lisp/org-keys.el   | 3 ++-
 lisp/org-table.el  | 1 +
 lisp/org.el| 5 +
 4 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 162a01e5e..c2d71514c 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -40,6 +40,7 @@
 (require 'org-id)
 
 (declare-function dired-dwim-target-directory "dired-aux")
+(declare-function dired-get-marked-files "dired" ( localp arg filter distinguish-one-marked error))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-type "org-element" (element))
 (declare-function org-inlinetask-goto-beginning "org-inlinetask" ())
diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 8f25bda2e..2984a4f51 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -58,7 +58,6 @@
 (declare-function org-clone-subtree-with-time-shift "org" (n  shift))
 (declare-function org-columns "org" ( global columns-fmt-string))
 (declare-function org-comment-dwim "org" (arg))
-(declare-function org-refile-copy "org" ())
 (declare-function org-copy-special "org" ())
 (declare-function org-copy-visible "org" (beg end))
 (declare-function org-ctrl-c-ctrl-c "org" ( arg))
@@ -145,6 +144,8 @@
 (declare-function org-promote-subtree "org" ())
 (declare-function org-redisplay-inline-images "org" ())
 (declare-function org-refile "org" ( arg1 default-buffer rfloc msg))
+(declare-function org-refile-copy "org" ())
+(declare-function org-refile-reverse "org-refile" ( arg default-buffer rfloc msg))
 (declare-function org-reftex-citation "org" ())
 (declare-function org-reload "org" ( arg1))
 (declare-function org-remove-file "org" ( file))
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 0bc668757..9a703d8bc 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -66,6 +66,7 @@
 (declare-function org-export-install-filters "ox" (info))
 (declare-function org-export-table-has-special-column-p "ox" (table))
 (declare-function org-export-table-row-is-special-p "ox" (table-row info))
+(declare-function org-forward-paragraph "org" ( arg))
 (declare-function org-id-find "org-id" (id  markerp))
 (declare-function org-indent-line "org" ())
 (declare-function org-load-modules-maybe "org" ( force))
diff --git a/lisp/org.el b/lisp/org.el
index e1780cf8d..630bfb19d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -158,13 +158,18 @@ Stars are put in group 1 and the trimmed body in group 2.")
 (declare-function org-element-context "org-element" ( element))
 (declare-function org-element-copy "org-element" (datum))
 (declare-function org-element-create "org-element" (type  props  children))
+(declare-function org-element-extract-element "org-element" (element))
+(declare-function org-element-insert-before "org-element" (element location))
 (declare-function org-element-interpret-data "org-element" (data))
 (declare-function org-element-lineage "org-element" (blob  types with-self))
 (declare-function org-element-link-parser "org-element" ())
+(declare-function org-element-map "org-element" (data types fun  info first-match no-recursion with-affiliated))
 (declare-function org-element-nested-p "org-element" (elem-a elem-b))
 (declare-function org-element-parse-buffer "org-element" ( granularity visible-only))
+(declare-function org-element-parse-secondary-string "org-element" (string restriction  parent))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-put-property "org-element" (element property value))
+(declare-function org-element-restriction "org-element" (element))
 (declare-function org-element-swap-A-B "org-element" (elem-a elem-b))
 (declare-function org-element-timestamp-parser "org-element" ())
 (declare-function org-element-type "org-element" (element))
-- 
2.33.0



[PATCH] Declare functions for byte compiler [9.5 (9.5-g769a55 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-25 Thread No Wayman


Recent changes have introduced byte-comp warnings for unknown 
functions at compile time.
These warnings are "louder" now that more users are native 
compiling Elisp, so one more reason to avoid them.


See attached patch.

>From 736e72b56b10ba451016e4cc07305d8065c02ac9 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sat, 25 Sep 2021 15:05:08 -0400
Subject: [PATCH] Fix byte-comp function warnings

* (org.el, org-table.el org-keys.el) Declare functions for byte compiler.
---
 lisp/org-keys.el  | 3 ++-
 lisp/org-table.el | 1 +
 lisp/org.el   | 5 +
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/org-keys.el b/lisp/org-keys.el
index 8f25bda2e..2984a4f51 100644
--- a/lisp/org-keys.el
+++ b/lisp/org-keys.el
@@ -58,7 +58,6 @@
 (declare-function org-clone-subtree-with-time-shift "org" (n  shift))
 (declare-function org-columns "org" ( global columns-fmt-string))
 (declare-function org-comment-dwim "org" (arg))
-(declare-function org-refile-copy "org" ())
 (declare-function org-copy-special "org" ())
 (declare-function org-copy-visible "org" (beg end))
 (declare-function org-ctrl-c-ctrl-c "org" ( arg))
@@ -145,6 +144,8 @@
 (declare-function org-promote-subtree "org" ())
 (declare-function org-redisplay-inline-images "org" ())
 (declare-function org-refile "org" ( arg1 default-buffer rfloc msg))
+(declare-function org-refile-copy "org" ())
+(declare-function org-refile-reverse "org-refile" ( arg default-buffer rfloc msg))
 (declare-function org-reftex-citation "org" ())
 (declare-function org-reload "org" ( arg1))
 (declare-function org-remove-file "org" ( file))
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 0bc668757..9a703d8bc 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -66,6 +66,7 @@
 (declare-function org-export-install-filters "ox" (info))
 (declare-function org-export-table-has-special-column-p "ox" (table))
 (declare-function org-export-table-row-is-special-p "ox" (table-row info))
+(declare-function org-forward-paragraph "org" ( arg))
 (declare-function org-id-find "org-id" (id  markerp))
 (declare-function org-indent-line "org" ())
 (declare-function org-load-modules-maybe "org" ( force))
diff --git a/lisp/org.el b/lisp/org.el
index e1780cf8d..630bfb19d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -158,13 +158,18 @@ Stars are put in group 1 and the trimmed body in group 2.")
 (declare-function org-element-context "org-element" ( element))
 (declare-function org-element-copy "org-element" (datum))
 (declare-function org-element-create "org-element" (type  props  children))
+(declare-function org-element-extract-element "org-element" (element))
+(declare-function org-element-insert-before "org-element" (element location))
 (declare-function org-element-interpret-data "org-element" (data))
 (declare-function org-element-lineage "org-element" (blob  types with-self))
 (declare-function org-element-link-parser "org-element" ())
+(declare-function org-element-map "org-element" (data types fun  info first-match no-recursion with-affiliated))
 (declare-function org-element-nested-p "org-element" (elem-a elem-b))
 (declare-function org-element-parse-buffer "org-element" ( granularity visible-only))
+(declare-function org-element-parse-secondary-string "org-element" (string restriction  parent))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-put-property "org-element" (element property value))
+(declare-function org-element-restriction "org-element" (element))
 (declare-function org-element-swap-A-B "org-element" (elem-a elem-b))
 (declare-function org-element-timestamp-parser "org-element" ())
 (declare-function org-element-type "org-element" (element))
-- 
2.33.0



Re: Switching to new Git repositories

2021-09-23 Thread No Wayman


Kyle Meyer  writes:


On 09/23/21 17:17:48 -0400, No Wayman wrote:


It looks like you've unintentionally added a ')' to the end of 
the

GITVERSION line.


Apologies. Must've been a stray.


Another approach would be to update org.el's version to contain
something that still signals "-dev" but won't trigger the 
"Invalid
version syntax" (which, based on grepping the Emacs repo, is 
signaled by
version-to-list).  But given that in the current setup a clone 
with tags
wouldn't use the header version, stripping -dev for consistency 
sounds

like the way to go.


I agree we should keep it simple and consistent.

Out of curiosity I ran this against the repo to see if the 
"Version" metadata had always followed its current convention:


git grep "Version:" $(git rev-list --all) -- lisp/org.el

Looks like the "-dev" suffix goes back to "9.4-dev" and before 
that we have "8.4-git" and "6.08-pre01".
I'm not sure what Org's convention is here, but the patsubst could 
be adjusted to be more flexible if necessary.


I tried to be more concrete with the commit message.
See attached.

>From 164029cb66eed8d47d7eb69d449660964749195d Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 23 Sep 2021 17:13:34 -0400
Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos

* mk/targets.mk (ORGVERSION, GITVERSION): trim "-dev" suffix from ORGVERSION.

61336f80 uses org.el's Version metadata to generate ORGVERSION when
the source repository has no tags.
This can result in an org-version of "Major.Minor-dev".
The "-dev" suffix is not recognized by `version-to-list' as a valid
version syntax because it is not part of `version-regexp-alist'.
---
 mk/targets.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 693e3781f..ee6f3f344 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -15,8 +15,8 @@ ifneq ($(wildcard .git),)
   ifeq ($(ORGVERSION),)
 # In elpa.git, there are no tags available.  Fall back to using
 # the org.el header.
-ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \
-  --visit lisp/org.el --eval '(princ (lm-header "version"))')
+ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
+  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
 GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
   else
 GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
-- 
2.33.0



Re: Switching to new Git repositories

2021-09-23 Thread No Wayman
Sounds like a weird issue.  I don't think this 9.5-dev tag is 
something from the Org repo.


There is a bug in mk/targets.mk introduced by 61336f80dc.
As others have pointed out, the new repository does not have tags.
As a fallback, org.el's version is read in it's header.
However, it looks like Kyle forgot to trim that string so we get 
ORGVERSION set to "9.5-dev" instead of "9.5".

This causes `org-version' to return an incorrect version string.

The attached patch addresses the issue in the makefile.

>From 9b81f396e69af146faceb13f5602fb6aa06a84e0 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 23 Sep 2021 17:13:34 -0400
Subject: [PATCH] mk/targets.mk: Fix ORGVERSION in tag-less repos

* mk/targets.mk (ORGVERSION, GITVERSION): properly generate ORGVERSION.

Fix bug introduced 61336f80 which caused ORGVERSION to be generated as
"Major.Minor-dev" instead of "Major.Minor" in tag-less repos.
---
 mk/targets.mk | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mk/targets.mk b/mk/targets.mk
index 693e3781f..35383f173 100644
--- a/mk/targets.mk
+++ b/mk/targets.mk
@@ -15,9 +15,9 @@ ifneq ($(wildcard .git),)
   ifeq ($(ORGVERSION),)
 # In elpa.git, there are no tags available.  Fall back to using
 # the org.el header.
-ORGVERSION := $(shell $(BATCH) --eval "(require 'lisp-mnt)" \
-  --visit lisp/org.el --eval '(princ (lm-header "version"))')
-GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD)
+ORGVERSION := $(patsubst %-dev,%,$(shell $(BATCH) --eval "(require 'lisp-mnt)" \
+  --visit lisp/org.el --eval '(princ (lm-header "version"))'))
+GITVERSION ?= $(ORGVERSION)-g$(shell git rev-parse --short=6 HEAD))
   else
 GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD)
   endif
-- 
2.33.0



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

2021-09-17 Thread No Wayman


Tim, Allen:

The attached compromise implements the bare minimum.
Tags can be separated with "," or ":" in the previously mentioned 
cases.

Scrapped the defcustom and showing delimiters in the prompt.
Any objections?

>From 31fbfca4884083adacd95054155cda9ed0128fba Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 3 Sep 2021 14:50:48 -0400
Subject: [PATCH] Allow "," to delimit tags

* org.el: Add `org-tags-crm-separtor' regexp
(org-set-tags-command, org-capture-fill-template): Use `org-tags-crm-separators'.
---
 lisp/org-capture.el | 2 +-
 lisp/org.el | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index cbdb30c03..cd65f8e6d 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1739,7 +1739,7 @@ The template may still contain \"%?\" for cursor positioning."
 			(org-add-colon-after-tag-completion t)
 			(ins (mapconcat
   #'identity
-  (let ((crm-separator "[ \t]*:[ \t]*"))
+  (let ((crm-separator org-tags-crm-separator))
 (completing-read-multiple
  (if prompt (concat prompt ": ") "Tags: ")
  org-last-tags-completion-table nil nil nil
diff --git a/lisp/org.el b/lisp/org.el
index 8b9d57157..572e291c7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12007,6 +12007,9 @@ tags."
 	;; it now points to BLANK-START.  Use COLUMN instead.
 	(if in-blank? (org-move-to-column column) (goto-char origin))
 
+(defvar org-tags-crm-separator (format "[ \t]*%s[ \t]*" (regexp-opt '("," ":")))
+  "Regexp to separate tags in commands which use `completing-read-multiple'.")
+
 (defun org-set-tags-command ( arg)
   "Set the tags for the current visible entry.
 
@@ -12066,7 +12069,7 @@ in Lisp code use `org-set-tags' instead."
 		  table
 		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
 		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
- (crm-separator "[ \t]*:[ \t]*"))
+ (crm-separator org-tags-crm-separator))
 		 (mapconcat #'identity
 (completing-read-multiple
 			 "Tags: "
-- 
2.33.0



Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-10 Thread No Wayman



No Wayman  writes:


The third case I outlined.
Tangling a :lexical t src block sults in a dynamically scoped 
file unless the

user manually inserts the file-local variable line.


*results

That's adjacent to the issue I originally raised, but we could do 
better in that case.





Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-10 Thread No Wayman



Timothy  writes:


Hi NoWayman,


I ran into this with some code I’m writing which checks against
`lexical-binding’.
Should the following result in “lexical binding enabled” or
“lexical binding disabled”?:


Can you think of any examples where this results in different 
behaviour (without

explicitly checking `lexical-binding')?

All the best,
Timothy



The third case I outlined.
Tangling a :lexical t src block sults in a dynamically scoped file 
unless the user manually inserts the file-local variable line.





Re: [BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-09 Thread No Wayman



My thoughts on this would be that if lexical-bindings is 
supposed to be
bound to t, it should be done by eval when it gets a non-nil 
value for
it's optional argument. If I execute (eval FORM t) in an emacs 
lisp
buffer, it looks like lexical-bind is not set either, so I don't 
think
it should be in org either. To set it means we could get the 
same code
behaving differently depending on whether the source block is 
'tangled'
and then evaluated or evaluated within org, which doesn't feel 
right.
 

I agree that we should avoid inconsistency. However it is already 
present.

You can verify this with the following src block:

#+begin_src emacs-lisp :lexical t :tangle ./dynamic.el :results 
verbatim

(symbol-value lexical-binding)
#+end_src

1. `org-babel-execute-src-block' with point in the src block => 
nil (lexical binding enabled)
2. `org-edit-special' with point in the src block, 
`eval-last-sexp' within *Org Src* buffer => t (lexical binding 
enabled)
3. Tangle to the block to "dynamic.el", `eval-last-sexp' within 
"dynamic.el" => nil (dynamic binding)


Might be worth asking on emacs-devel why (eval FORM t) does not 
set this variable?


I understand why it doesn't. Elisp can be interpreted independent 
of a buffer, and different buffers need to distinguish which scope 
to use. 
It's more a question of what do we gain by leaving it unbound 
while evaluating a src block?
A user can rebind `lexical-binding' without hurting anything. The 
only case I can think of is if they intend to use it as a free 
variable, it won't be free. I can't imagine a use case where that 
would be true while the user is also explicitly requesting lexical 
binding, though.

IMO, it should be set during evaluation (addressed by my patch).

An alternative solution would be to allow one to set the lexical 
environment as part of the header args. e.g.


#+begin_src emacs-ilsp :lexical ((lexical-binding . t) t)
(symbol-value lexical-binding)
#+end_src

That way we offer the full flexibility of `eval' to those who 
would use it.


A separate issue, but one worth considering, is whether or not 
tangling a `:lexical t` src block should automatically add the 
file-local variable line in the tangled file.


Prior confusion (its not just me, I swear):

https://emacs.stackexchange.com/questions/61754/how-can-i-enable-lexical-binding-for-elisp-code-in-org-mode#comment100554_61758

https://lists.gnu.org/archive/html/emacs-orgmode/2019-08/msg00247.html



[BUG?][PATCH] Should the `lexical-binding' variable be bound during src block with :lexical t? [9.4.6 (9.4.6-ga451f9 @ /home/n/.emacs.d/straight/build/org/)]

2021-09-09 Thread No Wayman


I ran into this with some code I'm writing which checks against 
`lexical-binding'.
Should the following result in "lexical binding enabled" or 
"lexical binding disabled"?:


#+begin_src emacs-lisp :lexical t
(message "lexical binding %sabled" (if lexical-binding "en" 
"dis"))

#+end_src

Currently the `lexical-binding' variable is not bound because 
`org-babel-execute:emacs-lisp'
passes t to `eval', which enables lexical binding, but does not 
bind the `lexical-binding' variable.

The attached patch binds the variable in the lexical environment.
It's a matter of whether or not this is the right thing to do.
Thoughts?


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.4, Xaw3d scroll bars)

of 2021-09-04
Package: Org mode version 9.4.6 (9.4.6-ga451f9 @ 
/home/n/.emacs.d/straight/build/org/)


>From 42b92303faa86b1e9bd0692fca9469eb6a8f02ce Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 9 Sep 2021 16:40:02 -0400
Subject: [PATCH] ob-emacs-lisp: bind lexical-binding for :lexical t src blocks

* lisp/ob-emacs-lisp.el (org-babel-execute:emacs-lisp): bind lexical-binding in lexical environments

Because we use `eval' to execute the src block, this variable needs to
be explicitly set. Passing t as eval's LEXICAL arg will not bind
this variable.
---
 lisp/ob-emacs-lisp.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index d03151f13..6cf387b96 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -61,7 +61,7 @@ by `org-edit-src-code'.")
 
 (defun org-babel-execute:emacs-lisp (body params)
   "Execute a block of emacs-lisp code with Babel."
-  (let* ((lexical (cdr (assq :lexical params)))
+  (let* ((lexical (org-babel-emacs-lisp-lexical (cdr (assq :lexical params
 	 (result-params (cdr (assq :result-params params)))
 	 (body (format (if (member "output" result-params)
 			   "(with-output-to-string %s\n)"
@@ -71,7 +71,7 @@ by `org-edit-src-code'.")
  (member "pp" result-params))
  (concat "(pp " body ")")
 			   body))
-		   (org-babel-emacs-lisp-lexical lexical
+		   (when lexical (list (cons 'lexical-binding t) t)
 (org-babel-result-cond result-params
   (let ((print-level nil)
 (print-length nil))
-- 
2.33.0



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

2021-09-06 Thread No Wayman



Allen Li  writes:

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's not so easy to notice such corruption in the case of captures 
which are filed away and then searched for (by tag) at a later 
time.
But that's neither here nor there. We both agree the behavior 
should be more consistent, and the patch I've proposed takes care 
of that.


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.

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.


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.


The separators are stored in a separate variable for use in the 
prompt.
I'll have to take another look to see if we can eliminate the 
duplicate code.
I do agree the function can be "private" and named more 
appropriately.

I'll change that in the next revision.

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

user friendly


Agreed. I'll tidy that up as well once a solution is agreed upon.
(IME Org/Emacs patches require more discussion up front, so I'd 
rather deal with that first

instead of putting too much time into a trivial patch up front)

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.




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

2021-09-03 Thread No Wayman


No Wayman  writes:


No Wayman  writes:


See the attached patch for a first draft implementation.


Attached is a second draft which compiles cleanly and makes use 
of mapconcat

where appropriate.

[2. org-tags-crm-separators-2 --- text/x-patch; 
0001-Add-org-tags-crm-separators.patch]...


See attached with amended commit message.

>From d059c4369ac17fcba885adf87c95c6797894d230 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 3 Sep 2021 14:50:48 -0400
Subject: [PATCH] Add org-tags-crm-separators

* org.el (org-tags-crm-separators): Defcustom controlling which
characters are used to delimit tags in commands which utilize
`completing-read-multiple'.
(org-set-tags-command, org-capture-fill-template): Make use of org-tags-crm-separators; Show
delimiters in tag prompt.
---
 lisp/org-capture.el |  7 +--
 lisp/org.el | 17 ++---
 2 files changed, 19 insertions(+), 5 deletions(-)

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))
   ":")))
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
@@ -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 "[ \t]*%s[ \t]*" (regexp-opt (mapcar #'char-to-string chars
+
 (defun org-set-tags-command ( arg)
   "Set the tags for the current visible entry.
 
@@ -12065,11 +12074,13 @@ 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)))
- (crm-separator "[ \t]*:[ \t]*"))
+		   (let* ((org-add-colon-after-tag-completion (< 1 (length table)))
+  (separators (or org-tags-crm-separators '(?: ?,)))
+  (crm-separator (org-tags-crm-regexp separators)))
 		 (mapconcat #'identity
 (completing-read-multiple
-			 "Tags: "
+ (format "Tags (%s to delimit): "
+ (mapconcat #'char-to-string separators " "))
 			 org-last-tags-completion-table
 			 nil nil (org-make-tag-string current-tags)
 			 'org-tags-history)
-- 
2.33.0



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

2021-09-03 Thread No Wayman


No Wayman  writes:


See the attached patch for a first draft implementation.


Attached is a second draft which compiles cleanly and makes use of 
mapconcat where appropriate.


>From 079f116f6bedcf2c2b1d08c18d71d8e432d94d38 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 3 Sep 2021 14:50:48 -0400
Subject: [PATCH] Add org-tags-crm-separators

commit message/formatting pending discussion of solution.
---
 lisp/org-capture.el |  7 +--
 lisp/org.el | 17 ++---
 2 files changed, 19 insertions(+), 5 deletions(-)

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))
   ":")))
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
@@ -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 "[ \t]*%s[ \t]*" (regexp-opt (mapcar #'char-to-string chars
+
 (defun org-set-tags-command ( arg)
   "Set the tags for the current visible entry.
 
@@ -12065,11 +12074,13 @@ 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)))
- (crm-separator "[ \t]*:[ \t]*"))
+		   (let* ((org-add-colon-after-tag-completion (< 1 (length table)))
+  (separators (or org-tags-crm-separators '(?: ?,)))
+  (crm-separator (org-tags-crm-regexp separators)))
 		 (mapconcat #'identity
 (completing-read-multiple
-			 "Tags: "
+ (format "Tags (%s to delimit): "
+ (mapconcat #'char-to-string separators " "))
 			 org-last-tags-completion-table
 			 nil nil (org-make-tag-string current-tags)
 			 'org-tags-history)
-- 
2.33.0



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

2021-09-03 Thread No Wayman



Timothy  writes:

Reading your thoughts I’m inclined to agree, perhaps it’s best 
if we settle on a
set of “sensible” separation characters, document them, and 
leave it at that.


NoWayman, what do you think of that?



I disagree with the idea that it shouldn't be customizable.
See the second patch I've offered.
I feel it addresses the issue without preventing customization.



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

2021-09-03 Thread No Wayman


Allen Li  writes:

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.


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.



There's also the option to only allow ":" and "," as separators.
Whichever behavior we choose, I don't think it's worth making it 
customizable.


I would rather not have to type ":" to separate Org tags when CRM 
allows me to use ","
(or another character of my choice) everywhere else. This violates 
the principle of least surprise.


An even simpler solution than my original patch is to have a 
defcustom which allows the user to customize

the CRM separator character(s) Org uses to read tags.

See the attached patch for a first draft implementation.

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.


>From 34d292a60bc45923589646499b6e06c5cb3ca036 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 3 Sep 2021 14:50:48 -0400
Subject: [PATCH] Add org-tags-crm-separators

commit message/formatting pending discussion of solution.
---
 lisp/org-capture.el |  7 +--
 lisp/org.el | 17 ++---
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index c51744680..e9cd8f490 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): "
+   (string-join (mapcar #'char-to-string separators) " ")))
  org-last-tags-completion-table nil nil nil
  'org-tags-history))
   ":")))
diff --git a/lisp/org.el b/lisp/org.el
index ce68f4692..d6739f7ed 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 characters used to separate tags during Org commands which read mutiple tags."
+  :type 'list
+  :group 'org-tags)
+
 (defvar org-tags-history nil
   "History of minibuffer reads for tags.")
 (defvar org-last-tags-completion-table nil
@@ -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 "[ \t]*%s[ \t]*" (regexp-opt (mapcar #'char-to-string chars
+
 (defun org-set-tags-command ( arg)
   "Set the tags for the current visible entry.
 
@@ -12065,11 +12074,13 @@ 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)))
- (crm-separator "[ \t]*:[ \t]*"))
+		   (let* ((org-add-colon-after-tag-completion (< 1 (length table)))
+  (separators (or org-tags-crm-separators '(?: ?,)))
+  (crm-separator (org-tags-crm-regexp 

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

2021-09-03 Thread No Wayman



Timothy  writes:

Ah, right — that looks sensible. I think we should probably note 
that in a

comment somewhere,


Yes, a comment is warranted.
I'll address minor issues like this once a solution is agreed 
upon.


or perhaps construct the regexp with `rx' so it’s actually using 
`org-tag-re'?


Unfortunately I don't think it's that simple.
They are very similar regexps, but I don't think we can just plug 
`org-tag-re'

into an rx form and have it work. A direct comparison:


org-tag-re =>"[[:alnum:]_@#%]+"
org-tag-crm-separator => "[^[:alnum:]_@#%]"

This is brittle, but we could define `org-tag-crm-separator' in 
terms of `org-tag-re' like so:


(defvar org-tag-crm-separator (concat "[^" (substring org-tag-re 1 
-1







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

2021-09-02 Thread No Wayman



Timothy  writes:


Hi NoWayman,

Thanks for your suggestion. At a glance it looks reasonable to 
me, but would you
be able to explain the default value you’ve set? It isn’t 
obvious to me how you
arrived at `"[ \t]*[^[:alnum:]_@#%][ \t]*"'. Also, do you think 
a
one-size-fits-all solution is a good fit here? I don’t do much 
with tags

personally, so I’m probably not the best person to judge.


(defconst org-tag-crm-separator “[ ]*[^[:alnum:]_@#%][ ]*”
  “Regexp used to determine `crm-separator’ when reading 
  multiple tags.”)


All the best,
Timothy


I was aiming for the inverse of `org-tag-re' which is:

"[[:alnum:]_@#%]+"

The idea being we treat any character which is not a valid tag 
character as the crm separator.




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

2021-08-26 Thread No Wayman


Remember to cover the basics, that is, what you expected to happen 
and
what in fact did happen.  You don't know how to make a good 
report?  See


https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


622f9fa76c8ee0766b15945c013b0950d703b955 ("org: Use crm for 
completing tags")
lexically binds crm-separator to ":" while prompting for multiple 
tags in

org-set-tags-command and org-capture-fill-template.

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


I can think of a couple ways we could improve this and make the 
behavior consistent.
We could introduce a defcustom which allows the user to choose 
whether or not
Org will rebind crm-separator during commands/functions which 
utilize

completing-read-multiple.
e.g.

#+begin_src emacs-lisp :lexical t
(defcustom org-contextual-crm-separator t
 "Use contextual binding of crm-separator during Org commands.
For example, when setting tags, \":\" is used as the separator.
If nil, `crm-separator' is used.")
#+end_src

Alternatively, we could change the lexical binding we're using 
during these commands/functions.
Instead of binding the separator explicitly to "[ \t]*:[ \t]*", we 
could instead use a regexp
which will match any character not described by org-tag-re. The 
benefit of
this is that completing-read-multiple completion will work for any 
separator
that doesn't match org-tag-re transparently and the results should 
be
consistent between org-set-tags-command and 
org-capture-fill-template.


The attached patch implements that change, which seems to do the 
right thing
from my testing. I can polish it, but I wanted to get opinions on 
the solution first.


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.


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

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


>From 2ec28b530eb28cf788c38556ec3cb97f3bacd4af Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 26 Aug 2021 12:51:27 -0400
Subject: [PATCH] RFC: broader regexp for lexically bound crm-separator

For testing purposes. Ammended commit message pending.
---
 lisp/org-capture.el | 2 +-
 lisp/org.el | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index c51744680..47b47c3ca 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1740,7 +1740,7 @@ The template may still contain \"%?\" for cursor positioning."
 			(org-add-colon-after-tag-completion t)
 			(ins (mapconcat
   #'identity
-  (let ((crm-separator "[ \t]*:[ \t]*"))
+  (let ((crm-separator org-tag-crm-separator))
 (completing-read-multiple
  (if prompt (concat prompt ": ") "Tags: ")
  org-last-tags-completion-table nil nil nil
diff --git a/lisp/org.el b/lisp/org.el
index ce68f4692..f5e396cba 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -602,6 +602,9 @@ not contribute to the agenda listings.")
 (defconst org-tag-re "[[:alnum:]_@#%]+"
   "Regexp matching a single tag.")
 
+(defconst org-tag-crm-separator "[ \t]*[^[:alnum:]_@#%][ \t]*"
+  "Regexp used to determine `crm-separator' when reading multiple tags.")
+
 (defconst org-tag-group-re "[ \t]+\\(:\\([[:alnum:]_@#%:]+\\):\\)[ \t]*$"
   "Regexp matching the tag group at the end of a line, with leading spaces.
 Tags are stored in match group 1.  Match group 2 stores the tags
@@ -12066,7 +12069,7 @@ in Lisp code use `org-set-tags' instead."
 		  table
 		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
 		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
- (crm-separator "[ \t]*:[ \t]*"))
+ (crm-separator 

Re: [PATCH] Rename headline to heading

2021-08-15 Thread No Wayman


No Wayman  writes:

As far as org-capture is concerned, support for transparently 
upgrading the
user's templates could easily be added to the 
`org-capture-upgrade-templates`

function.

It would just be one more case added to the existing pcase 
statement and would

prevent breakage for users.


See the attached patch which adds the mentioned case.
The docstring for `org-capture-upgrade-templates` could be worded 
better/more generally.
I believe we could also do a better job notifying the user when 
they have outdated
capture syntax. Really we should be recording *which* templates 
use outdated syntax
and pointing them to a solution. These are separate issues, 
though.


>From 4a133f0c5a7fef18ea1dfb38e2e1539da1db834e Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 15 Aug 2021 12:48:00 -0400
Subject: [PATCH] org-capture.el: Upgrade file+headline template target syntax

* lisp/org-capture.el (org-capture-upgrade-templates): Upgrade
templates which utilize file+headline target syntax to file+heading
---
 lisp/org-capture.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 831c3e1f4..28b3e33f4 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -109,7 +109,8 @@
   "Update the template list to the new format.
 TEMPLATES is a template list, as in `org-capture-templates'. The
 new format unifies all the date/week tree targets into one that
-also allows for an optional outline path to specify a target."
+also allows for an optional outline path to specify a target.
+It also accounts for renaming `headline` to `heading`."
   (let ((modified-templates
 	 (mapcar
 	  (lambda (entry)
@@ -128,6 +129,9 @@ also allows for an optional outline path to specify a target."
 	  (`(,key ,desc ,type (file+weektree+prompt . ,path) ,tpl . ,props)
 	   `(,key ,desc ,type (file+olp+datetree ,@path) ,tpl
 		  :tree-type week :time-prompt t ,@props))
+  ;; Rename "headline" to "heading"
+	  (`(,key ,desc ,type (file+headline . ,file+heading) ,tpl . ,props)
+	   `(,key ,desc ,type (file+heading ,@file+heading) ,tpl ,@props))
 	  ;; Other templates are left unchanged.
 	  (_ entry)))
 	  templates)))
-- 
2.32.0



Re: [PATCH] Rename headline to heading

2021-08-15 Thread No Wayman



As far as org-capture is concerned, support for transparently 
upgrading the user's templates could easily be added to the 
`org-capture-upgrade-templates` function.


It would just be one more case added to the existing pcase 
statement and would prevent breakage for users.




Re: what would cause failure in template for org capture?

2021-07-27 Thread No Wayman



Thanks for doing the bisect.
I was in the process of doing it myself and comparing disassembled 
byte-code when I saw the patch had been pushed.
For anyone curious, this particular bug was a byte compilation 
error.
When byte-compiled, org-capture-fill-template was attempting to 
compare strings
via a jump-table-eq bytecode instruction instead of a 
jump-table-equal.


Resolved on Emacs master as of 
949dd41c31dab69f7a5067bba324c28bb2cfbf8e




Re: what would cause failure in template for org capture?

2021-07-23 Thread No Wayman



from an earlier thread, I recall you mentioned you were using 
native

compilation? This is almost certainly the cause of your problem.


This does smell like a byte-compilation problem.
Seems to be a failure with any interactive, single-character 
%-escaped patterns in a template string (e.g. %^g, %^C, %^t).
I've narrowed it down to a call to pcase in 
`org-capture-fill-template'.
As Eric mentions, the problem disappears if the function is 
re-evaluated/instrumented.
I have disabled native compilation and the problem persists with 
just a freshly byte-compiled elc of org-capture.

Tested this with the following recipe:

1. eval the following:
(org-capture-fill-template "%^t") ;fails with `unrecognized 
template placeholder: %^t`
2. eval org-capture-fill-template's definition, and then re-eval 
the above. Works properly. User is prompted for a time.
3. byte compile org-capture-fill-template: (byte-compile 
#'org-capture-fill-template)

4. eval (org-capture-fill-template "%^t") ; error is back


Running Emacs 28.0.50
Repository revision: 903ecd7bea7d8f99a7dc84150728219283d79bf0
Repository branch: master






Re: new org-contrib and straight.el

2021-05-21 Thread No Wayman



Greg Minshall  writes:


Nick,
...i have not been getting the updated org-mode info
pages with my org package. 


Straight provides its own means of building/installing package 
info.

This may be a bug with the Org mode recipe we provide.
Please file a bug report at:

https://github.com/raxod502/straight.el

Be sure to include the output of `M-x straight-version` and `M-x 
emacs-version` at a minimum.


If you feel you have a reproduction case or recipe that works 
better, you can include

that recipe with a report using `straight-bug-report'.
It's a macro that will install straight in a clean environment,
run your code and produce a formatted report to share.




Re: new org-contrib and straight.el

2021-05-19 Thread No Wayman



Greg Minshall  writes:


Nick,

The recent changes to org-contrib's location/structure have 
been
accounted for on straight's "develop" branch. Once on that 
branch you

can rely on the default recipe:


thanks very much.  i'll look at switching to the development 
branch,

freezing and thawing.

cheers, Greg




You're welcome.

I've merged the develop branch into the master branch this 
morning, too.
So you should be able to reap that benefit on either branch, but I 
still

recommend using the lockfiles to your advantage.




Re: new org-contrib and straight.el

2021-05-18 Thread No Wayman




Hi, Greg.

The recent changes to org-contrib's location/structure have been 
accounted for on straight's
"develop" branch. Once on that branch you can rely on the default 
recipe:


#+begin_src emacs-lisp
(straight-use-package 'org-contrib)
#+end_src

You can see which version of straight you're currently using via 
`M-x straight-version`.
If you're on the "master" branch (commit e1390a9 as of this 
writing), you can update to the "develop"

branch by adding:

#+begin_src emacs-lisp
(setq straight-repository-branch "develop")
#+end_src

prior to straight's bootstrapping snippet in your in init file.
I recommend using the develop branch and utilizing the lockfile 
system via
`straight-freeze-versions` and `straight-thaw-versions` to define 
your own "stable releases".


Hope that helps.
If you have any other questions or run into problems feel free to 
reach out on our issue tracker:


https://github.com/raxod502/straight.el/issues/new/choose

Hope that helps,

Nick



Re: Bug: [PATCH] org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-05 Thread No Wayman



Sébastien Miquel  writes:

Here's another patch, to be applied on top of the previous one, 
that

fixes this.

The specific case you mention can also be achieved by setting 
the
:tangle argument to `yes`: in this case, the tangled file name 
is

computed using the buffer file name and changing the extension
according to the src block language.


Thanks for the tip. I probably added that years ago and haven't 
changed it.

Updated to keep things simple.

Thank you again for the report, and sorry for breaking 
everything.



Thanks for the patches. Tested them and everything seems to be 
working OK.




Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread No Wayman



Sébastien Miquel  writes:


Hi Bastien,

Bastien writes:
I tried to apply this (transitory?) patch against maint and it 
did not
apply. It applies okay on master. For bug fixes, please make 
patches

againt the maint branch.
This fixes a bug introduced by a commit in master. I've attached 
the same
patch here, properly formated. I think it should be applied to 
master.


It reverts a part of a2cb9b853: permissions are no longer set 
before writing

to the tangled file.

I've CC'd Tom, which made the original suggestion. I guess we 
could set the
write and execute permissions before writing, and set the read 
permissions

afterwards.



Another related bug to the changes:

I have the :tangle header-arg set to evaluate some elisp to return 
the file name:


org-babel no longer interprets this elisp. It is being used 
literally as the file name:

e.g.

Wrote /home/n/.emacs.d/(concat (file-name-sans-extension 
(buffer-file-name)) ".el")




Re: Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread No Wayman



Sébastien Miquel  writes:


Hi,

No Wayman writes:
I'm tangling my early-init/init.el with the :tangle-mode header 
arg set to

(identity (#o444)).

This should be `(identity #o444)` I believe ?



Apologies, I transcribed that incorrectly. I do have `(identity 
#o444)`. 

File permissions are now set before writing to the file, for 
security
reasons. In this case, you remove write permission so emacs 
fails to
write to the file. Perhaps we should try to support this use 
case.


However, even with the previous version, it seems that 
subsequent
tangles should have failed (emacs should fail to delete the 
previous
tangled file). Can you confirm this and explain how you dealt 
with it ?



Subsequent tangles did not fail for me. I just tested by building 
Org from a2cb9b853's parent: f84033b08.
Multiple tangles work with no permission errors on subsequent 
tangles.


Here's my init.org, if that's useful:

https://raw.githubusercontent.com/progfolio/.emacs.d/master/init.org


As a workaround, you could use a file-local
`org-babel-post-tangle-hook` to set file permission. Although
subsequent tangles will still fail.


Unfortunately, I don't have much use for the workaround if 
subsequent tangles will fail.
I currently have an after-save-hook function which tangles the 
files if I've edited any of the
src blocks. It's very convenient and I often will edit/tangle 
files set up like this multiple times.




Bug: org-babel-tangle: persmission denied when tangling [9.4.5 (9.4.5-gbc2659 @ /home/n/.emacs.d/straight/build/org/)]

2021-05-04 Thread No Wayman



I'm tangling my early-init/init.el with the :tangle-mode header 
arg set to (identity (#o444)).
The idea behind this was to prevent myself from accidentally 
editing the tangled source files
instead of the Org files. Unfortunately, since a3cb9b853 there 
seems to be a behavior change for org-babel-tangle which prevents 
this. An abbreviated stacktrace which shows the error when I try 
to tangle my files:


Debugger entered--Lisp error: (file-error "Opening output file" 
"Permission denied" "/home/n/.emacs.d/early-init.el")

 write-region("" nil "~/.emacs.d/early-init.el" nil 0)

Any way to work around this?

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.4, Xaw3d scroll bars)

of 2021-05-03
Package: Org mode version 9.4.5 (9.4.5-gbc2659 @ 
/home/n/.emacs.d/straight/build/org/)




Re: Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

2021-04-27 Thread No Wayman



Kyle Meyer  writes:


Bastien writes:


Hi,

thanks for the patch, we do indeed need to move forward for 
this.


Could you propose the patch against the master branch (not the 
maint
branch, since this is not a bugfix) and perhaps fix *all* 
warnings?


Thanks, but these were already taken care of by 8c29cbdef 
(Backport
commit c45bfd3c4 from Emacs, 2021-04-18), which was merged into 
master

with 664b65344.


Apologies for the noise!



Bug: [PATCH] define-minor-mode: prefer keyword args [9.4.5 (9.4.5-ga02a3b @ /home/n/.emacs.d/straight/build/org-plus-contrib/)]

2021-04-26 Thread No Wayman


Remember to cover the basics, that is, what you expected to happen 
and
what in fact did happen.  You don't know how to make a good 
report?  See


https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


The attached patch updates the calling convention for several 
minor-mode definitions to use keywords in place of the older 
positional arguments. With the native comp branch being merged 
into Emacs' master branch, these types of warnings become more 
apparent to end users, so I figure it's a good idea to stay on top 
of them.


Thanks,
Nick

>From b33e081225a441e43cd03cd127197e4abaa0966d Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 26 Apr 2021 08:25:25 -0400
Subject: [PATCH] Update define-minor-mode calling convention

* org-list.el, org-src.el, org-table.el, org.el: Migrate minor mode
definitions from positional arguments to keyword args.
---
 lisp/org-list.el  | 2 +-
 lisp/org-src.el   | 2 +-
 lisp/org-table.el | 4 ++--
 lisp/org.el   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index 98d9e36da..4d84d99bb 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -2296,7 +2296,7 @@ is an integer, 0 means `-', 1 means `+' etc.  If WHICH is
 ;;;###autoload
 (define-minor-mode org-list-checkbox-radio-mode
   "When turned on, use list checkboxes as radio buttons."
-  nil " CheckBoxRadio" nil
+  :lighter " CheckBoxRadio"
   (unless (eq major-mode 'org-mode)
 (user-error "Cannot turn this mode outside org-mode buffers")))
 
diff --git a/lisp/org-src.el b/lisp/org-src.el
index 20acee4e6..cabedecb6 100644
--- a/lisp/org-src.el
+++ b/lisp/org-src.el
@@ -682,7 +682,7 @@ This minor mode is turned on in two situations:
 \\{org-src-mode-map}
 
 See also `org-src-mode-hook'."
-  nil " OrgSrc" nil
+  :lighter " OrgSrc"
   (when org-edit-src-persistent-message
 (setq header-line-format
 	  (substitute-command-keys
diff --git a/lisp/org-table.el b/lisp/org-table.el
index 3030751cc..a0c354d86 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -499,7 +499,7 @@ This may be useful when columns have been shrunk."
 ;;;###autoload
 (define-minor-mode org-table-header-line-mode
   "Display the first row of the table at point in the header line."
-  nil " TblHeader" nil
+  :lighter " TblHeader"
   (unless (eq major-mode 'org-mode)
 (user-error "Cannot turn org table header mode outside org-mode buffers"))
   (if org-table-header-line-mode
@@ -1966,7 +1966,7 @@ lines."
 When this mode is active, the field editor window will always show the
 current field.  The mode exits automatically when the cursor leaves the
 table (but see `org-table-exit-follow-field-mode-when-leaving-table')."
-  nil " TblFollow" nil
+  :lighter " TblFollow"
   (if org-table-follow-field-mode
   (add-hook 'post-command-hook 'org-table-follow-fields-with-editor
 		'append 'local)
diff --git a/lisp/org.el b/lisp/org.el
index 675a614e2..f7fd90cf9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15640,7 +15640,7 @@ When a buffer is unmodified, it is just killed.  When modified, it is saved
 This mode supports entering LaTeX environment and math in LaTeX fragments
 in Org mode.
 \\{org-cdlatex-mode-map}"
-  nil " OCDL" nil
+  :lighter " OCDL"
   (when org-cdlatex-mode
 (require 'cdlatex)
 (run-hooks 'cdlatex-mode-hook)
-- 
2.31.1



Re: org-capture: question about function to create template

2021-03-15 Thread No Wayman




From: Joost Kremers 
To: emacs-orgmode@gnu.org
Subject: org-capture: question about function to create template
Message-ID: <87eeggh0r5@fastmail.fm>
Content-Type: text/plain

Hi list,

I've been looking at the =org-capture= mechanism a bit more 
closely recently and
noticed that in =org-capture-templates=, the template can also 
be a function.
This looks like a potentially useful feature, but I was 
wondering if there's any
way for this function to access the state of the ongoing capture 
process.


The metadata for the template is stored in the `org-capture-plist' 
variable.



Specifically, it would be useful for me if the function can find 
out the key of

the template that the user selected.


This is stored on the above plist as :key.

There are some corner cases to consider if you have overlapping 
capture processes.
You'll want to look into `org-capture-get' and 
`org-capture-current-plist' as well.


Depending on your needs you may find DOCT useful:

https://www.github.com/progfolio/doct






Re: Bug: org.el has wrong (or none) version [fatal: No names found, cannot describe anything. (fatal: No names found, cannot describe anything. @ /Users/niels/.emacs.d/straight/build/org-agenda/)]

2021-01-06 Thread No Wayman



I don't know anything about straight, but this sounds like what 
you'd
get if you try to generate org-version.el in an Org repo without 
tags.


This is the correct assessment.
Straight has a user option, `straight-vc-git-default-clone-depth', 
which may be customized
to perform shallow clones of N commits. I've ammended the default 
Org recipe to ensure a
full clone is performed. I've contacted Niels on his github to 
illustrate how this can be done on a per-recipe basis as well via 
the `:depth` keyword.


Thank you,

Nick Vollmer



[feature] capture: defcustom for item/checkitem to skip LOGBOOK [9.4.4 (release_9.4.4-159-g9140a7 @ /home/n/.emacs.d/straight/build/org/)]

2020-12-30 Thread No Wayman



Consider the following file named "/tmp/capture-item-logbook.org":

 start capture-item-logbook.org ---
* TODO TASK
SCHEDULED: <2020-12-30 Wed 21:30 ++1d>
:PROPERTIES:
:STYLE:habit
:END:
:LOGBOOK:
- State "DONE"   from "TODO"   [2020-12-29 Tue 21:30]
:END:

:+begin_src emacs-lisp :lexical t
(let ((org-capture-templates
  '(("x" "TASK ITEM" item
 (file+headline "/tmp/capture-item-logbook.org" 
 "TASK")

 (org-capture nil "x"))
#+end_src
 end capture-item-logbook.org ---

Executing the src block places the capture item in the LOGBOOK 
drawer if the entry type is 'item or 'checkitem.
Technically this is the correct behavior according to 
`org-capture-templates' docstring:


item  a plain list item, will be placed in the
   first plain list at the target location.
   Its default template is:
 "- %?"

The documentation on LOGBOOK drawers also mentions:

"You can also arrange for state change notes  and clock times to 
be stored in a ‘LOGBOOK’ drawer.
If you want to store a quick note there, in a similar way to state 
changes, use..." 

Is it worth having an option for org-capture's item/checkitem 
templates to skip targeting drawers?
capture is flexible enough where user's can implement their own 
point-placing function, but I wonder

if skipping drawers is the common case.

Thoughts?






Re: Org Capture Menu cannot be fully viewed

2020-12-16 Thread No Wayman




What is here missing is `org-capture-by-completing-read' so that
user may select among many various capture templates.



Compensating for initial bad design is expensive effort.


Are you suggesting something like this?:

#+begin_src emacs-lisp
(defun +org-capture-read ( arg)
 "completing read interface for org-capture template selection.
ARG is passed to `org-capture'."
 (let (parent)
   (when-let* ((templates
(mapcar (lambda (template)
  (let* ((keys (car template))
 (parentkeys (car parent)))
(if (= (length template) 2)
(progn (setq parent template) 
nil)
  (cons (concat (when (and parentkeys 
  (string-prefix-p parentkeys keys))
  (concat (cadr 
  parent) "/"))

(cadr template))
keys
org-capture-templates))
   (selection (alist-get
   (completing-read "capture template: "
(mapcar #'car (delq 
nil templates))

nil 'require-match)
   templates
   nil nil
   #'string=)))
 (org-capture arg selection
#+end_src emacs-lisp




Re: Org Capture Menu cannot be fully viewed

2020-12-16 Thread No Wayman



Pietru:

If you are extensively using Org's capture templates I suggest 
taking a look at:


https://github.com/progfolio/doct

A brief summary of some of the benefits it provides:

- Allows capture template inheritance
- Checks for certain errors in template declarations *before* 
 capture.

- Automatically computes the keys for nested menus
- Makes per-template hooks/contexts easy to declare.
- Allows for storing custom metadata with templates which can be 
 used within templates
- Declarative: Your template declarations will be easier to 
 read/share.


Taking the list of templates provided earlier as an example,
It could utilize nested menus/inheritance like so:

#+begin_src emacs-lisp :lexical t
(doct
'( :group "Archaeology"
   :file "~/histr/archaeol.org"
   :template "* Site_Type: %?\n %T\n"
   :children (("Research" :keys "r"
   :children (("Bioarchaeological" :keys "b")
  ("Collections"   :keys "c")
  ("Design/Data Recovery"  :keys "d")
  ("Environment"   :keys "e")
  ("Ethnographic"  :keys "g")
  ("Ethnohistoric" :keys "h")
  ("Historic Eval/Testing" :keys "t")))
  ("Survey" :keys "s"
   :children (("Architectural"   :keys "a")
  ("Geophysical" :keys "g")
  ("Reconnaissance"  :keys "r")
  ("Recovery/Excavation" :keys "R")))
  ("Consultation"  :keys "c")
  ("Architectural Documentation"   :keys "d")
  ("Site Stabilization":keys "e")
  ("Ground Disturbance Monitoring" :keys "g")
  ("Heritage Management"   :keys "h")
  ("Records Search/Inventory Checking" :keys "i")
  ("Methodology, Theory, Synthesis":keys "m")
  ("Archaeological Overview"   :keys "o")
  ("Remote Sensing":keys "R")
  ("Site Stewardship Monitoring"   :keys "d"
#+end_src

Each template inherits the :file and :template values.
The keys for the "Research" and "Survey" children templates are 
computed by doct,
so changing the whole groups prefix key only requires a change on 
the parent template's :keys.


I haven't demoed the custom metadata in this example as I don't 
know your exact use case,

but there is an example in the documentation:

https://github.com/progfolio/doct#custom-data


Hope this is useful for you.

~ Nick



Bug: [PATCH] org-agenda: "Invalid face reference: t" errors [9.4 (release_9.4-49-g4b150d @ /home/n/.emacs.d/straight/build/org/)]

2020-10-05 Thread No Wayman


I noticed recently that my message buffer was getting clobbered 
with thousands of Invalid face reference errors when moving point 
around an org-agenda buffer. e.g.:



Invalid face reference: t [4519 times]


Git bisect points to commit 
7a12e149907b5921011710d869b7554c35859c89



org.el (org-display-outline-path): Fix faces of the message

* lisp/org.el (org-display-outline-path): Set :height as the
default face height, and don't change other face attributes.

See a3576543f for a previous fix, and this discussion:



As a workaround, setting `org-agenda-show-outline-path' to nil 
prevents the errors.
I believe the face spec in the call to `add-face-text-property' in 
`org-display-outline-path' is incorrect.
The attached patch replaces it with an anonymous face, which works 
on my end.


>From 4b150d7ca3f8d7d9fe30f6b562b35a5f4072e5e1 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 6 Oct 2020 01:30:09 -0400
Subject: [PATCH] org.el (org-display-outline-path): Fix invalid face reference
 error

* lisp/org.el (org-display-outline-path): Use an anonymous face when
adding default :height to outline path
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 425e9391b..beb830b36 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -8057,7 +8057,7 @@ If JUST-RETURN-STRING is non-nil, return a string, don't display a message."
 	   (and file bfn (concat (file-name-nondirectory bfn) separator))
 	   separator))
 (add-face-text-property 0 (length res)
-			`((t :height ,(face-attribute 'default :height)))
+			`(:height ,(face-attribute 'default :height))
 			nil res)
 (if just-return-string
 	res
-- 
2.28.0



Re: Proposal: do not align tags in Agenda

2020-10-05 Thread No Wayman
I recently proposed a patch that would allow a workaround for this:

https://orgmode.org/list/87ft8gelpn@gmail.com/

It allows custom placement of the habit consistency graph within the agenda.
There is an accompanying example that places the graph on its own line
under the agenda item.
I've attached an org file with my current workaround which advises
`org-habit-insert-consistency-graphs'.


org-habit-single-line-suggestion.org
Description: Lotus Organizer


Re: org-capture at point

2020-10-02 Thread No Wayman



Looks like it was introduced with:

f5573e6a0 org-capture.el: Fix heading's level when inserting a
template "here"


I believe the issue is due to `org-back-to-heading' moving point 
when calculating the heading level.

The attached patch corrects the issue on my end.
Tested by running:

#+begin_src emacs-lisp :lexical t
(dotimes (n 3)
 (let ((org-capture-templates
`(( "e" "test"
entry
(file "/temp/null.org")
,(format "* %d" n)
:immediate-finish t
:no-save t
   (goto-char (point-max))
   (org-capture 0 "e")))
#+end_src

With a buffer containing:

* foo
** one
*** two
 three
*** four

Which results in:

* foo
** one
*** two
 three
*** four
*** 0
*** 1
*** 2

>From 5a35577f22cdc849ebcede6bac7b7f22da7eb16b Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 2 Oct 2020 14:01:35 -0400
Subject: [PATCH] org-capture.el: Fix heading's position when inserting a
 template "here"

* lisp/org-capture.el (org-capture-place-entry): Fix heading's
position when inserting a template "here" with C-0 M-x org-capture.
---
 lisp/org-capture.el | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 67c58ffdd..020feb4d6 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1150,10 +1150,11 @@ may have been stored before."
  (insert-here?
   ;; FIXME: level should probably set directly within (let ...).
   (setq level (org-get-valid-level
-		   (if (or (org-at-heading-p)
-			   (ignore-errors (org-back-to-heading t)))
-		   (org-outline-level)
-		 1
+   (if (or (org-at-heading-p)
+   (ignore-errors
+			 (save-excursion (org-back-to-heading t
+   (org-outline-level)
+ 1
  ;; Insert as a child of the current entry.
  ((org-capture-get :target-entry-p)
   (setq level (org-get-valid-level
-- 
2.28.0



Re: org-capture at point

2020-09-29 Thread No Wayman




Since org-plus-contrib 20200920, I'm no longer able to get
org-capture to insert a template at the point. Instead, it seems
to place the entry at the appropriate heading level, above the
current heading. Looking at the help page, perhaps it's this
behavior:

This happens with both a custom interactive function that calls
(org-capture 0), and by using a zero prefix.

I'm not able to get this functionality to work:
"When called with a ‘C-0’ (zero) prefix, insert a template at
point."


I can confirm this behavior.
Looks like it was introduced with:

f5573e6a0 org-capture.el: Fix heading's level when inserting a 
template "here"


I tested by running the following:

#+begin_src emacs-lisp :lexical t
(dotimes (n 3)
 (let ((org-capture-templates
`(( "e" "test"
entry
(file "/temp/null.org")
,(format "* %d" n)
:immediate-finish t
:no-save t
   (goto-char (point-max))
   (org-capture 0 "e")))
#+end_src


with Org built from f5573e6a0 output is:

* 1
* 2
* 0

prior to f5573e6a0 (tested on b79fef1da) output is:

* 0
* 1
* 2



Re: Bug: org-capture: %L causes arg out of range error for empty string annotation [9.4 (release_9.4-31-g8c44f2 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-25 Thread No Wayman


No Wayman  writes:

If `v-a' is an empty string, the call to `replace-match' throws 
an

Args out of range error. Similar assignments in that area of the
code use an `and' comparison to guard against this, so perhaps 
it

should be:



(v-L (if (and v-a (string-match l-re v-a))
(replace-match "\\1" nil nil v-a)
  v-a))


See attached patch

>From be476c236e40dd0ba87be9d466dd5cd00a6960b7 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 25 Sep 2020 03:42:57 -0400
Subject: [PATCH] capture: Fix bare link "Args out of range"

* lisp/org-capture.el (org-capture-fill-template): guard against empty
annotation string
---
 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 a6e95f24e..67c58ffdd 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1595,7 +1595,7 @@ The template may still contain \"%?\" for cursor positioning."
 	 (v-l (if (and v-a (string-match l-re v-a))
 		  (replace-match "[[\\1]]" nil nil v-a)
 		v-a))
-	 (v-L (if (or v-a (string-match l-re v-a))
+	 (v-L (if (and v-a (string-match l-re v-a))
 		  (replace-match "\\1" nil nil v-a)
 		v-a))
 	 (v-n user-full-name)
-- 
2.28.0



Bug: org-capture: %L causes arg out of range error for empty string annotation [9.4 (release_9.4-31-g8c44f2 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-25 Thread No Wayman



d06aa486d6c3163b6ef6e9ab665117bd93dff34a introduces the following 
in

`org-capture-fill-template':


(v-L (if (or v-a (string-match l-re v-a))
(replace-match "\\1" nil nil v-a)
  v-a))


If `v-a' is an empty string, the call to `replace-match' throws an 
Args out of range error. Similar assignments in that are of the 
code use an `and' comparison to guard against this, so perhaps it 
should be:




(v-L (if (and v-a (string-match l-re v-a))
(replace-match "\\1" nil nil v-a)
  v-a))



Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ 
Version 3.24.23, cairo version 1.17.3)

of 2020-09-19
Package: Org mode version 9.4 (release_9.4-31-g8c44f2 @ 
/home/n/.emacs.d/straight/build/org/)




Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-10 Thread No Wayman




I'll keep researching and see if I can come up with anything.


This is particularly difficult.
When instrumenting `org-add-planning-info` with edebug the 
resulting timestamp always has its time portion (given and/or 
end-time) ignored.

Tried it with both my personal setup and emacs -q. No luck.
I'm more likely to hack around this than figure out a proper 
patch,
though I still consider it a bug that org-schedule is unable to be 
informed by org-time-given and org-end-time-given I originally 
described.




Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-09 Thread No Wayman



Bastien  writes:


No Wayman  writes:

Well, back to square one -- the "fix" breaks setting the end 
time

of an existing schedule timestamp for me with.

I reverted it as 771c66f79.


Unfortunate, but I see the same breakage with the patch. I stepped
through trying to set and end time of an existing schedule 
timestamp

and I think the problem may be in `org-read-date-analyze'.
The sections commented:


   ;; Check if a time range is given as a duration



   ;; Check if there is a time range


Might be where the problem is.
Not 100% on why yet as I don't have deep knowledge of how this 
function is

supposed to work and it is a little opaque. I'll keep researching
and see if I can come up with anything.



Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-08 Thread No Wayman



Kyle Meyer  writes:

As I mentioned in the message linked upstream, it doesn't happen 
when
running just test-org/org-read-date 
(BTEST_RE='test-org/org-read-date'),

so there's some sort of interaction between tests.


Sorry, I was a little late getting to this, and it seems to be 
resolved- but this was my experience as well.

Running just that test didn't seem to fail.



Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-08 Thread No Wayman



Bastien  writes:


Hi No Wayman,

I pushed 4f49ebb6d, a small variant of your initial patch,
which pass the test fine by checking whether the variables
are bound outside or not, ignoring them if not.

Thanks again for the fix!


Sounds good to me! Thanks, Bastien.



Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-08 Thread No Wayman



Jack Kamm  writes:

Also, could you try executing some simple ob-python session 
blocks and

see if they hang? e.g.,

#+begin_src python :session :results output
  print(1+1)
#+end_src

#+begin_src python :session :results value
  1+1
#+end_src


These both work for me now on master as of f17d301e1.
I ran make test and recieved the following output:


1 unexpected results:
  FAILED  test-ob-python/session-multiline


Applied the patch you provided, re-ran make test and recieved:

Ran 862 tests, 862 results as expected, 0 unexpected (2020-09-09 
00:12:49-0400, 15.237936 sec)

12 expected failures


Source blocks executed correctly as well.



Re: idea for capture anywhere in x

2020-09-08 Thread No Wayman



I use a deamon specifically for this. Here's a gist with my setup 
(thought slightly out of date, this will work as a base):


https://gist.github.com/progfolio/af627354f87542879de3ddc30a31adc1



Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-07 Thread No Wayman



Bastien  writes:


If you can investigate why the test broke,
that'd be helpful.  Thanks!


Unfortunately I'm unable to get the test suite to run correctly.
I've followed the instructions in the testing/README, but the 
tests hang due to some sort misconfiguration with python and 
readline on my end:


Warning (python): Your ‘python-shell-interpreter’ doesn’t seem 
to
support readline, yet ‘python-shell-completion-native-enable’ 
was t

and "python" is not part of the
‘python-shell-completion-native-disabled-interpreters’ list. 
Native

completions have been disabled locally.


I'm running Emacs 28.0.5 on Arch linux. Searching for a solution, 
but haven't come up with anything useful yet.
I've tried adding (setq python-shell-completion-native-enable nil) 
in the --eval program from the commandline,
but this only silences the warning. Still hangs. I'll keep 
reseraching.




Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-05 Thread No Wayman



Bastien  writes:


Applied in maint as c7abcd514, thanks.


Thanks, Bastien. I noticed org-end-time-was-given is bound 
similarly.
This binding doesn't affect my usage, but I wonder if it is 
necessary.
If you think it isn't, I'd be happy to submit another patch 
removing it.




Re: time-warping - retroactively marking DONE?

2020-08-29 Thread No Wayman



Adam Spiers  writes:


Many thanks again for this.  It's working great for me!

In case anyone's interested, here's my use-package config (which 
uses

the awesome straight.el package manager to install it):

https://github.com/aspiers/emacs/blob/aa62bd84b51a02cb0fc980862a63514349d253bf/.emacs.d/init.d/as-org-mode.el#L111-L116

I agree with your observation that it might be nicer to separate 
out
the org-specific stuff into a separate package, because the 
epoch

stuff seems useful in its own right outside org-mode.


Thanks for trying it out. There are still some rough edges I have 
to work out, but I plan on working on it more when I get some more 
free time.




Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

2020-08-20 Thread No Wayman


Ihor Radchenko  writes:

As I remember, last time I played with multi-line agenda 
entries, there

were issues with org-agenda-next/previous-item. You may consider
checking if your patch breaks those.


Thanks for the heads up, Ihor. The patch itself shouldn't break
anything and is completely optional behavior, though the example I 
gave in the docstring does.

I ended up faking the newline with the display text-property:


(defun +org-habit-graph-on-own-line (graph)
 "Place org habit consitency graph below the habit."
 (add-text-properties
  (line-beginning-position)
  (line-end-position)
  `(display ,(concat (when-let ((icon (car 
  (org-agenda-get-category-icon

(org-agenda-get-category)

   (format " %s " icon))
 (string-trim-left (thing-at-point 'line))
 (make-string (or org-habit-graph-column 0) ? 
 )
 (propertize graph 'display '(height (+ 
 1)))


This works well for me so far.

I've revised the docstring attachment in the attached patch.

>From 41ee2b974a98e0beac00a8012eab91cec948e6d5 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 20 Aug 2020 13:46:49 -0400
Subject: [PATCH] habit: add custom option for placing consistency graph

* lisp/org-habit.el (org-habit-insert-consistency-graphs): Add
`org-habit-insert-graph-function' defcustom.

Allow user to control consistency graph placement with a customizable
function.  See `org-habit-insert-graph-function` docstring for an
example.
---
 lisp/org-habit.el | 51 +--
 1 file changed, 40 insertions(+), 11 deletions(-)

diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index f76f0f213..55577f442 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -104,6 +104,33 @@ means of creating calendar-based reminders."
   :package-version '(Org . "9.3")
   :safe (lambda (v) (or (integerp v) (null v
 
+(defcustom org-habit-insert-graph-function nil
+  "Function called to place each consistency graph.
+It must accept the graph string as its sole argument.
+It is invoked with point on the current habit's line in the agenda
+buffer, and is responsible for placing point on the line before the
+next habit if point is moved.
+
+For example, to insert graphs on a new line below each habit:
+
+\(setq org-habit-insert-graph-function
+  (lambda (graph)
+\"Place org habit consitency on its own line below the habit.\"
+(add-text-properties
+ (line-beginning-position) (line-end-position)
+ \\=`(display ,(concat
+ (when-let ((icon (car (org-agenda-get-category-icon
+(org-agenda-get-category)
+
+   (format \" %s \" icon))
+ (string-trim-left (thing-at-point \\='line))
+ (make-string (or org-habit-graph-column 0) ? )
+ (insert graph))
+
+If nil, the graph is inserted on the current habit's line at `org-habit-graph-column'."
+  :group 'org-habit
+  :type 'function)
+
 (defface org-habit-clear-face
   'background light)) (:background "#8270f9"))
 (((background dark)) (:background "blue")))
@@ -430,17 +457,19 @@ current time."
   (while (not (eobp))
 	(let ((habit (get-text-property (point) 'org-habit-p)))
 	  (when habit
-	(move-to-column org-habit-graph-column t)
-	(delete-char (min (+ 1 org-habit-preceding-days
- org-habit-following-days)
-			  (- (line-end-position) (point
-	(insert-before-markers
-	 (org-habit-build-graph
-	  habit
-	  (time-subtract moment (days-to-time org-habit-preceding-days))
-	  moment
-	  (time-add moment (days-to-time org-habit-following-days))
-	(forward-line)
+(let ((graph (org-habit-build-graph
+  habit
+  (time-subtract moment (days-to-time org-habit-preceding-days))
+  moment
+  (time-add moment (days-to-time org-habit-following-days)
+  (if (functionp org-habit-insert-graph-function)
+  (funcall org-habit-insert-graph-function graph)
+(move-to-column org-habit-graph-column t)
+(delete-char (min (+ 1 org-habit-preceding-days
+ org-habit-following-days)
+  (- (line-end-position) (point
+(insert-before-markers graph)
+(forward-line)
 
 (defun org-habit-toggle-habits ()
   "Toggle display of habits in an agenda buffer."
-- 
2.28.0



Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

2020-08-20 Thread No Wayman


No Wayman  writes:


It makes this sort of customization very simple


Famous last words. I forgot the agenda relies on text-properties 
for much of its functionality.
I've attached a patch that addresses this and also removes the 
`save-excursion` around the funcall to the custom insertion 
function.
I've noted in the documentation that if the function is moving 
point, it is responsible for making sure it ends up on the line 
before the next habit.


>From 93496b6b86d73a95512c277a1321005d5f1995d1 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 20 Aug 2020 13:46:49 -0400
Subject: [PATCH] habit: add custom option for placing consistency graph

* lisp/org-habit.el (org-habit-insert-consistency-graphs): Add
`org-habit-insert-graph-function' defcustom.

Allow user to control consistency graph placement with a customizable
function.  See `org-habit-insert-graph-function` docstring for an
example.
---
 lisp/org-habit.el | 45 ++---
 1 file changed, 34 insertions(+), 11 deletions(-)

diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index f76f0f213..99dfe8def 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -104,6 +104,27 @@ means of creating calendar-based reminders."
   :package-version '(Org . "9.3")
   :safe (lambda (v) (or (integerp v) (null v
 
+(defcustom org-habit-insert-graph-function nil
+  "Function called to place each consistency graph.
+It must accept the graph string as its sole argument.
+It is invoked with point on the current habit's line in the agenda buffer,
+and is responsible for placing point on the line before the next habit if point is moved.
+
+For example, to insert graphs on a new line below the habit:
+
+  (setq org-habit-insert-graph-function
+(lambda (graph)
+  (let ((props (text-properties-at (point
+(end-of-line)
+;; org-agenda functionality depends on current line's text properties
+(insert (concat \"\\n\" (make-string (1+ (or org-habit-graph-column 0)) ? )))
+(add-text-properties (line-beginning-position) (line-end-position) props)
+(insert graph
+
+If nil, the graph is inserted on the current habit's line at `org-habit-graph-column'."
+  :group 'org-habit
+  :type 'function)
+
 (defface org-habit-clear-face
   'background light)) (:background "#8270f9"))
 (((background dark)) (:background "blue")))
@@ -430,17 +451,19 @@ current time."
   (while (not (eobp))
 	(let ((habit (get-text-property (point) 'org-habit-p)))
 	  (when habit
-	(move-to-column org-habit-graph-column t)
-	(delete-char (min (+ 1 org-habit-preceding-days
- org-habit-following-days)
-			  (- (line-end-position) (point
-	(insert-before-markers
-	 (org-habit-build-graph
-	  habit
-	  (time-subtract moment (days-to-time org-habit-preceding-days))
-	  moment
-	  (time-add moment (days-to-time org-habit-following-days))
-	(forward-line)
+(let ((graph (org-habit-build-graph
+  habit
+  (time-subtract moment (days-to-time org-habit-preceding-days))
+  moment
+  (time-add moment (days-to-time org-habit-following-days)
+  (if (functionp org-habit-insert-graph-function)
+  (funcall org-habit-insert-graph-function graph)
+(move-to-column org-habit-graph-column t)
+(delete-char (min (+ 1 org-habit-preceding-days
+ org-habit-following-days)
+  (- (line-end-position) (point
+(insert-before-markers graph)
+(forward-line)
 
 (defun org-habit-toggle-habits ()
   "Toggle display of habits in an agenda buffer."
-- 
2.28.0



Re: [PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

2020-08-20 Thread No Wayman



No Wayman  writes:

I'm using it now to place each habit's graph on a new line below 
the habit at `org-habit-graph-column'. 


Forgot to mention, this also has the added benefit of not 
displacing the tags on each habit's line.




[PATCH] org-habit: custom consistency graph placement [9.3.7 (release_9.3.7-716-g6d5cab @ /home/n/.emacs.d/straight/build/org/)]

2020-08-20 Thread No Wayman


I like seeing a month long habit consistency graph, but this 
usually overwrites most of the information on each agenda habit 
line unless the window is particularly wide.
The attached patch adds a customizable option to place the graph. 
I'm using it now to place each habit's graph on a new line below 
the habit at `org-habit-graph-column'. It makes this sort of 
customization very simple, e.g.


 (setq org-habit-insert-graph-function
   (lambda (graph)
 (goto-char (point-at-eol))
 (insert "\n")
 (move-to-column org-habit-graph-column t)
 (insert graph)))

Would love to see it included in org-habit.

Thanks,
Nicholas Vollmer

>From 6d5cabcbe15e67873a7ce489e59cff642357d8e6 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 20 Aug 2020 13:46:49 -0400
Subject: [PATCH] habit: add custom option for placing consistency graph

* lisp/org-habit.el (org-habit-insert-consistency-graphs): Add
`org-habit-insert-graph-function' defcustom.

Allow user to control consistency graph placement with a customizable
function.  See `org-habit-insert-graph-function` docstring for an
example.
---
 lisp/org-habit.el | 42 +++---
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/lisp/org-habit.el b/lisp/org-habit.el
index f76f0f213..64d265448 100644
--- a/lisp/org-habit.el
+++ b/lisp/org-habit.el
@@ -104,6 +104,24 @@ means of creating calendar-based reminders."
   :package-version '(Org . "9.3")
   :safe (lambda (v) (or (integerp v) (null v
 
+(defcustom org-habit-insert-graph-function nil
+  "Function called to place each consistency graph.
+It must accept the graph string as its sole argument.
+It is invoked with point on the current habit's line in the agenda buffer.
+
+For example, to insert graphs on a new line below the habit:
+
+  (setq org-habit-insert-graph-function
+(lambda (graph)
+  (goto-char (point-at-eol))
+  (insert \"\\n\")
+  (move-to-column org-habit-graph-column t)
+  (insert graph)))
+
+If nil, the graph is inserted on the current habit's line at `org-habit-graph-column'."
+  :group 'org-habit
+  :type 'function)
+
 (defface org-habit-clear-face
   'background light)) (:background "#8270f9"))
 (((background dark)) (:background "blue")))
@@ -430,17 +448,19 @@ current time."
   (while (not (eobp))
 	(let ((habit (get-text-property (point) 'org-habit-p)))
 	  (when habit
-	(move-to-column org-habit-graph-column t)
-	(delete-char (min (+ 1 org-habit-preceding-days
- org-habit-following-days)
-			  (- (line-end-position) (point
-	(insert-before-markers
-	 (org-habit-build-graph
-	  habit
-	  (time-subtract moment (days-to-time org-habit-preceding-days))
-	  moment
-	  (time-add moment (days-to-time org-habit-following-days))
-	(forward-line)
+(let ((graph (org-habit-build-graph
+  habit
+  (time-subtract moment (days-to-time org-habit-preceding-days))
+  moment
+  (time-add moment (days-to-time org-habit-following-days)
+  (if (functionp org-habit-insert-graph-function)
+  (save-excursion (funcall org-habit-insert-graph-function graph))
+(move-to-column org-habit-graph-column t)
+(delete-char (min (+ 1 org-habit-preceding-days
+ org-habit-following-days)
+  (- (line-end-position) (point
+(insert-before-markers graph
+  (forward-line))
 
 (defun org-habit-toggle-habits ()
   "Toggle display of habits in an agenda buffer."
-- 
2.28.0



[PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-08-18 Thread No Wayman


The current behavior of `org-add-planning-info' does not include 
the time of day when
it is passed the TIME argument. This is because 
`org-time-was-given' is initially let-bound to nil

during the scope of the function.

The attached patch removes that binding and allows the caller to 
pass the time of day in the above case.


An example use case I use with org-capture templates:

(defun +org-schedule-relative-to-deadline ()
 "Prompt for optional deadline, then an optional schedule time.
The scheduled default time is the deadline."
 (interactive)
 (condition-case nil
 (org-deadline nil)
   (quit nil))
 (let ((org-overriding-default-time (or (org-get-deadline-time 
 (point))

org-overriding-default-time)))
   ;; works with patch, but without it the time of day is not 
   included in timestamp.
   (org-schedule nil (org-read-date 'with-time 'to-time nil 
   "SCHEDULE: " org-overriding-default-time


>From 2b0840a3963a16b4b92bfdad794a1327aa6f8bd4 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 18 Aug 2020 17:09:50 -0400
Subject: [PATCH] org: (org-add-planning-info): Respect caller's
 `org-time-was-given' value

* lisp/org.el (org-add-planning-info): Respect caller's `org-time-was-given' value

Allows programmatically passing a time of day to `org-schedule'.

e.g. if one wanted to schedule a task relative to its DEADLINE time of day:

(org-schedule nil (org-read-date t t nil "SCHEDULE: "
 (org-get-deadline-time (point
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index fb95590fc..aabdaebb9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10605,7 +10605,7 @@ among `closed', `deadline', `scheduled' and nil.  TIME indicates
 the time to use.  If none is given, the user is prompted for
 a date.  REMOVE indicates what kind of entries to remove.  An old
 WHAT entry will also be removed."
-  (let (org-time-was-given org-end-time-was-given default-time default-input)
+  (let (org-end-time-was-given default-time default-input)
 (when (and (memq what '(scheduled deadline))
 	   (or (not time)
 		   (and (stringp time)
-- 
2.28.0



Bug: Org bold emphasis gobbles leading stars on next headline [9.3.7 (release_9.3.7-710-g3f04ad @ /home/n/.emacs.d/straight/build/org/)]

2020-08-15 Thread No Wayman



ECM:

With the following Org mode file and point denoted by "|":

* Parent
|
** Sibling

Insert the text "*", resulting in:

* Parent
"*"|
** Sibling

textually, but the final star of the Sibling heading is hidden as 
well:


* Parent
"*"|
  Sibling

I believe the org-hide face is being overridden by the bold face.

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.3, Xaw3d scroll bars)

of 2020-08-12
Package: Org mode version 9.3.7 (release_9.3.7-710-g3f04ad @ 
/home/n/.emacs.d/straight/build/org/)




Re: Bug: eldoc error: (void-function nil) [9.3.7 (release_9.3.7-708-g5417e3 @ /home/n/.emacs.d/straight/build/org/)]

2020-08-15 Thread No Wayman



Kyle Meyer  writes:


Assuming it's fine with you, I'll squash this
into your patch.


Fine by me



Bug: eldoc error: (void-function nil) [9.3.7 (release_9.3.7-708-g5417e3 @ /home/n/.emacs.d/straight/build/org/)]

2020-08-13 Thread No Wayman


The patch to org-eldoc applied in b2b587387 still throws an error:

eldoc error: (void-function nil)

I was unable to step through this because (I think) eldoc causes 
the debugger to close as soon as input is received. The error 
occurs when `eldoc--invoke-strategy` attempts to funcall 
eldoc-documentation-default.


The attached patch works for me, but I do not know if it is the 
correct solution.


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X 
toolkit, cairo version 1.17.3, Xaw3d scroll bars)

of 2020-08-12
Package: Org mode version 9.3.7 (release_9.3.7-708-g5417e3 @ 
/home/n/.emacs.d/straight/build/org/)


>From 45dfdedbce47aa72c9f7f9f146b422236e9b9e23 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Thu, 13 Aug 2020 14:20:05 -0400
Subject: [PATCH] org-eldoc: (org-eldoc-documentation-function): set
 `eldoc-documentation-functions'

* contrib/lisp/org-eldoc.el (org-eldoc-documentation-function):

b2b587387 did not set eldoc-documentation-functions, resulting in
`eldoc--invoke-strategy' throwing a void-fucntion error.
---
 contrib/lisp/org-eldoc.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/contrib/lisp/org-eldoc.el b/contrib/lisp/org-eldoc.el
index aa1dcb41b..ce0b7ddc2 100644
--- a/contrib/lisp/org-eldoc.el
+++ b/contrib/lisp/org-eldoc.el
@@ -138,7 +138,8 @@
  (string= lang "emacs-lisp")
  (string= lang "elisp")) (if (fboundp 'elisp-eldoc-documentation-function)
  (elisp-eldoc-documentation-function)
-   (let (eldoc-documentation-function)
+   (let ((eldoc-documentation-functions
+	  '(elisp-eldoc-var-docstring elisp-eldoc-funcall)))
  (eldoc-print-current-symbol-info
((or
  (string= lang "c") ;; http://github.com/nflath/c-eldoc
-- 
2.28.0



Re: [PATCH] org-get-cursor-date regexp patch

2020-08-09 Thread No Wayman


Makes sense.  IMO it'd be nice to see something along the lines 
of this

explanation in the commit message itself.

The function name is missing here:

* lisp/org.el (org-get-cursor-date): ...


To my eyes, the new variable doesn't add any clarity over 
keeping it

inline.


Addressed in attached patch.

Also, I very much like rx and I'm okay if you want to stick with 
it

here, but in this particular case I find it less readable than

\\([0-9]?[0-9]\\):\\([0-9][0-9]\\)

or the stricter

\\([0-2]?[0-9]\\):\\([0-5][0-9]\\)


Fair enough. My preference for how the regular expression is 
notated does not matter so long as it is the correct expression.

I've inlined your second, stricter regular expression.

>From cad2044829e6d3ff76c2a3504564ed5bfcc36bfb Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 2 Aug 2020 14:42:34 -0400
Subject: [PATCH] org.el: (org-get-cursor-date): Fix regular expression

* lisp/org.el (org-get-cursor-date): Fix regular expression.

Previous regular expression assumed the time grid string will have two
digits in the hour portion of the time string.  However, the time grid
string does not always have two digits.  For example:

" 8:00.."
---
 lisp/org.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ee8be256d..f8dbb6307 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18731,22 +18731,22 @@ earliest time on the cursor date that Org treats as that date
   (let (date day defd tp hod mod)
 (when with-time
   (setq tp (get-text-property (point) 'time))
-  (when (and tp (string-match "\\([0-9][0-9]\\):\\([0-9][0-9]\\)" tp))
+  (when (and tp (string-match "\\([0-2]?[0-9]\\):\\([0-5][0-9]\\)" tp))
 	(setq hod (string-to-number (match-string 1 tp))
-	  mod (string-to-number (match-string 2 tp
+  mod (string-to-number (match-string 2 tp
   (or tp (let ((now (decode-time)))
-	   (setq hod (nth 2 now)
-		 mod (nth 1 now)
+   (setq hod (nth 2 now)
+ mod (nth 1 now)
 (cond
  ((eq major-mode 'calendar-mode)
   (setq date (calendar-cursor-to-date)
-	defd (encode-time 0 (or mod 0) (or hod org-extend-today-until)
-			  (nth 1 date) (nth 0 date) (nth 2 date
+defd (encode-time 0 (or mod 0) (or hod org-extend-today-until)
+  (nth 1 date) (nth 0 date) (nth 2 date
  ((eq major-mode 'org-agenda-mode)
   (setq day (get-text-property (point) 'day))
   (when day
 	(setq date (calendar-gregorian-from-absolute day)
-	  defd (encode-time 0 (or mod 0) (or hod org-extend-today-until)
+  defd (encode-time 0 (or mod 0) (or hod org-extend-today-until)
 (nth 1 date) (nth 0 date) (nth 2 date))
 (or defd (current-time
 
-- 
2.28.0



[PATCH] org-get-cursor-date regexp patch

2020-08-02 Thread No Wayman


The regular expression in `org-get-cursor-date' assumes the time 
grid string will have two digits in the hour portion of the time 
strng.
However, the grid time string does not always have two digits. For 
example:


" 8:00.."

The attached patch accounts for this and uses the rx macro to 
communicate the intent of the regular expression more clearly.


>From 4724b4cc5e9600da60b465c4c2f1968b75c7c31d Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 2 Aug 2020 14:42:34 -0400
Subject: [PATCH] org.el: (org-get-cursor-date): Fix regular expression

* lisp/org.el Fix regular expression.
---
 lisp/org.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ee8be256d..37136cc48 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -18728,10 +18728,11 @@ If WITH-TIME is non-nil, returns the time of the event at point (in
 the agenda) or the current time of the day; otherwise returns the
 earliest time on the cursor date that Org treats as that date
 (bearing in mind `org-extend-today-until')."
-  (let (date day defd tp hod mod)
+  (let ((hhmm-regexp (rx (seq (group (** 1 2 digit)) ":" (group (= 2 digit)
+	date day defd tp hod mod)
 (when with-time
   (setq tp (get-text-property (point) 'time))
-  (when (and tp (string-match "\\([0-9][0-9]\\):\\([0-9][0-9]\\)" tp))
+  (when (and tp (string-match hhmm-regexp tp))
 	(setq hod (string-to-number (match-string 1 tp))
 	  mod (string-to-number (match-string 2 tp
   (or tp (let ((now (decode-time)))
-- 
2.27.0



Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-

2020-08-02 Thread No Wayman


Kyle Meyer  writes:


Would you mind updating the patch to add a
test case along the lines of your ECM to 
test-org-list/toggle-item?


Thanks.


Added the test in the attached patch.
Thanks, Kyle.

~ Nicholas Vollmer

>From 838a6a548396eecfa958161abb66f0a1719a9aef Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 31 Jul 2020 18:38:11 -0400
Subject: [PATCH] org-list: Operate on single line if no active region

* lisp/org-list.el (org-toggle-item): Operate on single line if no
active region.
---
 lisp/org-list.el  | 2 +-
 testing/lisp/test-org-list.el | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index fb061b054..c43630d05 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -3032,7 +3032,7 @@ With a prefix argument ARG, change the region in a single item."
 (if (org-region-active-p)
 	(setq beg (funcall skip-blanks (region-beginning))
 	  end (copy-marker (region-end)))
-  (setq beg (funcall skip-blanks (point-at-bol))
+  (setq beg (point-at-bol)
 	end (copy-marker (point-at-eol
 ;; Depending on the starting line, choose an action on the text
 ;; between BEG and END.
diff --git a/testing/lisp/test-org-list.el b/testing/lisp/test-org-list.el
index abd1a3c83..24a55464d 100644
--- a/testing/lisp/test-org-list.el
+++ b/testing/lisp/test-org-list.el
@@ -1109,6 +1109,13 @@ b. Item 2"
 	  (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:END:\n\n\nText"
 	(org-toggle-item nil)
 	(buffer-string
+  ;; When no region is marked and point is on a blank line
+  ;; only operate on current line
+  (should
+   (equal " \n* H :tag:"
+	  (org-test-with-temp-text " \n* H :tag:"
+	(org-toggle-item nil)
+	(buffer-string
   ;; When a region is marked and first line is a headline, all
   ;; headlines are turned into items.
   (should
-- 
2.27.0



Re: Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-

2020-07-31 Thread No Wayman


I've attached a patch which removes the call to skip-blanks if 
there is no active region.

This works for me with the ECM I've provided.
Not sure if it will have any adverse repercussions outside of 
that.


>From ada4f2a55b7a701aac02d4fc167be4b46e72f2c9 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 31 Jul 2020 18:38:11 -0400
Subject: [PATCH] org-list: Operate on single line if no active region

* lisp/org-list.el (org-toggle-item): Operate on single line if no
active region.
---
 lisp/org-list.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index fb061b054..c43630d05 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -3032,7 +3032,7 @@ With a prefix argument ARG, change the region in a single item."
 (if (org-region-active-p)
 	(setq beg (funcall skip-blanks (region-beginning))
 	  end (copy-marker (region-end)))
-  (setq beg (funcall skip-blanks (point-at-bol))
+  (setq beg (point-at-bol)
 	end (copy-marker (point-at-eol
 ;; Depending on the starting line, choose an action on the text
 ;; between BEG and END.
-- 
2.27.0



Bug: org-toggle-item removes tags from next heading [9.3.7 (release_9.3.7-696-g82b496 @ mixed installation! /home/n/.emacs.d/straight/build/org/ and /home/n/.emacs.d/straight/build/org/eln-x86_64-pc-l

2020-07-31 Thread No Wayman



If `org-toggle-item' is called between the text of an entry and 
the next heading,

it removes the tags from the next heading.

ECM:

With the following Org markup in a buffer and point denoted by 
"|":


#+begin_example
,* First

Some text
|

,** Second :tag:
#+end_example

invoking `org-toggle-item' removes the second heading's tags, 
resulting in:


#+begin_example
,* First

Some text
|

,** Second
#+end_example

`org-toggle-item's documentation claims:

Convert headings or normal lines to items, items to normal 
lines.
If there is no active region, only the current line is 
considered.


Though this doesn't seem to be the case here. There is no active 
region, so I would expect it to do nothing in this case.


I stepped through `org-toggle-item' and I believe it's because of 
the following logic:


 >;; Determine boundaries of changes.
 >(if (org-region-active-p)

(setq beg (funcall skip-blanks (region-beginning))

 >end (copy-marker (region-end)))
   >(setq beg (funcall skip-blanks (point-at-bol))
   >end (copy-marker (point-at-eol

Blank lines are being skipped regardless of whether region is 
active or not.




Re: [Patch] Document org-capture-templates entry type default strings

2020-07-31 Thread No Wayman


Nicolas Goaziou  writes:

Could you send it again with a commit message more in line with 
our
habits (variable modified, etc), and two spaces at the end of 
sentences?


Sorry for the delay.
I've reformatted the patch.

>From cf52a18e4f2ca3c5138975c790fb6baec08d5c87 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 31 Mar 2020 17:39:51 -0400
Subject: [PATCH] capture: Document defualt template strings

* lisp/org-capture.el (org-capture-templates): Document default entry
type template strings.
---
 lisp/org-capture.el | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 2cc1ce394..0ca75c772 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -159,14 +159,20 @@ description  A short string describing the template, will be shown during
 type The type of entry.  Valid types are:
entry   an Org node, with a headline.  Will be filed
as the child of the target entry or as a
-   top-level entry.
+   top-level entry.  Its default template is:
+ \"* %?\n %a\"
itema plain list item, will be placed in the
-   first plain list at the target
-   location.
+   first plain list at the target location.
+   Its default template is:
+ \"- %?\"
checkitem   a checkbox item.  This differs from the
plain list item only in so far as it uses a
-   different default template.
+   different default template.  Its default
+   template is:
+ \"- [ ] %?\"
table-line  a new line in the first table at target location.
+   Its default template is:
+ \"| %? |\"
plain   text to be inserted as it is.
 
 target   Specification of where the captured item should be placed.
@@ -214,9 +220,10 @@ target   Specification of where the captured item should be placed.
 Most general way: write your own function which both visits
 the file and moves point to the right location
 
-template The template for creating the capture item.  If you leave this
- empty, an appropriate default template will be used.  See below
- for more details.  Instead of a string, this may also be one of
+template The template for creating the capture item.
+ If it is an empty string or nil, a default template based on
+ the entry type will be used (see the \"type\" section above).
+ Instead of a string, this may also be one of:
 
  (file \"/path/to/template-file\")
  (function function-returning-the-template)
-- 
2.27.0



Re: [PATCH] org-capture: Update plist before finalizing (Leo Vivier)

2020-07-26 Thread No Wayman



I needed a similar workaround in doct:

https://github.com/progfolio/doct/blob/80d291e5f1cbdabd4eb7f88c917653c59d3f14be/doct.el#L589-L592

I restore `org-capture-plist' to the value of 
`org-capture-current-plist' after the 
`org-capture-before-finalize-hook' is run.


As of: 
https://code.orgmode.org/bzg/org-mode/commit/3ba4f056d736c4ed4261ad3b234e0199edec6e8c
`org-capture-current-plist' is available during all hooks except 
`org-capture-after-finalize-hook'.
So `org-capture-plist' should be ignored in favor of 
`org-capture-current-plist' after the initialization of the 
capture process.
I came to the same conclusion. Restoring `org-capture-plist' after 
finalizing a capture should not cause any harm.




Re: time-warping - retroactively marking DONE?

2020-07-08 Thread No Wayman



I emailed Adam directly with an experimental package I wrote to 
solve the problem of changing the todo-state of an entry at an 
arbitrary time.

He suggested I posted here as well:

https://github.com/progfolio/epoch/

The package advises current-time to return `epoch-current-time' if 
is set (falling back to the usual current-time if not).
A macro, `epoch-with-time' is provided which allows a body to be 
executed with current-time set to an arbitrary time.
Two commands (which I may separate into their own package), 
`epoch-todo' and `epoch-agenda-todo' call their respective 
org-mode commands.
`org-read-date' is called with the tasks's SCHEDULED or DEADLINE 
time pre-populated so one can easily edit relative to that time.


Still very much a work in progress, but the two commands are 
useful for me so far.


Any ideas, suggestions, criticisms are appreciated.



Re: [PATCH] capture: respect KEYS with GOTO arg [9.3.7 (release_9.3.7-661-g4aa4dd @ /home/n/.emacs.d/straight/build/org/)]

2020-07-05 Thread No Wayman



Kyle Meyer  writes:


After applying, I added "lisp/" in front of the file name and
capitalized "pass".

Pushed (99b8f36ab).


Thanks, Kyle. Noted for future patches.



[PATCH] capture: respect KEYS with GOTO arg [9.3.7 (release_9.3.7-661-g4aa4dd @ /home/n/.emacs.d/straight/build/org/)]

2020-07-01 Thread No Wayman


`org-capture' does not pass its KEYS argument to 
`org-capture-goto-target'.
(Must not be a common use-case, as git blame points to 
org-capture's introduction 10 years ago!)


The attached patch does just that.
Wasn't sure if this was worthy of a NEWS entry. Will add if 
needed.


Thanks,
Nicholas Vollmer

>From 4aa4dd120a74679afe33b7fe603035dd0379441a Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Wed, 1 Jul 2020 13:43:29 -0400
Subject: [PATCH] capture: org-capture pass KEYS with GOTO arg

* org-capture.el (org-capture): pass `keys' arg to `org-capture-goto-target'.

Allows programmatically visiting a specific template.
---
 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 cc91251e0..2cc1ce394 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -628,7 +628,7 @@ of the day at point (if any) or the current HH:MM time."
 (setq org-overriding-default-time
 	  (org-get-cursor-date (equal goto 1
   (cond
-   ((equal goto '(4)) (org-capture-goto-target))
+   ((equal goto '(4))  (org-capture-goto-target keys))
((equal goto '(16)) (org-capture-goto-last-stored))
(t
 (let* ((orig-buf (current-buffer))
-- 
2.27.0



[PATCH] etc/ORG-NEWS: fix broken documentation link

2020-06-08 Thread No Wayman


Saw this error after `org-lint'ing ORG-NEWS while I was adding an 
entry for another patch.

The attached patch fixes a broken link for `org-clock-in-last'.

>From f5b6859031d2bf487b26475d84420363b5b29f02 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 8 Jun 2020 14:59:44 -0400
Subject: [PATCH] etc/ORG-NEWS: Fix broken documentation link

---
 etc/ORG-NEWS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f7c898f84..f313b07fe 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -4582,7 +4582,7 @@ See https://orgmode.org/elpa/
 
  You can temporarily activate continuous clocking with =C-u C-u
  C-u M-x= [[doc::org-clock-in][org-clock-in]] =RET= (three universal prefix arguments)
- and =C-u C-u M-x= [[org-clock-in-last][org-clock-in-last]] =RET= (two universal prefix
+ and =C-u C-u M-x= [[doc::org-clock-in-last][org-clock-in-last]] =RET= (two universal prefix
  arguments).
 
 
-- 
2.26.2



Re: [PATCH] Allow org-capture-mode-hook to access org-capture-current-plist [9.3.6 (release_9.3.6-443-g0e8aff @ /home/n/.emacs.d/straight/build/org/)]

2020-06-08 Thread No Wayman


Nicolas Goaziou  writes:


Could you add the modified function in the commit message, add
TINYCHANGE cookie if you haven't signed FSF papers yet, and add 
an entry

in ORG-NEWS about it?


I've modified the commit message and added an ORG-NEWS entry in 
the attached patch.
My FSF papers have recently cleared, so we should be good in that 
regard.


Thanks,
Nicholas Vollmer

>From 0590973aa7d487ed014ed6bcb5db6459b07218ab Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Mon, 8 Jun 2020 14:19:35 -0400
Subject: [PATCH] lisp/org-capture.el: Set `org-capture-current-plist' before
 `org-capture-mode-hook'

* org-capture.el (org-capture-place-template): Allow `org-capture-current-plist' access during `org-capture-mode-hook'

Ensure consistency between org-capture's hooks.
`org-capture-after-finalize-hook' is now the only hook that cannot
access `org-capture-current-plst' because the capture buffer is killed
when it is run.
---
 etc/ORG-NEWS| 1 +
 lisp/org-capture.el | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f7c898f84..8db9db645 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -478,6 +478,7 @@ function, ~org-edit-latex-fragment~. This functions in a comparable
 manner to editing inline source blocks, bringing up a minibuffer set
 to LaTeX mode. The math-mode deliminators are read only.
 
+*** org-capture: ~org-capture-current-plist~ accessible during ~org-capture-mode-hook~
 * Version 9.3
 
 ** Incompatible changes
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 9136d331b..7dde7e194 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1128,8 +1128,8 @@ may have been stored before."
 (`plain (org-capture-place-plain-text))
 (`item (org-capture-place-item))
 (`checkitem (org-capture-place-item)))
-  (org-capture-mode 1)
-  (setq-local org-capture-current-plist org-capture-plist))
+  (setq-local org-capture-current-plist org-capture-plist)
+  (org-capture-mode 1))
 
 (defun org-capture-place-entry ()
   "Place the template as a new Org entry."
-- 
2.26.2



Re: [Patch] Document org-capture-templates entry type default strings

2020-06-03 Thread No Wayman



Bastien  writes:


Hi,

No Wayman  writes:


I assume I'll receive some sort of confirmation from FSF when
everything is processed?


Yes, you should receive a confirmation - if not within a week or 
so,

let me know, sometimes asking again helps.

Best,


Received confirmation. I will submit revisions to open patches 
ASAP.




Re: [Patch] Document org-capture-templates entry type default strings

2020-05-21 Thread No Wayman



Bastien  writes:

People at the FSF may be having difficulties with processing 
these

requests due to the current situation.

If you don't get an answer within a week, I'll send an email to 
see

what delays we can reasonably expect.


Thanks, Bastien. You're probably right re current situation 
slowing things down.

However, things are moving along.
I received the assingment form on 05/06.
Had a bit of a delay on my end with signing.
Sent digitally signed form on the 17th.
I assume I'll receive some sort of confirmation from FSF when 
everything is processed?


I have a couple of outstanding patches Nicolas requested changes 
on.

I will submit revisions once paperwork goes through.



Re: [Bug]: org-capture-place-plain-text error when template :unnarrowed

2020-05-05 Thread No Wayman



Note, the empty string or a nil template do not cause the error.



[Bug]: org-capture-place-plain-text error when template :unnarrowed

2020-05-05 Thread No Wayman



org-capture-place-plain-text throws an error for templates which 
meet the following criteria:

 - entry type is 'plain
 - the template has a non-nil :unnarrowed option
 - the template string is not empty and does not explicitly 
 include "%?"


Seems to be thrown in this section of 
org-capture-place-plain-text:

 #+begin_src emacs-lisp
(when (or (search-backward "%?" beg t)
  (search-forward "%?" end t))
 #+end_src

A minimal failing case:
#+begin_src emacs-lisp
(let ((org-capture-templates
  '(("t" "test" plain (file "/tmp/bug.org")
 "FAIL" :unnarrowed t
 (org-capture nil "t"))
#+end_src

And a minimal passing case:
#+begin_src emacs-lisp
(let ((org-capture-templates
  '(("t" "test" plain (file "/tmp/bug.org")
 "PASS%?" :unnarrowed t
 (org-capture nil "t"))
#+end_src



Re: [Patch] Document org-capture-templates entry type default strings

2020-05-04 Thread No Wayman



Kyle Meyer  writes:

IIRC, when I reviewed another series, you were nearing a number 
of
changes at which we should make sure you've assigned copyright 
to the
FSF.  Assuming you haven't already, please consider doing so 
(see

).

Thanks.


Appreciate the reminder, Kyle. I emailed the form per the 
directions in that link roughly two weeks ago.

Still waiting on the assignment contract.



Re: [Patch] Document org-capture-templates entry type default strings

2020-05-04 Thread No Wayman



No Wayman  writes:


Any interest in this patch?
Apologies, intended this to be a reply to: 
https://lists.gnu.org/archive/html/emacs-orgmode/2020-03/msg00317.html




Re: [Patch] Document org-capture-templates entry type default strings

2020-05-04 Thread No Wayman



Any interest in this patch?



[PATCH] Allow org-capture-mode-hook to access org-capture-current-plist [9.3.6 (release_9.3.6-443-g0e8aff @ /home/n/.emacs.d/straight/build/org/)]

2020-05-03 Thread No Wayman


I'm proposing the following trivial patch to bring more 
consistency to org-capture-mode's hooks.
By setting org-capture-current-plist before invoking 
org-capture-mode in the capture buffer, users
can access the same variable in org-capture-mode-hook as they 
would in org-capture-before-finalize-hook and 
org-capture-prepare-finalize-hook.
org-capture-after-finalize-hook is the only outlier, but that 
makes sense as the capture buffer is no longer current when it 
runs.


~ Nicholas Vollmer

>From 0e8affeaea6034655bbd53faa412eed0826a7933 Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Sun, 3 May 2020 13:20:05 -0400
Subject: [PATCH] Allow org-capture-mode-hook to access
 org-capture-current-plist

Set buffer local org-capture-current-plist before putting capture buffer
in org-capture-mode. Allows hook functions to access the buffer local
version on the plist (consistent with before/prepare-finalize hooks).
---
 lisp/org-capture.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index d292defd6..f650c5473 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1128,8 +1128,8 @@ may have been stored before."
 (`plain (org-capture-place-plain-text))
 (`item (org-capture-place-item))
 (`checkitem (org-capture-place-item)))
-  (org-capture-mode 1)
-  (setq-local org-capture-current-plist org-capture-plist))
+  (setq-local org-capture-current-plist org-capture-plist)
+  (org-capture-mode 1))
 
 (defun org-capture-place-entry ()
   "Place the template as a new Org entry."
-- 
2.26.2



Re: [RFC] DOCT: Declarative Org Capture Templates

2020-04-24 Thread No Wayman



Nicolas Goaziou  writes:


Hello,

No Wayman  writes:


* [RFC] DOCT: Declarative Org Capture Templates


Thank you for your work.


Thank you for taking the time to respond.

Disclaimer: I am only using very basic capture templates. So, I 
cannot
comment realistically on the new syntax you suggest. In 
particular, the
example you give is way too complex for me to understand the 
benefits of
your syntax. I suggest to start out with showing simple 
use-cases.


Apologies, it's hard to strike a balance between showing something 
practical and over-writing.


- Is it compatible with the current syntax? If it isn't, is 
there a way

  to ease transition to the new syntax?


My package translates DOCT's syntax into the current syntax.
I have written a separate package that does basic translation from 
the current syntax to DOCT's as well.

It is not optimal yet, but does work for simple cases.
There are a few features of DOCT (property inheritance, management 
of hooks/contexts) that make it more difficult than just a syntax 
swap.
I could come up with something more fully featured, but in my 
experience thus far, it does not take long to translate from one 
syntax to the other manually.



- Is it simple to use on simple use-cases?


I would say so. There is a single function that does the 
translation. For example:


(doct '("Example" :keys "e" :file ""))

Returns:

(("e" "Example" entry (file "") nil :doct (:doct-name "Example" 
:keys "e" :file "")))


Part of my frustration of writing templates was always having to 
look up the structure of the template list.
Keys, description, type, target (with its variations) and 
template-string (with its variations) is a lot to remember.


Whereas, with:

(doct '("Example" :keys "e" :file ""))

I need only remember that the description comes first. The 
keywords are more self-describing as well.
There's an inherent complexity to the flexibility that org-capture 
offers, but this makes templates easier to write/read.


- Is it more capable than the current syntax, i.e., does it 
handle
  situations that are not possible, even in a convoluted way, 
  currently?



- DOCT validates templates before runtime execution.

For exmaple, you have a template with an entry type of `'entry'
and you forget the leading star in the template string.
Days later you go to use that template. It's borked.


This is different from introducing a new syntax for capture 
templates.


Actually, `org-insert-place-item' and 
`org-capture-place-table-line'

both try to fix misshaped templates already. OTOH
`org-capture-place-entry' merely calls `org-capture-verify-tree' 
on the

template, i.e., it barfs if the template is ill-defined. It is
a discrepancy we could fix independently on your new syntax.

I invite you to propose a patch for `org-capture-place-entry' so 
it does
a better job at fixing the initial template, if needed. I'll 
gladly

apply it.


`org-capture-place-entry' is run after `org-capture' is invoked, 
so while I agree a patch could improve the error, the user still 
hits that error when they are using their capture template 
(defeating the point of org-capture letting you take a quick note 
without losing your current context).
DOCT checks while converting declarations to templates, so the 
error is thrown before org-capture is used (almost like linting 
for templates).


Aside from that, most of what DOCT does is sugar for common use 
patterns I've observed in others' org-capture-templates.

For example, adding per-declaration hooks:

Without DOCT:

;;rest of template configured elsewhere...
;;make sure you update this if you ever change the key for this 
 template!

(defun my-org-template-hook ()
 (when (string= (org-capture-get :key t) "t")
   (message "Template \"t\" selected.")))

(add-hook 'org-capture-mode-hook 'my-org-template-hook)

With DOCT:

(doct `("Example" :keys "t" :file ""
   :hook (lambda () (message "Template %s selected." 
   (doct-get :keys)


DOCT ensures that function is only run for that template without 
having the user manually filter against `org-capture-plist's :key.
It also allows the user to do this inline with the rest of the 
declaration vs spreading it out.




[RFC] DOCT: Declarative Org Capture Templates

2020-04-23 Thread No Wayman

* [RFC] DOCT: Declarative Org Capture Templates

I've been working on an alternative syntax for 
org-capture-templates.
The result is a package called "DOCT" (declarative org capture 
templates):


https://github.com/progfolio/doct

A brief list of what I believe to be improvements over the current 
syntax/implementation:


- DOCT validates templates before runtime execution.

For exmaple, you have a template with an entry type of `'entry' 
and you forget the leading star in the template string.

Days later you go to use that template. It's borked.
You have a number of options:
- forget about whatever you wanted to capture and press on with 
 your original task
- manually take a note about what you originally wanted to capture 
 and another note to fix the broken template

- drop what you're doing and fix everything
None of these are ideal and all of them result in distraction.
DOCT performs a number of checks ahead of time when possible to 
prevent these types of errors.


- DOCT makes the parent/child relationship between templates 
 explicit.


`org-capture-templates` is a flat list. The relationship between 
templates is hardcoded in each template's "keys" value.
If you want to change the key for a top-level menu, you must then 
change it in each descendant's keys. DOCT uses nested plists

and implements property inheritance.

- DOCT manages per-template hooks/contexts.

Currently if you want to have a hook run for a particular 
template, you have to filter against `org-capture-plist' to check 
for the appropriate :key value.
As stated above, this is fragile and you have to update that key 
value in numerous places if it ever changes. The same goes for 
`org-capture-templates-contexts`.
DOCT allows specifying per-template contexts and hooks with the 
rest of the template's configuration.


- DOCT makes adding custom metadata to templates easy.

A common pattern for attaching data to a template is to add to 
`org-capture-plist'. This pollutes `org-capture-plist' more than 
necessary.
DOCT adds custom data to `org-capture-plist' under a single :doct 
keyword and allows users to access that data in the template 
string with familiar %-escape syntax.


This example is one I use daily for taking notes in programming 
projects:


#+begin_src emacs-lisp
(doct
`("Note"
  :keys "n"
  :file ,(defun my/project-note-file ()
   (let ((file (expand-file-name "notes.org" (when 
   (functionp 'projectile-project-root)

   
(projectile-project-root)
 (with-current-buffer (find-file-noselect file)
   (org-mode)
   ;;set to utf-8 because we may be visiting raw file
   (setq buffer-file-coding-system 'utf-8-unix)
   (when-let ((headline (doct-get :headline)))
 (unless (org-find-exact-headline-in-buffer 
 headline)

   (goto-char (point-max))
   (insert "* " headline)
   (org-set-tags (downcase headline
   (unless (file-exists-p file) (write-file file))
   file)))
  :template (lambda () (concat  "* %{todo-state} " (when 
  (y-or-n-p "link?") "%A\n") "%?"))

  :todo-state "TODO"
  :children (("bug"   :keys "b" :headline "Bugs")
 ("documentation" :keys "d" :headline 
 "Documentation")
 ("enhancement"   :keys "e" :headline "Enhancements" 
 :todo-state "IDEA")
 ("feature"   :keys "f" :headline "Features" 
 :todo-state "IDEA")
 ("optimization"  :keys "o" :headline 
 "Optimizations")
 ("miscellaneous" :keys "m" :headline 
 "Miscellaneous")

 ("security"  :keys "s" :headline "Security"
#+end_src

Each template inherits its parent's file finding function,template 
string, and a default :todo-state.
The template string access the child's :todo-state keyword with 
the "%{KEYWORD}" syntax in the template string.


I would be happy to work on getting these features into Org if 
there is any interest.

Any feedback is welcome.

Thanks, nv.


Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

2020-04-07 Thread No Wayman


No Wayman  writes:


Attaching a proper patch with your suggested revisions here.


Sorry, I'm not used to submitting patches through email.
I see it inlined on my end, but it does not appear as if it was 
attached.

Trying once more:

>From 289d3ff93c9f7f56ee54d98fd7d6294c4472a37b Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Tue, 7 Apr 2020 14:39:29 -0400
Subject: [PATCH] org-archive.el: fix org-archive-subtree-save-file-p

Consider case of 'from-org setting in saving logic.
Improve docstring.
Remove dead code comment.
---
 lisp/org-archive.el | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 10a5eb501..5e11c3743 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -92,14 +92,20 @@ When a string, a %s formatter will be replaced by the file name."
 	  (const :tag "Always" t)))
 
 (defcustom org-archive-subtree-save-file-p 'from-org
-  "Non-nil means save the archive file after archiving a subtree."
+  "Conditionally save the archive file after archiving a subtree.
+This variable can be any of the following symbols:
+
+t  saves in all cases.
+`from-org' prevents saving from an agenda-view.
+`from-agenda'  saves only when the archive is initiated from an agenda-view.
+nilprevents saving in all cases."
   :group 'org-archive
   :package-version '(Org . "9.4")
   :type '(choice
-	  (const :tag "Always save the archive buffer" t)
-	  (const :tag "Save target buffer when archiving from an agenda view" from-agenda)
-	  (const :tag "Save target buffer when archiving from an org buffer" from-org)
-	  (const :tag "Do not save the archive buffer")))
+ (const :tag "from-org"from-org)
+ (const :tag "from-agenda" from-agenda)
+ (const :tag "t" t)
+ (const :tag "nil")))
 
 (defcustom org-archive-save-context-info '(time file olpath category todo itags)
   "Parts of context info that should be stored as properties when archiving.
@@ -373,14 +379,13 @@ direct children of this heading."
 		 value
 	  ;; Save and kill the buffer, if it is not the same
 	  ;; buffer and depending on `org-archive-subtree-save-file-p'
-	  (unless (eq this-buffer buffer)
-		(when (or (eq org-archive-subtree-save-file-p t)
-			  (and (boundp 'org-archive-from-agenda)
-			   (eq org-archive-subtree-save-file-p 'from-agenda)))
-		  (save-buffer)))
-	  ;; (unless (or (not org-archive-subtree-save-file-p)
-	  ;; 		  (eq this-buffer buffer))
-	  ;; 	(save-buffer))
+  (unless (eq this-buffer buffer)
+(when (or (eq org-archive-subtree-save-file-p t)
+  (and (boundp 'org-archive-from-agenda)
+   (eq org-archive-subtree-save-file-p 'from-agenda))
+  (and (not (boundp 'org-archive-from-agenda))
+   (eq org-archive-subtree-save-file-p 'from-org)))
+  (save-buffer)))
 	  (widen
 	;; Here we are back in the original buffer.  Everything seems
 	;; to have worked.  So now run hooks, cut the tree and finish
-- 
2.26.0



Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

2020-04-07 Thread No Wayman



Kyle Meyer  writes:

Thanks for the suggestion.  The code is somewhat oddly 
formatted, at
least on my end.  Could you send a proper git-format-patch 
output to

this thread (either via git-send-email or as an attachment)?


Apologies, I pasted that from an Org buffer without reformatting.
Attaching a proper patch with your suggested revisions here.

I suppose the main argument against from-org is that it's not 
clear
from the name alone that it's referring to a non-agenda Org 
buffer
because "org" is of course a bit overloaded. Considered 
alongside

from-agenda, I don't think it's too bad though.



I agree. 'from-org is pretty vague. That, combined with the old 
saving logic was

part of the reason for my initial confusion.
I don't mind keeping it if you feel it's satisfactory, though.
I'm more after the proper functionality.

This current buffer bit also applies to unless-agenda/from-org. 
Perhaps
it'd make sense to just mention the current buffer behavior in 
the main

docstring, given it applies to all options (even though for
only-agenda/from-agenda, it's never the case that the archive 
buffer is

the current buffer).


I've dropped the mention of the current-buffer case in the 
docstring altogether.



In summary

  * I'd prefer to make a more minimal change on top of 
  3d0282ef8,
keeping the names chosen there.  Functionally that comes 
down to
adjusting the condition that guards the save-buffer call to 
consider

from-org.

  * I think it'd be good to expand the docstring (along the 
  lines of
what you suggested) as well as trim and clarify the tag text 
a bit.


Took a look at `org-archive-save-context-info' as you suggested. 
The new docstring is similar to that.




===File 
/home/n/.emacs.d/straight/repos/org/0001-org-archive.el-fix-org-archive-subtree-save-file-p.patch===
From 289d3ff93c9f7f56ee54d98fd7d6294c4472a37b Mon Sep 17 00:00:00 

2001
From: Nicholas Vollmer 
Subject: [PATCH] org-archive.el: fix 
org-archive-subtree-save-file-p


Consider case of 'from-org setting in saving logic.
Improve docstring.
Remove dead code comment.
---
lisp/org-archive.el | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/lisp/org-archive.el b/lisp/org-archive.el
index 10a5eb501..5e11c3743 100644
--- a/lisp/org-archive.el
+++ b/lisp/org-archive.el
@@ -92,14 +92,20 @@ When a string, a %s formatter will be replaced 
by the file name."

  (const :tag "Always" t)))

(defcustom org-archive-subtree-save-file-p 'from-org
-  "Non-nil means save the archive file after archiving a 
  subtree."

+  "Conditionally save the archive file after archiving a subtree.
+This variable can be any of the following symbols:
+
+t  saves in all cases.
+`from-org' prevents saving from an agenda-view.
+`from-agenda'  saves only when the archive is initiated from an 
agenda-view.

+nilprevents saving in all cases."
  :group 'org-archive
  :package-version '(Org . "9.4")
  :type '(choice
- (const :tag "Always save the archive buffer" t)
-	  (const :tag "Save target buffer when archiving from an agenda 
view" from-agenda)
-	  (const :tag "Save target buffer when archiving from an org 
buffer" from-org)

- (const :tag "Do not save the archive buffer")))
+ (const :tag "from-org"from-org)
+ (const :tag "from-agenda" from-agenda)
+ (const :tag "t" t)
+ (const :tag "nil")))

(defcustom org-archive-save-context-info '(time file olpath 
category todo itags)
  "Parts of context info that should be stored as properties when 
  archiving.

@@ -373,14 +379,13 @@ direct children of this heading."
 value
  ;; Save and kill the buffer, if it is not the same
	  ;; buffer and depending on 
`org-archive-subtree-save-file-p'

- (unless (eq this-buffer buffer)
-   (when (or (eq org-archive-subtree-save-file-p t)
- (and (boundp 'org-archive-from-agenda)
-  (eq org-archive-subtree-save-file-p 
'from-agenda)))
- (save-buffer)))
- ;; (unless (or (not org-archive-subtree-save-file-p)
- ;;  (eq this-buffer buffer))
- ;;(save-buffer))
+  (unless (eq this-buffer buffer)
+(when (or (eq org-archive-subtree-save-file-p t)
+  (and (boundp 'org-archive-from-agenda)
+   (eq 
org-archive-subtree-save-file-p 'from-agenda))
+  (and (not (boundp 
'org-archive-from-agenda))
+   (eq 
org-archive-subtree-save-file-p 'from-org)))

+  (save-buffer)))
  (widen
;; Here we are back in the original buffer.  Everything seems
;; to have worked.  So now run hooks, cut the tree and finish
--
2.26.0


Re: Bug: org-archive-subtree-save-file-p logic [9.3.6 (release_9.3.6-399-ge6df03 @ /home/n/.emacs.d/straight/build/org/)]

2020-04-06 Thread No Wayman



Kyle Meyer  writes:

Based on the history above, I believe the main purpose is to 
give users
a way to reverse the "no saving" behavior made in 63f6e851b (Do 
not save
target buffer after archiving subtree, 2017-11-25).  I'm 
_guessing_
that, on top of that, the idea adding a from-agenda value was 
that some
users may want to save only when archiving from the agenda, 
because in
that case they're a bit removed from the buffer and might not 
think to

save it, or something along those lines.


Assuming what I said above is true, I think what you propose 
here loses
the ability to save only when archiving from the agenda.  And 
more
importantly, users would not be able to give a blanket "don't 
save" in
order to retain the behavior introduced by 63f6e851b (Do not 
save target

buffer after archiving subtree, 2017-11-25).



Thanks for the explanation, Kyle. I understand the intent of the 
variable better now.

What do you think of something like this?

#+begin_src emacs-lisp
(defcustom org-archive-subtree-save-file-p 'unless-agenda
 "Conditionally save the archive file after archiving a subtree.
The value 'unless-agenda prevents saving from the agenda-view.
The value 'only-agenda saves only when the archive is initiated 
from the agenda-view.
The value t saves in all cases where the archive target buffer is 
not the current buffer.

The value nil prevents saving in all cases."
 :group 'org-archive
 :package-version '(Org . "9.4")
 :type '(choice
 (const :tag "Do not save archive buffer when archiving 
 from an agenda view" unless-agenda)
 (const :tag "Only save archive buffer when archiving 
 from an agenda view"   only-agenda)
 (const :tag "Save the archive buffer unless it is the 
 current buffer" t)

 (const :tag "Do not save the archive buffer")))
#+end_src

#+begin_src emacs-lisp
;;don't save when target buffer is current buffer
(unless (eq buffer this-buffer)
 ;;t always saves
 (when (or (eq org-archive-subtree-save-file-p t)
   ;;'unless-agenda saves unless archive initiated from 
   agenda
   (and (eq org-archive-subtree-save-file-p 
   'unless-agenda)

(not (boundp 'org-archive-from-agenda)))
   ;;'only-agenda saves iff archive initiated from agenda
   (and (eq org-archive-subtree-save-file-p 'only-agenda)
(boundp 'org-archive-from-agenda)))
   (save-buffer)))
#+end_src

This should result in the following scenarios:

| org-archive-subtree-save-file-p | called-from-agenda? | buffer 
 saved? |

|-+-+---|
| t   | nil | t 
 |
| t   | t   | t 
 |
| only-agenda | nil | nil 
 |
| only-agenda | t   | t 
 |
| unless-agenda   | nil | t 
 |
| unless-agenda   | t   | nil 
 |
| nil | nil | nil 
 |
| nil | t   | nil 
 |




Re: Emacs-orgmode Digest, Vol 170, Issue 5

2020-04-05 Thread No Wayman



Someone on #org-mode (sorry, I cannot remember the nickname) 
reported
that ".+" repeater style was not handling properly (not handling 
at all,

actually) hours spans.

As a reminder, ".+" means "repeat, starting from today as the 
base
date". With hours, it seems logical to "repeat, starting from 
now as the

base date". The attached patch does that.

WDYT?


Great idea! IIUC, this would allow habits to be repeated within a 
day. May use cases spring to mind: stretching, walking, hydration, 
medication, etc.




  1   2   >