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.