From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Reverting *Locate* buffers. Date: Thu, 29 Jun 2006 08:27:55 +0200 Message-ID: <857j30a32s.fsf@lola.goethe.zz> References: <200606260327.k5Q3Rfpd013691@jane.dms.auburn.edu> <853bdsmkey.fsf@lola.goethe.zz> <200606280158.k5S1wJCu004606@jane.dms.auburn.edu> <17569.64920.191861.355581@localhost.localdomain> <200606290313.k5T3DwTj002620@jane.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1151562546 21782 80.91.229.2 (29 Jun 2006 06:29:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2006 06:29:06 +0000 (UTC) Cc: pbreton@cs.umb.edu, tramp-devel@gnu.org, emacs-devel@gnu.org, raman@users.sourceforge.net Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 29 08:29:00 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Fvq1B-0002cT-Cv for ged-emacs-devel@m.gmane.org; Thu, 29 Jun 2006 08:28:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fvq1A-0007Ql-IF for ged-emacs-devel@m.gmane.org; Thu, 29 Jun 2006 02:28:48 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fvq0w-0007QL-Qb for emacs-devel@gnu.org; Thu, 29 Jun 2006 02:28:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fvq0w-0007Q9-0P for emacs-devel@gnu.org; Thu, 29 Jun 2006 02:28:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fvq0v-0007Q6-QH; Thu, 29 Jun 2006 02:28:33 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FvqDQ-0006wh-8z; Thu, 29 Jun 2006 02:41:28 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Fvq0u-0005Yo-WA; Thu, 29 Jun 2006 02:28:33 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 8B7701C4D3B9; Thu, 29 Jun 2006 08:27:55 +0200 (CEST) Original-To: Luc Teirlinck In-Reply-To: <200606290313.k5T3DwTj002620@jane.dms.auburn.edu> (Luc Teirlinck's message of "Wed, 28 Jun 2006 22:13:58 -0500 (CDT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:56273 Archived-At: Luc Teirlinck writes: > T. V. Raman wrote: > > While on the error message regarding tramp, I've found that tramp > being around causes *a lot* of recursive expand file calls --- > try running edebug on anything that calls expand-file-name to see > what I mean. > > Basically, tramp should only fire on the "head" of the path > being expanded -- at present it appears to fire for *each* path > component. > > Just as a general question to everybody interested (not just to the > person in the "To" field): > > Where do we stand now in this thread? Obviously, I can not implement > David's suggestion as long as there is this error message (assuming it > would not give other problems, even without that message, which I can > not test). > > Do I just commit my previously sent patch, or do we have the feeling > that there are bugs in Tramp which should be reported? Sounds like a bug to me. I think that my suggestion should be able to work and it is not really out of the ordinary with regard to using tramp. That being said, using "cd" to change into root is certainly not something to be done as a default setting, and it is actually not possible to know whether the "sudo" or "su" method would need to get used for a particular user on a particular system (if locate _is_ already running in some remote but non-root context, one would probably even want to use a multihop method from tramp, but this is so crazy that we really need not worry about it now). But the feature is so obscure that it needs to announce itself for customization, so failure of updatedb should be detected and the variable to try for customization in order to place updatedb in a tramp-governed announced after the error message. Note that this is a "wow feature": people will be pleasantly surprised if it is there, but not really expect it. So there is no large incentive to get it going if other difficulties rather than a tramp bug seem to make that infeasible. > Note that Tramp is independently maintained by tramp-devel, which I > have CC-ed, rather than by emacs-devel. I believe that the people > maintaining Tramp also read emacs-devel, but I am not sure that they > have followed this thread. Let's wait for their comment. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum