From: Michael Albinus <michael.albinus@gmx.de>
To: ken <gebser@mousecar.com>
Cc: help-gnu-emacs@gnu.org
Subject: Re: can't see existing directory on remote machine... workaround
Date: Sun, 11 Oct 2020 16:00:02 +0200 [thread overview]
Message-ID: <87ft6koobh.fsf@gmx.de> (raw)
In-Reply-To: <5d5402b1-c492-5339-61f0-f55a0e96838a@mousecar.com> (ken's message of "Sun, 11 Oct 2020 08:17:50 -0400")
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.
prev parent reply other threads:[~2020-10-11 14:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 15:17 can't see existing directory on remote machine ken
2020-10-08 15:43 ` can't see existing directory on remote machine... workaround ken
2020-10-08 17:31 ` Michael Albinus
2020-10-09 18:19 ` ken
2020-10-10 9:00 ` Michael Albinus
2020-10-11 12:17 ` ken
2020-10-11 14:00 ` Michael Albinus [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ft6koobh.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=gebser@mousecar.com \
--cc=help-gnu-emacs@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.