From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.bugs Subject: bug#5303: 23.1.91; Cannot load .emacs-history from savehist.el Date: Tue, 19 Jan 2010 21:01:04 +0100 Message-ID: References: <8F73D1539CE042B8A9B48F767127C43B@us.oracle.com> <87bpgtu9o5.fsf@stupidchicken.com> <87aawc1xlb.fsf@gmx.de> <8763701whc.fsf@gmx.de> <87r5pm2owq.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1263931787 24636 80.91.229.12 (19 Jan 2010 20:09:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2010 20:09:47 +0000 (UTC) Cc: 5303@debbugs.gnu.org, Chong Yidong To: Michael Albinus , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 19 21:09:38 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NXKON-0007X4-NL for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2010 21:09:36 +0100 Original-Received: from localhost ([127.0.0.1]:36215 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXKOO-0006Ym-Ah for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Jan 2010 15:09:36 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXKOJ-0006YF-Bd for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2010 15:09:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXKOE-0006VS-QT for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2010 15:09:31 -0500 Original-Received: from [199.232.76.173] (port=51704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXKOE-0006VK-Mv for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2010 15:09:26 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:55399) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NXKOE-0005aR-AF for bug-gnu-emacs@gnu.org; Tue, 19 Jan 2010 15:09:26 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1NXKH4-0006Y7-BF; Tue, 19 Jan 2010 15:02:02 -0500 X-Loop: bug-gnu-emacs@gnu.org Resent-From: Lennart Borgman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Jan 2010 20:02:02 +0000 Resent-Message-ID: Resent-Sender: bug-gnu-emacs@gnu.org X-Emacs-PR-Message: followup 5303 X-Emacs-PR-Package: emacs,w32 X-Emacs-PR-Keywords: Original-Received: via spool by 5303-submit@debbugs.gnu.org id=B5303.126393129325139 (code B ref 5303); Tue, 19 Jan 2010 20:02:02 +0000 Original-Received: (at 5303) by debbugs.gnu.org; 19 Jan 2010 20:01:33 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NXKGa-0006XN-Kr for submit@debbugs.gnu.org; Tue, 19 Jan 2010 15:01:32 -0500 Original-Received: from fg-out-1718.google.com ([72.14.220.154]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NXKGX-0006XA-2v for 5303@debbugs.gnu.org; Tue, 19 Jan 2010 15:01:30 -0500 Original-Received: by fg-out-1718.google.com with SMTP id e12so1077895fga.15 for <5303@debbugs.gnu.org>; Tue, 19 Jan 2010 12:01:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=DJpzXO57hFKEAMi8IAHaYcY/imMWWs03lXx0faDdrjA=; b=nUBm2cyFY7toWq7uQ19id538yIImzwtJbijqOuNfrp3xmUY9BfUjEZ+BbaTidMNZdi VriircWrLTKqU30BBDX/A+Q5NDWVtl7R/5VVV8Yw4KQM7BiBPO90I/LHWQuLA5ltsdUO g/JJdXSh962xiZCTargv8+yYkYsqfzuOPq9ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=uz3lTXLvlnl6D5qAIkZfWvFNwX6UPUm30nYR5IyAbblo3CCHazsSAIHOirqUUnbMRS kG+OZvtGub43OAB/NaZJnek2YBTH8gqEawRejT5ZZuJhG8vzLpB3+Frmm6l8D3EsvhC4 YI82nkLAPLOT6Tdd543dSsToLOgP2rTniy9qk= Original-Received: by 10.87.38.33 with SMTP id q33mr10815938fgj.3.1263931284195; Tue, 19 Jan 2010 12:01:24 -0800 (PST) In-Reply-To: <87r5pm2owq.fsf@gmx.de> X-Spam-Score: -3.0 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list X-Spam-Score: -2.9 (--) Resent-Date: Tue, 19 Jan 2010 15:02:02 -0500 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:34511 Archived-At: On Tue, Jan 19, 2010 at 2:40 PM, Michael Albinus wrote: > Lennart Borgman writes: > >> Yes, it is broken and it has been so for very long time. I just have >> not understood before that it was in the special case with a file in >> the root of a w32 drive. Hi Michael, Thanks for looking into this. > I could break down the example file from Drew to the following contents: > > > (setq command-history '((describe-key " "))) That is very good to know. Thanks. This makes me guess that it is a decoding problem. > When enabling traces of all Tramp functions, I see > > ====================================================================== > 1 -> tramp-completion-file-name-handler: operation=load args=("c:/emacs-history" nil nil t) .. > | | 3 <- tramp-completion-file-name-handler: "c:/emacs-history" > ====================================================================== > > > As you can see, the error happens inside > `tramp-completion-file-name-handler'. Eh, no. How do I see that ... ;-) Or do you mean that it does not happen inside tramp-completion-file-name-handler? > I've debugged it; the last action > I can see is disabling Tramp' file name completion handler, and calling > `load', again. The error does not seem to be caused inside a Tramp > function. > > As I am not able to debug C sources on W32, I must let it to you. It > seems to be something inside FLoad. Thanks. I have looked into it a bit. I think that what happens is that Vload_source_file_function is not called when the file is in the root of a w32 drive. Instead the alternate readloop further down in `load' (in lread.c) is called. I have not debugged it, this is what I have done instead: (defun temp-load (fullname file &optional noerror nomessage) (message "temp-load %s" fullname) (load-with-code-conversion fullname file noerror nomessage)) (setq force-load-messages t) (setq load-source-file-function 'temp-load) (load "c:/emacs-history") (load "c:/dl/emacs-history") I got this output Loading c:/emacs-history.el (source)... apply: End of file during parsing: c:/emacs-history.el temp-load c:/dl/emacs-history Loading c:/dl/emacs-history...done Looking at the code for `load' in lread.c I think the above shows that loading take different paths in the two cases. When the file is in the root it is not loaded by Vload_source_file_function. I am not sure what is happening, but maybe it goes further down, passing the message statements and further to the readevalloop. When the file is not in the root it is loaded by the Vload_source_file function. >> However I wonder why those files at all are interesting for tramp. I >> know little about tramp, but does not remote file names always start >> with something like "/ssh:", "/ftp:", "/telnet:" etc? >> >> If so why look for file names starting with "c:/"? > > Some packages ( I don't remember which ones) do add the volume letter to > file names, which haven't one. Tramp silently removes the volume letter > then, and continues. But is not that a bug in those packages then? Does not trying to fix it in Tramp introduce this new bug? >> And why does this file handler at all jump in during `load'? Shouldn't >> tramp-completion-file-name-handler just come in during completion? It >> should be invoked when the operations are file-name-completion or >> file-name-all-completion (see >> tramp-completion-file-name-handler-alist), but are these operations >> used during `load'? > > In `tramp-completion-file-name-handler' it is checked, whether Emacs is > in (file name) completion mode. If not, Tramp's file name completion > handler is disables, and the function is re-called, recursively. You mean that tramp-completion-run-real-handler is called when Emacs is not in file completion mode. It looks like it is disabling tramp-completion-file-name-handler. But why is the definition of it inside a (prog ...)? > Best regards, Michael. > >