emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Memnon Anon <gegendosenfleisch@googlemail.com>,
	Matt Lundin <mdl@imapmail.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: Occurance property, or some similar name?
Date: Wed, 13 Apr 2011 17:34:32 +0200	[thread overview]
Message-ID: <EA906F57-686C-43D2-B2F8-32C7DE333BFF@gmail.com> (raw)
In-Reply-To: <874o63tgg5.fsf@mean.albasani.net>


On 12.4.2011, at 22:00, Memnon Anon wrote:

> Hi,
> Christopher Allan Webber <cwebber@dustycloud.org> writes:
> 
>> I was once one of the many people who apparently originally
>> misunderstood what "SCHEDULED" meant, and used to set it to like, an
>> appointment time.
> 
> Well, you can use it that way.
> The point is: Scheduled items behave differently to timestamped items.
> If you prefer the behaviour scheduling provides you with, go for it.
> 
>> I kind of miss how nice it was back when I misunderstood how events work
>> (escept for all of those non-TODOs staying around forever on my
>> agenda..) where I had a dedicated property for this, and pressing
>> C-c C-s would always change that property.
> 
> I just did a quick check. 
> It seems to me that timestamps within a property work.
> So, if you prefer, you can set your timestamps in a property like this:
> 
> *  NEXT Task 2
>   :LOGBOOK:
>   :END:
>   :PROPERTIES:
>   :DATE:     <2011-04-12>
>   :END:
> 
> If you want a convenient keybinding to set this property, this seems
> to work:
> 
> --8<---------------cut here---------------start------------->8---
> (defun my-org-set-date ()
>  "Set DATE Property via org-read-date."
>  (interactive)
>  (org-set-property "DATE" (concat "<"(org-read-date)">")))
> 
> (define-key org-mode-map (kbd "C-c C-S-s") 'my-org-set-date)
> --8<---------------cut here---------------end--------------->8---
> 
> Okay, there is still setting it in the agenda.
> There are already functions doing special treatment for e.g. effort.
> It should work to grab it and modify it to our needs ...
> 
> --8<---------------cut here---------------start------------->8---
> (defun my-org-agenda-set-date ()
>  "Set the DATE property for the current headline."
>  (interactive)
>  (org-agenda-check-no-diary)
>  (org-agenda-show)   ;;; FIXME This is a stupid hack and should not be needed
>  (let* ((hdmarker (or (org-get-at-bol 'org-hd-marker)
> 		       (org-agenda-error)))
> 	 (buffer (marker-buffer hdmarker))
> 	 (pos (marker-position hdmarker))
> 	 (inhibit-read-only t)
> 	 newhead)
>    (org-with-remote-undo buffer
>      (with-current-buffer buffer
> 	(widen)
> 	(goto-char pos)
> 	(save-excursion
> 	  (org-show-context 'agenda))
> 	(save-excursion
> 	  (and (outline-next-heading)
> 	       (org-flag-heading nil)))   ; show the next heading
> 	(goto-char pos)
> 	(call-interactively 'my-org-set-date)
> 	(end-of-line 1)))))
> 
> (define-key org-agenda-keymap (kbd "C-c C-S-s") 'my-org-agenda-set-date)
> --8<---------------cut here---------------end--------------->8---

That looks like it should work.

I did some quick checking - I believe it would be possible to
make DEADLINE, SCHEDULED and CLOSED properties instead of having
them in the second line.  You and Matt have just shown that
an arbitrary property (like appointment) can serve as the
standard date of an entry.  The parser that is looking for CLOSED,
SCHEDULED, DEADLINE is lenient and does not mind if there is an
additional colon in front of the keyword.  So if you have a
(currently not allowed) :SCHEDULED: property, it will
behave correctly when constructing the agenda.

If I am not mistaken, we could introduce (not-trivial, but
likely without major headaches) an option like
org-planning-use-properties or so.  Much will work out of
the box.  The places where changes are needed are these functions:

org-add-planning-info
org-entry-put
org-entry-get
org-entry-properties

The main problem would be that it would not be trivial to have
mixed entries - user would have to make a decision if they want
planning info in the property drawer or not.  Things would not work well
or require a lot of extra checking with files that as mixed (agenda
production would work OK, but changing dates may cause problems.
But I guess this could be handled one way or another.

As I have explained earlier, to have planning info like tags and the
TODO keyword outside of drawers has historic reasons, but it is
also good for newcomers.

- Carsten



> 
> Did some quick testing, it *seems* to work.
> But I have no expertise in elisp (or programming for that matter), so
> this is probably "wrong" in one way or the other :).
> 
>> What I'm saying I guess is:
>> - Is there a popular property name for when something should be
>>   happening, in a non-TODO way?  I've thought of "OCCURANCE" but maybe
>>   that isn't the best (I suspect not)
>> - Maybe if we formalize this property, we should make a command for it?
>>   Maybe C-c C-S-o?
>> - It would be nice to formalize this so we could actually steer people
>>   in the right direction in the docs.
> 
> Oh, this was not a "How can I do x?" mail, but a request to formalize
> this in org core .... 
> 
> Nevermind ;)
> 
> Memnon
> 
> 

      parent reply	other threads:[~2011-04-13 16:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-11 22:42 Occurance property, or some similar name? Christopher Allan Webber
2011-04-12  4:22 ` theo
2011-04-12 14:41   ` Christopher Allan Webber
2011-04-12 19:28     ` Matt Lundin
2011-04-12 19:25 ` Matt Lundin
2011-04-12 20:52   ` Christopher Allan Webber
2011-04-13  1:01     ` Matt Lundin
2011-04-13 13:07       ` Christopher Allan Webber
2011-04-13  8:19     ` Michael Brand
2011-04-13 13:08       ` Christopher Allan Webber
2011-04-13 14:19         ` Michael Brand
2011-04-13 14:43           ` Christopher Allan Webber
2011-04-13 15:42             ` Michael Brand
2011-04-13 15:57               ` Christopher Allan Webber
2011-04-12 20:00 ` Memnon Anon
2011-04-12 20:24   ` Richard Riley
2011-04-13 15:34   ` Carsten Dominik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EA906F57-686C-43D2-B2F8-32C7DE333BFF@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=gegendosenfleisch@googlemail.com \
    --cc=mdl@imapmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).