From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: ken Newsgroups: gmane.emacs.help Subject: Re: can't see existing directory on remote machine... workaround Date: Sun, 11 Oct 2020 08:17:50 -0400 Message-ID: <5d5402b1-c492-5339-61f0-f55a0e96838a@mousecar.com> References: <976c9210-67fe-d3f6-ca17-9c1a33567a4f@mousecar.com> <87h7r4sjyc.fsf@gmx.de> <36b6f1d9-f5ae-688b-7839-b2ccaa3ac9b1@mousecar.com> <87mu0uh2vl.fsf@gmx.de> Reply-To: gebser@mousecar.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18413"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 11 14:18:23 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kRaIx-0004iX-6R for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 11 Oct 2020 14:18:23 +0200 Original-Received: from localhost ([::1]:52316 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kRaIw-0008LZ-9G for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 11 Oct 2020 08:18:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRaIV-0008LO-Fq for help-gnu-emacs@gnu.org; Sun, 11 Oct 2020 08:17:55 -0400 Original-Received: from mout.perfora.net ([74.208.4.197]:55985) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kRaIT-0006G0-1j for help-gnu-emacs@gnu.org; Sun, 11 Oct 2020 08:17:55 -0400 Original-Received: from [192.168.0.17] ([96.27.75.237]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MAxNa-1kbReM3g6W-009yGt for ; Sun, 11 Oct 2020 14:17:50 +0200 In-Reply-To: <87mu0uh2vl.fsf@gmx.de> Content-Language: en-US X-Provags-ID: V03:K1:EtjjY7X1Ph8ezjVWZeq9SpeiKKhhkK/au/tiZ52NiwcmzgMQknj L8JT9+2vnkFgxZF7tIV1rlWIFl2TgTR0fjP8/Oq7GfBhMxEEuZwL/OlCmqNDYtfIC9+G8Bn P0W3033jyGBk3rQIub1OR1Wid5E2tlsoXRDHZAkVCdfYBXxGHVHmi2tcRNGaxOUMpfvhoTX 7RMXfPi8q/KzOp+4EAQ/A== X-UI-Out-Filterresults: notjunk:1;V03:K0:exvhZ/zwFDU=:DEMw6rH03/gMZOrTeryIXc 334Tr06A2EdNWpDMIAJK7U/p4AoxQ0YBge2225vsFaCE1Wg62LKOlQxYvitoSy5D/Nuda66r+ xa/cPqtlSRMCfBfSmW39A4VrSWdLUybbkx5sXRCEcDVdJDUmcoH+mjqrzghAhSZlLmhH38K2l 86sE/v1RlvFIEJoaBAAYepr4N1wRhFrVW4jscjv00uuRr6aivJEHXS0X2jd+FjEsbAG2AyEwD tfbE87FTYXw13rb/IoRBcYSeFypMaRmGLJ7AMp2GsNZYyMq2/UD1LpA/Ym8P3y5Jl+bLailSj zweHaswZWNFToRu2kd7a4X5Yyp2ZVfLHhoHv14idvLyPDj17NQU1pvnCn9p3rjPiwvxm8x9Hk GjIyMI+Tjo7Vjms/jtSN1EPy3FRF81iujbgXQ915l8hSJKdNp5X2q2L1+HZUug811sLcuSIYq Rnh7v43UbqbTkWvNPE0l2WoY29nVgsn5MKGLjU+L8dENMWjIWRDdpJwCR68CRfiIHmOexLUSg 2eFkPUzfdWpLa/tDhvvkVn5zFpjgVAb4a2DAtKDoxwJukuNDaJL9JpzeyxdTfguiqEUVtpqEV KS5ZPLovZ7zzzPYkeK12gU41WJ2bNWEFd/mNXzV/LVd4GDVyjFvKf2Y9NzV2rSZBxx6R6/zea 86IevJ9F3EX7umGXyTBawwKYW/0gCc2bNRn/9ImlJfJSReONFYDNgi9HCQdQWZQinvaAXxxPe AK94V7AGirs4ltXz+FoQBj6zJDP6LwhU3GXmK5DhUiHSXd1WGTXZHLK1BJ1vxcQWQifxFDTU Received-SPF: none client-ip=74.208.4.197; envelope-from=gebser@mousecar.com; helo=mout.perfora.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/11 08:17:51 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:124427 Archived-At: On 10/10/20 5:00 AM, Michael Albinus wrote: > ken 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