bug#31489: 25.3; Dired unable to open directory "/ssh:example.com"

[Michael Albinus <michael.albinus@gmx.de>]

Christoph Michelbach <michelbach94@gmail.com> writes:

Hi Christoph,

> On Sat, 2018-05-19 at 20:10 +0200, Michael Albinus wrote:
>> > After applying your patch, I can enter the directory with the SSH
>> > resource name by hitting enter on it if and only if I start at "/:".
>> Of course. Otherwise, you would try to open "/ssh:example.com:", which is
>> a Tramp file name.
>
> Yes, but that's only because of how dired-find-file works (or the
> functions called by it). The user would expect a dired buffer of the
> external resource to be opened if tramp files were displayed in the
> dired buffer for "/" and they actually hit return on a tramp file. But
> they're not, so the user does not hit return on a tramp file. They hit
> return on a directory which is part of their local (V)FS. When the
> user hits return on some directory, they expect that directory to be
> opened. In the current implementation of dired, this is not the case.

I don't see how this could be avoided. Of course, dired could quote any
directory name with "/:" when opening a directory with a file name
dedicated to Tramp (or another file name handling library). But this
would discard *any* file name handlers in this subdirectory, including
something like uncrompressing files, as jka-compr does, or decrypting
files, whis is performed by epa.

> From the user's perspective, these are separate bugs:
>
> 1. The user is unable to access some directories by entering their paths.
> 2. Hitting return on a directory does not load the directory.
>
> If the user has to enter a path different from the actual path to
> avoid loading an external resource, that's perfectly acceptable. At
> some point, what the user means by their input has to be clarified and
> if they enter a location, disambiguating it is their job. But if the
> user hits enter on a directory, they just want that directory to be
> loaded. The function called upon hitting return should take care of
> disambiguation.

You haven't answered my question: Could you live w/o Tramp, and set
tramp-mode to nil? Or do you want still use Tramp, and I shall extend
Tramp with an "exclude file names" feature?

Both variants would be a solution for this.

Best regards, Michael.