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.
Carsten Dominik
Tassilo Horn
Jan Böcker