Re: more candidates for obsoletion

[Lars Ingebrigtsen <larsi@gnus.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  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);
>>  }

(I'm including the patch again, since it's been years since it was last
seen.  Or something.  :-)

> Doesn't look too bad.  A few questions and suggestions:
> - !NILP is implied y STRINGP.
> - You might prefer to use fast_string_match.

Fixed and fixed.  And then I don't have to save the match data either, I
guess?

> - Is the recursive debugging a problem you've found to show up
>   unavoidably all the time, or are you just being cautious?

It is a real problem.  My first test case used a string that the
debugger used, too, so Emacs went into an infinite debugging loop...

> - 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.

Sounds good.  I've had a peek around the sources, but I can't quite see
how to let-bind something from C.  What should I be looking for as an
example?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Emacs