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

[Juri Linkov]

>> Additionally to these changes, I also added canceling the previous timer
>> before starting a new timer to avoid several simultaneously started timers.
>> This improved responsiveness in non-remote case.  In remote case it helps
>> a little too, but still needs the lock for extremely slow connections.
>
> Why cancelling the *previous* timer? It has done already part of the
> job, so I would expect it will finish faster than a newly started timer.

Actually, the previous timer has not done any job, it's just waiting
for idle time to call the timer function that will do the job.
If a previous timer function (not timer) is stuck in file-readable-p,
this is a separate case for slow connections that is handled
by the lock in the timer function.

>> Here is a complete patch (BTW, I'm not sure if the check for file-remote-p
>> can be removed now):
>
> Yes. file-readable-p has performed already a remote operation (it runs
> "test -r <filename>"), so a test file-remote-p doesn't make sense.

But maybe using the image data from the buffer is much faster to display
the image (image data was already inserted to the image buffer by previous
remote file-reading operation), than to read the image data from the
remote file again by internal image-displaying functions.

> You haven't protected the timer function against the
> remote-file-error. Are you sure it cannot happen?

There is no need to protect the whole timer function
that doesn't use remote calls, so I protected only the
image-toggle-display-image call in the timer function.