org-alert icon indicating copy to clipboard operation
org-alert copied to clipboard

Plain timestamps should be recognized in addition to DEADLINE or SCHEDULED ones

Open ndokos opened this issue 3 years ago • 7 comments

It is common practice to have entries with plain timestamps, e.g. appointment reminders. See the Important note in the manual e.g.

org-alert--parse-entry currently insists that the timestamp be either a DEADLINE or a SCHEDULED timestamp: I think that's too draconian and should be relaxed to accept plain timestamps.

ndokos avatar Sep 14 '21 15:09 ndokos

Thanks for pointing that out. I think cfc8234 should at least help to address this issue. I'm not too sure how to update org-alert-match-string to get this behavior, but if you set it to nil it will just pull in every entry. This might be a pretty big problem if you have non-time-stamped entries in your agenda files, but it works decently otherwise. And then you can set the newly-exposed variable org-alert-time-match-string to something without SCHEDULED|DEADLINE in the front. I used

 (setq org-alert-time-match-string "<.*\\([0-9]\\{2\\}:[0-9]\\{2\\}\\).*>"))

when testing and it seemed to do what you want. Let me know if you have any trouble though.

ntBre avatar Sep 16 '21 12:09 ntBre

This seems to work, unfortunately with these settings: (use-package org-alert :ensure t :config (setq alert-default-style 'libnotify org-alert-interval 60 org-alert-notification-title "ORG Reminder!" org-alert-time-match-string "<.*\\([0-9]\\{2\\}:[0-9]\\{2\\}\\).*>" org-alert-match-string nil) (org-alert-enable)) I get the following error: Error running timer ‘org-alert-check’: (error "Invalid use of ‘\\’ in replacement text") Any ideas what could be wrong?

In general I think that the package should accept plain timestamps, since this is the canonical way in ORG to put events in the agenda.

Thanks!

ramos avatar Feb 17 '22 15:02 ramos

@ramos I'll reopen this and take a look in the next couple of days. I've been meaning to try to close the remaining open issues on the project.

I just tried a minimal example using your regex and it seems to work:

(let ((body "<2022-02-17 Thu 14:00>"))
  (string-match "<.*\\([0-9]\\{2\\}:[0-9]\\{2\\}\\).*>" body)
  (match-string 1 body))

Is that the kind of time stamp you're referring to? Also do you mean you think it should accept plain timestamps by default?

I think you might be running into an issue with the org-alert-match-string variable. Do you have non-time-stamped entries in this agenda file? Actually, could you just send an example of the type of file you're trying to parse? I would also like to add some test cases. Thanks!

ntBre avatar Feb 17 '22 20:02 ntBre

The kind of entries are like:

* Books to read
* * Alice in Wonderland
* Important call
<2022-02-25 Fri 15:00> 

With this file in your agenda files, it should alert you of "important call" on the 25th of Feb. The other entries without timestamps should be ignored.

I have tried the following:

(use-package org-alert
  :ensure t
  :config
  (setq org-alert-interval 60
	org-alert-notification-title "ORG Reminder"
	org-alert-time-match-string "<.*\\([0-9]\\{2\\}:[0-9]\\{2\\}\\).*>"
	org-alert-match-string nil)
  (org-alert-enable))

But now every heading is alerted, which is not what I wanted.

Thanks!

ramos avatar Feb 22 '22 10:02 ramos

@ramos Thanks for the test cases! Alerting on every heading is what I ran into before too. I ended up just splitting my org files to keep the scheduled stuff in its own file. I'll try to rework org-alert to handle this, as that's really how it should have worked all along.

ntBre avatar Feb 23 '22 21:02 ntBre

Perhaps parsing the agenda view, instead of the agenda files, is a good approach.

This would also properly support using functions as scheduled times. For instance, I use DEADLINE: <%%(diary-last-day-of-month date)>.

aeblyve avatar Aug 13 '23 23:08 aeblyve

Hmm, that's an interesting idea. Right now we're using org-map-entries to get the entries in the first place, so it would be a big refactor but might end up being simpler in the end. Clearly with how long this issue has been open, I haven't really prioritized it, but I would be glad to accept a PR!

ntBre avatar Aug 17 '23 15:08 ntBre