all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Albinus <michael.albinus@gmx.de>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 10319@debbugs.gnu.org
Subject: bug#10319: 24.0.92; doc string of `file-remote-p'
Date: Mon, 19 Dec 2011 22:18:43 +0100	[thread overview]
Message-ID: <877h1sdzv0.fsf@gmx.de> (raw)
In-Reply-To: <C8FDFC3F0F164743BD95600B52E1816D@us.oracle.com> (Drew Adams's message of "Mon, 19 Dec 2011 11:44:16 -0800")

"Drew Adams" <drew.adams@oracle.com> 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.





  reply	other threads:[~2011-12-19 21:18 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877h1sdzv0.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=10319@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /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.