Perhaps I'm misunderstanding and I'm testing a few more cases. If I spawn a
shell buffer pointing to /ssh:deb12:., a virtual Linux machine on my mac, I
expect the bash shell prompt ansi sequence to also affect the default
directory and now I can see that's not the case but I think it should be.
Testing for matching host names doesn't seem like a good idea. Doesn't
cd-absolute respect remote files? I think so. But if we block by matching
host names, we never get the remote directory reported.

On Mon, Feb 10, 2025 at 9:47 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Ship Mints <shipmints@gmail.com> writes:
>
> Hi,
>
> > My desktop mac's local host name is tlok.local. I open a shell buffer
> > as "/ssh:tlok.local:/Users/shipmints/" and as I "cd" around, I expect
> > the remote file prefix "/ssh:tlok.local:" to be maintained. If the
> > host name component is used as a discriminator, I don't get that
> > benefit despite that there actually is an active ssh connection. I
> > think it should be respected all the time as the user asked for it
> > explicitly.
>
> I don't get it. If your default directory is
> "/ssh:tlok.local:/Users/shipmints/", (file-remote-p default-directory)
> always returns "/ssh:tlok.local:", and (file-remote-p default-directory
> 'host)
> always returns "tlok.local". In the shell buffer, you cannot go to
> another host.
>
> Please give me a step-by-step scenario, if I miss something.
>
> Best regards, Michael.
>