This is my rifle. There are many like it, but this one is mine. My rifle is my best friend. It is my life. I must master it as I must master my life.
What does my rifle do? It searches rapidly through my Org files, quickly bringing me the information I need to defeat the enemy.
This package is a continuation of the fantastic org-search-goto/org-search-goto-ml packages, now with Helm support. It searches both headings and contents of entries in Org buffers, and it displays entries that match all search terms, whether the terms appear in the heading, the contents, or both. Matching portions of entries’ contents are displayed with surrounding context and grouped by buffer to make it easy to acquire your target.
Entries are fontified by default to match the appearance of an Org buffer, and optionally the entire path can be displayed for each entry, rather than just its own heading.
An animation is worth…a million words?
With helm-org-rifle-show-path
set to t
, the whole path to each heading is shown:
Note: I’m using solarized-theme
, and these org-level
face styles are just what I use, not part of this package. If you install this, they will be fontified according to your own theme and faces.
Install Helm and s. Then require this package in your init file:
(require 'helm-org-rifle)
Then you can customize the helm-org-rifle
group if you like.
Run one of the rifle commands, type some words, and results will be displayed, grouped by buffer. Hit RET
to show the selected entry, or <C-return>
to show it in an indirect buffer.
Commands:
helm-org-rifle
: Shows results from all open Org buffershelm-org-rifle-current-buffer
: Shows results from current buffer
- Show results from certain buffers by typing the name of the buffer (usually the filename).
- Show headings with certain todo keywords by typing the keyword, e.g.
TODO
orDONE
. - Show headings with certain priorities by typing, e.g.
#A
or[#A]
. - Show headings with certain tags by searching for, e.g.
:tag1:
. - Exclude results with a
!
, e.g.pepperoni !anchovies
. - Show entries in an indirect buffer by selecting that action from the Helm actions list.
- This package is based on
org-search-goto
(specifically,org-search-goto-ml
). Its unofficial-official home is on EmacsWiki, but I’ve mirrored it on GitHub. It’s a really great package, and the only thing that could make it better is to make it work with Helm. To avoid confusion, this package has a completely different name. - Thanks to Thierry Volpiatto for doing such an amazing job with Helm. Without him, this would not be possible.
- Thanks to Jack, aka /u/washy9999 for great feedback and suggestions.
I can’t recommend Outorg enough. If you edit source code and use Emacs, check it out!
None at the moment. Bug reporter z…I mean, bug zapper, standing by…
It would be easy to rifle through Org files in a directory or in a list of files, even if they aren’t already open.
Currently matches are made against word, punctuation, or symbol boundaries–not substrings. For most cases, this is probably the best default: if someone were searching for “Sol”, referring to the sun, he probably wouldn’t want to match “solution” or “solvent” or “soliloquy”. But if someone were trying to dig up a note he made a while back about apple pie, did he write about “an apple pie” or “some apple pies”? Dessert hangs in the balance!
So this should be a configurable default, and calling helm-org-rifle
with a prefix arg should put it into substring mode. Maybe there could even be a toggle within the Helm session.
Right now, if more than one term appears in the same range, parts of that range will show up more than once in the context. Not a big deal, but should be fixable.
helm-org-rifle-get-candidates-in-buffer
might be able to be optimized more with elp
. But the “low-hanging fruit” is probably gone, and performance seems good.
It would be nice to have a regexp mode…maybe.
org-search-goto
had a match limit. I removed it to simplify things, but it might still be useful, depending on how big one’s org files are. However, performance seems good now, so this probably isn’t needed.
GPLv3