all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 5303@debbugs.gnu.org, cyd@stupidchicken.com
Subject: bug#5303: 23.1.91; Cannot load .emacs-history from savehist.el
Date: Tue, 19 Jan 2010 23:24:55 +0200	[thread overview]
Message-ID: <83k4vd7pp4.fsf@gnu.org> (raw)
In-Reply-To: <87bpgphop0.fsf@gmx.de>

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Drew Adams <drew.adams@oracle.com>,  lennart.borgman@gmail.com,  5303@debbugs.gnu.org,  cyd@stupidchicken.com
> Date: Tue, 19 Jan 2010 20:36:27 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What is in the-file.el? will an empty file do? if not, what should be
> > there to reproduce the problem?
> 
> ------
> (setq command-history '((describe-key "^Z")))
> ------

Thanks.

I see the problem, but there's too many dragons here, or maybe it's
too late.

Here's the story I got so far.

The root cause for the problem is that we read this file in text mode,
not in binary mode.  Because of that, the literal C-z character in the
file is treated as EOF (a CP/M legacy, no less), and the rest is
history.

Why do we read the file in text mode?  That's where things become
rather murky.  AFAIK, we ought to be reading the file with
load-with-code-conversion, which is the value of
Vload_source_file_function:

      /* We are loading a source file (*.el).  */
      if (!NILP (Vload_source_file_function))
	{
	  Lisp_Object val;

	  if (fd >= 0)
	    emacs_close (fd);
	  val = call4 (Vload_source_file_function, found, hist_file_name,
		       NILP (noerror) ? Qnil : Qt,
		       (NILP (nomessage) || force_load_messages) ? Qnil : Qt);
	  return unbind_to (count, val);
	}

But we don't get to this code because we are caught here:

  if (!bcmp (SDATA (found) + SBYTES (found) - 4,
	     ".elc", 4)
      || (version = safe_to_load_p (fd)) > 0)
    /* Load .elc files directly, but not when they are
       remote and have no handler!  */

[Btw, I don't understand this condition.  What it's supposed to do?
allow us to load a byte-compiled file whose name does not end in a
.elc?]

(Are you saying "Huh??" yet?)  And we are caught here because,
although the file name does not end in .elc, safe_to_load_p returns
1.  Why? because fd is -2, and safe_to_load_p bravely returns 1 when
it fails to read from the file:

  static int
  safe_to_load_p (fd)
       int fd;
  {
    char buf[512];
    int nbytes, i;
    int safe_p = 1;
    int version = 1;

    /* Read the first few bytes from the file, and look for a line
       specifying the byte compiler version used.  */
    nbytes = emacs_read (fd, buf, sizeof buf - 1);
    if (nbytes > 0)
      {
      ...
      }
    if (safe_p)
      safe_p = version;

    lseek (fd, 0, SEEK_SET);
    return safe_p;
  }

Granted, trying to read from fd = -2 fails, and we return 1 here.  Is
that really supposed to happen?

Another question is why fd is -2.  That means `openp' detected that
C:/the-file.el is a ``magic'' file, i.e. it has a file handler.  But
this happens in a recursive call to `load', the one where, as Michael
says:

> the last action I can see is disabling Tramp' file name completion
> handler, and calling `load', again.

It looks like disabling Tramp's file name completion handler does not
prevent `openp' from thinking that C:/the-file.el has a handler.
However, when we actually try to find this handler after `openp'
returns -2, the handler turns out to be nil:

  /* If FD is -2, that means openp found a magic file.  */
  if (fd == -2)
    {
      if (NILP (Fequal (found, file)))
	/* If FOUND is a different file name from FILE,
	   find its handler even if we have already inhibited
	   the `load' operation on FILE.  */
	handler = Ffind_file_name_handler (found, Qt);
      else
	handler = Ffind_file_name_handler (found, Qload);
      if (! NILP (handler))
	return call5 (handler, Qload, found, noerror, nomessage, Qt);
    }

Thus, we don't call the handler, and end up with fd = -2, but in the
portion of code that doesn't seem to be able to handle this situation
well: it just calls readevalloop.  What is this part of Fload for? is
it for the case where we don't yet have mule.el loaded, and thus
load-with-code-conversion is not available?

I didn't yet have time to see why Emacs 23.1 does not hit this
problem, but given the above mess, it could well be by sheer luck.

Anyway, it's too late now.  If no one beats me to it, I will continue
tomorrow.






  reply	other threads:[~2010-01-19 21:24 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8F73D1539CE042B8A9B48F767127C43B@us.oracle.com>
2010-01-16 19:33 ` bug#5303: 23.1.91; Cannot load .emacs-history from savehist.el Chong Yidong
2010-01-16 20:03   ` Lennart Borgman
2010-01-16 21:11     ` Kevin Rodgers
2010-01-17 16:54     ` Michael Albinus
2010-01-17 16:58       ` Lennart Borgman
2010-01-17 17:18         ` Michael Albinus
2010-01-17 19:46           ` Lennart Borgman
2010-01-19 13:40             ` Michael Albinus
2010-01-19 17:39               ` Drew Adams
2010-01-19 19:28                 ` Eli Zaretskii
2010-01-19 19:30                   ` Chong Yidong
2010-01-19 19:36                   ` Michael Albinus
2010-01-19 21:24                     ` Eli Zaretskii [this message]
2010-01-19 22:13                       ` Eli Zaretskii
2010-01-20  1:25                       ` Lennart Borgman
2010-01-20  8:44                       ` Michael Albinus
2010-01-20  8:46                         ` Lennart Borgman
2010-01-20  8:56                           ` Michael Albinus
2010-01-20  9:02                             ` Lennart Borgman
2010-01-20  9:45                         ` Michael Albinus
2010-01-20 10:39                           ` Eli Zaretskii
2010-01-20 10:50                             ` Michael Albinus
2010-01-19 19:37                   ` Drew Adams
2010-01-19 19:44                     ` Eli Zaretskii
2010-01-19 19:52                       ` Drew Adams
2010-01-19 21:31                         ` Eli Zaretskii
2010-01-19 20:01               ` Lennart Borgman
2010-01-20  9:00                 ` Michael Albinus
2010-01-20  9:04                   ` Lennart Borgman
2010-01-20 10:13                     ` Michael Albinus
2010-01-20 10:38                       ` Lennart Borgman
2010-01-20 12:01                         ` Michael Albinus
2010-01-20 12:03                           ` Lennart Borgman
2010-01-20 12:15                             ` Michael Albinus
2010-01-20 12:21                               ` Lennart Borgman
2010-01-20 15:32                           ` Drew Adams
2010-01-20 15:41                             ` Michael Albinus
2010-01-20 17:33                               ` Drew Adams
2010-01-20 18:18                               ` Eli Zaretskii
2010-01-21  1:02                                 ` Lennart Borgman
2010-01-21 18:24                                   ` Eli Zaretskii
2010-01-21 18:42                                     ` Chong Yidong
2010-01-21 20:41                                       ` Chong Yidong
2010-01-20 18:17                             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83k4vd7pp4.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=5303@debbugs.gnu.org \
    --cc=cyd@stupidchicken.com \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.