bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12598: 24.2; utf-8 codepoints in doc-strings and compression of .el


From: Kenichi Handa
Subject: bug#12598: 24.2; utf-8 codepoints in doc-strings and compression of .el and .elc files
Date: Tue, 05 Feb 2013 22:40:18 +0900

In article <jwv7gmpl72g.fsf-monnier+emacs@gnu.org>, Stefan Monnier 
<monnier@iro.umontreal.ca> writes:

> > Should eval-buffer handle byte-compiled code in a buffer?

> That'd be nice, tho it might be kind of annoying to implement (having to
> look at buffer-file-coding-system to figure out the byte-size of each
> char when skipping #@NN).

If we don't change eval-buffer, we should fix Fload itself.
It has this code now:

  if (!memcmp (SDATA (found) + SBYTES (found) - 4, ".elc", 4)
      || (fd >= 0 && (version = safe_to_load_version (fd)) > 0))
    /* Load .elc files directly, but not when they are
       remote and have no handler!  */
[...]
  else
    {
      /* 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);
        }
    }

Apparently, Fload doesn't intend to handle a compressed
byte-compiled file.  And, it is possible to bind
load-source-file-function to some other function than
load-with-code-conversion, modifing
load-with-code-conversion is not enough.

---
Kenichi Handa
handa@gnu.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]