dumb-jump "hanging"

[zenspider]

I recently (inadvertantly) bumped from melpa-stable at 0.5.3 (iirc) to melpa and am having some pain now. I believe this is related to #101 but I have more info. Here's my basic setup, explanation below:

;; modes/dumb-jump.el:

(eval-after-load 'dumb-jump
  (let ((map dumb-jump-mode-map))
    (define-key map (kbd "C-c .") 'dumb-jump-go-other-window)
    (define-key map (kbd "C-c ,") 'dumb-jump-go-prefer-external-other-window)
    (define-key map (kbd "C-c *") 'dumb-jump-back)
    (define-key map (kbd "C-c q") 'dumb-jump-quick-look)))

;; hooks/enh-ruby-mode.el

(dumb-jump-mode)

so, on first load of a ruby file, dumb-jump-mode is invoked, which hits the autoload, which triggers my eval-after-load... that, for some reason causes dumb-jump-quick-look to actually trigger. And that is going through the following problematic stack trace:

;; Debugger entered--Lisp error: (quit)
  call-process("/bin/bash" nil t nil "-c" "ag --nocolor --nogroup --ruby ...")
  call-process-shell-command("ag --nocolor --nogroup --ruby ..." nil t)
  shell-command("ag --nocolor --nogroup --ruby ..." t)
  shell-command-to-string("ag --nocolor --nogroup --ruby ...")
  dumb-jump-run-command("require" "/Users/ryan" ("..." ...) "ruby" nil "/Users/ryan/Work/p4/zss/src/vlad/dev/lib/vlad.rb" 1 dumb-jump-parse-ag-response dumb-jump-generate-ag-command)
  #f(compiled-function (it) #<bytecode 0x1ffe5a8910e9>)("/Users/ryan")
  mapcar(#f(compiled-function (it) #<bytecode 0x1ffe5a8910e9>) ("/Users/ryan"))
  dumb-jump-fetch-results("/Users/ryan/Work/p4/zss/src/vlad/dev/lib/vlad.rb" "/Users/ryan" "ruby" nil nil)
  dumb-jump-fetch-file-results(nil)
  dumb-jump-get-results(nil)
  dumb-jump-go(t)
  dumb-jump-quick-look()
  eval-after-load-helper("/Users/ryan/.emacs.d/elpa/dumb-jump-20201205.1625/...")
  run-hook-with-args(eval-after-load-helper "/Users/ryan/.emacs.d/elpa/dumb-jump-20201205.1625/...")
  do-after-load-evaluation("/Users/ryan/.emacs.d/elpa/dumb-jump-20201205.1625/...")
  (dumb-jump-mode)
  rwd-enh-ruby-mode-hook()
  run-hooks(change-major-mode-after-body-hook prog-mode-hook enh-ruby-mode-hook)
  apply(run-hooks (change-major-mode-after-body-hook prog-mode-hook enh-ruby-mode-hook))
  run-mode-hooks(enh-ruby-mode-hook)
  enh-ruby-mode()
  set-auto-mode-0(enh-ruby-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)

Problem 1: I can't find how/why the eval-after-load-helper is invoking dumb-jump-quick-look.

It just doesn't look like quick-look is hooked anywhere that I can find.

(in describing this problem, it dawned on my that I'm using eval-after-load without quoting the form (or just using with-eval-after-load)... this makes problem 1 go away, but I still don't know what it is about the code above that is causing quick-look to trigger on file load/revert—feel free to ignore this one, I believe the other 2 problems are still relevant)

Problem 2: is that dumb-jump-go and/or friends have decided to walk all the way up to my home before starting a search, which is what the actual "hang" is.

Ignoring problem 1 for a sec...

I think if the traversal up winds up in the home directory, it should NOT search there and instead search in the directory of the originating file. Warn about not finding the top of a project, etc... something.

Adding config dumb-jump-stop-if-project-not-found (with options 'stop, 'warn, 'continue) or dumb-jump-disallow-home or somesuch would help here too.

Problem 3: is that the 2 second timeout is clearly NOT working.

With dumb-jump-debug set to t, I would hope that the combination of the two would provide quick feedback as to what is going wrong. Instead, I had to turn on debug-on-exit to get a stack trace that pointed out it was scanning home.

I see looking through the code that this only warns about the time and there is no timeout mechanism. I could see value in having an actual timeout vs having something that warns that you might be missing a faster binary.

[jacktasia]

Thanks for opening this.

Problem 1

define-key will return return DEF and let will return the last item in the list. So as far as I can tell you're effectively doing this (eval-after-load 'dumb-jump 'dumb-jump-quick-look)

Problem 2

This is already outlined in #101 as you mentioned but sounds like there's just no project denoter in your project so it keeps looking at the parent until it gets to ~ (see dumb-jump-default-project or maybe dumb-jump-project). The easiest solution would just be do touch .dumbjump in your project root. This is rarely a problem because people are usually using version control of some kind which naturally sets the boundaries of a project.

Adding config dumb-jump-stop-if-project-not-found (with options 'stop, 'warn, 'continue) or dumb-jump-disallow-home or somesuch would help here too.

I am definitely open to either of these ideas if someone wants to open a PR but in practice, I think needing something like this ends up being quite rare.

Problem 3

is that the 2 second timeout is clearly NOT working.

This is not a timeout nor do I think it is ever advertised as such. That said, I totally agree it would be nice if this was a timeout. I think I attempted to add this at some point but the single-threaded nature of emacs made this an easier said than done thing. Again, I am more than happy to consider a PR if anyone wants to add this type of functionality.

[jacktasia]

Closing, but happy to reopen if I missed or misunderstood anything above.

[zenspider]

sorry to take so long...

problem 1

totally understood. all on my side. still confusing.

problem 2

The easiest solution might be to add a file to the project I'm in. But what about my (not exaggerating) 99 others ? I still think it is a mistake to back up to the user's home and search from there. I can't imagine a scenario where that is the desired outcome unless they fired it off in that directory.

using version control of some kind which naturally sets the boundaries of a project.

That depends entirely on the VCS. Not all have hidden dirs at the top. Some have literally nothing.

I still think there could be some smarts added here... Obviously there could be a custom option to determine the behavior, but even simply erroring would help clue in the user that something is wrong and dumb-jump's assumptions can't be met as-is. Use that as an opportunity to tell them about the file denoters or the hidden file. Something other than literally starting to scan through, in my case, 118368 directories with 621681 files (and if anything, that's low).

problem 3

It's kinda implied by the name... it's called dumb-jump-max-find-time, not dumb-jump-warn-find-time or something similar.

maximum
as great, high, or intense as possible or permitted

[jacktasia]

But what about my (not exaggerating) 99 others ?

I don't follow your point here. You're only ever searching in one project at a time, so you only ever need to handle (ensure it has a denoter) one project at a time. One time cost per project. If you have 99 projects that have absolutely no popular project denoters, then worst case it's a few lines of bash to inject a .dumbjump file in each of them.

That depends entirely on the VCS. Not all have hidden dirs at the top. Some have literally nothing.

I haven't come across one. Curious to hear examples, but usually there is something in the project root (like a Makefile) if not the fallback to requiring just adding a dummy .dumbjump file feels pretty fair.

I still think there could be some smarts added here...

Please expand on this. What exactly is triggering the error? That we landed back into your ~? If you have a small home folder this actually works fine as a fallback. I understand it's not ideal for your setup.

Seems like you're hitting a lot of edge cases here. I am more than happy to accept PRs, but I don't see many obvious/easy things to change that are going to be a win for everyone and I have a strong urge to keep this project as "dumb" as possible.

[zenspider]

I get that... I have a popular ruby project called "minitest" and people keep trying to make it not-so-mini... I'll ponder and work on a PR.