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---
When exporting to html the source-code block name will be included
as a <label> immediately preceding the exported code. This <label>
is decorated with the 'org-src-name' css class.
When exporting to LaTeX with the listings package the source-code
block name will be included as a listings \title for the code
block. Currently the name will not be exported when the listings
package is not in use.
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:
Christopher Suckling writes:
> Thank you, but not quite working yet:
>
> ,----
> | #+BIND: org-export-latex-title-command ""
> `----
>
> now appears to be having the *effect* of setting a global variable.
>
> I load Emacs then visit the below test org file. I then export the file.
>
> I get a \maketitle line.
>
> I then C-c C-c on the #+BIND: line and re-export.
>
> \maketitle is removed.
>
> I then export another org file without the #+BIND: line.
>
> There is no \maketitle, even though there should be.
>
> I add
>
> ,----
> | #+BIND: org-export-latex-title-command "\foobar"
> `----
>
> to the new org file, C-c C-c and export:
>
> \foobar is added to the exported file.
>
> Finally, I re-export the original test org file (without C-c C-c on the
> #+BIND: line):
>
> \foobar is added to the exported file.
>
> However,
>
> ,----
> | C-h v org-export-latex-title-command
> `----
>
> always returns the value "\\maketitle", no matter what the value of the
> #+BIND: line.
>
> Best, Christopher
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.
Adam Spiers writes:
> I really like the way `M-x org-agenda C' takes you straight to the
> *Customize Option: Org Agenda Custom Commands* buffer. Similarly, it
> would be nice if `M-x org-remember C' took you straight to the
> *Customize Option: Org Remember Templates* buffer.
This does now work, but only if the user has no template defined for
the access letter `C'.
>
> Although in both cases it would be even nicer if the keystroke for
> this was customisable, as no doubt some people already have `M-x
> org-remember C' set up to do something else.
It is not customizable, like for the agenda....
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
Skip clocking out when we are clocking in the same task that
is currently clocking but go through the normal clock-in
setup so a modified task name or effort property is
updated in the modeline.
Avoid closing the currently clocking entry when clocking in the same task
again. Leave the clock entry open until some other task is clocked in.
This allows us to clock in tasks with hooks that are called frequently without
generating lots of short sequential clock entries for the same task.
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---
The regular expression was not optimal, and if there was a horizontal
rule, search would not start from the beginning of the buffer but from
after the rule!
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
When an agenda custom command has an empty string as MATCH element, so
far this would lead to a meaningless search using an empty matcher.
Now and empty (or white) string will be interpreted just like a nil
matcher, i.e. the user will be prompted for the match.
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.
>
David Maus writes:
> When `org-previous-item' is called on an item with nothing above it
> Orgmode enters an infinite loop. The reason is that
> `org-previous-item' searches for non-empty lines by moving point up
> line by line and if there is nothing above an item point gets stuck on
> begin of buffer.
>
> example.org
> ,----
> |
> | - Item
> `----
>
> Move point on Item, M-x org-previous-item RET and Orgmode enters the
> infinite loop.
>
> Attached patch adds a conditional clause to `org-previous-item' that
> leaves the search loop if point reaches beginning of buffer.
Daniel S. Sinder writes:
> Here's an "odd" problem when I call org-archive-subtree with a
> prefix argument. It seems that DONE subtrees are not found if
> I'm using odd level headlines. I've tried this minimal test
> case:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars odd
>
> * DONE Project 1
> *** DONE Task 1.1
> *** DONE Task 1.2
> ---- end: test case 1 ----
>
> If I put the cursor on the level-1 headline and do C-u C-c C-x
> C-s, I am not prompted if I want to archive the level-3 children.
> However, if I remove 'odd' from the STARTUP line and move the
> level 3 headlines to level 2, so I have this:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars
>
> * DONE Project 1
> ** DONE Task 1.1
> ** DONE Task 1.2
> ---- end: test case 1 ----
>
> then a repeat of the same command (C-u C-c C-x C-s) correctly
> asks if I want to archive the two level-2 headlines.
>
> I've removed my personal customizations and the problem does not
> go away.
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:
Julien Barnier writes:
> I recntly noticed that in some specific cases, the final '}' was
> esacped when exproting an emphasis element to LaTeX.
>
> For example, the following element :
>
> /aa/
>
> Is exported to :
>
> \emph{aa\}
>
> This does not append if the string begins with a space or if it
> is ASCII-only. For example, the followig strings are exported
> correctly :
>
> /aaa/
> //
>
> I don't understand why the problem only occurs with non-ASCII chars,
> but I think that the regexp to protect added special chars in the
> org-export-latex-fontify function is missing a '?' in the
> beginning. Tha attached patch corrects 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")
Nicolas Girard writes:
> My point was, in the following two examples, the empty lines right
> before "C" should be preserved in the LaTeX output.
>
> Cheers,
> Nicolas
>
> #===
> - A2
> - B2
>
> C
> #===
>
>
> #===
> - A3
> - B3
>
>
> C
> #===
Carsten Dominik
Eric Schulte
Bernt Hansen
John Wiegley