opensubscriber
   Find in this group all groups
 
Unknown more information…

e : emacs-devel@gnu.org 14 May 2012 • 10:20AM -0400

Re: more candidates for obsoletion
by Stefan Monnier

REPLY TO AUTHOR
 
REPLY TO GROUP




>  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


Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.