From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Optional argument for `file-local-copy' Date: Thu, 11 Dec 2014 10:22:11 -0500 Message-ID: References: <871tom5jou.fsf@gmx.de> <83bnnqb1lo.fsf@gnu.org> <20141129140856.GA3752@acm.acm> <83a93aax58.fsf@gnu.org> <20141129153320.GC3752@acm.acm> <87d2853q5i.fsf@gmx.de> <87k32cbo06.fsf@gmx.de> <87k32ahzmt.fsf@gmx.de> <8761dtoidb.fsf@gmx.de> <87iohlhrsx.fsf@gmx.de> <8761dik0f5.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418315990 14479 80.91.229.3 (11 Dec 2014 16:39:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Dec 2014 16:39:50 +0000 (UTC) Cc: Alan Mackenzie , Eli Zaretskii , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 11 17:39:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xz6mE-00019N-M9 for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 17:39:42 +0100 Original-Received: from localhost ([::1]:52409 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6mE-0007ma-6B for ged-emacs-devel@m.gmane.org; Thu, 11 Dec 2014 11:39:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6lh-0007hU-Ro for emacs-devel@gnu.org; Thu, 11 Dec 2014 11:39:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xz6lb-0000Nq-It for emacs-devel@gnu.org; Thu, 11 Dec 2014 11:39:09 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:41300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xz6lU-0000MK-Gd; Thu, 11 Dec 2014 11:38:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQRAOwQflRFxIoH/2dsb2JhbABbgwdSWQGCNIVavwSGGQQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCQ3WTAEBAQcBAQEBHpALZAeESAWLAYoegjaGF5FDgXiEGSExAYECgUMBAQE X-IPAS-Result: AuQRAOwQflRFxIoH/2dsb2JhbABbgwdSWQGCNIVavwSGGQQCAoEkFwEBAQEBAXyEAwEBAwFWIwULCzQSFBgNJIhKCQ3WTAEBAQcBAQEBHpALZAeESAWLAYoegjaGF5FDgXiEGSExAYECgUMBAQE X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="100202318" Original-Received: from 69-196-138-7.dsl.teksavvy.com (HELO pastel.home) ([69.196.138.7]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2014 11:38:55 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B5BF82654; Thu, 11 Dec 2014 10:22:11 -0500 (EST) In-Reply-To: <8761dik0f5.fsf@gmx.de> (Michael Albinus's message of "Thu, 11 Dec 2014 10:20:30 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179791 Archived-At: > The first idea to this came when I saw > . It offered a patch > to keep some copied remote images in a cache in order to redisplay > them. > Another evidence for such functionality is vc. If you open a remote file > under bzr control, there will be local copies of .bzr/checkout/dirstate, > .bzr/branch/format and .bzr/branch/last-revision. In the cvs case, > CVS/Entries is taken via file-local-copy. And there might be similar > cases for the other vc backends, I haven't checked. All of them are > candidates for a file cache as proposed. Yes, but how will you write the code so that the temp/cached files don't linger indefinitely? Don't get me wrong: I like the idea, but I think we need to think a bit more about how to handle the cache and deletion, in order to design the API correctly. Here's the problem I currently see: - OT1H you currently have the caller as the one responsible for the deletion of the file. - OTOH it's the handler that decides where to put the file. That seems to make it difficult to get a good behavior. E.g. you might want to keep the file for a long time (across sessions) in a special "cache" subdirectory somewhere, but this decision can't be made by the handler (because the caller will have to delete the file without knowing it's meant to be kept) and it can't be made by the caller either (because it can't tell the handler where to put the file). Maybe a better option is to change the optional argument so that it's not just a boolean but it's actually the name of a "candidate local copy" (i.e. it's the name of the local copy kept in the cache managed by the caller), tho maybe we'd need more info (e.g. the full file-attributes). Stefan