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.