I decided to try something else before I tried going through that painful process.
I took your previous diagnostic to the next level by simply running "emacs" and then trying the ssh path. That worked. I then brought down my main Emacs window that I start from a shortcut, started it up, and then without doing anything else, I tried the ssh path. It worked. I then brought it down again and brought it back up, and then did what I always do as my first step after starting Emacs, which is creating a shell buffer, and then trying the ssh path. That timed out. I then bounced it again, tried the ssh path, which worked, then created a shell buffer, which worked, and then I deleted the buffer that I got from ssh and tried the ssh path again, and it worked. I then did the same steps, and adding an ssh path to a different file in that same remote directory, and that also worked. I've tried these scenarios multiple times, and they are repeatable. 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. 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. On Mon, Mar 6, 2023 at 12:31 AM Michael Albinus <michael.albi...@gmx.de> wrote: > David Karr <davidmichaelk...@gmail.com> writes: > > Hi David, > > > Ok, that also worked. I guess that means there's something in my . > > emacs or loaded packages that is conflicting with this? > > > > I guess I can attach my .emacs file, which has been evolving literally > > over decades without my really knowing what I'm doing. I also went > > into "Manage Packages", copied the text out of that list, and flushed > > all the "available" lines, leaving the ones that are installed or > > dependencies. > > I've checked shortly your .emacs and the installed packages, but there's > nothing obvious preventing Tramp to work. > > So I recommend bisecting. Deactivate all installed packages, for example > by "chmod 000 ~/.emacs.d/elpa/*". Comment half of your .emacs, and start > Emacs loading a remote file, again. > > If it works, uncomment the commented part of your .emacs, and > comment the other part. Start again. > > If it doesn't work, continue bisecting the active part of your .emacs. > > If there's nothing in your .emacs, activate one package after the other > in ~/.emacs.d/elpa, and check whether Tramp works. > > Something like this. > > Best regards, Michael. >
buffer-cycle.el
Description: Binary data
cycle-shell.el
Description: Binary data
