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

[Michael Albinus]

ken <gebser@mousecar.com> writes:

> Hi, Michael,

Hi Ken,

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

And this shall be still the case. There is a buffer-local variable
default-directory, which is responsible for all this behaviour. If it
isn't changed accidently, it still shall work this way.

> 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

What I nice word :-) However, the Hauptaccouchewr is still Kai
Grossjohann. I'm just the maintainer.

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

Tramp still exists outside Emacs. And you can upgrade to the recent
version via GNU ELPA.

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

Yes, and that's why I have asked whether it is reproducible. To all of
my best knowledge, Tramp does not corrupt the default-directory
variable. So I would be grateful if you could show us a recipe for this
problem.

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

Yes, please.

> Thanks for your reply and your interest.
> Regards,
> ken

Best regards, Michael.