more candidates for obsoletion

more candidates for obsoletion

[Glenn Morris]

Any objections to obsoleting:

patcomp.el
play/bruce.el

Re: more candidates for obsoletion

[Sam Steingold]

btw, I have been getting "Package assoc is obsolete!" message on startup
for some time. I don't use assoc myself, so I wonder how I can figure
out which of the packages I use load it (to alert their maintainers).

> * Glenn Morris <etz@tah.bet> [2012-05-01 02:43:38 -0400]:
>
> Any objections to obsoleting:
>
> patcomp.el
> play/bruce.el
>
>

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 11.10 (oneiric) X 11.0.11103000
http://www.childpsy.net/ http://www.memritv.org
http://jihadwatch.org http://palestinefacts.org http://ffii.org
There are 3 kinds of people: those who can count and those who cannot.

Re: more candidates for obsoletion

[Juanma Barranquero]

On Tue, May 1, 2012 at 9:51 PM, Sam Steingold <sds@gnu.org> wrote:

> btw, I have been getting "Package assoc is obsolete!" message on startup
> for some time. I don't use assoc myself, so I wonder how I can figure
> out which of the packages I use load it (to alert their maintainers).

It shouldn't be hard to see in *Messages*. For example, if you do

 emacs -Q
 M-x load-library vhdl-mode <RET>

you'll see this in *Messages*

  Loading vhdl-mode...done
  Package assoc is obsolete!

Or, as a last resort, you can temporarily rename
lisp/obsolete/assoc.elc? and see which package from your .emacs fails
to load :-)

    Juanma

Re: more candidates for obsoletion

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

>   Loading vhdl-mode...done
>   Package assoc is obsolete!

It would, perhaps, be nice if the "obsolete" message described the
require trace?  Like

Package assoc is obsolete (loaded via foo->bar->zot->vhdl-mode)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: more candidates for obsoletion

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>>   Loading vhdl-mode...done
>>   Package assoc is obsolete!
>
> It would, perhaps, be nice if the "obsolete" message described the
> require trace?  Like
>
> Package assoc is obsolete (loaded via foo->bar->zot->vhdl-mode)

But this reminds me of a feature that I'd really like to see: Being able
to instrument a message for a backtrace.

That is, say `M-x backtrace-message RET obsolete RET', and then get a
backtrace whenever a string matching "obsolete" is messaged.

Especially with warning messages is can be really difficult to find out
the call sequence.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: more candidates for obsoletion

[Stefan Monnier]

> That is, say `M-x backtrace-message RET obsolete RET', and then get a
> backtrace whenever a string matching "obsolete" is messaged.

Sounds good (tho I'd call it debug-on-message or something like that).
Patch welcome,


        Stefan

Re: more candidates for obsoletion

[Lars Magne Ingebrigtsen]

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

>> That is, say `M-x backtrace-message RET obsolete RET', and then get a
>> backtrace whenever a string matching "obsolete" is messaged.
>
> Sounds good (tho I'd call it debug-on-message or something like that).
> Patch welcome,

If we want to get all the messages, I think set_message might be the
most likely place to put this.

The main problem is then how to avoid debugging recursively forever.
The following works, but surely there's an easier way to do this...

Proof of concept patch follows.  The real one would be structured
slightly differently:

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2012-05-11 06:39:26 +0000
+++ src/xdisp.c	2012-05-13 18:32:19 +0000
@@ -10407,11 +10407,22 @@
    Doesn't GC, as with_echo_area_buffer binds Qinhibit_modification_hooks
    to t before calling set_message_1 (which calls insert).
   */
+Lisp_Object call_debugger (Lisp_Object arg);
+static int debugging = 0;
+
+Lisp_Object
+undo_debugging (Lisp_Object arg)
+{
+  debugging = 0;
+  return Qnil;
+}
 
 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);
 }
 
 
@@ -28824,6 +28848,10 @@
   Vglyphless_char_display = Fmake_char_table (Qglyphless_char_display, Qnil);
   Fset_char_table_extra_slot (Vglyphless_char_display, make_number (0),
 			      Qempty_box);
+
+  DEFVAR_LISP ("debug-on-message", Vdebug_on_message,
+    doc: /* If non-nil, debug if a message matching this regexp is displayed.  */);
+  Vdebug_on_message = Qnil;
 }
 
 



-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: more candidates for obsoletion

[Stefan Monnier]

>  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

[Lars Ingebrigtsen]

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

Re: more candidates for obsoletion

[Stefan Monnier]

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

Indeed.

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

IIRC debug-on-error and debug-on-quit are let-bound to nil in the Elisp
part of the code, so you should do that as well (see debug.el).
Otherwise, `specbind' is the magic function to use from C.


        Stefan

Re: more candidates for obsoletion

[Lars Ingebrigtsen]

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

> IIRC debug-on-error and debug-on-quit are let-bound to nil in the Elisp
> part of the code, so you should do that as well (see debug.el).
> Otherwise, `specbind' is the magic function to use from C.

Ah, right.

I'm not a 100% sure I understand quite all the DEFSYM v DEFVAR stuff
works, actually.  Which should be a bit embarrassing after all these
years.

Anyway, I've now committed this little thing, so feel free to fix up any
things that aren't quite right.  :-)

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

Re: more candidates for obsoletion

[Thierry Volpiatto]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>>   Loading vhdl-mode...done
>>   Package assoc is obsolete!
>
> It would, perhaps, be nice if the "obsolete" message described the
> require trace?  Like
>
> Package assoc is obsolete (loaded via foo->bar->zot->vhdl-mode)
I would be nice also to have a more instructive message when a package
fail to load using `require'; Actually it just tell an error occur
loading ".emacs.el", but we don't know where.
I call here `require' in a `condition-case' to catch possible error and
send an instructive message about this error.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: more candidates for obsoletion

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Any objections to obsoleting:
>
> patcomp.el
> play/bruce.el

I propose also to obsolete net/xesam.el. XESAM is not developped
anymore since its 1.0 release (2009), and its web site xesam.org is
vanished.

In some projects, XESAM has been replaced by Nepomuk.

Best regards, Michael.