Subject: Re: bug#5303: 23.1.91; Cannot load .emacs-history from savehist.el

From: Lennart Borgman <[email-masked]>
Date: Tue, 19 Jan 2010 21:01:04 +0100

On Tue, Jan 19, 2010 at 2:40 PM, Michael Albinus <[email-masked]> wrote:
> Lennart Borgman <[email-masked]> 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.