Re: No longer accessible host paths

[Michael Albinus]

JD Smith <address@hidden> writes:

Hi,

> Thanks, tried this in the new version.  C-u M-x
> tramp-reload-these-files simply complains about no target and aborts.

I guess you have called `tramp-rename-these-files' on a local buffer, yes?
It is a user-error. And this is intended: `tramp-rename-these-files'
works only if you are visiting a remote buffer. Otherwise, you shall
call `tramp-rename-files'.

This is our old discussion about having one command, or two. I've
extended the error message, advising `tramp-rename-files'.

>     I understand that your use case doen't expect to change the file
>     name. But other people might have different preferences, and I
>     want to be prepared.
>
> I mean _substitute_ a y-or-n for the prompt.  I tried the C-g method
> (which is like selecting “no”), and that works, leaving some buffers
> behind on an ala carte basis.
>
> But I still maintain a random prompt saying "Set Visited File:
> /method:host:/common/path" is going to be *very* confusing to people.
> It still confuses me honestly.  To understand what you are being asked
> (and why), you have to notice that the current buffer changed (if it
> did), and you may have many windows which means only one of them
> changed.  And the prompt doesn’t mention at all *which* file you are
> setting the visited filename for, only the new host and directory path
> *which is the same for all files being changed* (for a reload-these
> anyway).  So you have to somehow infer that by looking for a window
> with a potential active remote-file-visiting buffer.

Understood. I have rewritten the 2nd prompt machinery to give you a
yes/no/all/none/edit choice (shamelessly stolen from ´dired-query').

> And here’s the workflow I wish I had:
>
> * Visiting File [/ssh:oldhost:/path/to/]
> * M-x tramp-rename-these-files,
> * “Change Tramp connection in 5 buffers `/ssh:oldhost:/path/to/‘:
>   /ssh/oldhost:/path/to”
> * edit this to be "/ssh:newhost:/path/another/“ [Ret] (no window
>   buffers change…)
> * Message: “Tramp connection changed in 5 buffers to
>   /ssh:newhost:/path/to/"
>
> All of the complexity to me comes because the current command tries to
> overload two very different actions: 1) change method/host/common
> directory path and 2) change the actual filename.  The latter isn’t
> really related to the thrust of this command, in my opinion.  What
> filename changes would be precipitated by a changing network
> circumstance?  And if you want to rename the file (not alter its
> method/host/directory path), you can simply C-x C-w after fixing up
> the host & directory paths.

Before I explain in length: could you pls try the new code? I hope it is
self-explanary.

> Anyway, if you disagree entirely about this I’ll drop it, I just know
> in 2 weeks when I need to reach for this command, I’ll still be
> baffled by that 2nd prompt :).

NoNoNo !!!

I'm the developer, and usually I know what I'm written, and what to
enter in the minibuffer prompt. Therefore, I don't count for final
decision on UI.

I'm very depending on your (and other people) feedback about usefulness.

>         I think of a directory name requirement as
>         /method:host:/you/need/something/here.  But /method:host:
>         works for either.  I’m asking should /method:host also work
>         for source and/or target?  Possibly not since it’s not yet a
>         confirmed host.
>
>     You see me still inquiring. Use "/method:host:" instead, and if
>     you dislike default expansion, use "/method:host:/". I don't see
>     how it limits you.
>
> Not a limitation just a confusion.  Maybe a gentle reminder in the
> docs here that a path with nothing past the final colon constitutes a
> default directory on the host.

I haven't touched the doc today. Maybe you could provide some phrases,
how it would read better?

> JD

Best regards, Michael.