alphapapa / org-rifle Goto Github PK

Is there a way to run helm-org-rifle at point, so that if, i.e., the cursor is on the word "word" we will search for all org occurences of "word"?

this is very cool! any chance it will be on melpa?

best and thx for your work

Z

The Find-files-raw branch is lightning fast, which I absolutely love! Unfortunately, once a selection is made, the resulting buffer forgets about the UTF-8 coding system.

@zeltak Hey Z, how are you my friend. :) If you have time, I'd appreciate it if you could test the latest version (should be on MELPA later today). I've improved the helm-org-rifle-occur commands so that headers and separators are displayed between sources and results, and you can collapse/fold each result separately (instead of the way it incorrectly folded across result boundaries before), and you can collapse all the results in each source. This ends up being sort of like org-sparse-tree but for multiple files at once.

Thanks for your help!

Attempting to call this refile with C-c C-w produces a pop-up window called helm-mode-org-refile which seems to be the ordinary helm org refile, which requires typing the full name of the file and header exactly as shown without permitting spaces.

I figured this was due to something wonky with my keybindings, so I tried manually overriding the binding:

(define-key map (kbd "C-c C-w") #'helm-org-rifle--refile)

Using this binding results in an error message: command-execute: Wrong type argument: commandp, helm-org-rifle--refile

Any ideas what is going on? I'm not familiar with what the #' is meant to accomplish here, but I think it has to do with lambdas?

I am using helm-org-rifle with spacemacs running helm. I also have helm-org-rifle-show-path set to t. Everything works great, except that longer org-mode paths are being heavily truncated in the display (even though it looks like there should be plenty of room to show the longer org-mode paths).

Is there a way to prevent this from happening?

Hi,
I'm not sure if this is an issue that only arises in my setup.
When I use helm-org-rifle-* to find something in a given target heading, the result (after pressing RET on a search result) is displayed like that, when the org mode file was collapsed before invoking the search command:

* heading1
* heading2
**** target heading
* heading 3

The issue with this is, that I don't know how to navigate to the parent node of "target heading". C-c C-p is jumping to "heading2" because it is the previous visible heading.

What I'd love to have would be when helm-org-rifle-* is displaying a search hit location like this:

* heading1
* heading2
** subheading 2a
*** subsubheading 2a1
**** target heading
* heading 3

1. Can you confirm this behavior or is this a side-effect with my configuration?
2. Is there a way to change the behavior so that I may see the parent headings as suggested above?

Thanks!

This is really awesome, thank you!
I was wondering if it were possible to custom define a couple different directories to have org-rifle search and then bind that to a particular key... such as f5 opens org-rifle for directory A, f6 opens org-rifle for directory B, etc.
Many thanks in advance for any help!

The paths will look nicer now that the Org links are replaced.

A user reported that searching isn't working properly for him when show-path is enabled.

It seems like most everything you are doing with this package would be useful and would work with regular Emacs star outlines (aside from special display formatting). Is there a major reason to limit it to Org buffers? You could probably generalize the code and then add a few org-specific commands on top to handle special needs within Org buffers, I would think.

This is by far the best search interface for org files, thank you very much for developing it! Only thing that is missing, is refiling function, could you implement it?

Emacs 27.1 compiled with MSYS2 MinGW on Windows 10 and using the official Git for Windows release, doing helm-org-rifle-directories on a directory that is tracked with git, I get the following traceback:

Debugger entered--Lisp error: (file-error "Creating process pipe" #("Too many open files" 0 19 (charset windows-1252)))
  call-process("C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil "--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree")
  apply(call-process "C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil ("--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree"))
  process-file("C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil "--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree")
  apply(process-file "C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil ("--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree"))
  magit-process-file("C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil "--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree")
  apply(magit-process-file "C:/Users/user/AppData/Local/Programs/Git/mi..." nil (t nil) nil ("--no-pager" "--literal-pathspecs" "-c" "core.preloadindex=true" "-c" "log.showSignature=false" "-c" "color.ui=false" "-c" "color.diff=false" "-c" "i18n.logOutputEncoding=UTF-8" "rev-parse" "--is-inside-work-tree"))
  magit-git-output(("rev-parse" ("--is-inside-work-tree")))
  magit-git-true("rev-parse" ("--is-inside-work-tree"))
  magit-rev-parse-true("--is-inside-work-tree")
  magit-inside-worktree-p(t)
  magit-file-mode-turn-on()
  global-magit-file-mode-enable-in-buffers()
  run-hooks(change-major-mode-after-body-hook after-change-major-mode-hook)
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer go.org> "~/go/go.org" nil nil "~/go/go.org" (271060402572376067 3868631747))
  find-file-noselect("c:/Users/user/go/go.org")
  helm-org-rifle-get-source-for-file("c:/Users/user/go/go.org")
  #f(compiled-function (it) #<bytecode 0x225b4d9>)("c:/Users/user/go/go.org")
  helm-org-rifle-files(("c:/*.org (lots of .org files ...))
  helm-org-rifle-directories()
  funcall-interactively(helm-org-rifle-directories)
  call-interactively(helm-org-rifle-directories record nil)
  command-execute(helm-org-rifle-directories record)
  helm-M-x-execute-command(helm-org-rifle-directories)
  helm-execute-selection-action-1()
  helm-execute-selection-action()
  helm-M-x(nil)
  funcall-interactively(helm-M-x nil)
  call-interactively(helm-M-x)
  (let ((completion-styles completion-styles)) (add-to-list 'completion-styles (if (version< emacs-version "27") 'helm-flex 'flex) t) (call-interactively 'helm-M-x))
  spacemacs/helm-M-x-fuzzy-matching()
  funcall-interactively(spacemacs/helm-M-x-fuzzy-matching)
  call-interactively(spacemacs/helm-M-x-fuzzy-matching nil nil)
  command-execute(spacemacs/helm-M-x-fuzzy-matching)

I realize that this is ultimately an issue with how Git is run on Windows with its own MSYS2 fork where apparently the maximum open file limit is 256. I experimented with setting it to a higher number, which initially works, but on subsequent helm-org-rifle-directories calls fails as before. I was just wondering if this has happened for other org-rifle users (as this becomes more likely with increasing number of .org files) and whether there are any ideas for a workaround? Is there anything that could be done on org-rifle side?

Feature request: Are there any plans to make helm-org-rifle's searching strategy better? Results do not seem to be sorted by relevance, most frequently visited, etc.

When I initially run helm-org-rifle-org-directory it takes about 5 seconds to show results. It stays this way for every search until I run helm-org-ql-org-directory just once from your org-ql package. After that, helm-org-rifle-org-directory is instantaneous (and awesome!). If I restart Emacs the rifle command is slow again until I run helm-org-ql-org-directory.

I will double check with emacs -q and try to make this reproducible soon, but since you're the author of both packages I thought you might have a hunch about this interaction already

Hi again

so im loving helm-org-file and have been using it alot over the past year or so. one thing that is constantly breaking my fast workflow are commands that work on directories such as helm-org-rifle-org-directory and helm-org-rifle-occur-directories. these can take a long time to load from the time you issue the command until it asks for input. i saw today with the latest ivy release that he included ripgrep for searching with is blazing fast. I was wondering if we can have something like that in helm-org-rifle?

thx alot again for your amazing work!

Z

When the buffer is generated by using one of the helm-org-rifle-occur-* , the buffer that is created does not have the affordances to allow outline-next and outline-previous to work (and thus enable navigation using speed commands)

When I toggle latex fragments preview in Org-mode.
I hope helm-org-rifle can showing those previews too. It will help me to quickly view those latex fragments.
Can it be implemented?
And this can be an option for user.

As mentioned in #4, it might be possible to not activate org-mode inside new buffers unless matches are found. If so, that might provide a significant speed boost. The question is probably whether the outline-related functions still work in a plain or text-mode buffer. If not, something would have to basically reimplement them, which would seem to violate a lot of DRY/NIH/etc. We shall see.

Thanks to @zeltak for your help. Will report here when I have something ready to test.

I get this error on M-x helm-org-rifle or M-x helm-org-rifle-current-buffer

using GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.9) of 2015-03-21 on kissel, modified by Debian

;; Package-Version: 20160420.818
;; Version: 1.3-pre

changing helm-org-rifle-after-init-hook block to this:

(defcustom helm-org-rifle-after-init-hook nil
  "`:after-init-hook' for the Helm buffer.
If you're thinking about changing this, you probably know what you're doing."
  :options '(helm-org-rifle-set-input-idle-delay)
  :group 'helm-org-rifle :type 'hook)

makes the error go away, and the package seems to work. Ironically, unlike the docstring predicts, I don't know what I'm doing. I found a similar discussion on a magit issue and copied that.

Tags inherited by subheadings currently do not show up in helm-org-rifle. For instance...

* My heading :tag1:
** My sub 1
** My sub 2

By default both My sub 1 and My sub 2 inherit :tag1, but a helm-org-rifle search for :tag1 only produces My heading as a result.

Hi,

I really enjoy using this package, but I still find myself using helm-org-agenda-files-headings sometimes. Mainly because I would like to insert a link to a heading. I also have written a few additional actions that I use with helm-org-agenda-files-headings which are useful for my purposes and have not yet found the time to port them to helm-org-rifle.

Maybe helm-org-rifle could consider adding some or all of the following actions:

• Insert link to heading
• Schedule heading
• Capture at heading
• Mark heading as default task (see org-clock-default-task)

The Capture at heading action would work by supplying a new option helm-org-rifle-capture-template-key which will be used as input to org-capture with point at the selected heading. Or instead of adding a new option, just explicitly create a new sub-heading.

org helm rifle: key words can less than 2 characters

but org helm rifle occur
if key words less than 2 characters show nothing

example:
test:
hello word
hehehe

search "he"
org helm rifle: show hello word and hehehe

org helm rifle occur: show nothing

Thanks for a nice package.

When run in a buffer using in-buffer settings helm-org-rifle-get-candidates-in-buffer encounters an error like the following

Debugger entered--Lisp error: (error "Before first headline at position 33 in buffer misc.org")
signal(error ("Before first headline at position 33 in buffer misc.org"))
error("Before first headline at position %d in buffer %s" 33 #)
byte-code("\300\301`p#\207" [error "Before first headline at position %d in buffer %s"] 4)
org-back-to-heading(t)
org-heading-components()

This can be fixed by adding

        (when (org-before-first-heading-p)
          (outline-next-heading))

after the call to (goto-char (point-min)) on line 301.

I've been using the WIP version of org-rifle for a while, and really like it -- but I've run into a weird error that may or may not be solvable.

A lot of what I do is based in text, and I use the text-centric org blocks like #+begin_verse/#+end_verse a lot. When I search my notes, though, words that appear in those verse blocks don't render or work properly. I've attached a screenshot to show how they display:

Functionality-wise, when I try to jump to one of the matches, it just goes to the start of the verse block rather than to the actual position of the word in the file.

I know mine is probably an edge case, but this is so close to being a perfect solution to my search and recall problems!

All the same, thanks for the hard work!

It will look nicer with the fixes to context strings and links, but recording it was kind of an ordeal, so...uh...someday...

I don't currently like how helm-org-rifle actually reveals the selected entry. Let's say you have something like:

** Tasks
*** TODO Task 1
*** TODO Task 2

If the tree is folded and you rifle to "Tasks" then you get something like

** Tasks
    ...

Eh, I would like to be able to customize this behavior to show the full entry and the collapsed children headings for example.

Great package by the way, very useful.

Hi. This is a great feature. It really helps to navigate my collection of .org files. As I move towards org-roam format of writing notes, I find myself writing the title of documents in the +title: at the beginning of the org file.

So my question is the following: Is is possible to also search through titles that are specified as #+title: My title?

Hello,

Thank you for the org-rifle. It's really great. Could you advise if the tag search allows for inheritance? I couldn't get this to work with:

#+FILETAGS: :postgresql

I'm trying to ease my searching while going through several different cheatsheets so I can rifle with:

:postgresql hba

But it's not matching the hba.conf header. I also haven't had much luck with matching the filename itself.

I can add the tags manually per heading if there isn't a way around this. Thank you again for your time.

Hi there!
Finally got time to check out org-rifle, got a minor issue, but otherwise I really like that it displays the outline header in search result, great job!

I've been using helm-swoop for a while to search through my plaintext notes.

There are few things I would miss from helm-swoop (I was testing on helm-org-rifle command):

• jumping to occurence in the buffer as you move through helm list (e.g. see gif). Is it possible in rifle? Perhaps I missed some setting to turn it on, but didn't manage to find.
• if you've got, say, two occurences of the search term on different lines under the same heading, swoop would show it twice on separate lines (as grep would), and I would be able to navigate with C-j/C-k between them. In contrast, org-rifle would only show you single line separated by the ellipsis. I've got something closer to what I want with (setq helm-org-rifle-ellipsis-string "\n"), but it still navigates between headings only. Would it be hard to implement, or it goes against the idea of what org-rifle is meant to do somehow?
• somewhat minor, but I also use swoop to search in non-org mode files (e.g. older notes from my pre-orgmode era, huge org-mode files which I open in fundamental mode, some random text files, etc). How hard do you think it would be to support fallback to swoop-like (grep-like) behaviour for non-org mode buffers?

Thanks!

Org rifle is great, I use it often and it gave me an enhancement idea.

For example, I search my notes for javascript stuff. I find it quickly, but it's annoying to type javascript or even javas often. Why can't I type js instead?

So I'd like to see a pluggable abbreviation feature where I could specify an alist for custom abbreviations.

E.g.

(setq org-rifle-abbrevs '(("js" . "javascript") ("ga" . "google analytics") ...))

With this set I could search for "js timer" and it would return "javascript timer" entries too. (And also the original "js" matches in case one wants to search for the original input, not the expanded abbreviation.)

Sometimes I search for a word that occurs often in my org files, maybe too often to be useful. However I know that I only have one section that has that as a heading. Is there a way to tell rifle to only look at headings?

It seems that when a buffer is narrowed, helm-org-rifle does not display contents outside the narrowing target. I suppose this is not an expected behavior for file/directory rifle commands, and I think you can resolve this issue by using org-with-wide-buffer inside helm-org-rifle--get-candidates-in-buffer. However, there can be situations where users simply want to search contents inside the narrowed scope, e.g. the user is looking at a narrowed indirect buffer.

What do you think?

Hello! Other helm-packages like helm-bbdb do offer the possibility to customize the actions. They do use variables like helm-bbdb-actions. Is it possible to customize the helm actions here? Can you include a variable like helm-org-rifle-actions? I would like to add lots of personal actions like copy the attachments directory to killring, add attachment, copy id to killring etc. Thank you and greetings, Tobias

The docu says on https://github.com/alphapapa/org-rifle#tips

Sort results by timestamp or buffer-order (the default) by calling commands with a universal prefix (C-u)

So I hit C-u, then C-c q, but I get an error message:

helm-org-rifle-directories: No org files found in directories: ~/Dropbox/org

But my org-agenda-files are in that folder, it's full of org files.

I have no luck when trying to go to a search hit in helm-org-rifle (by pressing return). The following message appears:

Symbol’s function definition is void: helm-org-rifle--show-marked-entries

This is with version 20170406.2149.

Hi @alphapapa, great package you have here. I'm not sure I'd have adopted Org without it. Thanks for sharing it.

A small issue is bugging me.

I like to set helm-org-rifle-show-path to t because otherwise I'd be totally lost.

However, in the few occasions I use helm-org-rifle-occur, the prepended paths break the speed keys and other functionality. Probably because the buffer does not respect Org's syntax anymore.

Is there a way to toggle off helm-org-rifle-show-path only for the occur buffer, while keeping it for rifle in general?

I use helm-rifle to search and then mark heading then press "C-c C-w" to refile then I get this error message:

funcall-interactively: Wrong number of arguments: #[(candidate) "�\211�\211�\211A�\242�
�r�q\210b\210\305 -\207" [candidate input0 --dash-source-292-- buffer pos org-refile] 3 ("/home/epic/.emacs.d/elpa/develop/helm-org-rifle-20190809.1831/helm-org-rifle.elc" . 34399) nil], 0

I am running spacemacs develop. I also tested this on my coworkers emacs (also running spacemacs but with different config) with the same result.

This also happens if I mark one, mark several, mark none but have the cursor over one entry, all resulting in the same error message.

I would love to debug this myself, but I am not well versed in elisp debugging (or coding) - I have programmed lots of Java. python etc.. How do i set the debugger so that I can see what fails?

The autoloads.el generated for this package appears to be a bit problematic: it first defines an autoload for the helm-org-rifle-define-command macro and then directly uses that macro to define the various commands inline. Depending on the order in which the autoloads file is loaded and the load-path is set up, that either directly pulls in the package and its dependencies, or fails to define the commands, both of which are missing the point of an autoload file.

There does not seem to be a way of telling the the autoload cookie mechanism about new command-defining top-level forms -- it just special-cases some forms like defun and copies the rest verbatim. So the only way I see around this problem would be to add explicit autoloads, i.e. instead of

;;;###autoload
(helm-org-rifle-define-command "current-buffer" ()

one should probably write

;;;###autoload
(autoload 'helm-org-rifle-current-buffer "helm-org-rifle" nil t)
(helm-org-rifle-define-command "current-buffer" ()

and remove the autoload on the macro altogether.

I can prepare a PR for this if you agree.

There was an issue #15 three years ago which asked whether it would be possible to integrate this with ivy, and the reply was that there ivy lacks some of the features provided by helm, so such an idea would need exploring. I wonder if something has been done in the time since, or maybe it is not that practical after all.

This package is wonderful and I have no problem switching to Helm just for it. Ivy has usually been much more responsive for me though so if something similar could also be done in ivy it would be awesome.

Hi @alphapapa, thanks for this package!
Is there a way to include files in org-agenda-text-search-extra-files when using helm-org-rifle-agenda-files?

TIA,
aded

@zeltak @jonmoore @whacked Hi there, I have just pushed a new branch that lets you sort results by the latest timestamp in each node.

https://github.com/alphapapa/helm-org-rifle/tree/sort-by-timestamp

It seems to be working but I would like it to get more testing before I release it. If you have time, would you mind testing it out?

1. There are new commands: helm-org-rifle-sort-by-latest-timestamp and helm-org-rifle-current-buffer-sort-by-latest-timestamp.
2. The regular commands can be run with a prefix to prompt for the sorting method, either nil (which is the order they appear in the file), or to sort by latest timestamp. The sorting method persists. This UI could be a bit nicer still. Also, the prefix conflicts with using a prefix for running helm-org-rifle-directories recursively, so I'll have to figure out another way to do that.

Also, please let me know if you have any ideas for the best way to access the sorting feature. The best way I've thought of would be to have a separate command to activate sorting which would present the different sorting options in a list with Helm and then activate the command. Another possibility would be to use a hydra, but I'm not sure I want to add a dependency for that.

Thanks. :)

For some of the notes I take I like to have a screenshot of an equation from an ebook (rather than figure out the complicated latex for it). It would be great If I could see these preview images while searching through my notes with org-rifle.

Any way of accomplishing this?

I've tried adding

  (advice-add 'helm-org-rifle--occur-prepare-results-buffer :after (lambda (&rest r) (org-display-inline-images)))

but was not seeing the results I want.

Hi! I thought, is it possible to view the outline of the file with helm-org-rifle-current-buffer'? helm-org-in-buffer-headings' does that (from `helm-org' package in melpa), but it fails to preserve the structure of the tree, sorting everything in alphabetical order. A keyword in the input field (or even a seperate function) would work very nicely, I think, allowing both search customization and the ability to have the whole outline right in front of you when you need it.

Hi! Sorry for posting this here, since its probably not related to helm-org-rifle. Anyway I tried to add an action to helm-org-rifle to make it possible to open org-brain entries directly from it. The code looks like this:

(defun helm-org-rifle-open-in-brain (candidate)
  (-let (((buffer . pos) candidate))
    (with-current-buffer buffer
      (goto-char pos)
      (org-brain-visualize-entry-at-pt))))

(add-to-list 'helm-org-rifle-actions
             (cons "Show entry in org-brain" 'helm-org-rifle-open-in-brain)
             t)

(defun helm-org-rifle-brain ()
  "Rifle files in `org-brain-path'."
  (interactive)
  (helm-org-rifle-directories (list org-brain-path)))

When I use helm-org-rifle-brain and then use the Show entry in org-brain action, the buffer part of candidate in helm-org-rifle-open-in-brain is a killed buffer. Do you have any experience with this behaviour?

From the documentation:

When =helm-org-rifle-show-path= is enabled, replace Org links in headings with their descriptions. This prevents =org-format-outline-path= from truncating the links, making them useless for reading.

I tend to have a lot of headings that contains only links with no paragraphs underneath it, and I usually prefer to search with the outline path visible. But the behavior mentioned in the documentation above makes it hard for me to search them because the links are now invisible in the helm buffer. This is especially true when I'm searching based on tags.

Are there any workarounds to this?

In the Github docs, there's this line,

If you installed from MELPA, your rifle is ready. Just run one of the commands below.

where 'commands' is a link. But I get a 404 error when I click on it.

Say I have

* Parent
** Child
** Grandchild <--I want to be here

and

* Heading
** Also With
*** Grandchild

I keep searching using helm-org-rifle by typing "Child/Grandchild" or "Child Grandchild" so that I can get to my desired location. But this doesn't seem to work with helm-org-rifle. Instead I can only type "Grandchild" and have to sift through the multiple results.

Is there a way around this?

I did an Upgrade recently, of all my packages on Melpa. Now when I run helm-org-rifle I am prompted for a "PATTERN:" (which I key in) and I can then select a result in the indirect buffer.

However, when I hit [enter] to complete the selection, I receive an error message:

Wrong number of arguments: (1 . 1), 0

Any ideas?

Thanks,
-Adam