[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
bug#12598: 24.2; utf-8 codepoints in doc-strings and compression of .el and .elc files, Stefan Monnier, 2013/02/08