Wes Hardaker writes:
> Attached is a patch that lets local variables define whether or not todo
> dependency blocking should be used (both for TODOs and for checkboxes).
> I have one file in particular that I'm using checkboxes to quickly
> indicate multi-selections from a list but for most of my files I want
> TODOs blocked by uncompleted checkboxes.
>
> Normally org uses hook methods for checking for TODO blocks and this
> patch just inserts a check at the top to test and see if the variable
> turning on the blocking type is still set.
zwz writes:
> I use org-remember for my contact records.
>
> This is a template in org-remember-templates
> ("Contact" ?c "* %^{Name} \n%[~/.contact]\n" "contact.org" "Contacts")
>
> the content of the file "~/.contact":
> :PROPERTIES:
> :Mobile: %^{mobile}
> :Email:
> :Added: %u
> :END:
>
> I found that the prompt "%^{mobile}" works, but *the inactive time stamp "%u"
> does not.* It is not replaced.
>
> I guess it is a bug.
Bill Jackson writes:
> When exporting to LaTeX, curly brackets in a command will be escaped
> if that command also contains angle brackets. This can be a problem
> when using beamer. An example input file:
>
> ------------------------------------------------------------------------
>
> #+LaTeX_CLASS: beamer
>
> * The One and Only Frame
> When LaTeX \alert<2>{commands} contain angle brackets, the curly
> brackets are erroneously escaped in the output. \alert{Commands}
> that do not contain angle brackets work properly.
>
> ------------------------------------------------------------------------
>
> Typing C-c C-e l will generate the output file:
>
> ------------------------------------------------------------------------
>
> % Created 2010-01-15 Fri 13:57
> \documentclass{beamer}
> \usepackage[latin1]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
>
> \title{escCurly}
> \author{}
> \date{15 January 2010}
>
> \begin{document}
>
> \maketitle
>
> \begin{frame}
> \frametitle{Outline}
> \setcounter{tocdepth}{3}
> \tableofcontents
> \end{frame}
>
> \begin{frame}
> \frametitle{The One and Only Frame}
> \label{sec-1}
>
> When \LaTeX{} \alert<2>\{commands\} contain angle brackets, the curly
> brackets are erroneously escaped in the output. \alert{Commands}
> that do not contain angle brackets work properly.
> \end{frame}
>
> \end{document}
Bill Jackson writes:
> When exporting to LaTeX, the commands \LaTeX and \TeX are not
> processed consistently. In particular, the backslash for \LaTeX is
> escaped. This might not be a bug, but it is a bit confusing. An
> example input file:
>
> ------------------------------------------------------------------------
>
> * The One and Only Header
> The command \LaTeX generates an escaped backslash, while \TeX and
> \alpha do not. Note that LaTeX is converted to a command, while TeX
> is not.
>
> ------------------------------------------------------------------------
>
> Typing C-c C-e l will generate the output file:
>
> ------------------------------------------------------------------------
>
> % Created 2010-01-15 Fri 13:47
> \documentclass[11pt]{article}
> \usepackage[latin1]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage{graphicx}
> \usepackage{longtable}
> \usepackage{float}
> \usepackage{wrapfig}
> \usepackage{soul}
> \usepackage{amssymb}
> \usepackage{hyperref}
>
>
> \title{escLaTeX}
> \author{}
> \date{15 January 2010}
>
> \begin{document}
>
> \maketitle
>
> \setcounter{tocdepth}{3}
> \tableofcontents
> \vspace*{1cm}
> \section{The One and Only Header}
> \label{sec-1}
>
> The command \\LaTeX{} generates an escaped backslash, while \TeX and
> $\alpha$ do not. Note that \LaTeX{} is converted to a command, while TeX
> is not.
>
> \end{document}
The coding system of the LaTeX class will now only be set to the value
corresponding to the buffer's file coding system if the class
specifies \usepackage[AUTO]{inputenc}. Any other value for the coding
system will not be modified.
Jan Bcker writes:
> Consider the following situation:
>
> * A
> Some text.
> * B
>
> - Place the cursor on A, press C-x n w (org-narrow-to-subtree).
> - Go to the very end of the buffer and insert "xyz".
> - C-x n w (widen).
>
> You end up with:
>
> * A
> Some Text
> xyz* B
Patch by Stephen Eglen, who writes:
> Just a small suggestion here. In the agenda, an entry like:
> * <2010-01-20 Wed 09:00-09:30> test
>
> gets formatted as follows:
>
> Wednesday 20 January 2010
> 8:00...... ----------------
> test: 9:00- 9:30 test
> 10:00...... ----------------
>
> the leading whitespace before '9:00' and '9:30' is needed to align the
> times, but having the space after the dash looks odd (at least to my
> latex-trained eyes). Would it be possible to patch org-agenda to put a
> leading zero rather than leading whitespace. With this patch, I see:
>
> Wednesday 20 January 2010
> 08:00...... ----------------
> test: 09:00-09:30 test
> 10:00...... ----------------
This patch introduces a new user option to select this behavior.
Stephen Eglen writes
> Within the agenda buffer, if I type 'i j' to jump to the current date I
> get:
>
> Debugger entered--Lisp error: (void-function org-datetree-find-date-create)
> org-datetree-find-date-create((1 20 2010))
> org-agenda-diary-entry-in-org-file()
> org-agenda-diary-entry()
> call-interactively(org-agenda-diary-entry nil nil)
>
> If I then do M-x load-library org-datetree
>
> and repeat 'i j', it works. Should this function be autoloaded?
the progress-marker local variable set inside of a let in
org-exp-blocks is used to constrain searches in org-babel-exp to
ensure that a babel block doesn't overwrite non-babel src blocks
Geert Kloosterman writes:
> When an org link is created from an URL containing a hex escape
> `org-make-link-string' creates a link that ends up corrupted the moment
> it is followed (e.g. using `org-open-at-point').
>
> I've traced this back to `org-link-escape' and `org-link-unescape'. The
> following shows how the hex code "%2B" is converted to a "+" after an
> escaping round trip:
>
> (org-link-unescape (org-link-escape
> "http://some.host.com/form?&id=blah%2Bblah"))
> ==>
> "http://some.host.com/form?&id=blah+blah"
>
> In my case this small change ended up in a broken URL.
>
> Additionally, when the URL-escape happens to be in lower case (or
> otherwise not present in `org-link-escape-chars') we end up with an
> error:
>
> (org-link-unescape (org-link-escape
> "http://some.host.com/form?&id=blah%2bblah"))
> ==>
> Debugger entered--Lisp error: (wrong-type-argument characterp nil)
> char-to-string(nil)
> ...
>
> When `org-url-encoding-use-url-hexify' is set to `t' we do get a proper
> round trip of the URL containing hex-escapes:
>
> (setq org-url-encoding-use-url-hexify t)
> (org-link-unescape (org-link-escape
> "http://some.host.com/form?&id=blah%2bblah"))
> ==>
> "http://some.host.com/form?&id=blah%2bblah"
>
>
> Setting `org-url-encoding-use-url-hexify' does not fix the complete
> problem however: `org-open-at-point' still did not end up with the
> proper URL. Within `org-open-at-point' there is another call to
> `org-link-escape':
>
> (org-link-escape path org-link-escape-chars-browser)
>
> This time a mapping table is passed in explicitly (the second argument).
> However, when `org-url-encoding-use-url-hexify' is set,a this mapping
> table isn't used, resulting (again) in a broken URL.
>
> I have attached a patch that fixes the problem: do not use url-hexify in
> `org-link-escape' and `org-link-unescape' when an explicit mapping table
> has been specified.
>
> In summary:
> - the default behaviour of `org-link-escape', with
> `org-url-encoding-use-url-hexify' set to nil, has some issues with
> handling URLS which contain url-encoded hex escapes
> - when a mapping table is passed to `org-link-escape' and
> `org-link-unescape', they should probably not use url-hexify.
> Patch attached.
The variable `org-clock-out-when-done' can now also be a list of
states. When the TODO state of a task changes to one of these states,
the clock will stop running in that task.
This extension of the logic was a proposal by Ricard Riley.
Marting G. Skjaeveland writes:
> I pulled a fresh copy of org-mode this morning and noticed that
> references to source code line numbers no longer work as they used
> to. Instead of displaying the number of the line with the label, the
> label is displayed.
>
> Exporting the following example, retrieved from the online
> documentation (http://orgmode.org/manual/Literal-examples.html),
>
> -------------------------------------start
> #+BEGIN_SRC emacs-lisp -n -r
> (save-excursion (ref:sc)
> (goto-char (point-min)) (ref:jump)
> #+END_SRC
>
> In line [[(sc)]] we remember the current position. [[(jump)][Line
> (jump)]] jumps to point-min.
>
> -------------------------------------end
>
> gives me in latex export
>
> -------------------------------------start
> \begin{verbatim}
> 1: (save-excursion
> 2: (goto-char (point-min))
> \end{verbatim}
>
> In line \hyperref[(sc)]{(sc)} we remember the current
> position. \hyperref[(jump)]{Line (jump)} jumps to point-min.
> -------------------------------------end
>
Patch by Stephan Schmitt, who writes:
> An error was thrown when all tags of a headline are hidden by
> org-agenda-hide-tags-regexp (in this case the function
> get-text-property got nil as third argument)
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.
Carsten Dominik
Dan Davison
Eric Schulte
Bernt Hansen
John Wiegley