[O] Bug: org-agenda-columns failing when Diary entries are included [9.0.5 (9.0.5-dist @ /home/ohanluaine/eibhear_org/lisp/org-9/lisp/)]
Hi,
I believe there's a bug in org-mode 9.0 when calling
org-agenda-columns in an agenda view that includes items from the
emacs diary file.
To reproduce
1. Setup:
The following shell commands should build the test case.
# a) Create a location for this test case:
mkdir -vp ~/tmp/columns-bug
# b) Create a simple org-mode file:
cat << EOF > ~/tmp/columns-bug/columns-bug.org
* TODOs
** TODO Eat your chocolate egg
SCHEDULED: <2017-04-16 Sun 11:30>
** TODO Wish Michael a Happy Birthday
SCHEDULED: <2017-03-17 Fri 10:00>
EOF
# c) Create a simple diary file:
cat << EOF > ~/tmp/columns-bug/columns-bug.diary
17 March 2017 12:01 Afternoon is well and truly started
EOF
# d) Create a (not so) simple init file (this assumes that org
#mode 9.0 is somewhere on the load-path):
cat << EOF > ~/tmp/columns-bug/columns-bug.init
(require 'appt)
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(appt-disp-window-function 'appt-disp-window)
'(appt-display-duration 60)
'(appt-display-format (quote window))
'(appt-display-interval 5)
'(appt-message-warning-time 15)
'(calendar-date-style (quote european))
'(calendar-latitude 52.36)
'(calendar-location-name "Dublin, Ireland")
'(calendar-longitude -6.19)
'(calendar-mark-diary-entries-flag t)
'(calendar-time-display-form
(quote (24-hours ":" minutes (if time-zone " (")
time-zone (if time-zone ")")))
)
'(calendar-view-diary-initially-flag t)
'(diary-file "~/tmp/columns-bug/columns-bug.diary")
'(diary-hook (quote (appt-make-list)))
'(diary-list-entries-hook (quote (diary-include-other-diary-files)))
'(diary-list-include-blanks t)
'(diary-number-of-entries 7)
'(display-time-24hr-format t)
'(org-agenda-files (quote ("~/tmp/columns-bug/columns-bug.org")))
'(org-agenda-include-diary t)
'(org-finalize-agenda-hook (quote (org-agenda-to-appt)))
'(org-sort-agenda-notime-is-late nil)
)
(org-agenda-list nil "2017-03-17" 'day)
EOF
# e) Launch emacs:
emacs -Q -l ~/tmp/columns-bug/columns-bug.init
This will start emacs, calling columns-bug.init instead of
.emacs, and will immediately show the org-agenda-list screen for
the 17th March, 2017. There you'll see three entries:
- St. Patrick's Day from "Diary". This is a calculated entry
because diary-show-holidays-flag is t.
- The "Wish Michael a Happy Birthday" TODO from the org-mode file
above.
- The "Afternoon is well and truly started" diary item from the
diary file above.
2. Call org-agenda-columns interactively.
Expected Result
===
The columns overlay for the agenda should be presented.
Actual Result
=
The building of the columns view fails with the following report in
the minibuffer:
Wrong type argument: number-or-marker-p, nil
Alternative scenario
In the same org-agenda-list view, jump to 2017-04-16. This has two
entries, "Easter Sunday" as a calculated diary entry and "Eat your
chocolate egg" from the org-mode file. Calling org-agenda-columns
succeeds.
Discussion
==
The error occurs in org-columns--displayed-value in org-colview.el
because the call to org-current-level for a diary item from the
diary file returns nil.
The automatically-inserted information follows.
Thanks,
Éibhear
Emacs : GNU Emacs 25.2.1 (x86_64-unknown-cygwin)
of 2017-04-21
Package: Org mode version 9.0.5 (9.0.5-dist @
/home/ohanluaine/eibhear_org/lisp/org-9/lisp/)
current state:
==
(setq
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-occur-hook '(org-first-headline-recenter)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-sort-agenda-notime-is-late nil
org-confirm-shell-link-function 'yes-or-no-p
org-finalize-agenda-hook '(org-agenda-to-appt)
org-agenda-include-diary t
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-babel-pre-tangle-hook '(save-buffer)
org-mode-hook '((closure
(org-inlinetask-min-level buffer-face-mode-face org-mode-map
org-tbl-menu org-org-menu org-struct-menu org-entities
org-last-state org-id-track-globally org-clock-start-time
texmathp-why remember-data-file
org-agenda-tags-todo-honor-ignore-options
iswitchb-temp-buflist calc-embedded-open-mode
calc-embedded-open-formula calc-embedded-close-formula
align-mode-rules-list org-emphasis-alist
Re: [O] More clocktable breakage
Achim Gratz writes: > Nicolas Goaziou writes: >> At the moment, I cannot reproduce it. I tried M-up in the following >> document: >> >> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 >> Thu 12:00>" >> #+END: clocktable > > The breakage happens in this clause in org-at-timestamp-p: > >(match > (let ((boundaries (org-in-regexp tsr))) > (save-match-data > (cond ((null boundaries) nil) > ((org-at-planning-p)) > ((org-at-property-p)) > ;; CLOCK lines only contain inactive time-stamps. > ((and inactive-ok (org-at-clock-log-p))) > (t >(eq 'timestamp >(save-excursion > (when (= pos (cdr boundaries)) (forward-char -1)) > (org-element-type (org-element-context)) > > After matching the timestamp in the header argument correctly, the code > falls through to the default cond, where (org-element-type > (org-element-context)) returns 'dynamic-block, which isn't a 'timestamp. > The successful match gets discarded and the timestamp doesn't get > recognized. An empty clause for (org-at-block-p) would fix it, but I'm > not sure that is the right thing to do. I haven't looked at > org-element-context to see whether it might misinterpret something. I did look at org-element-context and the code in org-at-timstamp-p makes even less sense to me now. The only time org-element-context returns 'timestamp is when it is on a planning line, but org-at-timstamp-p has already left the cond in that case in the second clause. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] hyperlink type for Claws-mail
Saša Janiška writes: > Hello, > > I do wonder if there is some way to add hyperlink type for Claws-mail? > org-link-set-parameters. There are examples of its use for gnus, rmail, mhe, eww, w3m, irc and a few others in the source. AFAICT, almost all of them define two functions, one to follow the link and the other to store the link. E.g. org-gnus does this: (org-link-set-parameters "gnus" :follow #'org-gnus-open :store #'org-gnus-store-link) > Today, asked the same question in #claws and I was told that something > like this could work: > > claws-mail --select [#mh/mailbox/]folder[/msg|/msgid]` > > and tried with the following: > > claws-mail --select '#imap/gour/INBOX/10254' > > and I can confirm that it works. > > The 'msgid' from above is visible within Claws when one enables 'Number' > column in Summary view… > > Now I wonder what would be correct way to create such link(s) within > org-mode by invoking some function by feeding it the ’msgid’ or possibly > some more data ( mailbox, folder etc.) so that when I later click on > such created hyperlink the following: > > claws-mail --select ... > > is going to be invoked? > > Any hint? > > > Sincerely, > Gour -- Nick
Re: [O] More clocktable breakage
Achim Gratz writes: > Achim Gratz writes: >> Nicolas Goaziou writes: >>> At the moment, I cannot reproduce it. I tried M-up in the following >>> document: >>> >>> #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend >>> "<2006-08-10 Thu 12:00>" >>> #+END: clocktable These are not timestamps. Even though they look like timestamps, you wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is correct, IMO. Moreover, its docstring says This function checks context and only return non-nil for valid time stamps. If you need to match anything looking like a time stamp, or if you are sure about the context, consider using ‘org-in-regexp’, e.g., (org-in-regexp org-ts-regexp) so ISTM a correct fix would be to have the function you're calling (I don't remember it) use this instead of `org-at-timestamp-p'. WDYT? -- Nicolas Goaziou
Re: [O] More clocktable breakage
Nicolas Goaziou writes: #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 Thu 12:00>" #+END: clocktable > > These are not timestamps. Even though they look like timestamps, you > wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is > correct, IMO. Moreover, its docstring says […] Well, that's the change you made that I pointed at earlier. The functionality of org-shift* has unfortunately regressed due to that change you introduced by "hardening" the recognition of timestamps. And no, to the user they really are timestamps in the arguments of a dynamic block, splitting syntactical hairs aside. > so ISTM a correct fix would be to have the function you're calling (I > don't remember it) use this instead of `org-at-timestamp-p'. I already said that the fix might not be the right one, although it would be in the same spirit as the exceptions already present for properties drawers, planning lines and clocks and org-at-block-p only matches in the first line of a dynamic block, so I'd say it's still sufficiently constrained. N.B.: The regex used in org-at-block-p is overbroad since it matches the whole block, I think it should use org-at-dblock-start-re instead. Anyway, when you changed the scope of that function you'd need to check all users of the API and fix them where necessary. The main users of that predicate were and still are the org-shift* family of commands and they do expect a looser recognition than what you implemented based on the docstring. Maybe that's true in other places also, I haven't checked. It's also obvious that the test coverage of this is bad. So that looser recognition would need to be factored out again or you revert this predicate and apply the stricter check where it matters (the agenda functions, most likely). Also, again, I think that function is buggy even without these issues as the only code I can find in org-element-context that deals with timestamps is conditional on being on a planning line and if that's true we should never get there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Bug: org-agenda-columns failing when Diary entries are included [9.0.5 (9.0.5-dist @ /home/ohanluaine/eibhear_org/lisp/org-9/lisp/)]
Hello,
"Éibhear" writes:
> I believe there's a bug in org-mode 9.0 when calling
> org-agenda-columns in an agenda view that includes items from the
> emacs diary file.
>
> To reproduce
>
> 1. Setup:
>The following shell commands should build the test case.
>
> # a) Create a location for this test case:
> mkdir -vp ~/tmp/columns-bug
>
> # b) Create a simple org-mode file:
> cat << EOF > ~/tmp/columns-bug/columns-bug.org
> * TODOs
> ** TODO Eat your chocolate egg
>SCHEDULED: <2017-04-16 Sun 11:30>
> ** TODO Wish Michael a Happy Birthday
>SCHEDULED: <2017-03-17 Fri 10:00>
> EOF
>
> # c) Create a simple diary file:
> cat << EOF > ~/tmp/columns-bug/columns-bug.diary
> 17 March 2017 12:01 Afternoon is well and truly started
> EOF
>
> # d) Create a (not so) simple init file (this assumes that org
> #mode 9.0 is somewhere on the load-path):
> cat << EOF > ~/tmp/columns-bug/columns-bug.init
>
> (require 'appt)
>
> (custom-set-variables
> ;; custom-set-variables was added by Custom.
> ;; If you edit it by hand, you could mess it up, so be careful.
> ;; Your init file should contain only one such instance.
> ;; If there is more than one, they won't work right.
> '(appt-disp-window-function 'appt-disp-window)
> '(appt-display-duration 60)
> '(appt-display-format (quote window))
> '(appt-display-interval 5)
> '(appt-message-warning-time 15)
> '(calendar-date-style (quote european))
> '(calendar-latitude 52.36)
> '(calendar-location-name "Dublin, Ireland")
> '(calendar-longitude -6.19)
> '(calendar-mark-diary-entries-flag t)
> '(calendar-time-display-form
>(quote (24-hours ":" minutes (if time-zone " (")
> time-zone (if time-zone ")")))
>)
> '(calendar-view-diary-initially-flag t)
> '(diary-file "~/tmp/columns-bug/columns-bug.diary")
> '(diary-hook (quote (appt-make-list)))
> '(diary-list-entries-hook (quote (diary-include-other-diary-files)))
> '(diary-list-include-blanks t)
> '(diary-number-of-entries 7)
> '(display-time-24hr-format t)
> '(org-agenda-files (quote ("~/tmp/columns-bug/columns-bug.org")))
> '(org-agenda-include-diary t)
> '(org-finalize-agenda-hook (quote (org-agenda-to-appt)))
> '(org-sort-agenda-notime-is-late nil)
> )
>
> (org-agenda-list nil "2017-03-17" 'day)
> EOF
>
> # e) Launch emacs:
> emacs -Q -l ~/tmp/columns-bug/columns-bug.init
>
>This will start emacs, calling columns-bug.init instead of
>.emacs, and will immediately show the org-agenda-list screen for
>the 17th March, 2017. There you'll see three entries:
>- St. Patrick's Day from "Diary". This is a calculated entry
> because diary-show-holidays-flag is t.
>- The "Wish Michael a Happy Birthday" TODO from the org-mode file
> above.
>- The "Afternoon is well and truly started" diary item from the
> diary file above.
>
> 2. Call org-agenda-columns interactively.
>
>
> Expected Result
> ===
> The columns overlay for the agenda should be presented.
>
>
> Actual Result
> =
> The building of the columns view fails with the following report in
> the minibuffer:
>
> Wrong type argument: number-or-marker-p, nil
Fixed. Thank you.
Regards,
--
Nicolas Goaziou
[O] sort habits by priority
I want to sort habits by priority, such that priority overrides all other criteria (schedule, deadline, consistency, etc.). In attempting to implement this I discovered that org-habit-get-priority is an inline function and thus cannot be overridden by the user. There seems to be no straightforward way to accomplish my goal without editing the org source code directly. I am not the only one to run into this problem: http://stackoverflow.com/questions/37200762/sort-todays-habits-by-priority-in-main-agenda-view I think the best solution is either to make org-habit-get-priority a regular function (assuming this doesn't cause a serious performance degradation) or to add user-customizable variable(s) which can configure how habits are prioritized. Thoughts? Jesse
Re: [O] More clocktable breakage
Achim Gratz writes: > and org-at-block-p only matches in the first line of a dynamic block, [...] > N.B.: The regex used in org-at-block-p is overbroad since it matches the > whole block, I think it should use org-at-dblock-start-re instead. This old and buggy function has nothing to do with the problem at hand. Also, even if it used org-at-dblock-start-re, it would still be buggy (is it closed? is it in an example block?). > Anyway, when you changed the scope of that function you'd need to check > all users of the API and fix them where necessary. Really? I thought it would magically happen... somehow. Silly me. > The main users of that predicate were and still are the org-shift* > family of commands and they do expect a looser recognition than what > you implemented based on the docstring. Maybe that's true in other > places also, I haven't checked. The main user of that predicate is the agenda, now. > It's also obvious that the test coverage of this is bad. Patch welcome. > So that looser recognition would need to be factored out again or you > revert this predicate and apply the stricter check where it matters > (the agenda functions, most likely). Another idea is to add an optional argument to `org-at-timestamp-p' to allow "sloppy" matching (or strict matching, it doesn't really matter) and skip checks when it is required. So all functions requiring this predicate can make use of it, as long as they call it properly. WDYT? > Also, again, I think that function is buggy even without these issues as > the only code I can find in org-element-context that deals with > timestamps is conditional on being on a planning line and if that's true > we should never get there. I don't think there is a bug there. Do you have an ECM? Regards,
Re: [O] sort habits by priority
Hello, Jesse Johnson writes: > I want to sort habits by priority, such that priority overrides all > other criteria (schedule, deadline, consistency, etc.). > > In attempting to implement this I discovered that > org-habit-get-priority is an inline function and thus cannot be > overridden by the user. There seems to be no straightforward way to > accomplish my goal without editing the org source code directly. > > I am not the only one to run into this problem: > http://stackoverflow.com/questions/37200762/sort-todays-habits-by-priority-in-main-agenda-view > > I think the best solution is either to make org-habit-get-priority > a regular function (assuming this doesn't cause a serious performance > degradation) or to add user-customizable variable(s) which can > configure how habits are prioritized. > > Thoughts? You can implement your own sorting strategy. See `org-agenda-cmp-user-defined'. So you don't need to change or override this function. Regards, -- Nicolas Goaziou
Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers
Hello, Brent Goodrick writes: > In the current implementation of org-src--contents-for-write-back, the > `with-temp-buffer` uses fundamental-mode. Correct. > Later, while inside that temp buffer, spaces are inserted in to indent > the entire source block over to where it needs to be (in my original > post, notice that I have the source block within a list item so the > source block needs to be aligned properly under that list item, no > matter to what depth that list item is). Correct. > It is in mode hook functions that certain changes to indentation can > occur, so that is why I'm switching into that mode. This is where I don't follow you. At this point, indentation changes are tailored for the source, i.e., Org, buffer. Special indentation rules from the source block mode do not apply here. > But that is not enough: In order for the text to be aligned properly > inside the org mode buffer after indentation, there cannot be a mix of > tabs and spaces, as shown in my original post. IIRC, `indent-to' is > called within the `write-back' function, and `indent-to' is affected > by the `indent-tabs-mode' value, which by default in emacs lisp mode > buffers, is t. You cannot set `indent-tabs-mode' to nil and discard user's configuration. What if I want it to be non-nil in Org buffers? Another option is to delete any leading indentation and indent it again according to `indent-tabs-mode' value in source buffer. WDYT? Regards, -- Nicolas Goaziou
[O] [PATCH] Honor the :python header argument in python src-blocks
Hello, This is my first post to the mailing list and I just wanted to say thank all of you for making such a great piece of code! Below is a patch that should fix the problem where a python session was being initiated without first checking the :python header argument. --- PATCH --- From a721c97924b5b965179a2dd90e54d63c7de00317 Mon Sep 17 00:00:00 2001 From: Nathaniel Nicandro Date: Thu, 27 Apr 2017 18:16:41 -0500 Subject: [PATCH] Honor the :python header argument in python src-blocks * lisp/ob-python.el (org-babel-execute:python): `org-babel-python-command` should be set before calling `org-babel-python-initiate-session`. TINYCHANGE --- lisp/ob-python.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/ob-python.el b/lisp/ob-python.el index b838a48..f533658 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -73,15 +73,15 @@ This will typically be either `python' or `python-mode'." (defun org-babel-execute:python (body params) "Execute a block of Python code with Babel. This function is called by `org-babel-execute-src-block'." - (let* ((session (org-babel-python-initiate-session + (let* ((org-babel-python-command + (or (cdr (assq :python params)) org-babel-python-command)) + (session (org-babel-python-initiate-session (cdr (assq :session params (result-params (cdr (assq :result-params params))) (result-type (cdr (assq :result-type params))) (return-val (when (and (eq result-type 'value) (not session)) (cdr (assq :return params (preamble (cdr (assq :preamble params))) - (org-babel-python-command - (or (cdr (assq :python params)) org-babel-python-command)) (full-body (org-babel-expand-body:generic (concat body (if return-val (format "\nreturn %s" return-val) "")) -- 2.3.8
