[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more candidates for obsoletion
From: |
Stefan Monnier |
Subject: |
Re: more candidates for obsoletion |
Date: |
Sun, 13 May 2012 22:20:36 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
> static void
> set_message (const char *s, Lisp_Object string,
> EMACS_INT nbytes, int multibyte_p)
> {
> + int count = SPECPDL_INDEX ();
> +
> message_enable_multibyte
> = ((s && multibyte_p)
> || (STRINGP (string) && STRING_MULTIBYTE (string)));
> @@ -10420,6 +10431,19 @@
> (intptr_t) s, string, nbytes, multibyte_p);
> message_buf_print = 0;
> help_echo_showing_p = 0;
> +
> + record_unwind_save_match_data ();
> +
> + if (! debugging &&
> + ! NILP (Vdebug_on_message) &&
> + STRINGP (Vdebug_on_message) &&
> + ! NILP (Fstring_match (Vdebug_on_message, string, Qnil))) {
> + debugging = 1;
> + record_unwind_protect (undo_debugging, Qnil);
> + call_debugger (Fcons (Qerror, Fcons (string, Qnil)));
> + }
> +
> + unbind_to (count, Qnil);
> }
Doesn't look too bad. A few questions and suggestions:
- !NILP is implied y STRINGP.
- You might prefer to use fast_string_match.
- Is the recursive debugging a problem you've found to show up
unavoidably all the time, or are you just being cautious?
- You could turn your `debugging' into a Lisp var (call it
"inhibit-debug-on-message"), or you could let-bind debug-on-message to
nil around the call to the debugger.
Stefan
Re: more candidates for obsoletion, Michael Albinus, 2012/05/02