I use pdf-tools for reading and recently started using bookmark+ and dired+ for navigating. Unfortunately these two great packages seems to conflict.

One of the issues I noticed was that the bookmark+ command for bookmarking a pdf location in a pdf-tools buffer didn’t work; it gave an empty buffer warning. Turns out bookmark+ creator Drew Adams had already suggested a workaround which I discovered here: https://emacs.stackexchange.com/questions/72786/bookmark-plus-and-pdf-tools-pdf-view-error

So that solved or at least patched that issue. But then I noticed that with dired+ installed and any fairly large pdf opened in pdf-tools, emacs will freeze if you attempt to do dired-jump or helm-find-files. Dired-jump without dired+ is not affected by the size of the pdf at all and just opens the underlying directory immediately. But with dired+ anything above about 1mb or so hangs it for quite a while, anything around 10mb or more just freezes it for minutes on end to the point that unless you want to go make yourself lunch and coffee, you will have to force kill emacs to keep working.

As a noob, non-techie, non-developer, I just wanted to ask, what is the right way of asking about possibly getting this issue fixed, because I love these two packages and would love to have both in working order, but obviously don’t have the coding know how to do it myself. Of course if anybody knows of a fix that’s already out there for this issue, I’d love to know about that as well.

  • 00-11@alien.topB
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    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.

    • jcdix@alien.topOPB
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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.

      • 00-11@alien.topB
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        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.

        • jcdix@alien.topOPB
          link
          fedilink
          English
          arrow-up
          1
          ·
          1 year ago

          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.

          • 00-11@alien.topB
            link
            fedilink
            English
            arrow-up
            1
            ·
            1 year ago

            Keep investigating. (I assume the problem doesn’t arise with just Helm and PDF-tools (i.e., without Dired+).)

            • jcdix@alien.topOPB
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              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.

              • 00-11@alien.topB
                link
                fedilink
                English
                arrow-up
                1
                ·
                1 year ago

                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).

                • jcdix@alien.topOPB
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  1 year ago

                  Sorry, last message here. I will follow up with diredp-send-bug-report. I will try your last suggestion.

                  Thanks!

            • jcdix@alien.topOPB
              link
              fedilink
              English
              arrow-up
              1
              ·
              1 year ago

              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!