* more candidates for obsoletion @ 2012-05-01 6:43 Glenn Morris 2012-05-01 19:51 ` Sam Steingold 2012-05-02 9:25 ` Michael Albinus 0 siblings, 2 replies; 13+ messages in thread From: Glenn Morris @ 2012-05-01 6:43 UTC (permalink / raw) To: emacs-devel Any objections to obsoleting: patcomp.el play/bruce.el ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 6:43 more candidates for obsoletion Glenn Morris @ 2012-05-01 19:51 ` Sam Steingold 2012-05-01 22:06 ` Juanma Barranquero 2012-05-02 9:25 ` Michael Albinus 1 sibling, 1 reply; 13+ messages in thread From: Sam Steingold @ 2012-05-01 19:51 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 19:51 ` Sam Steingold @ 2012-05-01 22:06 ` Juanma Barranquero 2012-05-01 22:25 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Juanma Barranquero @ 2012-05-01 22:06 UTC (permalink / raw) To: sds; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 22:06 ` Juanma Barranquero @ 2012-05-01 22:25 ` Lars Magne Ingebrigtsen 2012-05-01 22:28 ` Lars Magne Ingebrigtsen 2012-05-02 5:03 ` Thierry Volpiatto 0 siblings, 2 replies; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-05-01 22:25 UTC (permalink / raw) To: Juanma Barranquero; +Cc: sds, emacs-devel 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 22:25 ` Lars Magne Ingebrigtsen @ 2012-05-01 22:28 ` Lars Magne Ingebrigtsen 2012-05-02 13:02 ` Stefan Monnier 2012-05-02 5:03 ` Thierry Volpiatto 1 sibling, 1 reply; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-05-01 22:28 UTC (permalink / raw) To: Juanma Barranquero; +Cc: sds, emacs-devel 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 22:28 ` Lars Magne Ingebrigtsen @ 2012-05-02 13:02 ` Stefan Monnier 2012-05-13 18:34 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2012-05-02 13:02 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Juanma Barranquero, sds, emacs-devel > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-02 13:02 ` Stefan Monnier @ 2012-05-13 18:34 ` Lars Magne Ingebrigtsen 2012-05-14 2:20 ` Stefan Monnier 0 siblings, 1 reply; 13+ messages in thread From: Lars Magne Ingebrigtsen @ 2012-05-13 18:34 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, sds, emacs-devel 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/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-13 18:34 ` Lars Magne Ingebrigtsen @ 2012-05-14 2:20 ` Stefan Monnier 2012-09-04 18:10 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2012-05-14 2:20 UTC (permalink / raw) To: Lars Magne Ingebrigtsen; +Cc: Juanma Barranquero, sds, emacs-devel > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-14 2:20 ` Stefan Monnier @ 2012-09-04 18:10 ` Lars Ingebrigtsen 2012-09-04 19:29 ` Stefan Monnier 0 siblings, 1 reply; 13+ messages in thread From: Lars Ingebrigtsen @ 2012-09-04 18:10 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, sds, emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-09-04 18:10 ` Lars Ingebrigtsen @ 2012-09-04 19:29 ` Stefan Monnier 2012-09-04 21:24 ` Lars Ingebrigtsen 0 siblings, 1 reply; 13+ messages in thread From: Stefan Monnier @ 2012-09-04 19:29 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Juanma Barranquero, sds, emacs-devel >> - 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-09-04 19:29 ` Stefan Monnier @ 2012-09-04 21:24 ` Lars Ingebrigtsen 0 siblings, 0 replies; 13+ messages in thread From: Lars Ingebrigtsen @ 2012-09-04 21:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juanma Barranquero, sds, emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 22:25 ` Lars Magne Ingebrigtsen 2012-05-01 22:28 ` Lars Magne Ingebrigtsen @ 2012-05-02 5:03 ` Thierry Volpiatto 1 sibling, 0 replies; 13+ messages in thread From: Thierry Volpiatto @ 2012-05-02 5:03 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: more candidates for obsoletion 2012-05-01 6:43 more candidates for obsoletion Glenn Morris 2012-05-01 19:51 ` Sam Steingold @ 2012-05-02 9:25 ` Michael Albinus 1 sibling, 0 replies; 13+ messages in thread From: Michael Albinus @ 2012-05-02 9:25 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-09-04 21:24 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-05-01 6:43 more candidates for obsoletion Glenn Morris 2012-05-01 19:51 ` Sam Steingold 2012-05-01 22:06 ` Juanma Barranquero 2012-05-01 22:25 ` Lars Magne Ingebrigtsen 2012-05-01 22:28 ` Lars Magne Ingebrigtsen 2012-05-02 13:02 ` Stefan Monnier 2012-05-13 18:34 ` Lars Magne Ingebrigtsen 2012-05-14 2:20 ` Stefan Monnier 2012-09-04 18:10 ` Lars Ingebrigtsen 2012-09-04 19:29 ` Stefan Monnier 2012-09-04 21:24 ` Lars Ingebrigtsen 2012-05-02 5:03 ` Thierry Volpiatto 2012-05-02 9:25 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).