Preview only in temp buffer like consult

[lynnux]

Thanks for this useful package! But I noticed that the previewed files are actually opened and they are all in recentf buffer list. If the preview works like consult's preview, it should be awesome! Sorry for my poor english.

[trembel]

I agree to this, similar to what is done in https://github.com/mac230/eim-peep-dired/ would also work for me:

(defun eim-peep-dired-next-file ()
  (interactive)
  (setq curr-dired (buffer-name))
  (dired-next-line 1)
  (setq new-buf (dired-copy-filename-as-kill))
  (eim-peep-dired-display-file-other-window)
  (switch-to-buffer-other-window next-buf)
  (eimp-fit-image-to-window-2)
  (run-with-timer 0.5 nil 'set-buffer-modified-p nil)
  (run-with-timer 0.5 nil 'switch-to-buffer-other-window curr-dired))

(defun eim-peep-dired-prev-file ()
  (interactive)
  (setq curr-dired (buffer-name))
  (dired-previous-line 1)
  (setq new-buf (dired-copy-filename-as-kill))
  (eim-peep-dired-display-file-other-window)
  (switch-to-buffer-other-window next-buf)
  (eimp-fit-image-to-window-2)
  (run-with-timer 0.5 nil 'set-buffer-modified-p nil)
  (run-with-timer 0.5 nil 'switch-to-buffer-other-window curr-dired))

[protesilaos]

Hello folks!

Sorry for being slow to respond. I did not have reliable Internet access. Now I do and am back in action.

This is a topic I want to understand better. Namely, what exactly registers the previews in the list of recent files.

We discussed this with Karthik Chikmagalur and I made this suggestion: @.***%3E>

Maybe that is enough for our purposes?

-- Protesilaos Stavrou https://protesilaos.com

[juergenhoetzel]

Thanks for this useful package! But I noticed that the previewed files are actually opened and they are all in recentf buffer list. If the preview works like consult's preview, it should be awesome! Sorry for my poor english.

To prevent the recentf-list from being overloaded with a lot of preview files I came up with the following hacky recentf-exclude predicate:

(use-package dired-preview
  :config (add-to-list  'recentf-exclude (lambda (file-name)
                       (equal file-name (car (timer--args dired-preview--timer))))))

It checks if the file-name was opened via the preview timer.

Unfortunately I can't find a simpler way to check this via simpler predicate that doesn't use dired-preview internals.

[protesilaos]

From: Jürgen Hötzel @.***> Date: Sun, 21 Apr 2024 06:55:57 -0700

Thanks for this useful package! But I noticed that the previewed files are actually opened and they are all in recentf buffer list. If the preview works like consult's preview, it should be awesome! Sorry for my poor english.

To prevent the recentf-list from being overloaded with a lot of preview files I came up with the following hacky recentf-exclude filter:

[... 8 lines elided]

Unfortunately I can't find a simpler way to check this via simpler predicate.

I was working on a refactoring of this code base, which includes a way to inhibit recentf from tracking previews. We do it by wrapping our "get buffer" code in this:

(cl-letf (((symbol-function 'recentf-track-closed-file) #'ignore))
  ...)

Does this work for you?

Note that the changes are still a work-in-progress.

-- Protesilaos Stavrou https://protesilaos.com

[juergenhoetzel]

(cl-letf (((symbol-function 'recentf-track-closed-file) #'ignore)) ...) Does this work for you?

Yes :+1: when changing to recentf-track-opened-file. See #12

[protesilaos]

Previews are no longer tracked by recentf. We can safely close this now. Thank you!

[AsuraHeap]

Hello, would it be possible to reopen this? I have recentf-mode set to nil and still find that the previewed files are opened and remain in the buffer list. Additionally, previewed folders open dired buffers that remain.

I am using emac 29.3 and the version of dired-preview from gnu-elpa (i.e. 0.2.0).

[protesilaos]

From: AsuraHeap @.***> Date: Sun, 12 May 2024 17:10:51 -0700

Hello, would it be possible to reopen this?

Yes, sure!

I have recentf-mode set to nil and still find that the previewed files are opened and remain in the buffer list.

Okay, I will need to check this.

Additionally, previewed folders open dired buffers that remain.

I cannot reproduce this. We start killing buffers once their cumulative size is above the dired-preview--buffers-threshold. Maybe your buffers are below that?

By the way, this is the code for that variable and I think making it a user option is helpful:

;; TODO 2023-07-07: This can become a user option, but let's keep it
;; simple for now.  We need to be sure this is always doing the right
;; thing.
(defvar dired-preview--buffers-threshold (* 1000 1024)
  "Maximum cumulative buffer size of previews.
When the accumulated preview buffers exceed this number and
`dired-preview--kill-buffers' is called, it will kill buffers
until it drops below this number.")

-- Protesilaos Stavrou https://protesilaos.com

[AsuraHeap]

Thank you! I may not fully understand how the package is meant to function. After scrolling aimlessly through directories I end up with over 200 buffers. The bottom portion of the buffer list looks like this: Would this be expected?

As an aside, using the < and > keys for the commands dired-prev-dirline and dired-next-dirline respectively fails to bring up the preview.

[protesilaos]

From: AsuraHeap @.***> Date: Mon, 13 May 2024 18:14:12 -0700

Thank you! I may not fully understand how the package is meant to function. After scrolling aimlessly through directories I end up with over 200 buffers. The bottom portion of the buffer list looks like this: Would this be expected?

This part is by design. Basically, we keep the buffers open while you are in Dired because as you scroll back you may want to preview them again.

The collected buffers are killed once you exit Dired.

About the recentf-mode, I have been using it since your original comment and I notice that I do not get anything there. Could it be a configuration issue?

As an aside, using the < and > keys for the commands dired-prev-dirline and dired-next-dirline respectively fails to bring up the preview.

Fine, we can add those to the dired-preview-trigger-commands. You can send a pull request, if you want. Otherwise, I will do it.

-- Protesilaos Stavrou https://protesilaos.com