Manish writes:
> I noticed a small inconsistency. If you start with following sample
> org file and press C-c C-c in the first cookie, it doesn't get updated
> correctly whereas the second one does. The only difference is that
> one has children TODO tasks and the other has a list of checkboxes.
>
> Starting file:
>
> --8<---------------cut here---------------start------------->8---
> * Item 1 [/]
> 1. [X] line 1
> 2. [ ] line 2
> * Item 2 [/]
> *** TODO Sub-item 2.1
> *** DONE Sub-item 2.2
> --8<---------------cut here---------------end--------------->8---
>
> Status after C-c C-c in the summary cookie.
>
> --8<---------------cut here---------------start------------->8---
> * Item 1 [0/0]
> 1. [X] line 1
> 2. [ ] line 2
> * Item 2 [1/2]
> *** TODO Sub-item 2.1
> *** DONE Sub-item 2.2
> --8<---------------cut here---------------end--------------->8---
Charles Sebold writes:
> This is with a clean Emacs, nothing in .emacs except for what is
> necessary to add my org-mode lisp directory to the load path and
> (require 'org-install), Emacs pulled down from bzr this morning, and
> current git download of org-mode, pulled a few minutes ago.
>
> With an org file like this:
>
> ------------------------------------------------------------------------
> * TODO Try out [[elisp:(org-version)][link problem]] if possible
> ------------------------------------------------------------------------
>
> Pull this into an agenda view, then put cursor over the link and try to
> follow it. The result is as follows:
Oscar Fuentes writes:
> When a [/] is used on a header that does not contain subitems, pressing
> C-c C-c on it signals an error on the minibuffer:
>
> org-update-statistics-cookies: No data for statistics cookie
>
> and the cookie appears with the same face (text color) as if it were
> incomplete.
>
> IMHO, [/] on a header without subitems should show [0/0] with the same
> face used for the case where all subitems are done.
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.orghttp://lists.gnu.org/mailman/listinfo/emacs-orgmode
file+sys:/path/to/file will use the system to open the file, like
double-clicking would
file+emacs:/path/to/file will force opening by Emacs
Also, when using C-c C-o on a headline of get a list of links in the
entry, pressing RET will open *all* links. This allows something like
projects to be defined, with a number of files that have to be opened
by different applications.
These were requests by John Wiegley.
PT writes:
> [Orgmode] org-read-date-prefer-future 'time doesn't always prefer future
>
> This is a very useful setting, because it allows the user to
> quickly schedule a task into the future by simply entering the
> time, but it doesn't always do the right thing.
>
> Suppose I scheduled a task to 1pm, but I didn't have time to deal
> with it during the day. It's 5pm now. If I want to reschedule the task to
> tomorrow 10am then I can write simply 10am to the time prompt and
> it puts the task correctly to tomorrow 10am. However, if I want
> to reschedule it to tomorrow 2pm then I can't write simply 2pm,
> because then it schedules the task at 2pm today (which is past
> already, since it's 5 pm).
>
> The problem is the feature uses the task's own scheduled time to
> determine if a time is in the past, instead of the current time.
>
>
> It's Org-mode version 6.33
Matt Lundin writes
> I believe that commit b8e0d6fdb4 broke
> accessing timestamps with the org-entry-get.
>
> With that commit, several functions I use to check whether an entry has
> a timestamp stopped working.
>
> In other words,
>
> (org-entry-get nil "TIMESTAMP_IA")
>
> or
>
> (org-entry-get nil "TIMESTAMP")
>
> always return nil, even if a timestamp exists.
>
> Strangely, the org-entry-properties alist includes values for TIMESTAMP
> and TIMESTAMP_IA.
>
> I tested this by evaluating the expressions in the sample entry below:
>
> --8<---------------cut here---------------start------------->8---
> * TODO Test 💻
> <2009-12-19 Sat>
> [2009-12-19 Sat 17:47]
>
> (org-entry-get nil "TIMESTAMP_IA")
> (org-entry-get nil "TIMESTAMP")
> (org-entry-properties)
> --8<---------------cut here---------------end--------------->8---
Samuel Wales writes:
> I found three places where the lowercase version of a todo
> kw is treated specially in the latest org. For example,
>
> * todo this is lowercase
>
> First, in the agenda, they have a special face.
>
> Second, when inserting an id link, they are removed.
>
> Third, when printing the olpath, they are removed. To
> reproduce, place point at bol on 5 and press the spacebar.
> I expect todo to be in the olpath, but it is not.
>
> Thanks.
>
>
> Samuel
>
>
> * 1
> *** 2
> ***** here are some keywords i like
> ******* todo
> ********* 5
David Maus writes:
> Just realized that there a lot of broken links in the published
> version of Worg. Seems like something went totally wrong with the
> export to html. For instance:
>
> http://orgmode.org/worg/
>
> "The main resources"
>
> The link to the official page reads http:/g and leads to
> http://orgmode.org/worg/g
>
> -or-
>
> http://orgmode.org/worg/org-contrib/org-protocol.php
>
> "Firefox"
>
> As of March 2009 Firefox users follow the steps documented on
> http:l. Here is a summary: ...
>
> the link reads "http:l" and leads to
> http://orgmode.org/worg/org-contrib/l
>
> And so on.
>
Paul Griepentrog writes:
> Every once in a while I use org-mode in a buffer that is not
> associated with a file... and then org-goto gets confused. To repeat:
>
> BUFFER-NO-FILE
> ---------------
> * One
> - a
> * Two
> - b
> ---------------
>
> M-x org-mode
> C-c C-j
> org-get-refile-targets: Wrong type argument: stringp, nil
>
> [...]
>
> This patch fixes it:
Bernt Hansen writes:
> ,----[ test.org ]
> |
> | * Main task
> | ** DONE Task 1
> | ** DONE Task 2
> | ** TODO Task 4
> | ** TODO Task 3
> | ** TODO Task 5
> | * Next task
> `----
>
> Put the point on * Main Task
> C-x n s to narrow to subtree
> C-c C-v to show active TODOs
> Put point on TODO Task 4
> M-down arrow
> M-up arrow
>
> generates
>
> Debugger entered--Lisp error: (error "before first heading")
Add a variable org-complete-tags-always-offer-all-agenda-tags, which makes org
complete all tags from all agenda files if non-nil. Usually, setting it
locally to t in org-remember buffers is most convenient.
Scot Beker writes:
> I cite my references in org like
> this.\autocite[231]{bibtexkey_2009}, where '231' is the
> relevant page number. When exporting to LaTeX, Org thinks
> that the value in square brackets is a footnote number and
> produces a document with a "footnote definition not found:
> 231" error message at the bottom of the document. My
> settings are below, and I've searched pretty hard through
> them to look for anything that might have caused it. Any
> ideas?
Ian Barton writes:
> I am not sure if this is intended behaviour or not.
> If I start a new document with no headings and type:
>
> - item 1
>
> then press M_Ret, I get:
>
> - item 1
> *
>
> If my document is like:
>
> * Heading
> - item 1
>
> M-Ret works as expected.
Bernt Hansen writes:
> The org-agenda multi-occur search command (C-c a /) does not return
> results on buffers that are currently narrowed if the search would
> normally match outside the narrowed region. This prevents possible
> matches from being displayed.
David Maus writes:
> By accident I noticed that if you clone a subtree using C-c C-x c who
> or whose content is the last line of the file orgmode inserts the
> clone without the desired newline.
>
> example.org
> ,----
> | * Just a test
> `----
>
> If you move the point behind test and press C-c C-x c 1 <RET> <RET>
> the clone is inserted right behind "test".
>
> example.org
> ,----
> | * Just a test*Just a test
> `----
>
> Instead orgmode should insert a newline before inserting the clone
> when the file misses an empty line at the end.
Samuel Wales writes:
> I find that changing a task from a todoish state to blank
> causes blocking to occur. I normally want all todo state
> changes except those to doneish states to be non-blocked.
>
> I think the issue might be that blank is special-cased, as
> if it were a doneish state. I would prefer blank to be a
> todoish state just like any other.
Sebastian Rose writes
> 1. Open an *.org file you can export to PDF. Ensure the file is not
> located where your Org-mode sources are (org-*.el files). Choose a
> file, that includes some images or a SETUPFILE using relative
> paths.
> 2. M-x default-directory RET
> to see the value of that variable in the current buffer.
> 3. C-c C-e p
> to export to PDF and verify it works.
> 4. C-c C-x !
> to `org-reload'
> 5. Now repeat steps 2 and 3. Note, that the export fails.
Sebastian also submitted the basic patch to fix this
Rick Moynihan writes:
> I'm wondering if anyone logs rescheduled tasks with org-mode... As I
> find myself sometimes scheduling tasks for a future date, but then on
> the day not having the capacity to do them. In these situations I
> just reschedule them, but it'd be nice to record the dates for which
> an item was originally scheduled in the LOGBOOK.
>
> Has anyone configured org-mode to do this? lognotedone only appears to
> log state changes (rather than schedule/deadline changes).
This lets you see how long has passed since the specified timestamp property
each entry. The three operators (@min, @max, @mean) show either the age of the
youngest or oldest entry or the average age of the children.
Alessandro Paccacio writes:
> I've an outline like this:
>
> * Project A
> ** TODO Task A-1 [0/3]
> *** TODO Subtask A-1-a
> *** TODO Subtask A-1-b
> *** TODO Subtask A-1-c
>
> where level 1 heading is the name of a project, level 2 heading is a
> generic task broken into three level 3 headings. As suggested in
> section 5.5 of the manual, I've hooked the org-summary-todo function
> to org-after-todo-statistics-hook, in order to automatically change
> the level 2 TODO to DONE when all the subtasks are DONE.
> Unfortunately, when I change to DONE the first subtask, an unexpected
> TODO is added to level 1 heading:
>
> * TODO Project A
> ** TODO Task A-1 [1/3]
> *** DONE Subtask A-1-a
> *** TODO Subtask A-1-b
> *** TODO Subtask A-1-c
>
> From now on, the switch TODO->DONE or DONE/TODO applies to level 1
> heading, even if the [/] cookie in level 2 is correctly updated:
>
> * DONE Project A
> ** TODO Task A-1 [3/3]
> *** DONE Subtask A-1-a
> *** DONE Subtask A-1-b
> *** DONE Subtask A-1-c
>
> Is there a way to apply the automatic change of TODO to the parent
> heading only, as below?
>
> * Project A
> ** DONE Task A-1 [3/3]
> *** DONE Subtask A-1-a
> *** DONE Subtask A-1-b
> *** DONE Subtask A-1-c
This bug resulted from a recent patch which made a prefix arg of 2 to
mean refile to the clock. However, I forgot to actually test the
value of the prefix arg...
Carsten Dominik
Tassilo Horn
Jan Böcker
Eric Schulte
Bernt Hansen
James TD Smith