Re: can't see existing directory on remote machine... workaround

[ken <gebser@mousecar.com>]

On 10/10/20 5:00 AM, Michael Albinus wrote:
> ken <gebser@mousecar.com> writes:
>
> Hi Ken,
>>>> I found a workaround... I change the default, inserting "scp:" ... e.g.,
>>>> "/remo:~/dir/dir2/" -> "/scp:remo:~/dir/dir2/".  I doubt, however, that
>>>> this workaround will change the emacs code.
>>>>
>>>> "/remo:~/dir/dir2/"
>>> I don't know whether adding "/scp:" counts as a workaround. But for sure
>>> "/remo:~/dir/dir2/" is not remote directory, a leading connection method
>>> (like "scp") is mandatory.
>>>
>> Well, then it should have been put in place automatically by emacs and
>> it wasn't.
> "Emacs" doesn't put anything in place automatically. Which package do
> you have in mind, which shall "put in place" this automatically?
>
> IOW, could you pls give us a reproducible scenario, starting with
> "emacs -Q"?
>
> Best regards, Michael.
Hi, Michael,

When I said "automatically, I meant that, for instance, when I have a
remote file open and I do "C-x C-d", emacs "automatically" puts the
current directory into the minibuffer (so that it can be edited if
desired), and then I hit "Enter" to display the file listing for that
directory.  And the "current directory" here means the directory where
the file resides that was currently open.  In the same way, if I have a
remote file open and then do "C-x C-f", again emacs *automatically* puts
the current directory into the minibuffer (again, which can be edited if
desired), I type in the name of the file I want to open, hit "Enter",
and emacs opens a buffer for that file.  All this is great, fantastic,
and the way it should be.  It's so great, in fact, that I don't notice
anymore the *entire* contents of the prompt in the minibuffer, but just
the right-hand part of the minibuffer prompt relevant to the work I'm
doing at that moment.  It's worked that way for decades.  So frankly, I
don't remember, because it works so well, whether there was always the
"scp:" as part of the minibuffer prompt for remote files or not.  I
believe so, but that's going on very faint memory of when tramp was
first implemented in emacs decades ago and I wondered at and marveled
over its ability to seamlessly open and edit files on remote machines
pretty much in just the same way as if they were local files, this at a
time when with Windows you had to remember and specify whether a file
was on "A:" or "C:" or wherever, as if they were separate filesystems...
because, for MS, they were.  Not having to remember is great... but then
occasionally remembering is helpful.

As for "which package" provides this functionality, I don't know.  It
used to be a package called "tramp", which I'm sure you're quite
familiar with (being its Hauptaccoucher), but it appears all the tramp
functionality has been incorporated into emacs and so it's no longer a
separate package; "rpm -qa| grep -i tramp" returns nothing and I don't
see mention of "tramp" anymore in the dozens of emacs status messages
that go flying by when I do anything with remote files.  But I probably
missed the memo on that, so while I'd very much like to know, I can't say. 

It appears that the problem has fixed itself.  Since implementing my
workaround for that one file, emacs now automatically includes that
"scp:" in all the minibuffer prompts for remote files.  I don't know how
that could have happened, how that one small fix could propagate itself
to all subsequent instances, but my suspicion is that a recent version
update created a small corruption in my ".emacs.desktop", one which left
out that little "scp:" for one file and then all subsequent files and
directories until I put it back in, at which time it put it back in
again for all files and directories.  But that's just a blind guess
based on the chronology of the problem's occurrence.  Hopefully we won't
have to figure it out with certainty because the problem is now gone
forever.  But if it comes back, say, after a reboot or another version
update, and the workaround fails, then we take another look.

Thanks for your reply and your interest.
Regards,
ken