A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Try commenting out the definition of dired-jump in dired+.el, and see if that makes a difference. (The main difference is that the Dired+ version opens the directory listing with the destination, it it's hidden.)
Then M-x diredp-send-bug-report. Provide your Emacs release, platform etc. info, and preferably a recipe starting from emacs -Q. Thx.
Maybe check also with the pdf-tools maintainer.
Thanks for your suggestion. I still had the same issue. I notice that helm-commands called when in the pdf-tools buffer also freeze, not just the dired-jump (C-x C-j) command. The helm buffer opens when you do helm find files or helm locate etc. But then when you move down and try to open a folder, emacs freezes. It doesn't freeze if you just open a file. So it is any command that wants to get you to a dired buffer from the pdf-tools-buffer. I.e. C-x d freezes, helm-find-files, helm-locate - all freeze if you use them to try to open a dired buffer. But helm freezing doesn't occur in a pdf-tools buffer when dired+ is not loaded, meaning dired+ is definitely what causes it. But in a non-pdf-tools buffer with dired+ loaded helm works fine. So it has something to do with pdf-tools and dired+ being in conflict.
So the problem is apparently not with Dired+'s dired-jump, but something else in Dired+. But if you can repro the problem easily using dired-jump, maybe try M-x debug-on-entry dired-jump and step through the debugger to see what seems to be the problem - with emacs -Q and just Dired+ and PDF-tools loaded. But instead of trying to debug it here, M-x diredp-send-bug-report, as mentioned above.
Thanks so much. I will try doing that some time soon. I've never tried debugging before but it's a good chance to learn how so I think this will be kind of fun.
d in the debugger steps into evaluating the current sexp to be evaluated.
c steps past it, i.e., it evaluates it without digging into the steps of evaluating it.
So you can use c to skip over steps that you don't want to get into in to detail, and use d otherwise.
I'll try that. Thanks. I just tried your suggestion of emacs -Q and that revealed something interesting, which is that with just pdf-tools and dired+ loaded, jumping to dired works fine. But then I installed and activated helm and then the problem of freezing appears. So it seems to have something to do with using these 3 packages together.
Keep investigating. (I assume the problem doesn't arise with just Helm and PDF-tools (i.e., without Dired+).)
I will keep at it. No, I've used helm and pdf-tools together for years, and I only had the problem just recently when I started using dired+. Anyway, I'll do that "diredp-send-bug-report" you suggested as follow up, and maybe even open an issue with helm. I recently reported a helm issue and they literally fixed it by the next day. I was so happily surprised that I am now a patreon supporter!
I tried debug-on-entry before calling dired-jump and didn't see any errors. I am not sure if I know what I am looking at when I drill down to the active variables. As I mentioned, it is not completely frozen, it is just taking a very long time when there is a large pdf in the buffer, so it might not throw an error.
But I did do another test which seems to rule out helm in itself as the problem. In an emacs with no packages except pdf-tools and dired+ the same problem occurs in ido-mode, but NOT when simply using the default basic completion style. Ido-mode offers completion candidates, but just as with helm, when you try to go to a dired buffer, emacs hangs. With no dired+, the same operation in ido-mode works smoothly. So it seems the issue is being caused by dired+ in combination with not just helm, but ido completion. I could try other completion packages, I suppose, to see if those also have the same problem.
As I said, please follow up off list, using M-x diredp-send-bug-report. You haven't even mentioned your platform etc.
One quick thing to try would be to evaluate this, to see if the extra font-locking is the problem: (remove-hook 'dired-mode-hook 'diredp--set-up-font-locking).
Sorry, last message here. I will follow up with diredp-send-bug-report. I will try your last suggestion.
Thanks!
I will also do what you suggest and maybe open an issue with pdf-tools.
I am a layperson, but the problem seems to be that the kind of buffer variable pdf tool creates doesn't work if the files are big with whatever functions dired+ uses to handle those buffers whereas the functions for "go to dired buffer from pdf-tools buffer" that get called without dired+ installed do handle the pdf-tool buffers. So yeah, that could be just as easily be a problem either with the way pfd-tools creates the buffers or with how dired+ handles them. Dired+ works fine with everything else when jumping to dired.
Anyway, that was the thought process of a former English major.