[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: |
Eli Zaretskii |
Subject: |
bug#12598: 24.2; utf-8 codepoints in doc-strings and compression of .el and .elc files |
Date: |
Sat, 09 Feb 2013 11:16:40 +0200 |
> From: Kenichi Handa <handa@gnu.org>
> Date: Sat, 09 Feb 2013 14:05:50 +0900
> Cc: Stromeko@nexgo.de, 12598@debbugs.gnu.org
>
> In article <jwvwqulebdh.fsf-monnier+bug#12598@gnu.org>, Stefan Monnier
> <monnier@IRO.UMontreal.CA> writes:
>
> > I notice here that jka-compr-load is supposed to handle this case, but
> > was somehow not triggered. Maybe we should fix that part.
>
> It seems that Fload explicitly suppresses that trigger.
>
> /* If file name is magic, call the handler. */
> /* This shouldn't be necessary any more now that `openp' handles it right.
> handler = Ffind_file_name_handler (file, Qload);
> if (!NILP (handler))
> return call5 (handler, Qload, file, noerror, nomessage, nosuffix); */
>
> I don't understand the above comment (why can openp handle
> this case?)
See "bzr diff -c 39793". In that revision, the SUFFIXES argument to
openp was changed, and its handling inside openp was changed as well.
I believe the intent was to let openp call the file handler.
> and I confirmed that loading *.elc.gz works well by enabling this
> code again.
Why doesn't it work when openp calls the same handler?
bug#12598: 24.2; utf-8 codepoints in doc-strings and compression of .el and .elc files, Stefan Monnier, 2013/02/08