[Orgmode] Column view bugs
Carsten, I took a closer look at column view today and really liked what I saw. It seems to have gotten a lot better since I tried it on 5.01, but it may just be that I understood the implementation this time around. I think it works very well and I am very surprised it hasn't gotten more use. I did find a few bugs however, and I think this may be what has deterred people from using it more. Bug #1 You cannot set the property with C-c C-x p in column view unless the properties drawer is already created. It will say text is read-only after prompting you for property and value. Since you can edit properties fine if there is a property drawer, it seems like we should be able to just create a property drawer if it doesn't already exist. Feature Request #1 Is it hard to allow setting TODO and tag setting with normal commands while on the heading in column view? Bug #2 M-f M-b jump around in a confusing way in column view. Maybe just make them like C-f and C-b? Feature Request #2 Is it hard to allow editing of headings with e in column view? Bug #3 C-c C-x p fails if there isn't a newline after the current heading. Put * Heading at bottom of file and try adding a property. I get Wrong type argument: number-or-marker-p, nil Feature Request #3 I think a currency sum type would be a nice addition. Bug #4 I don't think column summaries work without a column width. I get "Format specifier doesn't match argument type" with the following * Equipment :PROPERTIES: :COLUMNS: %32ITEM %Cost{+} :END: ** Item 1 :PROPERTIES: :Cost: 10 :END: Bug #5 If * Heading is the first thing in a file, pressing e in column view on that will give Args out of range errors. Bug #6 If you have a blank line in buffer and then this * Heading ** Subheading If there is no newline after Subheading and you try to use e on any of it's columns you will get an End of buffer message Bug #7 With the example above, if there is a newline after Subheading, you can edit priority and tags fine but editing TODO on Subheading or Heading butcher the "* Heading" line. Setting TODO on Heading will replace "* Heading" with " TODO ng" and give a message "before first heading." Setting TODO on Subheading will give similar results. Thought #1 I'm not sure having the column headings at the top of the buffer is the best place if you have multiple level 1 headings in one file and the level 1 heading you're editing in column view is not the first. In tall windows with long files you the column headings can turn up really far from the actual columns. I don't know, maybe it is easiest to put it at the top, but you might think about putting it above the level 1 heading of the list in column view or even right above the first list in column view. Feature Request #4 Is having the column view print practical? What about export? Bug #8 M-S-right is really nice, but it doesn't work if you haven't already defined your COLUMNS. Either it shouldn't prompt for info or it should create a COLUMNS for you (my preference). Bug #9 M-S-left asks if you want to remove column, such as PRIORITY, but it doesn't actually do it when you're not using your own COLUMNS Bug #10 M-right and M-left behave differently depending on whether COLUMNS is defined or not. Thanks! --Scott ___ 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] Org-mode version 5.12
On 10/11/07, Carsten Dominik <[EMAIL PROTECTED]> wrote: > Changes in Version 5.12 > --- >- The variable `org-ellipsis' now defaults to `org-link'. What are your thoughts on making this clickable, with RET and mouse? I don't know, the link face makes it looks like it should be. Just an idea. --Scott ___ 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] More options for org-log-done
Hi, Can/should we add more options to org-log-done, or maybe create a new variable org-log-state, to specify what state changes need to be logged. I have very fixed TODO state settings for all my org files and wish to avoid using in-buffer options for that. I just wonder how many people feel the same need as I do. Thanks for giving this a thought. Wanrong ___ 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
On Oct 12, 2007, at 19:20, Richard G Riley wrote: I have a possible bug here (5.12). When embedding the CATEGORY as a property e.g in my org file Yes, logging state changes is broken in 5.12, *#$&*&$. Fixed in 5.12c, thanks. , | '(org-agenda-custom-commands |(quote ( | ("d" org-todo "DELEGATED" nil) |("c" org-todo "DONE|DEFERRED|CANCELLED" nil) |("w" org-todo "WAITING" nil) | ("W" agenda "" ` What an innovative way of totally misusing org-agenda-custom-commands. `C-c a d' will indeed change a TODO state, something org-agenda-custom-commands was not designed for (and which I do not recommend...)! But "c" will not work, the symbol for creating a TODO list is `alltodo', not `org-todo'. - Carsten I hit "C-c x d" to move to "DELEGATED", I get prompted for a note, but the note is not stored as a sub item of the parent task anymore. In fact I don't know where it is stored. ___ 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
Carsten Dominik <[EMAIL PROTECTED]> writes: > On Oct 12, 2007, at 17:04, Richard G Riley wrote: >> >> Yes. The concept of not having to worry about where things are in the >> org file doesn't really work for me. I like things having a certain >> category in that category section - otherwise there seems little point >> in having lines like >> >> , >> | * Emacs >> | >> | :PROPERTIES: >> | :CATEGORY: Emacs >> | :END: >> ` > > Check out this message - it might contain what you are looking for. > > http://thread.gmane.org/gmane.emacs.orgmode/3179/focus=3586 > >> >> This might seem like an incredibly naive question, but with the concept >> of "general properties", where do TAGs fit in now? Is a tag a special >> kind of property? I am having difficulty seeing the best way to utilise >> the tools and would appreciate some wise words of guidance here. > > See my other message in a new thread. > > - Carsten I have a possible bug here (5.12). When embedding the CATEGORY as a property e.g in my org file ** TODO master tags/categories :VOCAB: SCHEDULED: <2007-10-14 Sun> DEADLINE: <2007-10-15 Mon> :PROPERTIES: :CATEGORY: Emacs :MISC: test :END: [2007-10-12 Fri] [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#886][Email from Bastien: Re: Orgmode Categories]] when I change the state e.g with this custom command sample , | '(org-agenda-custom-commands |(quote ( | ("d" org-todo "DELEGATED" nil) |("c" org-todo "DONE|DEFERRED|CANCELLED" nil) |("w" org-todo "WAITING" nil) | ("W" agenda "" ` I hit "C-c x d" to move to "DELEGATED", I get prompted for a note, but the note is not stored as a sub item of the parent task anymore. In fact I don't know where it is stored. ___ 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
Rainer Stengele <[EMAIL PROTECTED]> writes: > 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 would think that setting these up initially would require as much work and attention as simply managing them manually. > 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. What I do is mark tasks that can't be done yet as either NEEDSPREREQ or WAITING, or put them in my SomedayMaybe.org file if there's no possibility I'll get to them before my next weekly review. I only look at NEXTACTION tasks when I'm choosing a task to do, and when I complete a task, I look at its project to see if any NEEDSPREREQ tasks can now be done. If so, I change those to NEXTACTION. Yes, it would be possible to annotate these with a hook of some kind so that they are changed from NEEDSPREREQ to NEXTACTION automatically. But my feeling is that doing that would frontload the planning process too much, take just as much time/attention, and overall interfere with getting things done. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada| ___ 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
On Oct 12, 2007, at 17:04, Richard G Riley wrote: Yes. The concept of not having to worry about where things are in the org file doesn't really work for me. I like things having a certain category in that category section - otherwise there seems little point in having lines like , | * Emacs | | :PROPERTIES: | :CATEGORY: Emacs | :END: ` Check out this message - it might contain what you are looking for. http://thread.gmane.org/gmane.emacs.orgmode/3179/focus=3586 This might seem like an incredibly naive question, but with the concept of "general properties", where do TAGs fit in now? Is a tag a special kind of property? I am having difficulty seeing the best way to utilise the tools and would appreciate some wise words of guidance here. See my other message in a new thread. - 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] depending TODOs, scheduling following TODOs automatically
pete phillips <[EMAIL PROTECTED]> writes: > 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. I agree. If you're using a GTD-like methodology, all you really need is something that is good at maintaining lists of things (and generating cross-cutting lists of things like project vs. context). If you are using a day-planner methodology, all you really need is to be able to maintain dated lists with attached statuses. Org-mode is really good for both of these things. Once you get into "enterprise" (read as over-bureaucratized) project planning, then you really need software designed for the bureaucratic requirements of your organization, or for your organziation's bureaucracy to be built around something like MS-Project. I don't think it's a good idea for org-mode to try to support this type of work. Gnome Planner might be a workable tool for this kind of job. -- +---+ | Jason F. McBrayer[EMAIL PROTECTED] | | If someone conquers a thousand times a thousand others in | | battle, and someone else conquers himself, the latter one | | is the greatest of all conquerors. --- The Dhammapada| ___ 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] About TODO state, tags and properties in Org-mode
About TODO state, tags and properties in Org-mode In a recent message to emacs-orgmode, Richard G Riley asked for more background about the concept of properties and their relation to tags. Let me try to take a step back and explain these concepts together. Every node in an Org-mode outline tree is an /entry/. Due to the outline structure of the document, the entry may have a parent, and it may have children. In order to function as a task manager, Org-mode assigns certain qualities to entries. The most general way to assign qualities are /properties/. Properties are a list of keyword-value pairs. In Org-mode, properties are stored in a special block, called the /property drawer/. In principle, the concept of properties would be enough to handle everything that a user might want to assign to an item. We could have a "TodoState" property that captures the TODO state, a "Priority" property that captures the priority, "Deadline", "Scheduled", "Appointment" properties for dates and times, etc. However, properties are a "heavy" concept. Keeping them in a plain text file requires a block of text under each and every entry, making even simple lists complex and heavy, and hiding important state information. However, Org-mode was develloped with the philosophy /Make simple things simple and hard things possible/. Therefore[1], Org-mode has other concepts the assign qualities to entries by adding small strings to the entry line itself. These concepts are: - The /TODO state/, a single word at the beginning of an entry line. This can be viewed as a privileged property that can have exactly one of a limited number of values. These values are mutually exclusive and the TODO state of an entry is uniquely determined. Also, the TODO state cannot be inherited, i.e. it is independent of the states of the parent. - The /priority/, indicated by a small cookie in the headline. Again, this could also be a property, but it is nice to have a way to use it in very simple lists. Just like the TODO state, the priority is not inherited. - /Tags/. These can be viewed as /boolean/ properties. They are either true of false, set or not-set. Since TAGS are listed in the valuable real estate in the headline itself, they are always visible in in this way privileged. Tags are inherited, i.e. if a parent has a certain tag, this tag also applies to its children (at least you can use them like this, but you can also localize tags fully to an entry by setting a variable). So when should you use what? - As a beginner, use just the TODO state and priorities. - To categorize or to assign GTD contexts, use tags. - Turn to properties if you need to assign a quality that has many values. For example, when you find yourself creating tags like release_1_1, release_1_2, release_1_3, it is time to introduce your first property. - Property are also used internally to store customization parameters that should apply to only a part of the outline tree, usually a subtree. For example, the CATEGORY property defines the category of a (sub)tree. I hope this makes things a bit clearer. - Carsten [1] OK, here I am lying. This is not something that happened by design, but historically. First simple concepts like the TODO states were implemented, tags and properties later. However, this is exactly why Org-mode still feels light-weight. You absolutely do not have to use the advanced concepts of tags and properties if you only want a plain list or a TODO state. Sometimes that fact that a piece of software has not been designed top-down can work out in its advantage. ___ 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] remember/org error
Hi all, I keep getting the following error after performing a M-x remember, entering some text in the new buffer and pressing C-c C-c. The following error occurs on the final C-c C-c. (error "Invalid search bound (wrong side of point)") As far as I know I have the configuration setup as specified in the org manual. I've attached a backtrace. I'm using what I downloaded as org 5.12b though org-version claims it is 5.12a. Thanks again to everyone on the list; especially Carsten. R. Debugger entered--Lisp error: (error "Invalid search bound (wrong side of point)") re-search-forward("^[ ]+" # t) (while (re-search-forward "^[ ]+" end t) (goto-char (match-end 0)) (setq col (current-column)) (if (< diff 0) (replace-match "")) (indent-to (+ diff col))) (if (save-excursion (end-of-line 1) (re-search-forward prohibit end t)) nil (while (re-search-forward "^[ ]+" end t) (goto-char ...) (setq col ...) (if ... ...) (indent-to ...))) (unless (save-excursion (end-of-line 1) (re-search-forward prohibit end t)) (while (re-search-forward "^[ ]+" end t) (goto-char ...) (setq col ...) (if ... ...) (indent-to ...))) (let ((end ...) (prohibit ...) col) (unless (save-excursion ... ...) (while ... ... ... ... ...)) (move-marker end nil)) (save-excursion (let (... ... col) (unless ... ...) (move-marker end nil))) org-fixup-indentation(1) (if org-adapt-indentation (org-fixup-indentation diff)) (let* ((level ...) (down-head ...) (diff ...)) (replace-match down-head nil t) (and org-auto-align-tags (org-set-tags nil t)) (if org-adapt-indentation (org-fixup-indentation diff))) org-demote() funcall(org-demote) (if (and (re-search-forward ... nil t) (< ... end)) (funcall fun)) (save-excursion (setq end (copy-marker end)) (goto-char beg) (if (and ... ...) (funcall fun)) (while (and ... ...) (funcall fun))) (let ((org-ignore-region t)) (save-excursion (setq end ...) (goto-char beg) (if ... ...) (while ... ...))) org-map-region(org-demote 4278 4319) (while (not (= shift 0)) (org-map-region func (point-min) (point-max)) (setq shift (+ delta shift))) (save-restriction (narrow-to-region beg end) (while (not ...) (org-map-region func ... ...) (setq shift ...)) (goto-char (point-min))) (if (= shift 0) nil (save-restriction (narrow-to-region beg end) (while ... ... ...) (goto-char ...))) (unless (= shift 0) (save-restriction (narrow-to-region beg end) (while ... ... ...) (goto-char ...))) (let* ((txt ...) (^re ...) (re ...) (^re_ ...) (old-level ...) (force-level ...) (previous-level ...) (next-level ...) (new-level ...) (shift ...) (shift1 shift) (delta ...) (func ...) (org-odd-levels-only nil) beg end) (if force-level (delete-region ... ...)) (beginning-of-line 1) (setq beg (point)) (insert txt) (unless (string-match "\n[ ]*\\'" txt) (insert "\n")) (setq end (point)) (goto-char beg) (unless (= shift 0) (save-restriction ... ... ...)) (when (interactive-p) (message "Clipboard pasted as level %d subtree" new-level)) (if (and kill-ring ... org-subtree-clip-folded) (hide-subtree))) org-paste-subtree(2 "* Fri Oct 12 17:20:30 2007 (foo)\n foo\n ") (save-restriction (widen) (goto-char (point-max)) (if (not ...) (newline)) (org-paste-subtree (org-get-legal-level 1 1) txt)) (cond ((org-on-heading-p t) (org-back-to-heading t) (setq level ...) (cond ... ... ... ...)) ((and ... ...) (save-restriction ... ... ... ...)) ((and ... reversed) (save-restriction ... ... ... ... ...)) (t (org-paste-subtree ... txt))) (save-restriction (widen) (and (goto-char ...) (not ...) (insert "\n* " ... "\n")) (setq reversed (org-notes-order-reversed-p)) (when (and heading ... ...) (goto-char ...) (if ... ... ...)) (if fastp (setq spos org-goto-start-pos exitcmd ...) (setq spos ... exitcmd ... spos ...)) (if (not spos) (throw ... nil)) (goto-char spos) (cond (... ... ... ...) (... ...) (... ...) (t ...)) (when remember-save-after-remembering (save-buffer) (if ... ...))) (save-excursion (save-restriction (widen) (and ... ... ...) (setq reversed ...) (when ... ... ...) (if fastp ... ...) (if ... ...) (goto-char spos) (cond ... ... ... ...) (when remember-save-after-remembering ... ...))) (save-current-buffer (set-buffer (or visiting ...)) (unless (org-mode-p) (error "Target files for remember notes must be in Org-mode")) (save-excursion (save-restriction ... ... ... ... ... ... ... ... ...))) (with-current-buffer (or visiting (get-file-buffer file)) (unless (org-mode-p) (error "Target files for remember notes must be in Org-mode")) (save-excursion (save-restriction ... ... ... ... ... ... ... ... ...))) (let* ((txt ...) (fastp ...) (file ...) (heading org-remember-default-headline) (visiting ...) (org-startup-folded nil) (org-startup-align-all-tables nil) (org-goto-start-pos 1) spos exitcmd level indent reversed) (if (and ... org-remember-previous-location) (setq file ... heading ...)) (setq current-prefix-arg nil) (let* (... first)
Re: [Orgmode] Categories
Richard G Riley <[EMAIL PROTECTED]> writes: > Completion doesnt work for me. Possibly this is a result of using > icicles? You just TAB to completion? Can you please provide more details: What version of Org-mode? What did you do? What did you expect? What did you get instead? > This might seem like an incredibly naive question, but with the > concept of "general properties", where do TAGs fit in now? TAGs are special properties. They are special regarding the way you access them (C-c C-c), the way you display them (flushright) and the way Org can process them (with specific search/sort queries.) But in other respect, they are just "properties" of an entry. Hope this might help you find the best use for tags. > I am having difficulty seeing the best way to utilise the tools and > would appreciate some wise words of guidance here. For me a todo line gets associated with : | a project | CATEGORY | | a process state | TODO keyword | | an action-type | tags | | a context of action | tags | My setting for tags is this: #+TAGS: { Read(r) Write(w) Code(c) } #+TAGS: Mail(m) Print(p) #+TAGS: { @HOME(H) @LAB(L) } #+TAGS: { @Online(O) @Offline(F) } The first two lines are action-types. The two last lines are contexts. The conventions I use are these: 1) the keys for action-types are lower-case, the keys for contexts are upper-case. 2) contexts comes with a leading "@" 3) the tags for *physical* contexts are all capitalized, while those for notional contexts are just first-letter capitalized. The tags that I'm more likely to use are Read, Write or Code. A subset of my agenda views: (setq org-agenda-custom-commands '(("r" tags-todo "Read/NEXT" nil) ("w" tags-todo "Write/NEXT" nil) ("R" tags-todo "Read/NEXT|TODO" nil) ("W" tags-todo "Write/NEXT|INPROGRESS" nil))) Then I regularily check for something to read with "r" (meaning something to read next) or "R" (including other TODO); or I check for things that I have to write with "w" (the things I have to write next) or "W" (including work in progress, which is likely to take more than on day.) For the "Mail" an "Print" tags, i use the normal C-c a m key, since I don't use them that often. At the beginning I worried too much about having a consistent set of tags. For the example above, there is some overlap between Mail Write and Code. But you don't need to worry about that. Just use the tags, and progressively you will be able to get rid of useless one. HTH, -- 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] Categories
Carsten Dominik <[EMAIL PROTECTED]> writes: > You can add a category property to the entry, and that will overrule the > category that might be inherited from above. With the latest org-mode > 5.12, > press `C-c C-x p'. This will prompt you for a property name, enter > CATEGORY > (using completion). The it will ask you for the category itself and > you Completion doesnt work for me. Possibly this is a result of using icicles? You just TAB to completion? > can enter it, again using completion against existing categories > (given as > properties *anywhere* in the file. So this will not see the > #+CATEGORY lines, > only the > > :PROPERTIES: > :CATEGORY: work > :END: > > definitions. > > You can also insert a line > > #+PROPERTY: CATEGORY_ALL work home phone whendrunk > > to define a complete list of categories. > > Note that setting the property wil change the category of the item, > but it will *not* move it to a different place in the file. If I > understand correctly, this is what you want. Yes. The concept of not having to worry about where things are in the org file doesn't really work for me. I like things having a certain category in that category section - otherwise there seems little point in having lines like , | * Emacs | | :PROPERTIES: | :CATEGORY: Emacs | :END: ` This might seem like an incredibly naive question, but with the concept of "general properties", where do TAGs fit in now? Is a tag a special kind of property? I am having difficulty seeing the best way to utilise the tools and would appreciate some wise words of guidance here. > > - 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] Categories
On Oct 12, 2007, at 16:12, Richard G Riley wrote: Bastien <[EMAIL PROTECTED]> writes: Richard G Riley <[EMAIL PROTECTED]> writes: The CATEGORY property does the same job than the old #+CATEGORY, except that its scope is well defined, i.e. we don't need to bother anymore on where #+CATEGORY has to be. Did you before? IIRC this was a recurrent issue on this list. , | (setq org-remember-templates | '((?c "* %?\n :PROPERTIES:\n :CATEGORY: %^{Category}\n :END:\n\n %i\n" "~/org/todo.org" "Tasks"))) ` Almost. There is no completion or "pick" for the available categories. I would expect something like a "tab for completion" field similar to set tag for a task. Yes. We can imagine something like %^c (prompt for a category with proper completion). But then why not %^s for the SUMMARY property? And %^d for the DESCRIPTION property? My answer try to avoid going into this, since I (still) think handling properties from within a remember template is a bit too much. But I might be wrong. Inserting properties (including the CATEGORY property) interactively from a template looks a bit too much for me. But not using remember very often, and only for taking quick notes -- not editing my main Org file. I'm not sure I understand. One of the most important task properties is the category I would have though. You can use property inheritance. Ask your remember template to put the entry in the right subtree, and use a category for that entry only. I do. e.g , | '(org-remember-templates | |(?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs") ` I think we are talking at cross purposes. A category is the A number one most important property for task organization I would have thought. I can already place them in the right org file section using the template and others like it above. But there appears to be no way to manipulate them then e.g move to other category other can cut and paste. Possibly my total ignorance of "properties" is the issue here as I can find no examples of their use or how an end user should utilise them. I am assuming from your words here that "category" is merely a property. , | > You can use property inheritance. Ask your remember template to put the | > entry in the right subtree, and use a category for that entry only. ` What do you mean the right subtree? I already, through the template, put it into the right sub section delimited by the category property. What do you mean by "use a category for that entry only"? Do you mean only the sub tree has a category property? In this case that is what I have - sections of tasks with a category section separating them. e.g , | * FaceBook | | :PROPERTIES: | :CATEGORY: FaceBook | :END: | | | * Emacs | | :PROPERTIES: | :CATEGORY: Emacs | :END: | | ** [2007-10-12 Fri 15:03] How to use categories in org-mode | | [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#874][Email from Bastien: Re: Orgmode Categories]] ` My original question is how to assign the task above to another category nice and easily and not using cut and paste? Is it possible? ideally I would, as with tags, have the ability to choose from all existing categories in use in the current file. You can add a category property to the entry, and that will overrule the category that might be inherited from above. With the latest org-mode 5.12, press `C-c C-x p'. This will prompt you for a property name, enter CATEGORY (using completion). The it will ask you for the category itself and you can enter it, again using completion against existing categories (given as properties *anywhere* in the file. So this will not see the #+CATEGORY lines, only the :PROPERTIES: :CATEGORY: work :END: definitions. You can also insert a line #+PROPERTY: CATEGORY_ALL work home phone whendrunk to define a complete list of categories. Note that setting the property wil change the category of the item, but it will *not* move it to a different place in the file. If I understand correctly, this is what you want. - 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] Categories
Bastien <[EMAIL PROTECTED]> writes: > Richard G Riley <[EMAIL PROTECTED]> writes: > >>> The CATEGORY property does the same job than the old #+CATEGORY, except >>> that its scope is well defined, i.e. we don't need to bother anymore on >>> where #+CATEGORY has to be. >> >> Did you before? > > IIRC this was a recurrent issue on this list. > >>> , >>> | (setq org-remember-templates >>> | '((?c "* %?\n :PROPERTIES:\n :CATEGORY: %^{Category}\n >>> :END:\n\n %i\n" "~/org/todo.org" "Tasks"))) >>> ` >> >> Almost. There is no completion or "pick" for the available categories. I >> would expect something like a "tab for completion" field similar to set >> tag for a task. > > Yes. We can imagine something like %^c (prompt for a category with > proper completion). But then why not %^s for the SUMMARY property? > And %^d for the DESCRIPTION property? My answer try to avoid going > into this, since I (still) think handling properties from within a > remember template is a bit too much. But I might be wrong. > >>> Inserting properties (including the CATEGORY property) interactively >>> from a template looks a bit too much for me. But not using remember >>> very often, and only for taking quick notes -- not editing my main >>> Org file. >> >> I'm not sure I understand. One of the most important task properties is >> the category I would have though. > > You can use property inheritance. Ask your remember template to put the > entry in the right subtree, and use a category for that entry only. I do. e.g , | '(org-remember-templates | |(?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs") ` I think we are talking at cross purposes. A category is the A number one most important property for task organization I would have thought. I can already place them in the right org file section using the template and others like it above. But there appears to be no way to manipulate them then e.g move to other category other can cut and paste. Possibly my total ignorance of "properties" is the issue here as I can find no examples of their use or how an end user should utilise them. I am assuming from your words here that "category" is merely a property. , | > You can use property inheritance. Ask your remember template to put the | > entry in the right subtree, and use a category for that entry only. ` What do you mean the right subtree? I already, through the template, put it into the right sub section delimited by the category property. What do you mean by "use a category for that entry only"? Do you mean only the sub tree has a category property? In this case that is what I have - sections of tasks with a category section separating them. e.g , | * FaceBook | | :PROPERTIES: | :CATEGORY: FaceBook | :END: | | | * Emacs | | :PROPERTIES: | :CATEGORY: Emacs | :END: | | ** [2007-10-12 Fri 15:03] How to use categories in org-mode | | [[gnus:nnmaildir%2BMyMail:DevelopmentEmail#874][Email from Bastien: Re: Orgmode Categories]] ` My original question is how to assign the task above to another category nice and easily and not using cut and paste? Is it possible? ideally I would, as with tags, have the ability to choose from all existing categories in use in the current 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
Re: [Orgmode] Categories
Richard G Riley <[EMAIL PROTECTED]> writes: >> The CATEGORY property does the same job than the old #+CATEGORY, except >> that its scope is well defined, i.e. we don't need to bother anymore on >> where #+CATEGORY has to be. > > Did you before? IIRC this was a recurrent issue on this list. >> , >> | (setq org-remember-templates >> | '((?c "* %?\n :PROPERTIES:\n :CATEGORY: %^{Category}\n >> :END:\n\n %i\n" "~/org/todo.org" "Tasks"))) >> ` > > Almost. There is no completion or "pick" for the available categories. I > would expect something like a "tab for completion" field similar to set > tag for a task. Yes. We can imagine something like %^c (prompt for a category with proper completion). But then why not %^s for the SUMMARY property? And %^d for the DESCRIPTION property? My answer try to avoid going into this, since I (still) think handling properties from within a remember template is a bit too much. But I might be wrong. >> Inserting properties (including the CATEGORY property) interactively >> from a template looks a bit too much for me. But not using remember >> very often, and only for taking quick notes -- not editing my main >> Org file. > > I'm not sure I understand. One of the most important task properties is > the category I would have though. You can use property inheritance. Ask your remember template to put the entry in the right subtree, and use a category for that entry only. Isn't this more simple? -- 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] typo? in org-install, org-5.12b
Stuart McLean <[EMAIL PROTECTED]> writes: > I think this might be a typo in the file `org-install.el', line 56: > > (autoload 'org-show-toc "org-toc" "Create and display a table of contents" > t) > > Shouldn't this be `org-toc-show'? Yes, it should. Thanks! -- 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
[Orgmode] typo? in org-install, org-5.12b
Hi, firstly, thanks for Org-mode, I live in this mode, so to speak ;-) I think this might be a typo in the file `org-install.el', line 56: (autoload 'org-show-toc "org-toc" "Create and display a table of contents" t) Shouldn't this be `org-toc-show'? Regards, Stuart ___ 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
"Eddward DeVilla" <[EMAIL PROTECTED]> writes: > 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. I feel quite the same. People love Org because of its "simplicity". But we should call it "efficiency" rather than "simplicity", since what we really like in it is the fact that it makes complex actions easily achievable. For example, both org-remember-templates and org-agenda-custom-commands can be very complex variables, yet Org lets you configure them the way you want so that using them becomes very "simple". I think it would be the same for the trigger stuff: finding your way through the best configuration for *you* would be a rather complex process, but using them to perform the simple actions that you need would not be that complex. BTW, I don't see the point behing the argument: "I'm using Org for simple project management and XXX for complex project management, so please keep Org as simple as it is." If both tools let you manage complex projects, there will compete in the same area and that will be a problem for *you*. But not for the software itself, and not for people that use only Org (and might be tempted to use it for more complex PM.) My 2 cents, -- 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] if both schedule and deadline, appear only once in agenda
Gijs Hillenius <[EMAIL PROTECTED]> writes: > But maybe I should not :-). But here goes: I plan to start working on > an item by date X -> schedule stamp. The item has a deadline, so -> > deadline. For that I use `org-deadline-warning-days'. I start the deadline when it shows up in my agenda. The default value for this is 14, but you can set a value for each deadline like this: DEADLINE: <2004-02-29 Sun -10d> Meaning that you should start the deadline 10 days before the deadline. ,[ (info "(org)Deadlines and scheduling") ] | You can specify a different lead time for warnings for a specific | deadlines using the following syntax. Here is an example with a | warning period of 5 days `DEADLINE: <2004-02-29 Sun -5d>'. ` HTH, -- 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] Categories
Richard G Riley <[EMAIL PROTECTED]> writes: >> You could set a :CATEGORY: property for entry. >> > How do you do that? Please check (info "(Org)Property syntax") to know more about properties. > | #+CATEGORY: Emacs Although this is still supported, you can now use this: , | * A headline here | :PROPERTIES: | :CATEGORY: Emacs | :END: ` The CATEGORY property does the same job than the old #+CATEGORY, except that its scope is well defined, i.e. we don't need to bother anymore on where #+CATEGORY has to be. > My question is how to assign a task to a category, preferably through > a pick/select from a list of predefined category names. Maybe something like this: , | (setq org-remember-templates | '((?c "* %?\n :PROPERTIES:\n :CATEGORY: %^{Category}\n :END:\n\n %i\n" "~/org/todo.org" "Tasks"))) ` (Note that white spaces are important.) Inserting properties (including the CATEGORY property) interactively from a template looks a bit too much for me. But not using remember very often, and only for taking quick notes -- not editing my main Org file. > ps Is there an IRC channel for org? The mailing list is busy enough I > wonder if an IRC channel wouldnt be a good idea to help people through > teething pains. Do you think "being-productive-with-Org" and "lurking-on-Org-channel" can get along nicely? Ahem. The good thing with the mailing is that it helps to provide a huge "dynamic FAQ" to googlers. IRC logs too often die in the darkness. -- 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] if both schedule and deadline, appear only once in agenda
On 12 Oct 2007, Bastien wrote: >> Or should I maybe simply not use both stamps for the same item? > > I don't see why you need both of them. Can you answer that? Yes. But maybe I should not :-). But here goes: I plan to start working on an item by date X -> schedule stamp. The item has a deadline, so -> deadline. Would an example help: I'd like to be forewarned by Org that I have a new item coming onto my todo list, as of next Monday. And I want to see that, I need to get it done on Wednesday. But call me crazy.. -- /* This bit of chicanery makes a unary function followed by a parenthesis into a function with one argument, highest precedence. */ -- Larry Wall in toke.c from the perl source code ___ 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] if both schedule and deadline, appear only once in agenda
Gijs Hillenius <[EMAIL PROTECTED]> writes: > 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. Meaning you have to blame yourself twice :) > Or should I maybe simply not use both stamps for the same item? I don't see why you need both of them. Can you answer that? -- 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 Dominik <[EMAIL PROTECTED]> writes: > 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. I agree that if we keep making org-mode smarter and smarter, it will start to become a bear that is overly complicated -- and in the world of task management, complexity is death. I use a dedicated Project Management application when I need scheduling and management of complex time and resource dependencies (Merlin, from http://merlin2.net). I setup a proposal for a client, and then I use Merlin to record the time spent, by capturing moments with timeclock.el and entering the resulting blocks via the Merlin interface. It takes time, but the value to me and my customer of knowing where we stand and when things should complete is definitely worth the effort (and software cost!). But with org-mode, I'm not reporting to other people. I want something light and agile. This is the first task management scheme *in my life* that I've used daily for more than 3 months. That is saying something, let me tell you. I've even written my own systems still in use by other people (see Emacs Planner)!! In fact, I would probably say that before the year is out, org-mode's interface and basic data structures should reach Feature Complete status. I think we still need more hooks, for user customization, and several more "library API functions" to make writing those customizations easier; but in terms of the core package, I can't see how to improve on perfection from here. John ___ 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
Bastien <[EMAIL PROTECTED]> writes: >> * Hardware >> ** TODO Install >> * Software >> ** TODO Install :ADDRESSTHISONE: >> * Patches >> ** TODO Install >> >> Thats why I thought a GUID property would be required. > > I a sense, that shows that having a proper GUID system will only be > useful in case there are many tasks with the same name, which should > already be discouraged since headlines may show up in the agenda buffer > with no context at all. GUIDs could always be defined using a property, to allow users to find a task uniquely. It doesn't have to be a canonical part of org-mode at all. John ___ 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
Hi, "Eddward DeVilla" <[EMAIL PROTECTED]> writes: > You could set a :CATEGORY: property for entry. > > Edd > This is different from a tag how? How do you do that? At the moment my org file has sections like this: , | * Emacs | | #+CATEGORY: Emacs | | | * Register | | #+CATEGORY: Register ` And I then have a host of "insert task" options thus: , | '(org-remember-templates |(quote ( | (?t "* TODO %?\n %u\n %i\n %a\n" "~/org/todo.org" "Tasks") |(?n "* %U %?" "~/org/notes.org" "Notes") |(?f "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "FaceBook") |(?l "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Linux") |(?e "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Emacs") |(?R "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Register") |(?r "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Remember") | (?j "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Journal") | (?L "* %U %^{Title}\n %i\n %a\n" "~/org/todo.org" "Links") | ) | ) ` My question is how to assign a task to a category, preferably through a pick/select from a list of predefined category names. Category functionality appears to be limited to place holders in the org file which then anchor sections in the agenda but I'm not 100% sure. ps Is there an IRC channel for org? The mailing list is busy enough I wonder if an IRC channel wouldnt be a good idea to help people through teething pains. regards r. > 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