This is a loose collection of ideas and TODO items for the future development of Org-mode. These ideas come from various sources, mostly from emacs-orgmode@gnu.org, from direct emails to me, or from my own day-dreaming. I don't always mention the source of an idea, out of laziness. However, when I implement a good idea, I try to mention the origin of this idea in the Acknowledgments section of the manual - let me know if I forgot to give you credit for something.
On this page, I am using TODO keywords in the following way:
| Keyword | Intention |
|---|---|
| TODO | A development that is going to happen, once I have time or once I figure out how to do it. |
| IDEA | A new idea, I have not yet decided what if anything I will do about it. |
| WISH | A wish, probably voiced by someone on emacs-orgmode@gnu.org. This is less than a new idea, more a change in existing behavior. |
| QUESTION | A question someone asked, that needs some thinking before it can be answered |
| DECLINED | I have decided not to implement this feature, but I am keeping it in the list so that people can see it, complain, or still try to convince me. |
| INCONSISTENCY | Some behavior in Org-mode that is not as clean and consistent as I would like it to be. |
| BUG | This needs to be fixed, as soon as possible. |
| DONE | Well, done is done. |
| NEW | This is a tag, indicating recently added entries |
| <50> |
Could I use a dynamic block for this?
(and (fboundp 'coding-system-get)
(boundp 'buffer-file-coding-system)
buffer-file-coding-system))
always returns nil, implicating that setting the coding system for
the export buffer would not work correctly. however, I have never
followed up on this and never had a bug report - so I am wondering
if there is an issue at all.
TODO entries: 1 or 1,2,...
DEADLINE is 10-ddays, i.e. it is 10 on the due day
i.e. it goes above top todo stuff 7 days
before due
SCHEDULED is 5-ddays, i.e. it is 5 on the due date
i.e. it goes above top todo on the due day
TIMESTAMP is 0 i.e. always at bottom
but as a deadline it is 100
but if scheduled it is 99
TIMERANGE is 0 i.e. always at bottom
DIARY is 0 i.e. always at bottom
Priority * 1000
No, because S-left/right does this already pretty well
#+TAGS: [@WORK(w) @HOME(h) @CLUB(c)] Laptop(l) PC(p) Car(r)This could indicate that @WORK, @HOME, @CLUB are mutually exclusive.
If I do this, I will also need a syntax for the global alist to indicate the same thing.
It seems to me that with such grouping of tags, sorting would be useful as it would improve the overview over the current tags. I might even be able to support mutually exclusive tags with fontification in the interface. Or arrange things such that the mutually exclusive ones are all in the same row or column, to optimize the visual feedback.
For the internal format, I think best would be something like
'( (:startgroup) ("@work") ("@home") ("@club") (:endgroup)
("Laptop") ("PC") ("Car"))
This setup makes sure that assoc and rassoc still do work as
expected.
Then: how to update this? Each time a checkbox is added or toggled, go up and update all the counts, right up to something which is not an item, or up to the previous header line.
Maybe I should also make an option for turning this on, to avoid slowdown. I guess for long lists this could be slow.
Also would need a command for global update.
An maybe plain list and checkboxes should get their own chapter? In Structure they seem to be a bit hidden…..
Also a menu sublist…
Email from John Smith (if I an the receiver) Email to John Smith (if I am the author)or
John Smith on: Some subject (this is the current Org-mode default.)The first format requires better parsing of the messages (to get both author and receiver names), and also some way to detect if I am the author of this email or not.
or something like that…….
Date: 2008/02/12 12:28:15