David Karr <firstname.lastname@example.org> writes:
> So, it seems like there's something about my process of creating shell
> buffers, which if done before the first tramp connection, makes tramp
> time out. I don't know what information tramp caches. It's possible
> that in the last scenario, if I then tried a tramp connection to a
> different host, that would fail, but I'm just guessing.
OK, that seems to be it.
> I create shell buffers using a couple of very small packages that I
> wrote decades ago, which I haven't had any issues with since. They
> manage a "ring" of shell buffers which I can either step through, or
> search for a particular one by its current directory. I'll attach
> them, if there's a clue there. Reading the file comment for
> "cycle-shell.el", I think I must have simplified it slightly after I
> wrote that comment, because I don't depend on a "shell-for-cycle"
> package anymore.
I've skimmed only shortly over the packages. However, you seem to create
shell buffers premature, before calling `shell'. So that function
expects, that the shell buffer is already prepared properly. But it
isn't I guess, `shell' does something more when creating a new buffer.
So I recommend to let `shell' do everything it believes what should be
done creating a buffer. You might debug your functions to see where they
block. And for your functionality, adding shell buffers to a ring, you
could add yourself into `shell-mode-hook', which seems to be the proper
I was thinking that I haven't really looked at this code for a very long time and might not be able to figure out how to make this happen, but I decided to give it a try, and I noticed in the doc for the "shell" function that it can take a prefix argument for the name of the buffer to use, instead of the default. That might be a better way to do this that might make it more compatible with tramp. I'll see if I can figure this out.
Before I noticed this, I had tried sending a request for help on this to gnu.emacs.help, but I got crickets.
Sorry that I cannot say too much about. Starting by tomorrow, I'll be
almost offline for some days.
Best regards, Michael.