After that, on resizing the window with image or the whole frame
Emacs stalls. The hang occurred from 10:29 till 10:35 (as seen
from timestamps in attached file) when I interrupted it with C-g.
PS Interrupting was not feasible on some occasions so I tried to
debug with (tramp-debug-to-file t). Anyhow, if it is
self-contained bug report file, it is a convenient way to email
necessary information, compared to saving the buffers.
and so on. Obviously, the idle timer image-fit-to-window is called, and
it doesn't finish within the image-auto-resize-on-window-resize time
frame (1 second). So the next idle timer is called on top, which also
doesn't finish in time, etc pp. This confuses Tramp.
I have prepared a patch for tramp-sh.el (appended), which shall prevent
this scenario. Could you pls try, whether this patch fixes your problem?
> I tried to reproduce the same steps and seems like it did not fix the
In which way it isn't fixed? My local tests have shown, that an image in
a remote buffer is resized, after changing window size. Doesn't this
happen to you?
> Attaching debug file and tramp-sh.el after applying the patch.
> Also I get the messages:
> Error running timer ‘image-fit-to-window’: (file-error "Forbidden
> reentrant call of Tramp")
> File error: Forbidden reentrant call of Tramp [5 times]
This is expected, I see them as well. My patch changes Tramp such a way,
that it prevents timers to run remote commands when they shouldn't. The
error message is the result of the patch; guilty timers must be adapted
to avoid this case.
Until now, they didn't care, and so they have blocked Emacs like in your case.
> I tried the new version and emacs does not hang. Also the resizing has
> become much faster (I suspect I have the same connection speed and it
> was very slow with your initial patch).
Thanks for the reply. I haven't done something special wrt performance
in my patch. However, my final patch uses a different approach; maybe
this has also some performance improvement consequences :-)
> However I do see "Error running timer..." messages and I occasionally
> get unexpected ... changed on disk; really edit buffer? prompt.
In Emacs' etc/NEWS file I've dropped the note
If such an error occurs, please report this as bug via 'M-x report-emacs-bug'.
Until it is solved you could ignore such errors by performing
This setting might be helpful for the time being. The bug report shall
still be submitted, and I'll inspect also your debug output later on,
when time permits.
> I am aware that the code for image display is well outside of TRAMP
> and separate report should be submitted. I am attaching a tramp debug
> file I got when opening the image in a clean session (no .emacs conf)
> and playing with resizing it. On the last resize I got buffer edit
> prompt. Let me know if this has to be submitted to general Emacs bug
> reporting list.
Yes, I believe it fits all together. But since this is not my game
field, a bug report might involve other Emacs developers for fixing it.
>> I am aware that the code for image display is well outside of TRAMP
>> and separate report should be submitted. I am attaching a tramp debug
>> file I got when opening the image in a clean session (no .emacs conf)
>> and playing with resizing it. On the last resize I got buffer edit
>> prompt. Let me know if this has to be submitted to general Emacs bug
>> reporting list.
> Yes, I believe it fits all together. But since this is not my game
> field, a bug report might involve other Emacs developers for fixing it.
Just a wild guess: does the appended patch to image-mode.el helps?