From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Mon, 19 Dec 2011 13:29:31 -0800 Message-ID: <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> References: <87wr9uuvn3.fsf@gmx.de><1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com><87bor5eyz0.fsf@gmx.de><88D1EF1166814B70B0E2CD052362AA72@us.oracle.com><87ehw0e7u0.fsf@gmx.de> <877h1sdzv0.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1324330218 12619 80.91.229.12 (19 Dec 2011 21:30:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2011 21:30:18 +0000 (UTC) Cc: 10319@debbugs.gnu.org To: "'Michael Albinus'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 19 22:30:14 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rckmj-0000Dp-R3 for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Dec 2011 22:30:14 +0100 Original-Received: from localhost ([::1]:47493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rckmj-0008Fi-Dc for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Dec 2011 16:30:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:51944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rckmg-0008Dz-13 for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2011 16:30:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rckmd-0005SK-Vm for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2011 16:30:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:44965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rckmd-0005S7-U7 for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2011 16:30:07 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RckoU-0008DZ-3g for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2011 16:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2011 21:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10319 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10319-submit@debbugs.gnu.org id=B10319.132433030031558 (code B ref 10319); Mon, 19 Dec 2011 21:32:02 +0000 Original-Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 21:31:40 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcko8-0008Cx-K2 for submit@debbugs.gnu.org; Mon, 19 Dec 2011 16:31:40 -0500 Original-Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcko6-0008Cq-Vk for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 16:31:39 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBJLTgJK015258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 21:29:43 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBJLTX4a002355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 21:29:33 GMT Original-Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBJLTXDV022866; Mon, 19 Dec 2011 15:29:33 -0600 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Dec 2011 13:29:32 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <877h1sdzv0.fsf@gmx.de> Thread-Index: Acy+k85yYRuh4ym4SFWg/PlfwaOsoAAAEbvA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4EEFACC7.00C0,ss=1,re=0.000,fgs=0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Mon, 19 Dec 2011 16:32:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:55075 Archived-At: > The second sentence means that a relative filename like > "/sudo::../../.." does not make sense, because it cannot > expand out of the "/sudo::" jail. So what are we trying to tell _users_ here? Is this what we are really trying to say? FILE must be an absolute file name. If so, what should we say happens if you nevertheless pass a relative file name? Return value is unspecified (could be nil or non-nil)? An error is raised? What should we tell users is the behavior? > > Something like this (but see my question about relative > > file names not working): > > > > Test whether FILE specifies a location on a remote system. > > A file is considered remote if accessing it is likely to > > be slower or less reliable than accessing local files. > > > > `file-remote-p' never opens a new remote connection. It can > > only reuse a connection that is already open. Relative file > > names do not work across remote connections (????). > > > > Return nil or a string identifying the remote connection > > (ideally a prefix of FILE). For example, the remote > > identification for filename "/user@host:/foo" could be > > "/user@host:". > > > > IDENTIFICATION specifies which part of the identification to > > return. IDENTIFICATION can be the symbol `method', > > `user', `host', or `localname'. Any other value is handled > > like nil and means to return the complete identification. > > The string returned for IDENTIFICATION `localname' can differ > > depending on whether there is an existing connection." > > > > If CONNECTED is non-nil, return an identification only > > if FILE is located on a remote system and a connection is > > established to that remote system. > > Sounds OK to me. From my point of view you could submit the > changed docstring. > > > We should also perhaps say what "the complete > > identification" is/means. IOW, when IDENTIFICATION is nil, > > what can we say about the return value? > > In that case, the returned string could make a local file > name remote. We could always offer to apply > (concat (file-remote-p "whatever") "local-file-name") > given that `concat' accepts nil as argument. Sorry, I just don't understand your reply to my question (what is the complete identification - what is returned if IDENTIFICATION is nil). Could you rephrase or elaborate? Thx - Drew