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?
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---
Carsten Dominik