From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: testing for a remote file to include file on a Windows mappeddrive Date: Fri, 25 Jan 2008 23:30:54 -0800 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1201332696 1146 80.91.229.12 (26 Jan 2008 07:31:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jan 2008 07:31:36 +0000 (UTC) Cc: Emacs-Devel , Jason Rumney To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 26 08:31:55 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JIfW4-00016R-6n for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 08:31:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIfVd-0006Jo-DJ for ged-emacs-devel@m.gmane.org; Sat, 26 Jan 2008 02:31:25 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JIfVY-0006Hi-EI for emacs-devel@gnu.org; Sat, 26 Jan 2008 02:31:20 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JIfVW-0006GB-Oy for emacs-devel@gnu.org; Sat, 26 Jan 2008 02:31:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JIfVW-0006G3-IE for emacs-devel@gnu.org; Sat, 26 Jan 2008 02:31:18 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JIfVR-00075H-TR; Sat, 26 Jan 2008 02:31:14 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m0Q7VATD012799; Sat, 26 Jan 2008 00:31:10 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m0Q7V9Va014569; Sat, 26 Jan 2008 00:31:10 -0700 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3539233341201332654; Fri, 25 Jan 2008 23:30:54 -0800 Original-Received: from dradamslap1 (/141.144.72.89) by bhmail.oracle.com (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 25 Jan 2008 23:30:54 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:87546 Archived-At: > > Also, IIUC, `file-remote-p' isn't only boolean; the non-nil return value > > means something. I don't know what should be returned for a > > file on a mapped network drive. > > I'm not thrilled about the non-boolean return value of file-remote-p. > Its semantics seem to be custom-tailored for Tramp and doesn't make so > much sense in general :-( Perhaps that other info should be relegated to some other function. Or perhaps it should be local to Tramp, if it is not useful elsewhere. At least for the use of `file-remote-p' that is to avoid possibly expensive remote access, any info that might take more time to dig up should be left out. > > And should we perhaps have a function that distinguishes remote > > files that are not on a mapped drive from those that are? Is > > there any need to distinguish these? (We currently do distinguish > > them, in that `file-remote-p' returns non-nil for the former and > > nil for the latter.) > > It all depends what you want to know. In doc-view, we recently tried to > use file-remote-p in order to figure out whether we could pass the file > name to a local process, only to discover that it wasn't the right > predicate to use. I replaced it later on with > (let ((file-name-handlers-alist nil)) (file-readable-p )). > > I think file-remote-p should really give a kind of performance and > reliability info: is the file available from local (i.e. fast and > reliable) storage, or is it only available via a network access which > may be slow and may fail. Yes, I think that is the most common use of `file-remote-p', in any case. Whether that is, or needs to be, a true test of remoteness is another question. If not, the name could perhaps be changed. Typically, I think what's wanted in that use case is to just get an idea whether the file name is likely to represent a remote file - info as to whether or not the file is in fact remote is often not needed. For this common use case, the function is in fact a sort of `file-might-take-a-while-to-access-p' - it is not the remoteness that is as important as the potential access time. For example, if it takes actually connecting remotely to find out for sure whether some file exists remotely, that is not appropriate for many current uses of `file-remote-p', IIUC. At least, that was the use case I had in mind: I don't want the function to take any extra time to find out for sure; I just want to know if it is likely to be remote, in which case I will skip certain operations. > Now whether access via NFS should be considered as remote or not is not > clear: it's ofen used for home directories, and treating all the user's > file as "remote" is probably not a great idea. I agree that the different notions of "remote" should be clarified, and one should be able to obtain each of them that represents an important use case. It is definitely useful to be able to distinguish "possibly remote" from "local" in terms of potential performance impact - that is, regardless of whether the meaning is truly remote vs local. I imagine that some of the other distinctions might also be useful. Your use of `file-readable-p' for doc-view would presumably be one of those.