From unknown Sun Aug 17 09:09:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#10319 <10319@debbugs.gnu.org> To: bug#10319 <10319@debbugs.gnu.org> Subject: Status: 24.0.92; doc string of `file-remote-p' Reply-To: bug#10319 <10319@debbugs.gnu.org> Date: Sun, 17 Aug 2025 16:09:02 +0000 retitle 10319 24.0.92; doc string of `file-remote-p' reassign 10319 emacs submitter 10319 "Drew Adams" severity 10319 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 17 21:19:38 2011 Received: (at submit) by debbugs.gnu.org; 18 Dec 2011 02:19:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rc6Li-0005cF-4L for submit@debbugs.gnu.org; Sat, 17 Dec 2011 21:19:38 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rc6Lf-0005bz-Nk for submit@debbugs.gnu.org; Sat, 17 Dec 2011 21:19:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rc6Jy-000886-Gf for submit@debbugs.gnu.org; Sat, 17 Dec 2011 21:17:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:36724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rc6Jy-000880-FB for submit@debbugs.gnu.org; Sat, 17 Dec 2011 21:17:50 -0500 Received: from eggs.gnu.org ([140.186.70.92]:48073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rc6Jx-0008NE-G0 for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2011 21:17:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rc6Jw-00087o-H5 for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2011 21:17:49 -0500 Received: from rcsinet15.oracle.com ([148.87.113.117]:55412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rc6Jw-00087j-8s for bug-gnu-emacs@gnu.org; Sat, 17 Dec 2011 21:17:48 -0500 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 pBI2Hj8m008667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Dec 2011 02:17:46 GMT 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 pBI2HjDO001054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 18 Dec 2011 02:17:45 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBI2HjIn030690 for ; Sat, 17 Dec 2011 20:17:45 -0600 Received: from dradamslap1 (/10.159.55.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 17 Dec 2011 18:17:44 -0800 From: "Drew Adams" To: Subject: 24.0.92; doc string of `file-remote-p' Date: Sat, 17 Dec 2011 18:17:38 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acy9KzaVEQ4d5/dZSPaMBJ+EfrygEQ== 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.0A090207.4EED4D4A.0064,ss=1,re=0.000,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) This part means nothing, and is misleading: "`file-remote-p' will never open a connection on its own." What could "on its own" possibly mean here. This function can invoke a handler, which can open a connection. So this function can open a connection. We don't distinguish what the implementation of a function does from what the function does. If the code in the body of `file-remote-p' ends up opening a connection, then `file-remote-p' opens a connection. You are probably trying to say something useful here (what?), but so far you have not said anything useful by this sentence. And it misleads. In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-06 on MARVIN Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.6) --no-opt --cflags -ID:/devel/emacs/libs/libXpm-3.5.8/include -ID:/devel/emacs/libs/libXpm-3.5.8/src -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include -ID:/devel/emacs/libs/giflib-4.1.4-1/include -ID:/devel/emacs/libs/jpeg-6b-4/include -ID:/devel/emacs/libs/tiff-3.8.2-1/include -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags -LD:/devel/emacs/libs/gnutls-2.10.1/lib' From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 18 03:35:15 2011 Received: (at 10319) by debbugs.gnu.org; 18 Dec 2011 08:35:16 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcCDD-0005kN-Pq for submit@debbugs.gnu.org; Sun, 18 Dec 2011 03:35:15 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RcCDB-0005kF-Kz for 10319@debbugs.gnu.org; Sun, 18 Dec 2011 03:35:14 -0500 Received: (qmail invoked by alias); 18 Dec 2011 08:33:26 -0000 Received: from p57BB9CB5.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.156.181] by mail.gmx.net (mp033) with SMTP; 18 Dec 2011 09:33:26 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19z2TQhrTVzteulDAkA6u9MlA/z1POtOXR4opP3QC 7W4DR/F3clz9XC From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' References: Date: Sun, 18 Dec 2011 09:33:20 +0100 In-Reply-To: (Drew Adams's message of "Sat, 17 Dec 2011 18:17:38 -0800") Message-ID: <87wr9uuvn3.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > This part means nothing, and is misleading: > > "`file-remote-p' will never open a connection on its own." > > What could "on its own" possibly mean here. This function can invoke a > handler, which can open a connection. So this function can open a > connection. We don't distinguish what the implementation of a function > does from what the function does. If the code in the body of > `file-remote-p' ends up opening a connection, then `file-remote-p' opens > a connection. the intention is exactly as said: any implementation of `file-remote-p' shall not open a new remote connection, if it is not established yet. > You are probably trying to say something useful here (what?), but so far > you have not said anything useful by this sentence. And it misleads. The wording comes from me. If there are better ways to say this, please propose. I'm not a native English speaker. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 18 10:04:56 2011 Received: (at 10319) by debbugs.gnu.org; 18 Dec 2011 15:04:56 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcIII-0006o8-T2 for submit@debbugs.gnu.org; Sun, 18 Dec 2011 10:04:55 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcIIG-0006o0-Ie for 10319@debbugs.gnu.org; Sun, 18 Dec 2011 10:04:53 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBIF336H017146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Dec 2011 15:03:04 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBIF322U017420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2011 15:03:02 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBIF32Sh014032; Sun, 18 Dec 2011 09:03:02 -0600 Received: from dradamslap1 (/10.159.55.81) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Dec 2011 07:03:01 -0800 From: "Drew Adams" To: "'Michael Albinus'" References: <87wr9uuvn3.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Sun, 18 Dec 2011 07:02:53 -0800 Message-ID: <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87wr9uuvn3.fsf@gmx.de> Thread-Index: Acy9X7hjhDYEx5SPSkmeKhcCcD5oUwANCZdA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090204.4EEE00A8.0095,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > "`file-remote-p' will never open a connection on its own." > > > > What could "on its own" possibly mean here. This function > > can invoke a handler, which can open a connection. So > > this function can open a connection. We don't distinguish > > what the implementation of a function does from what the > > function does. If the code in the body of `file-remote-p' > > ends up opening a connection, then `file-remote-p' opens > > a connection. > > the intention is exactly as said: any implementation of > `file-remote-p' shall not open a new remote connection, > if it is not established yet. I didn't understand that from the phrase used. I thought that it somehow was referring to the fact that the handler might open a new connection, and that that wouldn't be `file-remote-p' doing so "on its own". But if a given connection has already been established, and if `file-remote-p' then (re-)opens it, it is not a "new" connection. Or maybe I'm missing something else (maybe a difference between open and establish?). So even your better explanation here leaves me a little confused. Do you just want to say that `file-remote-p' never opens a new connection (i.e., a connection that is not already established/open)? If so, let's just say that: It never opens a new remote connection. It can only reuse a connection that is already open. If not, then I'm afraid I'm still confused about the behavior (I'm no expert on remote connection) and what we are trying to say about it. > > You are probably trying to say something useful here > > (what?), but so far you have not said anything useful > > by this sentence. And it misleads. > > The wording comes from me. If there are better ways to say > this, please propose. I'm not a native English speaker. I understand, and will try to propose something, once I understand what we're really trying to say. Can the handler establish a _new_ connection? If so, then `file-remote-p' can do so. If not, then can't we just say that `file-remote-p' never establishes (opens) a new connection? Let me know what the point is - what we're trying to communicate about opening connections, and once I understand that I can make a suggestion wrt wording. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 03:42:20 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 08:42:20 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcYnb-0005qi-HF for submit@debbugs.gnu.org; Mon, 19 Dec 2011 03:42:20 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RcYnY-0005qY-5W for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 03:42:18 -0500 Received: (qmail invoked by alias); 19 Dec 2011 08:40:22 -0000 Received: from p57BB978C.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.151.140] by mail.gmx.net (mp056) with SMTP; 19 Dec 2011 09:40:22 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18OCnBLTXsORjPyv/3b+dzzcCrAN2UdWfhAbz+hAm 9yXudfjoXr6VA/ From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' References: <87wr9uuvn3.fsf@gmx.de> <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> Date: Mon, 19 Dec 2011 09:40:19 +0100 In-Reply-To: <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> (Drew Adams's message of "Sun, 18 Dec 2011 07:02:53 -0800") Message-ID: <87bor5eyz0.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > Do you just want to say that `file-remote-p' never opens > a new connection (i.e., a connection that is not already > established/open)? Yes. > If so, let's just say that: It never opens a new remote > connection. It can only reuse a connection that is > already open. Sounds OK to me. > I understand, and will try to propose something, once I > understand what we're really trying to say. Can the handler > establish a _new_ connection? If so, then `file-remote-p' > can do so. If not, then can't we just say that > `file-remote-p' never establishes (opens) a new connection? It is a promise to libraries using `file-remote-p'. It is guaranteed that the function call is cheap, and that it could be used here and there w/o remarkable overhead. It is also an implementation hint. Any handler that provides an own implementation of `file-remote-p' shall behave like this. `tramp-handle-file-remote-p' and `ange-ftp-file-remote-p' do so. As a consequence, the result might differ whether a connection is already open, or not. If the connection is not established yet, we get (file-remote-p "/ssh::" 'localname) => "" If there is an established connection, we see (file-remote-p "/ssh::" 'localname) => "/home/albinus" Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 11:12:58 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 16:12:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcfpi-0008J7-5T for submit@debbugs.gnu.org; Mon, 19 Dec 2011 11:12:58 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rcfpf-0008Ix-TR for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 11:12:56 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBJGB0FA026444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 16:11:01 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBJGAxpF003558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 16:10:59 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBJGAw48021800; Mon, 19 Dec 2011 10:10:58 -0600 Received: from dradamslap1 (/10.159.51.27) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Dec 2011 08:10:58 -0800 From: "Drew Adams" To: "'Michael Albinus'" References: <87wr9uuvn3.fsf@gmx.de><1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> <87bor5eyz0.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Mon, 19 Dec 2011 08:10:47 -0800 Message-ID: <88D1EF1166814B70B0E2CD052362AA72@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87bor5eyz0.fsf@gmx.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Acy+KdtaHsJYlG5+TlCcQJ+tfsf2xAAPTLrw X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090202.4EEF6215.00EF,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > Do you just want to say that `file-remote-p' never opens > > a new connection (i.e., a connection that is not already > > established/open)? > > Yes. > > > If so, let's just say that: It never opens a new remote > > connection. It can only reuse a connection that is > > already open. > > Sounds OK to me. Let's do that then. IMO, that will avoid some misunderstanding. > > Can the handler establish a _new_ connection? If so, then > > `file-remote-p' can do so. If not, then can't we just say > > that `file-remote-p' never establishes (opens) a new > > connection? > > It is a promise to libraries using `file-remote-p'. It is guaranteed > that the function call is cheap, and that it could be used here and > there w/o remarkable overhead. That is covered by what is said above: it never opens new connection. > It is also an implementation hint. Any handler that provides an own > implementation of `file-remote-p' shall behave like this. > `tramp-handle-file-remote-p' and `ange-ftp-file-remote-p' do so. I doubt that trying to hint that in the doc string will help more than hurt user understanding. IMO we would either need to spell that out clearly or put it in comments in the code. I think the latter is preferable. The doc string should be aimed mainly at users of the function, not at implementors of substitute definitions of it. But all of that kind of thing can be stated clearly in the source file for those to whom it is useful. > As a consequence, the result might differ whether a connection is > already open, or not. If the connection is not established yet, we get > (file-remote-p "/ssh::" 'localname) => "" > If there is an established connection, we see > (file-remote-p "/ssh::" 'localname) => "/home/albinus" That might be worth pointing out in the doc string. It might be useful to users of the function. Perhaps you could just add text like this: "The return value can differ depending on whether there is an existing connection." Do we want to say more than that? Is there some rule about this? E.g., if no existing connection is the return value _always_ ""? If no rule, then just adding that sentence (or similar) should be enough. Thx - Drew From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 13:28:34 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 18:28:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rchww-0003Ff-LD for submit@debbugs.gnu.org; Mon, 19 Dec 2011 13:28:34 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Rchwt-0003FV-0a for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 13:28:32 -0500 Received: (qmail invoked by alias); 19 Dec 2011 18:26:34 -0000 Received: from p57BB978C.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.151.140] by mail.gmx.net (mp034) with SMTP; 19 Dec 2011 19:26:34 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18ppWBiAQ8pwaMgarSM197aCG2/j6i4pgFbiMJORE KP+PDAjxgvgJXR From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' References: <87wr9uuvn3.fsf@gmx.de> <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> <87bor5eyz0.fsf@gmx.de> <88D1EF1166814B70B0E2CD052362AA72@us.oracle.com> Date: Mon, 19 Dec 2011 19:26:31 +0100 In-Reply-To: <88D1EF1166814B70B0E2CD052362AA72@us.oracle.com> (Drew Adams's message of "Mon, 19 Dec 2011 08:10:47 -0800") Message-ID: <87ehw0e7u0.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: >> > If so, let's just say that: It never opens a new remote >> > connection. It can only reuse a connection that is >> > already open. >> >> Sounds OK to me. > > Let's do that then. IMO, that will avoid some misunderstanding. > >> It is also an implementation hint. Any handler that provides an own >> implementation of `file-remote-p' shall behave like this. >> `tramp-handle-file-remote-p' and `ange-ftp-file-remote-p' do so. > > I doubt that trying to hint that in the doc string will help more than > hurt user understanding. IMO we would either need to spell that out > clearly or put it in comments in the code. I didn't intend to include it as such. It is an implicit implementation hint. > I think the latter is preferable. The doc string should be aimed > mainly at users of the function, not at implementors of substitute > definitions of it. But all of that kind of thing can be stated > clearly in the source file for those to whom it is useful. OK. >> As a consequence, the result might differ whether a connection is >> already open, or not. If the connection is not established yet, we get >> (file-remote-p "/ssh::" 'localname) => "" >> If there is an established connection, we see >> (file-remote-p "/ssh::" 'localname) => "/home/albinus" > > That might be worth pointing out in the doc string. It might be > useful to users of the function. Perhaps you could just add text like > this: > > "The return value can differ depending on whether there > is an existing connection." We shall mention that the return value is still a string. And the difference happens only for localname parts. > Do we want to say more than that? Is there some rule about this? > E.g., if no existing connection is the return value _always_ ""? If > no rule, then just adding that sentence (or similar) should be enough. I wouldn't give a rule. There are other cases, like (file-remote-p "/ssh::" 'localname), which returns "~" when there is no connection, and "/home/albinus" otherwise. Combining your proposals, the docstring could be "Test whether FILE specifies a location on a remote system. Returns 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:". A file is considered "remote" if accessing it is likely to be slower or less reliable than accessing local files. Furthermore, relative file names do not work across remote connections. IDENTIFICATION specifies which part of the identification shall be returned as string. IDENTIFICATION can be the symbol `method', `user', `host' or `localname'; any other value is handled like nil and means to return the complete identification string. The string returned for IDENTIFICATION `localname' can differ depending on whether there is an existing connection." If CONNECTED is non-nil, the function returns an identification only if FILE is located on a remote system, and a connection is established to that remote system. `file-remote-p' never opens a new remote connection. It can only reuse a connection that is already open." > Thx - Drew Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 14:46:17 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 19:46:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcjA9-00052f-DF for submit@debbugs.gnu.org; Mon, 19 Dec 2011 14:46:17 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcjA5-00052X-W7 for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 14:46:15 -0500 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBJJiHHj010589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 19:44:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBJJiH9k024044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 19:44:17 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBJJiGD3012965; Mon, 19 Dec 2011 13:44:16 -0600 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Dec 2011 11:44:16 -0800 From: "Drew Adams" To: "'Michael Albinus'" References: <87wr9uuvn3.fsf@gmx.de><1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com><87bor5eyz0.fsf@gmx.de><88D1EF1166814B70B0E2CD052362AA72@us.oracle.com> <87ehw0e7u0.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Mon, 19 Dec 2011 11:44:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ehw0e7u0.fsf@gmx.de> Thread-Index: Acy+e8AYuCUwGeSORW+RuuUr1vxYJwAB4YCQ 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.0A090207.4EEF9412.010B,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > That might be worth pointing out in the doc string. It might be > > useful to users of the function. Perhaps you could just add > > text like this: > > "The return value can differ depending on whether there > > is an existing connection." > > We shall mention that the return value is still a string. And the > difference happens only for localname parts. Good. > > Do we want to say more than that? Is there some rule about this? > > E.g., if no existing connection is the return value _always_ ""? If > > no rule, then just adding that sentence (or similar) should > > be enough. > > I wouldn't give a rule. There are other cases, like (file-remote-p > "/ssh::" 'localname), which returns "~" when there is no > connection, and "/home/albinus" otherwise. > > Combining your proposals, the docstring could be > > "Test whether FILE specifies a location on a remote system. Returns > nil or a string Returns -> Return. I think that's the convention, but I'm no expert. > identifying the remote connection (ideally a prefix > of FILE). For example, the remote identification for filename > "/user@host:/foo" could be "/user@host:". > A file is considered "remote" if accessing it is likely to > be slower or less reliable than accessing local files. I'd suggest moving that just after the first sentence ("Test..."). > Furthermore, relative file names do not work across remote > connections. Why "Furthermore"? This seems unrelated to anything preceding it. If I'm right, I'd suggest just dropping "Furthermore". But in fact I don't know what this sentence means. What do you mean here by "do not work"? > IDENTIFICATION specifies which part of the identification shall be > returned as string. shall be returned as string -> 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 string. No need for "string" here. > The string > returned for IDENTIFICATION `localname' can differ depending on > whether there is an existing connection." Good. > If CONNECTED is non-nil, the function returns an the function returns -> return > identification only if FILE is located on a remote system, No comma here. > and a connection is established to that remote system. > `file-remote-p' never opens a new remote connection. It can only > reuse a connection that is already open." I'd suggest putting that last part just after "A file is considered remote if..." 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. We should also perhaps say what "the complete identification" is/means. IOW, when IDENTIFICATION is nil, what can we say about the return value? HTH - Drew From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 16:21:00 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 21:21:00 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rckdo-0007C1-4q for submit@debbugs.gnu.org; Mon, 19 Dec 2011 16:21:00 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RckdX-0007BZ-RB for 10319@debbugs.gnu.org; Mon, 19 Dec 2011 16:20:59 -0500 Received: (qmail invoked by alias); 19 Dec 2011 21:18:47 -0000 Received: from p57BB978C.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.151.140] by mail.gmx.net (mp025) with SMTP; 19 Dec 2011 22:18:47 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19SbCV3wuRSFMYbg22hV206xcn5RDCruocFacav0S Olr0KoItF+ErIN From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' References: <87wr9uuvn3.fsf@gmx.de> <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> <87bor5eyz0.fsf@gmx.de> <88D1EF1166814B70B0E2CD052362AA72@us.oracle.com> <87ehw0e7u0.fsf@gmx.de> Date: Mon, 19 Dec 2011 22:18:43 +0100 In-Reply-To: (Drew Adams's message of "Mon, 19 Dec 2011 11:44:16 -0800") Message-ID: <877h1sdzv0.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: >> A file is considered "remote" if accessing it is likely to >> be slower or less reliable than accessing local files. > > I'd suggest moving that just after the first sentence ("Test..."). > >> Furthermore, relative file names do not work across remote >> connections. > > Why "Furthermore"? This seems unrelated to anything preceding it. If I'm > right, I'd suggest just dropping "Furthermore". But in fact I don't know what > this sentence means. What do you mean here by "do not work"? Both sentences from the docstring are not from me. For the first sentence, I even disagree with Stefan (but we should NOT discuss this here). The second sentence means that a relative filename like "/sudo::../../.." does not make sense, because it cannot expand out of the "/sudo::" jail. > 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. > HTH - Drew Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 19 16:31:40 2011 Received: (at 10319) by debbugs.gnu.org; 19 Dec 2011 21:31:40 +0000 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 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 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 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 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 Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Dec 2011 13:29:32 -0800 From: "Drew Adams" To: "'Michael Albinus'" 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> Subject: RE: 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > 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 From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 04:17:34 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 09:17:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RcvpG-0007Ja-Pv for submit@debbugs.gnu.org; Tue, 20 Dec 2011 04:17:34 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RcvpE-0007JS-L2 for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 04:17:33 -0500 Received: (qmail invoked by alias); 20 Dec 2011 09:15:32 -0000 Received: from p57BB964B.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.150.75] by mail.gmx.net (mp064) with SMTP; 20 Dec 2011 10:15:32 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX1+wJntZo3awFrdQfDyyWpj37HW7ocSCuwp+Jr5PSj UGtQ39ZUQZkrAg From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' 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> <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> Date: Tue, 20 Dec 2011 10:15:29 +0100 In-Reply-To: <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> (Drew Adams's message of "Mon, 19 Dec 2011 13:29:31 -0800") Message-ID: <87zkend2oe.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: >> 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? Any relative filename cannot expand to a different remote connection, or a filename of your local filesystem. But you are right, this information is irrelevant for the docstring of `file-remote-p'. >> > 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? When IDENTIFICATION is nil, the returned string is everything until the last ":" (with expanded default method, default user, default host). (file-remote-p "/sudo::/") => "/sudo:root@localhost:" (file-remote-p "/localhost:/") => "/scpc:localhost:" What I have tried to explain is a common technique for creation of new remote filenames, derived from an existing one. Let's say you have a variable `file' containing the remote filename "/sudo::/path/to/file", and you want to create a new remote filename for the file "/bin/sh". You apply then (concat (file-remote-p file) "/bin/sh") > Thx - Drew Best reards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 10:55:34 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 15:55:34 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd22Q-0000Hk-I6 for submit@debbugs.gnu.org; Tue, 20 Dec 2011 10:55:34 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd22N-0000Hb-Iv for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 10:55:32 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBKFrUPk006268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 15:53:31 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBKFrT00022246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 15:53:30 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBKFrTEe010678; Tue, 20 Dec 2011 09:53:29 -0600 Received: from dradamslap1 (/10.159.57.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Dec 2011 07:53:29 -0800 From: "Drew Adams" To: "'Michael Albinus'" 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><9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> <87zkend2oe.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Tue, 20 Dec 2011 07:53:24 -0800 Message-ID: <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87zkend2oe.fsf@gmx.de> Thread-Index: Acy+9+9tRTEoZS15Q0GKGlQbSakwegAMxRNg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090201.4EF0AF7C.002C,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > > 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? > > Any relative filename cannot expand to a different remote > connection, or a filename of your local filesystem. But you > are right, this information is irrelevant for the docstring > of `file-remote-p'. "relative file names do not work across remote connections" should be dropped, as it is not clear at all what we're trying to say by it. If we want to say something about relative file names, then it needs to be clear, whatever it is. We really should say what happens if a relative file name is passed as arg. It's still not clear to me, from your statement above. Are you saying that nil is always returned for a relative file name? If so, let's just say that: "Return nil if FILE is a relative file name". (No need to say that you must or should use an absolute name.) If that's not the case, please try again to explain, and I'll propose something else once I understand. (Simple tests seem to indicate that nil is returned.) > >> > 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? > > When IDENTIFICATION is nil, the returned string is everything > until the last ":" (with expanded default method, default user, > default host). > > (file-remote-p "/sudo::/") => "/sudo:root@localhost:" > (file-remote-p "/localhost:/") => "/scpc:localhost:" Fine. Let's say that (it's not obvious, IMHO). When IDENTIFICATION is nil, the returned string is a complete remote identifier: with components method, user, and host. The components are those present in FILE, with defaults filled in for any that are missing. > What I have tried to explain is a common technique for creation of new > remote filenames, derived from an existing one. Let's say you have a > variable `file' containing the remote filename "/sudo::/path/to/file", > and you want to create a new remote filename for the file > "/bin/sh". You apply then (concat (file-remote-p file) "/bin/sh") That's a useful tip about another way to _use_ the function, and also not so obvious. Let's say that too. Tip: You can use this expansion of remote identifier components to derive a new remote name from an existing one. For example, if FILE is "/sudo::/path/to/file" then (concat (file-remote-p FILE) "/bin/sh") returns a remote name for file "/bin/sh" that has the same remote identifier as FILE but expanded; a name such as "/sudo:myhost.org:/bin/sh". HTH. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 12:05:08 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 17:05:08 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd37j-0001qJ-Uo for submit@debbugs.gnu.org; Tue, 20 Dec 2011 12:05:08 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Rd37g-0001qA-4K for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 12:05:06 -0500 Received: (qmail invoked by alias); 20 Dec 2011 17:03:01 -0000 Received: from p57BB964B.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.150.75] by mail.gmx.net (mp015) with SMTP; 20 Dec 2011 18:03:01 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19Bh9JkKGpBZ115qsnc3kQk6rFr9P2z1xFWsrea4I /vO4oEqbgvWs5b From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' 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> <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> <87zkend2oe.fsf@gmx.de> <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> Date: Tue, 20 Dec 2011 18:02:57 +0100 In-Reply-To: <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> (Drew Adams's message of "Tue, 20 Dec 2011 07:53:24 -0800") Message-ID: <87ehvzch1a.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > Are you saying that nil is always returned for a relative file name? If so, > let's just say that: "Return nil if FILE is a relative file name". (No need to > say that you must or should use an absolute name.) Thinking about (and testing a little bit) it seems like this: for relative file names it always returns nil, indeed. This is because it does not apply `expand-file-name'. Your proposed sentence looks OK. >> When IDENTIFICATION is nil, the returned string is everything >> until the last ":" (with expanded default method, default user, >> default host). >> >> (file-remote-p "/sudo::/") => "/sudo:root@localhost:" >> (file-remote-p "/localhost:/") => "/scpc:localhost:" > > Fine. Let's say that (it's not obvious, IMHO). > > When IDENTIFICATION is nil, the returned string is a complete > remote identifier: with components method, user, and host. > The components are those present in FILE, with defaults filled > in for any that are missing. OK. >> What I have tried to explain is a common technique for creation of new >> remote filenames, derived from an existing one. Let's say you have a >> variable `file' containing the remote filename "/sudo::/path/to/file", >> and you want to create a new remote filename for the file >> "/bin/sh". You apply then (concat (file-remote-p file) "/bin/sh") > > That's a useful tip about another way to _use_ the function, and also not so > obvious. Let's say that too. > > Tip: You can use this expansion of remote identifier components > to derive a new remote name from an existing one. For example, > if FILE is "/sudo::/path/to/file" then > (concat (file-remote-p FILE) "/bin/sh") returns a remote > name for file "/bin/sh" that has the same remote identifier as > FILE but expanded; a name such as "/sudo:myhost.org:/bin/sh". OK as well. Minor change: the result for the sudo case ought to be "/sudo:root@myhost:/bin/sh". "root" is the default user name for "sudo", and "myhost" instead of "myhost.org" because the default host name in this case is the value of `system-name'. > HTH. Thanks, and best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 12:10:31 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 17:10:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd3Cv-0001xV-6P for submit@debbugs.gnu.org; Tue, 20 Dec 2011 12:10:30 -0500 Received: from rcsinet15.oracle.com ([148.87.113.117]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd3Ct-0001xO-Hi for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 12:10:28 -0500 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBKH8QAs023905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 17:08:27 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBKH8Ppo014840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 17:08:26 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBKH8PBa013710; Tue, 20 Dec 2011 11:08:25 -0600 Received: from dradamslap1 (/10.159.57.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Dec 2011 09:08:24 -0800 From: "Drew Adams" To: "'Michael Albinus'" 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><9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com><87zkend2oe.fsf@gmx.de><7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> <87ehvzch1a.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Tue, 20 Dec 2011 09:08:20 -0800 Message-ID: <79FB392943994EDE9705C50A53C21ABD@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87ehvzch1a.fsf@gmx.de> Thread-Index: Acy/OUGCSBXMxRAzTTuBvcZZf/NxPgAAISPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090201.4EF0C10B.0090,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) Sounds like you have what you need now and will update the doc string, so this can be closed. Thx for your help. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 12:16:22 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 17:16:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd3Ic-00025x-8E for submit@debbugs.gnu.org; Tue, 20 Dec 2011 12:16:22 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Rd3IZ-00025m-0l for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 12:16:20 -0500 Received: (qmail invoked by alias); 20 Dec 2011 17:14:17 -0000 Received: from p57BB964B.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.150.75] by mail.gmx.net (mp014) with SMTP; 20 Dec 2011 18:14:17 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX19HA0hfHLhHs/dcy02Tr+JZl4s/QO+H/MUvCbTZKS LfTieLxnNTlW47 From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' 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> <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> <87zkend2oe.fsf@gmx.de> <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> <87ehvzch1a.fsf@gmx.de> <79FB392943994EDE9705C50A53C21ABD@us.oracle.com> Date: Tue, 20 Dec 2011 18:14:13 +0100 In-Reply-To: <79FB392943994EDE9705C50A53C21ABD@us.oracle.com> (Drew Adams's message of "Tue, 20 Dec 2011 09:08:20 -0800") Message-ID: <878vm7cgii.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: > Sounds like you have what you need now and will update the doc string, so this > can be closed. Thx for your help. Sounds like everything is your wording. Do you want to commit it under your name? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 20 12:35:52 2011 Received: (at 10319) by debbugs.gnu.org; 20 Dec 2011 17:35:52 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd3bT-0002WT-A3 for submit@debbugs.gnu.org; Tue, 20 Dec 2011 12:35:52 -0500 Received: from acsinet15.oracle.com ([141.146.126.227]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rd3bR-0002WL-B5 for 10319@debbugs.gnu.org; Tue, 20 Dec 2011 12:35:49 -0500 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBKHXbvX016803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 17:33:38 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id pBKHXZUj014861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 17:33:36 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBKHXZGW001234; Tue, 20 Dec 2011 11:33:35 -0600 Received: from dradamslap1 (/10.159.57.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Dec 2011 09:33:35 -0800 From: "Drew Adams" To: "'Michael Albinus'" 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><9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com><87zkend2oe.fsf@gmx.de><7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com><87ehvzch1a.fsf@gmx.de><79FB392943994EDE9705C50A53C21ABD@us.oracle.com> <878vm7cgii.fsf@gmx.de> Subject: RE: bug#10319: 24.0.92; doc string of `file-remote-p' Date: Tue, 20 Dec 2011 09:33:31 -0800 Message-ID: <0A27F2FCDFE94AA4BA8C11F090D24DBA@us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <878vm7cgii.fsf@gmx.de> Thread-Index: Acy/OtINqWKsNBg3TCaCls/OxLYcsgAAptoA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090208.4EF0C6FC.00B4,ss=1,re=0.000,fgs=0 X-Spam-Score: -6.2 (------) X-Debbugs-Envelope-To: 10319 Cc: 10319@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.2 (------) > Sounds like everything is your wording. Do you want to commit it under > your name? Please commit it for me. You can use my name if you like. Thx. From debbugs-submit-bounces@debbugs.gnu.org Wed Dec 21 13:37:12 2011 Received: (at 10319-done) by debbugs.gnu.org; 21 Dec 2011 18:37:12 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RdR2O-0005L7-Dd for submit@debbugs.gnu.org; Wed, 21 Dec 2011 13:37:12 -0500 Received: from mailout-de.gmx.net ([213.165.64.23]) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RdR2L-0005Ky-Bb for 10319-done@debbugs.gnu.org; Wed, 21 Dec 2011 13:37:10 -0500 Received: (qmail invoked by alias); 21 Dec 2011 18:35:01 -0000 Received: from p57BB9646.dip0.t-ipconnect.de (EHLO detlef.gmx.de) [87.187.150.70] by mail.gmx.net (mp007) with SMTP; 21 Dec 2011 19:35:01 +0100 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX1+/UtUqeAi/wp17ruesObA10k0h7nOUyYLmv8rppY aL5TsQ+pznPyXW From: Michael Albinus To: "Drew Adams" Subject: Re: bug#10319: 24.0.92; doc string of `file-remote-p' 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> <9F8218E3FA3645D9B59B2F8EEE480A8C@us.oracle.com> <87zkend2oe.fsf@gmx.de> <7ED9EAB31656456981FDB12C5ABD0C7B@us.oracle.com> <87ehvzch1a.fsf@gmx.de> <79FB392943994EDE9705C50A53C21ABD@us.oracle.com> <878vm7cgii.fsf@gmx.de> <0A27F2FCDFE94AA4BA8C11F090D24DBA@us.oracle.com> Date: Wed, 21 Dec 2011 19:34:58 +0100 In-Reply-To: <0A27F2FCDFE94AA4BA8C11F090D24DBA@us.oracle.com> (Drew Adams's message of "Tue, 20 Dec 2011 09:33:31 -0800") Message-ID: <8762h9bwod.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Y-GMX-Trusted: 0 X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10319-done Cc: 10319-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) "Drew Adams" writes: >> Sounds like everything is your wording. Do you want to commit it under >> your name? > > Please commit it for me. You can use my name if you like. Thx. Done. Thanks again, and best regards, Michael. From unknown Sun Aug 17 09:09:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 19 Jan 2012 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator