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 <shipmi...@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 <shipmi...@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 <shipmi...@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
>>>
>>

Reply via email to