From: Kenichi Handa <handa@m17n.org>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: 2435@emacsbugs.donarmstrong.com
Subject: bug#2435: Bug 2435
Date: Fri, 06 Mar 2009 13:48:40 +0900 [thread overview]
Message-ID: <E1LfRzE-0000uk-Oh@etlken> (raw)
In-Reply-To: <877i33cmto.fsf@cyd.mit.edu> (message from Chong Yidong on Thu, 05 Mar 2009 23:11:31 -0500)
In article <877i33cmto.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:
> Kenichi Handa <handa@m17n.org> writes:
> > We should take care of re_search_2 and re_match_2_internal
> > too.
> >
> > If the problem is only the call of openp in
> > load_charset_map_from_file, and building various Lisp object
> > is ok, we can change load_charset_map_from_file to open a
> > charset map by itself without using openp.
> Not using openp would be troublesome. How about binding
> file-name-handler-alist to nil inside load_charset_map_from_file? That
> prevents find-file-name-handler from performing the regexp compilation
> and string search.
That's a good idea if "building various Lisp object is ok"
is true.
Stefan, what do you think?
---
Kenichi Handa
handa@m17n.org
*** charset.c.~1.169.~ 2009-01-30 21:29:36.000000000 +0900
--- charset.c 2009-03-06 13:44:24.000000000 +0900
***************
*** 494,499 ****
--- 494,509 ----
extern void add_to_log P_ ((char *, Lisp_Object, Lisp_Object));
+ extern Lisp_Object Vfile_name_handler_alist;
+
+ static Lisp_Object
+ load_charset_map_from_file_restore (arg)
+ Lisp_Object arg;
+ {
+ Vfile_name_handler_alist = arg;
+ return Qnil;
+ }
+
static void
load_charset_map_from_file (charset, mapfile, control_flag)
struct charset *charset;
***************
*** 508,518 ****
--- 518,533 ----
Lisp_Object suffixes;
struct charset_map_entries *head, *entries;
int n_entries;
+ int count = SPECPDL_INDEX ();
suffixes = Fcons (build_string (".map"),
Fcons (build_string (".TXT"), Qnil));
+ record_unwind_protect (load_charset_map_from_file_restore,
+ Vfile_name_handler_alist);
+ Vfile_name_handler_alist = Qnil;
fd = openp (Vcharset_map_path, mapfile, suffixes, NULL, Qnil);
+ unbind_to (count, Qnil);
if (fd < 0
|| ! (fp = fdopen (fd, "r")))
{
next prev parent reply other threads:[~2009-03-06 4:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87fxhvcmvf.fsf@cyd.mit.edu>
[not found] ` <E1LePPk-0002zE-RW@etlken>
2009-03-03 16:40 ` bug#2435: Bug 2435 Chong Yidong
2009-03-04 2:16 ` Kenichi Handa
2009-03-04 4:41 ` Chong Yidong
2009-03-04 7:47 ` Kenichi Handa
2009-03-05 4:09 ` Chong Yidong
2009-03-05 6:39 ` Kenichi Handa
2009-03-05 4:42 ` Chong Yidong
2009-03-05 11:23 ` Kenichi Handa
2009-03-05 16:46 ` Stefan Monnier
2009-03-06 3:38 ` Kenichi Handa
2009-03-06 4:11 ` Chong Yidong
2009-03-06 4:48 ` Kenichi Handa [this message]
2009-03-06 5:07 ` Stefan Monnier
2009-03-06 5:21 ` Kenichi Handa
2009-03-07 4:00 ` Chong Yidong
2009-03-07 23:07 ` Stefan Monnier
2009-03-09 1:12 ` Kenichi Handa
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=E1LfRzE-0000uk-Oh@etlken \
--to=handa@m17n.org \
--cc=2435@emacsbugs.donarmstrong.com \
--cc=cyd@stupidchicken.com \
/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.