Re: tags-todo agenda shoud not ignore DONE items

[Kyle Meyer]

[ Sorry for the slow reply here, and thank you for looking into this. ]

James N V Cash writes:

> Bastien  writes:
>
>> Confirming this as an issue, if someone wants to fix it.
>
> I've tried taking a shot at addressing this issue via the patch attached.
>
> As mentioned in the thread, might potentially cause issues by changing
> how it matches -- should there be an option? Or is the idea just that
> if you really do want to exclude done tags, you'd query like "/!DONE"?

Yep, that's the idea, I think.  It's mentioned in both 942b6267a
(org-agenda: `tags-todo' command type includes DONE keywords,
2017-04-18) and 2fb129b5c (`org-scan-tags' retrieve all TODO keywords,
not only not-done ones, 2017-08-17).

>
> diff --git a/lisp/org.el b/lisp/org.el
> index 020cfc873..3db1add8b 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -11691,7 +11691,7 @@ See also `org-scan-tags'."
>  `(and ,tagsmatcher ,todomatcher)
>(or tagsmatcher todomatcher t
>(when org--matcher-tags-todo-only
> - (setq matcher `(and (member todo org-not-done-keywords) ,matcher)))
> + (setq matcher `(and (member todo org-todo-keywords-1) ,matcher)))
>(cons match0 `(lambda (todo tags-list level) ,matcher)
>  
>  (defun org--tags-expand-group (group tag-groups expanded)

This does resolve the reported issue with the b tags-todo set reported
in .  However, it
breaks the org-tags-view todo-only operation (agenda's M): it no longer
filters out todos in a DONE state.  This behavior is explicitly
specified in the manual:

  Using ‘M-x org-agenda M’ or ‘/!’ does not match TODO keywords in a
  DONE state.

In , I asked,
"shouldn't tags-todo consider only none-DONE todo items, in the same
spirit as m versus M?"  And, looking at this again, it's not only in
spirit; the tags-todo agenda view and org-tags-view's todo-only are
really directly linked:

   ((eq type 'tags-todo)
(org-let lprops '(org-tags-view '(4) org-match)))

After rereading the thread at m2ftazm3l1@brautaset.org, I'm still
not convinced we should break that link.

Re: [PATCH] ol-wl: add maildir and rss to folder types

[Kyle Meyer]

Chen Li writes:

> with this commit, org-link can open maildir and rss folder.
>
> more to read: http://wanderlust.github.io/wl-docs/wl.html#Folders~

Thanks.

I don't use wanderlust and haven't tested it out, but that looks
straightforward enough.  Applied (1cc04), tacking on a change log to
the message.

Note that contrib/ is being moved to a separate repo [1], with the
eventual goal of each file being maintained elsewhere, in case you or
someone you know is interested :)

  [1] https://orgmode.org/list/87wnzfy60h@bzg.fr

Re: org-agenda-get-timestamps and properties

[Kyle Meyer]

Michael Heerdegen writes:

> When debugging, I found that `org-agenda-get-timestamps' does, depending
> on the position of the SCHEDULED spec, do return a timestamp when an
> entry is formatted like this:
>
> ** APPT 10:40 Xyz
> :PROPERTIES:
> :ID:   1d313f9a-3044-4c23-9278-422646ec9063
> :END:
> SCHEDULED: <2020-11-08 So +1d>

To be valid, the SCHEDULED spec should be immediately following the
headline.  So this is just a timestamp...

> but not when formatted like this:
>
> ** APPT 10:40 Xyz
> SCHEDULED: <2020-11-08 So +1d>
> :PROPERTIES:
> :ID:   1d313f9a-3044-4c23-9278-422646ec9063
> :END:
>
> although the latter form is, AFAICT, recommended, and at least it's what
> I get when creating ids automatically with (org-id-get-create).

...while this is a valid scheduled heading.

> No timestamp, and my appointments don't work (bad).
>
> Has anybody any insight into this matter?

I haven't looked too closely, but at first glance
org-agenda-get-timestamps not detecting the second entry seems expected.
org-agenda-get-timestamps has a comment that says "[s]kip date ranges,
scheduled and deadlines, which are handled specially".  Still without
looking closely, I'd guess that the "handled specially" is referring to
org-agenda-get-scheduled and org-agenda-get-deadlines.

Re: [PATCH] ob-java.el: Allow for more whitespace

[Kyle Meyer]

ian martins writes:

> Subject: [PATCH 1/2] ob-java.el: Do not wrap a main method in a main method
>
> * lisp/ob-java.el (org-babel-expand-body:java): The code was checking
> for existence of a class declaration before wrapping the content of
> the code block in a main method, but it should be checking for
> existence of a main method.

Sounds good.

> Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code
>
> * lisp/ob-java.el (defconst *-re): Updated regexps to allow for more
> whitespace in the content of java code blocks, and removed some
> redundancies.

Sorry, more change log nitpicking from me (which is even less fun to do
than other nitpicking because I dislike the practice of including change
logs in commit messages).

Please name each variable in full.  Here's the relevant bit from the
guidelines that Emacs's CONTRIBUTE points to:

If you mention the names of the modified functions or variables,
it’s important to name them in full.  Don’t abbreviate function or
variable names, and don’t combine them.  Subsequent maintainers will
often search for a function name to find all the change log entries
that pertain to it; if you abbreviate the name, they won’t find it
when they search.

https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs

We should probably link to that in worg's org-contribute.org.

> * testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
> Added test case with lots of whitespace.

Is this related to Jarmo's report at
?  If so, it'd be good
to include a Reported-by trailer as well as a link.

> -(defconst org-babel-java--package-re 
> "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> +(defconst org-babel-java--package-re 
> "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
>"Regexp for the package statement.")
> -(defconst org-babel-java--imports-re 
> "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> +(defconst org-babel-java--imports-re 
> "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
>"Regexp for import statements.")
> -(defconst org-babel-java--class-re 
> "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*\n?[[:space:]]*{"
> +(defconst org-babel-java--class-re 
> "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*{"
>"Regexp for the class declaration.")
> -(defconst org-babel-java--main-re "public static void 
> main(String\\\(?:\\[]\\\)?[[:space:]]+[^ ]+\\\(?:\\[]\\\)?).*\n?[[:space:]]*{"
> +(defconst org-babel-java--main-re 
> "public[[:space:]]+static[[:space:]]+void[[:space:]]+main[[:space:]]*([[:space:]]*String[[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
>"Regexp for the main method declaration.")
> -(defconst org-babel-java--any-method-re "public .*(.*).*\n?[[:space:]]*{"
> +(defconst org-babel-java--any-method-re 
> "public[[:space:]]+.*[[:space:]]*([[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
>"Regexp for any method.")

Not speaking Java, I don't have anything actually valuable to say about
this change, but I wouldn't complain if these regular expressions were
switched over to rx (or at least tamed a bit in terms of line length).

Thanks for the fixes.

[Meta] Mailing list helper functions

[Ihor Radchenko]

Recent changes in https://orgmode.org/worg/org-mailing-list.html
encouraged several unusual practices when posting to org-mode mailing
list:
1. Using Woof headers to label Bugs/Help requests/Patches [1]
2. Avoiding full quoting of earlier thread when it gets too long (which
is default in Emacs and many other mail clients) [2]

I wrote two small helpers for message-send-hook reminding to follow the
suggestions. Hope they can be useful for other users following the
maillist from inside Emacs.

(defun yant/notmuch-mua-woof-check-maybe ()
"Remind to use Woof headers when sending email to org-mode maillist."
(let ((case-fold-search t))
  (save-excursion
(goto-char (point-min))
(when (re-search-forward "^\\(To:\\|CC:\\).+emacs-orgmode@gnu\\.org" 
nil t)
  (goto-char (point-min))
  (unless (re-search-forward 
"^X-Woof-\\(Bug\\|Help\\|Change\\|Release\\|Patch\\):" nil t)
(unless (yes-or-no-p "No Woof-(Bug|Help|Patch): t/nil headers found 
in message being sent to emacs-orgmode@gnu.org. Send anyway? ")
  (error "Forgot Woof headers")))
  (add-hook 'message-send-hook #'yant/notmuch-mua-woof-check-maybe)

(defun yant/notmuch-mua-too-long-cite-reminder ()
"Remind to cut unnecessary thread citation when replying to orgmode."
(let ((case-fold-search t))
  (save-excursion
(goto-char (point-min))
(when (re-search-forward "^\\(To:\\|CC:\\).+emacs-orgmode@gnu\\.org" 
nil t)
  (message-goto-body)
  (when (> (- (point-max) (point)) 5000) ; Message too long.
(unless (yes-or-no-p "Message is too long. May need to cutoff 
excess citation lines. Send anyway? ")
  (error "Forgot to cutoff excess citation")))
  (add-hook 'message-send-hook #'yant/notmuch-mua-too-long-cite-reminder)

[1] https://orgmode.org/worg/org-mailing-list.html#orga4190ea
[2] https://orgmode.org/worg/org-mailing-list.html#orgf343a0f

Best,
Ihor
 

Re: [FR] Don't hardcode checker functions prefix in org-lint

[Gustavo Barros]

Hi All,

On Tue, 10 Nov 2020 at 17:22, Gustavo Barros  
wrote:


This is a small feature request for `org-lint' not to hardcode the 
checker

functions' prefix, as it currently does.


I've been playing with and testing this further, and I found an 
uncovered corner in my initial suggestion: the revert-buffer behavior in 
the report buffer.  It is still simple to handle it, but requires a 
couple of extra steps: set the prefix variable as a buffer local 
variable in the report buffer in `org-lint--display-reports' and 
let-bind this value before moving to the linted buffer in 
`org-lint--generate-reports'.


As an extra sugar, but non essential, it would also be nice to be able 
to set the report buffer's name.


In sum, the suggestion/request then entails:

#+begin_src emacs-lisp
(defvar-local org-lint--checkers-prefix nil)
(defvar-local org-lint--report-buffer-name nil)

(defun org-lint--generate-reports (buffer checkers)
 (let ((checkers-prefix (or org-lint--checkers-prefix "org-lint")))
   (with-current-buffer buffer
 ;; [...]
 (funcall
  (intern (format "%s-%s"
  checkers-prefix
   (org-lint-checker-name c)))
  ast)
 ;; [...]
 )))

(defun org-lint--display-reports (source checkers)
 ;; changed let-binding <--
 (let ((buffer (get-buffer-create (or org-lint--report-buffer-name
  "*Org Lint*"
   (with-current-buffer buffer
 (org-lint--report-mode)
 (setf org-lint--source-buffer source)
 (setf org-lint--local-checkers checkers)
 ;; added variable setting <--
 (setf org-lint--checkers-prefix org-lint--checkers-prefix)
 (org-lint--refresh-reports)
 (tabulated-list-print)
 (add-hook 'tabulated-list-revert-hook #'org-lint--refresh-reports 
 nil t))

   (pop-to-buffer buffer)))
#+end_src

That's about it.  With it, I get a fully functional Lint report for 
personal lints with something like:


#+begin_src emacs-lisp
(defun my/org-lint (&optional arg)
 (interactive "P")
 (let ((org-lint--checkers my/org-lint-checkers)
   (org-lint--checkers-prefix "my/org-lint")
   (org-lint--report-buffer-name "*My Org Lint*"))
   (funcall-interactively 'org-lint arg)))
#+end_src

Best regards,
Gustavo.

Re: Missing argument in org-reset-checkbox-state-subtree?

[Bob Wilson]

Thanks again Kyle,
   Per your suggestion I have reverted my change to 
org-reset-checkbox-state-subtree, and instead updated 
org-reset-checkbox-state-maybe in org-checklist.el (I’m much happier editing 
org add-ons than editing org!).

Specifically, I follow up org-reset-checkbox-state-subtree with a call to:
(org-map-entries ‘org-update-parent-todo-statistics)

and this seems to address my problem as well, but definitely more elegantly!

Kind regards,
Bob

> On Nov 11, 2020, at 7:22 PM, Kyle Meyer  wrote:
> 
> Bob Wilson writes:
> 
>> I’m writing about a possible bug in
>> org-reset-checkbox-state-subtree. This function calls
>> org-update-checkbox-count-maybe with argument 'all, but this value is
>> not defined in the function (or anywhere else that I can see).
> 
> [ I'm looking at the copy on master (e9c3993ee), though org-list.el
>  hasn't changed since that last release. ]
> 
> org-reset-checkbox-state-subtree calls
> 
>(org-update-checkbox-count-maybe 'all)
> 
> and org-update-checkbox-count-maybe calls
> 
>(org-update-checkbox-count all)
> 
> And org-update-checkbox-count considers ALL, so I'm not spotting
> anything that's undefined.
> 
>> I’d like this value to be nil because I don’t want to update the
>> statistics cookies in the entire buffer, but I don’t see a way to do
>> this (pardon my limited elisp). My workaround is to add an optional
>> all argument to org-reset-checkbox-state-subtree and pass it to
>> org-update-checkbox-count-maybe.
> 
> Why does refreshing the stats for the entire buffer cause a problem for
> you?
> 
>> This seems like the desired functionality unless I’m missing
>> something. Is the current implementation intentional?
> 
> Yes, the change was made with a0bc3bdeb (org-list: fix update of
> check-boxes cookies in whole trees, 2011-06-20).  The example that
> prompted that change was reported at
> .
> 
> Here's a reduced example:
> 
>  * a
>  ** aa [1/1]
>  - [X] l
>  ** ab [1/1]
>  - [X] m
> 
> Calling org-reset-checkbox-state-subtree with point at the top-level "a"
> should uncheck l and m and the stats of both subheadings should go to
> [0/1]:
> 
>  * a
>  ** aa [0/1]
>  - [ ] l
>  ** ab [0/1]
>  - [ ] m
> 
> If you were to drop `all' from -reset-checkbox-state-subtree's the call
> to -update-checkbox-count-maybe, the result would instead be
> 
>  * a
>  ** aa [1/1]
>  - [ ] l
>  ** ab [0/1]
>  - [ ] m

Re: Missing argument in org-reset-checkbox-state-subtree?

[Kyle Meyer]

Bob Wilson writes:

> I use the org-checklist add-on so that marking the task as complete
> resets the checkboxes to empty. But I noticed that every time I do so,
> it resets the statistics cookies everywhere else in the org file! And
> by reset, I mean it replaces things like [5/7] with [0/0]. I have to
> do C-u C-c # (org-update-statistics-cookies ALL) to fix it.

[ Rearranging things to lead with your complete example first... ]

> * Task A [1/2]
> ** DONE Subtask A.1
>CLOSED: [2020-11-12 Thu 08:47]
> ** TODO Subtask A.2
> * TODO Daily Wind-Down
>   SCHEDULED: <2020-11-12 Thu 17:00 +1d>
>   :PROPERTIES:
>   :RESET_CHECK_BOXES: t
>   :END:
> - [ ] Respond to emails
> - [ ] Pat myself on the back
>
> Marking the Daily Wind-Down as complete resets the buffer so it looks like:
> * Task A [0/0]
> ** DONE Subtask A.1
>CLOSED: [2020-11-12 Thu 08:47]
> ** TODO Subtask A.2
> * TODO Daily Wind-Down
>   SCHEDULED: <2020-11-13 Fri 17:00 +1d>
>   :PROPERTIES:
>   :RESET_CHECK_BOXES: t
>   :LAST_REPEAT: [2020-11-12 Thu 08:47]  
>   :END:
> - [ ] Respond to emails
> - [ ] Pat myself on the back
>
> The first line shows the problem: the statistics cookies have updated
> to [0/0].

Thanks.  I can trigger that as well.  So, with the example from
, the issue is that,
without specifying `all', the _checkbox_ statistics for sibling
subheadings do not get updated, just the last one.

In contrast, the problem here looks to be that org-update-checkbox-count
will result in _todo_ statistics being set to zero, and it doesn't take
care of refreshing them.

This problem goes away with the higher-level
org-update-statistics-cookies because it calls
(org-update-checkbox-count 'all) but _then_ follows up with a call to
(org-map-entries 'org-update-parent-todo-statistics).

> Just for completeness, I will write out my thoughts (and you’ll soon
> see just how little I know of elisp — I apologize!). Here is the
> org-reset-checkbox-state-subtree as of 9.4:
>
> (defun org-reset-checkbox-state-subtree ()
[...]
>   (org-update-checkbox-count-maybe 'all)
>
> In the last line, it calls org-update-checkbox-count-maybe with ‘all
> argument. I don’t full understand the single quote part. My
> understanding is that it tells lisp not to evaluate the value (which
> is good, because there is no all variable defined at this scope).

Yes, that's right.  (info "(elisp)Quoting") has more details.

> My only idea here is that it’s a way of saying, “by the time you
> actually need this value, I’ll have told you what it is”. But what is
> relevant is that I don’t think ‘all is nil; it’s some kind of
> placeholder, so it effectively gets evaluated as true. Or so it seems
> to me.
>
> org-update-checkbox-count-maybe passes this placeholder unmodified to
> org-update-checkbox-count which does all the heavy lifting. But
> nowhere is the all argument ever modified, it continues to be that
> non-nil placeholder, which seems to get evaluated as true. It’s not
> clear to me why this placeholder would get passed to the function if
> it is never set to anything else. But again, I don’t fully understand
> the single quote syntax.

In this particular case, org-update-checkbox-count doesn't check for a
_specific_ non-nil value, so indeed the only thing that is important is
that the value of org-update-checkbox-count's ALL ends up non-nil.  t
(no need to quote), or any number of things aside from nil, could be
passed instead.

Using "'all" rather than "t" here is just making things a bit more
readable by hinting what the parameter/effect is.

> The org-update-checkbox-count is quite complicated (from my
> elisp-neophyte perspective), so it is not clear to me why it resets
> the statistics cookies to [0/0], but whatever it does, it does it in
> the entire file.
>
> The “fix” that I made was on the first and last lines of the function:
>
> (defun org-reset-checkbox-state-subtree (&optional all)
> ...
>   (org-update-checkbox-count-maybe all)
>
> where you can see all I did was remove the single quote from all, and
> added all as an optional parameter. Now I feel like this was the wrong
> fix, but it does solve my problem!

Right, it's problematic because it'd bring back the previous issue with
sibling checkbox statistics not being updated.

> Maybe the real problem had nothing to do with the entire buffer part,
> and was more about why the statistics cookies get updated to [0/0].

That's my current thinking, but I haven't taken a closer look at
org-update-checkbox-count yet.

Re: Bug: Exporting "as PDF file and open" causes unnecessary revert prompt if PDF was already open [9.4 (release_9.4-103-gf0b8de @ /home/erik/.emacs.d/straight/build/org/)]

[Tim Cross]

Erik Hahn  writes:

> In a graphical emacs -Q instance, open any Org file. Export it as PDF and open
> (C-e l o). Then do the same again. Emacs prompts "File foo.pdf changed
> on disk. Reread from disk (yes or no)" although no external program (not
> counting latex as external here as it was started by Emacs) actually
> changed the file.
>
> Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
>  of 2020-03-26, modified by Debian
> Package: Org mode version 9.4 (release_9.4-103-gf0b8de @ 
> /home/erik/.emacs.d/straight/build/org/)

Hmm. Not sure if this is strictly speaking a bug. Latex is an external
program and the process does replace the file on disk, so it has changed
compared to the buffer. So at that level, the revert seems normal.

However, Emacs knows this process has occurred and knows it should
re-read from disk as a new PDF has just been created, so perhaps it
should just do the revert without asking? This may have consequences for
users who are working with large PDF documents and high DPI settings who
may not want to re-generate the PDF every time, so it may be necessary
to make the auto reloading an option?

--
Tim Cross

Re: official orgmode parser

[Tom Gillespie]

Hi Bastien,
 I agree it would be great to ask them to contribute to whichever
ruby library they are using. I will see if I can get in touch, but I
have no idea of where to start if we really want to get to the folks
who could make a decision. It looks like gitlab uses the same org-ruby
library as well
https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/Gemfile#L156.
They may be easier to reach out to. I have also cced Wally to see if
he has any insights here. Best!
Tom

Re: [PATCH] lisp/org.el: Use `org-document-info' face for subtitles

[Titus von der Malsburg]

On 2020-11-07 Sa 23:04, Kyle Meyer wrote:
> Titus von der Malsburg writes:
>
>> On 2020-11-06 Fr 07:18, Kyle Meyer wrote:
>>> Titus von der Malsburg writes:
>>>
 Subject: [PATCH] lisp/org.el: Use face org-document-info for subtitle

 * lisp/org.el: The value for the #+subtitle: property is now displayed
 with face `org-document-info' instead of `org-meta-line'.

 Like the title, author, e-mail, date, the subtitle is information
 that is displayed in the exported document.
>>>
>>> Makes sense to me, and I guess it was left out just because #+subtitle
>>> wasn't around until v8.3.
>>>
 ---
  lisp/org.el | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/lisp/org.el b/lisp/org.el
 index 03df139fb..27f09645b 100644
 --- a/lisp/org.el
 +++ b/lisp/org.el
 @@ -5307,7 +5307,7 @@ by a #."
 (min (point-max) end-of-endline))
   '(face org-block-end-line)))
t))
 -   ((member dc1 '("+title:" "+author:" "+email:" "+date:"))
 +   ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
  (org-remove-flyspell-overlays-in
   (match-beginning 0)
   (if (equal "+title:" dc1) (match-end 2) (match-end 0)))
>>>
>>> Please also update org-document-info-keyword's docstring.
>>
>> Done.  I also updated the docstring for `org-document-info'.  See attached 
>> patch.
>
> Thanks.  Applied (e2fe59683), add entries to the changelog for the
> faces.

Attached is a follow-up patch that allows users to hide the #+SUBTITLE: keyword 
via `org-hidden-keywords' just like #+TITLE, #+AUTHOR:, and similar.

  Titus

>From 794e126fa1ab3cebc8de3bf35324e8353bc8a427 Mon Sep 17 00:00:00 2001
From: Titus von der Malsburg 
Date: Thu, 12 Nov 2020 18:03:33 +0100
Subject: [PATCH] lisp/org.el: Allow hiding #+SUBTITLE: keyword via
 `org-hidden-keywords'

* lisp/org.el: Allow users to include 'subtitle in
`org-hidden-keywords' to hide #+SUBTITLE: keyword.

This way #+SUBTITLE is treated like similar keywords for title, date,
e-mail, and author.
---
 lisp/org.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/org.el b/lisp/org.el
index 73b270712..0d2fbddda 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3573,6 +3573,7 @@ appear in the buffer without the initial \"#+TITLE:\" part."
   :type '(set (const :tag "#+AUTHOR" author)
 	  (const :tag "#+DATE" date)
 	  (const :tag "#+EMAIL" email)
+	  (const :tag "#+SUBTITLE" subtitle)
 	  (const :tag "#+TITLE" title)))
 
 (defcustom org-custom-properties nil
-- 
2.25.1

Re: Missing argument in org-reset-checkbox-state-subtree?

[Bob Wilson]

Hi Kyle,
   Thanks so much for your thoughtful response. It would probably be helpful if 
I gave more context on the problem I was having!

I have a daily wind-down routine where I respond to any lingering emails, etc. 
So I have an item like:

* TODO Daily Wind-Down
SCHEDULED: <2020-11-12 Thu 17:00 +1d>
- [ ] Respond to emails
- [ ] Pat myself on the back

I use the org-checklist add-on so that marking the task as complete resets the 
checkboxes to empty. But I noticed that every time I do so, it resets the 
statistics cookies everywhere else in the org file! And by reset, I mean it 
replaces things like [5/7] with [0/0]. I have to do C-u C-c # 
(org-update-statistics-cookies ALL) to fix it.

I’m new to elisp, but I tried my best to debug what was going on. I could be 
completely wrong about the underlying cause, but I was able to make a change 
that prevented this phenomenon from occurring. I thought other people might be 
having the same problem, but it sounds like maybe not!

Just for completeness, I will write out my thoughts (and you’ll soon see just 
how little I know of elisp — I apologize!). Here is the 
org-reset-checkbox-state-subtree as of 9.4:

(defun org-reset-checkbox-state-subtree ()
  "Reset all checkboxes in an entry subtree."
  (interactive "*")
  (if (org-before-first-heading-p)
  (error "Not inside a tree")
(save-restriction
  (save-excursion
(org-narrow-to-subtree)
(org-show-subtree)
(goto-char (point-min))
(let ((end (point-max)))
  (while (< (point) end)
(when (org-at-item-checkbox-p)
  (replace-match "[ ]" t t nil 1))
(beginning-of-line 2)))
(org-update-checkbox-count-maybe 'all)

In the last line, it calls org-update-checkbox-count-maybe with ‘all argument. 
I don’t full understand the single quote part. My understanding is that it 
tells lisp not to evaluate the value (which is good, because there is no all 
variable defined at this scope). My only idea here is that it’s a way of 
saying, “by the time you actually need this value, I’ll have told you what it 
is”. But what is relevant is that I don’t think ‘all is nil; it’s some kind of 
placeholder, so it effectively gets evaluated as true. Or so it seems to me.

org-update-checkbox-count-maybe passes this placeholder unmodified to 
org-update-checkbox-count which does all the heavy lifting. But nowhere is the 
all argument ever modified, it continues to be that non-nil placeholder, which 
seems to get evaluated as true. It’s not clear to me why this placeholder would 
get passed to the function if it is never set to anything else. But again, I 
don’t fully understand the single quote syntax.

The org-update-checkbox-count is quite complicated (from my elisp-neophyte 
perspective), so it is not clear to me why it resets the statistics cookies to 
[0/0], but whatever it does, it does it in the entire file.

The “fix” that I made was on the first and last lines of the function:

(defun org-reset-checkbox-state-subtree (&optional all)
...
(org-update-checkbox-count-maybe all)

where you can see all I did was remove the single quote from all, and added all 
as an optional parameter. Now I feel like this was the wrong fix, but it does 
solve my problem! Maybe the real problem had nothing to do with the entire 
buffer part, and was more about why the statistics cookies get updated to [0/0].

Here is a minimal example that showcases the problem (without my “fix” in 
place):

* Task A [1/2]
** DONE Subtask A.1
   CLOSED: [2020-11-12 Thu 08:47]
** TODO Subtask A.2
* TODO Daily Wind-Down
  SCHEDULED: <2020-11-12 Thu 17:00 +1d>
  :PROPERTIES:
  :RESET_CHECK_BOXES: t
  :END:
- [ ] Respond to emails
- [ ] Pat myself on the back

Marking the Daily Wind-Down as complete resets the buffer so it looks like:
* Task A [0/0]
** DONE Subtask A.1
   CLOSED: [2020-11-12 Thu 08:47]
** TODO Subtask A.2
* TODO Daily Wind-Down
  SCHEDULED: <2020-11-13 Fri 17:00 +1d>
  :PROPERTIES:
  :RESET_CHECK_BOXES: t
  :LAST_REPEAT: [2020-11-12 Thu 08:47]  
  :END:
- [ ] Respond to emails
- [ ] Pat myself on the back

The first line shows the problem: the statistics cookies have updated to [0/0].

For what it’s worth, my “fix” may be the wrong fix, but it does solve the 
problem! So if anyone else runs into the same problem, I hope my horrible elisp 
debugging is mildly helpful!

Kind regards,
Bob Wilson


> On Nov 11, 2020, at 7:22 PM, Kyle Meyer  wrote:
> 
> Bob Wilson writes:
> 
>> I’m writing about a possible bug in
>> org-reset-checkbox-state-subtree. This function calls
>> org-update-checkbox-count-maybe with argument 'all, but this value is
>> not defined in the function (or anywhere else that I can see).
> 
> [ I'm looking at the copy on master (e9c3993ee), though org-list.el
>  hasn't changed since that last release. ]
> 
> org-reset-checkbox-state-subtree calls
> 
>(org-update-checkbox-count-maybe 'all)
> 
> and org-update-checkbox-count-maybe c

Language and LaTeX longtable (mismatch org-export-dictionary ./. org-latex-babel-language-alist)

[H.-Dirk Schmitt]

Hello!

I'm using the following statements in a org-mode document:
  #+LANGUAGE: de-de

  #+LATEX_HEADER: \usepackage[AUTO]{babel}

This works fine, especially that the ngerman hyphenation is used (→
'de' is translated to the old (outdated) language rules 'germanb').

To set a really long table I'm using the longtable latex package via:
 #+ATTR_LATEX: :environment longtable  :align |l|r|r|r| :placement [h]

My problem is now that this is emitting the LaTeX code:
  \multicolumn{4}{l}{Continued from previous page}

As I understand this should be translated by org-mode via org-export-
dictionary to the German phrase "Fortsetzung von vorheriger Seite", but
the key 'de-de' is not defined here.

My questions:
1. Is this a bug in Org-Mode 9.1 or 9.4 (both tested)?
2. Or is this still a missing feature? Should the translation
processing includes a conversion for language codes like 'de-de' to a
fallback 'de'.
3. How can I extend in my ~/.emacs  the org-export-dictionary?

Best Regards,

H.-Dirk Schmitt

Bug: Exporting "as PDF file and open" causes unnecessary revert prompt if PDF was already open [9.4 (release_9.4-103-gf0b8de @ /home/erik/.emacs.d/straight/build/org/)]

[Erik Hahn]

In a graphical emacs -Q instance, open any Org file. Export it as PDF and open
(C-e l o). Then do the same again. Emacs prompts "File foo.pdf changed
on disk. Reread from disk (yes or no)" although no external program (not
counting latex as external here as it was started by Emacs) actually
changed the file.

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian
Package: Org mode version 9.4 (release_9.4-103-gf0b8de @ 
/home/erik/.emacs.d/straight/build/org/)

[PATCH] ob-java.el: Allow for more whitespace

[ian martins]

Two patches are attached. One allows for more whitespace in java code
blocks. The other fixes a bug that would result in a main method being
wrapped in another main method.
From 9fbb5a436ebc007d19adc20fcee7ebf08e4aec3b Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:09:11 -0500
Subject: [PATCH 1/2] ob-java.el: Do not wrap a main method in a main method

* lisp/ob-java.el (org-babel-expand-body:java): The code was checking
for existence of a class declaration before wrapping the content of
the code block in a main method, but it should be checking for
existence of a main method.
---
 lisp/ob-java.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index d8d4db852..92e873f0d 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -296,7 +296,7 @@ is simplest to expand the code block from the inside out."
   ;; wrap main.  If there are methods defined, but no main method
   ;; and no class, wrap everything in a generic main method.
   (goto-char (point-min))
-  (when (and (not (re-search-forward org-babel-java--class-re nil t))
+  (when (and (not (re-search-forward org-babel-java--main-re nil t))
  (not (re-search-forward org-babel-java--any-method-re nil t)))
 (org-babel-java--move-past org-babel-java--package-re) ; if package is defined, move past it
 (org-babel-java--move-past org-babel-java--imports-re) ; if imports are defined, move past them
-- 
2.25.1

From 19af495f4152cd7b8580ceab2a168182f44bedbb Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:18:48 -0500
Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code

* lisp/ob-java.el (defconst *-re): Updated regexps to allow for more
whitespace in the content of java code blocks, and removed some
redundancies.

* testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
Added test case with lots of whitespace.
---
 lisp/ob-java.el  | 10 +-
 testing/lisp/test-ob-java.el | 18 ++
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 92e873f0d..d65176d4e 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -77,15 +77,15 @@ like javac -verbose."
   :package-version '(Org . "9.5")
   :type 'symbol)
 
-(defconst org-babel-java--package-re "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
+(defconst org-babel-java--package-re "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
   "Regexp for the package statement.")
-(defconst org-babel-java--imports-re "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
+(defconst org-babel-java--imports-re "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
   "Regexp for import statements.")
-(defconst org-babel-java--class-re "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*\n?[[:space:]]*{"
+(defconst org-babel-java--class-re "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*{"
   "Regexp for the class declaration.")
-(defconst org-babel-java--main-re "public static void main(String\\\(?:\\[]\\\)?[[:space:]]+[^ ]+\\\(?:\\[]\\\)?).*\n?[[:space:]]*{"
+(defconst org-babel-java--main-re "public[[:space:]]+static[[:space:]]+void[[:space:]]+main[[:space:]]*([[:space:]]*String[[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
   "Regexp for the main method declaration.")
-(defconst org-babel-java--any-method-re "public .*(.*).*\n?[[:space:]]*{"
+(defconst org-babel-java--any-method-re "public[[:space:]]+.*[[:space:]]*([[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
   "Regexp for any method.")
 (defconst org-babel-java--result-wrapper "\npublic static String __toString(Object val) {
 if (val instanceof String) {
diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index e14975412..50d3ef5b0 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -128,6 +128,24 @@ public static void main(String args[]) {
 #+end_src"
 (should (string= "42" (org-babel-execute-src-block)
 
+(ert-deftest ob-java/simple-with-main-whitespace ()
+  "Hello world program that defines a main function with the square brackets after `args'."
+  (org-test-with-temp-text
+  "#+begin_src java :results output silent
+public
+static
+void
+main
+ (
+ String
+ args []
+ )
+{
+System.out.print(42);
+}
+#+end_src"
+(should (string= "42" (org-babel-execute-src-block)
+
 (ert-deftest ob-java/simple-with-class ()
   "Hello world program that defines a class."
   (org-test-with-temp-text
-- 
2.25.1

Re: Archiving repeated tasks under corresponding date tree for each repeated item

[Ihor Radchenko]

> Hope it is clear now, thanks so much for any help!

Sorry for not making my previous email more clear. I actually understood
what you want to achieve. My suggestion was rather an alternative
approach to "revisit the past" - you can always build agenda view for a
specific date (or range of dates) in the past. That way, you would not
need to look into archive file manually at all.

On your actual question, I think I found some old reddit comment [1] that
may be relevant. The code provides a new command to archive an org
headline without actually deleting it. That way, you will get a copy of
your headline on the date of archival. Below is the original code with
me adding docstrings for more clarity.

(defun my/org-archive-delete-logbook ()
"Delete LOGBOOK of the entry at point. It is obsolete once the copy of
the item is moved to the archive file."
  (save-excursion
   (org-end-of-meta-data)
   (let ((elm (org-element-at-point)))
 (when (and
(equal (org-element-type elm) 'drawer)
(equal (org-element-property :drawer-name elm) "LOGBOOK"))
   (delete-region (org-element-property :begin elm)
  (org-element-property :end elm))

(defun my/org-archive-without-delete ()
"Archive item at point, but do not actually delete it."
  (cl-letf (((symbol-function 'org-cut-subtree) (lambda () nil)))
(org-archive-subtree)))

(defun my/org-archive-logbook ()
"Create an archive copy of subtree at point and delete LOGBOOK in the
first headline of the subtree."
  (interactive)
  (my/org-archive-without-delete)
  (my/org-archive-delete-logbook))

I think you can modify the last function and call it in
org-trigger-hook, so that repeating items would be archived without
deleting every time you mark the item DONE.

[1] 
https://old.reddit.com/r/orgmode/comments/dg43hs/can_i_archive_a_property_drawer/f3frk2n/

Best,
Ihor

Gerardo Moro  writes:

> Thanks, Ihor.
> Indeed, that is an excellent feature of agenda. I use it sometimes  to
> visualize what I have DONE during the week on the sopt.
> What I aim to accomplish however is a more systematic log of all the DONE
> tasks, this is, to have an archive file where to archive all tasks.
> This file is in the format:
>
> 2020
>2020-01-01 DONE task1
>2020-01-12 DONE task2
>2020-02-01 CANCELLED task3
>
> So it is indeed a datetree file where I can revisit the past :) if you will.
> The problem with habits and repeated tasks is that they don't get archived
> when DONE...
> They get archived once the task is cancelled or completed as a whole, all
> under the day the task stopped continuing, under which I have all the
> logged individual completion.
> It would be desirable to have each "completion" archived under its
> corresponding datetree, it is more meaningful :)
>
> Hope it is clear now, thanks so much for any help!
> GM
> So even if I have beeng doing the task every wednesday for a year, it won't
> be archived
>
> El mar., 3 nov. 2020 a las 7:53, Ihor Radchenko ()
> escribió:
>
>> > It would be great if each of these individual "task
>> > happenings" were archived under the date and time they were completed
>> > individually, and not just all as one block. This way I could get weekly
>> > reviews that take those into account.
>>
>> What about trying to do your weekly review using org-agenda? You can
>> show the task every day you complete it by enabling org-agenda-log-mode
>> in your weekly agenda (v l). If your tasks are also archived regularly,
>> you may also need "v A" to include archive files into agenda view.
>>
>> Best,
>> Ihor
>>
>>
>> Gerardo Moro  writes:
>>
>> > Dear all,
>> >
>> > I am resending this as I believe it's a useful concept to implement,
>> > especially by those who track their tasks and do weekly/monthly reviews.
>> >
>> > When I archive a repeated task (let's say, a learning project of 15
>> minutes
>> > every Wednesday day for 2 months), the task gets archived in a date tree
>> > all under the day it was closed (cancelled) as a whole. This means that
>> all
>> > the LOGGED individual instances of repetition are archived on the day the
>> > project got completed. It would be great if each of these individual
>> "task
>> > happenings" were archived under the date and time they were completed
>> > individually, and not just all as one block. This way I could get weekly
>> > reviews that take those into account. Not sure if I made myself
>> understood!
>> > :))
>> >
>> > Thanks!
>> > G
>>

Re: typos in doc.org

[Richard Lawrence]

hj-orgmod...@hj.proberto.com writes:

> https://www.orgmode.org/worg/sources/doc.org :
>
> availables -> available ,  uesr -> user :

Fixed - thanks for the report!

-- 
Best,
Richard

typos in doc.org

[hj-orgmode-1]

https://www.orgmode.org/worg/sources/doc.org :

availables -> available ,  uesr -> user :

24c24
<  over availables options will open the custom interface, which
---
>  over available options will open the custom interface, which
27c27
< These are the main "internals" that the uesr may want to know about,
---
> These are the main "internals" that the user may want to know about,

Agenda follow mode + indirect window settings

[Gerardo Moro]

Hi,

I want my agenda to have follow-mode active when starting Emacs.
I suppose this would do the trick?

(setq org-agenda-start-with-follow-mode t)
(setq org-agenda-follow-indirect t)

1) Do I need both? I have observed that having only the second one does not
work.
2) Is there a way to make the "indirect" window populate the vertically
existing window (I always work with the frame split in two vertically).
Right now it shows in a very small window beneath the agenda.

Thank you so much,
G

Re: Archiving repeated tasks under corresponding date tree for each repeated item

[Gerardo Moro]

Thanks, Ihor.
Indeed, that is an excellent feature of agenda. I use it sometimes  to
visualize what I have DONE during the week on the sopt.
What I aim to accomplish however is a more systematic log of all the DONE
tasks, this is, to have an archive file where to archive all tasks.
This file is in the format:

2020
   2020-01-01 DONE task1
   2020-01-12 DONE task2
   2020-02-01 CANCELLED task3

So it is indeed a datetree file where I can revisit the past :) if you will.
The problem with habits and repeated tasks is that they don't get archived
when DONE...
They get archived once the task is cancelled or completed as a whole, all
under the day the task stopped continuing, under which I have all the
logged individual completion.
It would be desirable to have each "completion" archived under its
corresponding datetree, it is more meaningful :)

Hope it is clear now, thanks so much for any help!
GM
So even if I have beeng doing the task every wednesday for a year, it won't
be archived

El mar., 3 nov. 2020 a las 7:53, Ihor Radchenko ()
escribió:

> > It would be great if each of these individual "task
> > happenings" were archived under the date and time they were completed
> > individually, and not just all as one block. This way I could get weekly
> > reviews that take those into account.
>
> What about trying to do your weekly review using org-agenda? You can
> show the task every day you complete it by enabling org-agenda-log-mode
> in your weekly agenda (v l). If your tasks are also archived regularly,
> you may also need "v A" to include archive files into agenda view.
>
> Best,
> Ihor
>
>
> Gerardo Moro  writes:
>
> > Dear all,
> >
> > I am resending this as I believe it's a useful concept to implement,
> > especially by those who track their tasks and do weekly/monthly reviews.
> >
> > When I archive a repeated task (let's say, a learning project of 15
> minutes
> > every Wednesday day for 2 months), the task gets archived in a date tree
> > all under the day it was closed (cancelled) as a whole. This means that
> all
> > the LOGGED individual instances of repetition are archived on the day the
> > project got completed. It would be great if each of these individual
> "task
> > happenings" were archived under the date and time they were completed
> > individually, and not just all as one block. This way I could get weekly
> > reviews that take those into account. Not sure if I made myself
> understood!
> > :))
> >
> > Thanks!
> > G
>