Correct way to handle buffers opened with TRAMP? Particularly when the buffers and underlying host are no longer available.

[trharmon0]

I saved a couple of Activities representing coding work on remote systems with buffers opened over TRAMP. The underlying host (and its buffers) are no longer available. Now, even with a TRAMP buffer and session cleanup via TRAMP's interactive util functions, activities-resume and a couple of other activities functions hang indefinitely and require a C-g to get Emacs back under control.

Curious if you have any advice on how this should be handled? It doesn't necessarily seem like a problem with the activities library so much as the usual silliness from TRAMP. But perhaps there's something we could do to recover from the activities side?

[alphapapa]

Hi,

Hm, that's a bit awkward, indeed. My first thought is that TRAMP is not timing out quickly enough, but the problem may not even be that simple, because I'm reminded of occasional issues I've noticed in which I have a TRAMP dired or file-backed buffer open that's pointing to an SFTP server, and when I call a command to switch to another buffer, and my completion framework wants to display metadata about it, it hangs while waiting for TRAMP to reestablish a connection to the server, which is quite annoying.

Anyway, if the TRAMP-backed buffers are in the activity's last-saved state, it seems to me that resetting the activity should remove such buffers from the activity, so resuming the activity shouldn't try to recreate the TRAMP-backed buffers. If the TRAMP-backed buffers are in the activity's default state, you probably need to kill the TRAMP-backed buffers and redefine the activity (C-u C-x C-a C-d) without them.

Please try those ideas and let me know if it helps. If the problem persists, we might need to deal with the windows' recent buffers lists, or something like that.

[trharmon0]

These "zombie" activities continue to cause issues. I'm unsure how to kill/clean/reset them. I'm unable to dired-style mark and kill them via activities-list. If I try to create a new one with the same name as an old problematic one that is not allowed. If I try to resume a known problematic one I can wait until the TRAMP timeout expires to get into the activity but then activities-kill hangs indefinitely.

I thought perhaps I could backdoor the process by going straight to the bookmarks backend and editing there but the problematic ones are not shown via list-bookmarks.

Thoughts?

[trharmon0]

I'm not sure where I got this impression but my understanding was that the activities were stored as bookmarks. They do not appear in ~/.emacs.d/bookmarks so I went looking elsewhere and found the variable =activities-activities= which appears to be where they are defined. Not an elisp expert but this data structure looks like an a-list? So maybe I can find a util function which will purge an a-list entry via some sort of regex on the number (ex: "#1=...")?

[trharmon0]

The simplest solution was:

(setq activities-activities nil)

[alphapapa]

@trharmon0

These "zombie" activities continue to cause issues. I'm unsure how to kill/clean/reset them.

Have you not seen the manual/readme? It clearly lists the command activities-discard, as well as explaining how to reset them.

As far as I can tell, you haven't tried the suggestions I made; unless you're willing to, I won't be able to help you.

[trharmon0]

No, I stopped at -kill. -discard did not jump out at me as relevant and I was on a deadline for some code that was being developed in an activity/tab that was having issues.

[alphapapa]

Ok, well, there is likely an issue here that needs to be improved, but in order to understand and fix it, it will need to be reproducible; so I'll need you to explain the problem in detail, step-by-step, starting from a just-started Emacs instance.

[alphapapa]

@trharmon0 I'm guessing that #133 will solve this problem for you. Would you be willing to try it and report back?

[trharmon0]

I just started to rebuild the set of activities today. Let me get back to you on this. Thx.