From: "Drew Adams" <drew.adams@oracle.com>
To: "'Michael Albinus'" <michael.albinus@gmx.de>
Cc: 10319@debbugs.gnu.org
Subject: bug#10319: 24.0.92; doc string of `file-remote-p'
Date: Sun, 18 Dec 2011 07:02:53 -0800 [thread overview]
Message-ID: <1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com> (raw)
In-Reply-To: <87wr9uuvn3.fsf@gmx.de>
> > "`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.
next prev parent reply other threads:[~2011-12-18 15:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-18 2:17 bug#10319: 24.0.92; doc string of `file-remote-p' Drew Adams
2011-12-18 8:33 ` Michael Albinus
2011-12-18 15:02 ` Drew Adams [this message]
2011-12-19 8:40 ` Michael Albinus
2011-12-19 16:10 ` Drew Adams
2011-12-19 18:26 ` Michael Albinus
2011-12-19 19:44 ` Drew Adams
2011-12-19 21:18 ` Michael Albinus
2011-12-19 21:29 ` Drew Adams
2011-12-20 9:15 ` Michael Albinus
2011-12-20 15:53 ` Drew Adams
2011-12-20 17:02 ` Michael Albinus
2011-12-20 17:08 ` Drew Adams
2011-12-20 17:14 ` Michael Albinus
2011-12-20 17:33 ` Drew Adams
2011-12-21 18:34 ` Michael Albinus
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1C247F238CC24F6F9A0A3D077D3E09FE@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=10319@debbugs.gnu.org \
--cc=michael.albinus@gmx.de \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).