matching property in agenda view - emacs

I want collect and create a block containing headlines which only has "ID" property in the headlines.
i.e The headlines to be filtered looks like
* Headline
:PROPERTIES:
:ID: my-id
:END:
I am using the following code to configure the custom agenda command which does not work
(setq org-agenda-custom-commands
'(("c" "MY Agenda"
((tags "ID")))))
I have read the org manual http://orgmode.org/manual/Matching-tags-and-properties.html#Matching-tags-and-properties but still unable to figure out how to do it.

Your code as such is asking it to find all headlines that have a :ID: tag on the headline. To look for properties you have to use the property match feature which is listed a bit lower on the linked manual page.
Since I'm assuming you need it to match any ID and not just a specific ID you'll have to use the regexp matching by either matching (=) or not matching (<>) the regexp that follows in curly brackets.
To match your ID property you'll need the regexp to be ID={.+}. If you used .* as the match it would also match headlines without any ID property. If you have some a set of IDs you want to match that have something in common you can adjust the regexp to match them.
So your custom agenda command will have to be:
(setq org-agenda-custom-commands
'(("c" "MY Agenda"
((tags "ID={.+}")))))

Related

Org-mode [[file: ]] link to a file with specific :PROPERTIES: :ID:

I'm trying to find a way to add a clickable link in org-mode that opens another local file and scrolls to a specific property id.
It's easier to explain with an example:
$ cat file1.org
* org links that I've tried and they don't work properly
[[file:path/to/another-file.org::#d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]]
[[file:path/to/another-file.org:id:d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]]
[[file:path/to/another-file.org::d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]]
[[file:path/to/another-file.org::id:d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]]
$ cat another-file.org
* Top category
** Category X
*** Question :drill:
:PROPERTIES:
:ID: d89ba6bd-7c9a-4559-9965-7a6541f1a7c5
:END:
Content of d89ba6bd-7c9a-4559-9965-7a6541f1a7c5 entry
*** Question :drill:
:PROPERTIES:
:ID: some-other-property-uuid
:END:
Content of some-other-property-uuid entry
Unfortunately, I can't change the structure of another-file.org. I can only reference using a property id.
Just renaming "Question :drill:" would have been much easier but it is duplicated many times and as I said it is not available for updates.
Update:
With "CUSTOM_ID" property it seems to be working
*** Question :drill:
:PROPERTIES:
:CUSTOM_ID: d89ba6bd-7c9a-4559-9965-7a6541f1a7c5
:END:
Content of d89ba6bd-7c9a-4559-9965-7a6541f1a7c5 entry
[[file:path/to/another-file.org::#d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]]
But is there any way to make it with with default :ID: property?
Try setting org-link-search-must-match-exact-headline to nil. That makes the third type of link above [[file:path/to/another-file.org::d89ba6bd-7c9a-4559-9965-7a6541f1a7c5][ref]] do a fuzzy text search, whereas the other values (t and the default query-to-create) are biased towards headlines when the target file is an Org mode file.
Here's the doc string of org-link-search-must-match-exact-headline:
org-link-search-must-match-exact-headline is a variable defined in ‘ol.el’.
Its value is nil
Original value was ‘query-to-create’
This variable is safe as a file local variable if its value
satisfies the predicate ‘symbolp’.
You can customize this variable.
This variable was introduced, or its default value was changed, in
version 24.1 of Emacs.
Documentation:
Non-nil means internal fuzzy links can only match headlines.
When nil, the a fuzzy link may point to a target or a named
construct in the document. When set to the special value
‘query-to-create’, offer to create a new headline when none
matched.
Spaces and statistics cookies are ignored during heading searches.
BTW, I found it by reading the External Links section of the manual: look for text search and the accompanying footnote.

Emacs untagged agenda items in org-agenda

How I can find the agenda items which are not tagged in org-agenda mode?
If I use the filtering option org-agenda-filter-by-tag (/ - or C=u /) I have to exclude one by one all tags to achieve this and that is not what I want exactly.
Use the special property TAGS:
TAGS=""
will match headlines with no tags.
See http://orgmode.org/org.html#Special-properties.

org-mode: How to perform an agenda keyword search limited to headline text?

The org-mode agenda command 's' will perform a keyword search over both the headline and the body text of org-mode items. Is there a way to limit the search to just the headline text?
You can enter a regular expression to match only headlines.
For example:
{^\*+.*mykeyword}
will search for lines starting with one or more *, and containing "mykeyword".
Adding a * before entering any keyword is a better and shorter way of searching for headlines only.
For details and other tricks, see Advanced searching

How can I use other heading styles like twiki ---+ or mediawiki == h2 == in org-mode?

I really want to use org-mode.
But, I want to use org-mode to understand structured documents that have already been written using different heading syntax,
e.g. using twiki's ---+
---+ H1
Top level
---++ H2
Nested
---+ H1 #2
Second top level
Or mediawiki like
= H1 =
Top level
== H2 ==
Nested
= H1 #2 =
Second top level
I'd like to have all of the goodness of org-mode folding, etc., just using these different heading styles.
Actually, worse that that:
I would like, say, the twiki or mediawaiki headings to take priority over org mode asterisk headings. But I would like to have both in use.
= H1 =
Top level
* this is a list
** nested
* list
** nested
== H2 ==
Nested
= H1 #2 =
Second top level
--+ What I have tried so far
I have been able to use outline mode to handle twiki,
for example via
---+ Emacs stuff
# try (defvar twiki-outline-regexp "---+\\++ \\|\\(\\(?: \\)+\\)[0-9*] ")
Local Variables: ***
outline-regexp: "^---\\++" ***
org-outline-regexp: "^---\\++" ***
End: ***
However, org-outline-regexp doesn't do hwat I would hope.
emacs' outline-mode's out-level function looks almost exactly like what I want.
(defvar outline-level 'outline-level
"*Function of no args to compute a header's nesting level in an outline.
It can assume point is at the beginning of a header line and that the match
data reflects the `outline-regexp'.")
i.e. instead of regexps, a generic function.
But I have not managed to make it work with org-mode. It looks like org-mode does not really use this, or, rather, has other stuff.
;; In Org buffers, the value of `outline-regexp' is that of
;; `org-outline-regexp'. The only function still directly relying on
;; `outline-regexp' is `org-overview' so that `org-cycle' can do its
;; job when `orgstruct-mode' is active.
(defvar org-outline-regexp "\\*+ "
"Regexp to match Org headlines.")
(defconst org-outline-regexp-bol "^\\*+ "
"Regexp to match Org headlines.
This is similar to `org-outline-regexp' but additionally makes
sure that we are at the beginning of the line.")
(defconst org-heading-regexp "^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$"
"Matches an headline, putting stars and text into groups.
Stars are put in group 1 and the trimmed body in group 2.")
Failing this, well, the main thing that I want from org-mode is links, Asking another question here
How can I "linkify" a non-org-mode buffer in emacs
My frustration was simply that org-mode has different rules for what constitutes a new outline section than outline-mode does. It requires a space after the asterisks, so it doesn't work on my extensive collection of notes, which forgo those spaces.
I resolved that by removing the trailing space in the not-well-documented org-outline-regexp variable, which is used to initialize the buffer-local variable outline-regexp, and that seems to be working for me. E.g. (set-variable 'org-outline-regexp "\\*+")
As to your actual question, my guess is that other regexp's and code would have to change to handle radically different stuff like twiki or mediawiki headings.

Re-organizing in org-mode

In org-mode, I have a simple list of items, with multiple tags (C-c C-c). I like convert this in such a way that I can display each tag as different header and see the items under that tag. For example, if I have tags 'company' and 'fruit' applied to the item 'apple' , then I like to see 'company' and 'fruit' as header and see the 'apple' as item under both of them. I have many other items and I like to combine them. So I can have all fruits under 'fruit' header etc..
The best approach is to use agenda views.
To do this, add your current file(s) to org-agenda-files and then use the org-agenda command. The m option allows you to perform a tag matching search across all your agenda files. So, for example, if you wanted to list all the headlines tagged with "company" in a list, you could do so with C-c a m company <enter>
Org-mode isn't made in a way that encourages you to reorganize your .org documents this way. Instead, you should do agenda searches that give you a dynamic view of what you want to see. E.g., if you do an agenda search for the tags 'company' and 'fruit', the agenda buffer will show all headings that have both of those tags.
As far as having a document that consists of a list of tags, without actual headings, I don't think Org would work that way very well. For example, take the case where you say you have three tags: 'company', 'fruit', and 'apple'. In a normal Org document all three of those tags would apply to the heading. They would not apply to each other. So if you have a case where 'company' and 'fruit' apply to apple then 'apple would have to be the headline, like this:
* Apple :company:fruit:
It makes no sense to have a blank headline that has just tags, since as I said the tags are intended to apply to the headline text, not to each other. So this doesn't really make any sense:
:company:fruit:apple:
What you could do is have a document like this:
* apple :fruit:company:
* fruit :apple:company:
* company :fruit:apple:
And in that case the agenda searches would show what you want. But the document has some redundancy, since same term shows up in different cases as both heading and as a tag.