Is there any harm if people who want to achieve what I outlined bind tramp-show-ad-hoc-proxies to non-nil? If that works in the way I suggest, why not recommend it?

On Sat, Feb 15, 2025 at 7:37 AM Michael Albinus <michael.albinus@gmx.de> wrote:
Ship Mints <shipmints@gmail.com> writes:

Hi,

> Hmm. I prefer storing the fully-qualified multi-hop file name in the
> bookmark itself. I share my bookmarks across machines which all have
> identically structured file systems, identical ssh configurations,
> identical "production" Emacs configs, and I expect my bookmarks to
> load without having to copy over another file. I will occasionally
> share a bookmark snippet with someone else and expect it to work
> (these people have similar set ups--assuming they follow the
> configuration guidelines).

The crucial point is tramp-default-proxies-alist. If
tramp-save-ad-hoc-proxies is non-nil, an updated version of that user
option is saved in your ~/.emacs file, including ad-hoc definitions.

And if you share .emacs like you do it with your bookmarks, there is no pain.

> Can we take a look at fully-qualified file name reconstruction?

There is a reason that ad-hoc multi-hop file names are called ad-hoc:
they are ad-hoc, cand not designed to survive an Emacs session.

For example, Tramp supports a use case (requested by Tramp users), where
a container with the very same name exists @work on a remote machine,
and @home on another remote machine. Tramp supports this scenario, you
can always access this container as "docker:container-name:". See
section "6.4.1 Using different proxies for the same destination" in the
Tramp manual. If the extended multi-hop file name would be saved in your
bookmarks (or recentf) file, this doesn't work.

Best regards, Michael.