By default, title, author, date and email lines appear in dark blue
with the initial keywords greyed out. The title is in a larger font
than the others. This is implemented by the following new faces:
org-document-title
org-document-info
org-document-info-keyword
In addition, the variable org-hidden-keywords can be used to make the
corresponding keywords disappear.
Magnus Henoch writes:
> This patch has been sitting in my tree for a while... It's a fix to
> org-map-dblocks, to make it use save-excursion instead of remembering
> position values. I need this since I have a dblock function that
> asynchronously updates dblocks from HTTP responses, and some dblocks
> ended up getting updated twice or thrice.
[...]
> My dblock-write function calls url-retrieve, to asynchronously retrieve an
> HTML page. The callback function I pass to url-retrieve will then fill
> in the information I need into the dynamic block.
>
> So in the following case:
>
> * Find start of dblock 1, store as pos
> * Make HTTP request for dblock 1
> * Go back to pos
> * Find end of dblock 1
> * Find start of dblock 2, store as pos
> * Make HTTP request for dblock 2
> * Asynchronous event: HTTP response for dblock 1 arrives, insert lots of
> data in dblock 1
> * Go back to pos
> * Find end of dblock 2
>
> the last step will actually find the end of dblock 1, if the amount of
> data inserted in dblock 1 is great enough that pos suddenly points
> inside it. (Then it will of course find dblock 2 again, request its HTML
> page again, and thus insert the data twice.)
>
> An equivalent fix would be to make pos a marker instead.
Ryan Thompson writes:
> I have found a bug. When the point is at the end of an empty headline
> and you press M-RET (or C-RET) to make a new headline, it deletes all
> the whitespace at the end of the empty headline first, which causes
> the headline to break. I'm not sure if the correct behavior is to
> leave an empty headline, or maybe just do nothing and leave the point
> at the end of the empty headline without creating a new one, but the
> correct thing is definitely *not* to break the headline.
Patch by Jan Bker.
Jan writes:
> What is this?
> =============
>
> This patch changes the way extension regexps in `org-file-apps' are
> handled. Instead of against the file name, the regexps are now matched
> against the whole link, and you can use grouping to extract link
> parameters which you can then use in a command string to be executed.
>
> For example, to allow linking to PDF files using the syntax
> file:/doc.pdf::<page number>, you can add the following entry to
> org-file-apps:
>
> Extension: \.pdf::\([0-9]+\)\'
> Command: evince "%s" -p %1
>
> In a command string to be executed, the parameters can be referenced
> using %1, %2, etc. Lisp forms can access them using (string-match n link).
>
>
> Where to get it?
> ================
> Either apply the patch by hand or
>
> git pull git://github.com/jboecker/org-mode.git org-file-apps-parameters
>
>
> What's next? / Feedback
> =======================
>
> - Find the bugs. Since this messes with links, a central concept of Org,
> I probably have missed some edge cases; so please test this and
> report if it works for you.
>
> I also appreciate any feedback on code quality or the design decisions
> made. I am learning elisp along the way, so you may be able to write
> some changes in a more idiomatic and/or elegant way.
>
> - Add a mechanism for org-mode modules to add default values to
> org-file-apps, similar to the variables org-file-apps-defaults-*.
> This could be used by modules to define their own extensions to the
> syntax of file: links.
>
> - Modify org-docview.el to use this and deprecate the docview: link syntax.
>
>
> What does it (intentionally) break?
> ===================================
>
> This patch introduces a backwards-incompatible change. If LINE or SEARCH
> is given, the file is no longer guaranteed to open in emacs: if IN-EMACS
> is nil and an entry in org-file-apps matches, that takes precedence.
>
> A grep of the lisp/ and contrib/ directories showed that no code in the
> org-mode distribution was relying on this behaviour; whereever LINE or
> SEARCH is given, IN-EMACS is also set to t.
>
> I decided against adding an additional parameter because that would be
> redundant; the original link as seen by org-open-at-point can be
> reconstructed from PATH, LINE and SEARCH.
>
> I am not that sure if this is the right way to do this, but it seems to
> break as little as possible while hopefully avoiding to add too much
> complexity.
Patch by Dan Hackney.
Dan Hackney writes:
> For paragraph text, `org-adaptive-fill-function' did not handle the
> base case of regular text which needed to be filled. This commit saves
> a buffer-local value of `adaptive-fill-regexp' and uses it if none of
> the org-specific regexps match. This allows email-style ">" comments
> to be filled correctly.
John Wiegley writes:
> I have the following data in my Org-mode file:
>
> #+LINK: cegbug https://portal/bugzilla/show_bug.cgi?id=
>
> ** TODO [[cegbug:351][#351]] Bizcard: Fix Maven build setup
> - State "TODO" from "STARTED" [2010-03-01 Mon 14:42]
>
> Now, in the Agenda and in the Org-mode buffer, everything looks fine.
> I can also use C-c C-o if my cursor is within the #<NUMBER> text.
>
> However, if I'm in the Agenda and I hit C-c C-o, it says 'No match'
> after about a second. Is there any reason I can't open these links
> from the Agenda view?
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
This patch implements reading American dates, like
2/5/3 --> 2003-02-05
2/5 --> ????-02-05
Is also fixes a bug that would force the current year when reading a
date like 2/5 (American) or 2-5 (ISO), and in this way would prevent
`org-read-date-prefer-future' to do its job. This bug was reported by
Lukasz Stelmach.
Move the marker for the last refile location to the heading instead of at the
end of the entry. This was causing C-u C-u C-c C-w to end up on the heading
following the newly refiled entry.
This can help to get out of an inconsistent state produce for example
by viewing from the agenda. Reported by Matt Lundin:
> I'd like to report a minor issue with org-agenda-goto and inline tasks.
> Let's say one has the following file:
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> Blah blah blah blah.
> *************** Here is an inline task.
> *************** END
> Blah blah blah blah blah.
> *************** TODO Here is a second inline task.
> *************** END
> Blah blah blah blah blah.
> *************** Here is a third inline task
> *************** END
> Blah blah blah blah blah.
> --8<---------------cut here---------------end--------------->8---
>
> Let's say one also has the following settings:
>
> --8<---------------cut here---------------start------------->8---
> (setq org-show-hierarchy-above t)
> (setq org-show-siblings '((default . nil) (isearch . t) (agenda . t)))
> (setq org-show-entry-below '((default . nil) (isearch . t) (agenda . t)))
> --8<---------------cut here---------------end--------------->8---
>
> If 1) one tries to jump to the TODO from the agenda and 2) the entry is
> currently folded, org-show-context reveals only the headlines. E.g.,
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> *************** Here is an inline task.
> *************** END...
> *************** TODO Here is a second inline task.
> *************** END...
> *************** Here is a third inline task
> *************** END...
> --8<---------------cut here---------------end--------------->8---
>
> Invoking org-cycle on the END headline does nothing, since all headlines
> deeper than org-inlinetask-min-level are exempted from cycling. As a
> result, the only way to reveal the text in the entry is to cycle the
> parent twice (first to close, then to reveal).
Ruud Brekelmans writes about problems with spurious footnotes:
> I still find similar behavior when exporting to LaTeX with:
>
> #+BEGIN_LaTeX
> \newcommand{\norm}[1]{\lVert#1\rVert}
> #+END_LaTeX
Emilio Arias writes:
> egallego@babel.ls.fi.upm.es (Emilio Jess Gallego Arias) writes:
>
> To reproduce save this minimal org file:
>
> #+STARTUP: even
> * A
> :PROPERTIES:
> :ARCHIVE: a
> :END:
> ** B :ARCHIVE:
> Some text
>
> and hit TAB when in the * A headline; then the ** B headline contents
> will be incorrectly shown.
>
> I've found the culprit in org-hide-archived-subtrees:
>
> ,----
> | (defun org-hide-archived-subtrees (beg end)
> | "Re-hide all archived subtrees after a visibility state change."
> | (save-excursion
> | (let* ((re (concat ":" org-archive-tag ":")))
> | (goto-char beg)
> | (while (re-search-forward re end t)
> | (and (org-on-heading-p) (org-flag-subtree t))
> | (org-end-of-subtree t)))))
> `----
>
> The problem is that the RE matches the first archive "property" and
> then does an org-end-of-subtree which skips all the subtrees of the
> parent tree where the ARCHIVE property is located.
>
> I've replaced this part
>
> | (and (org-on-heading-p) (org-flag-subtree t))
> | (org-end-of-subtree t)))))
>
> by
>
> | (when (org-on-heading-p)
> | (org-flag-subtree t)
> | (org-end-of-subtree t)))))))
>
> so org-end-of-subtree is only called if we are really in a headline. I
> think that makes sense.
>
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.
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
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.
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...
Chris Randle writes:
> I've just noticed that creating a sparse tree with `C-c / r' is
> not displaying matches in my org file. It hasn't always been this
> way, I *think* things were working OK around 6.29, but it's hard
> to be sure.
>
> I've managed to pare my org file down to a few lines that
> demonstrate the problem
>
> ===============================
>
> * Customers
> ** Customer A
> *** Billing
> **** Support during September :ARCHIVE:
> ** Customer B
> 07964-xxxxxx
>
> *** Problem with Laptop
> ** Customer C
> *** Current Details
>
> *** Test of 07968 showing up
> ** Customer D
> 01673-xxxxxx
> 07968-xxxxxx
>
> *** Laptop slowdown fix
> spoolsv.exe at 99%
>
> ===================================
>
> Setting a sparse tree by regexp 0796[48] returns "3 match(es) for
> regexp 0796[48]", but the tree doesn't expand at the hit
> locations. If I manually expand the tree at the locations of the
> hits, the results are highlighted. It makes no difference if the
> hits are in a headline or in notes beneath a headline.
>
> Remove the ARCHIVE tag from the "Support during September"
> headline with `C-c C-x a' and redo the sparse tree. Everything
> now appears expanded as I'd expect.
Hmm, maybe the outline behavior of hide-subtree has changed???
Anyway, we now just use our own function for this.
The following keys now do archiving
C-c C-x C-a archive using the command specified in
`org-archive-default-command'
This variable is by default set to `org-archive-subtree', which means
arching to the archive file.
The three specific archiving commands are available through
C-c C-x C-s archive to archive file
C-c C-x a toggle the archive tag
C-c C-x A move to archive sibling
These bindings work the same in an Org file, and in the agenda.
In addition:
- In the agenda you can also use `a' to call the default archiving
command, but you need to confirm the command with `y' so that this
cannot easily happen by accident.
- For backward compatibility, `C-c $' in an org-mode file, and `$' in
the agenda buffer continue to archive to archive file.
Carsten Dominik
Dan Davison
Eric Schulte
Bastien Guerry
Bernt Hansen
Tassilo Horn
Jan Böcker
James TD Smith
John Wiegley