Re: [Orgmode] Modify org-remember-templates to include a name to show when selecting it
On Oct 10, 2007, at 12:15, Matiyam wrote: Hi! In my setup i have 5 org-remember-templates. Since my memory is not very good :), i have modified org-remember-templates to include another element in the list that tells me the name of it. And then org-remember-apply-template to, when prompting for selecting the template, show the name along with the keycode. Something like: Select template: Work (w) Home (h) I think the patch is easy enough, so i haven't created a bug. The idea is good, but since you insert a new element in the middle of the list, it will break all existing customization of that variable. I can make it internally compatible if the name is the first thing in each list. Will be in 5.12. Thanks. - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: how to add a LOCATION in the exported iCal
On 2007-10-09 22:37 +0100, Bastien wrote: Leo [EMAIL PROTECTED] writes: However, in order to insert the LOCATION property, I need to first run org-insert-property-drawer and then `C-c C-c s' ... Is there a better way of setting LOCATION? Well, no. But property drawers are designed for this kind of additionnal information, aren't they? You might also think of the SUMMARY and DESCRIPTION props, which are set the same way. It is more consistent to keep all this in the same place. On 2007-10-09 22:00 +0100, Carsten Dominik wrote: [...] You can bind `org-set-property' to a key, it can be called without first creating the drawer. I guess I should think up a default binding. Another good way to set LOCATION is column view. - Carsten Many thanks Bastien and Carsten! -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the most powerful email client -- http://gnus.org/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Code snippet for bolding or italicizing A/C priority strings
On Oct 10, 2007, at 10:37, John Wiegley wrote: John Wiegley [EMAIL PROTECTED] writes: This code snippet will modify your agenda buffer upon creation so that the string [#A] is bolded, and [#C] is italicized. It keeps whatever color it had, it's just now strong or weak based on priority. Actually, I'm finding I like having the whole title bolded or italicized, just like Gnus does: I have generalized this code to work with modified customized priorities and to do the right thing when changing the priority from the agenda. Thi code will be in 5.12. You can turn it off with `org-agenda-fonfity-priorities', default will be on. Thanks, John! - Carsten ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: depending TODOs, scheduling following TODOs automatically
(Sorry, I'm writing this in my very-early Eurostar, it may not be accurate at the time it will be sent.) Eddward DeVilla [EMAIL PROTECTED] writes: I'm losing track of who proposed what. I was up late last night. I'm liking the TRIGGER/BLOCKER idea that Bastien has been talking about, Reshaping the proposal for TRIGGER/BLOCKER. Thinking of this again, I believe TRIGGER/BLOCKER should not be properties of a task, but rather of one of their properties. Then look at this: , | * A task | :PROPERTIES: | :TODO: NEXT | :: DONE (org-todo-in-subtree DONE) | :END: ` This says: when the :TODO: property is DONE perform the function (org-todo-in-subtree DONE), which could be a lambda expression. And then this: , | * A task | :PROPERTIES: | :TODO: MAYBE | :: NEXT (org-previous-entry-done-p) | :END: ` This says: only set the property :TODO: to NEXT when the previous entry is DONE. The advantage of this implementation is that - it capture John's idea of letting lisp expression do the job of performing actions (and checking for conditions), replacing the hairy ugly syntax I first proposed; - it's property-based, therefore more flexible than :NEXT: or even :TRIGGER: (unless we use very complex stuff in TRIGGERS) - it looks quite *readable* (especially if indentation is in use) - it's extensible: :?: trigger action interactively :!: don't trigger action interactively :|: don't trigger any action after this one :: give priority to this triggered action ... just to give a few ideas. except it lacks the ability to reference any task that isn't immediately before, after, under or above the triggering or blocked task. I'm starting to think links might be to best tool in org for identifying a task (todo item). I'm not sold on that yet. I may need to give that another night. I tend to think that a labelling system should not be designed in the same framework than the one we have been thinking about so far to add actions to property changes. After all, labels are only one very specific way to refer to tasks. We can build the trigger/blocker system then make it aware of labels, if any. But more experienced programmers might have better insight on this. Best, -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] writes: It's hard to 'address' a todo item. Not that hard: [[*Test%20headline]] Link's might be the best thing we have for that. Exactly! And what if the text of the link could also store the todo state value of its target (when both relevant and accessible[1])? For me, linear ordering would not be enough and requiring the hierarchy to model the dependencies will require me to break up tasks that logically belong together. It just might be that it's not time to address that though. The trigger/blocker functions might not be linear - they could check arbitrarily for any headline's property just by searching for the task in the buffer. Notes: [1] Their are plans for adding a TODO property to e-mail in Gnus, via the Gnus registry. Then storing a link from an e-mail from Gnus could suggest its TODO property as a default TODO property in Org. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
On Thu, Oct 11, 2007 at 01:44:11PM +0100, Bastien wrote: Eddward DeVilla [EMAIL PROTECTED] writes: It's hard to 'address' a todo item. Not that hard: [[*Test%20headline]] How does that work to address this case? * Hardware ** TODO Install * Software ** TODO Install :ADDRESSTHISONE: * Patches ** TODO Install Thats why I thought a GUID property would be required. Thanks. -- Russell Adams[EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Hi everyone,
I have read this discussion with great interest, and I would like to
add a few thoughts.
First, let me say that I was surprised that quite a few people are so
keen to see this kind of features. I myself would worry
a lot about spending more time to set up and maintain these connections,
than I would be saving by using them. And I am not sure if Org-mode
really scales up nicely when it comes to really large projects, large
number
of people interacting, keeping complex GANTT charts up to date etc.
Me, I have sometimes made these charts during an initial project setup,
to get a feeling what amount of time and resources would be needed, but
I have
never kept these complex structures alive and up to date. Obviously,
others
believe they can.
About implementing triggers and blockers in Org-mode:
- first of all, I believe we can keep the question of adressing
an item (using GUIDs or relations like next TODO item in the
subtree)
completely separate from the mechanism by which Org-mode triggers an
action.
- concerning the TRIGGER proposal by John, and the TRIGGER/BLOCKER
functionality
discussed later: In Emacs terms, this seems to translate into a
*hook*
that is called at the right moment. I'd say that a single hook is
enough.
The right moment to call it would be when Org-mode has figured out
everything
about a change that is about to occur, but before actually doing it.
We can be general what kind of change this could be, a TODO state
change,
adding a tag, setting a property, changing the priority, anything
really.
So we would have a property that contains a Lisp form, and that lisp
form would
be evaluated at that moment.
TRIGGER would then mean to perform actions in other entries.
BLOCKER would mean to query other entries for information, and, if
necessary,
abort the current action, for example by throwing to a specified
catch form.
Obviously, if you nee both triggers and blockers, the blockers need
to run
first, but we don't need separate properties/functions for this.
The detailed implementation would then be a number of Lisp functions
that
take as arguments a *single* structure that contains all the info of
the change,
for example a property list like
(list :type 'TODOSTATE :from nil %to INPROGRESS )
Compared to John's proposal with two lists describing previous and
new state,
the difference is that my list describes a *change*, while Johns
function would
have to figure out if the entry info actually changed. But for the
rest it is
similar.
The language that has been discussed could be moved into the call
and therefore set no restrictions what so ever. For example
:PROPERTIES:
:TRIGGER: '(progn
(org-block-unless 'done #address1 #address2 #address3)
(org-trigger 'todo RESUME #address4))
:END:
It seems to me that everything people have been discussing here could
be implemented based on such a scheme.
Security is an issue, yes. We could diffuse it a bit by blessing some
functions, but it would not be easy to totally get rid of this problem.
The best I can think of is to give the user a choice whether to execute
such code or not.
- Carsten
On Oct 9, 2007, at 4:15, Bastien wrote:
Adam Spiers [EMAIL PROTECTED] writes:
- if A changes to DONE, change B from BLOCKED to NEXT
(this is the obvious one)
- if A changes to DONE, change B from NEXT to CANCELLED
(if only A or B needs to be done, not both)
There must be others people can think of easily.
Updating my own proposal.
We could use the TODO keywords instead of SEND as a way to say that
reaching a particular todo state should trigger some kind of action.
See this for example[1]:
,
| * TODO When this task is marked done, send SCHEDULED to the next task
| :PROPERTIES:
| :CANCELED: {SCHEDULED 'subtree nil) {TODO 'subtree CANCELED}
| :DONE: {SCHEDULED 'next +1d} {TODO 'next NEXT}
| :END:
`
This would translate:
- when the todo state CANCELED is reached, trigger these two actions:
+ UNSCHEDULED all tasks in the current subtree (SCHEDULED to nil)
+ If a task in this subtree has a TODO keyword, turn it to CANCELED
- when the todo is set to DONE, trigger these two actions:
+ SCHEDULED next task (same level) for a day after current SCHEDULED
+ If the next task has a TODO keyword, turn it to NEXT
(I took the SCHEDULED and TODO properties, but this could be any
property from the :PROPERTIES: drawer.)
Therefore we would spare the cost of a new SEND special property. We
would just need to add TODO keywords to the set of special properties
(there is very little chance that users already use TODO keywords as
properties anyway, right?)
The drawback of using todo keywords instead of SEND is that SEND
calls
for RECV, and having both SEND and RECV would make it possible to
handle
dependencies in two directions: from the source to the target and back
to the source.
I first
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Carsten Dominik [EMAIL PROTECTED] writes: I have read this discussion with great interest, and I would like to add a few thoughts. I guess some of us were waiting for that -- thanks for sorting this out :) First, let me say that I was surprised that quite a few people are so keen to see this kind of features. Well, maybe there are too few tutorials out there demonstrating how people actually use Org, but everytime someone sends an example I'm amazed how this example looks so personal and add something new to what I could imagine. Given the number of different persons using Org (at least the number of emacs-orgmode@gnu.org subscribers?) I wouldn't be surprised that people come up with clever use of TRIGGERS in their own planning habits. Even better if they share it through tutorials... - first of all, I believe we can keep the question of adressing an item (using GUIDs or relations like next TODO item in the subtree) completely separate from the mechanism by which Org-mode triggers an action. 100% agreed (see my previous post.) So we would have a property that contains a Lisp form, and that lisp form would be evaluated at that moment. TRIGGER would then mean to perform actions in other entries. Just to make things perfectly clear - here is the process (as I understand it) : 1. describe the last change performed on a headline in a Lisp form 2. feed any TRIGGER with the Lisp form from 1. and perform actions Is that right? The detailed implementation would then be a number of Lisp functions that take as arguments a *single* structure that contains all the info of the change, for example a property list like (list :type 'TODOSTATE :from nil %to INPROGRESS ) The uncertainty of my understanding relies on the fact that I'm not sure whether this implementation is supposed to describe the TRIGGER function or the Lisp form from the first step of the process, as described above. Thanks for any further clarification! -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Carsten == Carsten Dominik [EMAIL PROTECTED] writes: Carsten First, let me say that I was surprised that quite a few Carsten people are so keen to see this kind of features. I myself Carsten would worry a lot about spending more time to set up and Carsten maintain these connections, than I would be saving by using Carsten them. And I am not sure if Org-mode really scales up Carsten nicely when it comes to really large projects, large number Carsten of people interacting, keeping complex GANTT charts up to Carsten date etc. Me, I have sometimes made these charts during an Carsten initial project setup, to get a feeling what amount of time Carsten and resources would be needed, but I have never kept these Carsten complex structures alive and up to date. I have to say that I'm a bit worried if org-mode goes in this direction. Just because Carsten may be able to beat it into shape to do this (albeit in very elegant lisp), it doesn't mean he should. org-mode developed as a means of maintaining lists, and it excels at this. Just because the GTD methodology uses the term Project doesn't mean that we should turn org-mode into a fully fledged project planning application. If you need project planning capability, then you probably need all the bells and whistles that go with it - GANT and PERT charts, critical path calculations, multi-user capabilities etc. My concern is that *very* few people need that type of functionality, and if you do, there are now some very good applications now under GNU/Linux to choose from. org-mode is a superb PIM and list manager (in my view, probably about the best there is). Just because we have one incredible hammer, let's not start seeing everything else as a nail! Just a personal viewpoint of course. :-) Pete ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Hey, I'm new here but I have to say that I totally agree with Pete. Why not just work on integration with popular project management tools? e.g export to Jira, Trac, ... (btw, syncing todos with Trac tickets would really come handy :) Sebastjan On 10/11/07, pete phillips [EMAIL PROTECTED] wrote: Carsten == Carsten Dominik [EMAIL PROTECTED] writes: Carsten First, let me say that I was surprised that quite a few Carsten people are so keen to see this kind of features. I myself Carsten would worry a lot about spending more time to set up and Carsten maintain these connections, than I would be saving by using Carsten them. And I am not sure if Org-mode really scales up Carsten nicely when it comes to really large projects, large number Carsten of people interacting, keeping complex GANTT charts up to Carsten date etc. Me, I have sometimes made these charts during an Carsten initial project setup, to get a feeling what amount of time Carsten and resources would be needed, but I have never kept these Carsten complex structures alive and up to date. I have to say that I'm a bit worried if org-mode goes in this direction. Just because Carsten may be able to beat it into shape to do this (albeit in very elegant lisp), it doesn't mean he should. org-mode developed as a means of maintaining lists, and it excels at this. Just because the GTD methodology uses the term Project doesn't mean that we should turn org-mode into a fully fledged project planning application. If you need project planning capability, then you probably need all the bells and whistles that go with it - GANT and PERT charts, critical path calculations, multi-user capabilities etc. My concern is that *very* few people need that type of functionality, and if you do, there are now some very good applications now under GNU/Linux to choose from. org-mode is a superb PIM and list manager (in my view, probably about the best there is). Just because we have one incredible hammer, let's not start seeing everything else as a nail! Just a personal viewpoint of course. :-) Pete ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell == Russell Adams [EMAIL PROTECTED] writes: Russell however you must realize that a tool meant to maintain Russell personal lists of items may eventually grow to encompass Russell larger projects. :-) I do realise this. But the question that needs to be answered is whether this is necessarily the best path ? Russell I think the reason this discussion took off is that if an Russell existing project management tool worked the way we wanted Russell it to, this would be a moot discussion. As it is, it Russell appears that none of the traditional PM style tools Russell integrate with Org use or provide similar functionality. I Russell know I've been frustrated trying to export Org data to MS Russell Project and keep them in sync. It could be that you are trying to use the wrong tool ? Task Juggler http://www.taskjuggler.org/ is cross platform and will do all the PM you need out of the box. As the system is based on a text mode, I am willing to bet that you could write some perl or other code to move your org file into it. Possibly the other way as well. Don't get me wrong - I have used PM tools myself for very big projects (in fact I used to maintain the PM FAQ document on Usenet many years ago http://www.non.com/news.answers/proj-plan-faq.html), but I just question if org-mode is the right path to follow for this. Let me explain my concern. If Carsten decides to move along the PM route (and it is entirely his call), then I suspect that the amount of code required to implement all the necessary functionality will be huge. It would probably dwarf the present org-mode code base. At that stage, the ability of Carsten to respond so quickly to requests for features and bug fixes will, I think, be compromised. Also, it is bound to have an effect on the speed of org mode. My main concern is that the focus of org-mode will have shifted away from where I want it to be, which I admit is a personal concern and perhaps a little selfish :-) Anyway, just my thoughts. Have a good evening all. Pete ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
On Thu, Oct 11, 2007 at 06:10:50PM +0100, pete phillips wrote: I do realise this. But the question that needs to be answered is whether this is necessarily the best path ? It isn't necessarily. I'm just pointing out it's likely to grow as more folks use it for larger lists. After all, most PM software just maintains a specialized kind of list. Yes I've looked at task juggler, and was impressed, but its overkill for what I need. (its also GUI!) I think the key here is that Org needs some PM-like functionality, but I certainly wouldn't advocate trying to make Org a full PM. Org is great for lists, notes, TODO's, etc. Ever try to take freeform notes in MS Project? ;] I'm interested to see where Carsten and the others take these ideas. Russell -- Russell Adams[EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell Adams [EMAIL PROTECTED] writes: I think the key here is that Org needs some PM-like functionality, but I certainly wouldn't advocate trying to make Org a full PM. Org is great for lists, notes, TODO's, etc. Ever try to take freeform notes in MS Project? ;] I'm interested to see where Carsten and the others take these ideas. Maybe I should have been soberer while trying to imagine how the suggested features could be implemented in Org. In fact, I just thought it was challenging to figure out what could be the best implementation and, while trying to write down those ideas, I surely gave the false impression that I took for granted that Org should go that direction. But this is, of course, questionable. I think this direction is the good one if: 1. people provide convincing examples on how PM-like features would be useful for their own use of Org; 2. the implementation does not change what people already like in Org; 3. the implementation is incremental, slowly absorbing proposals from people really using them. As for 1. I can think of a very simple need I come accross quite often: I have a few headlines, and the first one is typically being marked NEXT. Once this task is done, I want the next one to be marked NEXT. Other example: when I cancel a headline, I want to interactively cancel subtasks that still populate the agenda buffer. For 2. and 3., only Carsten can have a clear view on that ones I guess. Regards, -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell == Russell Adams [EMAIL PROTECTED] writes: Russell It isn't necessarily. I'm just pointing out it's likely to Russell grow as more folks use it for larger lists. After all, most Russell PM software just maintains a specialized kind of list. Russell Yes I've looked at task juggler, and was impressed, but its Russell overkill for what I need. (its also GUI!) Nah. It *has* a GUI, but underneath it is text based. I've run a few projects with it, and I know it uses text. The structure is very simple. From the Tutorial: Chapter 4. Tutorial: Your First Project We have mentioned already that TaskJuggler uses plain text files that describe the project to schedule it. As you will see now, the syntax of these files is easy to understand and very intuitive. I doubt it's overkill. The nice thing about task juggler is that you can just use as much as you need. I have used it for some large projects (but, like Carsten, only for the initial planning and resource allocation phase). I genuinely think that if there is a band of org-moders (hmmm we could do with a cooler collective noun I think ?) who need PM functionality, then a combination of org-mode and TJ with some perl glue would be pretty good. Russell I think the key here is that Org needs some PM-like Russell functionality, but I certainly wouldn't advocate trying to Russell make Org a full PM. Org is great for lists, notes, TODO's, Russell etc. Ever try to take freeform notes in MS Project? ;] Nope. I don't use MS to start with. ;-) Also, when using TJ, I was also able to make notes in emacs (because I was coding the TJ files in emacs). Anyway, this horse is flogged to death! If your experience of TJ is only the GUI, I'd seriously recommend a look at the command line mode. The nice thing about using org-mode with other programmes is that it tends to conform to the UNIX philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Pete ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: depending TODOs, scheduling following TODOs automatically
Russell Adams schrieb: On Thu, Oct 11, 2007 at 06:10:50PM +0100, pete phillips wrote: I do realise this. But the question that needs to be answered is whether this is necessarily the best path ? It isn't necessarily. I'm just pointing out it's likely to grow as more folks use it for larger lists. After all, most PM software just maintains a specialized kind of list. Yes I've looked at task juggler, and was impressed, but its overkill for what I need. (its also GUI!) I think the key here is that Org needs some PM-like functionality, but I certainly wouldn't advocate trying to make Org a full PM. Org is great for lists, notes, TODO's, etc. Ever try to take freeform notes in MS Project? ;] I'm interested to see where Carsten and the others take these ideas. Russell -- Russell Adams[EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode I also do not expect to grow Org into anything near a full PM. But I do would be more than glad to get some basic (trigger or blocker) functionality to model dependencies between todos. Again, one of my main needs would be to hide todos until other todos are in a certain state. Then show them after the trigger is pulled. At the moment I have to a lot of todos in my agenda which I cannot work on because of the trigger not ready. Or I have to undo the todos to not see them and not forget to trigger them myself at the right moment. Thats my 2 cents I stated the discussion with. rainer ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: depending TODOs, scheduling following TODOs automatically
On 2007-10-11 22:12 +0100, Rainer Stengele wrote: I also do not expect to grow Org into anything near a full PM. But I do would be more than glad to get some basic (trigger or blocker) functionality to model dependencies between todos. I'd rather org stays as a PIM not PM; there are tons of PMs, please use them. Again, one of my main needs would be to hide todos until other todos are in a certain state. Then show them after the trigger is pulled. At the moment I have to a lot of todos in my agenda which I cannot work on because of the trigger not ready. Or I have to undo the todos to not see them and not forget to trigger them myself at the right moment. Thats my 2 cents I stated the discussion with. rainer -- .: Leo :. [ sdl.web AT gmail.com ] .: [ GPG Key: 9283AA3F ] :. Use the most powerful email client -- http://gnus.org/ ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Categories
Categories are fairly handy for keeping the agenda well organised, but what are the functionalities for moving tasks between different categories e.g a task might move from PROJ1 to PROJ2 or some such? Must it be done manually using cut and paste in the org file? ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] clarification about org-mode
The spate of design memos about GUIDs and scheduling leads me to ask this : is there any concept of depends on at all at the moment in org? I don't see it if there is. e.g its quite possible to have a level one task complete but a level 2 one incomplete. ** DONE PHP/HTTP authentication:WEB: SCHEDULED: 2007-10-13 Sat - State TODO [2007-10-12 Fri 01:30] \\ get php /http authentication working *** STARTED sub task SCHEDULED: 2007-10-12 Fri - State STARTED[2007-10-12 Fri 01:32] \\ started - State TODO [2007-10-12 Fri 01:31] \\ blah ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: depending TODOs, scheduling following TODOs automatically
Hi, I am generally against introducing very specialized features to org-mode, for the same reasons as described by others in this thread. The power of org-mode lies in simplicify of the model it offers: information is a collection of lists that can be queried in various ways. This model is simple yet powerful. For example, org-mode can be used not only to store ordinary tasks (pay rent, every month), but also meta-tasks concerning the org-file itself (make sure there are no stuck projects, every week). I find this simple idea of storing meta-tasks very useful. It gives your org-file life, making it the single point of trust. As long as you remember to check your org-mode every day, you will never forget anything. Instead of following the books that tell you to develop a habit of ... just put this habit as an repetitive task in org-mode. Back to task dependencies. I use three tags: NEXT for enabled actions, TODO for actions that wait for the previous one on the list, and WAITING for actions that wait for something else. Whenever an action is completed, you can easily check whether the next TODO should be enabled (changed to NEXT) or not. WAITING actions (with dependencies across different lists) are more tricky, but in my experience, are quite rare. Here, if you know that completing task A will enable task Q in another part of the file, insert a meta-task TODO enable [[Q]] just after A. No special functionality needed, just standard linking. Of course there are some cases in which this scheme doesn't work, but these are not many, and I don't believe making them work automatically is worth the effort. This is because, in my case, most of the WAITING actions rely on external triggers (email, phone call), which are simply not automatable. Piotr ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] clarification about org-mode
Richard G Riley [EMAIL PROTECTED] writes: is there any concept of depends on at all at the moment in org? Not strictly, but properties are inherited: Doing (org-entry-get (point) CATEGORY t) on a headline will fetch the category of the parent if this category is not defined for the headline. ,[ org-entry-get ] | Get value of property for entry at point-or-marker pom. | If inherit is non-nil and the entry does not have the property, | then also check higher levels of the hierarchy. | If the property is present but empty, the return value is the empty string. | If the property is not present at all, nil is returned. ` don't see it if there is. e.g its quite possible to have a level one task complete but a level 2 one incomplete. Yes it possible. -- Bastien ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Re: depending TODOs, scheduling following TODOs automatically
Well, I think I'm going to try something else to get the task dependencies I'm after. I'm using a BLOCKED tag now. I'm thinking I'll go with a BLOCKED property followed by the list of blockers. I'll probably use links there, but I'll have to find a way to make that less fragile with the dynamic portions of the heading. I wasn't looking for any automatic state changes myself, so that would pretty much cover it. I'll probably be able to make a dynamic block that will generate a table with the tasks sorted parent first or sorted by which task is blocking the most other tasks, if I care enough. I can't say I have any plans to use triggers, but will they really hurt anything? I mean if it makes the code a mess then that wouldn't be good. But frankly, I have no need for the GTD 'find a stuck project' stuff, and it hasn't been a problem for me. Edd ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] Categories
You could set a :CATEGORY: property for entry. Edd On 10/11/07, Richard G Riley [EMAIL PROTECTED] wrote: Categories are fairly handy for keeping the agenda well organised, but what are the functionalities for moving tasks between different categories e.g a task might move from PROJ1 to PROJ2 or some such? Must it be done manually using cut and paste in the org file? ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Org-mode version 5.12
Org-mode 5.12 is up on http://orgmode.org Enjoy! - Carsten Changes in Version 5.12 --- * Overview - Remember templates can now have a name. - `C-c C-k' will abort taking a note (remember of log) - `C-c C-x C-w' and `C-c C-x M-w' now accept a prefix arg. - Lines in the agenda can be fontified according to priority. - New variable `org-scheduled-past-days'. - New variables `org-agenda-deadline-leaders' and `org-agenda-scheduled-leaders'. - New sparse tree function `org-sparse-tree'. - The variable `org-ellipsis' now defaults to `org-link'. - The #+OPTIONS line has a new option tags. - New variable `org-use-property-inheritance'. * Incompatible Changes - `C-c /' now calls `org-sparse-tree'. * Details - Remember templates can now have a template name as the first element. The name will be listed along with the selection character when prompting for a template. It is best to have the name start with the selection character, for example if you use (Note n), you will be prompted like [n]ote. Thanks to Matiyam for this proposal. - `C-c C-k' will abort taking a note. You can use this in remember buffers and when taking a logging note (e.g. for a state change). Thanks to Bastien. - `C-c C-x C-w' and `C-c C-x M-w' now accept a prefix arg to cut N sequential subtrees. This was a proposal by John. - Lines in the agenda are now bold if they have priority A and italic if they have priority C. You can turn this off using the variable `org-agenda-fontify-priorities'. Thanks to John Wiegley for the idea and code. - New variable `org-scheduled-past-days' to set the number a scheduled item will be listed after its date has passed. Default is 1, i.e. indefinitely. - New variables `org-agenda-deadline-leaders' and `org-agenda-scheduled-leaders' to adjust the leading text o scheduled items and deadline in the agenda. Thanks to John Wiegley for a patch. - New sparse tree function `org-sparse-tree'. This is now the default binding for `C-c /'. It requires one additional keypress to select a command, but in return is provides a single interface to all the different sparse tree commands, with full completion support. - The variable `org-ellipsis' now defaults to the face `org-link' because the visibility of the dots is really bad and I have found this change very useful indeed. - The #+OPTIONS line has a new option tags which can be used to set `org-export-with-tags'. Thanks to Wanrong Lin for this proposal. - New variable `org-use-property-inheritance'. Configure it to `t' if you want that searching for entries with certain properties always should assume inheritance. This is not well tested yet, please check it out. - Bug fixes ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] if both schedule and deadline, appear only once in agenda
Hello, I hope the subject line is clear, but I bet not. I have a TODO item with both a schedule and a deadline and this results in the item appearing twice after the deadline passes in my Org weekly Agenda. Is there a way that I can automatically change this behaviour? What I do now is manually delete the schedule stamp once the deadline is made. Or should I maybe simply not use both stamps for the same item? Thanks, by the way, for Org mode. Gijs ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
