Re: Tramp connection status with connection sharing

[Ship Mints]

Sorry for the noisy messages. It's Saturday and God knows I have the day off.

In the end, it was ansi-osc-directory-tracker resetting default-directory without regard to the shell being in Tramp-space.

I advised ansi-osc-directory-tracker to manipulate the default-directory to keep it in Tramp-space. It's a bit of a circuitous thing because ansi-osc-directory-tracker has no easy way to know if the buffer is a Tramp buffer. I can't use with-connection-local-variables as-is since it depends on default-directory which isn't in Tramp-space. And there are no buffer locals set directly by Tramp to test a shell buffer being Tramped (were there ever? should there be at least one little tiny one?).

Without either, in a shell-mode-hook, if a Tramp file, I squirreled away a copy of a Tramp vec from (tramp-dissect-file-name default-directory 'nodefault) in a buffer local. Inside ansi-osc-directory-tracker I can reconstruct a Tramp-space default-directory as

(when squirreled-vec

  (setq default-directory

    (tramp-make-tramp-file-name squirreled-vec default-directory)))

(I don't really call it a squirrel--it's more like a rat). Storing the vec is convenient vs. just a flag for I'd have to go make a vec anyway.

My mystery is solved for now. But people who use "modern" ansi shell directory tracking may find this issue in the future.

I'm all ears for a better solution that doesn't involve shell-hook trickery. If this kind of thing is to be fixed in Emacs core, it could be in shell-mode proper so no hook required. Would either need a Tramp local or shell-mode can just do what I did.

Other approaches?

-Stephane

On Sat, Feb 8, 2025 at 2:36 PM Ship Mints <shipmints@gmail.com> wrote:

More details. On the originating Emacs the following snippet reports what it should but on the sister Emacs it returns nil.

      (with-connection-local-variables
       (message "%S" (pp (buffer-local-value 'connection-local-variables-alist (current-buffer)))))

On Sat, Feb 8, 2025 at 2:32 PM Ship Mints <shipmints@gmail.com> wrote:

Okay, so it's a combination of both issues. The default-directory does indeed remain "remote" on the originating Emacs session but in sister sessions it reverts to the local form. Something I'm doing wrong?

On Sat, Feb 8, 2025 at 2:29 PM Ship Mints <shipmints@gmail.com> wrote:

Turns out this is a different issue.

A remote file name such as /ssh:tlok.local:/Users/shipmints/ opens a shell with ssh just fine. BUT the buffer's default-directory is set to /Users/shipmints and does not retain its remote form. That causes file-remote-p to think it's a local directory (which it is). But the buffer remains under Tramp management, so it's a bit wonky. Perhaps there's a better way to ask if a connection is alive for the buffer.

Checking into this deeper, it looks like comint's ansi-osc-directory-tracker resets default-directory and might need some assistance to know it's in a buffer under Tramp management. It simply calls cd-absolute which knows nothing of the originating Tramp remote file format.

I will try advising ansi-osc-directory-tracker, and if that works, perhaps I'll submit a patch to make a permanent change.

Unless someone else has better ideas on how to handle this? It doesn't seem like I could be the first to notice this issue considering how widely used Tramp is.

-Stephane

On Sat, Feb 8, 2025 at 1:28 PM Ship Mints <shipmints@gmail.com> wrote:

This form reports t only on the Emacs instance where the Tramp connection was established but not in sister Emacs sessions that share the connection.

    (file-remote-p default-directory nil 'connected)

Perhaps I'm doing something wrong but I expected this to work.

-Stephane