org-store-link with headline as description using CUSTOM_ID property? - org-mode

I recently upgraded my org-mode (to version 9.4.6) and now org-store-link/org-insert-link when used with a headline with a CUSTOM_ID property no longer inserts a link with the text of the headline as the link description. Instead, the generated description is the full pathname of the file containing the link and the custom id as a search target (delimited by "::").
I liked the old behavior; how can I get it back?

I'm not sure what the previous code was for that, but I think they've added a separate custom_id in org-store-link (file ol.el).
You can see in org-store-link underneath the comment ;; Store a link using the CUSTOM_ID property. in that function. This may not be a proper fix but you could simply change
;; OTHER CODE
;; Store a link using the CUSTOM_ID property.
(setq custom-id (org-entry-get nil "CUSTOM_ID"))
(setq cpltxt
(concat "file:"
.
.
to
;; Store a link using the CUSTOM_ID property.
(setq custom-id (org-entry-get nil "CUSTOM_ID"))
(setq desc (org-link--normalize-string (org-get-heading t t t t)))
(setq cpltxt
(concat "file:"
.
.
Basically setting desc as the current heading. There should be a better way but this works for me.

Related

Secret structure in org-mode?

I'm wondering I if there's any functionality in org-mode that can make me able to operate with secret structure, that is: structure that I can see when I'm editing but that is treated as if it wasn't there when exporting. It's mainly importing when I export to ascii.
Example:
I would like this in the .org file:
* Normal heading
** Secret heading 1
Some text 1
** Secret heading 2
Some text 2
** Secret heading 3
Some text 3
To be exported to this:
Normal heading
--------------
Some text 1
Some text 2
Some text 3
What makes the headings secret can be anything like a tag, a property or something else but the secret headings should be foldable.
Edit:
Found this solution (from here) (I'm using org-mode 7.9.3 f. It doesn't work. Headlines with the :ignoreheading: tag are still displayed:
;; backend aware export preprocess hook
(defun sa-org-export-preprocess-hook ()
"My backend aware export preprocess hook."
(save-excursion
(when (eq org-export-current-backend 'latex)
;; ignoreheading tag for bibliographies and appendices
(let* ((tag "ignoreheading"))
(org-map-entries (lambda ()
(delete-region (point-at-bol) (point-at-eol)))
(concat ":" tag ":"))))))
(add-hook 'org-export-preprocess-hook 'sa-org-export-preprocess-hook)
You can use the EXCLUDE_TAGS property and tag certain sections, then export with org-export-exclude-tags. E.g:
#+EXCLUDE_TAGS: noexport
* Public Section
* Secret Section :noexport:
Documentation here.
What you want is addressed here -- and here's the answer (repeated):
Add the following to your .emacs file:
(require 'ox-extra)
(ox-extras-activate '(ignore-headlines))
Use the ignore tag on headlines you'd like to have ignored (while not ignoring their content)
I upgraded to org-mode 8.2.5h and with that this works:
(defun sa-ignore-headline (contents backend info)
"Ignore headlines with tag `ignoreheading'."
(when (and (org-export-derived-backend-p backend 'latex 'html 'ascii)
(string-match "\\`.*ignoreheading.*\n"
(downcase contents)))
(replace-match "" nil nil contents)))
(add-to-list 'org-export-filter-headline-functions 'sa-ignore-headline)
But only if you don't have the options: #+OPTIONS: tags:nil. Guess it's sort of obvious that tags shouldn't be filtered away before a filtering that relies on a certain tag is invoked - but that bugged me for quite some time.
Note: when exporting to ascii the headline underlining will remain without the headline, so you need this setting too:
(setq org-ascii-underline (quote ((ascii) (latin1) (utf-8))))
... to remove headlines all together.
In the linked question about the ignoreheading tag I posted a working, simpler org-export-before-parsing-hook solution for Org 8.2.10 in Emacs 24.1.1.
It is based on the documentation of the org-map-entries function which also states that it wraps it in save-recursion automatically. It is simpler than using concat because the second argument to org-map-entries is an agenda-style match string.
While trying to solve the same problem I found this thread describing how to extend ox-extra.el using a notignore tag. This method does not export any headings unless explicitly tagged notignore. Content of the heading are exported normally.
For most of my documents the notignore approach is more useful than the 'ignore' approach because the majority of headings are 'secret structure' not intended for export.
Presently I have notignore-headlines activated in my init.el file. Can anyone suggest a way to activate this on a per document basis.

Add CREATED date property to TODOs in org-mode

I read the org-mode manual but couldn't find an easy way to add a CREATED field to newly created TODOs. In combination with org-log-done one could then compute the time it took to close a particular TODO. This is especially useful when using archive files.
Example:
* TODO Do something
CREATED: [2012-09-02 Sun 23:02]
* DONE Do something else
CREATED: [2012-09-02 Sun 20:02]
CLOSED: [2012-09-02 Sun 22:02]
I would expect the CREATED field to be added to new tasks (tasks which don't have that field) whenever the file is saved.
Any suggestions on how to achieve this? Using something like Git is not a solution for me to track the creations of TODOS.
I use org-expiry to implement that functionality, which is in the contrib directory of org.
The base configuration I use is:
;; Allow automatically handing of created/expired meta data.
(require 'org-expiry)
;; Configure it a bit to my liking
(setq
org-expiry-created-property-name "CREATED" ; Name of property when an item is created
org-expiry-inactive-timestamps t ; Don't have everything in the agenda view
)
(defun mrb/insert-created-timestamp()
"Insert a CREATED property using org-expiry.el for TODO entries"
(org-expiry-insert-created)
(org-back-to-heading)
(org-end-of-line)
(insert " ")
)
;; Whenever a TODO entry is created, I want a timestamp
;; Advice org-insert-todo-heading to insert a created timestamp using org-expiry
(defadvice org-insert-todo-heading (after mrb/created-timestamp-advice activate)
"Insert a CREATED property using org-expiry.el for TODO entries"
(mrb/insert-created-timestamp)
)
;; Make it active
(ad-activate 'org-insert-todo-heading)
If you are using capture it does not automatically work and needs a little glue. I have posted the complete config here: https://gist.github.com/4037694
A more lightweight solution would be to add ! flag to the TODO state:
(setq org-todo-keywords '((sequence "TODO(!)" "DONE")))
Then:
* TODO get of your ass
- State "TODO" from [2016-06-03 to. 10:35]
It isn't very pretty though.
Ref: http://orgmode.org/org.html#Tracking-TODO-state-changes
You don't need to modify functions with 'defadvice' to run expiry code on capture.
You should use hook:
(add-hook 'org-capture-before-finalize-hook
(lambda()
(save-excursion
(org-back-to-heading)
(org-expiry-insert-created))))
Same for 'org-insert-todo-heading'. There is a hook:
(add-hook 'org-insert-todo-heading-hook
(lambda()
(save-excursion
(org-back-to-heading)
(org-expiry-insert-created))))
Org provides a hook org-after-todo-state-change-hook which you can use here:
org-after-todo-state-change-hook is a variable defined in ‘org.el’.
Documentation:
Hook which is run after the state of a TODO item was changed.
The new state (a string with a TODO keyword, or nil) is available in the
Lisp variable ‘org-state’.
Use it as follows:
(require 'org-expiry)
(add-hook 'org-after-todo-state-change-hook
(lambda ()
(when (string= org-state "TODO")
(save-excursion
(org-back-to-heading)
(org-expiry-insert-created)))))
org-expiry is part of org-contrib, which is included in the org-plus-contrib package on the org ELPA.
Here's a buried treasure:
(setq org-treat-insert-todo-heading-as-state-change t)
I found it here, in response to someone saying they wanted an org-insert-todo-heading-hook.
Just tried it out and, true to form, when you org-insert-todo-heading, it counts as a state change, so ex: #+TODO: TODO(t!) | ... will add a log.
If you create all your TODOs with org-capture the following capture template does the trick:
(setq org-capture-templates
'(
("t" "TODO Task" entry (file+headline "~/inbox.org" "Tasks")
"* TODO %?\nCREATED: %u\nSRC: %a\n%i\n")
))
The result will look something like this:
* Tasks
** TODO Dummy task
CREATED: [2015-05-08 Fri]
SRC: [[file:~/path/to/file/where/you/created/the/task.org::*heading"][heading]]
Here is a lightweight solution that does not require an external package. I got it from the answer by #MarcinAntczak, the comments by #Clément, and this similar thread. It works with org-capture and with M-S-RET. Put this in your Emacs initialization file (e.g. ~/.emacs):
(defun insert-created-date(&rest ignore)
(insert (format-time-string
(concat "\nCREATED: "
(cdr org-time-stamp-formats))
))
(org-back-to-heading) ; in org-capture, this folds the entry; when inserting a heading, this moves point back to the heading line
(move-end-of-line()) ; when inserting a heading, this moves point to the end of the line
)
; add to the org-capture hook
(add-hook 'org-capture-before-finalize-hook
#'insert-created-date
)
; hook it to adding headings with M-S-RET
; do not add this to org-insert-heading-hook, otherwise this also works in non-TODO items
; and Org-mode has no org-insert-todo-heading-hook
(advice-add 'org-insert-todo-heading :after #'insert-created-date)
I did not add this function to state changes (e.g., from plain heading to TODO) because it would need to be in a properties drawer and I prefer to not have those extra lines. If you prefer to have it in properties, use the function defined in see this thread.
You can add a time stamp at creation time with zero config, but it won't be labeled CREATED. Rather than manually typing TODO, use C-c C-t. It will then be logged as "state changed to TODO from """ and time stamped.

Interactively enter headline under which to place an entry using capture

Using capture templates like the one below, I can add entries to different headlines in a file. How can I manually enter a headline during capture, instead of setting up each headline to a key in the .emacs file like I am now doing?
(setq org-capture-templates
'(
("l" "Log" entry
(file+headline "c:/Org/log.org" "Log")
"\n\n** %?\n<%<%Y-%m-%d %a %T>>"
:empty-lines 1))
It looks like, in newer versions of org at least, that custom functions can be used in capture templates to do this.
Instead of:
entry
(file+headline "~/Work/work.org" "Refile")
You can use:
entry
(file+function "~/Work/work.org" function-finding-location)
Where 'function-finding-location' is a custom function you have written yourself, which could easily prompt you for a headline.
Or, you can go even farther, and define a custom function which will prompt for both file name and headline name (or anything else you can dream up):
entry
(function function-finding-location)
I don't really know enough elisp to write these functions myself, but this looks like the place to start. It'd be nice if someone else could offer up some code. The relevant documentation is here:
http://orgmode.org/manual/Template-elements.html
I wrote a function to be used with file+function which will prompt for a location on capture.
It uses the internal prompting function of org-refile so we get completions of headings in the prompt (with maxlevels overridden to 9). When the user enters an unknown heading, it creates it at the end of the file.
(defun org-ask-location ()
(let* ((org-refile-targets '((nil :maxlevel . 9)))
(hd (condition-case nil
(car (org-refile-get-location nil nil t t))
(error (car org-refile-history)))))
(goto-char (point-min))
(outline-next-heading)
(if (re-search-forward
(format org-complex-heading-regexp-format (regexp-quote hd))
nil t)
(goto-char (point-at-bol))
(goto-char (point-max))
(or (bolp) (insert "\n"))
(insert "* " hd "\n")))
(end-of-line))
In your case, you use it like this:
(setq org-capture-templates
'(("l" "Log" entry
(file+function "c:/Org/log.org" org-ask-location)
"\n\n** %?\n<%<%Y-%m-%d %a %T>>"
:empty-lines 1))
I don't believe you can have it prompt for the headline on capture. You can however refile from within the capture window which should result in the desired behaviour.
I would define a catch-all target headline/file so that if you forget you will always collect them in the same location and then just have to refile them once created. If you also set a category/tag on this headline you will be able to easily see the misfiled capture entry and refile it as desired. (Example below)
Then instead of finishing with C-c C-c choose to refile with C-c C-w and you will be asked to select the headline you want to send the new entry to.
The capture template I use for this catch all is as follows (adapted from Bernt Hansen's capture settings)
("i"
"Incidents"
entry
(file+headline "~/Work/work.org" "Refile")
"* TODO %^{Ticket} - %^{User}\nSCHEDULED: %^t DEADLINE: %^t\n:PROPERTIES:
\n:DATE: %^U\n:END:\n%^{MANAGER}p%^{HOSTNAME}p%^{LOCATION}p%^{TEL}p\n%c"
:empty-lines 1 :clock-in t :clock-resume t)
(Line breaks are added to avoid scrolling when reading here)
The heading is configured as follows
* Refile :refile:
:PROPERTIES:
:CATEGORY: Unsorted
:END:
With this I end up with all non-refiled tasks showing up as
Unsorted: Deadline: TODO <Headline> :refile::
I currently tend to use tags as reference if I'm waiting for coworkers/managers to deal with the ticket, or to remind me to speak to them about it when I see them so the tag at the end stands out clearly, as does Unsorted if I'm trying to remember what the issue is (since I simply have a case number and user name showing, details within the entry).
while capturing a note, after finishing writeup press C-u C-c C-w to refile under desired new headline.
you also need to set this variable
(setq org-refile-allow-creating-parent-nodes (quote confirm))
you can set it to t instead of confirm. But I like it be confirm because I dont often refile to new targets

org-mode capture with sexp

I'm trying to get create a capture template that converts an URL to an org-mode link with the <title> as the link name.
My conversion function looks like this:
(defun get-page-title (url)
"Get title of web page, whose url can be found in the current line"
;; Get title of web page, with the help of functions in url.el
(with-current-buffer (url-retrieve-synchronously url)
;; find title by grep the html code
(goto-char 0)
(re-search-forward "<title>\\([^<]*\\)</title>" nil t 1)
(setq web_title_str (match-string 1))
;; find charset by grep the html code
(goto-char 0)
;; find the charset, assume utf-8 otherwise
(if (re-search-forward "charset=\\([-0-9a-zA-Z]*\\)" nil t 1)
(setq coding_charset (downcase (match-string 1)))
(setq coding_charset "utf-8")
;; decode the string of title.
(setq web_title_str (decode-coding-string web_title_str (intern
coding_charset)))
)
(concat "[[" url "][" web_title_str "]]")
))
When called from normal emacs lisp code it returns the correct result. But when used in this org-capture-template it only returns bad url.
setq org-capture-templates
(quote
(("l" "Link" entry (file+headline "" "Links")
"* \"%c\" %(get-page-title \"%c\")"))))
Is the order of expansion different? Do I need to escape the string differently? Magic?
The first %c is only their to debug the string and indeed is getting printed as "url".
Please don't even bother pointing out that parsing XML with regexp is the wrong approach. Cthulhu is already haunting me and this isn't going to make it worse.
The problem is the order of expansion of template parameters. The simple % templates are expanded after the sexp has been evaluated. The original error message still contains a template and thus is expanded into the contents of the clipboard and thus the error message contains not the string that was originally passed to get-page-title.
The solution is to access the kill ring from within the sexp:
%(get-page-title (current-kill 0))
EDIT This behavior is now documented in org-mode.
Wouldn't the solution be to use org-protocol.el?
http://orgmode.org/worg/org-contrib/org-protocol.html
I just tested it with the following template (adding a sub-heading for your desired title as headline).
Template:
("t"
"Testing Template"
entry
(file+headline "~/org/capture.org" "Testing")
"* %^{Title}\n** %:description\n\n Source: %u, %c\n\n%i"
:empty-lines 1)
Then using a browser-based keybind (in my case with Opera, although examples for Firefox, Uzbl, Acrobat and Conkeror are provided as well) I was able to capture the following:
** Testing for StackExchange
*** org-protocol.el - Intercept calls from emacsclient to trigger custom actions
Source: [2011-08-05 Fri], [[http://orgmode.org/worg/org-contrib/org-protocol.html]
[org-protocol.el - Intercept calls from emacsclient to trigger custom actions]]
org-protocol intercepts calls from emacsclient to trigger custom actions
without external dependencies.
(I broke the org-link simply to keep the scrolling to a minimum, it was not on two lines originally)
#aboabo shared an undocumented variable in https://stackoverflow.com/a/21080770/255961 that provides a more general solution to the question's topic of how to use sexp with keyword values in a template (beyond kill ring). The variable org-store-link-plist stores all the information being passed to the capture. So you can access its values directly from a function like this:
(defun url()
(plist-get org-store-link-plist :url))
("w" "capture" entry (file "~/refile.org")
"* [[%:link][%:description]] :NOTE:\n%(url)%U\n"
:immediate-finish t)
PS, According to the manual page (quote below) it sounds to me like your approach in teh question should work also. But I agree what you describe is what seems to be actually happening - it seems like a bug relative to the manual.
%(sexp) Evaluate Elisp sexp and replace with the result. For convenience,
%:keyword (see below) placeholders within the expression will be
expanded prior to this.

Get a list of all tags in emacs

Is there a way to get all of the tags from the files defined in your tags table list? I've set my tags file like this:
(setq tags-table-list '("~/project/TAGS"))
I've tried (tags-completion-table), but it doesn't contain all the tags.
If you got only one TAGS file, M-x visit-tags-table ~/project/TAGS or (visit-tags-table "~/project/TAGS") should load the TAGS table into a buffer which means it becomes accessible to Emacs in the same way it would be used for, M-x tags-search.
If you add more TAGS files to the project or have more than one project, (setq tags-table-list '("~/project1/TAGS" "~/Project2/TAGS" ...)) and doing (visit-tags-table-buffer t) should visit the next table each time it is called, until the end of the list.
EDIT:
(defvar buffer-in-string)
(defvar string-list)
(defun write-buffer-to-string ()
(interactive)
(setq buffer-in-string (buffer-substring (point-min) (point-max)))
(kill-buffer) ;; If the buffer is big, it makes sense to kill it,
;; since its contents are copied into the string anyway
(setq string-list (split-string buffer-in-string " "))
)
That should bring the buffer into a string. There should be a more elegant way, but at the moment, this is the most I could write with my very limited elisp fluency.
Function tags-completion-table gives you a completion table to use. From the doc string:
Build 'tags-completion-table' on demand.
The tags included in the completion table are those in the current
tags table and its (recursively) included tags tables.
And tags-lazy-completion-table gives you a completion function to use. It uses tags-completion-table.