Subject: Re: bug#45256: Viewing images over network using TRAMP (errors and unexpected prompts)

From: Michael Albinus <[email-masked]>
Date: Thu, 17 Dec 2020 09:44:01 +0100

Juri Linkov <[email-masked]> writes:

Hi Juri,

>> From my pov, image-fit-to-window must be hardened in order to avoid this
>> reentrant call. Maybe an internal lock at entry, which is honored by
>> every next call until the lock is removed.
>
> The simplest solution is just to increase the number of seconds
> in the user option 'image-auto-resize-on-window-resize'
> proportionally to network latency.

That's a global variable, right? So you would also delay resizing of
images located locally.

> Locking could be implemented as well.  How would be better to do this?
> Maybe by using a buffer-local variable?

Yes. Something like

--8<---------------cut here---------------start------------->8---
(defvar image-fit-to-window-lock nil
  "Lock for `image-fit-to-window' timer."

(defun image-fit-to-window (window)
  "..."
  (unless image-fit-to-window-lock
    (unwind-protect
	(progn
	  (setq-local image-fit-to-window-lock t)
	  ...)
      (setq image-fit-to-window-lock nil))))
--8<---------------cut here---------------end--------------->8---

There's also another thread. When image-fit-to-window is called from
Emacs the first time, there could also be a running Tramp operation,
which would be disturbed. See the recent discussion about "Tramp and
timers" in the emacs-devel ML. Tramp would detect this situation, and
fire the (new) error remote-file-error. This must also be handled, like

--8<---------------cut here---------------start------------->8---
(defun image-fit-to-window (window)
  "..."
  (ignore-error 'remote-file-error
    ...))
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.