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