Re: [PATCH] * tramp-sh.el (tramp-optimize-remote-path): Add it.

[Michael Albinus]

Andrey Portnoy <aportnoy@fastmail.com> writes:

Hi Andrey,

> I've thought more about this and I can't shake the feeling that "nil
> tramp-remote-path = '(tramp-own-remote-path) with no checks" will be too
> confusing.

Understood. We don't need the nil value, indeed.

> As you say above, we'd be overloading nil tramp-remote-path to mean "use
> the remote path set by the remote host with no checks" on top of the
> existing meaning "make the 'base' remote path empty".
>
> How about the following:
>
> 1. We introduce a new variable tramp-optimize-remote-path with a default
>    value of t for backward compatibility (same as in my original patch).
>
> 2. We add a "fast path" to tramp-set-remote-path that skips the whole
>    "get/optimize/set" process when tramp-optimize-remote-path is non-nil
>    and tramp-remote-path is '(tramp-own-remote-path).
>    Alternatively, we keep the original behavior of tramp-set-remote-path
>    but add a new function tramp-maybe-set-remote-path that invokes
>    tramp-set-remote-path when we can't take the "fast path" as described
>    above.

As said I habe reservations to use several user options handling the
samr problem. Experience tells me, that people will use it unintendedly.

And think also about connection local variables. If we have several user
options in game, people must set them properly for different remote
hosts. Another can of worms.

I  believe, jst a special andling of '(tramp-own-remote-path) as value
of tramp-remote-path is sufficient.

> with no checks" by setting tramp-remote-path to '(tramp-own-remote-path)
> and by setting tramp-optimize-remote-path to nil. I have a feeling it's
> better to transfer control to the user by giving them an explicit option
> rather than introduce a tricky implicit behavior.

Using a special value in a user option is not a tricky implicit
bevaior. This is what Emacs and Tramp do all the days. It must be
documented properly, of ourse.

> I understand the value of keeping the API surface as small as possible,
> but in this case it feels worth it to expand it.

My proposal is already an expansion.

> Some users might want the ability to disable the path optimizations in
> cases other than '(tramp-own-remote-path), so it seems good to give them
> that option separately.

Some users might want this for 25 years ...

I iunderstand your docker exsmple, and we shall support this.

> I'm attaching two patches sketching out the alternatives in paragraph
> (2) above.
>
> What do you think?

You still focus on tramp-set-remote-path. As said in my last message, we
need also to touch tramp-get-re mote-path.

Have you tested (exec-path) with your patches in play? I didn't, but I
elieve we need to do something here as well.

Best regards, Michael.