unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: Phil Sainty <psainty@orcon.net.nz>
Cc: 54606@debbugs.gnu.org
Subject: bug#54606: 27.1; next/previous image command in image-mode triggers tramp connections for all remote dired buffers
Date: Thu, 31 Mar 2022 11:47:41 +0200	[thread overview]
Message-ID: <875ynuh2rm.fsf@gmx.de> (raw)
In-Reply-To: <3947f11808243544dcdd4e4d2fde4922@webmail.orcon.net.nz> (Phil Sainty's message of "Mon, 28 Mar 2022 23:13:14 +1300")

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Phil Sainty <psainty@orcon.net.nz> writes:

Hi Phil,

> In 27.1 this code is in `image-next-file'.  In master it's now
> `image-mode--directory-buffers', but the relevant code looks
> the same:
>
>       ;; Find a dired buffer.
>       (dolist (buffer (buffer-list))
> 	(with-current-buffer buffer
> 	  (when (and (derived-mode-p 'dired-mode)
> 	             (equal (file-truename dir)
> 		            (file-truename default-directory)))
>
> That call to (file-truename default-directory) for each dired
> buffer can cause tramp to spin up for closed connections for
> entirely irrelevant dired buffers.

I've reproduced the problem. As said already (?), it is similar to
bug#54542. The solution there was to wrap the code in question by
let-binding non-essential to t, and to enhance Tramp to behave
accordingly.

The Tramp change is already in the master branch, and also in the just
released Tramp 2.5.2.3 on GNU ELPA. So I've applied the following change
in master:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 635 bytes --]

diff --git a/lisp/image-mode.el b/lisp/image-mode.el
index d7dfb4336b..69af538aa7 100644
--- a/lisp/image-mode.el
+++ b/lisp/image-mode.el
@@ -1196,8 +1196,9 @@ image-mode--directory-buffers
   "Return an alist of type/buffer for all \"parent\" buffers to image FILE.
 This is normally a list of Dired buffers, but can also be archive and
 tar mode buffers."
-  (let ((buffers nil)
-        (dir (file-name-directory file)))
+  (let* ((non-essential t) ; Do not block for remote buffers.
+         (buffers nil)
+         (dir (file-name-directory file)))
     (cond
      ((and (boundp 'tar-superior-buffer)
 	   tar-superior-buffer)

[-- Attachment #3: Type: text/plain, Size: 1598 bytes --]


This changes the behavior. Recipe:

- emacs -Q /ssh:detlef:Pictures/IMG_0040.JPG
- Disable Ethernet/WLAN connection
- Type 'n' in the image buffer.

If the last step happens shortly after disabling the connection, nothing
changes, and Emacs is blocked. This is because Emacs needs some seconds
to detect the new status of the respective Tramp process (‘exited
abnormally with code 255').

However, waiting 10 seconds or longer (in my case), typing 'n'
immediately returns with the message

--8<---------------cut here---------------start------------->8---
user-error: No next file in this directory
--8<---------------cut here---------------end--------------->8---

That sounds acceptable, isn't it?

It shall also help for other dired buffers with different, already
closed, Tramp connections.
>
> Can we put some guards in there to decide whether or not dir
> and default-directory are actually on the same host before
> comparing them via file-truename?

If you want to go *this* direction, there would be a simple change:

--8<---------------cut here---------------start------------->8---
	  (when (and (derived-mode-p 'dired-mode)
	             (equal (file-remote-p dir)
		            (file-remote-p default-directory))
	             (equal (file-truename dir)
		            (file-truename default-directory)))
--8<---------------cut here---------------end--------------->8---

file-remote-p doesn't do anything on wire.

> -Phil (who is simply testing (not (file-remote-p default-directory))
>        as an interim fix)

Best regards, Michael.

  parent reply	other threads:[~2022-03-31  9:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-28 10:13 bug#54606: 27.1; next/previous image command in image-mode triggers tramp connections for all remote dired buffers Phil Sainty
2022-03-29 13:03 ` Lars Ingebrigtsen
2022-03-29 13:09   ` Michael Albinus
2022-03-30 11:43     ` Phil Sainty
2022-03-30 11:51       ` Michael Albinus
2022-03-30 12:03       ` Lars Ingebrigtsen
2022-03-31  9:47 ` Michael Albinus [this message]
2022-03-31 11:41   ` Lars Ingebrigtsen
2022-03-31 18:09     ` Phil Sainty
2022-04-01  7:06       ` Michael Albinus
2022-04-02 13:02         ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875ynuh2rm.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=54606@debbugs.gnu.org \
    --cc=psainty@orcon.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).