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

2021-03-30 Thread Allen Li
Bastien  writes:

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

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

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



Re: [PATCH] Query when exiting with running clock

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

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

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

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

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

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

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

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

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

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

[PATCH] Query when exiting with running clock

2021-01-12 Thread Allen Li

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

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

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

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

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

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

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

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

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

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

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

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

The relevant code in org.el:

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

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

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



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

2020-09-05 Thread Allen Li
On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko  wrote:

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

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

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

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

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

Which would show in the agenda as:

BabelLinks: TODO Finish the text prop org-mode

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

Just my 2 cents.


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


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

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

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

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

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

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



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

2020-08-21 Thread Allen Li
Kyle Meyer  writes:

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

That sounds reasonable, let me prepare a new patch.

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



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

2020-08-18 Thread Allen Li

Example Org file:

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

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

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

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

Attached patch.

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

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

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


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


Re: Delete duplicate subtrees?

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

Maybe this will be useful to you.

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

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

>
> --
> Thanks
> David
>



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

2020-04-07 Thread Allen Li


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

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

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

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

Filter / +foo-bar RET

I expect to see only

TODO foo

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

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

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



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

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

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

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

Can be reproduced with a .org file containing:

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

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



Re: Properties Drawer versus tags

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

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

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

>
> LB



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

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

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

>
> --
> Thanks
> David
>



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

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

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

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

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



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

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

It was removed in commit f1c030bed54737319aeb1d592e3340d6a48cea3a



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

2019-11-12 Thread Allen Li
The docstring for org-agenda-skip-unavailable-files says:

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

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

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

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

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

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

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

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



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

2019-05-14 Thread Allen Li
Repro:

1. emacs -Q
2. Eval:

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

3. Make a tmp.org containing:

* TODO foo
* TODO bar

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

Expected:

agenda tag set on bar entry

Actual:

agenda tag set on foo entry

More info:

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


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



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

2019-04-25 Thread Allen Li
Example variables:

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

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

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

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

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

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

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



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

2019-04-08 Thread Allen Li
Make file /tmp/tmp.org containing:

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

1. emacs -Q
2. Eval

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

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

Contents of tmp.org:

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

Expected:

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

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

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

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

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



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

2019-02-25 Thread Allen Li
Thank you for the comments, attached new patch.

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

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

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

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

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

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

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

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

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

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

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

I have attached a patch implementing this on maint.

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

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

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



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

2019-02-13 Thread Allen Li
Apologies for the spam.

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

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

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



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

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

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

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

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

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

Go back to first cycle.

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

One way to fix is redefine:

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

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

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



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

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

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

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

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



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

2019-02-13 Thread Allen Li
0. Make /tmp/tmp.org containing

* TODO foo bar

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

Expected:

Column format is preserved

Actual:

Column format is reset

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

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



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

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

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

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

>
> Regards,
>
> --
> Nicolas Goaziou



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

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

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

>
> Regards,
>
> --
> Nicolas Goaziou



Re: [O] Package System questions ?

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

>From the NEWS file in emacs master:

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

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

>
> True?
> --
> David
>



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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

>
> Thanks,
> Bernt



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

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

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

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

vs

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

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

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

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

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

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

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

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

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



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

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

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

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

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

>
> Regards,
>
> --
> Nicolas Goaziou



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

2018-12-11 Thread Allen Li
Attached patch

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

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

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

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



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

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

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


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



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

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

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

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

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

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

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

The bounds used by narrowing:

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

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

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

>
> Regards,
>
> --
> Nicolas Goaziou



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

2018-12-10 Thread Allen Li
org-map-entries narrows the buffer to narrower than the given entry.

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

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

2018-12-07 Thread Allen Li
Attached patch fixing this.

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

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

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

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

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

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

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



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

2018-12-07 Thread Allen Li
There's an escaping bug in Org capture:

1. emacs -Q
2. Evaluate:

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

