Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add support for org links. #206
This is based on #34 but also stores all the related entry metadata, so they can be used in capture templates.
Also adds support for org mode 9+ which uses different link syntax/functions.
For use in templates, you can use all the metadata under
("l" "Read later" entry (file "~/org/refile.org") "* %?%:description :readlater: - %:link %(when (< 0 (length \"%:elfeed-entry-link\")) (concat \"- web link: \" \"%:elfeed-entry-link\"))")
The difficulty with these Org pull requests is that I don't use Org and I'm unfamiliar with how it's used. I don't really have the context I need make a decision about merging, so they just languish. That's why elfeed-org is a separate package, maintained by @remyhonig who (I presume) knows this stuff.
@skeeto The problem is that
You can think of org files as glorified markdown. Instead of just normal links (to websites), it supports links to email (gnus), files, bibtex, irc, bookmarks, git commits, search strings, direds, grep result sets and many more things. Basically a link provites a syntax to store "something" which when run provides the desired outcome.
So when I create such a link in my notes file which points to a mail or an elfeed entry, I can just click on it (or
Elfeed already provides integration with bookmarks, which is in principle very similar, org links are just textual representation for the same concept.
Alright, this seem simple enough, so I merged it. The header says to
referenced this pull request
Apr 12, 2017
I'm not sure what is going on to be honest. If you know how the elisp debugger works maybe you can step through
The properties are only stored when you capture from the "show" mode (viewing an entry) not from the search. Are you doing that?