[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christoph Michelbach
Subject: bug#31489: 25.3; Dired unable to open directory "/ssh:example.com"
Date: Sun, 20 May 2018 20:12:12 +0200

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]