3. Evaluate (require 'org-protocol)

4. Evaluate to simulate org protocol capture:

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

Causes error:

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

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

Note that this works:

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

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



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

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

Sounds good to me.

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



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

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

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

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



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

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

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

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

>
> Regards,
>
> --
> Nicolas Goaziou



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

2018-12-03 Thread Allen Li
(I used org-submit-bug-report, but this is a feature request.)

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

#+begin_example
yanked text

#+end_example

#+begin_example
yanked text#+end_example

>
> Regards,
>
> --
> Nicolas Goaziou



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

2018-10-01 Thread Allen Li
org-insert-structure-template (C-c C-,) leaves point at an inconvenient
place (X marks the spot):

#+begin_example
X#+end_example

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

#+begin_example
X
#+end_example

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



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

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

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

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



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

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

> Hello,

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

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

> Applying the recipe above, I get:

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

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

Thanks for the quick fix.




> Regards,

> --
> Nicolas Goaziou



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

2018-02-27 Thread Allen Li
On Mon, Feb 26, 2018 at 3:11 PM Nicolas Goaziou <m...@nicolasgoaziou.fr>
wrote:

> Hello,

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

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

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

No, the issue still exists.


> Thank you.

> Regards,

> --
> Nicolas Goaziou



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

2018-02-26 Thread Allen Li
On Mon, Feb 26, 2018 at 5:54 PM Samuel Wales  wrote:

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

> real questions, fyi, but never mind.

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

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

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

> i care just what project i am in.

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

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

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

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

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

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

> i presume you mean:

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

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

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

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

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

> i'm ok with removing the binding.

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

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

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

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

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

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

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



> thank you for engaging.



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

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

> Hello,

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

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

> I can reproduce it.

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

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

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

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

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

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

Folded, this looks like

* foo...
* bar...

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

* bar
* foo...

Unfolded, this looks like

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

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



> Is there any good solution to this problem?

> Regards,

> --
> Nicolas Goaziou



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

2018-02-13 Thread Allen Li
With the org file:

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

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

Final content is

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

The behavior is insidious when the contents are folded:

* foo...
* bar...

turns into

* bar...
* foo...

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

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

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



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

2018-02-09 Thread Allen Li
Thanks, your new patch looks acceptable to me.


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

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


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

2018-02-07 Thread Allen Li
On Wed, Feb 7, 2018 at 1:47 PM Matt Lundin  wrote:

> Matt Lundin  writes:

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

> The attached patch fixes this issue.

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

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

C-h C-k M-S-

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

It is bound to .

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



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

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

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

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

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

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



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

2018-01-29 Thread Allen Li
I was not aware Org had its own mark ring, and I see no use for it
personally when Emacs's mark ring exists.

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



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

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

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

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

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

Actual:

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

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



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

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

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



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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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

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

>
> --
> Nick
>
>



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

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

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

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

There is always undo and automatic Emacs file backups.

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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



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

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

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

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



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

2017-12-31 Thread Allen Li
I wrote a command to remove duplicate subheadings, which I use to
remove duplicate captured links among other things.  Would this be a
useful addition to Org mode?

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

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



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

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

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

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



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

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

Oops, done.  Attached new patch.

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

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

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

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

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

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



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

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

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

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

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

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



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

2017-12-30 Thread Allen Li
Doing a text agenda search with org-agenda-text-search-extra-files
set to (agenda-archives) and with a buffer restriction results in an error:

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


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



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

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

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



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

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

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

The original thread (which is long-winded):

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

The second bug, also timezone issues:

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



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

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

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

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

Archiving to a separate file yields:

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

Archiving to a subtree yields:

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

BUT if the Archive heading isn’t last:

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

Archiving to a separate file yields:

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

Archiving to a subtree yields:

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

The implementation is painfully inconsistent.



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

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

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

* ^Heading

M-S-left/right works here.

* Heading
^content text

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

* Heading

- foo
  - bar
^second bar line

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

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

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



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

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

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





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

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

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

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

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

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



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

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

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

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

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

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

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

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





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

2017-12-06 Thread Allen Li
(Can reproduce with Org 9.1.3, submitting with emacs -Q)

Using a file tmp.org:

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

This appears like so with default visibility:

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

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

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

Expected visibility:

  * Foo
  ** Archive :ARCHIVE:...

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



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

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

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

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

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

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

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





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

2017-12-06 Thread Allen Li






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

2017-12-03 Thread Allen Li
org-attach-directory should be safe to set as a file local or
directory local string.

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

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

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

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



[O] Org mode bug submission and viewing?

2017-12-01 Thread Allen Li
What's the proper way to submit an Org mode bug, and are the bugs
collected anywhere for viewing their status?

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

Is there a preferred way to submit bugs?

Where are the numbered bugs coming from?

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



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

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

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

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





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

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

There's an additional quirk to this behavior:

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


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

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



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

2017-11-20 Thread Allen Li
Create a file tmp.org with contents

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

1. emacs -Q
2. M-: (setq org-enforce-todo-dependencies t) RET
3. C-x C-f tmp.org RET
4. Move point to grandchild2
5. C-c C-t

user-error: TODO state change from TODO to DONE blocked (by "TODO child1")

The documentation emphasizes that ORDERED is not inherited.  The
behavior that I would expect is that child1 blocks child2, but it should
not block grandchild1 or grandchild2.

However, I think the current behavior is also reasonable under some
workflows.  I’m creating a bug to track opinions, if one behavior is
significantly more desired than the other, or if an option to control
this behavior would be welcome.

Emacs  : GNU Emacs 25.2.50.1 (x86_64-pc-linux-gnu, GTK+ Version
3.22.11), modified by Debian
Package: Org mode version 9.1.3 (9.1.3-elpaplus @
/usr/local/google/home/ayatane/.emacs.d/elpa/org-plus-contrib-20171116/)



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 9:56 PM, Tim Cross  wrote:
>
> OK, thanks for the additional information. That helps a lot.
>
> We can now narrow down where the issue is.
>
> After having looked (only very casually) at some of the org date/time
> related functions, I think there may be quite a few issues. I'm not
> convinced the root cause is org-2ft converting to UTC, though I think
> that change has probably revealed some of the issues.
>
> There does seem to be some inconsistency or lack of clarity regarding
> some of these operations and it could well be that the switch to using
> UTC is not the correct approach, but just switching back probably isn't
> either What does appear to be required is increased consistency in some
> of these functions or where/how they are used. .

Thanks.  I think I have been harping a bit too hard on org-2ft, but
indeed it seems to be a bit more systemic an issue.

> To correctly fix this, I feel more analysis is warranted. I'm prepared
> to look at this and present a summary and options, but it will have to
> wait until after 21st when I start leave from work. It is a complex area
> and perhaps my skills won't be up to it, but I should at least be able
> to identify the main areas needing attention/decisions.

My initial approach would be to do some refactoring here, especially
among org-2ft, org-matcher-time, and org-parse-time-string, each of
which calls the others in a cycle and each share a part of the logic
for interpreting Org mode timestamps.

I'm not familiar with refactoring FOSS code via mailed patches, nor if
Org maintainers would welcome such patches, but I would be willing to
do some refactoring here.

>
> Whether we should change back to non-UTC for time comparisons in the
> meantime is not something I feel informed enough to make a call. It
> really depends on the daylight savings time related issues affecting
> clock tables and other functionality.  This is probably something core
> org maintainers will need to make a call on.
>
> Tim



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
Sorry for the spam, but I am digging to see how deep the rabbit hole goes.

All five of the first branches in org-matcher-time are wrong (again,
local timezone dependent):

(org-time= "<2017-11-01>" "")
nil
(org-time= "<2017-10-31>" "")
nil
(org-time= "<2017-11-02>" "")
nil
(org-time= "<2017-11-02>" "<+1d>")
nil

For my immediate bug, all that is needed is a small fix to
org-time-today and modifying the call to float-time in
org-matcher-time.

However, there are a lot of float-time calls in Org mode, and I don't
know how many of them need to be modified to return org-2ft time
shifted timestamps instead of UTC Unix timestamps.



[O] Bug: org-parse-time-string et al hit recursion limit [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
Running (org-parse-time-string "<@@@>") results in hitting max-lisp-eval-depth

org-parse-time-string calls org-matcher-time calls org-2ft calls
org-parse-time-string

There is a condition-case in org-2ft that catches the error and
returns 0, but it would be nice if this wasn't implemented via hitting
the recursion limit.



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
I found another one (It is 2017-11-01 in local time for me)

(org-time= "<2017-11-01>" "")
nil

This is also local timezone dependent.

Tim made the point that these floats are not intended to be Unix
timestamps and only used for comparison, but this implementation
detail leaks quite heavily.  Furthermore, the value returned by
org-2ft for these comparisons isn't even constant.

For example (org-2ft "<2017-10-10 10:00:00>") returns 1507629600.0 for
me today, but in four days it will return a different value,
1507626000.0.  Surprise, the offset from local time to UTC is not
constant, even on the same machine in the same timezone.

The most immediate impact of this is that all of Org mode's time
comparison functions will be wrong when called during a local time
offset change.  For those of us who are lucky, this may be twice a
year, but for others who are unlucky, it may be multiple times per
year or month, up to the whims of the local government.

This is one of the reasons I think "we're just using them for
comparisons" doesn't excuse org-2ft doing its little time shift.  The
other reason is all of the regressions that change caused, including
this current bug, and yet another is my gut instinct that this is a
poor design choice from a technical perspective as a software
engineer.



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 8:27 PM, Tim Cross  wrote:
>
> I get that, what I am not clear about is where you encounter this issue
> when using org .eg. is it when entering now as a date for generating an
> agenda of past or current scheduled items etc or is this a problem with
> some custom functions you have written where you need to enter 'now'
> manually and due to the use of UTC in time comparisons are forced to
> adjust manually for UTC or something else? This is what is not
> clear. From my own use, I don't see the issue you describe with
> scheduled items not appearing or appearing when they shouldn't, so don't
> know how to reproduce the issue your having i.e. when I do agenda
> searches, I don't see deadline or scheduled items showing up when they
> should not etc.

It is when doing any kind of tag search.  So org-agenda, mostly.

I'm not surprised you cannot reproduce it because it is dependent on
your local timezone.

>
> This matters because if the issue is the former, then we likely do have
> a real bug. However, if it is the latter, then it may be a bug or it may
> be just an implementation weakness or it could just be a difference of
> opinions on how it should be.
>
> Your examples don't clarify what the issue is. It is obvious that if we
> convert times to UTC for calculation purposes that this will affect the
> display of those timestamps, but as far as I can tell, org doesn't
> convert back and use those converted values in any visible way. Provided
> all values are converted consistently, it should not matter. Therefore,
> if there is a problem, then something must not be getting converted
> correctly, but it is not possible to narrow down where this is without
> more info.

Ah, perhaps I should make the issue clearer.

When I run this at 2017-11-01 20:55:30

(org-2ft "")
1509594900.0

(org-2ft "<2017-11-01 20:55:30>")
1509569700.0

Therefore when org.el does a tag search for SCHEDULED="", it will
not match <2017-11-01 20:55:30>, assuming that I have frozen my system
clock to that time.

>
> If you can provide an ECM then we can avoid assumptions and different
> interpretations and focus on the issue.

Again, this is dependent on your local time zone.  Try setting your
time zone to America/Los_Angeles.

1. emacs -Q
2. Assume it is 2017-10-10 12:00:00 local time
3. Create an agenda file

* TODO thing
SCHEDULED:<2017-10-10 13:00:00>

4. M-x org-agenda RET m SCHEDULED>""

Expected:

thing shows up

Actual:

thing does not show up

>
> Tim
>
> --
> Tim Cross



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 5:09 PM, Tim Cross <theophil...@gmail.com> wrote:
>
> Let me try to clarify and see if that helps.
>
> Org is only forcing time into UTC format for functions which deal with
> time comparisons. i.e. those which use org-2ft. The reason for doing
> this is to try and avoid issues relating to daylight savings timezone
> changes when performing comparison operations.
>
> It is not clear to me exactly how this is actually creating a problem
> for your scenario as there does not seem to be anywhere in org where
> values created by org-2ft are converted back to human readable time
> strings. If you can provide more details on how this is a practical
> issue in org-mode that might help.

I think I made the problem quite clear multiple times.

Assuming today is 2017-10-31, SCHEDULED<"" will match results
that have SCHEDULED=<2017-11-01> depending on your local time zone.

>
> I do think there was an error in your example analysis.
>
> In your examples of
>
> (current-time-string (float-time))
> "Mon Oct 30 21:21:31 2017" ; right
>
> (current-time-string (org-time-today))
> "Mon Oct 30 00:00:00 2017" ; right
>
> (current-time-string (org-2ft "<2017-10-31>"))
> "Mon Oct 30 17:00:00 2017" ; wrong
>
> the last one is only wrong because you have failed to tell
> current-time-string that the value you are converting is a UTC time. If
> you change the code to
>
> (current-time-string (org-2ft "<2017-10-31>") "UTC")
> "Mon Oct 30 00:00:00 2017" ; correct

No, that is wrong. Mon Oct 30 00:00:00 2017 UTC != Mon Oct 30 00:00:00
2017 UTC-7

(format-time-string "%FT%T%z" (org-2ft "<2017-10-31>"))
"2017-10-30T17:00:00+0700" ; wrong
(format-time-string "%FT%T%z" (org-2ft "<2017-10-31>") "UTC")
"2017-10-31T00:00:00+" ; wrong

In fact, you haven't solved a thing, since (current-time-string
(org-2ft "<2017-10-31>") "UTC") == (current-time-string (org-2ft
"<2017-10-31>"))  The time is still the same, and still wrong, just
formatted differently if you silently drop the TZ info from the time
string.

>
> Now, considering your suggestion to change org-2ft to not use UTC.
>
> If we change org-2ft to not use UTC time, we end up with time
> related calculations which cross daylight savings boarders becoming
> incorrect. So, if you have a clock table where you want to calculate the
> number of hours between two timestamps and one is within daylgiht
> savings time and the other is outside it, your calculation will be out
> by an hour.

Or rather, we end up with time related calculations which cross
daylight savings becoming correct.

But I am beginning to see the picture; someone wanted time related
calculations crossing DST to be incorrect to appear "right" to time
zone naive applications.

>
> As org-2ft is not used in conversion of 'epoch' time to times strings by
> org, I'm not sure reverting the change gains us anything and will likely
> adversely impact things like clock table calculations. What may be
> justified is to add a note to the manual which clearly states that if
> you are using org-2ft in your own code and plan to convert the result
> back to a timestamp string, you need to ensure you explicitly tell the
> function performing the conversion the input value is in UTC and not
> local time.

Yes, org-2ft documentation should be updated at the very least,
assuming that this behavior is desired.

>
> I agree that enhancing org timestamps to include TZ information would be
> a non-trivial chunk of work, I do feel it is the only solid way to
> address all of these issues. I suspect there are still edge cases in
> time related computations which fail even with the UTC approach and
> there are certainly extensions which could benefit from explicit TZ
> information (for example, taskgjuggler, which does time calculations for
> planning and where such calculations can easily cross multiple daylight
> savings TZ changes or include operations covering different timezones
> etc).
>
> Tim
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> Apologies, my reply was partially omitted.  My full reply follows
>>
>> On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross <theophil...@gmail.com> wrote:
>>>
>>> Allen Li <vianchielfa...@gmail.com> writes:
>>>
>>>> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> wrote:
>>>>>
>>>>> My preferences would be
>>>>>
>>>>> 1. If a timestamp does not include the TZ, then assume the local TZ
>>&g

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 1:55 PM, Nicolas Goaziou  wrote:
>
> IIRC, the point is to remove DST in durations, i.e., in the difference
> between two dates. One way to do that is to assume UTC in both start end
> end date. Most of the commits are about making sure UTC is used whenever
> two Org dates are to be used in a duration computation, and nowhere
> else.

Alas, I still can't seem to find the original DST bug.  I'm not sure
using UTC solves DST problems.

For example, in the timezone America/Los_Angeles,

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour

This is what Emacs gives me using the default time zone

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 4 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 2 hour

This is what Emacs gives me using UTC

<2017-11-05 01:00:00> -> <2017-11-05 04:00:00> = 3 hours
<2017-10-10 01:00:00> -> <2017-10-10 04:00:00> = 3 hours
<2017-03-12 01:00:00> -> <2017-03-12 04:00:00> = 3 hours

Using UTC seems strictly wrong to me.

>
> I think the change to org-2ft was a side-effect, since it is indirectly
> used is a duration.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
Apologies, my reply was partially omitted.  My full reply follows

On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross <theophil...@gmail.com> wrote:
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> wrote:
>>>
>>> My preferences would be
>>>
>>> 1. If a timestamp does not include the TZ, then assume the local TZ
>>> 2. If a timestamp does include the TZ, honour that TZ
>>
>> Org mode does not support TZ in time strings and adding support isn't
>> the topic of the current bug.
>>
>
> I disagree. The root cause of the bug is due to a lack of clarity
> regarding timezones. I also suspect this is also the basic cause of
> issues relating to the use of timestamps/time strings and daylight
> savings, especially when it comes to performing calculations etc.

Unless I missed something, Org mode does not support explicit
timezones in Org timestamps, and adding such support would take a
large effort [1].

[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00299.html

Unfortunately, I do not have time for the task.  Thus, Org mode
will have to make due with only Org timestamps without an
explicit timezone unless a savior appears.

>
>> I want to emphasize the distinction between timestamps and time
>> strings.  Timestamps are a
>> float value, Unix timestamps.  Time strings are Org mode specific,
>> like <2017-10-30 12:34:56>
>
> Org mode refers to what you are calling time strings as timestamps. In
> reality, there is no difference - one is just a numeric representation
> and the other is a string representation. It is good you have clarified
> your definition to reduce confusion. However, I think the problems are
> arising because of a lack of explicit TZ handling.

There's a pretty significant difference.  Unix timestamps are
standardized and used widely by most computers and Emacs itself.
Unix timestamps are time zone agnostics.

Org timestamps (time strings, whatever) are used exclusively by
Org mode.  As Org timestamps do not support explicit timezones,
they are not time zone agnostic.  The interpretation of an Org
timestamp depends on the time zone of the local machine, whereas
the interpretation of a Unix timestamp does not depend on the
time zone of the local machine.

>
>>
>> Timestamps do not have timezone information since they describe an
>> exact (well, minus leap seconds)
>> point in time, the number of seconds after the epoch.
>>
>
> A point in time is measured in number of seconds since epoch. However,
> if you want to use local (wall) time to display that point, you have to
> include TZ information when converting that number to a more
> meaningful/usable (for humans) format.

I'm not sure what you mean.  Time zone information is provided by
the local machine OS.  If I pass a Unix timestamp to Emacs/the OS
and tell it to format it in human readable format in the local
time zone (the default behavior), then it will be done, without
my having to attach time zone information anywhere.

> The point 'now' for me is UTC+1100
> and for you (based on your previous post) UTC-0700, so our
> representations in string format of this value will be different. Even
> on a single machine, it is also relevant. For example, if I have two org
> timestamps (your times strings) and I want to calculate the number of
> hours between the two, I need to include TZ information as one timestamp
> might be during daylight savings time and the other outside daylight
> savings time.

Ideally, except Org mode does not support including explicit TZ
information in Org timestamps.  Thus, Org mode can only current
interpret Org timestamps according to some blessed time zone.
Four months ago, that blessed time zone changed from the local
machine's time zone to UTC.

> Any calculation which fails to consider TZ information in
> this case will be out by an hour.
>
> If we just take the simple solution and ignore TZ information,

Org timestamps do not have TZ information.  It's not a matter of
not ignoring TZ information, support for TZ information would
have to be added, which as I understand is non-trivial.

> we will
> break calculations which cross daylight savings 'boarders'. I also
> suspect we will get inconsistent behaviour when integrating with other
> systems (such as external calendars, ical integration or sharing
> timestamp data with others etc).

As long as we use Unix timestamps when integrating with other
systems, there is no ambiguity.

>
>>> 3. If the timestamp does not include a time component, default to 0:00:0
>>
>> This is what Org mode does
>>
>>> for the local TZ
>>
>> This is what Org mode used to do, now it interprets 

Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 6:09 AM, Tim Cross <theophil...@gmail.com> wrote:
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross <theophil...@gmail.com> wrote:
>>>
>>> My preferences would be
>>>
>>> 1. If a timestamp does not include the TZ, then assume the local TZ
>>> 2. If a timestamp does include the TZ, honour that TZ
>>
>> Org mode does not support TZ in time strings and adding support isn't
>> the topic of the current bug.
>>
>
> I disagree. The root cause of the bug is due to a lack of clarity
> regarding timezones. I also suspect this is also the basic cause of
> issues relating to the use of timestamps/time strings and daylight
> savings, especially when it comes to performing calculations etc.

Unless I missed something, Org mode does not support explicit
timezones in Org timestamps, and adding such support would take a
large effort [1].

[1]: https://lists.gnu.org/archive/html/emacs-orgmode/2011-04/msg00299.html

Unfortunately, I do not have time for the task.  Thus, Org mode
will have to make due with only Org timestamps without an
explicit timezone unless a savior appears.

>
>> I want to emphasize the distinction between timestamps and time
>> strings.  Timestamps are a
>> float value, Unix timestamps.  Time strings are Org mode specific,
>> like <2017-10-30 12:34:56>
>
> Org mode refers to what you are calling time strings as timestamps. In
> reality, there is no difference - one is just a numeric representation
> and the other is a string representation. It is good you have clarified
> your definition to reduce confusion. However, I think the problems are
> arising because of a lack of explicit TZ handling.

There's a pretty significant difference.  Unix timestamps are
standardized and used widely by most computers and Emacs itself.
Unix timestamps are time zone agnostics.

Org timestamps (time strings, whatever) are used exclusively by
Org mode.  As Org timestamps do not support explicit timezones,
they are not time zone agnostic.  The interpretation of an Org
timestamp depends on the time zone of the local machine, whereas
the interpretation of a Unix timestamp does not depend on the
time zone of the local machine.

>
>>
>> Timestamps do not have timezone information since they describe an
>> exact (well, minus leap seconds)
>> point in time, the number of seconds after the epoch.
>>
>
> A point in time is measured in number of seconds since epoch. However,
> if you want to use local (wall) time to display that point, you have to
> include TZ information when converting that number to a more
> meaningful/usable (for humans) format.

I'm not sure what you mean.  Time zone information is provided by
the local machine OS.  If I pass a Unix timestamp to Emacs/the OS
and tell it to format it in human readable format in the local
time zone (the default behavior), then it will be done, without
my having to attach time zone information anywhere.

> The point 'now' for me is UTC+1100
> and for you (based on your previous post) UTC-0700, so our
> representations in string format of this value will be different. Even
> on a single machine, it is also relevant. For example, if I have two org
> timestamps (your times strings) and I want to calculate the number of
> hours between the two, I need to include TZ information as one timestamp
> might be during daylight savings time and the other outside daylight
> savings time.

Ideally, except Org mode does not support including explicit TZ
information in Org timestamps.  Thus, Org mode can only current
interpret Org timestamps according to some blessed time zone.
Four months ago, that blessed time zone changed from the local
machine's time zone to UTC.



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Wed, Nov 1, 2017 at 12:18 AM, Tim Cross  wrote:
>
> My preferences would be
>
> 1. If a timestamp does not include the TZ, then assume the local TZ
> 2. If a timestamp does include the TZ, honour that TZ

Org mode does not support TZ in time strings and adding support isn't
the topic of the current bug.

I want to emphasize the distinction between timestamps and time
strings.  Timestamps are a
float value, Unix timestamps.  Time strings are Org mode specific,
like <2017-10-30 12:34:56>

Timestamps do not have timezone information since they describe an
exact (well, minus leap seconds)
point in time, the number of seconds after the epoch.

> 3. If the timestamp does not include a time component, default to 0:00:0

This is what Org mode does

> for the local TZ

This is what Org mode used to do, now it interprets it as 00:00:00 UTC.

> 4. org-2ft should not enforce the UTC TZ. I agree this is incorrect.
>
> Rationale is that the user should have ability to fully control how
> their timestamps are represented. However, adding the TZ is probably
> just a pain for the majority of use cases, so defaulting to the local
> (wall) TZ is OK provided you can override this consistently by adding
> explicit TZ values.
>
> However, there is some devil in the details we need to work out. For
> example, should we support both TZ names (like AEDT or Australia/Sydney)
> and POSIX style +11/+11:00/+1100, should we add an option to tell org to
> always add TZ info in timestamps which include time components and if
> so, how complex will this need to be e.g. handle setting a future/past
> timestamp which is in a different (daylight savings) offset and what
> about the additional complexity in dealing with timestamp calculations
> where dates might be in different offsets due to daylight savings -
> while all quite possible, it does add significant complexity and this
> may have adverse impact on performance. Not to say we shouldn't do it,
> just that it will take significant work.
>
> I suspect just the first part won't have major impact - at least no more
> than enforcing UTC in org-2ft.

Org mode does not support TZ in time strings currently.  While I would
like such a feature very much,
adding TZ support isn't the topic of the current bug, just fixing how
time strings are interpreted.

>
> Tim
>
> P.S. when you start to think about it, it is easy to see how Java
> screwed up this stuff so badly!



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-11-01 Thread Allen Li
On Tue, Oct 31, 2017 at 10:41 PM, Tim Cross  wrote:
>
> I think this whole issue really requires a lot more analysis and
> design. Just removing or cancelling various commits is unlikely to
> improve matters and could result in new problems.

You're right, but the new behavior was introduced fairly recently.

> For org to work correctly, especially when interacting/interfacing with
> other systems, such as external calendars, the use of timestamps must
> handle timezones consistently and accurately. This is the only way that
> any daylight savings calculations will work consistently as different
> timezones have different rules for when daylight savings start/finish
> (and these rules change).
>
> If the tests only support UTC/GMT timezone, they are poor tests and need
> to be adjusted to use whatever the timezone is on the system running the
> tests.
>
> I also wonder if there is some inconsistencies in how timestamps without
> a time component are being handled. It would be good to know if the
> issues Alan has observed exist when a full timestamp is used ie. one
> with HH:MM:SS.s and not just date. If timezones are not been applied
> consistently when choosing the default i.e. 00:00:00.0 with respect to
> timezone offset, you will get inconsistencies when moving between
> displayed (string) and calculated (number/seconds since epoch) values.

I think we first need to agree on how Org mode should handle
time.  What seems most natural to me is:

* Floating point timestamps are Unix timestamps, seconds since Epoch.
* Org format time strings are interpreted in the local machine's time zone.

Let us assume that my timezone is UTC-07.  In that case,
<2017-10-30> should be interpreted as 2017-10-30T00:00:00-0700,
or 2017-10-30T07:00:00+.

<2017-10-30>1509346800.02017-10-30T00:00:00-0700
 2017-10-30T07:00:00+
<2017-10-30 12:34>  1509392040.02017-10-30T12:34:00-0700
 2017-10-30T19:34:00+

Currently, org-2ft returns:

<2017-10-30>1509321600.02017-10-29T17:00:00-0700
 2017-10-30T00:00:00+
<2017-10-30 12:34>  1509366840.02017-10-30T05:34:00-0700
 2017-10-30T12:34:00+

This is because org-2ft calls org-parse-time-string with t for
zone, i.e. parse the time string as though it were UTC.  That
should be apparent from the last column.

Hopefully, we can agree that the former is the desired behavior.
Working on this assumption, org-2ft should be changed to the
original behavior, i.e., to not parse time strings as UTC.

The question then becomes, what breaks if we just naively change
org-2ft?  The new behavior was only added to org-2ft four months
ago, so worst case is reverting every time-related change in the
interim puts us back four months in time-related logic.

But looking through the history, most of the time-related changes
in the interim were to fix regressions caused by the initial
logic change.  If we revert the original "regression", then those
interim changes are also not needed.



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-10-31 Thread Allen Li
 On Tue, Oct 31, 2017 at 11:52 AM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> Can you clarify on the issues the UTC timezone fixes?
>
> At the moment, I can only give you a pointer, which is commit
> 97a1a498956da2e1961df5a0506df4cbb98fff52. Some other commits followed
> this one in maint and master.
>
> You may want to check the ML for the initial bug report.

Bisecting on maint shows that this regression happened at
cc5a9bf538a4a7eb1b84d368336c46cead106e01

I tested using this command:

find . -name "*.elc" -delete; emacs -Q --batch --eval "(add-to-list
'load-path default-directory)" --eval "(require 'org)" --eval "(princ
(current-time-string (org-2ft \"<2017-10-31>\")))"

I guess the relevant bug is
http://lists.gnu.org/archive/html/emacs-orgmode/2017-07/msg00097.html,
but oddly enough, I cannot reproduce that bug at
cc5a9bf538a4a7eb1b84d368336c46cead106e01~1

>From what I can glean from the history,
112c5ba479d52c3c36de5c7aafd14ab6bc075005 is where things started to go
wrong.  UTC timezone was added to tests.  From there, a number of
commits were added to fix regressions.

The problem is that the tests were made to assume UTC timezone and Org
mode was changed to also use UTC timezone to make the tests pass;
however, this means that org.el no longer works for non-UTC time
zones.

That commit's message (112c5ba479d52c3c36de5c7aafd14ab6bc075005) also
seems suspect.  It claims to be removing DST offset by enforcing UTC.
That could only be true for people using GMT.  In GMT during DST,
enforcing UTC would "remove" the DST offset, but that is not true
anywhere else.

Given my chain of reasoning, the commits following
112c5ba479d52c3c36de5c7aafd14ab6bc075005 to fix "regressions" is
really just converting all of Org mode's timestamps to use the
"timezone adjusted" Unix timestamps introduced by
112c5ba479d52c3c36de5c7aafd14ab6bc075005



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-10-31 Thread Allen Li
On Tue, Oct 31, 2017 at 11:23 AM, Nicolas Goaziou
<m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> Removing the t for zone fixes it
>
> [...]
>
>> I will also note that the FIXME comment in org-parse-time-string
>> suggests that it too is not handling timezones correctly.  In fact,
>> perhaps org-parse-time-string should not take a zone argument, since
>> Org does not support timezones thus the only valid value for zone is
>> nil.  I suspect that org-display-custom-time, another caller that
>> passes t for zone, is also timezone incorrect.
>
> Both changes were introduced to fix some issues with daylight saving
> time, in particular in clock reports. It is not possible to simply
> suggest reverting them without considering the underlying issues.
>
> I agree there are issues to fix. Unfortunately, the solution you suggest
> is not sufficient.

Let me clarify the exact behavior that needs to be fixed.

Assuming today is 2017-10-31, SCHEDULED<"" will match results
that have SCHEDULED=<2017-11-01> depending on your local time zone.

Can you clarify on the issues the UTC timezone fixes?  Because my
understanding at this point is that Org timestamps should be
interpreted as localtime, yet they are being interpreted as UTC time.
I can't see how, e.g.,  if I am in timezone UTC-5, I want all my Org
timestamps <2017-11-01> to be interpreted as <2017-10-31 19:00>.

Assuming that is in fact the behavior we want for some reason, then
, or rather everywhere (float-time) is used in Org mode, should
receive a corresponding time shift.



Re: [O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-10-30 Thread Allen Li
On Mon, Oct 30, 2017 at 5:40 PM, Allen Li <vianchielfa...@gmail.com> wrote:
> (current-time-string (time-to-seconds (org-2ft "<2017-10-31>")))
> "Sun Oct 29 17:00:00 2017"
>
> This seems wrong
>
> In org-2ft
>
> (org-parse-time-string s nil t)
>
> The t means use UTC instead of Emacs local time.
>
> However, Org translates  into (float-time), which is in Emacs localtime.
>
> 1. SCHEDULED>"" compares a UTC time against a local time.
> 2. Either org-2ft should be fixed to be localtime, or  should be
> (float-time) in UTC.
>
> I don't know how Org internals works, but my experience so far has
> been that Emacs and *nix in general is very naive about timezones; a
> naked timestamp is assumed to be localtime if it does not have
> accompanying timezone information.
>
> Thus, it seems to be more correct to change org-2ft to parse times as
> localtime.  However, I don't know if UTC timestamps are assumed by
> other parts of Org internals, in which case fixing  (float-time)
> would be safest.

My initial analysis was wrong because I wasn't thinking clearly.

Just to set a stake in the ground: timestamps are seconds since epoch
and timezone neutral.  Emacs time values are also timezone neutral:
(sec-high sec-low microsec picosec)

(current-time-string (float-time))
"Mon Oct 30 21:21:31 2017" ; right

(current-time-string (org-time-today))
"Mon Oct 30 00:00:00 2017" ; right

(current-time-string (org-2ft "<2017-10-31>"))
"Mon Oct 30 17:00:00 2017" ; wrong

Removing the t for zone fixes it

(defun org-2ft (s)
  "Convert S to a floating point time.
If S is already a number, just return it.  If it is a string, parse
it as a time string and apply `float-time' to it.  If S is nil, just return 0."
  (cond
   ((numberp s) s)
   ((stringp s)
(condition-case nil
(float-time (apply #'encode-time (org-parse-time-string s)))
  (error 0.)))
   (t 0.)))

(current-time-string (org-2ft "<2017-10-31>"))
"Tue Oct 31 00:00:00 2017" ; now right

I will also note that the FIXME comment in org-parse-time-string
suggests that it too is not handling timezones correctly.  In fact,
perhaps org-parse-time-string should not take a zone argument, since
Org does not support timezones thus the only valid value for zone is
nil.  I suspect that org-display-custom-time, another caller that
passes t for zone, is also timezone incorrect.

That is to say, nothing in Org allows passing in a custom timezone,
let alone a UTC timezone; thus, every caller that passes a non-nil
zone to org-parse-time-string is getting an incorrect result.

tl;dr time is hard.



[O] Bug: org-2ft and/or float-time is wrong [9.1.2 (9.1.2-22-ga2a034-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20171023/)]

2017-10-30 Thread Allen Li
(current-time-string (time-to-seconds (org-2ft "<2017-10-31>")))
"Sun Oct 29 17:00:00 2017"

This seems wrong

In org-2ft

(org-parse-time-string s nil t)

The t means use UTC instead of Emacs local time.

However, Org translates  into (float-time), which is in Emacs localtime.

1. SCHEDULED>"" compares a UTC time against a local time.
2. Either org-2ft should be fixed to be localtime, or  should be
(float-time) in UTC.

I don't know how Org internals works, but my experience so far has
been that Emacs and *nix in general is very naive about timezones; a
naked timestamp is assumed to be localtime if it does not have
accompanying timezone information.

Thus, it seems to be more correct to change org-2ft to parse times as
localtime.  However, I don't know if UTC timestamps are assumed by
other parts of Org internals, in which case fixing  (float-time)
would be safest.



Re: [O] Bug: Missing agenda files file causes org to fail [9.1.2 (9.1.2-22-ga2a034-elpaplus)]

2017-10-29 Thread Allen Li
On Sat, Oct 28, 2017 at 1:44 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello,
>
> Allen Li <vianchielfa...@gmail.com> writes:
>
>> If org-agenda-files is set to a file through customize.el and that
>> file is missing, Org will fail to load at all.
>
> I cannot reproduce it. Could you provide the error message and a recipe?

1. emacs -Q
2. Evaluate in *scratch* buffer:

(custom-set-variables
 '(org-agenda-files "~/some-nonexistent-file"))

3. Open up any Org file: C-x f ~/tmp.org

4. Error appears in minibuffer: File mode specification error:
(file-error Opening input file No such file or directory
/home/bob/some-nonexistent-file)

5. Type

* asdf

6. Type M-RET, get error org-heading-components: Wrong type argument:
stringp, nil  This is because org.el was loaded partially (I think).

Other symptoms of partial loading: #+STARTUP does not have a face,
some other commands (but not all) result in errors

>
> Regards,
>
> --
> Nicolas Goaziou



[O] Bug: Missing agenda files file causes org to fail [9.1.2 (9.1.2-22-ga2a034-elpaplus)]

2017-10-27 Thread Allen Li
If org-agenda-files is set to a file through customize.el and that
file is missing, Org will fail to load at all.

Org should not fail to load, either it should create an empty file or
it should print a warning and still load itself.  I think the former
would be easier to implement.



  1   2   >