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